1.4 How much and how rich?
There are many levels of RIA integration. Some companies just want a shot of Web 2.0 in their drink, something to spiff up the user experience and make the site more contemporary. Others are trying to smooth over interface limitations of an HTML site, but still want to keep the basic framework. Still others are looking to develop a robust, end-to-end RIA solution for their clientele. How deep you decide to go depends on your budget, timeline and needs.
The book About Face discusses the different postures of software, some of which I will co-opt here as definitions for the different levels of RIA integration. Of course RIA integration runs a continuum, but this section is meant to help you decide what level might be right for your project and what’s involved.
1.4.1 Full steam ahead: sovereign applications
Full-scale integrations, or (to borrow the term from About Face) sovereign applications are online applications that are dedicated to one purpose or set of tasks, and usually offer the entire screen for use. These applications allow users to interact with and manipulate data, and usually promote stickiness and deep involvement with the site: users set up accounts, create profiles, upload media, invite friends. The goal for these is usually to provide an immersive and focused experience free from distractions such as external links.
Full-scale integrations and sovereign applications are gaining more and more prominence on the web, seen in applications such as Mixbook, flickr, and Yahoo Pipes. More corporations are turning to online applications for wikis, content management systems and human resources tools. Some makers of consumer software are going even further by creating desktop applications that seamlessly integrate with the web experience, but without any browser limitations. Joost is a great example of this; the user downloads Joost software to their local machine, but streams and views video in much the same way as on youtube. The end result however is a more robust, cinematic experience.
Because these types of applications are really products that will have competition based on a feature set or the quality of the user experience, companies are more willing to push the boundaries with these. The immersive quality of these applications allows designers to have more freedom to try unconventional interactions. This is definitely not the place to skimp on design strategy or interaction design, as your long-term return on investment is directly tied to the user’s favorable impression of the software.
There’s no way around it: creating a sovereign application is a lot of work. Creators of rich internet applications often include Web 2.0 features such as interactive maps, dynamic filtering, social networking, status, messaging, etc., none of which are simple or straightforward. With technologies based on Flash or other plugins (OpenLaszlo, Flex) both the design and development time is simply more: interactions are more complex, and the animations and other interactions that make RIAs great take longer to implement. Even using a more straightforward and less robust AJAX technology may require more development time if other Web 2.0 features such as social networking are included.
All of these warnings aside, I’m the first to encourage you to jump off this cliff and go RIA all the way. If you’re certain that your product has a focus that requires a dedicated application and your company has a stomach for the investment, this is the best way to provide a quality user experience while differentiating your product.
1.4.2 Transient integrations
The transient designation covers partial RIA integrations and widgets. One example could be giving an ecommerce site an AJAX makeover, to smooth over some of the interaction pain points without changing the overall HTML structure. Another example is a stock widget that lives on a page with other content, such as on a blog, updating continuously.
Transient integrations are well suited to sites and applications that aren’t visited frequently, or where less emphasis is placed on manipulating data instead of viewing it. These types of applications need to more closely adhere to typical web conventions because they don’t have the stature to require a steep learning curve of their users. They are also ideal when an overall HTML framework is desired, where users might like to bookmark individual views or share with others.
Widgets are miniature applications, but still deserve the transient label. There seems to be a growing passion for widgets that show the weather, follow stocks, play music, display RSS feeds, showing up on dashboards, myspace pages, blogs, and so on. Although we will see increasingly complex widgets appear in the near future, they still tend to have more of an emphasis on viewing data rather than entering or changing it, and always want to be very welcoming to a first-time user. Considering the small space available on a widget, the feature set must be reined in as much as possible.
Because their functionality is generally limited, investment of time and money for a transient integrations is less. Emphasis in the user interface is on clarifying work flows and simplicity in general. If time and money is limited, restrict the changes to those that will make the biggest impact in the user experience.
1.4.3 Just a sip: the RIA component
The last category is component, and this refers to the individual pieces of a rich interface which may be implemented singly. Some great examples of these are menus that expand in place, tooltips, dynamic inline messaging, etc. Even isolated components can dramatically improve the user experience, increasing the user’s feeling of responsiveness and efficiency of the site. Although creating a site by piecing together rich components one at a time will inevitably result in Franken-software, rich components can be added as shorter-term solutions.
1.4.4 Above all else, simplicity
There are many compelling reasons to add richness to a site or application. But because RIAs and Web 2.0 are the subject of so much hype, people have a sense of urgency without truly understanding the impacts. Occasionally we get clients who want a full blown web application when a widget will suffice, or they come to us with a buzzword checklist: social networking, user generated content, drag and drop, and hey, let’s throw in a node map for good measure. There are valid reasons to incorporate any of those things, but only under the right circumstances.
A company called 37 Signals has gotten a lot of attention recently for their minimalist approach to software. They propose isolating the true needs, the core functions needed to fulfill the vision for the software. Consider everything else icing on the cake to be incorporated as time/money/need allows. Or never. Very often features that seemed essential in the ideation phase of software development prove to be irrelevant when that software gets some face time with users.
Although it may seem like an obvious concept, it’s amazing how many companies lose the forest for the trees, getting into spitting contests with competitors over feature sets. More features add more complexity, greater cost, and longer development times. Cutting it down to the essentials will help you clarify the main identity of your software baby, and allow you to grow with it.
1.5 Summary
Hopefully you’re a little closer to understanding why RIAs are different and why that’s a good thing, There’s a lot of fuss about a new breed of technologies and features characteristic of Web 2.0. and it’s helpful to understand at least broad distinctions in technologies (plugin-based versus AJAX), and the types of rich interactions on everyone’s laundry list (social networking, user generated content, etc.). You’re also armed with knowledge about the continuum of integration, and what that means to your design or development effort.
With that under your belt, we can move on to the differences in designing the software, and how to prepare mentally for that task.
1.3 RIA interactions
As an interaction designer, RIAs represent my day in the sun. The great impetus for Web 2.0 and RIAs in general is to improve the user experience! How could I not be behind that?!? Alas, RIAs still have their share of detractors, even among designers. I can sum up their reservations in two words: Skip Intro. At first blush all the new features available in RIAs may seem be a surface polish only, designed to enhance a site’s cool factor with some sparkly (yet gratuitous) animations. But in truth, the advent of truly interactive web applications represents a significant shift in the online user experience and great opportunities for designers and creators of online software. Now we’ll look in depth at some ways the interfaces. – and even users’ habits – are changing as a result.
1.3.1 Searching
On a fundamental level, RIAs enable a change to users’ searching pattern, or how they find data more directly on a website. The typical user’s searching pattern online can be characterized somewhat like a tree. The user starts at the trunk (a homepage or perhaps a page of Google search results). The trajectory then follows a branch, each joint representing a decision node, or a choice to further refine the data. At the end of each branch is a leaf, an endpoint where no further refinement can take place.
On a site like Home Depot, if I’m looking for, say, reflective insulation for my roof (and choose not to perform a search for it), I need to start my journey by guessing where this item lives on the site, choosing a main category and subsequent subcategories until I find the item. For the insulation, I must traverse this path: homedepot.com > Building Supplies > Building Materials > Roofing, Gutters and Siding > Roofing > Roofing Accessories > Reflectix Reflective Insulation ($21.00). The Home Depot site gives me a breadcrumb trail to jump back to earlier nodes and branches if I find I’m in the wrong section. But if I’m looking for an item and don’t have enough information to perform a search, I must essentially keep guessing, narrowing my search until I find what I’m looking for, or come up empty and choose a different node.
I liken this approach to fishing. When you’re out on the lake with your fishing pole, there may be one fish in that lake or one thousand, but you don’t know because you can’t see below the surface of the water. One of my main goals in almost every project I touch is to remove that opaque layer and let people see what’s inside before they start to fish.
RIAs remove some of that opaque layer by offering the leaf nodes further up the branch, simply by incorporating them into the current view. A good example of this is the revamped Gap site, which applies a rollover detail view. Instead of clicking an item in a list to see it in detail, then clicking the back button to return to my list, I may simply hover over the item or one of its neighbors without leaving the page. Snap offers a similar feature for links in blogs and search result pages, allowing the user to preview the link before leaving the current page.
Smaller branches can also be incorporated further down the tree as well. For example, adding something to a shopping cart was often a 2-3 page operation in the old days (page 1: click “add to my cart”, page 2: confirm “Add to my cart?” click Yes/No, page 3: “This item has been added to your cart” click Return to Shopping/Check Out). This kind of path derails the user’s shopping experience for a routine action. RIAs in contrast often allow the user to add an item to the shopping cart without leaving the page, and sometimes even allow viewing the cart’s contents as well.
Another great example of incorporating branches is expandable navigation. If I am able to find my item before committing to a page refresh, I’ll feel much more efficient and have a better overall experience on the site. Done well, the entire site map can be accessible in a few clicks from the main navigation.
1.3.2 The new taxonomy
Categorizing data , or supporting findability, is a key concept in interaction design, and a front where some progress has been made (although miles to go before we sleep). In my Home Depot example, we see a very top-down approach to categorization or taxonomy. I may know what I want, but I also need to know what Home Depot thinks it’s called and where they think it should live on their site. Sometimes things are difficult to find because of a disconnect in how I think about something versus how the site creator thinks about it.
Tagging is one solution to this problem, allowing users to label and categorize data (coined folksonomy) to help others find their way to content. As I mentioned before, it’s not always the optimal way to add information, but given the right context and user base, it can be very helpful. In fact, tagging is just another way for users at large to add metadata to items on a site (purposefully or unconsciously), data that others can use as filters: I can search for flickr photos tagged “bunnies”, I can browse 4-star movies on netflix, I can see the “Videos being watched right now” on Youtube.
1.3.3 Serendipitous browsing
The layout of a site like Home Depot is very purposeful: very focused and task driven. I want to find what I need, pay, and get out, and I will measure my success by how little time it takes me. This is great for some sites, but other sites may want their visitors to settle in for a while, explore and find things they weren’t necessarily looking for. This notion is called “unconscious” or “serendipitous” browsing.
On sites measured by their stickiness – how long their users remain on the site – it’s to your advantage to figure out new ways to prolong the trip. Offering tangents up for exploration (people who liked x also liked y, bestseller lists, most watched lists, etc.) is a good way for people to find new content. Also keep in mind the “long tail”, meaning the less frequently accessed content essential to niche audiences. Markers like “most watched” and “most popular” create a self-reinforcing pattern: they bubble to the top because a few people liked them, then stay there because they’re the first thing that people see. Help users find hidden gems at the bottom of the barrel by offering content derived from means other than popularity contests. This can come in the form of random selections, user generated recommendations, or other curated lists. Departure from the usual suspects can add the sense of surprise and delight in your application.
1.3.4 Other rich interactions
Many of the new interactions in RIAs are actually old interactions borrowed from desktop software. Nifty conventions like drag and drop, multiple-selection, and direct manipulation are used to great effect in RIAs, orienting the user, explaining the interface, and allowing the user to interact with data in more intuitive ways.
Some of the new style of interactions available in RIAs may be a little foreign to web users, and require some getting used to. I can say with authority that old conventions in a new setting can wreak havoc in a usability test, but I also feel that the accompanying richness and power can be worth the learning curve.
1.2 A few words about Web 2.0
I would be remiss if I didn’t explain RIAs in the larger context of Web 2.0. Web 2.0 has gained a following and notoriety approaching that of a cult. Although some may question whether everyone immediately needs to convert to “Web 2.0 Everything” to still be considered relevant, it is very true that the web this time around is different than the first time. It’s worth your while to investigate these differences as they are significantly impacting user expectations and how software designers are creating new products.
Here’s a quick overview of a few fundamental concepts behind Web 2.0.
1.2.1 Mashups
Mashups are an exciting new genre of applications, combining technologies in new and interesting ways. Programmers access open APIs (code from companies: Google maps for example has open APIs) or other public data, and play around. Online maps are a favorite component for mashups and have been wedded with lots of other technologies such as real estate, traffic reports, ski conditions – you name it.
Mashups can use other kinds of public data also -- news feeds, restaurant ratings, photo tags -- not just for creating software, but also creating art. The exciting thing to note here is that having this kind of data in the public arena is a great proposition for all involved. Artists, software engineers, and companies alike can access data for free. Public information can be used to disseminate knowledge, compile data in new and meaningful ways, and create communities around sharing information, advancing the web a little further.
1.2.2 Social Networking
Many new sites leverage relationships as a way to add value for their users, and it’s proving to be very effective. Friendster, Facebook, and Linked In are all about creating and maintaining relationships; sites like Flickr and Last.fm are ostensibly about other things (photos and music, respectively) but their social networking features are also a big draw, allowing their users to share with and keep tabs on friends. Obviously it’s a great proposition for the company too: since most sites require that users join to participate (the walled garden approach), members must recruit new members to expand their networks and take full advantage of available features.
A word of warning: social networks are not a “if-you-build-it-they-will-come” kind of proposition. Creating a networking feature set is a lot of work on both the front end and the back end. It also requires registration and other kinds of participation from the user, who may or may not feel the effort is worth the return. And without an active network, your site may look like a trendy nightclub with no one inside.
1.2.3 User-generated content
Web 2.0 found a good source of cheap help to create its websites… you! Web 1.0 was very top-down: “they” decided what articles were news, what videos were shown, what was “hot”, etc. Now “we” call the shots. We blog. We upload videos of our own making. We tag. We rate. And we add value to these sites that we interact with… all for free.
Put bluntly, user contributions can be a force of good or evil. Tagging almost seems de rigueur these days, but before you implement tagging on your site, go and take a hard look at tags on Youtube or a similar site. Some of the tags are helpful in finding relevant videos, but many of them are random, irrelevant or too general. Useless tags muck up an interface and frustrate users . Other warnings to consider: sites that allow user posting are often targeted by spammers, and people may upload or post things unsuitable for your audience or the mission of your site. Tread carefully with this feature set and be sure you know what you’re getting into.
Web 2.0 may seem like a lot of hype, but it has breathed new life into the web and gotten everyone talking again. Web 2.0 represents a state of mind and a shift in user expectations. Use it to your advantage.
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.
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).
Those close to me know about my close encounter with authorship last year. I signed a contract with a book publisher to create a book on designing rich internet applications, and managed to get about a third of the way through. It was what you might call a "learning experience" (if you love a good euphemism), but overall it was a labor of love. If you don't know the whole dramatic story, I can tell you over beers some night.
The book died on the vine, but I do want my hard work to be out there in some form. I've decided to publish the book as a series of blog posts, hoping that this can be of service to other designers. Enjoy!
