Are you ready for AJAX risks?

It's a cool collection of technologies, but there's downside to those slick user interfaces. Here's how to be best prepared.

1 2 3 4 5 Page 2
Page 2 of 5

Maintenance

JavaScript, DHTML and Cascading Style Sheet (CSS) code have a tendency to become complex and difficult to maintain. One difficulty is that a lot of developers do not use a good IDE to write and test their code. Another difficulty is the need to employ tricky optimization techniques in script for performance considerations. These factors contribute to spaghetti code (code with a disorganized and tangled control structure) and higher long-term maintenance costs than applications written in a traditional architecture that rely more on server-side processing. The risk centers on quickly and adequately maintaining applications over time in a changing technological environment.

Maintenance risk is aggravated by the way browser vendors arbitrarily change the way the browser works and interprets CSS and JavaScript. On occasion, Microsoft or Mozilla will "pull the rug out" from a particular technique or approach by closing a security hole or "fixing" a CSS problem. An example of this is Mozilla and access to the clipboard, which has changed at least once. Another is changes to the DHTML box model in Internet Explorer 7. As Microsoft approaches a more standards-compliant CSS implementation, it will break many of the Web applications that were built to work on an older, buggier model.

The risk is that enterprises must react quickly and frequently to address sudden, unexpected and costly maintenance duties because of changes in the browser, which can be exacerbated by hard-to-maintain spaghetti code.

Forward Compatibility

Forward compatibility is related to maintenance risk. As new browsers and operating systems arrive on the scene, parts of AJAX applications might need to be rewritten to accommodate the changes in the layout engine, CSS interpreter, and underlying mechanisms of JavaScript, XMLHttp and DHTML. In the past, early-stage browsers such as Opera and Safari have been bad for arbitrarily changing the way CSS positions elements on a page. IE7 has done this again, too. This is a risk because developers need to be one step ahead of all possible changes coming from new browsers that would affect the user experience. This can impact cost containment because it's inherently unpredictable, whereas backward-compatibility work can be tested and more accurately estimated. It's important to note, however, that public betas are always available for new versions of browsers.

Firefox 3.0

Right on the heels of Firefox 2.0 is the upcoming Firefox 3.0 release, slated potentially for Q4 2007. Version 3 will likely be more of an upgrade than a completely new iteration. Mozilla is considering 50 new possible features, including upgrades to the core browser technology, improved add-on management and installation, a new graphical interface for application integration, enhanced printing functionality, private browsing capability and a revised password manager.

For developers, Firefox 3.0 will mean more in terms of Web standards compatibility and accessibility. One goal is to pass the ACID2 Web standards HTML and CSS rendering test, which implies changes to the browser's core rendering engine. Compliance for CSS 2.1 is also on the road map, which will also affect the way pages are displayed.

Safari 3.0

Little is known about the next version of Safari, and Apple rarely comments on the product road map, but Safari 3.0 is rumored to include major updates to the CSS rendering engine, which will feature a full or partial implementation of CSS 3.0 including the capability to allow users to resize text areas on the fly. Safari 3.0 will also include an updated Web Inspector tool for browsing the DOM, which will assist developers.

Internet Explorer 8 (IE "Next")

It might seem premature to be discussing IE8, given the recent release of IE7 and Vista, but Microsoft is already planning the next iteration. The final product is expected sometime in 2008 and will possibly feature some emphasis on microformats (content embedded inline with HTML). Although some improvements to XHTML support are expected, it is not yet known if JavaScript 2.0 will be on the road map. According to IE platform architect Chris Wilson, Microsoft will invest more in layout and adhering to the CSS 2.1 specifications. He also said Microsoft wants to make its browser object model more interoperable "to make it easier to work with other browsers and allow more flexible programming patterns."

Opera 10

Although no release date has been set, the vision for Opera 10 appears to be platform ubiquity. Opera's goal is to create a browser that can run on any device and operating system, including mobile and gaming consoles -- a move that could shift the balance a little in favor of this powerful, but still underappreciated, browser.

Third-Party Tools Support and Obsolescence

Adopting third-party tools such as Dojo or Script.aculo.us can add a lot of functionality to an application "for free" but also bring with them inherent risk. More than one project has gone sour as a result of serious flaws in third-party frameworks, and because of the black-box nature of third-party tools, they are next to impossible to troubleshoot. One West Coast e-commerce firm implementing Dojo needed to fly in highly paid consultants to address issues they were having with the framework. The flaws were addressed and contributed back into the framework but not before the project incurred large unexpected costs.

Obsolescence can also inflict pain down the road if frameworks are not maintained at the rate users would like, or supported in future iterations of development. This can be particularly painful when rug-pulling events occur, such us when browsers or operating systems are upgraded. Adding features or improving the functional capabilities can require bringing in developers with in-depth knowledge of the tool.

Cultural and Political Risks

There are internal and external political risks in any software project. Something that is overlooked a lot right now, in our exuberance over rich Web applications, is the potential negative impact on our audience. Of course, the point is to improve usability, but is there a possibility that 10 years of bare-bones HTML has preprogrammed Internet users to the point of inflexibility? It's a mistake to assume our users aren't smart, but all users have expectations about the way Web applications should respond and provide feedback. If our audience is sophisticated, trainable and adaptable, designers have more latitude in the way users can be expected to interact with the application. Are we saying designers should be afraid to innovate on inefficient, outdated Web 1.0 user interfaces? Not at all, but some caution might be warranted.

End Users' Expectations

AJAX has a way of making things happen quickly on a page. An insufficiency of conventional visual cues (or affordances) can actually inhibit usability for less-technologically expert users. The general public has a heterogeneous set of expectations. If experience tells a user that an item must usually be clicked, rather than dragged, they might get bogged down with a drag-and-drop element -- regardless of its apparent ease of use. It's not hard to imagine how this could happen: If you have never seen a draggable element in a Web page before, why would you expect to see one now?

Switching costs are low on the Internet. This is a cultural and economic characteristic of the Web in general, which contributes to a short attention span of users. If users become frustrated by something on a public web site, they have a tendency to move on to something else. AJAX is a double-edged sword in this instance.

1 2 3 4 5 Page 2
Page 2 of 5
  
Shop Tech Products at Amazon