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.

A Week Off

clip_image002I took this past week off to build a combination entryway landing and walkway at our house. I figured that by the end of the week, I’d have a nice analogy between a small construction project and building a SharePoint site. Of course my construction work was delayed by Hurricane Sandy, and when our office lost power, I started thinking about the value in having certain essential content available in a Cloud-based ECM system. Fortunately, if I ever move in that direction, I have a good start courtesy of a timely article by Cheryl McKinnon on CMS Wire. Getting back to the construction analogy, I think that there are some clear common threads between building a physical structure and building something in SharePoint.

Foundation – Every construction project builds off of a good foundation. In the case of our landing, it was a series of six 10” concrete piers, each extending 42” down to get below the frost line. I could have saved myself some back-aching labor and tried to connect the structure to the roof piers that were already there and the side of the house, but that would have meant possibly compromising the piers and affecting the design (see below). We made similar decisions when building our SharePoint site. We could have handled both our internal and Internet users with the same server. That would have saved time and money, but it might have compromised security and it would have meant that trade-offs would have to be made for many internal solutions. We opted for the more expensive approach of having two farms, one internal and one Internet facing, and that has proven to be a very good solution for us.

Proper construction techniques – Although this landing isn’t supporting anything other than a few people, and perhaps a package delivered by UPS, it has to be built according to the building code. Sometimes I wish there was a building code for SharePoint, because people shouldn’t be allowed to build SharePoint badly. When we meet with people to discuss the site they want, we often propose building more than they wanted. We want them to include metadata, we want them to utilize managed metadata when it exists or build it when it would help others. We want them to think hard about whether they need a site, or a library or a folder. We ask them to think down the road to the point where their site has an abundance of content and try to imagine how future users will find what they need. We help them decide what out-of-the-box parts to use the same way the guy at Kelly-Fradet helped me decide what fasteners to use for the Trex decking. When there isn’t anything in the box that meets their needs, we help them build the part that meets their requirements – if they aren’t capable of building that part; we supply or bring in a professional.

Appropriate design elements – The early (and easy) plan to use the existing piers and anchor the landing to the house would have meant cutting into the vinyl siding for about 8’. Whenever you do that, you expose your house to the elements. Of course there are ways to guard against infiltration, but the best way is to not make that cut. When visiting my brother earlier this year, he showed me how his deck comes close to his house, but doesn’t penetrate the siding. That means that although in the course of 25 years a few deck boards rotted, the siding of his house didn’t. Not only does that make sense, it looks much better. When building a SharePoint solution, you have to think about the design while you’re building the foundation. I’ve seen many sites where, after the solution is built, people say things like “I wish it looked better” or “I wish we could look at this…” The time to make those wishes is before you start building.

Sandy cut 3 ½ work days off of my 8-day schedule. Not only did that leave me with a few long days, it meant postponing the walkway section of the project. That’s OK; we can work around that by deploying the two sections in two phases. Our work in SharePoint often follows a similar path. For example, we built a document repository, put it into production and then went back and built a management dashboard several months later. Like home improvement, SharePoint is easier to build right than it is to change later. Getting it right the first time, even if it takes longer and costs a little more is well worth the effort.

Taking the Next Step

imageIf you follow this blog, or even if you drop in from time to time, you know two things about our SharePoint implementation – we have had some success, and much work remains. Given that situation, this might not seem like the time to be more aggressive with our SharePoint goals, but I think it is. I want to build on the success we have had; I want to extend our reach into other areas of our business, while also expanding the number of ways that we can take advantage of SharePoint.

Lately, we have been working to find something in between the boring out-of-the-box look and feel of SharePoint and a totally custom solution. We want to avoid recreating, as Owen Baern said: “The Problem SharePoint Solved”, but we are trying to give our users the experience they deserve. I am also trying to save time and money by extending SharePoint into the realm previously dominated by fat-client desktop applications. During the past 10 months, we have had some good success building off the lessons we learned during a training session last year with Marc D. Anderson, but as the title suggests, it was time to move the bar. Last year, we learned a lot about working with Data View Web Parts and script, and we used that knowledge to build a couple of very cool summary analysis pages (dashboards if you prefer buzzwords). This year, we wanted to get started with Marc’s SPServices library, so we had him take us to school again.

