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

By David Heller

Published: December 6, 2005

“So far, we’ve had few discussions about the value of RIAs to users and how RIA technologies let us create better, more usable Web applications.”

Recently, there has been a lot of talk about Rich Internet Applications (RIAs), how they work, and how to choose the appropriate RIA technology. Unfortunately, so far, we’ve had few discussions about the value of RIAs to users and how RIA technologies let us create better, more usable Web applications.

This article addresses two questions:

  • What is wrong with traditional, pre-RIA Web applications?
  • How do RIAs remedy their problems?

What Is a Traditional Web Application?

A traditional Web application is heavily dependent on the metaphor of the page. A page presents a single set of information in response to a user request or query and provides limited interactivity. Bob Baxley, in his book Making the Web Work, discusses various page types. A page might be a form—allowing limited user input—a view of a single dataset or media object, or a list view of aggregated, or summary, data. Without adding richness, you cannot really break away from these three basic page types. Each page type has an infinite set of variations and, depending on the level of richness that you add, can provide a certain amount of intrapage interactivity such as the selection of options, drag and drop within a page, and even business rule validation.

No matter how much interactivity you add to a single page in a Web application, there is one overriding limit. When a user navigates to a page, the Web server sends both the information that the page presents and all of the code that supports user interactions on the page. Interactions on the page do not trigger another get from the server to obtain further information that would support a greater degree of interactivity. Doing so would initiate a page refresh, which downloads a new page.

Why Is the Metaphor of a Page So Apt for the HTML-Based Web Experience?

“The page metaphor defines the user experience of the traditional Web, because following a hyperlink initiates a change that is similar to the experience of turning the pages of a book.”

This question begs the further question: Why does the page metaphor even matter? The page metaphor defines the user experience of the traditional Web, because following a hyperlink initiates a change that is similar to the experience of turning the pages of a book. As I turn to the next page of a book, there is a moment when neither the previous page nor the next page is available or readable. I must pause for a moment before I can continue reading. The same is true of Web pages. I must wait while the next page loads.

On content sites, the page is an appropriate metaphor, because most Web pages let us view narrative content that is similar to the content in magazines, books, pamphlets, and other print media. Traditional Web sites often have site maps, which are analogous to the tables of contents in books, and index pages, which have the same function as the indexes in books.

Prior to the introduction of Web versions of applications, this idea of a page was not the primary metaphor for applications. Windows and panels were the primary containers of functionality, and the transition points when users requested new data did not lead to such stark differences in context. The only transitions that placed users in a new context were those that denoted a complete change in task or a different step in a task.

The cultural effect that the page metaphor has had is quite strong. This metaphor permeates not just our Web applications’ behavior models, but also the artifacts that we, as designers, use to communicate our ideas such as wireframes and site maps. This legacy is an issue that we must deal with as we move forward. Beyond the Page, a presentation by Gene Smith at the IA Summit in 2005 addressed the issues relating to moving beyond the page metaphor and its design repercussions.

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?

“RIAs offer richer interactive behaviors and more functionality that works within a single screen.”

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.

Figure 1—The iHotelierSM reservation system for the Broadmoor Hotel

Reservation system for Broadmoor Hotel

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.

To summarize, a Rich Internet Application

  • places more behavioral logic and captured data on the client machine
  • allows communication between the networked client and the server without forcing page refreshes
  • provides better control and use of various media, including text, graphics, animation, video, and sound
  • supports distributed content, widgets, and logic

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. … Most large corporations do not allow employees to enable ActiveX or install Java applications on their computers.”

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?

“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.”

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.

9 Comments

Hi, thanks for your article. Could you be more explicit about this sentence: “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.” ?

Security issues of these technologies are known, but what do you mean they won’t work in a corporate environment?

“Unfortunately, so far, we’ve had few discussions about the value of RIAs to users and how RIA technologies let us create better, more usable Web applications.”

Nonsense. Much of 2005 has been spent talking about “Web 2.0” and Ajax, two terms suspiciously absent from this article. Sites like Flickr, which has this responsive interface you describe, are in fact built with HTML, as is Google Maps, Oddpost, and other responsive new applications. Thus, your conflation of “page-based” and “HTML-based” as counters to “RIAs” is nonsense. Much of this article just boils down to “there are some challenges as users’ expectations of interactivity become more sophisticated, especially if all you’ve ever designed is content templates.” And it’s unfair to spend most of the article talking about technologies and security issues, then insist that the conversation focus on “strategic” issues.

And again with the damn Broadmoor hotel application? How many times have we seen that thing trotted out? Isn’t there something more recent or popular you could have used? You’ve been banging this “HTML is dead” drum for at least a couple of years now, and if anything, it’s become obvious that HTML-based technologies are getting more capable, and designers are getting more adept at using the technology appropriately.

Do you see Ajax as an effective RIA?

Thanks for the comments and questions.

First off, Marcus, ya gotta settle down a bit, don’t ya think. One of the things that differentiates publications from blogs is timeliness. This article was written in the first half of ‘05, as a reaction to early RIA articles back then that were just hyping technology without looking at the other story. What new patterns and design elements can we find by richening up the application and what are the investments we are asking for from both users and developers to do so?

