It’s official – I’m ignoring the fact that May 12th, 2010, is the launch date for SharePoint 2010 & Office 2010 – sorry, I’m a little busy right now. As I hinted last week, we recently replaced a production fat-client system with a SharePoint solution. Truth be told, the fat-client wasn’t all that fat, the system also wasn’t that well written… don’t ask. The people using this system spend a lot of time in SharePoint so when they asked me to fix this system, I suggested moving the whole process to SharePoint. They liked that idea, I liked the idea, but our experience adds further weight to the message of last week – either “train your users or build their solutions for them”.
The solution in this case is a simple Custom List with a few Lookup columns, a validation workflow and a few custom views. The users in this case know what they want, they are some of our best SharePoint users, but they don’t want to build the SharePoint they use. We (in my department) on the other hand, love building SharePoint solutions. When we built this list, we replicated the functionality of the fat-client and we added the new features that the users wanted. We back-filled the data, tested and deployed the solution and wham – open up the complaint department. “It takes a lot longer to make an entry to the SharePoint list than it did to the previous system.” On further examination, we discovered that the thing that was taking longer was the Lookup columns, these replaced text fields in the old system.
It was faster to enter a few characters into a non-validating text field than to find the right value in a list, but the result of entering those characters was often inconsistent. “John Smith” vs. “J Smith” vs. “jsmith” vs… well, you get the idea. If the users were designing this solution, they would replace the Lookup Column with a Text Entry box – that would be too many mistakes to list here. A little more investigation revealed a relationship between those lookup fields, one of those “if A then B and C” type deals. When I suggested that we could let them start from a quick menu that I could build in SharePoint Designer and then present them with a new list entry that was about 75% complete, they became very happy. While we were having the discussion, we asked a few more questions about the way they work and we added a few more tweaks to the list. Now we are busy building Custom List v.2.
For every Laura Rogers and Mark Miller in the SharePoint world that would build the perfect solution, there are likely a few thousand Larry Curly and Moes that would create, as Dilbert might say: “a smoking pile of failure.” Even when people start to learn how to use the more robust Web Parts, that doesn’t mean they should be allowed to solo. Very often, when people learn how to use a technical feature, it becomes their feature-of-choice – this is the origin of the adage: “if your only tool is a hammer, every problem looks like a nail.” Should SharePoint design and development be restricted to IT? Absolutely not! End users should be encouraged to learn more about SharePoint, but the education should not begin with: “here’s how to write a workflow”, we need to start with fundamentals. In a few weeks, we will invite our end-users to see the solution I’m talking about here. We will walk them through the choices we made, the reasons we made those choices as well as the results. We will encourage them to look at the SharePoint solutions they use and consider how they could be better or, if they don’t know the answer to that, then to simply write down what they don’t like. Then they can discuss their ideas with us and we will either help them make the changes or we will build them the site they really want.