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.

This article is excerpted from the book Enterprise AJAX: Strategies for Building High Performance Web Applications by David Johnson, Alexei White and Andre Charland, published by Prentice Hall Professional. Copyright 2008 Dave Johnson, Alexei White, Andre Charland.

AJAX has at least three main areas of risk: technical, cultural/political, and marketing risks:

Technical -- These are issues that directly relate to the design, development and maintenance of software, including security, browser capabilities, timeline, cost of development and hardware, skills of the developers, and other things of that nature.

Cultural/political -- These are fuzzy issues that focus around the experience of end users, their attitudes and expectations, and how all this relates to software.

Marketing -- These are issues that relate to successful execution of the business model resulting in sales, donations, brand recognition, new account registrations, and so on.

Advertisement

These issues are all related, and you can easily bundle them into completely different groups depending on the frame of reference. What's important is to categorize risk into levels of severity for your project and use that as a driver for decision-making.

Technical risks

Technical risk, unlike other kinds of risk, can actually result in a project not being completed. These sources of risk must be of prime importance when evaluating third-party frameworks for building AJAX [Asynchronous JavaScript and XML] applications because of the lack of technical control. Some studies have shown that 50% of enterprise software projects never go into production (Robbins-Gioia Survey, 2001). Following are some of the reasons why.

Reach

Sometimes, when writing software for large groups of people, we need to build for the lowest common denominator. Essentially, we need to sometimes build so that the individuals with the most out-of-date, inferior hardware and software can still access the application. The general public tends to use a lot of different client browsers and operating systems. We're stating the obvious here, but it's important for Web applications to be compatible with the browsers our users want to use, or we risk not delivering the software to them. Whether that means a ~1% market share for Opera is worth paying attention to and is something that needs to be dealt with -- software must, at least, be tested rigorously on a representative sample of these platforms so that we know what our reach is. This is an example of a technical risk and this reach/richness trade-off is probably the biggest everyday problem with the Web.

The basic problem with Web applications is that different browsers interpret pages differently. Although this much is obvious, what isn't known is what challenges will be faced as we begin to "push the envelope." What's easy to do in Firefox might end up being ridiculously hard in Internet Explorer. The risk lies in successful execution of the project requirements while reaching all our target browsers and operating systems.

Research firm In-Stat/MDR predicts mobile workers in the U.S. alone will reach 103 million by 2008, and the following year, the number of worldwide mobile workers will reach 878 million. This means that an ever-increasing number of workers will be accessing corporate Web applications from outside the workplace, resulting in a loss of control over the software -- especially of their Web browsers.

There is a general trade-off between the level of richness in an application and the number of people who can use that application (because of client platform incompatibility). The seriousness of this risk is determined by several factors:

  •  Whether the application is public versus private (behind the firewall). Public applications have an inherently more heterogeneous audience. Enterprise applications often have an advantage in that it's easier to tell corporate users to stick to one or two browsers than the general public.

  •  The breakdown of preferred browsers and operating systems of the target audience, that is, how many employees or customers use Safari Mac versus Firefox Mac versus Firefox PC versus Internet Explorer?

  •  The potential marketing impact of being incompatible with a segment of users. A good question to ask is, "How many people will we lose if we can't support Safari, and is that acceptable from a public relations point of view and cost-benefit point of view?"

  •  The degree to which users are willing to adapt their use of browser or operating system.

Over time, this trade-off has skewed in favor of richness. There is a tacit understanding among browser vendors that they need to provide a comparable level of JavaScript, DHTML, XML and XMLHttpRequest functionality to be competitive, and generally speaking, there is a way to write AJAX-powered software that works on all the major browsers. Mozilla, which is cross-platform, tries to ensure that things work the same whether they're running on Linux, Mac OS or Windows. Safari has been playing catch-up ball with Mozilla, as has Opera, but every quarter, new features are announced for upcoming version of those products, and the great browser convergence continues. As these browsers continue to mature, it is easier to write rich applications that work across them all. An example of this is the recent introduction of XSLT support in Safari, making it possible to deliver XML-driven applications across all major browsers.

Browser Capabilities

So much going on in the world of AJAX is uncharted territory right now. It seems that browser vendors are just beginning to understand what developers want from them, and glaring bugs and omissions sometimes create unexpected roadblocks when building cross-platform solutions. Some notable examples are the long-standing absence of XSLT in Opera and Safari and anchor-tag bookmarking problems in Safari. Internet Explorer 6 and 7 have glaring bugs in positioning of DHTML elements that require sometimes complex workarounds. Some techniques that work well in Internet Explorer can be prohibitively slow in Firefox (particularly relating to XSLT).

This risk is that developing a feature can take an unpredictable length of time or reveal itself to be basically impossible. Clearly, there is still a limit to the degree that the browser can mimic true desktop-like software, and where the boundaries lie precisely is still being explored. So often, AJAX development becomes a process of creative workarounds. Developers find themselves going down one road to solve a problem, realizing it's not going to work, having to back up and look for a new one.

1 2 3 4 5 Page 1
Page 1 of 5
9 steps to lock down corporate browsers
  
Shop Tech Products at Amazon