Time is Money – Or Something

imageOne day back in the mid-80s, I was sitting at my desk at one of the Big 8 (or was it 6) audit/consulting firms when my boss walked in. He looked at my desk and saw that I was drawing a diagram (we didn’t have much in the way of graphics capabilities in those days). He asked me what it was. I explained that I thought a diagram would help our client (Bob) understand the work we were doing.

“How long have you been working on that?”

“About an hour”

“When will you be done?”

“Maybe 15 minutes”

“OK, when you’re done, fax it to Bob and ask him for $280”

“Whaaaat?

“That’s how much it cost him for you to draw that. That’s assuming that what I’m looking at is the presentation copy. Or were you going to ask the people in the report department to make that pretty? In that case, ask Bob for more money”

The picture vs. the thousand words thing wasn’t going to work. My diagram was worth 50 or 60 words at best. My boss was adamant that we spend our client’s money as if it were our own. I’ve never forgotten that lesson. I’ve shared that story with almost everyone who has ever worked for me. The wisdom in that story is one of several pillars supporting the notion that “just because you can do something, doesn’t mean that you should do something.”

Since we decided to use SharePoint for content management in 2006, our goal had always been to expand SharePoint into the other areas where we could “make it work.” Our logic was simple – the more people used SharePoint, the more familiar they would be with its features. It was a good theory but expanding SharePoint requires effort if you want to maintain a quality user experience

Last year we decided to abandon our dreams of extending imageSharePoint via the Internet to work with our various business partners. We decided to reel our expectations for SharePoint back into the services that it provides out-of-the-box pretty – back into the SharePoint comfort zone. One of the things that SharePoint doesn’t do well is surveys, and although we have experience making the results of a SharePoint survey look good, a process that takes many hours, we don’t have the ability to make the survey itself look good…can you say WuFoo?

WuFoo gave us the opposite challenge that SharePoint does. We get a nice customer experience out of the box, but we don’t have the flexibility of wiring up some pretty Data View Web Parts to digest the results.

Here are a few things we were able to easily do with WuFoo that we couldn’t ever figure out with SharePoint:

  • Insert text comments into the survey to explain the upcoming questions
  • Add instructions to help people understand how to answer the questions (without making the question 10 miles long).
  • Make the survey pretty
  • Change the default text when it didn’t make sense
  • Exit the survey without completing required fields based on certain answers (without branching)

We had looked at online surveys before, but the price point that we needed to buy at, in order to get the features we needed, was too high. Also, there were a couple of features that we could make work in SharePoint that didn’t work with the online surveys. Fortunately, products evolve and WuFoo now offers all the features we need at a price that we would be silly to ignore.

By using WuFoo, we can give our customers a great user experience, and the woman in our office who is building the survey has figured out how to configure the web-based reports to give us all the information we need to manage the event. And, they look pretty good. Our coworker who is in charge of the event has already said that he thinks this year’s survey is the best that he has seen. You see, he’s the one who has to deal with the customers who fill out the survey.

WuFoo isn’t free. Well, it can be free, but the free version won’t do all the things we need. But, an employee’s time isn’t free either. When you do the math that my old boss taught me, WuFoo is, as he used to say, “A bargain at twice the price.

Lightning Conductor Web Part

New Haven RailroadA while back, I suggested that I wasn’t worried about the changes that Microsoft was making / has made to SharePoint because the market would come to our rescue. The pronoun here is referring to those of us who had gotten used to wiring up Data View Web Parts and customizing pages in SharePoint Designer. The collective changes in SharePoint 2013 will make building those solutions a different exercise and one that brings us closer to programming than my staff wants to be. I’ll save until later the philosophical debate(s) around whether script-coding is programming; whether programming is evil and to be avoided or a necessary skill that should be required, and whether JavaScript is the official language of the new world order and we should all just suck-it-up. Today, I want to point out one vendor that has stepped into the role I outlined last October.

We have been previewing the Lightning Conductor Web Part from Lightning Tools and I am happy to report that it looks like it can easily help us provide one of the solutions that we used to turn to XSL to provide – the custom view of data from places our users don’t want to go. OK, it’s not that they don’t want to go there; they just don’t want to be on the road forever. The people using SharePoint in our company don’t really want to use SharePoint to conduct business; they want SharePoint to work for them. We made a promise to those people years ago when we (Information Services) chose SharePoint; we said that we would invest time and budget into making SharePoint easy to use. I take that promise very seriously. If I start telling people “you have to learn a lot more about SharePoint in order to have it help you with that task…” I’m practicing bait and switch. This new tool is pretty cool, and it appears to be a really good use of my budget. So, what does this tool actually do? Well, I can’t describe this any better than the Lightning Tools website, but here’s what we like about it:

Using the tool, we can quickly put a web part on a page that aggregates content from multiple libraries on the site, from within the site collection, from within multiple site collections or from across our entire farm. We can filter this content, we can sort this content and we can decide what columns to include. We can do all of this from within the browser, without opening SharePoint Designer and without even leaving the page that we want to put the web part on. Configuration is fast, and the results are immediate. And, if we screw it up, we can simply delete the part without having messed up the entire page.

