Episode II

imageShortly 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.

Make SharePoint Simple

imageToward the end of 2012, I read several messages on Twitter, a few blog entries and even a couple of supportive eNews articles that were talking about how the year had been a turning point for Microsoft. Some were factual, some analytical and at least one proclaimed Microsoft to now be “cool” again. My contribution was to ask the question: “will 2013 be the beginning of the end for SharePoint?” Why so glum? Well, you would have to read that article, but I have a suggestion that would help prevent my question from being answered in the affirmative – make SharePoint simple!

During the course of 2012, I had to work with six different groups outside of the company that I work for. Four of these groups were comprised of business people collaborating, two for short-duration projects and two for the long haul. The others were the two groups of students I mentored at a state university during their senior MIS class. Despite my offering to create a SharePoint for some of those groups, all six chose Box or DropBox for collaboration and for long-term document storage. Not everyone offered a reason, but those who did said that “SharePoint is too complicated.”

Last week, I had an experience with SharePoint that caused me to feel the same way. I was updating our Annual Report, a process that I have managed (and blogged about) on SharePoint for years. This year, it went off the rails. I would select the menu option to “Edit in Microsoft Word,” make my changes and then be slowly driven to frustration when I was unable to check the document back in. If I opted to use my local drafts folder, I was told that “the document is checked out on a different computer.” If I chose not to use the local drafts folder, I was told that the document was checked out to Dan – as if I were someone else. The site where I wasn’t able to work is on our Internet-facing SharePoint server, where it has been for 6 years, and with which our internal domain is trusted. I was able to upload new documents, new versions of existing documents and I was able to check-out, open, edit, save and check-back-in a PDF file, using Acrobat Professional. I could email these documents to myself, and use Harmon.ie to save and check the documents into the server from Outlook. I could even open a document on my iPad with Harmon.ie’s app, edit it in Office HD2, replace it and check it back in – the only way I could not edit and replace the Word document was from within Microsoft Word!

The cause(s) of the problem remain elusive; the work-around was to check the document back in from Word’s File menu, without clicking Save first. I searched the Web on a variety of terms, including “Word cannot save document to SharePoint” (which returned over 2,000,000 results), but I failed to find a definitive solution. Suggestions included the usual suspects, like permissions, which I knew was not the problem and services that either were or weren’t running on either my laptop or the server. I tried all of the suggestions that looked viable, but none solved the problem. The leading contenders for reasonable explanation were a series of responses that point out the difference between “check-out” and “lock”, and attempt to explain the way that Office interacts with SharePoint. The most bizarre was one which alleges that check-in can be affected by where your cursor is within a Word document – I’m serious, you can read that here. It’s ironic that SharePoint would probably be off the hook if it wasn’t for the guilt-by-association with Office.

This experience didn’t make me feel like one of the cool kids. I felt like the geek who can comprehend the nuances of a strange work-around, even though it makes no sense. I’ll take a minute to remind you that this is a process that worked before. I am not sure whether it was the introduction of Windows 7, IE-9 or the various Microsoft upgrades that have been applied client-side and on the server since I last worked off this site. Perhaps, as one blog suggested, the culprit is one or more corrupt cookies on my laptop. I don’t care; like the other people trying to use SharePoint, I just know that it used to work, but it doesn’t work today. When basic things stop working and when making them work again takes numerous steps, configuration changes or different versions of software, we lose the battle for simplicity, and by the way, simplicity is what people really want.

Is This Right

clip_image002Last week, I was talking about accuracy. This week, I learned that there is something more important than accuracy – confidence. We have been working on the design of a SharePoint solution that is both simple and complicated at the same time. Of course, we are concerned about accuracy, but the people using our system will have to feel confident that they have selected the information that they need. This isn’t a challenging SharePoint problem; this is a design issue, a usability issue and ultimately an adoption issue.

Our project involves a contact list. That’s simple, but it’s really about 10 contact lists, and since they need to be exposed on both an internal and an Internet-facing server, it’s really 20 contact lists. The “master” list is a group of people who serve on a variety of committees, and that’s the only list we want to maintain. The people come and go and the committee membership changes from year-to-year. We need to know who is on each committee today, we need to know who was on each committee 2, 3, 5 and perhaps 10 years ago, and we need to know this from multiple angles. For example, I might simply want to be able to contact the members of Committee A. On the other hand, if I’m about to meet one of the people on the list, I might want to know every committee he or she serves on. In yet another scenario, if a person is retiring, I might want to know every committee the person ever served on. We’ve cracked the list design issues, and with the help of HarePoint Workflow Extensions, we’ve cracked how to keep the lists in sync on the Internet-facing server. OK, so what is this confidence issue?

Let’s think about those scenarios again. In the first one, I want to see the names of the people who are currently serving on Committee A. Obviously, I could simply filter the list on a few columns to distill the contents down to right group. That would work, but while most people know how to do this, they don’t want to have to do it every time; that’s what views are for. Views, now this is where we start to get into trouble with usability.

