A Few Minutes with AppleCare

A survey request I didn’t mind receiving

This was originally published on my other blog, but I think it works here, too. I know from comments I’ve received on previous posts that some of you are not fans of Apple. I’m not so much a fan of Apple, as I am a developer who has to work with Apple as we create iPhone/iPad Apps for our employees.

I’m not trying to convince you to buy an iPhone, an iPad or a Mac. I don’t care what you use to do your job, pay your bills, process your photos or write your blog. If you’re happy, I’m happy. I use my iPhone for nearly everything one can do with a phone these days. I use my iPad in support of business, especially while traveling. I write my blog, process my pictures and do the bulk of my job on Windows laptops. My wife pays the bills.

Regardless of what technology, platform (if my boss is reading this, his eyes just rolled) or operating system you’re using, occasionally, you need help. Sometimes, you have to deal with a large vendor’s myriad-level-deep-voice-mail-to-nowhere. Sometimes, your request is routed “off-shore.” Sometimes, you’re relegated to a web-based process, be it a chat or an email exchange. Quite often, you’re left on your own to google your way out of a deep hole.

When I began my call with Apple’s Developer Support Group, I wasn’t optimistic. Mine wasn’t a technical issue, it was an account governance issue, and our two development accounts with Apple are governed (on their end) by over 2,000 pages of terms. I can’t share the details of my issue (try to hide that smile), but I want to share six things that AppleCare did well. So well that I would recommend that any organization, technical or otherwise, steal these ideas. Seriously, steal them! This is one case where you want to be like Apple.

The questions speak to the things Apple is trying to achieve.

1) Four simple options – There was no guesswork involved in the simple voice mail prescreening message. Choices 1-3 were binary. They wanted to know if I was involved with three very specific things. I wasn’t, so I pressed 4 as instructed.

2) Hold Music Options – This is one thing that could make all tech-support / customer service so much better. I had the option to: hold with pop/rock, hold with classical music, hold with jazz or hold in silence. Please, steal this idea, even if you only add “hold in silence” as an option.

3) Fast & Accurate – I was expecting my ‘4 – other’ key press to lead me to a long wait. Instead, in under 3 minutes, a cheerful human being picked-up. Matt asked me several questions. He repeated back the important information, use phonetic “N as in Nancy” spelling to verify details like my email address, and he summarized my problem and stated his understanding of my objective. Oh my word, this guy actually wanted to make sure that he knew what I wanted as an outcome!

Unfortunately, after all the gathering, spell-checking and objective understanding, Matt couldn’t actually help me. But, he said that he knew the group who should be able to help me. Now you know as well as I do, that this is where customer service sinks into a frustrating, seemingly endless, often circular journey of despair. My experience was different:

4) Information gathered and provided – Matt asked for a callback number, in case his attempts to transfer me failed. He also gave me the direct number of the group that he was transferring me to. He put me on hold (previous options, still in effect) for what initially seemed like a long time. Then Matt came back on the line and introduced me to Ashley.

5) Amazing – Number five is now known as “The Amazing Number 5!” I’m talking five golden rings amazing. When Ashley picked up she said: “Matt briefed me on your issue.” What? What tech support school did you guys go to? I was expecting Ashley to start at the beginning, run me through all the questions and then punt me to some no-nothing-schlep who would repeat the process. I didn’t have to repeat anything. She began with a summary of my problem and my expectations, as she understood them. She was correct.

Ashley couldn’t help me achieve the objective I wanted, because Apple doesn’t permit the type of account management I wanted to establish. She did, however, offer an acceptable alternative. She carefully explained the alternative and I agreed that, while different than what I had hoped for, it would work just as well.

6) Insure success – Before hanging up, she asked me if I knew all the steps I had to complete and if I knew how to complete them. She listened while I explained my next steps, she confirmed that my understanding was correct, and she offered to stay on the line while I completed those tasks.

Except for maybe giving Ashley a sweet southern accent, I can’t imagine anything that could have improved my experience. Again, I’m not shilling for Apple, but I do think there are some lessons to be learned from this experience.

The Cost Benefit of User Experience

What are people saying about the last thing you built for them?