I have seen a large number of shout-out’s and thank you’s to Marc on Twitter about SPServices, but we really hadn’t come up with a reason to use it, until a couple of months ago. Having split our Internet-facing server into several site collections, we wanted a way to intelligently share items from a master list at the root level of the farm. The list contains employee contact information, including relational items so we can assign them to the sites we insure, the committees of our Board of Directors, and the business partners we deal with. All of these assignments are made by role, so an insured knows who the underwriter is, who the engineer(s) are and who to call for technical support. We have done this in the past with a separate master list in each site collection, using views or DVWPs, but we wanted a single list, so the people who maintain the contact information didn’t have to bounce around between sites. We also wanted the list to be easy to load on each/any page, and we wanted it to look good.

Marc quickly put us on the road to success, with a simple extract of data from the master list, displayed in a Content Editor Webpart that had that familiar SharePoint look and feel. We were impressed, but then Marc put us on the highway, making the list look a little better and driving its contents dynamically from the page it was on. I dropped that link on a test page, in a different site collection, and it sprang to life with the appropriate data. Next, Marc put us on a Trans-AM course, when he used his library’s feature to return a JSON array, so that we could group the results in a way that made sense to our customers, as opposed to the way they were returned by the query. image

Some of our insureds operate multiple reactor sites and there may be numerous underwriters and/or engineers assigned to the account. In those cases, we wanted the account staff to be grouped by insured site, but we wanted the technical staff only listed once. For single unit locations, we wanted the team listed without any grouping or at least with the single group opening in an expanded state.

As Marc worked his middle-tier magic, we got the clear impression that he could put us on a Formula-1 course if we wanted to go that far – we didn’t. We want a good user experience, but we still wanted our users to know they were in SharePoint. This is the point when I am glad we teamed up with Marc. He didn’t come here with a solution in search of a problem; he didn’t walk in trying to sell us the same approach he used at his last client, or his favorite approach, in fact, he ended up trying something new. He came to teach, and he taught us how to do what we wanted to be able to do. If we ever need help building a solution, he’s the first person I would call. This time around it was a learning event, and it was a total success.

Does SharePoint Make You Happy

Earlier this week, I was lucky enough to share the stage with Jill Hart, at an AIIM New England event titled “Usability Matters”. Jill set me up, by asking me to speak first. She had the advantage of having seen my presentation and she knew that it included information about things we did wrong in addition to the things we did right. During my presentation, Jill revised her presentation to include quotes, examples and even pictures of me. Even as I introduced her, Jill was revising her presentation.

As we were preparing for the transition, I asked Jill if she wanted to use my remote control device to advance her slides. When she started speaking, she talked about how she immediately felt good once she realized that my remote was a Kensington. She had used this manufacture’s devices before, she knew it would work and, more importantly, she knew how it would work. She went on to talk about the ways that previously positive user experiences build brand loyalty with customers. She gave tons of examples, good and bad, and she helped me understand that although my wife jokes about me being a marketing sap, I am really responding to a great user experience when I reach for my Stanley FatMax tools. Then I started wondering about SharePoint.

If you are in a typical business environment, someone is bound to ask “where can I get a copy of…” and the answer, at least on occasion is going to be “that’s in SharePoint.” The next time that happens, watch the person’s facial expression. Are they as happy to know that the stuff they need is in SharePoint as Jill was to know that the remote was a Kensington? Are they as excited as I was the day I saw a Stanley FatMax Utility Knife hanging on the rack at Home Depot? If they aren’t then you haven’t done your job. If their expression is similar to that of someone who just realized that they are missing a key ingredient for a recipe, you could be in trouble. If their expression matches the one when they are told “you have to go to DMV to process that transaction” you might want to think about starting over.