Views are a fantastic feature within SharePoint, but neither lists nor views scale very well. That’s not to say that you can’t put a ton of items in a list, or create a bunch of views, but sooner than later the results are untrustworthy. Once you get a couple of pages of items in a list, you have to resort to sorting or filtering to make it useful. Similarly, once you have 15 or 20 views on a list, the selection is equally unmanageable; in fact, a large selection of views might even be worse than a large collection of items. When I am setting sort and filter parameters, I know what I am doing; the trouble is that I have to be able to imagine the results as I proceed. When I choose a view, I am relying on someone’s ability to name a list intelligently. If I make the user figure out how to get the information they want, I put the burden of accuracy on them and it becomes a confidence issue.

There’s a very fine line between wanting my users to understand SharePoint and forcing them into a situation where they are uncomfortable. When they get to that point, they are going to ask someone else (maybe me) to get them the information they need, and at that point SharePoint and I have failed.

We have to find a way to tame a large list that can be rendered in a large number of ways. I can’t just substitute a bunch of input fields for a search or data view web part, that’s really no different than asking them to configure the raw list. I need to give them links and simple binary selections, coupled with a standard output format so they remain confident that they are getting what they want. Links like “Committee A Members” with a choice for “Current members only” or “Most recent five years” or “2000 – Present”. The output should be simple: Contact name (with a link to details), his or her role on the committee and the company they work for. I would argue that this kind of solution is the poster child for “perfect is the enemy of good enough” – making this process more elaborate, or the making the results fancier will only erode the confidence of the average user.

The simplest contact list that we have ever prepared, is rendered from our annual Policyholder Meeting survey, it’s a dirt-simple list: “Who’s Golfing on Thursday”, and it’s an absolute favorite among my coworkers.

Too Simple

imageI recently ran into a problem trying to replace the chain on my chainsaw. There were really two problems. First, there are almost no chains to be had in the state of CT after Storm Alfred dropped a few gazillion tree limbs on fences, roads and power lines. Second, Husqvarna changed the style of chain that my chainsaw uses without changing the model number of the saw. I purchased what the guide in the store indicated was the correct chain, only to have it not contour to the tip of the cutting bar. Standing in Home Depot, I started browsing through websites looking for tooth design, chain width, pitch, etc. when it finally occurred to me that if I simply bought a replacement bar and chain kit, my problem would be rendered mute. In addition, I would have Oregon’s model number for the replacement chain in the future.

The fact that I was heading down the more complicated path at first, is no surprise to me; sometimes I skip right past the simple solution because I’m looking for something elegant. Give me a minute; I can spin that last statement into something that sounds more noble than idiotic. I’m not sure if it’s the developer in me or the fact that I like to make my job interesting, but I will often start out pursuing a solution that could probably be considered overkill. In spite of that, we have had three bits of success lately with very simple solutions. Note that there isn’t anything remarkable about these solutions, other than, perhaps, the fact that I ignored or forgot about using them at first.

$9 Answer – When we upgraded our Internet-facing server from SP 2007 to 2010, we reorganized our content to make installation, backup and restoration easier. An unfortunate side-effect of this effort was that the URLs changed for the sub-sites. Since the main server home page is just the front door to services being provided to our members, policyholders, employees and a wide variety of vendors, nobody ever really starts there. They go there one time, click the link that applies to them and then they bookmark the page they land on. We started thinking of all the ways we could make those old URLs work, when we realized that we could simply buy a domain name for each sub-site. Now, no matter what we do with their content, even if we take it out of SharePoint, they know how to get to it.

A Library is as Good as a Site – OK, sometimes a library is as good as a site. We had a policyholder contact us looking for help uploading a bunch of large files. As I’ve written before, our first choice is to direct them to the site we have set up for their company on our server. In this case, the company doesn’t have a site yet. Our first thought was that we had two choices: 1) we could make them wait a bit while we built a site for their company, or 2) we could send them through the generic “drop box” library that we have. Then we remembered that libraries in SharePoint are permission-trimmed content. We didn’t have to build them a site (yet), we simply created a library on the main page of our Policyholder site that only they have access to. That way, they end up heading to the place we want them to get used to, and they have immediate access to all the common documents available to policyholders.

SharePoint Libraries are Email Enabled – As you’re probably aware, this isn’t a new feature, but it is one that I tend to forget about. In a meeting last week, a group of us realized that in order to resolve a problem we were having with a vendor, it would be necessary to review the emails we have received from this vendor. Most people admitted to routinely deleting these messages but since I file them in a folder, I offered to move them into SharePoint. Later in the day, when I went to create the library to move them to, I realized that I had already done that. In fact, the message distribution rules we established in Exchange, already route these messages to the library via the library’s email address. Note: for those of you that are about to chastise me for not having documented this composite solution, I did, I just forgot to look at the documentation.

Albert Einstein supposedly said “Everything should be made as simple as possible, but no simpler.” In reading up on that, it is not clear to me that he actually said that, or that he meant “everything” in the way we mean everything when we refer to SharePoint. Still, he was Einstein, so…