In Part I of this review, I discussed the mind-numbingly convoluted workflow needed to handle user submissions of photos using SharePoint and InfoPath. In Part II, I'm going to discuss another convoluted workflow for managing a series of rotating blurbs.
On the home page are nine promotional blurbs, handled by a javascript that shows three at a time. Each business day, new blurbs are put in the first three slots, the oldest three drop out of rotation, and the remaining six are shifted down three spots in the order. You would assume that this process of rotation is a perfect candidate for automation.
Nope, it's all done manually and in the most inefficient way possible.
Now each promo blurb is its own document in a version control system. This is a very good start. Where do they go wrong? Ask me where the display order for the blurbs is stored. The display order is stored in each blurb. That means when a blurb is supposed to move from slot 1 to slot 4, you must:
- check it out of the version control system
- open it
- go to the display order field and change the 1 to a 4
- save it
- check it back into the version control system and commit your "changes" as a major (x.0) version
And please remember, you're not doing this once, you're doing it nine times... once for each of today's blurbs... so you can make room for the new three showing up tomorrow (but you put their sort order in them while creating them, so you don't have to check them out... unless you created them in advance). And of course, because you're not associating a date with the sort order, you must do this every day. There is no way to program slots more than one business day in advance. If you're going to be off, for whatever reason, someone else will have to take time out of their day to do this for you.
Now, anybody who understands databases and automation would never make the sort order a property of the document in this situation. In the 2003 copy of the Visual Quickstart Guide to MySQL, this kind of logic opens chapter 3. Five pages into chapter 3 of a beginner's book on databases, it's explaining why you shouldn't do this.
And for this reason, every day, I have to book in the new blurbs for tomorrow and pull out the old blurbs that should no longer appear. I used to do that at IMDb... in 1998... when I had to code the daily homepage by hand. By early 1999 we'd kludged up a system to modularize the homepage and schedule the modules.
It wasn't even a real CMS. We built a skeleton of the homepage with placeholders for content bits. Each bit had a file name, like "motd.html" for the "Movie of the Day" feature. Then a Perl script ran at midnight. If on February 1, 1999, it found a file called "motd.19990201.html" in the pending directory, it copied it over "motd.html" in the live directory. If there was no file with that name, it left motd.html alone. A few minutes after that, another script read the current bits, fleshed out the skeleton and published the new home page.
It's that simple. We were doing it more efficiently in 1999 with two simple Perl scripts. With thousands of dollars in Microsoft software and Microsoft-approved SharePoint and InfoPath developers (not ones who just put it on their resume and talked a good game, but ones working at Microsoft), this is the best system they could develop? What's wrong with this picture?
Of course, once you've been root on your own LAMP system and coded your own CMS from scratch, being a cog in someone else's wheel will no doubt be frustrating. And don't get me wrong, I'm liking the work. I'm just having issues with the tools I'm being given to do it. If I'm ever in a position to talk someone out of SharePoint or InfoPath, I will. Possibly I just have.
Entries (RSS)