I’m doing you a favor today. I’ve written about this subject before, but I’m going to spare you the trouble of searching my blog and I’m going to spare you the accidental navigation (if you’re reading this on a mobile device and trying to scroll) caused by me inserting a bunch of links to previous posts. I’m looking back over my 35-plus years doing systems development and I’m going to summarize the whole thing for you:

The people who use the systems you build deserve the best experience you can give them.

There. That’s it. That’s really all you have to read. If you are wondering how I came to that conclusion or why I’m bringing it up, feel free to continue reading but if you’re content to nod your head and even grudgingly agree with me, well then, off you go.

OK, you stuck around. You know what that means. You’re going to have to read a story.

In 1988, I was in a meeting with my boss, a representative of our underwriting department and one of my better programmers. We were discussing a feature the underwriters wanted in the system we were developing for them. First, a little background (hey, you had your chance to leave):

Nuclear reactors get shut down for stuff like refueling and when they are shut down we charge them less for insurance. The way we do this is by dividing the year into a series of consecutive time intervals, each with its own set of state variables and its own pro-rata premium. Creating a new time interval was a big deal and a difficult process prior to the system we were writing. The designer wanted to make it easy. He wanted the system to show a list of time intervals and let the user highlight one and press the “+” key to insert a new time interval after the highlighted one.

This seemed like a simple request and I agreed to it. The designer wanted more. Since we had never had such an interactive feature in a screen before (this was running under DOS), he wanted us to build a prototype. I told him that wasn’t necessary. I told him that he could see the working element as soon as it was done. He argued that a prototype was necessary because this was a “radical departure from any previous approach.” He also added that he wasn’t sure we could make this. I slammed my hand on the table and said:

“If the feature you want can be programmed on a DOS PC, she can build it. We don’t have to prove that to you up front, just let her do her (expletive) job!”

After the meeting, the woman came into my office and said:

“I appreciate your confidence in me and I like the way you stood up for me, but I don’t actually know how to do that.”

I knew that, but as far as I was concerned, that fact was irrelevant. She could learn. The feature was going to make someone’s job easier and that was worth learning how to do.

Today, as we are in the early days of a new wave of development, I am more convinced than ever that the effort required to build a better user experience is a price worth paying. The math is simple. You build a system once every three to five to seven years but people use that system every single day. Where do you want them to register on the UI-O-Meter?

As an added benefit for those of you who stuck around, I am giving you the answers to a few common problems. Note: I have tested all of these:

“We don’t have time to do this” – Give them a choice of waiting a little longer or accepting a second phase to the project.

“We can’t do that in SharePoint” – Buy an add-on feature or hire one of those SharePoint whiz-kid consultants who can.

“This can’t be done in SharePoint” – Move the process to a different platform.

“This would take too many development hours” – Do the math. Development hours vs. hours spent using a crappy system.

If all of those fail, slap your hand on the table and sprinkle in a few bad words.

If you have your own favorite excuse and an alternate way of looking at it, please add your thoughts to the comments.

Liking Nintex

Summer is a funny time in most small shops. Projects start and stop as people take time off and attentions get diverted to the periodic crisis or to fill-in for an absent coworker. The downside for someone trying to craft a blog entry at the end of each week is that there isn’t much to work with. Those of you that come here don’t come to hear about the meetings I attended or the fires I put out. The upside is that this post will be short.

One of the interesting things I did this week was to build a SharePoint Workflow using Nintex Workflow. I’ve used Nintex before, but this time, I was teaching someone else how to build a “proper” workflow. The workflow is another part of our Payables process and it allows our accountants to delete a payable that has been submitted and approved for payment. Yeah, sometimes people make mistakes. To prevent someone from making those mistakes worse, this workflow needs to verify that a series of conditions are true. The payable has to be at a specific status. The person running the workflow has to be a member of accounting. A bunch of people have to be notified, the activity has to be logged and we also have to let people know if any of those conditions aren’t met and the workflow has to be stopped.

All of those things can be done using a SharePoint Designer workflow. So, why does the title point out that I like Nintex Workflows? Well, that’s the point of this post. Here is my list of the things I like about Nintex Workflows:

I can add multiple logical conditions into the kick-off point of a single “Run if” block. You can see that illustrated in the image at the top.