I have to be honest, I am trying to stay out of trouble with SharePoint user experience; ours hasn’t always been good enough. The biggest problem has always been navigation. We would have that little discussion quoted above, and, along with the recipe face (see above), the person would say something like “oh, I can never find anything out there” in a way that would equate SharePoint with the area of space beyond the asteroid belt. When we upgraded to SharePoint 2010, we consolidated a lot of SharePoint content to make it easier to find. In some cases, we eliminated sites completely because the only thing of value in the site was a single document library. Why make people step around an empty task list, an empty list of links, an empty calendar and that picture of those freakishly happy people that adorns the Team Site template – all to get at one library. A very simple example of something we added was a link on most pages (we’re not done yet) back to the main page. Breadcrumbs are great, but they are still two clicks instead of one, and many people don’t realize that the little folder icon contains the breadcrumbs in SP 2010.

In my presentation, I also mentioned that we are working to decrease the degrees of separation between task and content. We bought SharePoint as an ECM solution, to manage our digital content, but there’s a problem with that approach. In most cases, digital content is the end of the line; the report, the PowerPoint file, the PDF, all represent end products of a sometimes lengthy process. We are working now to insert SharePoint into the process itself. We are trying to find ways to accommodate the precursors to those results, the links, data, reference material and images that went into the report or presentation. Hopefully, by bringing people into SharePoint earlier in their process, they will get more comfortable. Besides, someone is just as likely to want to find the image they used in a report last year as they are to find the actual report.

For the ROI fans in your organization, remind them that we will never get our money’s worth out of SharePoint if people only use it when they have to. If we want to move the bar on SharePoint adoption, we need to focus on user experience. I wonder if Stanley makes a FatMax web part.

Absorbing Frustration

clip_image002The tag line includes “…we find frustrating” for a reason. Every now and then, SharePoint presents you with a situation that just makes you scratch your head. Here’s the most recent one for me: There is a setting on the People and Groups column where you can specify that multiple people or groups are allowed. However, if you are filtering on a people and groups column, you can’t use the “contains” operator. I can imagine that since “contains” invokes a string function, it would be more work to implement it on people, and I can further imagine a developer saying: “if they want to filter on multiple people, they can use a group.” However, a group doesn’t work for us.

We have an Internet-facing site for our business partners, and we also include a section for employees who may need to access company content when they are away from a machine that can establish a VPN connection. This site is on a separate farm, and a separate domain. Our internal domain users can authenticate via an Active Directory Trust, so, in theory they only have to remember one set of credentials. The problem is, they have to include the domain name, so they log in like “co-domain\jsmith” which is a little annoying, particularly if you’re using an iPad. If they don’t mind maintaining two UserIDs, they can use credentials from the outside domain, in which case they could log in as “jsmith”. As you can imagine, this is easier sometimes, but not always. If I am on my domain laptop, it’s easier to be “inside me.” Normally, it doesn’t matter who you are, because we establish permissions for both. Of course, since I said this was frustrating, you realize I’m not talking about a normal situation.

In trying to support a company Wellness Program, we are building a site where employees get points for doing healthy things. They can redeem these points for awards. In addition, the program administrator can redeem their points for them. This combination of activity means that the Points and Redemptions list has items “Created by” an internal domain user, an external domain user and the administrator. OK, we aren’t filtering on that when we want to show the employee their own point balance. Our first attempt at setting up a filter mechanism was to put both userIDs in a People column of an Employee list and filter on “Domain Names contains [Me]” – no can do. To get around this, we created two columns in the Employee list in addition to a name column (“John Smith”), we have a trusted ID “co-domain\jsmith” and an outside domain column “jsmith”. We pick using the name, and a workflow populates the domain versions wherever they might be needed later. When we want to filter, we select: outside domain user = [Me] OR inside user = [Me].

