Web Applications: Richer or Poorer?

Times change quickly on the technology landscape. Yesterday’s marvel is soon replaced by a better, faster, sleeker animal — one built of bits and bytes and technological innovation that just a few years earlier seemed like the stuff of dreams.

Such is the story of the Internet. Some call it Web 2.0. Or simply, the New Internet. By any name, it is far more fluid, interactive and far-reaching than ever before. Compare it now to its infancy, and it’s almost like comparing a modern racecar to a Model T.

Recently the media have been abuzz with discussions of these new concepts and technologies. Web 2.0 is an umbrella term that seems to embrace every popular new Web trend, but Rich Internet Applications (RIAs) built using new technologies like Ajax and/or Flash are a solid technical development that some e-commerce sites are already deploying. As always, new technology creates new opportunities for those who can exploit it successfully, but also presents them with challenges. So what is a Rich Internet Application, and do you really need one to keep up with your competition?

The Evolution of the Web Page

The Internet has evolved to become much more than a network that enables e-mail and other simple message exchanges. It’s still that, of course, but — through the Web — it has become much more. It’s a platform for automation, with computers talking to computers. The Web is becoming a highly programmable environment in which applications can respond immediately to a request in all sorts of ways — all dependent on individual user profiles that make possible highly specific, targeted responses.

How has this evolution occurred? Because the Web originated as a way for researchers to share information previously recorded in documents, the first Web sites consisted only of static pages of linked text. This simple model provided an excellent foundation, but once the idea of the Web caught on, people wanted to share more than just text. Web pages soon evolved far beyond their origin in the world of documents and hypertext.

Today’s browsers allow a Web page to contain a complex structure of text and graphics, to make use of plug-in programs to play audio and video files or streamed multimedia content, and to invoke code (“scripts”) on the user’s machine (“the client”) that supplements the basic browser function of rendering HTML. JavaScript and Flash are the two major technologies for client-side scripting, which can be used to create richer interface elements like graphic rollover effects, custom pull-down menus and other navigation aids, or even data input validation functions for forms.

From Web Pages to WebApps

In the world of e-commerce, most Web pages do not stand alone. They are simply steps of a larger process that we call a Web Application, sometimes abbreviated to WebApp. The scripted features I have described, while enhancing a customer’s interaction with individual Web pages, do not alter the fundamental model of a Web application as a series of Web pages. In this model the application logic runs on the server, being executed between Web pages after the user clicks. A crucial aspect of this model is its synchronous nature — after each click, users must wait while the server handles their input and the browser downloads a response page.

During the last few years Web developers have been evolving a new model — the Rich Internet Application. As with most technical advances in computing, alternative approaches vie for acceptance as the de facto standard. Here the two main contenders are Adobe’s Flash suite, and a collection of Web technologies now referred to as “Ajax,” a name coined by Jesse James Garrett of Adaptive Path about a year ago. Ajax is short for Asynchronous JavaScript and XML.

Both approaches have their advocates and detractors, as a few Web searches will reveal. Complicating matters, some claim that “Flash is Ajax”, and yet others such as AFLAX advocate using them together.

New Technology, Old Possibilities

While this heated debate rages among geeks, for a Web user the differences between RIA technologies are actually less important than their similarities. Although they use different mechanisms, both Ajax and Flash introduce an intermediate layer, or “engine,” between the browser’s user interface and the Web server. Downloaded at the start of the session, the engine handles display changes and communicates with the server.

Adding this layer allows developers to build Web applications with characteristics that the Gartner Group has described as “between the fat but rich client/server model and the thin but poor Web based UI model.” As explained and illustrated by Garrett, the extra layer allows the user’s interaction with the application to happen asynchronously — independent of communication with the server.

Freeing the Web browser from its synchronous connection with the Web server makes available several new possible client behaviors:

• Information can be fetched from a server in anticipation of the user’s input;
• In response to an input, a browser display can be incrementally updated, rather than having to be entirely refreshed;
• Multiple separate user inputs can be validated and accumulated on the client before being sent to the server;
• Responses to some user inputs can be generated without invoking any server communication;
• Processing previously performed by servers can be offloaded to the client desktop.

By exploiting these possibilities, designers can make their Web applications more responsive and less dependent on browser-to-server response time.

Is a Richer Application a Better One?

So will a richer Web application actually be a better one? Crucially, will customers find it more usable? In a previous article about the importance of site responsiveness, I noted that to satisfy customers, a Web site must fulfill four distinct needs: availability, responsiveness, clarity and utility. We can use this framework to evaluate the likely result of employing RIA technology.

First, consider utility. Does a site actually deliver the information or service customers want? While it is doubtful that switching to an RIA design would ever lessen the utility of a site, neither does it assure increased utility. The traditional synchronous Web communition model may be a simple one, but its simplicity has not actually prevented most companies from doing business successfully over the Web using a standard browser. Maybe a few applications such as online gaming and some types of online trading did require users to download and install a proprietary client, but such examples seem to be in the minority.

Next comes clarity. The site must be simple and natural — it must be easy to learn, predictable and consistent. RIA technology may indeed allow developers to create more natural interfaces, but it will not guarantee a better customer experience than a traditional Web application. To quote Garrett, “the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.”

Next, consider responsiveness. In theory, an RIA will be a more responsive application. Web server requests will be limited to the bare minimum required to do the job, reducing the size and frequency of data exchanges between browser and server. The reality, however, is less straightforward. Optimizing any design to speed up one class of work always makes some other workload slower. Unless you consider and test for a wide range of use cases, what seemed to be a clever way to reduce network traffic may sometimes turn out to be slower than the older and simpler design.

Some RIA advocates also argue that since much of the processing has moved to the client, Web server processing time will be saved, making the server more responsive. However, any interpreted script will probably take several orders of magnitude longer to run on the client than it would on a server. So, whether a benefit exists will depend very much on the nature of the application.

Finally, how about availability? Because a Rich Internet Application is more complex than a traditional one, companies that decide to employ the technology must be prepared to invest more in design, development, testing and management to make it successful. These applications inevitably involve running complex code on the client, and use more complex and application-specific strategies to manage the communication between browser and server.

Making such complex code efficient and bug-free is not a task to be taken lightly. Today, the development and testing tools we need are still in their infancy. The Open Ajax initiative may help to address this issue.

Monitoring the application in production, understanding the customer’s experience, and detecting and diagnosing problems will also be harder, requiring more careful planning. Better tools are needed to help us meet the challenges of creating and managing robust applications.

Now Is the Time for Planning

All the same, companies will continue to invest in new Web sites and Web applications because the Web is now the platform for doing business efficiently and quickly. So, e-commerce will continue to drive the evolution of Web technologies, and Rich Internet Applications are just the current phase of that evolution.

They represent a gradual but inevitable move back to the richer user experience of a desktop client in the client/server model, but implemented through Internet and Web protocols. Over time, a richer distributed-function model will inevitably replace the synchronous thin-client model underlying the first Web sites, once technology like Ajax or Flash evolves to permit it.

To wrap this up with another transportation analogy, trying to hang onto the simple model is like insisting on riding the bus when you are offered a new car. The bus works well for some journeys, but people prefer a car, especially if they can still take the bus when it suits them. It’s the same with simple HTML-based Web pages and richer WebApps. Like buses and cars, you can still take your pick, as appropriate.

Of course, if you don’t yet know how to drive an RIA car, riding the basic HTML bus will be simpler, faster and a lot more reliable today. Still, don’t think for a moment that RIA cars won’t catch on — you had better start thinking about learning to drive one sometime soon!