I can act against multiple list items in one step. For example, I can say “go find all the allocations that have the same payment_request_ID as this item and delete them.” You can’t do that in SharePoint Designer in SharePoint 2010

I can give an intelligent name to each workflow step. So, the above example step can be called “Delete Allocations” – I like that.

I can copy steps. We need to create a log entry regardless of the end-state of the process. Since some of those states cause the workflow to stop, I need to have the “Create Log Entry” step in multiple places which is very easy to do. Copy. Paste. Configure. Done.

I can drag and drop steps in and out of Condition blocks and Impersonation blocks which is very helpful when you realize that you have the right action but that it’s happening in the wrong place.

I can export and import entire workflows. In fairness, I think I can do this in SharePoint Designer, but I have had problems with that process and this worked like magic. I built the basic structure of this workflow from an earlier workflow that lets the person who submitted the payable to delete it before it’s approved.

And, my favorite thing – you work in a browser as opposed to a somewhat finicky, somewhat unpredictable and somewhat predictably bad stand-alone product.

That’s it for today. Not much of a product review, but I think you can understand why I like Nintex. And, I said it in fewer than 600 words.

Good Question, the Answer is Yes!

After some fairly extensive proof-of-concept work, I had the opportunity to meet with some of our engineers this week to review our plans for the “system” of SharePoint lists, libraries, interconnecting metadata and workflows required to track the recommendations the engineers make as a result of their inspections. Wow, was that really one sentence? Sorry. Everything that I took to the meeting was wired together to support a smooth flowing business process. Of course, this was a review with the end-users, the people who know how that smooth process goes off the rails.

As I worked my way through the process flow I described last week, a question emerged. I had described how, in order to avoid processing a recommendation, only to have it be removed after review, the main workflow wouldn’t run until the report status was final. They pointed out that while that was logical most of the time, during the group review meeting they need to review all recommendations, including the ones that are “about to be released.” No problem, the workflow can be started manually. Also, we will add another little bit of metadata to prevent duplicate updates from occurring when the report gets released.

We spent a good deal of time reviewing the way the workflow was processing the text of the Word document. “What if the order (New, Pending, Open, Closed) was mixed up?” “What if we refer to a recommendation inside the text of another recommendation?” “What if the status e.g. ‘pending’ is used in the body of the recommendation?” All good questions, but none of them are show stoppers.

I had been tipped off to the fact that the various status states could appear in any order. The good thing about processing text with the aid of a Regular Expression is that I don’t need to care where the text is. Also, the format of these reports allows me to distinguish between “Pending” as a section header and “pending” as in “the reason this recommendation is still pending…” Same with the recommendation numbers, HarePoint’s workflow extensions lets me distinguish between a number used as a title and the same number used in text. There’s no magic here, when these strings are used as headers, they are either preceded or followed by CR/LF combinations.

The next question revealed a bit of the process that I was not aware of, “what about recommendation status changes that result from a phone call or an email?” I had to stop and think, and I had to remember that:

SharePoint “systems” are still in SharePoint.

In other words, everything that the workflow is doing can be done (or undone) by humans. Engineers love hearing that. They love knowing that there is a ‘manual override’ or a way to start, stop and derail a process without having to call the IT Guy. Of course, I mentioned that while phone calls would require a manual entry, we could easily apply a similar workflow to an email-enabled library. In that case, the engineer could simply CC SharePoint and let the automation happen. We opted not to add that feature, but it’s always nice letting people know that SharePoint is prepared to go even further.

The final significant questions were focused on the recommendation review process itself. The process starts with a recommendation by one engineer. The group reviews the material and decides whether to accept, reject or modify the proposal. “Can we differentiate between what the account engineer proposes and what the committee approves?” “Yes, absolutely, how do you want to do it?” Options include:

• Change a bit of metadata in the item from ‘proposed’ to ‘approved’
• Keep the proposed version of the item in addition to the approved version
• Duplicate the proposed item as a stub approved item at the start of the review process

They opted for the third choice. They wanted a visible trail to indicate the activity. I pointed out that we could build columns into the item so each item could store before and after versions of the metadata, but that seemed messy.

