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.