I would be willing to bet that some of you have already thought of a better way to solve my problem than the brute force approach I took. If you have, please add a comment. However, if you follow this blog, you know that I don’t try to teach people how to do things here; this blog is more about why we do things. Why did I (have the person actually building the site) go to all this trouble? So we could absorb the frustration at this level.

We could have simply said “when you visit the Wellness site to enter points, you must use your co-domain credentials;” in fact, I’ve done things like that before – I know better now. We have to build this site once; people have to use it every day. I can’t begin to count the times I’ve have had to remind myself, and other programmers of that (1:n) ratio over the course of my career. No system, platform, device or language is perfect; automated systems will always include pain points and frustration. Good architects, designers and developers remove these before deploying a solution; they absorb the pain and frustration into the solution. When we deploy the Wellness site, it won’t be pretty under the hood, it will include this somewhat hard-coded kludge of name variants, but it will work like the employees expect. No matter how they login, they will see their points.

Great Ideas Come From Customers

clip_image002We spend a lot of time and considerable effort managing an Internet-facing server for our members, customers and business partners. Usually, this is a “build it and they will come” type effort. We build out what we think is an effective site, we track a certain amount of usage that tells us it’s working, we pat ourselves on the back and move onto the next task. In the course of normal business, we don’t actually have contact with these important users. Recently, I attended our company policyholder meeting, and I got to spend some time in one-on-one meetings with a few of our customers. It’s one thing to send someone their user credentials and receive a “Thanks, this looks good…” email. It’s a whole ‘nother thing to sit next to that person and walk them through their site.

I always get a little nervous before these meetings, and I always come away realizing that the nervousness was unnecessary. We are providing a service to our customers, and they appreciate it. If they have problems, suggestions or questions, they really appreciate the fact that we are willing to solve, consider or answer them. We had a few of each to deal with this time, and I learned a lot in the process.

One of the things that I learned is how important it is to consider SharePoint from the point of view of the user. We look at this site as a multi-use portal; it serves our members, our policyholders, many of our important business partners and our employees. One of the things we did when we upgraded to SP 2010 was to create separate content databases along these various groups. That we had to do this is a good thing, it means people are using the site. Of course, it also means that the URLs changed. Navigation from the top level site didn’t change, and the main URL didn’t change, but these people want to start at a place that makes sense to them; they don’t want to enter the front door and then walk down to “Men’s Wear.” Fortunately, we anticipated this problem, and we secured a domain name that will link them to the front page of the policyholder site – forever!

One of the things that we didn’t anticipate is how our site can be both important and trivial, and how that dichotomy influences what our users want. Our site is important, because it is a source of information that our policyholders need. Our site is trivial, because they have a thousand other things to keep track of. They rely on our content always being up to date; they want to know when our content changes but they don’t want dealing with that content or those changes to be a big drill. They want us to improve notification.

We thought that notification was easy – users can set up alerts and get notified of everything that changes, and they can have as many users as they like. Well, some of their users don’t remember to set up alerts, and they want some people to be notified without having them be credentialed users on the site. They want to have a contact list that can include users and non-users, and they want a “more descriptive email notification” to go out when content changes, not simply the SharePoint alert. I know that we can handle that request for one policyholder sub-site, and I think we can handle it for all of them with a roll-up list, but suffice it to say, we have some work ahead of us.

Another challenge that lies ahead of us is training. One of the changes we made during the upgrade process was to eliminate folders in the various document libraries. Face-to-face, I was able to show the benefit of having all the content in one place, and being able to sort and filter on the metadata. Apparently, “face-to-face” was the important part of that sentence. I was asked if I could provide remote video training. The answer is “yes I can,” but now that task is on my plate; I don’t think anyone from my awesome staff is going to volunteer to be the trainer. At least this will give us a chance to put Lync to the test.

I am famous for looking for the bright side to every situation (and there always is a bright side). When I look at this situation, I think about how lucky I am to be able to meet with these folks and get their honest feedback. Of course great food, open bars and a hike through a San Diego canyon helped set the stage for a comfortable exchange, but the important thing is that the dialog will help us turn a good site into an awesome site.