The last question was kind of a bonus question: “is there any way that all this stuff can help us document the proceedings of the review committee?”

“Yes, yes it can.”

Given the choices that they made, it will be pretty easy to prepare a composite view of the proposed items and the approved items that will provide a chronology of what took place. We won’t be recording the conversation, but we will be documenting the results.

The really cool part of this conversation was that, with the exception of a few tricky bits from HarePoint, this can all be brought to our engineers courtesy of out-of-the-box SharePoint. Microsoft baked some serious power into this product.

Episode II

Shortly after I posted the first episode in this little mini-series on leaving SharePoint, Christophe a.k.a. @PathToSharePoint suggested that Office 365 might be the answer to the problems we are having. I responded, telling him SharePoint 365, sorry SharePoint Online will have a role in our future, just not this role. It is as if SharePoint Online had shown up for an audition, missed the lead role but got picked up as an extra on a different film. Hey, that’s show-biz.

The reason we looked at SharePoint Online was because we thought it would be easy. In some ways, it would be easy. Unfortunately, the ways in which it would be easy are the ways it would be easy for us. We already know SharePoint, so working with SharePoint in the cloud would be a snap. We already have the content organized in SharePoint so moving it to the cloud would be a snap. We already own MetaVis, so moving our on-premises SharePoint stuff into the cloud would be…what’s the word for a snappier snap…let’s say easy-peasy. The problem is that we’re supposed to be making life easier for our customers. How does that work for me?

Once when I was discussing two options with my boss, he summarized my arguments by saying:

“Let’s see, the business benefits are the same. Option one is expensive but it would be easy for you. Option two is cheap but it will be harder for you to work with. I’m going to go with option two.”

That’s the thing with business problems, the solutions are spread across a spectrum of benefit. If we can’t have the whole rainbow, we have to focus on our members and our customers first.

The big reason SharePoint Online would be easy is because we are going to use it for a part of our normal business process. We have some stuff in SharePoint on premises that requires high availability. Specifically, it needs to be available when our office is without power. We don’t have any redundant power options, so we have to create redundant content. The content is in SharePoint, the redundant content will be in SharePoint online, done. That works really well, but again, it works for us. There are ways to make it easy for our domain users to log into SharePoint in the cloud, but our customers aren’t in our domain. In order to get them to login, they would have to have some sort of Microsoft account.

As far as Microsoft is concerned, this isn’t an issue because everybody either has or can have a Microsoft account. Yeah, but that’s not really the case. Some people don’t have an account. Some of those people don’t want one. Some people have a Microsoft account, but it isn’t associated with their job.

I had to create a Microsoft account in order to work with an association I belong to. As an old boss used to say: “the process was 1, 2, 6;” in other words, a snap. I don’t use this account very often, but whenever I do, my first task is to delete about 100 pieces of junk mail. This is the last thing I want our customers to have to do in order to work with us.

In addition, for security reasons, some of our customers are prevented from using personal credentials to access content while at work and others are prevented from creating such an account that is linked to their domain email address. In our on premises implementation, we had a separate domain and we issued credentials when necessary. Moving to the cloud seemed like a step backward as far as user experience goes.

Finally, in addition to all of the above, if we did go with SharePoint Online as a solution, our content would be in SharePoint, duh. I you remember the original post in this series, the problem with that is that most of our customers, I’d say 95% of them; simply want to download files from our repository. They don’t want calendars, tasks, blogs, wikis, custom lists, metadata and workflows – just the files. When that’s all they want, you either have to spend time to make SharePoint look less capable than it is, or you are going to make your customers wade through a process that seems overly complex.

If you are a lover of suspense, stop reading. I’m going to spoil the ending of this saga. We have decided to use Citrix ShareFile for this application. I’ll explain why we selected it and how we use/plan to use that service in the final installment of this series. Until then, I can say that we are very excited about it, our employees are very excited about it and the customers we’ve spoken to are very excited about it.

It’s Alive

Well I guess the phrase is actually “it’s now gone live” but that just doesn’t invoke the same emotional response. We have a business process that is now partially running in SharePoint. Even better, the right portion is running in SharePoint and the stuff that shouldn’t be in SharePoint is running somewhere else.

