I spent my freshman year at the University of Georgia (go Bulldogs) and thanks to some friends on my dorm floor, I was able to visit some beautiful parts of that state. Once while driving around some desolate south-Georgia back roads, we stumbled across a Pirate game on the radio. I recognized KDKA AM 1020 Pittsburgh immediately by the announcer’s voice. We could hear that game in Georgia due to the ability for AM radio waves to skip across the planet, bouncing off the Ionosphere. FM radio waves, due to the different way they propagate, are limited to line-of-site reception. Hmm, if this is an analogy to SharePoint, wouldn’t I want to be AM? No; we chose an FM model because it’s more narrowly focused, but capable of delivering a higher quality signal (think classical music vs. political talking heads). If we extend this analogy just a little closer to the breaking point, we like operating in a narrow band of the “development spectrum” within SharePoint so we can:
Focus on Quality – This is very important to my team. We don’t want to simply be a company that uses SharePoint; we want to implement Content Management in SharePoint. That requires adherence to the standards and best practices associated with ECM, not just the creation of a bunch of libraries. In addition, we want to improve the business process associated with the creation, use and distribution of the information that we store in SharePoint. In the current project that I’m working on, I have worked with the owner of the process to build a better way of entering data, segregating data and presenting data for review. In the course of defining the requirements, we are expanding the use case from one where we keep track of stuff to one where we keep track, manage, analyze and share this stuff with our coworkers and our customers.
Stay close to home – We keep our solutions close to “out-of-the-box”, because we want our users to be able to understand, combine, extend and reuse the work we’ve done. We also don’t want to invest too heavily in development because we have better things to be developing. No offense to ECM, but out-of-the-box SharePoint can look pretty good, and if it’s easy to use and satisfies the customers, we don’t need to make it overly snazzy. Plus, I keep coming back to the notion that, in using SharePoint, people learn how to use SharePoint, and that knowledge is cumulative. I have also found that my coworkers are more interested in how the solution works, than appearance. I think there’s a fine line between adding functionality to have the page look tricked out and modern, and adding functionality that improves the user experience – we’re working hard to find, but not cross that line.
Be a wee bit anal – I know that some of you might be asking “why not just let your users develop their own solutions from the ground up?” The answer is simple and a bit selfish; I don’t want to join some friends of mine who have been left with half-finished or half-baked SharePoint solutions when some department level guru decides to leave. I want our solutions to be documented. I want to know what needs to change if we move the solution to a new server, or to our Internet-facing farm, and I want to be able to maintain the “systems” that our employees have come to rely upon. I also want our solutions to follow some standards. For example, where we have managed metadata in use, I don’t want to see a solution that is using a Choice column that has (at the moment) the same information as what is in the term store.
The system that I mentioned above organizes data from a series of inspection reports and follow-up meetings in three related lists. In order to review that data, we built a Web Part Page that contains about 5 Data View Web Parts to pull the related bits from those lists and present them in a useful format. To setup the page, we pass a bunch of parameters in with the URL. For example, based on source parameters, the page can be grouped by Facility, or by Engineer, or by Category. We construct those URLs in a workflow and store them with each item in the master list so they can be exposed as links in a wide variety of views. The Facility link, for example will configure the page to be grouped by Facility. We could have just built a second DVWP page to drive the sort and filter process and then build the URL on-the-fly, but that would put us in maintenance mode. SharePoint Views look pretty good, and many of our users can build them. Letting them add the URLs to their own views, lets them extend our solution. It’s still a line-of-sight system, but it has a little better reach.