RIAs: The Technology Is Exciting, but They Really Do Help Users

What Is Wrong with the Page Metaphor and Is It Wrong for Everything?

First, let’s re-examine the primary reason for the use of the page metaphor. The original purpose of the Web was to distribute content that was most closely analogous to printed articles, abstracts, and other similar documents. The Web’s primary task flows involved information distribution and consumption.

But even from the early days of the Web, people have done more than just consume information. Web sites have also let users complete transactions such as purchasing items on e-commerce sites and paying bills online and perform collaboration and content management tasks. While these early Web applications fit nicely into a page metaphor, because of the step-by-step nature of their interactions, some of their more complex transactions could benefit from the use of protocols that are not subject to the limitations of the page metaphor.

The problem with traditional Web applications is that they often require users to either send data to the server or send a new request to the server to obtain more information. In either case, the Web browser must display a new page, regardless of whether the submission of or request for data occurs at a natural stopping point in a user’s task flow.

This interruption, in some circumstances, leads to a significant wait and, thus, causes a significant and seemingly unnecessary break in a task flow. This unexpected delay is an opportunity for thought, contemplation, aggravation, and remorse—probably in that order—and can lead to

• negative brand experience
• premature use of browser options such as back or refresh
• a user’s clicking again, resulting in further delay
• a user’s giving up and abandoning calls to customer service, entailing costs for the company providing the Web application

The limitations of the page metaphor have tremendous impacts on the user experience of Web applications, for example:

• It is difficult to manage the display of information in different areas on a page without refreshing the entire page.
• Web pages serve as the equivalents of dialog boxes in desktop applications, resulting either in the loss of context or in window management problems.
• Web applications often do not handle validation exceptions well. Web applications’ use of animation to communicate transitions with contextual cues is very limited. Generally, there are fewer opportunities for providing contextual dynamism.
• Web applications offer limited capabilities for tracking user interactions. While some feel that the opposite is the case, the reality is that we can track only clicks in a traditional Web application. In an RIA, we can track mouse movements.

What Makes an Application Rich?

With the distributed processing of an RIA on a networked computer, it is possible to send more data from the server to the client computer and use more of its processing power to handle complex user interactions in real time. RIAs offer richer interactive behaviors and more functionality that works within a single screen. They require fewer returns to the server—conserving both network and server CPU bandwidth—and therefore, require fewer arbitrary interruptions of a user’s normal task flow.

Another valuable feature of most RIAs is the addition of a messaging layer that can communicate between the client computer and the server without the user being aware of it, and most importantly, without any arbitrary interruption of a user’s task. Because an RIA can request information and display it on the current page, there is no loss of context—as there would be with a page refresh—and it is clear how any changes to the content have occurred.

The oldest and most famous example of such a Web application is the reservation system for the Broadmoor Hotel in Colorado Springs, shown in Figure 1.

While you might criticize its design, this Web page demonstrates the possibilities of having three distinct interactive areas on the same page. More importantly, if you use this system, you will experience what it is like to complete transactions without loading a new page. While it is important to view the calendar and the room descriptions at the same time, one might consider making a reservation to be a separate step in the task flow. However, this RIA lets the designer keep all of this functionality on the same page. This RIA also provides better contextual transitions between pages.

The RIA’s messaging layer not only overcomes the limitations of the page metaphor, it also supports real-time communication between the client computer and the server. While the implementers of many traditional Web applications have figured out how to hide the asynchronous behavior of the browser and give the perception of real-time communication, there are limitations to such solutions. They are hard to maintain, are limited in scale, and still allow the browser to process only one HTTP request at a time. Yes, the browser can manage more than one connection at a time, but it can handle only one HTTP request at a time per connection. Many RIAs use server extensions that further enhance their real-time messaging layer.

The aspect of RIAs that people most often discuss is their use of graphics, animation, and sound to bring user interfaces to life. Some would like to ignore this aspect of richness in favor of the more serious programmatic side of RIAs. However, I believe we would be doing RIAs a disservice if we didn’t explore the very real value to the user experience of their capabilities for displaying graphics and text and their use of animation and sound.

With the cross-browser/cross-platform realities of traditional HTML-based solutions, it is almost impossible to get text to appear exactly the way you want it to look. Some RIA solutions allow a designer to be quite precise in designing a visual interface. For example, they allow you to embed the precise fonts that you want to use. This is especially important when text is a major part of your brand. Why should we all have to use Arial and Verdana because Microsoft® says so?

RIAs can use graphics formats that conserve network bandwidth—usually vector-based Flash® or SVG graphics. These graphics formats provide greater efficiency in animations and when reusing a single image across many instances on a Web site. However, they do require more CPU processing power, so you could say you are exchanging network bandwidth for CPU bandwidth.

Animation is underused in almost all software design. Mac OS® X uses animation well as a means of teaching users and re-enforcing the lesson of context. Microsoft Windows® XP attempts to do the same, but its animations are not as satisfying. You can also use animation to provide a more subtle alerting mechanism. In general, movement tells a better story and engages users better than refreshing a page.

Sound is even more underused than animation in Web design. It is very effective as a feedback mechanism and provides another means of engaging a user’s senses. While it is possible to use sound in HTML, many RIAs offer better sound manipulation than HTML does.

