Happiness is…

imageRealizing that the thing you need your coworkers to do in order for your SharePoint solution to work, is something they already like doing.

Yeah, that was too long for a title, but that’s how I feel right now. It’s as if my doctor had told me that “in order to remain healthy, you need to eat more Heath Bar Klondikes.” In addition, my new found happiness reveals one of SharePoint’s often overlooked strengths. Yes, if you want to, go get a Klondike before reading; it’s ok.

The project that I’ll be working on while my coworker and friends are in Vegas is one where we hope to link several aspects of our engineering process. To do this, we needed to refine an identifying number that has been in use forever. To really achieve that value we are looking for, we need a way to make it seem like this new way is the way we’ve always done things. The really cool thing is that SharePoint can make this all possible.

I’ve talked about bits and pieces of the neighborhood in which I’m working before, loss control inspection reports, recommendations and composite views of data. We have a solution that lets us track and support the development of a loss control inspection report. Ultimately, that process ends with the final report being stored as a PDF, in a records library – locked away forever. However, the process leaves the Word document that created the PDF, behind for review. Keep that in mind.

We also have a solution that tracks the recommendations our engineers make in those reports. These ‘recs’ have a long and complicated life. They get written. They get reviewed. Customers comment on them, engineering peers comment on them and once or twice a year, they get ranked:

  • How important are they?
  • How are they being addressed?
  • Where are they in that life-cycle?

We built a series of custom lists to aid in this process. We also built a couple of composite pages, aided by some data view web parts to assist in that review. Still, something is missing.

What’s missing is the link between the reports in which the recs originated and the recs and the rec-review process. My job is to establish those links.

This is where ECM projects often run into trouble. We have hundreds of reports. We have hundreds of recommendations. Most of the recommendations are ‘closed’ but they still have value. A lot of information is coded into those custom lists, but the real value, the mother-load of information, is in the original reports. The trouble is that this isn’t a one-and-done process.

The recs can appear in many reports over time and any single report can refer to multiple recommendations. It takes time to review, reread, search and add metadata to those reports in order to link them to the lists…or does it?

Well, it seems that it will take some time, but not much. It also appears that going forward we can keep the reports and the recs in sync, with little or no effort at all.

The key to my happy day lies in the fact that SharePoint, with the aid of some workflow add-on products, can read those reports. Further, it turns out that the way our engineers like to write those reports, their “style,” the style they’ve been using forever, lends itself to being picked apart by Regular Expressions.

The reports already have metadata that tell us what policy they refer to. The recommendations have an ID number that tell us what facility they refer to. Today, I built another SharePoint custom list that links those facility ID numbers and our policy numbers. Now it looks like I’ll be able to have a workflow read the reports, pick out the recommendations and automatically maintain the activity in the recommendation lists. If this is successful, once an engineer finalizes a report, a SharePoint workflow will create a stub new recommendation or a stub recommendation update item, and then create a “please complete this item” task.

I’m talking in the future because I’ve only completed the proof-of-concept steps. I can read the reports. I can find the recommendations. I can build a new composite identifier and I can stick it in every custom list where it’s required. I usually wait until I have a solution to write about it, but this was so much fun, I needed to share it. When I finish this project, I’ll let you know how it works, in this blog and at AIIM14. If I fail or partially fail, I’ll write about that, too.

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.

Shared, Public and Private

imageContinuing with the theme of “what may seem like an oversight might actually be a good thing,” our project brought us to the finer nuances of the SharePoint calendar this week. As I mentioned last week, we discovered that a calendar was a good way to represent the access paths to the content we are storing. This is because much of the content is associated with an event. Using the calendar not only lets us tag content with the event it belongs to, but also lets us answer questions like “what did we prepare for these guys last year?” The calendar works, but as is often the case with SharePoint, some people want more than they should have. In our case, the primary users were requesting a level of calendar integration with Exchange that we either couldn’t or didn’t want to provide. Note: I added the two options because it seems that if you need to do something that SharePoint doesn’t support out-of-the-box, there’s always a way to get it done. That’s usually a good thing, but not this time.

Calendars were perhaps the first collaboration communication mechanism. I’m not just talking about SharePoint; we have had public, community, team, company and project calendars since farmers first began planting crops based on the appearance of the night sky. While you might think that with today’s modern capabilities, we could all just have one calendar; that would be a disaster. In fact, it’s not even clear when we want to switch between the three types of calendars implied by the title.

Shared Calendars – These are a great boon to collaboration. People on teams can easily tell when they can and can’t schedule meetings, and they can build around other information. For example, we have an employee who normally telecommutes from Chicago. Seeing that he is in CT for a meeting helps me to schedule things that would benefit from an in-person meeting. I don’t think SharePoint is a good place for shared calendars. Although I’m sure there are ways to make the sharing work well, calendar sharing is a transactional process and it works better in Outlook.

Public Calendars – This is what we are building into our latest SharePoint solution, and it’s a perfect use of SharePoint. Public calendars tell the world when things are going to occur, and lots more. Ours is also letting people know who from our company is going to be attending, who is sponsoring the event, and it will have links to all the content related to the event. In the past, we have used them to store agendas and provide links to the supporting material for each topic. The site we are working on is a collection of document libraries, and the calendar is like the calendar on the bulletin board of your public library. It makes it easy for people to see what is going on in this area, without having to check multiple shared calendars.

Private Calendars – These calendars, as well as the private events people put on shared calendars should be, as the name suggests, private. I don’t need to know when someone’s colonoscopy is scheduled, the fact that they’re out of the office is good enough for me. I had my Outlook calendar published into my MySite under SharePoint 2007, but that connection lasted about a week. Outlook is much easier to connect to than SharePoint, and I can see my Outlook calendar anytime, anyplace and from any device that I can see SharePoint from. I don’t know a technical way to prevent it, but there should be a penalty for putting personal items in a SharePoint public calendar.

Those may all seem like obvious conclusions, but we have had requests to accommodate as well as attempts and successful violations of all the above. People, it seems, need to be made aware of the purpose of each calendar that they encounter. Here’s my standing guideline for SharePoint calendars.

Every item on this calendar relates to the content stored on this site!

Once again, as Steve Weissman loves to say: “it’s not technology, it’s psychology

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.