« Started the New Year Right | Main | Respecting XHTML's XML Heritage »
January 10, 2007
Hint to Microsoft: State Diagrams are Useful
My work with Microsoft's new web content management system (the replacement for SharePoint and MCMCS) continues... one "improvement" that the MS team made on the new version was to allow multiple points of entry for revisions to files on the system. For example, page layouts can be checked out, edited, and checked back in using the MS Office SharePoint Designer application, or they can be checked out and in using the web interface. The idea was to ease use by allowing people to work with documents using an interface of their own choosing while maintaining access controls. The outcome was to introduce complexity and increase the potential for errors caused by different versions of the file existing in multiple locations simultaneously. This is what's known as an "update anomaly" in database management systems.
If that wasn't clear, let me explain the problem that I've run into with this issue. I currently work in the SharePoint Designer to make changes to the CSS files on a page. But to publish those changes to the web from the designer requires an overly complex workflow with lots of clicking and unneeded emails being sent by the system (someone made a change, a workflow started, you approved a change....), but if I use the web interface to view all draft documents I can publish changes with a single action. So that's what I do. Except, when a change is published the file in question becomes "checked in" to the system, but the SharePoint Designer application can't see that change in status. It thinks the file is still checked out to the current user. Any further changes to the file cannot be saved back to the system, and SharePoint Designer refuses to refresh file status meaning that I can't re-checkout the file into the Designer. If I'm careful to check files in every time I want to view changes on a live web page, the problem can be avoided. Of course, if MS was careful in designing the workflow the problem could have been avoided completely.
And that's where State Diagrams come in. A good state diagram would have highlighted the potential problem here long before any code was actually written. Changes to the code now will cost MS orders of magnitude more than spending extra time in the planning stages would have. Not that it matters to me, I'm stuck working with whatever they release no matter how good or bad it is. But it's still nice to vent a little.
Posted by ashusta at January 10, 2007 10:53 AM