Would users ever ask for animation, sound, or perfect rendering of text and graphics? Probably not. But these extras make a proven difference in users’ total experience of not only a Web application, but a company’s brand image. Consistency in branding engenders trust and credibility, as the research findings of the recent Stanford Web Credibility Project demonstrated.

The most important aspect of network-distributed applications is that they are distributed. Traditional Web applications are not wholly distributed. Either the client computer’s operating system, the browser, or both determine their form widgets, fonts, and many of their behaviors. The ability to dynamically distribute basic and complex user interface elements makes distributed applications invaluable platforms—regardless of their degree of richness.

So, What Is the Problem?

For me, there aren’t really problems with any of the suggested solutions for RIAs, network-distributed applications, or other means of enriching Web applications. Other people, however, find problems in

• the immaturity of the technologies
• their development environments
• security concerns
• the lack of flexibility in design criteria (Okay, this one is mine.)

Security is probably the largest single problem. Over the last three years, the need to protect yourself and your enterprise from bad people and bad programs on the Internet was probably the number one obstacle to the adoption of rich, network-distributed Web applications. Most large corporations do not allow employees to enable ActiveX® or install Java™ applications on their computers. While many new RIAs work around these challenges, there is still a fear of their use. Some basic forms of RIAs still don’t work in a corporate environment, including Macromedia® Flash, Sun™ Java Web Start technology, and Microsoft .NET™/ActiveX. For the consumer market, there are fewer obstacles, but many users are afraid to install anything new, unless it comes from a very trusted source. Unfortunately, many formerly trusted sources have become untrustworthy. (For example, AOL® Instant Messenger™ installs a WeatherBug® application without asking users if they want to install it.)

The other problems with RIAs may concern some, but they are more like excuses rather than reasons. Technological change is a cultural reality, and I never accept resignation to the status quo. Lack of control over design criteria is a concern of mine, as I noted above, but I’d rather work under such constraints than be severely limited in the kinds of interaction models Web applications can support.

What About Desktop Applications?

While few, if any, RIAs can match the capabilities of a network-distributed desktop application, I didn’t pose this rubber-meets-the-road scenario as a problem with RIAs. The main reason for the small number of desktop applications in this arena centers on security. Any software that can access the desktop can do way too much to a user’s client computer without him knowing about it. If getting approval to install an RIA is hard, installing one that connects the desktop to the Internet is almost impossible within many organizations.

That said, there are good examples in the consumer market. Here are some of the ones I like:

• Google™ Desktop™—which allows you to search both your desktop and the Web at the same time
• almost all of the photo-sharing services, including Flickr™, Picasa™, Kodak™ EasyShare Gallery, and Snapfish™
• good instant messaging clients, including Trillian™, Adium X, AOL Instant Messenger, Yahoo!® Messenger, MSN® Messenger, and Paltalk.com™

How Will These Design Considerations Impact You?

In all likelihood, RIAs don’t present new design considerations for experienced application designers. However, they do present challenges for people who are moving to Web application design from more content-oriented, or page-oriented, design. Making this switch is similar to moving from designing books to writing screenplays. Most good software designers write scenarios, because their narrative form provides the best way of making a software design come to life. Actors, settings, and plot all come into play in the narrative of a good scenario for a software product just as they do in a screenplay.

As Gene Smith expressed in his presentation, Beyond the Page, we need to start thinking differently about our deliverables. My personal leanings lie somewhere between the position that the design is the product, and you can just create a working prototype of your design for a Web application, and the more traditional, rational method of creating detailed design documentation. I find that, while modeling a prototype is fun, a prototype is not actually a great communication tool for complex designs. The problem is that each person who needs to work with your design will look at the prototype from a different point of view. While they will see certain details in your prototype, they may not see the details you intend them to see. There needs to be some means of annotating a prototype. Doing this at a sufficient level of detail within the prototype itself is very difficult, because you end up with the annotations completely overwhelming people’s experience of the prototype. In the end, design and documentation are not necessarily the same thing.

Concluding Thoughts

While new technology options are letting us move away from the page metaphor, I have not focused on technology in this article. However, in my view, Macromedia Flash provides the best RIA technology. Without going into a comprehensive comparison, what I see in Flash—including its Flex™ engine—is a complete platform for both the front end and back end of an RIA that provides all of the aspects of richness that I’ve described. Its only negative is that it can’t communicate with the desktop—though Macromedia Central™ can.

The advent of Web applications has distracted us from the ongoing work on network-distributed applications. While using the Web browser to present types of content that are analogous to various types of printed documents makes sense, transaction-heavy applications do not quite fulfill their potential in this medium. It is now time to step back a bit and consider which technologies provide the best platform for particular classes of Web applications.

I look forward to engaging fellow software designers in discussion of this topic and to thinking even more strategically about Rich Internet Applications. 

Bibliography

Baxley, Bob. Making the Web Work: Designing Effective Web Applications. Indianapolis, Indiana: New Riders Publishing, 2003.

Smith, Gene. “Beyond the Page.” Paper presented at the IA Summit, Montreal, March 2005. Retrieved December 6, 2005.

“Stanford Web Credibility Research.” Retrieved December 6, 2005.