The business process is “payables” – something everybody has to do but something most people do differently than we do. See, we’re small, we don’t have a lot of vendors, we don’t have a complicated (no you can’t have that) procurement process and we don’t have a receiving dock. We buy things. We hire contractors. We incur professional fees. We refund premium on occasion and we reimburse people for things. We do this a bunch of ways. We have Concur (shudder and cue the foreboding music) which I actually kinda like. We do ACH transactions. We do wire transfers and we write checks. We also periodically reimburse people for small purchases with something called cash. I’m sure some of the younger readers are Googling that term.

The payables process, in addition to resulting in many financial outcomes, begins with a variety of financial transactions. Eventually, we will lasso all of these transactions and pull them into the same ring, but we decided to start with Check-Requests and checks. The process is pretty simple. We buy something from a vendor. They send us an invoice. We send them a check. In between step 2 and 3, someone studies the invoice, makes sure it’s legitimate, prepares a check request and then somebody else approves that request. That whole process, the stuff between step 2 and 3, is now done in SharePoint. Below are some of the cool things we (remember ‘we’ now means ‘they’ and stands for the shy people on my team) were able to include:

• Maintaining a list of vendors that are automatically checked to make sure they aren’t on the US Treasury’s list of bad guys, and then approved by someone in authority in accounting.
• Create a check request for an invoice(s) from an approved vendor.
• Attach the image(s) of the receipt(s) to that check request.
• Allocate the amount of that/those invoice(s) across multiple departments or multiple accounts within a department. For example, I buy a server, but some portion of the invoice is for the warranty.
• Route the check request to one or more people for approval.
• Do all the little checks and balances like making sure that the total of the allocations equal the total of the request.
• Approve individual check requests for payment.
• Allow the approvers to send the request back to the previous person to correct an error.

The tools used to make this happen include:

• SharePoint external lists and the ability to impersonate users when working with them
• InfoPath forms
• Custom lists and views
• Data View Web Parts to put the forms, lists and view on a single interactive page.
• SharePoint Designer workflows to respond to the various activities a user did and to validate the transaction while it is in process
• HarePoint’s Workflow Extensions to do some of the tricky stuff that SharePoint Designer doesn’t seem to do, like execute SQL Statements or use Regular Expressions to evaluate a sting.
• Nintex Workflow’s “for each” capability to cycle through each Paid request in an external list to update our detailed custom list with the payment details.
• All the various widget to widget connections you can establish in SharePoint Designer to get web parts to respond to other web parts.

We decided to use InfoPath instead of other techniques because we wanted a more functional form with less code buried behind it. I’m not sure that we saved on the coding effort, but I like the mix we are left with. We are trying to stay very close to the level where we can establish the action we want by “configuring” parts instead of writing code. It’s a fine-line kind of balancing act, but it works for us.

This just in, yes I know that Microsoft has put InfoPath on the short-line track to obscurity, but it will be around for a while and I feel that we risk very little by using it the way we do.

The reason I said that the right stuff is and isn’t running in SharePoint is central to our use case for having SharePoint and it is something that I think people often overlook – SharePoint runs in a browser. By building the front-end of this application in SharePoint, I can let people who are traveling submit invoices to be paid, approve payment requests and manage their budgets without having to write any web stuff. Also, since we have that Mass360 browser I talked about, I can approve payments on my iPad without a VPN connection.

The stuff that’s not running in SharePoint are those back-room accounting processes that nobody sees and everyone is content just knowing that they get done. Nothing to see here, move along.

Platform Jacking

I first heard the term Newsjacking used by David Meerman Scott. In fact he may have invented the term. That doesn’t surprise me. I have heard David speak several times, and he has been so far ahead of the curve that the future appeared to be a straight line.

I hope that’s enough homage to @dmscott for him to look the other way as I borrow his term and mangle it. I simply couldn’t think of a better way to describe what happens when a company moves in to exploit a hole in what should be another product’s / company’s domain. Think about the way Google stepped into fill the void Apple left when they decided to stop using Google Maps (in favor of their not nearly as accurate maps). Now, instead of Google being passed by, this may have evolved into a normal competition, but that’s a subject for someone else’s blog.

