Reveal Codes – A Different Kind of Dashboard

clip_image002A few weeks ago, I was one of the presenters at AIIM New England’s event “Usability Matters.” I included a demonstration during my presentation and I felt compelled to point out that the default view of a particular library was the one requested by the user. That view extends several miles beyond the right border of the browser, and I can’t figure out why anyone would want to look at it. After the event was over, several people told me that their users also seem to prefer the comprehensive unending view to any of the custom views they have created. I put all of this out of my mind until I read about Bill Gates testifying in an antitrust case brought by Novell (who owned Word Perfect) where he is quoted as saying “Word won because it was the better program.” Thank you Bill, I’ve been waiting 13 years for someone to say that. You see, 13 years after switching to Microsoft Office, some of my users still complain that they miss Word Perfect, and they especially miss Reveal Codes mode.

Of course, Bill Gates saying Word is better won’t convince my Reveal-Codes-loving users that Word was ever any match for Word Perfect. I still wonder why people wanted to see all the details behind the results, especially when those details were practically indecipherable; Reveal Codes was like reading a website in the View Source window. Reveal Codes was only useful to me to see why my document didn’t look right, more like Reveal Errors mode. The same is true with the All Items view in SharePoint, the only time it’s useful on a large list is when something is wrong with one item that keeps it off a useful list. Unlike Word Perfect, where the rendered document was on display above the codes, SharePoint offers no real insight into the things we’ve done wrong – we have to build that ourselves.

Our recent experience building dashboards and analysis pages with Data View Web Parts has pointed out their usefulness in highlighting errors, although that was never our intent. The first error we encountered was on the analysis pages for our Policyholder Meeting. The DVWP summary page said that 90 people were coming to Wednesday’s dinner, but the view of dinner guests included 92 names. The reason for the discrepancy was that two people had indicated that their spouse was attending dinner, but didn’t check their own box. I only noticed this because I was testing the accuracy of the DVWP, but it pointed out a problem with our survey, albeit an odd one. As we have been building a dashboard for our engineering inspection reports, we are finding similar odd results. There have been a number of times that we wire up a Data View only to find ourselves saying “that can’t be right…” Subsequent investigations invariably show that someone made a bad choice. Clearly these aren’t the statistics we were hoping to show, but I realize that they are important, and that we won’t find them any other way – we are already near the point where a list of all reports is overwhelming.

Since SharePoint doesn’t give us an abundance of error-checking options, it’s incumbent upon us to design views or widgets that tell us when something is wrong. We have found that pairing a simple indicator, say a count of items matching a condition, with a view of those items works very well. An example is a DVWP that shows Inspections by engineer. The part includes the number of inspections and the number of reports completed. One engineer popped off the list immediately by having completed 10 inspections but only 5 reports. A view sorted by engineer and showing all the gory details highlighted the problem inspections. One was an inspection report that was uploaded early in the life of this tracking system; the engineer had so many issues that he started over, but he never deleted his first attempt. A second error was caused when the engineer, in preparation for sharing the Word document with his customer, removed all the metadata before saving the document one final time. Since Word manages SharePoint metadata, this action put our list in a state of great discord.

We have been focusing a lot lately on ways to improve SharePoint adoption. I am discovering that adoption brings with it a new set of demands – if people are using SharePoint as a business tool, we have to ensure the quality of the information stored there. The analysis techniques we are using to build management dashboards are also helping us find documents and list items that need our attention. Maybe, instead of just highlighting any odd looking results, I’ll add a link that says “Reveal Codes” – that just might make everybody happy.

Let’s Get This Right

clip_image002The picture on the right is a collection of hand tools that I recently used to put a beveled edge on some 10’ boxes that were built to cover a pair of structural beams. Working with these tools provided feedback regarding the nature of the wood, and helped me avoid tearing out big chunks. This is a trick I learned from an old woodworker about 25 years ago. Coaxing information out of the material in front of us is an art form in the workshop and in the work place. Recently, we have begun building the “analysis” page for our inspections report library. OK, it’s a “Dashboard”, but I hate using buzzwords.

In building this page, we are on a multi-part mission. First, we want to wrap this project up so that we can move on to our next task. Second, we want to complete this dashboard, there, I used it in a sentence, in order to send a powerful message – there is information in content!

In quickly rolling down the side of an inexpensive pine board with a router, I might not notice the small knot that will ruin my profile. Similarly, in quickly looking at the contents of a document library, the head of this department might not notice a pattern in the various dates. In fact, he would probably select a view that doesn’t include the dates. He might miss the fact that tasks appear to be happening out of sequence, or that some tasks are taking longer for some people than they are for others. He won’t do the math, so he won’t know the averages that could help him plan next year’s work better or the ones that will help him build a better training program. Worst of all, he might not realize just what an impressive amount of work his department racked-up in 2011. None of these numbers tell a complete story, but they all tell someone where to look, and they tell them in a single glance – Well, they do if we do our job right.

Dashboards, ack, now I’m getting comfortable with that word, can’t just be a feel good group of statistics on a page. Nor should they just be a stage to show off the awesome power of Data View Web Parts. Dashboards have to be meaningful. We can glean lots of information from the data we have been collecting behind the scenes as our workflows run, but which of that information is actually useful? The larger question is “how are we supposed to know?” We are facing the age-old developer’s dilemma. We have a limited understanding of the way this department works, and the head of this department has an even more limited understanding of what our technology can do. Example: if he doesn’t know that SharePoint has a Calculated Column type, he doesn’t know that you can count the days between dates. If I explore that example a bit more, I come up with a scenario that better illustrates the challenge.

We can calculate the days between confirming an inspection and the date of that inspection. A high number of days might indicate that someone plans well in advance. A low number of days might indicate poor planning, or it might be the result of the inspection having been rescheduled. In any case, the average number of days, however good it might make the manager feel is probably meaningless. Since we know what is considered the ideal lead time for the confirmation, we have a way of displaying this number that will work as a first attempt. As for the number of days between the inspection and the report being prepared, now we might like to see an average as well as something that highlights the outliers. The point is, I can’t simply build a columnar report here; I need to handcraft a report in which every value communicates information that might be passed on to others or acted upon. If you consider a real world dashboard, there is no fluff. OK, having a tachometer on a car with an automatic transmission is questionable, but there’s very little fluff. What we see on our car’s dashboard is important or actionable and it’s presented in the mode that is most useful to us while driving.

We can’t build that type of dashboard yet, but we can make a start. We will cherry pick the most straight forward statistics and show the manager of this department a selection of numbers, graphs and status indicators. If nothing else, our dashboard will let him know what we can do. After he sees that, he can tell us where to draw the red lines and when to flash the warning lamps.