Yod, “security concerns” is what IT departments use as their excuse for not allowing Java or ActiveX (required to run Flash) on their user’s machines. But the real point isn’t the why, but the result … User’s aren’t allowed to run these technologies in many corporate environments, so the why IT departments do this is less important than the reality to designers when they try to make a decision about technology choices.

Rob C, there have been some great articles about Ajax being included in the RIA mix. I think that John Boutelle has a really good one comparing Ajax to Flash on his Blog (on second reading it’s more about what Flash is good for, but has subtle comparisons to Ajax.

In my current employment, we are designing an RIA for the corporate sphere, and we have not yet decided a final framework. The options are Ajax or Flash as Flash is pretty ubiquitous (the closest thing to HTML).

But we also know that both of these solutions will not be enough, because we have one basic requirement that neither of them has: We have to connect to the desktop. We have to read the C drive and mapped drives to move content from server to local machine and back again in ways that the browser security model won’t allow.

Ajax also doesn’t do as well when it comes to animation. I don’t mean tiny movies, but rather effects that add to the total user experience. Ya know, the genie effect in Mac. Stuff like that. Flash is better at this, but still takes a bit of work.

On the horizon XAML is really going to pick up speed, especially since they are providing engines to run on other operating systems.

I hope this helps answer some of the questions and address some of the comments.

Oh! okay, I’ll bite! Marcus … re: the “HTML’s time is dead” thing … It was meant wholeheartedly (and most people got it) as a provocative piece to get people thinking fresh. While some people got it that HTML’s time is a changing, many people were (actually most still are) designing Web experiences as if it was 1996. While we have Flickr and Gmail coming down the pike, very few companies like SalesForce and Documentum, and other more business level applications have moved forward and quite honestly even most consumer experiences. Gap has done an okay job, though I disagree with their decisions. At least they are trying, right? But they are not the norm. Someone has to kick these people in the butt, and they have to be shocked out of their stupor to see that there are new ways of communicating interaction between system and user. Of course that piece in Boxes and Arrows is now 3 years old!!!!! So to bring it up now seems a tad lame in and of itself.

RIAs are gaining acceptance in corporate worlds. Chase Manhattan Bank has invested 8 figures in a new enterprise lending platform that is entirely FLEX based. Other lenders will follow suit shortly. Yahoo beta mail is RIA based. Soon (2-7 yrs) all major consumer direct experiences and anything done through an on-demand/SaaS model will be RIA based. Okay, not all; only the industry leaders and most successful companies will be fully immersed in RIA. For more interrupt-driven / non-linear tasks, RIAs provide opportunity for ridiculous efficiency improvements. I’m short on time. An RIA changes everything you thought about a Web application. You have to experience it to see the differences. I recommend checking out Yahoo Mail, and then Yahoo beta. It’s way underdeveloped at this point, but you will get the picture. Think of that same power applied to more complex business applications. That’s what companies like Macromedia, Dorado, and others are bringing to the table.

Wait for Adobe Apollo. It will solve the problems of reading the C: drive and leverage all the RIA programming technologies that are availble now in one package.

Hi Ryan, In a world where many many corporate facilities don’t allow Flash or Java or .NET to be installed or ActiveX to be turned on, why would Apollo solve the problem of the C drive any more than Swing or .NET does today? People have not upgraded to Acrobat Reader 7.0 for the most part, and Flash 8 is not a defacto, ubiquitous standard either. Now, in about 3 years when Vista—and/or WPF/E—gets some traction, then maybe we can really open up the desktop. ;)

Hi David,

Very inspiring article. Great.

How does Flex compare with OpenLaszlo?

I feel that OpenLaszlo is the best RIA technology at present. It can currently work with Flash and, in future, will support DHTML, Java ME, Silverlight, and so on.

Flex is also good, but will work only with Flash!!!

Please give your valuable suggestions.

Thanks and regards.

Hi Kumar,

I don’t think your statements are completely accurate about Flex. Flex outputs to both SWF and to HTML/JavaScript, which can be used to create a pretty nice Ajax application.

OpenLaszlo is nice. Flex is nice. .NET 3.0 is nice. I don’t think there is a clear winner in any category. Then throw out there new JavaFX and re-runs of CURL, and the whole RIA sector is pretty robust.

I personally don’t have any favorites for technology. In my last position, we custom coded our own Ajax interfaces and did .NET work. In my current position, we are custom coding and using .NET3 with Expression Suite. I’ve also dabbled with Flex as well. They all have their pluses and minuses. I haven’t worked with OpenLazslo, but on paper I’m not seeing any huge advantages outside of the open source piece.

I would have to add that I’m not a developer. I’m a designer, and so development environments concern me a lot less than runtime engine choices, as those impact the user more directly. If an IDE limits the user experience or pushes it in specific directions, then I’m concerned, but in these cases, I don’t see too much of that going on any more.

Sorry I couldn’t be more helpful, but the point of the article is really to move past technology discussions and into the realm of talking about design.

If you go to my SlideShare space, you can see a few presentations I’ve done that expand further on “Why do RIAs?” Enjoy!

Join the Discussion

Asterisks (*) indicate required information.