Microsoft, in my opinion has been jacked on at least two (maybe 3) occasions. OK, here’s the difference between me and David Meerman Scott and my blog and a blog written by an analyst – ‘my opinion’ is based on my experience and that’s all. Here are my three candidates:

MaaS360 – Back in the days when we were eagerly awaiting the first beta of SharePoint 2010, I was listening to a presentation by a Microsoft employee who suggested that one of the features of SP2010 would be a way to tunnel into SharePoint without VPN – Something Microsoft does with both Exchange and Lync via an edge Server. Those two features were a tremendous boon to our operation, and left most of our employees not even needing VPN connections on their laptops. If we had that ability for SharePoint, I could forget how to spell VPN, but we don’t. Once again, if we actually do, please explain it to me in a comment and I’ll buy you a beer if we ever meet in person.

Anyway, what I don’t think Microsoft does for my laptop, they clearly don’t do for my iPhone or my iPad – but MaaS360 does. If you’re not familiar with MaaS360, it’s a mobile device management app which allows companies to control mobile access at a very granular level. In addition, there is the MaaS360 Browser that talks to its counterpart server and provides seamless access to SharePoint from my iPhone. We are now planning to build out a collection of nice mobile pages so our employees will have access to SharePoint from their iPhone/iPads without VPN.

Harmon.ie – By far the best example of filling a void is Harmon.ie, the product that fills the chasm between Exchange and SharePoint so brilliantly that I no longer want Microsoft to build the feature into either server. Harmon.ie’s product is so cool, and so robust that I needed a term like Platform Jacking to describe it – some of our employees literally work out of Outlook and the Harmon.ie sidebar as if SharePoint doesn’t even exist. SharePoint, in these cases has simply become the invisible conduit to the even more invisible SQL Server.

I’ve written about Harmon.ie before, but a reader recently asked me to review Harmon.ie’s iPad app. OK, so we have to go back to that whole “not an analyst” thing. Giving a review sort of implies that I know something about Harmon.ie’s competitors – I don’t. Someone on my staff used to, but then we purchased Harmon.ie and we stopped caring about alternatives. Here are a couple of reasons why we still don’t care:

Harmon.ie works – You might be surprised to hear “it works” used as a differentiating statement for products, but it can be. Some products don’t work, or they don’t work as advertised. Harmon.ie works, and if you every find and area where it doesn’t, they will fix it fast.

Harmon.ie fills many holes – Harmon.ie started by filling the hole between Exchange and SharePoint and Lotus Notes and SharePoint. Then, they released Harmon.ie for the iPad and I had a way to connect my Exchange email with SharePoint on my iPad that looked and felt very similar to the way I connect these two essential products on my desktop. Now, I see that Harmon.ie has been released for the OWA client for Office 365. These guys are always one step ahead of demand.

WebEx – I recently received a new laptop at work. Somewhere during the lifespan of my old laptop, we switched to WebEx for hosting public meetings. Check out the picture at the top – That’s from my desktop, and WebEx has attached itself to my Lync client as if to remind me that Lync doesn’t work so well for public meetings. WebEx is jacking Lync right on Microsoft’s front lawn.

Helping Out for the Holidays

This is always a tough time of year to write about SharePoint. Monday was the first day of our fiscal year which means it was also the first day of the process known as year-end. We also have a lot of activity associated with the policy renewals that happen on January 1^st, so there usually isn’t a lot of time for SharePoint. Fortunately, a bunch of holidays occur in between our year-end and those renewals.

Last year, one of my coworkers decorated her office door. She did a great job, but there are a lot of doors and hers was the only pretty one. This year, she wanted to try and encourage others to join her. A few ideas bounced around a few heads, and a contest was born. The cool thing is that the winner gets to choose a charity to benefit from the proceeds of the contest. Of course, we’re going to use SharePoint to handle the contest. The process is pretty simple, but I learned a bunch of things about SharePoint that I didn’t know, and they might come in handy if you ever have a similar need. I didn’t figure any of this out; I just searched and picked one of many available answers. I’ve included the links here, in case they’re interesting to you.