For example, we will be able to gather policies, underwriting correspondence, inspection reports, engineering metrics, previous claims and presentations given to any one of our customers, on any page on our farm. These documents (someday will) all reside in the sites where they belong, but I (will be able to) pull them together – without waiting for a search to complete – wherever they might be useful. Parenthetical expressions aside, we already have content in multiple locations that needs to be aggregated to be more useful.

Of course there are a lot of other ways to accomplish these tasks. I have watched lots of people demonstrate various techniques at seminars and, inspired by those demos, I urged my team to learn these techniques. These days, I want my team building solutions. I want them to show off their content and information management prowess, not their syntax skills. The people on my team can imagine great solutions by merging their understanding of SharePoint, content management and the unique attributes of our crazy little business. If I can buy tools like this to let them quickly build what they can imagine, it seems like a good move.

I think we are moving forward with this purchase We just purchased this product! We had a few questions during our evaluation, and they were quickly answered by the responsive service group at Lightning Tools.

Let me dwell on that last thought for a second. I love it when a vendor lets you work with the actual technical support group during a sales evaluation. Not only did we get our answers, we were able to evaluate the support as well. BTW, the support is as good as the product.

The Lightning Conductor looks like a nice fit for us, but I’ll fill you in on our actual experience after we put it to use. Maybe I’ll get one of my team members to write about and I’ll get a week off – this is sounding better and better.

Personalized to the Point of Failure

imageIn 1997 I wrote a bit of code that has finally come back to haunt me. The idea was sound, the implementation was flawed but I didn’t know it at the time. I wanted a way to include some rudimentary (by today’s standards) personalization into our desktop systems. I crafted a Parent Class that contained a System Setup utility and a startup routine to access and apply preferences. I stored things like the fonts and font sizes, the position and size of the main window and certain basic application parameters. This was at a time when most Windows applications contained UI elements that didn’t even scale when you stretched the window, so I was quite happy with the outcome. My mistake? – following Microsoft’s advice to abandon the trusted .ini file in favor of storing this stuff in the Registry. I wrote a Registry interface before a good commercial class library was available for Smalltalk, and that bit of code has reached its breaking point.

It seems that errors with personalization are moving like ripples on a lake, because while I am rewriting a 15-yr old process, we are facing the other side of the personalization dilemma, when to say “no.” We’ve been asked to reduce the detail in a dashboard view in SharePoint. Saying “no” isn’t something I enjoy, but we do have to know where to draw the line between a personal view and the minimal amount of information a user should receive. This is a tricky endeavor. I used to work for a man who viewed the world as a series of binary equations. Status to him was “done or not done?” He would prefer a dashboard with a simple red/green indicator (no yellow required), but that isn’t always what people need to see. “Not done” inevitably leads to questions, and good dashboards should answer the most common questions as well as report the status. This is especially true in SharePoint, where finding those answers may not be easy. Our dashboard highlights reports that are nearly overdue as well as reports that are actually overdue. Seeing that 7 reports are approaching their delivery deadline will absolutely cause you to ask “which reports?” but finding them takes a bit of sleuth work. So, if someone asks me to remove the actionable list of those reports from the dashboard, I hesitate; I want to talk to them and walk them through the scenario(s) that might unfold and test their resolve on that request.

Another oddball request we received this week was actually a multi-part mind numbing exercise. We have a list of contacts, which are organized into three categories. To avoid adding enough detail to identify the suspects, I’ll just call them Type A, B and C contacts. We had to produce a series of reports that include A’s and occasionally B’s but never C’s. That was pretty easy. Now we have a request to include a single B-type contact on a report that doesn’t contain B’s. In addition, we need to include a contact that is neither an A, nor a B nor a C on a report that only includes A’s.

These are the kind of problems that make you question your design effort, not to mention your chosen profession, but a bad design wasn’t the cause of our problem. The root cause in this case is the nature of this list – contacts are people and people aren’t as easy to manage and categorize as things. Rather than try to manage our way through this issue, we opted for a few technical tweaks that provide the necessary capabilities while stopping short of hard-coding individual reports.

I hope that you can see from my opening story that I am a fan of personalization; however, I do think there are practical limits that should be considered:

1 – There should not be an ability to eliminate information that is widely considered to be essential to the understanding of the content.

2 – Personalization should not require arduous coding. This is another way of saying that personalization should be intuitive and available to all visitors to a site. When we start trying to make micro-adjustments to accommodate specific individuals, it’s time to push back.

3 – Personalization should not interfere with knowledge transfer. This might be a special case of the first item in the list, but it’s worth considering separately. When we look at what information is essential to the viewer, we have to consider what an experienced user does with that information as opposed to what the new guy might do with it. It’s fair to say that not all people know what information they might need under certain situations.

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.