I began driving in the era when Interstate highways were beginning to replace the convoluted network of US and State highways interconnected by local roads. One of the first major bits of Interstate to open up in western PA was I-79 between Bridgeville and Washington, PA a.k.a. “little Washington” so you didn’t confuse it with Washington, D.C. I-79 was an alternative to, but did not replace US Rt-19. Unfortunately for me, my father stood by Rt-19 as his first choice for any destination between our house and little Washington. I can remember his arguments, which varied between: “Rt-19 is actually shorter” to “by the time you deal with getting to and from the ramps, the highway isn’t that much faster” – I call results like that a Failure Due to Marginal Improvement (FDMI).
I have recently been reminded of those conversations with my dad, as I try to replace an Excel spreadsheet with a series of SharePoint lists. The issue is that we aren’t talking about replicating data; we are talking about changing, and hopefully improving the process that the data is associated with. The question is, are we doing enough.
The spreadsheet works – The current “system” in Excel doesn’t work well, but has the advantage that people know how it works. This is often the reason why people want to just move what they have into SharePoint, the thought is that they will still understand it. When we are replacing a list, we are often changing the way items are created, maintained and viewed. The result should be a better overall experience, but will it be good enough to offset the change?
Several weeks ago, Marc Anderson raised the question of whether form or function was more important. I suggested that the form-function ratio should never be less than 4:3, and this little project is an example why I think that is true. SharePoint lists are about as close to a database solution as you can get without invoking SQL, but we’re still talking rows and columns, and rows and columns are Excel’s forte. When you start moving Excel data into SharePoint, you create one or two (in this case three) Custom Lists. If you show the user an All Items view of their data in SharePoint, it’s going to look worse than it did in Excel. SharePoint doesn’t use its screen real estate as efficiently as Excel, and people who like Excel will pick up on that immediately.
The Excel-based solution I am replacing is a collection of observations and recommendations. Each row has details about the observations on the left, a huge column of text containing the observations in the center, and a series of recommendations on the right side of an A-X layout. The text is nearly unreadable and it is hard to stay on the same row as you scroll right to left, but the process is easy to understand. Read the details, read the text, write the recommendation.
Moving to a data view web part of items, with options to expose the details in a second DVWP, the observations in another and the previous recommendations in a third, give us a composite view of each item in an easy to read format.
I’ve got one more concern as I get ready to touch base with the future owner of this solution. Since the stuff isn’t in the same “row” (it’s not even in the same list) he needs to have an increased level of trust in the underlying process. Sometimes it’s hard for people to accept that everything on that page is everything there is. Again, you gain that confidence in the spreadsheet visually; it’s not a pretty sight, but you can see it. I plan to walk the new owner through the process of building an entry from the ground up. By the time we come back to the composite page, he will know exactly what he should see. I’ve made that trip eight times, so I know it’s going to be a sweet ride. In addition to making it work, the user experience needs to be clearly superior to Excel if we’re going to avoid FDMI.