Photos can be rated – We don’t deal with photos very often, in fact this might be the first time we are “dealing” with photos. Other photo libraries that we have are holding logos, pictures from business events we have held and pictures of things we want to put in a report. Not exactly stuff anyone cares to rate. We decided not to use this feature because we want a more direct way of choosing a winner and we don’t want to make people assign a value to every picture, but it’s pretty cool none the less.

There are Thumbnails – Well, of course there are thumbnails, that’s what we are looking at when we look at the standard library view, but those thumbnails aren’t directly available, or are they? Well, I found a short article from Stephen Wilson at Rackspace for accessing the thumbnails in SharePoint 2013. I tried his technique and it worked in our 2010 libraries as well. I spent a little time trying to wire up a related list that would show the thumbnail and let people make a choice (like a survey would be if SharePoint surveys worked better), but that didn’t pan out. The reason we’re doing this in SharePoint is because we have some remote workers who can’t see the actual doors. We don’t want them to have to go to the list, click on the thumbnail to see the photo and then go back to the list to vote. This needed to be simpler.

You can make workflows easier to use – One of the things people hate about workflows is that you have to do the whole right-click – select Workflows – select the workflow – start the workflow thing. Now you can make a really pretty page where this stuff all happens behind the scenes, but it’s year-end, and this is a simple contest. One way to simplify the workflow process is to add an HTML column that provides the shortcut to the workflow right in the item. I’ve used this method a number of times in other lists, but Varinder Singh wrote a nice blog entry on how to do it.

I’m going to opt for the workflow solution. People can look at the pictures, choose the one that they like and run the “Select as Winner” workflow. The workflow is pretty simple – it will add the name of the picture and their name to a list. A workflow in that list will throw out any previous entries that person made and a view will take care of the counting and sorting. Nothing fancy here, but it feels good to be able to say “yeah, we can do that in SharePoint” whenever somebody asks for a solution. Give us a few weeks, and I’ll post a picture of the winning door and the winner’s choice of charity.

ECM is an Activity not a Product

Last week the AIM New England Chapter held an event with the goal of trying to figure out how people are using SharePoint. You can read about the event, the discussion and the wisdom the expert speakers shared in the Event Experience Report, but I want to talk about a note found on page 6:

“One person described a decision to move a customer facing solution out of SharePoint because the customers were not interested in the features SharePoint has to offer. The solution has evolved into a ‘content publishing’ solution and management feels that there are better platforms than SharePoint on which to build such a solution.”

I’ll confess to being that person. Are we giving up on SharePoint? No. Is our content management program changing? Yes.

When we first began using SharePoint in 2006, we liked what we saw. While we were struggling to figure out how to best use the product in-house, someone asked if we could use SharePoint to exchange documents, information and perhaps collaborate with some of our customers and business partners. As you might expect, good little techies that we were / are, we jumped at the chance to add a second farm and build an Internet-facing SharePoint server.

We developed solutions. We formed pilot groups. We tested, tweaked, added and perfected features and we held training events. We met with our customers and we spoke with our coworkers and what we heard was that our customers don’t need SharePoint. Our customers want to share files, and share is 90% retrieve and 10% submit. Do the math, there’s nothing left for “collaborate on” or “construct a process around” or any of the other things we have been trying to get people interested in. That’s OK! We understand serving customers, and we don’t want to make customer service harder than it needs to be.

But wait a minute. If we already have SharePoint, why abandon it? SharePoint can certainly be used to share files with people over the Internet.

That’s true, but we’re not in 2006 any longer. SharePoint can be made to be a simple repository of shared documents and SharePoint can certainly handle segregating and protecting private documents while also providing access to public documents, but so can lots of other products. It is one thing to put some effort into SharePoint to create a solution that looks, feels and acts like a more expensive product. It’s quite another thing to put some effort into SharePoint to make it look, feel and act like a less expensive product. Sometimes, SharePoint just isn’t the right answer.

One of the problems with technology and the notion of businesses adopting technology, is that technology changes. One of the most important responsibilities of an IT group is to make and to keep other people aware of what those changes are and what those changes mean to the already adopted solutions. A critical element of that understanding is the fact that installed solutions are not free. We cannot look at something that was developed in and deployed on SharePoint and say “that’s done, let’s move on to something else” – systems, including the things we build in SharePoint, are never done.

