Ajax and Your CMS
By Jonathan Downes and Joe Walker at 2006-04-03 00:48:00 |If a modern day Rip van Winkle woke up after just a year's sleep, he would be stunned by the buzz around Ajax today. Technology is moving very quickly in this space and whether you are a web author, a CMS developer, or a regular web user, Ajax will make some exciting changes to your world. (We'll assume you already know about Ajax; if not, read this introductory primer.)
For the Web CMS world, Ajax offers the possibility for a better user experience for content authors as well as site visitors. But what of its limitations? While Ajax delivers many benefits, it also creates a few challenges. This article will look at some of the benefits and limitations of Ajax for managing web content.
2 Sides to Ajax in your CMS
Fundamentally, there are two dimensions to examining Ajax and your content management system.
Ajax in my CMS Interface: Firstly, how is my CMS Vendor applying Ajax to improve their CMS product to benefit authors and site managers? To the extent that Ajax can afford a potentially more familiar, desktop feel to a web-based application, this is the area we would expect most of their attention to be focused at the moment. And indeed, many vendors are working on Ajax-driven interfaces for their products.
CMS support for creating Ajax-driven web sites: Secondly, what tools is my CMS vendor providing me with to include Ajax in the sites I produce for my customers? This area may come later but is vitally important. As Ajax interfaces become commonplace, your team will want to look at providing them to your customers. It is one thing to have a greatly improved user interface on your CMS tool, but you do not want to lose web traffic and sales because your websites have fallen behind on usability.
What opportunities does Ajax afford?
Single-Page Interface: One of the great things about Ajax is that you don't need a page refresh every time you want to add some more information to the page. This is sometimes referred to as a "Single-Page Interface" and is particularly useful where a large data set is required behind the scenes to enable a function. For example, CMS vendor Day has long made use of Ajax for their tree navigation, overcoming many of the technical and graphical challenges with the traditional approach (see screen below). For example maintaining the state of which branches of the tree are open and which are closed is very difficult with standard HTML, and is also very inefficient on the network.
CMS vendor Mediasurface uses Ajax for presenting context-sensitive information. The screens below illustrate what happens when the 'Edit Item Details' task is selected. The toolbar, menu bar and task pane on the right are updated directly within the browser window to present the editor with additional information, the appropriate edit boxes, and a revised set of options.
Ajax has been successfully used for in line spell checking on the web, and can work well for auto completion of meta data in a manner similar to Google's Googlesuggest. Editors will like the fact that they can save changes without the need for a full "submit," which might generate a new version or prematurely kick off a workflow with an unnecessary e-mail to somebody. As an approach, Ajax supersedes the frames approach -- still common in many DM and CM systems -- to providing subparts of an interface that can be managed independently.
Drag and drop: Ajax has brought with it a seemingly infinite increase in the amount of information available for the page designer to present to the user. Consequently there has been a revival and acceleration in the development of web user interface tools and techniques. One notable opportunity for the content management applications is the use of drag-and-drop for positioning and ordering of content on a page, again traditionally the realm of the desktop application. Examples of this type of interface in action include customising news layout in google news and gadget layout on Microsoft's live.com. Also Scriptaculous offers some very interesting demos.
Better Performance: This covers a range of issues,
but in general Ajax provides a faster update of page content than does full
page refreshing. Since the server is sending data and not full pages, response
times improve, and with layout changes reflected at the client, the overall
load on the server is reduced (although this needs to be balanced off with
the increase in the number of requests being made back to the server). For
authors, this can mean a snappier experience within the tool -- never a bad
thing - and likewise, improve the performance of a CMS-driven site that would
otherwise serve entire pages dynamically.
Nevertheless, it is worth being aware of the user perception issue. If authors can't see anything happening, they will think that nothing is happening. Ironically, a visible but slower full page refresh maybe perceived as more responsive than a sub page update. Inserting the word "loading" or similar while data is being retrieved can really assist here.
Manage Ajax-enabled snippets: If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.
What are the potential drawbacks for the Web Author?
Back Button & Bookmarks: "Single Page" interfaces complicate the relationship between the URL and the content in the page. Consequently you break two traditional web expectations, the back button and the bookmark. A number of vendors deal with this by removing the traditional web buttons from the Ajax user interface. Here the desktop concept of undo becomes much more relevant and the vendor can more closely control the navigation of the user within the application. To be sure, many CMS tools today will not support the back button nor persistent URLs within the application, although in general they are getting better at this, and URLs that can be embedded in e-mails are increasingly important in a world where information workers spend much of their day in Outlook.
It is work noting, however, that there are circumstances when a user would not expect these features to work even in the traditional web world, for example, pressing the back button after submitting your credit card details does not undo an online purchase. Likewise, bookmarking the BBC News home page does not return you to the same content every day.
Refresh: Related to the above issue is the risk that a page refresh part way through an Ajax sequence will return the user to a page at the beginning of the sequence. For example, if you are looking at a specific mail on Gmail and press refresh you are returned to the Inbox. Here again, most CMS tools -- which are essentially forms-based applications -- already will tend to create unexpected behavior upon manual page refresh, but Ajax probably aggravates the problem.
Visual Accessibility: This relates to the use of screen readers like Jaws. Readers that are designed around traditional Multi-Page Interface sites are going to struggle with an Ajax rich site. It should be noted that most CMS interfaces are already non-compliant for all sorts of reasons (use of color for meaning, graphical navigation, etc.), and many vendors are working on separate, accessible interfaces. Ajax will compound the challenge for vendors and buyers alike. In time we expect that screen readers will improve to handle more dynamic pages, and CMS vendors will become better at allowing their pages to integrate with screen readers, but meanwhile this presents a real challenge.
Preview: Authors always want to preview content before publishing it. So how can your CMS enable them to preview changes to a text snippet that appears only under certain circumstances? This challenge is similar to the problem of previewing pages destined to be published on highly personalized sites. Some vendors provide authors capabilities to simulate user behavior to confirm where and how modified content will appear. Publishers of Ajax-driven sites will want the same.
Browser compatibility: Needless to say this is an issue on public sites, but it also comes into play on the CMS contributor side, where vendors are just now getting a decent handle on IE quirks and developing FireFox compatibility. Many of the technologies used by Ajax websites have been around for several years, but have been largely ignored by web developers. One of the big reasons for this was the difficulty developers had in making their solutions work in all browsers. Two recent factors have changed this to a large extent; browsers have become more standards based, and libraries like DOJO, DWR and SAjax (see above) do a lot to mask the nuances.
Some of these issues may dissuade you or your vendor from using Ajax aggressively at the moment, but history would suggest that it is only a matter of time and of course some creative technical development before suitable solutions or work-arounds become available. Perhaps Ajax will even provide radically new approaches and give us better functionality than we thought possible.
On the whole, Ajax is here to stay. It is still early days, but the number of unanswered questions appears to be more than matched by the growing amounts of development energy. While at the moment, content management vendors may be satisfied to experiment with Ajax in their contributor interfaces, their approaches will rapidly mature. After coming to appreciate Ajax within their CMS tool interfaces, content managers will be demanding support tools for Ajax in the templates and sites they themselves publish. It will be interesting to see how quickly the vendors can respond.