Chapter 1: Understanding RIAs (part 1)

Your company has decided to take the plunge, drink the Kool-Aid, buy the ranch and go whole-hog RIA. This thought probably makes you break into a cold sweat. There’s so much breathy excitement surrounding Web 2.0 and rich internet applications today that it’s difficult to separate the hype from the reality: so many terms to decipher (mash-ups, moblogs, long tail), technologies to consider (AJAX, XML, Ruby on Rails) and words to misspell (Flickr, Digg, Payloadz). Although there’s definitely a hype factor in play here, the reality is that RIAs are changing the web, in my opinion for the better.

Rich internet applications are simply everywhere, and on the tip of everyone’s tongue these days. There’s a great groundswell of interest in moving the online experience away from what is known as “brochure-ware” (read-only, top-down, anti-interactive websites) to sites that let folks interact, manipulate and contribute, resulting in an experience that’s a lot more compelling and seriously fun.

In this chapter I’d like to walk you through the basics of RIAs and Web 2.0, and talk about the differences in both technology and interaction from what we’ve traditionally seen on the web. Understanding these differences and what’s involved to get an RIA up and running will help you to understand how far down the RIA road you should go.

1.1 Qu'est-ce que c'est RIA?
The term “rich internet application” covers a lot of ground, and has very fuzzy borders. In this territory lives a variety of application types and technologies, with varying sizes, complexities and levels of interactivity. As if this weren’t vague enough, RIA means different things to different people. For example, some companies may implement a rich internet application that adds power and robustness to the backend but has no net effect on the user experience, while for others adding “richness” may be primarily focused on the user experience, resulting in a UI paint job with no changes under the hood.

1.1.1 The Basics
The most common characteristic of a rich internet application is its ability to update data without a page refresh. While an HTML page must pull down a full set of data from the server with every page load, an RIA pulls data only when it’s needed (or even before it’s needed), and refreshes only that part of the page. Although the technologies that enable this have been around for some time, only fairly recently has their use become widespread.

To further understand the definition of an RIA, let’s break it into its parts:

Rich refers to richness of interaction, almost approaching the look and feel of desktop software. Not seen in your garden-variety HTML sites are snazzy interactions like drag and drop, plus the newfound ability to interact with and manipulate data instead of simply viewing it. Rich internet applications can also incorporate what is known as Rich Media, which includes video, audio and complex animations.
 

Internet refers to the ability of an application to connect to remote data, but doesn’t necessarily imply continuous connection or access through a browser. There has recently been a surge of interest in erasing the boundary between desktop and internet applications, by creating software that is saved locally on the user’s computer but connects to the internet when needed or when available. The flip side of this is a movement to host all software on servers instead of locally, so applications would be accessed online only when needed, on a per-use fee.
 
Application, strangely enough, is the most flexible part of this definition. When most people hear the word “application” they generally think about a robust piece of desktop software such as Microsoft Word. The Oxford American Dictionary states that an application is: “a program or piece of software designed and written to fulfill a particular purpose of the user” but there are no clear boundaries about how large or small this dedicated software must be. For my purposes, I allow the broadest meaning possible, including a simple rollover menu on an otherwise HTML page, all the way to a full-page integrated web application.
 

1.1.2 Technologies
From a technical perspective, the parameters don’t get any clearer. There are many frameworks, toolkits, and platforms that have evolved to provide this rich experience, and many more are sure to come. Currently RIAs fall into two loose categories: those based on Flash or other plug-ins, and those that are not. Web applications that run on Flash capitalize on the ubiquity of the Flash player (90-99% penetration among the different versions) and offer dynamic visual effects. OpenLaszlo, and Adobe Flex both use the Flash player, although both are also offering alternative runtimes. Microsoft’s new Silverlight also falls in this category, as it requires its own proprietary plug-in, similar to Flash.

On the other side is AJAX (Asynchronous JavaScript and XML ). AJAX technologies tend to leverage DHTML, which easily lives in the same page with HTML components, allowing for a ”bits and pieces” approach to revamping a site or application. Using AJAX creates more headaches around browser compatibility, but it’s quickly learned by experienced programmers. Just a word of warning: people often (incorrectly) use AJAX interchangeably with “rich” even if the technologies used are not based on AJAX.

Development time of an RIA compared to that of a HTML web application can be significantly more, but there are good reasons that companies are willing to invest the time, money and effort. Rich internet applications have the potential to be lightweight and much more flexible than an application written in HTML. They also tend to be platform agnostic and don’t care if you’re on Mac, PC, or Linux. In the case of web-based applications, no installation is required and updating is seamless for the user. Finally, the benefit of accessing applications and data from any computer trumps desktop-bound software, even when the online software is not as pretty or powerful (think online email applications).