SharePoint was the right platform in 2006 because it was just about the only affordable solution we had for securely sharing content over the Internet. We tried to take advantage of the platform, to offer more features and to entice people into turning file sharing into collaboration, but the demand isn’t there. I understand that, the underlying task isn’t a collaborative effort. The underlying task is a mature business process that doesn’t need to be “improved” by SharePoint or anything else. Now that there are simpler, less expensive solutions for securely sharing files over the Internet, it’s time to consider them. Guess what, they work and they work better than SharePoint.

They work better, and they are cheaper, because they are less capable and because they have been perfected toward a narrower goal. The solutions that we are looking at were born in the cloud; they don’t have to be migrated into the cloud. The solutions were born into a mobile world so they come with desktop apps and apps for every mobile operating system – good looking native apps! The people who built these solutions know what they are doing and they know what we need to do, so integration with Outlook is baked in, drag & drop integration with Windows is baked in, permissions, controls, auditing and reporting are all baked in. Yes, these are file-sharing only solutions, but when that’s all you need, that’s all you need.

We are still a SharePoint shop and this is still a SharePoint blog, but my focus has always been Enterprise Content Management. The title of this post is from a comment I made recently on a friend’s blog: ECM is not dead, but ECM is an activity, not a product. The ‘M’ in ECM is also a responsibility and it’s one that I take seriously.

Forget the User – Think About the Next User

If you know me, or if you know my history, you know that I haven’t always placed an emphasis on “user experience.” I was more concerned with just making things work. Then I met Jill Hart at iPhoneDevCon and I got religion about user experience. I took a class taught by Bob Larrivee and I realized that you can and should design ECM solutions with people in mind. I met Marc Anderson and I learned that there are tons of ways to make SharePoint user friendly without slowing down the development process. I mention these people, not so much as a way of dropping popular cool names in the opening paragraph, but to pay them homage before making a statement that they might be tempted to beat me with.

Forget about the user; make the solution work for the organization!

I can hear my friends groaning. I can hear them saying “no Dan, you can focus on the organization AND the user” and I can almost see them shaking their heads.

I’m not trying to go back to my “make it work, make it fast and then make it pretty” roots, but lately I find myself worrying that the pendulum has swung a bit too far in favor of the user. Specifically, there is a fine line between a great user experience and a solution that is built for a specific user or a specific group of users.

Today people are getting used to having the apps they want, having them now and having them on the cheap, but we can’t afford to treat them like Congress. We can’t let them have their way at the expense of the greater good. Now, in case any of my coworkers are reading my blog, I’m not talking about you, I’m talking about, you know, that other guy. But, if I were talking about you, I might ask you to step back and stop thinking about our project in terms of the way you want this solution to work. Think about the way it needs to work. If I were talking to one of our consultants, I would ask them to stay true to the fundamental best practices that they have built their business on, and remember that they are here to add value to our situation even if their recommendation is a bitter pill. (OK, I think I used enough clichés in that sentence). If I were talking to the members of my team, I would remind them that we aren’t in a popularity contest, but that we have a job to do.

SharePoint is the foundation on which we build our solution. In building that solution, we need to create a viable and sustainable structure that can support the business process going forward. If you’re tired of trying to figure out the metaphors, I’m talking about having the right libraries, the right metadata and automating the right processes to the right extent. I’m talking about taking a hard look at the content we have and working hard to organize it in a way that makes sense. Once all of that is in place, go ahead and make it pretty. I’m fine with pretty. I like pretty (who doesn’t like pretty?), I’ll build pretty things. What I won’t do, is build a solution that is pretty but makes no sense. I won’t build a solution that embeds “the way we’ve always done things” into what is supposed to be a forward looking project. I will build solutions around the right way to do things, but I won’t build them around the way you want to do things (unless those are the same things).

Caveats, clichés, parenthetical expressions, disclaimers and explanations aside, the bottom line is we all have a responsibility to do the right thing as we commit our company’s information to a repository that our successors will have no choice but to use. Let’s get this right and then let’s make it pretty.

The above blathering rant is not based on any current projects and the references to people or people-like entities are not meant to represent my current or retired coworkers. This is all based on things I’ve heard, read about, imagined or things I remember from previous jobs.