Sidebar: Our Journey from ECM to WCM
I recently debriefed the director of internet technology at a large Washington, D.C. citizens’ association after he led a web content management technology selection effort. Here’s how he told their story:
Initially our IT team pushed hard for a single platform to meet a number of information needs rather than looking at a solid solution for our most pressing need: supporting our website. Our whole association brand is represented on the web; it’s important to us.
We looked at some traditional ECM vendors, but their WCM products were not as flexible or up to snuff. Some of the user interfaces were not something that we would be able to get people to use. The amount of effort to customize and implement in our environment was substantially more. WCM was one feature among several other things they offered, and we would end up buying the Queen Mary when really we just needed the presidential yacht.
We’re not going to use the WCM for B2B integration or print management, just for streaming stuff to the web. The reality is that the requirements for the print world are sufficiently different that it’s too big a challenge for us to take on at this moment.
In the long term, we do hope to install strong hooks to leverage our web content in different ways and environments. During our [just completed] proof of concept, we were able to integrate our separate social networking software with our WCM templates. I’m pleased about that.
Sidebar: Ajax & Your CMS
Still, CMS user interfaces are generally behind when it comes to web-application best practices and rich internet application (RIA) design patterns. Even relatively simple functionality such as auto-completing entry fields, inline status, cursor hovering tips, and wait indicators are still sorely lacking, though they’re often touted as “in the development queue.”
What’s become clear is that the aspirations of product managers at web CMS vendors have often exceeded their developers’ near-term ability to reconstruct user-interface layers and get Ajax-powered applications to work across their diverse installed bases.
On the whole, though, the new focus on Ajax to increase usability is a very good thing. However, before you sign a contract based on a slick new contributor interface, keep in mind the following caveats.
Ajax brings potential cross-browser compatibility problems. Test any interface thoroughly in your enterprise standard browser(s).
Page refresh, the Back button, and other browser-specific functions don’t work with Ajax. Of course, they are often the bane of any web application, but some web editors are used to having them around. Some CMS user interfaces with Ajax pop a new browser window with all navigation and buttons turned off.
It is difficult, if not impossible, to bookmark an Ajax-powered page (indeed, the whole notion of “page” can go away), or send a link via email to the particular state in an AJAXed application.
The browser may make a lot of little calls to the server, which could have performance implications.
Expect to see more Ajax-based CMS user interfaces later in 2007 and into 2008. Meanwhile, early adopters can plan to be doing a lot of testing for vendors.
Open Text / Red Dot