10 posts from 2008

3.3 Finding the where in here: getting back, starting in the middle and other snapshots in time
The Back button is a notoriously sticky issue with some RIAs, particularly Flash- or plugin-based ones, but it’s really only one part of the story. The deeper issue is deep-linking, or how to take a snapshot of a specific point in time in an RIA. In the HTML model, going to a new page means pulling down a specific set of data, all at once. In rich internet applications, the data is pulled asynchronously; a lot of little calls instead of one big chunk. As a result, creating a snapshot of the data to display when hitting the Back button or creating a bookmark is very complex, and may or may not involve discrete URLs for every view. Handling of deep-linking right now is wildly inconsistent across RIAs, partially because of the labor involved in creating a holistic solution and partly because no true standards have emerged.

To get a handle on why deep-linking is (necessarily) different from the normal process of capturing a bookmark or back state, think about your favorite desktop application and imagine it running in a browser. Think about what you would expect a unique snapshot to contain. How would I make a bookmark in Adobe Photoshop to share with a friend? When that friend opened the link would it show the file and all my palettes in exactly the state I left them?  Would it capture the history of my doc and support 10 levels of undo upon opening? Would it indicate the tool I was last using? Or would it concentrate on the finished product (similar to sharing a “file” rather than the interface)?

First let’s define what that snapshot could contain. Everything in an application can be boiled down to two types of edits: change to the view state and change to the data state. View states are changed when I manipulate the interface: click on a menu, slide out a preference panel, select a tool, etc. Data state changes occur when I tag a photo, fill out a form, change my profile, or anything else that actually edits data. Determining what to capture in the event of Undo, Back, Save or bookmarking depends on how much of these two states needs to be retained. Many RIAs are opting to capture changes in the data state without capturing changes to the interface. In that way the default view state is maintained, while the user doesn’t lose data. In other applications, the layout and interface customization is very important, and should also be retained.

There are many ways of creating (and faking) snapshots, but context is key. To find the right deep-linking solution, consider again what the user is trying to accomplish by in asking for that snapshot. Now let’s look at the scenarios that create a need for snapshots and talk about ways to address them.

3.3.1 Back button
As I said earlier about the Back button, when it comes to sovereign or plugin-based applications your best bet is to guide users away from it. I feel very strongly that the Back button paradigm is at odds with rich internet applications, and trying to support it will only encourage this unhealthy relationship. Ruthless as I am, I even believe that the slap on the wrist that the Back button doles out (Naughty user! Go back two spaces and lose a turn!) is helpful in teaching users about RIA behaviors.

That controversial statement made, if you do decide to include Back button support, there are a few guidelines to follow.  First, the more your application looks like a traditional HTML page, the more expectation from the user that the Back button will behave “normally”. AJAX implementations are harder to distinguish from their HTML environments, and tend to need more back button support. Web sites with a Flash application vibe will discourage Back button reliance.

Back button states (when supported) are often reserved for major changes to the interface, such as clicking on a section tab. The Picnik application follows this example, providing for a discrete URL for each major section and serving up the last view of that section.  ClickShirt also supports the Back button to move to the previous step in the process (from the buying interface back to the designing interface, for example).

Lastly, Back button use should never trump a Save action. If the user has saved data (for example, altered her profile information), this data should not undone by clicking the Back button. Be certain as a designer that you’re making a clear distinction to the user between undo or “previous version” and Back.

3.3.2 Saving
Many deep-linking issues can be sidestepped by designing clear and effective saving functionality with “cancel” and/or “revert” features. This allows users to maintain control of the data by canceling or committing to the edits they’ve made. Whether a save action is initiated by the user or automatically, it will provide clearer rules about what is available and when. Saving functionality evokes the familiar document-based model found on the desktop, which captures a view of the data on each save (usually overwriting the previous version). The data snapshot is more clearly defined and accessible to the application, and the user has a better understanding that the data state is what’s being saved, not the view state.
 
An added benefit is that by requiring saving you will alert users to instances where changes could be lost. Generally, navigating away from an area with unsaved changes (whether to a different part of the application or to another site entirely) should force the user to commit or cancel unsaved edits.

A nice variation on Save functionality is the version/revision history model. This allows users to access previous versions without fear of commitment. Although this can be offered along side a manual saving interface, it’s especially nice to see with auto-save. The application can capture various points along the way, without asking the user to save or discard those changes at every point. Most importantly, it provides no incentive for Back button use.

3.3.3 Undo
Earlier in this chapter, I mentioned that often folks reach for the Back button when what they’d really like is an “undo” feature. Undo actions tend to be much more granular than Back button actions, for example undoing text formatting versus returning to a different section of the application. Undo actions always have immediacy: they recall the last action performed and never need to retain information across sessions.

Try to identify possible points where users might want to undo. Undoing small edits is a handy feature to have, especially in an immersive application that supports lots of editing (such as a photo editing tool or word processor). In these cases offering an Undo button is a great idea. This is becoming more common, supported by keyboard shortcuts as well. Most users familiar with Undo in desktop applications will also understand that Undo is always related to a change in a data state, not a view state. It’s also standard practice to limit the number of undo actions, which again is acceptable from a user standpoint. On the development side, maintaining small version changes in the application is simpler that supporting a Back button, with clearer ground rules.

Sometimes a user would like to reverse a high-cost action. “Delete” is a classic panic-inducing action, which causes anxiety before executing and often incites swearing after. Many UI solutions have been created to deal with the finality of delete, solutions which could be adapted to other Undo scenarios. One method is fading out an item that has been deleted but not actually purging it until the session is over (offering a button in the mean time to undo the delete). Another route is to include “trash” functionality, which stores deleted items until the user manually purges. The simplest approach can simply offer a message to confirm delete (Are you sure?) with no Undo.

As applications become more robust on the web, designers won’t have the luxury of overlooking Save and Undo functionality. Users expect this in desktop applications and will be requiring it online in the very near future.

3.3.4 Bookmarking and sharing
People choose to bookmark pages for a variety of reasons. It’s difficult for the software creators to surmise what a user will want to bookmark and why, and thus it’s very difficult to build for it. Also, user’s mental model of the “page” in an RIA is still fuzzy, and there’s no obvious way to inform users what is bookmarkable. Take for example a basic HTML form on any site. A user could surmise that bookmarking would save the contents of the fields they’ve already entered (but haven’t yet submitted). Of course anyone who works in the computer industry would know that this isn’t the case in HTML, but why couldn’t it be?
 
I think the most defined and supportable bookmarking scenario is when a user bookmarks of a single bit of content such as a pair of shoes on an ecommerce site, or a specific article on a blog. In these types of sites it’s good to have discrete URLs for the final leg of the drill-down. This could happen in the typical way, through the browser, but the sentiment can be supported in other ways, such as wish lists, “save for later”, or other earmarking interfaces. You can also offer a way to get a URL even if that page wouldn’t normally exist in the typical application view: youtube for example offers a “URL” button on their interface for videos embedded externally on blogs and other sites. Not everyone will know what to do with that kind of a button, so use judiciously.

Ultimately, the decision to support bookmarking is completely subjective. Most likely, URLs will be created with other purposes in mind which will determine what someone sees when they bookmark that section. Try to make the user aware of the functions that support other bookmarking scenarios, such as saving a work in progress, recording an item I want to view later, or the sharing of content.
 
Sharing scenarios are a little bit different. Typically sharing with someone requires a characterization of a final output (a file, image or edited content), not the interface. I might want to send you a link to a shirt I’m thinking about buying, a photo of my cat, or a playlist I’ve composed. Guiding users to interfaces that are specifically designed for sharing crystallizes the purpose of the tool, both in the user’s minds and for the designer.
 
Because of the issues with bookmarking mentioned above, a user can’t simply copy a URL and paste it into an email. A few solutions have been created to get around this, but I have yet to see a completely clear direction that would pass the “mom test” (could my mom figure this thing out?). The most common solution seen lately is a Share button. The Share button usually presents a form in which the recipient’s email address is typed. It is generally understood that the user is sharing data in some kind of final output (not a view state), but the actual format of the data is often unknown to the sender.

Collaboration is a variation on sharing, but with a twist.  The collaborator will access the latest saved view, but typically with all interface elements in the default state. An invitation to collaborate is usually good for the life of that document.
I think the main trip-up to many application sites and sharing is the login process. People today are over-registered and leery of giving personal information away unless the benefits are clear. Creating a walled garden for all of your content may have its perks, but keep in mind a sizable group of people just won’t bother. How many unviewed pages are floating out in the world because the recipient did not want to register for an account?

3.4 Summary
Browser and HTML interactions, standards and structure have become deeply ingrained in our internet consciousness. But the times they are a’changin. The browser will continue to be a main entry point for online content, but as RIAs become ubiquitous, even the browser is going to have to give a little. In the meantime, we have an awkward middle stage, with users stuck trying to figure out if the site they’re looking at is animal, vegetable or mineral.

While this conflict plays out, continue your work as mediator, but don’t be afraid of a little tough love. The browser standards can be unnecessarily restrictive, and in some situations it’s best to declare loud and clear “this is a rich internet application!” and tell the browser to talk to the hand. Most of all, you must decide if the site is animal, vegetable or mineral and let the posture, look and feel, interactions, and workflow support that stand.
 
Now that we’ve put the browser in it’s place, let’s really shake things up by exploring new frontiers in RIAs and the possibilities of dynamic data.

3.2 Embracing the desktop: the new old paradigms
I have given a lot of space so far to browser paradigms and user expectations of them. Interaction paradigms can also come from the desktop, by which I mean both the operating system and also client-side applications such as Microsoft Word, Adobe Photoshop, etc.
 
Although I’m sure there’s a small contingent of computer users who connect in coffee shops and schools only to the net (and are subsequently oblivious to the desktop and client-side applications), I’m still going to make the sweeping generalization that most computer users are familiar with desktop interaction paradigms. They know to double-click on a folder to open, know that right-clicking will reveal shortcut menu commands, and know to drag a folder here or there to change its location on the hard drive. All of this knowledge falls apart on the web however, because of a change in context and the demands of the browser. Sure, many newbie users double-click impatiently on links and other objects, but through daily negative reinforcement they have learned this and other desktop interactions are a no-no.
 
The browser can stand in the way of many desktop interaction paradigms. One thing to always remember is that your application is subservient to the browser, and at times the browser is a cruel master. The browser can make the decisions about display options, rendering, keyboard shortcuts, and other things. And it’s difficult to map these obstacles because each browser is different (Firefox, Internet Explorer, Safari, etc.), there are differences between platforms (Mac, PC, Linux, etc.) and worst of all, the user may just decide to go ahead and tweak the preferences in a completely unique way (block popups, configure keyboard shortcuts, etc.).

Your application may have other masters too, and may need to adhere to other platform or plugin considerations. Flash is one application that can confuse browser behaviors. Some web browsers swallow the keyboard commands before they make their way into Flash. For example, Gliffy allows the keyboard shortcut for copy, but so does the browser.  The browser doesn’t know if it should handle a copy command itself or pass it to Flash, resulting in unpredictable behavior. Some embedded media players also have their own scripted behaviors that may or may not be at odds with that of the browser. Also consider what kind of instruction the operating system may be passing along.

There are many, many desktop paradigms to tap into, far too many to be covered here. Instead I’m going to focus on some of the current crop of web paradigms harvested from the desktop. Standards such as double-click, right-click and keyboard shortcuts can be employed in RIAs, but gently… very gently.

3.2.1 Drag and drop
I tend to separate what I see are two kinds of drag and drop. There is one kind of drag and drop that moves things about the screen. I can move cells in Excel this way, move a rectangle in Illustrator, etc. This is very spatially direct in concept, and I think easy for most to understand.

As a designer, you can create affordances for this kind of drag and drop by rendering things both in look and spirit as objects (for more info on objects, see Think in objects, not links, Chapter 2). Objects tend to have hard borders and drop shadows, along with the occasional dot pattern (to indicate a draggable area) that designers have come to call “grippies”. The content of these should be discrete pieces that users can easily visualize as objects: an email, a pair of pants, a vcard, etc. For the most part, it easy to indoctrinate your users on this kind of drag and drop, as long as your visual and interaction language is clear and your use is consistent.

The other kind of drag and drop, I consider an initiation action. This is when you drag something to another place to change its state. One example of this is in Gliffy, where I can drag an item from the palette onto my canvas. Clickshirt employs the same kind to move graphic elements and text onto a shirt design. This kind of drag and drop may, on the surface, seem to employ the spatial metaphor, but in reality this is a greater conceptual leap that users generally are not familiar with and will not find consistently among sites.

Encouraging this kind of interaction requires you to be far more explicit, including instructional text, visual affordances, and some kind of “undo” action if possible. Once the action has been completed, it is also essential that the change in state be represented somehow. Sometimes the target area can reflect the change, for example a shopping cart (of which the contents are hidden) may give a little “bump” feedback and change the quantity display. Or the item being moved may reflect the change. In click-shirt the button that is dragged to the canvas has a different look than the object that actually appears on the canvas. I love these kinds of interactions, but enter them carefully as they are not readily understood by most (and may be candidates for the cool-but-fluffy category).

3.2.2 Double-click
Double-click is absolutely second nature in operating systems. Most of the time the concept represented by double-click in this environment is “open”, “launch”, or some variation: open this folder, launch that application, etc. In desktop applications, double-click is not quite as standardized, but again refers often to “opening”, or perhaps ‘enable editing”. For example, double-clicking a symbol in Flash will let me edit its contents, and double-clicking on a folder in my mail client allows me to rename that folder. On the web however, double-click is simply not done. Users are so accustomed to an HTML world free of double-clicking that the thought never enters their minds to double-click on an object.
 
Examining double-click standards on the desktop and in client applications shows that double-click functionality usually does not have affordances, meaning there is nothing about a look of an object that indicates that double-clicking will yield an interaction. In very few instances, text will be visible instructing the user of double-click functionality, but often the way to learn about double-click functionality is by either just trying it or reading about it in the help docs. On the desktop this is forgivable because double-click is part of the genus of desktop interaction standards. On the web this discoverability issue is cause for concern.

I would imagine that as desktop and online worlds eventually collide, double-clicking will become ubiquitous (most certainly for the open/launch/edit functions). But in the mean time, it is an option that must be weighed carefully. Ask yourself if you can afford to hide key pieces of functionality behind a double-click, hoping that users will catch the scent. Would it be a wise use of space to create affordances for double-clicking? Better advice is to avoid it altogether for now. Many alternatives, such as rollover buttons leading to action menus are available, and more obvious for users
.
3.2.3 Right-click
Much of what I said about double-click can be said about right-click. It is something with which users are quite familiar, but with caveats. In client-side applications, users expect a full range of functionality available with right-click menus, functionality which is also replicated on the top menus of the application (Although some RIAs are incorporating top menus found in desktop applications, I don’t find this to be an appropriate navigational scheme. Top menus utilize space reserved for them by the operating system.  There is no such standardization on browsers or web pages). Real estate in web applications is always tight, so redundant controls are rarely found.

Also, users who employ right-click in a browser expect browser controls there (copy link, save image, etc.) Although you can put your own controls in there, there are a few pitfalls you should consider:

    • Creating “hit areas” for right-click is tricky and time consuming for both the designer and developer. All of the screen real estate needs to be divvied up and assigned controls. Areas which do not have your application’s right-click menu specified may either have browser’s default menu appear or you must suppress right-click altogether.
    • Depending on the technology you’re using, browser defaults may not be suppressed. If you’re directing a non-savvy user to employ right-click, consider whether that user will be confused by seeing under-the-hood commands like “View Page Source”.
    • If the right-click menu is not there, the browser may read the action as a single mouse click. Be sure if you include right-click that you have considered the “cost” of an inadvertent single click occurring in the same place.
    • Right-click commands must be duplicated elsewhere in the application
    • Mac users continue to be resistant to right-clicking, despite cajoling from the PC community

If you choose to incorporate right-click, but sure to create and affordance for it or provide some instructional help before it’s needed. Be sure that any items included in the menu are accessible elsewhere in the application.  And be patient: right-click’s time will come.
 
3.2.4 Keyboard shortcuts
Keyboard shortcuts or hotkeys are a feel-good feature on the computer. Using them not only saves time, but also gives the user a sense of proficiency with the application. Although it may not be the best way to impress your friends, learning keyboard shortcuts puts you a little closer to the expert category of user.
 
More and more applications are employing keyboard shortcuts on the web, especially those that can tap into users’ experience with existing desktop applications. Google Docs is one such example, evoking familiar applications (Microsoft Word and Excel) on the web. Anyone with a passing knowledge of those applications will instantly catch the basics of using Google Docs, and keyboard shortcuts are a way to support intermediate users of those applications as well.

Gliffy is another fabulous example for this section, successfully creating a desktop-like application on the web. Gliffy, in case you’ve never used it, is an online application that is similar to Omnigraffle or Visio, tools used to make flow charts and wireframes among other things. Although Gliffy is not as robust as the offline applications, it has lots of the goodness you’d expect from a desktop application, plus thoroughly modern features like online collaboration and publishing. Drag and drop, double-click and keyboard shortcuts are all well-integrated and promote a desktop feeling. I was surprised to find I had slipped completely into “desktop mode” and inadvertently used a keyboard shortcut... successfully!

Keyboard shortcuts really add to the efficiency of an application and help the user find flow in their work, but unfortunately this again is where our antagonist, The Browser steps in. In the example of Gliffy, I used CTRL+C to copy an item and CTRL+V to paste. That worked, and increased my confidence in hotkeys within the application. Then I click CTRL+B to bold some selected text. Slap! Instead of bolding my text, this opens up my bookmarks in Firefox. “Flow” down the drain. I’ve had similar shocks to the system when I’ve attempted to save a file I’m working on in an online application (CTRL+S), forgetting that I’m in the browser and am instead confronted with a saving interface for the web page instead of my document.

In these instances, there’s really nothing you can do to override the browser, but I still wouldn’t suggest throwing the baby out with the bathwater. All in all, I love having these features there for advanced users. Just try to familiarize yourself with the commands most hoarded by the browser (CTRL +D and CTRL +S for example are never going to be available in a browser) and look for obvious ways for your users to access those commands.

3.2.5 That Desktop Feeling
As you incorporate all of the above, keep in mind that “desktop” is also a feeling, a spirit, a vibe that the user may sense without really being aware of it. There is always a base-level of uncertainty present for users on the web, and I would be remiss if I didn’t point out that RIAs exacerbate that uncertainty to a degree. Steve Krug in his book Don’t Make Me Think refers to question marks floating above people’s heads when things are not clear. I see some of these question marks relating to the online experience at a base level. Am I connected? Is the site up? If I submit this form and it doesn’t go through, will I have to fill it out again? Desktop applications have their difficulties for sure, but for the most part allow you to attain a low level of zen knowing that at the very least things are stable and “on”.

Creating a desktop feeling online for your users means doing your level best to assuage all of those background fears. Minimize surprises for your users. Create a state of flow. Provide feedback on any action, and provide actionable information in the event of failures. Make all actions as low-cost as possible and give your users a back door to escape when they mess up. You can’t make sure their internet connection is always up, but you can design for the cases when it isn’t, creating a more stable and comfortable environment for work or play.

These are a few of the desktop standards creeping into RIAs, but there are many more.  Desktop applications are often built with different goals in mind than RIAs, but as connectivity and bandwidth become less and less of an issue, the boundaries between the two may be erased. It’s a good idea to be aware of the desktop world, and decide for yourself what other standards may be right for your project.

For as long as most of us have been using the internet, the way to view online content has been through a browser. The browser is its own application that has its own controls, standards, and behaviors that users now take for granted and employ almost unconsciously. Because of this, one of the most common reservations I hear from companies thinking about transitioning to RIAs is that RIAs break fundamental notions about browser behavior. They have heard controversy about the back button, and worry about the usability of non-standard browser interactions like drag and drop. They envision their users caught in the middle of an ugly conflict between the browser and the rich internet application inside. It’s a showdown at high noon, and only one can survive.

Of course, the demise of the browser would be greatly exaggerated. HTML will be a dominant standard for a while to come and browsers will continue to be a preferred point of entry to anything online, but web applications will become more and more prevalent. Our job as designers is to help the users navigate the inherent tension between the browser and the web app, treating it more like a conversation than a war. We need to make apparent to the user which party is talking and must be listened to, and allow the dialogue to flow naturally.

To that end, creators of web applications need to dissect the browser and understand when it can work for us and when it’s best to keep it on a short leash. We also need to look beyond the current HTML paradigms and draw from new sources, including an old friend: the desktop. When we do that we can make peace between the browser and its rich content.

3.1 Browser baggage: the back button and other relics
Since the inception of the browser a few basic controls have been consistently offered: a URL field, back, next, and reload buttons. All of them have the potential to wreak havoc with an RIA.

Browsers are explicit in their hierarchy. The application keeps its controls in the chrome at the top, which very clearly from a UI standpoint shouts “I am in control of this content!” In creating a rich internet application, we are asking the users to ignore this great big signpost, the controls that they have relied on for all of their internet lives. Trust us, we say, it’s better in here.

And I find that users are generally willing to play along… that is until something goes wrong. At this point they quickly activate Plan B: the browser controls. But in all likelihood the browser control will not do the expected, and will probably get them deeper into trouble. Now we’ll take a closer look at some browser favorites we’ve come to rely on and how to avoid their potential pitfalls.

3.1.1 Back/Next buttons
At some point in a conversation with someone new to RIAs, they’ll look solemnly at me and say, “Yes, but what about the Back button?” People are understandably concerned about losing one of the main tools of navigation through any website. HTML websites are structured to enable this use, and even make efforts to complement it.
 
RIAs on the other hand, do not have unique URLs for each view, and so even determining the meaning of “Back” is very tricky. Back to what? Back to before I adjusted this dynamic filter? Back to when I had that tabslider open? Back to when I was in the preferences section of the application? And sometimes the user doesn’t really mean “back” but instead “undo”, which is an equally sticky but conceptually distinct problem. Discouraging use of the Back button takes some courage, but will greatly benefit your users.

Depending on the level of complexity and integration of your application, use of the Back button can have a few different outcomes. In the case of a sovereign, plug-in based web application, the user may be popped out of the application entirely and back to whatever page they had visited prior to your application. Hitting the Next button at this point will bring the user back to the application, but probably at the beginning of an experience, waiting for the application to load. Yuck.

In the case of transient, AJAX, or smaller-scale integrations, or widgets in an otherwise HTML page, the user might click the back button intending to view a previous state, and instead ends up on a previous page. Clicking Next may cause them to lose whatever changes or additions they made to that state in the first place. Double yuck.

There are a variety of solutions to this problem, none of which is optimal or foolproof. The best solution of is to yank the user’s focus to the controls inside your application and hold them there. Communicate clearly throughout the workflow, minimize confusion at all costs, and clearly mark exits to any action. Carefully consider situations where the user might want to Undo something, which is a desire that frequently sends them reaching for the back button. It is also worth mentioning that creating the look and feel of an application versus a web site will steer users toward application-appropriate interactions.

Another somewhat sneaky tactic is to take is to remove browser chrome altogether, typically done by displaying the application in a popup. This will remove Back button temptation from the user. If the browser page consists of the application and nothing else, you might be able to get away with this. If you’re dealing with a smaller integration, an application that resides within an HTML wrapper, or an application that’s a subsection of a larger site, this option is not a possibility.
 
If back button is really something you want to support, there are ways to implement it and ways to fake it. Depending on the complexity of your application this can be somewhat simple or a screaming nightmare. We’ll cover all the ins and outs of this later in this chapter in “Finding the Where in Here”.

3.1.2 Reload
Reload has many of the same pitfalls as with the Back and Next buttons. Reload will bring a plugin-based application back to the entry point, starting at a loading animation. In AJAX implementations, data or UI features may be lost on reloading.

The main difference to consider is that users click Reload generally when they perceive some kind of performance problem. In a rich internet application, one scenario where a performance problem could be perceived is when the user performs a search and no results are displayed. If there is no feedback (loading animation, timeout or error message) the user may conclude that the application is stuck and hit the Reload button.
 
The key again is communication. If you are designing an application that allows users to customize data, be sure that you have designed the application in“no data” scenarios. When the user enters your application for the first time, they won’t have the robust data set your design is optimized for, so add instructional messages, sample data, or whatever else might help get the ball rolling.
 
Once the user is actually using the application, loading animations are a great way to create a continuous feedback loop and let the user know something’s happened after a click. Also be sure to consider all real failure scenarios as well. There are a number of ways to handle errors and failures (see Error messages suck, Chapter 2), but be sure to inform the user what went wrong and how to avoid it in the future. All of these tactics can minimize the use of the Reload button.

3.1.3 Popups
Popups come in two flavors in a browser: content popups that appear outside a page (presumably to help the user keep their place in the originating site or application) and dialog popups (modal or otherwise) that offer feedback messages, often on an application level.
 
Content popups have become the lepers of the internet, largely because of the proliferation of intrusive popup and popunder advertisements. But popups are a mainstay in the RIA world, to provide both a rich and contained user experience. Flash-based applications don’t have as much of a problem with popup blockers, but using javascript, DHTML or some other technologies in a popup will trigger blockers and could leave your users out in the cold. Also to consider:

    •  All browsers have different ways of handling popups and blocking
    •  Some users may have non-standard browsers that don’t follow convention
    •  Java may be turned off, blocking some technologies
    •  People often install software separate from the browser to block popups

One way to mitigate a poor experience where popups are concerned could be to include a message before the launch of the popup, something along the lines of “Application X will pop up in a new window. Please disable your pop up blockers to access the application.” (This is what I like to call “Strange behavior alert!”, pointing out a behavior that is not by any means my wish for the user, but that they should know about nonetheless). It also might be a good idea for the originating window to indicate that a popup was launched, in case the user didn’t see it or the blocker doesn’t identify when it blocks a page.

If popup blockers are a concern, be sure that you incorporate this issue into the initial architecture of your site. You may choose to change directions if it seems the risks of putting your application in a popup outweigh the benefits. Less savvy users may consider anything in a popup to be undesirable, and may not take the steps necessary to see the application. Nothing is as sad as a site unseen.

2.2 Creating a Flow
Flow as defined by Mihaly Csikszentmihalyi, identifies the state in which one ceases to think, but merely do, becoming so involved in and focused on an activity that everything else falls away. One can achieve flow reading a book, playing chess, running a marathon, painting a picture, or any other scenario where concentration is complete and consuming. This concept translates to software design as a state of total engagement in the workflow, thinking about the task, the creation, the content, NOT the software. Flow is a difficult state to achieve in anything, not just software. If an application is too rudimentary, the user may become bored, too difficult and she may become frustrated. Our goal as designers is to help users achieve flow, and do our best not to interrupt once it’s flowing.

As I sit here and write this in Microsoft Word, I focus on the words in my head, which fluidly translate to my fingertips. In these moments of flow, I’m not thinking about Microsoft Word, but rather my thoughts and my phrasing. When a squiggly red correction line suddenly appears or an autofill suggestion pops up, I find myself thinking about the software instead of my task. Both of these tools are useful to me, so I’m willing to put up with them instead of turning them off, but they are indeed flow breakers.

Rich internet applications absolutely empower designers to create that state of flow. When users can drag an item into their shopping cart (which uses a familiar metaphor of physical-world shopping), instead of hunting for a “Checkout” button, more thought is given to the task (shopping) than to the process (clicking a button). As you design, keep these principles in mind to foster flow in your applications:

2.2.1 Keep tools at hand
A good way to break flow is to send your user hunting for a tool. Sometimes it’s a button or function that the user knows is there, somewhere, but can’t find it. “Of course I can delete this email, but where is the button?” Other times it’s a deeper question of whether or not the tool exists and what it’s called, let alone where to find it. “I wonder if I can resize this picture? Where would I find a tool like that?” Providing these kinds of tools and information close by can shorten the hunt. The best kinds of designs, RIA and otherwise, support direct and local action wherever possible.

In the physical world, if you want to know more about the figurine on your aunt’s coffee table, you walk over to it, take a closer look, possibly pick it up (careful now!) and look at details like finish, manufacturer, artists’ name, etc. The same is true in RIAs. Tools and other contextual information can be revealed upon closer inspection, or upon interaction with the item. I call these localized tools. Luckily this is a great idea that’s catching on, and there are a hundreds examples of this on the internet, including inline editing, rollover buttons, auto-fill, tooltips, rating widgets, and on and on.

Localizing tools and information helps focus the user’s attention, resulting in more awareness of animations and other changes to the UI in that area. It also maintains a level of comfort for the user, knowing that necessary information and tools are always at the ready. This is the theory behind some other conventions from the desktop world, like right-click. As I will talk about in Chapter 3, right click menus have pitfalls on the web, but the sentiment of localizing tools is still an effective approach.

Obviously there’s a limit to the number of tools you can crowd into a small space. But before you shunt them off to a toolbar menu somewhere, prioritize the tools, and decide which ones are important enough to keep close by. And the other tools… if they’re not important enough to keep close by, are they important enough to keep? If the goal is clarifying the UI, the answer may be ‘no’.

2.2.2 Offer contextual help
A close cousin of localized tools is contextual help. Providing Help in applications is almost always under-considered and half-baked. Nine times out of ten “Help” for an application comes in the form of a tiny button in the corner that ushers you off to an HTML page that hasn’t been updated in a year. Not very flow-friendly. In really great applications, help is considered at the beginning, middle and end of a project and keeps itself in the context of the application. Providing help within the user’s field of attention supports flow.

RIAs offer some really neat and innovative ways to incorporate contextual help. One of these is tutorial help. This kind of help provides basic instruction about using the application, and often makes a distinction between first time use of an app and subsequent use. One example of this is a tutorial overlay, which is becoming popular. This is a somewhat transparent image placed over an application that includes high-level notes on button functions and basic tasks. This may be activated by the absence of a cookie (meaning the user has never viewed the application before) or may include a “Don’t show this again” type of checkbox for manual removal. I’ve also seen a surge in tutorial animations that appear on first time use. These can be very effective tools.

Another very popular form of contextual help is the tooltip, which is basically a block of informative text that is visible on mouse hover. Tooltips can be short and sweet, such as displaying a button’s name or function, or can contain lots of explanatory text or details about an item. This kind of interaction is really nice because it allows for a clean interface that relies on icons and other abstractions, while still revealing information for those who seek it out.
 
Inline messaging is a fairly new interaction type for the web that’s gaining ground. These are little contextual clues to the completion of a task, such as character-counters on fields with character limits, simultaneous feedback on form fields such as password, auto-suggestion and auto-fill, and status messages such as “your email has been sent”. I often see poorly executed examples of inline messaging, but I’m still really happy that people are going to the effort.

The usual design rules apply here of course, that messaging is clear, well-written, and supports flow. A caveat to the design of inline messaging is that you must also design a way to return to a neutral state. This can be accomplished manually, via a close button, or automatically by querying the back end for a status change that will prompt the interface to change back to neutral. Whether the message is related to status or an error, it will become irritating if it’s visible beyond its usefulness.

Aside from these types of contextual help, there are lots of other little helper fairies tucked into nooks and crannies of applications ready to do your bidding. Mini-calendar widgets are sent from heaven – how did we ever survive without them? Progress bars let the user know how much longer they must wait. Display of “number of steps” in a task informs the user where they are in the workflow. Adding user aids in context will keep your users happy and focused.
 
2.2.3 Error messages suck
Error messages and other dialogs break the flow every time. I know from experience that the reason users are often confronted with cryptic error messages is that designers tend to design for rainbows and sunshine. We envision what our application will look like in a perfect world, full of data and intermediate users and warm fuzzy feelings. But since developers by contrast always prepare for doomsday, it falls to them to create messages and dialogs for the failures they encounter while coding. It’s a little bit harder, although critical, that designers step back and design for the less optimal use case.

As the old adage goes, an ounce of prevention is worth a pound of cure, so at this point I will talk about some of the causes of error messaging in RIAs. With the emphasis on states in RIAs, messaging can get even more confusing. There may be many areas in your application with which users can interact. If an error message comes up, is it clear which area is causing the issue? I have often employed tabsliders to group information, and struggle with this frequently. The user can either have the ability to change focus to another tabslider (and risk later seeing an error message for data in a tabslider that is not open), or the contents of the tabslider must be validated (and the application is locked down) before the user moves on. Neither is really the optimal case. It is no small task for the engineers to create all of the scenarios in which the application is locked down until an error is corrected.

 
And at what point does the application query the back end to validate and check for an error? A familiar example of this is a traditional HTML form, in which fields are not validated until the “submit” button at the bottom is clicked. At that point the user gets a message that the format is wrong on the phone number, or they forgot to fill in the “city” field. Now we are seeing more real-time checking on forms, as in the password example above, but this results in a very chatty application and can be a very processor-intensive route to take.
 
Since RIAs are constantly loading data, images, etc., we also have to design for timeouts or failure to load. On some applications these take the form of a modal dialog (Video failed to load: click OK), but this seems unnecessary. Sometimes an error message can come in the form of an icon, as seen on HTML images that don’t load, or inline text.

Since some error/confirm messaging is unavoidable, there are a few techniques to ensure that they aren’t quite as jarring for the user. If you choose to incorporate modal dialogs, reserve them mainly for error messages, and go easy on confirmations. Modal confirmations should be reserved for somewhat high-stakes actions (Are you sure you’d like to shut down the electrical grid for Northern California? Yes/No) Write the explanations to clearly identify both the problem and the solution (and if this is not a strong skill of yours, hire someone suited for this), and be aware that although you’ve named buttons and functions in your application, the user may not be familiar with your vocabulary. Present clear options on your buttons using verbs instead of affirmative/negative words. I would rather see four or five words on a button that explain exactly what it does, than to see yes/no buttons and have to read the explanatory paragraph three times just to be sure I understand the action I’m about to take.

A problem with modal dialogs is that they often cover up the area in question. The new thing lately is to make them draggable. This feels like a bit of a band-aid solution to me, but if you go this route be sure that the window cannot be dragged off the screen. And on a visual note, be sure that the interface clearly reflects a modal state. The most popular way to handle this is to give the background application a slightly opaque cover which mutes the appearance and allows the dialog to stand out. Adding this cover will also illustrate which actions may still be accessible, such as global navigation or logout.

A new take on the modal dialog box is what I call transitional dialog, which is prevalent on Facebook among other applications. A dialog box appears with a confirmation message, but then fades away after a few seconds. I like this approach because, although it does break the flow, it doesn’t force you to interact. Avoid placing buttons on these dialogs or the user may feel like he’s in a game of whack-a-mole.

Inline messaging is probably the best answer for a variety of situations, because it suggests making a change without forcing it. It can be a way to lead your horse to water without making him drink. The right messages in a friendly tone can encourage learning and prevent the appearance of true error messages. Again, they require more conversation between the application and the backend, and you will need to design a way for the user to return to neutral state, but these are well suited for the kind of low-level explanation that is often needed in applications.

Lastly, I want to say here that I think there is great opportunity for innovation in the area of error messaging and dialogs. Just because they’ve taken the form of a little window for the past 20 years doesn’t mean that’s the ideal situation. I could envision dialogs of the future incorporating animations, or actually pointing to the error in question. Use your imagination (and then find a developer willing to go on a lark with you).

2.2.4 Fun! Fun! Fun!
I’ve saved the best for last: enhance flow by making your application fun! C’mon, who doesn’t like fun?? Fun software may sound like a contradiction in terms, but I think there’s an opportunity to make any application fun, event if it’s check-balancing software. As a matter of fact, check-balancing software could probably benefit the most from the addition of fun to keep people engaged, learning and satisfied.

Before I proceed, I have to make a couple of clarifications. First, I see a difference between “fun” and “clever”. Clever can sometimes come off as sarcastic or ironic, and clever wants you to know that it’s a little bit smarter than you. Clever gets very old, very fast. Fun, on the other hand is universal, multi-generational, pure. Fun is a good feeling and fosters loyalty. Secondly, fun should never stand in the way of usability (or then it’s not fun, right?) and should still be respectful of the tasks that need to be accomplished. Never lose sight of basic design tenets while enriching your UI with a little fun.

That said, the obvious place to seek inspiration about fun interfaces is games. Gaming inspires a variety of feelings that, for some reason or another, humans think are fun. Some of these feelings, like “adrenaline surge” and “blood-lust”, we’ll leave to the design crew of Grand Theft Auto. I will cover a few of the more innocent qualities found in gaming, such as competition, sense of accomplishment, surprise and wonder.

Sometimes competition can be fun, tapping into a users’ competitive streak or desire to be on top. Certainly social networking sites such as Facebook and Linked In foster competition among their users in the collection of friends or contacts, with the number collected in prominent display. Linked In goes even further these days by incorporating a “Best Answer” feature in its forums. If someone selects your answer as the best answer, you are then declared an “Expert” on that topic. Way to fire up the alpha dog.

Another closely related feeling is a sense of accomplishment (which is basically competition with yourself, achieving a personal best). On a holistic level, this can be fostered by a UI that allows users to become intermediates or experts quickly. You can also encourage this sense of accomplishment by providing steps for your users to complete, or levels to attain. Again, Linked In has a good example of this with their “Profile Completeness” meter that is designed to motivate you to collect more recommendations and contacts. Ebay has its “Power Seller” demarcation (with many levels therein), which I’m sure is fosters a sense of pride in sellers.

Surprise and wonder are two attributes that rarely have positive connotations when in the context of software. My definition includes discovery, exploration, and finding something unexpected yet delightful. Tread carefully here of course, but try to include a sense of lightness and humor where possible. Surprises in the form of Easter Eggs, or hidden interactions, can be a fun way for users to spend a little extra time with the software. I’ve seen sites where mousing over the company logo animates it in a fun way. Sometimes a seemingly random connection can be surprising and funny: Adium, an Instant Messaging software for the Mac, is personified inexplicably by a duck, which quacks when there are new messages. It very cute and funny, and I can also turn it off when the joke’s worn off.

Another way to incorporate surprise and wonder is to give the interface anthropomorphic or physical-world properties, or to add a little flair to animations. I’m not entirely sure why, but giving objects weight, momentum, and other physical-world properties makes the interface feel fun and inspires people to gawk. And anything that goes “boing” is sure to be a hit. I mentioned earlier the cute little dog-like shudder on the Mac login screen when an error is detected. The “genie” effect when a window is docked is also very cute and engaging.

Lastly, fun is a mood that can be expressed by your software’s visual look and feel. This look can range from friendly to downright silly. Big buttons and friendly colors create a sense of fun, as do unusual shapes. It may be difficult to advocate for a fun interface when being stared down by corporate, buttoned-up style guides, but a fun and friendly interface can enhance users’ comfort with the software and possibly even inspire loyalty.

2.3 Summary
RIA, non-linear thinking does not come naturally to most, in fact sometimes it can make your head hurt. Understanding the conditions that are necessary for good “rich” design, both in the way you think about your design and the environment you offer to your users is essential to capturing the fluid feel of RIAs. Now that we have knocked down the barriers to RIA thinking and built up methods to encourage flow, we can turn to the next obstacle, this one wily and formidable; the browser.
 

I have talked about the inherent differences between traditional HTML sites and rich internet applications, but what may not be completely obvious is the different mindset required from the designer and the need for a different holistic approach to designing the user experience.

HTML thinking results in a particular kind of workflow, both in the way it’s designed and in the way a user interacts. It’s a hard habit to break. If you have a history designing for HTML, you may have traditionally focused on creating a clean linear path for your users to complete tasks, and your goal has been a direct and efficient user experience, often traveled via forward and back navigation. If you’ve been doing it for a long period of time, you may have a little toolkit in your head of web standards and conventions, at the ready. Conversely, in designing a rich internet application, the focus is on creating a fluid environment for an immersive experience. Your linear path now has wormholes, and you need a whole new toolset and strategies to design for them.

In this chapter I’ll show you how to convert to “RIA thinking”, pointing out the differences between designing for HTML and for Web 2.0, and discussing new paradigms along the way. I’ll also show you how to encourage a state of flow or deep immersion from your users, something that was difficult if not impossible in HTML applications. Getting these basics down will give you a new-fangled toolbox to make designing a little easier for you and more enriching for the user.

2.1 Thinking in RIA
You’ve seen the slick, flashy sites out there that are making the rounds. Some neato fly-out menu catches you by surprise and you say, “Oh, now that’s cool.” But the first time you sit down to design something similar, you may feel like you’re at the mental equivalent of your first yoga class. Suddenly you’re required to design for things are moving around and interacting with one another, for multiple workflows happening simultaneously, and for a page that never refreshes. Your brain just doesn’t bend that way... yet.

The first step to “thinking in RIA” is to build a voracious appetite for RIAs. When I first started designing RIAs, I really had to hunt around to find interesting UI on the web. Now not a day goes by that I don’t see some amazing work to keep me motivated. Tuning in to tech blogs like TechCrunch and ZD Net, among many others, can put you first in line to hear about and see new applications. Sign up for every beta launch you find, and keep track of upgrades to older online applications. Also, stay abreast of trends in desktop software, taking careful note of animations and workflows. Immersing yourself in the application world will help you make better judgments about what works and what doesn’t… and I won’t tell if you lift a few ideas for your next project.

Once you’ve done some research you’ll realize that a fundamental shift has occurred in what appears on a webpage and how the user interacts with it. Here I’d like to point out some key differences between HTML and RIA thinking to help you change the mindset:

2.1.1 States, not pages
On a basic level, the mental model for any HTML site is a book, and the views are pages. I can go forward or back through the pages, bookmark a page that interests me, skip to a different page in another part of the book. Thus, when I create an HTML experience, at any given time I’m really only focusing on the elements of a particular page, or how to navigate between pages. In RIAs, the focus is on states instead, little moments in time or views of data that communicate change in the application, yet aren’t easily referenced by a page number. States are generally defined in relation to an action, focusing on the areas of change, not necessarily the entire screen.

Flickr has mini-applications cordoned off in its “Organize” section which help users organize photos, create photo sets, plot photo locations on a map, etc. In the “Batch Organize” application, I may select multiple photos in my library and move them onto the palette. The selection of the photos is a state, the dragging is a state and the dropping is a state.

UI needs to be considered for all of these, even though the content or the URL of my “page” hasn’t changed. Bill Scott of Yahoo terms these “Interesting Moments” and has contributed to a wonderful document available online that catalogues Yahoo’s experience with states. It’s definitely worth checking out.

Thinking about states instead of pages allows you to design for an application that may be somewhat of a moving target. In HTML sites, there are no surprises – every page has a design, and every layout has been hard coded. In RIAs often the user can interact with many things on the screen, leading to an infinite number of configurations. Some of these configurations you may never have thought of, much less documented.

Initially, page-based thinking is the hardest hurdle to overcome when designing RIAs, but designing modular pieces based on states will ensure that the interaction flows smoothly. Enough research and practice will make states a natural part of your toolset.

2.1.2 Think in objects, not links
I remember learning Apple BASIC when I was in junior high, and vividly recall spending a whole class period “programming” to get my name to repeat all the way down the screen, in rainbow colors (and this was considered an “advanced” task). No wonder I avoided computers like the plague for several years.

BASIC and other command line interfaces work in a layer of abstraction, requiring that the user be fluent in a programming language to accomplish even the most basic of tasks, such as “moving” a file from one directory to another. People who have learned these languages have no problem using this kind of interface to alter and manipulate files on a hard drive, but the rest of us need a little help (with a shorter learning curve). Then came the GUI or graphical user interface, which created visual representations or objects of those files on the computer and allowed you to act on them in ways that were more intuitive, and similar to the physical world. Now instead of changing a file location via a command line interface I can drag that object into a folder, easy as pie.

Finally we are seeing the object metaphor bloom on the web. In my Flickr example, the photos are objects. The thumbnail of a photo represents that photo and all of its characteristics (the metadata and any other information I’ve added such as name or description) and I can manipulate those objects in a number of ways. I can multiple-select, add metadata, drag and drop into a group, delete, and more.

Now we have a chance to extend that metaphor even further. One example of this is Laszlo Systems’ product, the Laszlo Webtop, which features “smart objects” that group information and allow communication between applications.

Imagine finding a photo you like in Flickr and dragging it off that page and right into a chat window. Dragging this photo does not merely copy and paste an image into a chat window. The image is still an object and retains its metadata, meaning I can double click and see the originating Flickr page or use its embedded data.

On a side note, the repackaging of data in mashups and the proliferation of aggregators (applications that compile information from external sources, such as blog- and feed-readers like Bloglines), mean that the ability for data to keep some grouping or identity is going to be increasingly important. Objects will eventually be shared across sites, applications and beyond.

In summary, creating objects lessens the abstraction of manipulating data on a computer. Objects keep data grouped and allow users to manipulate it in more intuitive ways, rounding out the user experience.

2.1.3 Map the space
Space is such an important element in an RIA that it requires careful consideration, right from the very beginning. A visual designer may be skilled at creating a space that is uncluttered with a clear visual hierarchy, but the interaction designer must be making fundamental decisions about location, how many items are visible at one time, direction of movement in a workflow, and more. Organizing the space well is a way to streamline the workspace, focus attention and enable a workflow. And as the user may navigate within one environment/page for their whole session, the stakes are definitely high.

Layout is very much a key element in my brainstorming. Although this has something to do with typical eye movement patterns and visual hierarchies, it really is more related to establishing a workflow. Poorly considered spaces are often unusable because of an uninviting environment for carrying out tasks. When direct manipulation is allowed, such as multi-select and drag and drop, where an item resides in relation to the task flow very much impacts usability. Layout planning involves navigation elements, objects or groups of objects, drop targets like shopping carts or photo albums, lists of data, and many other items. Giving things a home in your design takes a level of abstraction away, and will surface UI problems more quickly to allow you to deal with them. And don’t forget the space for advertising!

Many applications leverage a pattern we’re used to seeing, in email clients and other applications, called the Three-Panel layout. This layout shows progressive granularity of information, and is familiar to most users. Even without “panels” per se, this kind of layout displaying larger groups of information on the left and details on the right is also typical of navigation schemes. In creating a photo application, placing albums on the left and groups of photos on the right, can tap into a familiar pattern.

If you are designing for multiple windows inside an application, such as a dashboard, you should consider those constraints from the beginning. If an application has multiple windows, they may either be z-ordered (able to overlap each other) or part of a liquid layout. In a z-ordering scheme, the design must ensure that information is not lost behind a window. Inner windows are often resizable, which means the data inside must resize accordingly. Sometimes it’s best to offer only one size for these window, or a large view and a minimized one.

Liquid layouts (in which resizing the browser window appropriately resizes all browser content) are certainly cool but can be a nightmare to design for, introducing a whole other set of variables. As a designer you have to consider what the data will look like at a variety of sizes and when the data should be cut off and scrollbars appear. Be sure to account for all controls and navigation at smaller and less optimal sizes as well.

Often designers must deal with organizing and minimizing the overwhelming amount of data and actions offered at one time. One of the tried and true tools for creating a compact layout is hide/reveal info. This can take the form of tabsliders (accordions), drawers and rollovers, among other things.

 

Obviously, being able to conceal information when it’s not needed reduces visual clutter, but it can also be used to guide a user through the workflow. This is a tenet of “task-based UI”: if only things related to the task at hand are visible, there’s less opportunity for confusion. If a user chooses to reveal a different set of information, that may indicate she’d like to embark on a different task, and the view of the application may change accordingly.

RIAs are geared toward offering lots of tools/options/data at once, so wise use of limited real estate is essential. Although it’s easy to gloss over quantity, size and placement of items during the preliminary design phases, considering these issues early on will save you headaches later.

2.1.4 Animations are a force for good, not evil
Whenever someone refers to a site as “sexy” I just know by now that the site has animation. Although I personally don’t advise using that adjective when describing a website, I will admit that when people call a site “sexy”, it’s a compliment. Animations create a feeling of modernity and freshness, which definitely enhance a site’s “cool factor”. But the medicine in the jelly is that animations can actually be good for the user experience. When used to indicate transitions, changes in states, or to provide UI clues, animations can clarify the interface and become powerful part of RIA thinking.

There are many kinds of animations, but almost all of them contribute to a continuous feedback loop. On an HTML site, clicking on an item produces what I call the strobe effect: when the lights come back on, things look different every time. After every click, the user must reorient themselves first with the page overall, then identify the elements that have changed. Providing transitional animations, by contrast, keeps the user from losing his bearings by indicating a change before, during and after it happens.

One of the simplest and most effective animations is the fade. When an item is moved, deleted, or altered in any way, showing a slower transition from one state to the next is highly useful. 37 Signals gained some notoriety for their “yellow fade technique” but this type of transition is becoming ubiquitous. I’m particularly delighted to see it on lists of data while being filtered. On some AJAX implementations where no fade is used, it’s difficult to notice when items are removed in filtering, especially if the user’s attention is still on the filters when data is removed.

Another type of animation is ghosting, which is typically used for drag and drop. The item being dragged changes in opacity to become almost see-through, and very clearly conveys what is being dragged and to where. There are a few issues with this technique, however. The dragged item may obscure the drop target if the item is too large or too opaque. Counter this issue by either converting the dragged item to an icon while being dragged, or take the opacity of the item down significantly.

Yet another type of animation is animated feedback. This type of animation is fun and often takes on an anthropomorphic quality. One example is the “bump” that I first saw in a Laszlo ecommerce demo from 2000. When the user clicks the button “Add to Cart” the tabslider containing the shopping cart “bumps” a couple of times to indicate that it has received the item. Another example that makes me giggle every time I see it is the Mac login error. If I type in an incorrect password, the login window shudders for a brief second, kind of like a wet dog shaking out the water.

Lastly, and for lack of a better name, are the "Hey! Over here!" animations. These animations call attention to a UI feature that may otherwise go unnoticed, or to the next step in a multi-step process. At times I have specified a periodic glimmer on a button to put it back on the user’s radar. A well-designed drag and drop interface often includes an animation on the drop target, such as a subtle glow, to indicate where an item can be dropped. Subtlety is definitely key in this one, otherwise you risk emulating one of those obnoxious banner ads screaming to improve your credit score.

Although I will cover animation deliverables as part of the design process in Part 2, I would like to offer a few pointers here as well. Like most interaction designers, you’ve probably never taken an animation class or created one, and are unsure about how to convey an animation to the client or development team. There is a lot of nuance to animation that may be lost if left to chance. To that end, it’s helpful to have the barest of Flash animation skills, especially if you work in a small design team where visual and interaction design role distinctions don’t exist. Better yet, enlist the help of an animator, a visual designer with animation skills, or someone who knows Flash well enough to mock it up for you. You may describe it and hand it off, but be prepared to review frequently with the animator or visual designer and later, the developer. If you don’t have access to someone with those kinds of animation skills, find a similar example on the web to convey your idea about how animation should behave.

2.1.5 Mighty metaphors
The ability for direct manipulation in RIAs allows users to tap into what they know about the physical world and apply it to the virtual world as a metaphor. If I’m allowed to drag and drop an item into my shopping cart, that aligns with how I would go about the task of shopping at a brick and mortar store. In this instance, the shopping cart is a great metaphor for a group of items I’m preparing to buy, even though such a thing is certainly not necessary (or most efficient) from a programming standpoint.

Metaphors can be visual, interactive or simply in name, and they supply short-hand information about how to interact with an item or its purpose. For example, folders on operating systems are a metaphor that has served the computer world well, instructing us to group files together in the way we might in the physical world. This metaphor is buttressed by a second metaphor, drag and drop, which allows us to move the files manually into the folder as in the physical world. Photo albums and playlists help users understand how to group their photos and music without ever having used a similar site.

Some new metaphors are emerging on the web. Bubbleshare has a magnifying glass metaphor for its zoom feature; one drags the glass over the picture to zoom. The success of this interface is debatable. Although less literal, I have used the magnifying metaphor to signify an area of an application where details about an item can be viewed.

Sometimes metaphors tap into inappropriate or redundant paradigm. For example, many web-enabled VoIP telephone applications harken the traditional telephone by providing a keypad. Not only is it unlikely that people will dial with a mouse when they could type, but also the orientation of the numbers on a dialpad are opposite that of a 10-key pad on a computer keyboard. That’s just confusing.

I love metaphors, but they are like salt. If you use a small amount, it can enhance the flavor of your application. Too much and it will be unpalatable. This means that a metaphor should never get in the way of functionality, and should never be carried too far. If all desktop folders had to be opened by dragging open a corner of the folder and literally moving documents out one by one, that would be a ridiculous extension of the metaphor. This applies to naming metaphors as well. To calling the community section of your site the “Town Square” may be folksy, but it muddles the meaning. Exercise restraint.

2.1.6 Plan performance
Certainly performance has been a consideration with HTML, so much so that many sites and browsers once offered “text only” functionality to cut down on image loading time. The advent of larger pipes supplying heftier bandwidth means that fewer people are tapping their fingers waiting for images to load, but the tech world still seems intent on testing the limits of their patience and the volume of the data pipes. Instead of waiting for an image to load, people are now waiting for video, for Flash animations, for large, data-heavy RIAs… it’s like a weird variation on Parkinson’s law: the larger the pipes get, the more data we will stuff in them until they slow to a crawl.

The good news and the bad news about RIAs is that they tend to do a lot of preloading. Launch of a sovereign application usually requires a wait time while the application loads because, while sovereign applications cut back on page refresh during use, they require that a large chunk of the app to be loaded up front. For that reason, RIAs are not always the best choice for developing or outlying areas, or communities known to be on slow connections or dial-up. In my world, where everyone is connected to the Nth degree, we often overlook the fact that we are a small minority.

Besides the initial loading, RIAs have built a following by anticipating user needs with other types preloading. Google maps is a great example that could have come about 10 years ago. The window that shows my map is only one ninth of the map that has been loaded. When I drag the map, the experience appears fluid because the map has loaded non-visible areas, anticipating my needs. Applications can also perform a type of preloading called paging for long lists of data. On the Laszlo Webtop, if a Contacts list has 5000 names in it, that application will not automatically load all 5000 on launch. It will load the visible set plus a “page” more (that number determined by the team). It will fetch more names as scrolling begins.

There are a few other scenarios that can cause performance to take a hit. One is redraw. If I can drag a window or other item across the screen, the computer has to create a picture for every step of that journey, essentially drawing cels like an animator. Especially on larger items or windows with lots of data, this can eat up a lot of processing power. Another issue is chattiness, or when the application constantly needs to talk to the back end. For example, it would be ideal if an online email client knew the second an email arrived and then displayed it in my inbox. The reality is that constant communication and polling for data (Any mail yet? Any mail yet? How about now? Any mail yet?) makes for a very chatty application and slows performance. Instead, applications often ask for data at determined intervals or rely on the user to manually perform the request (for example, the “get mail” button in an email application).

As a designer, you can and should design for performance. Think about the data retrieval process while designing, and identify potential sticky spots. Work with developers to specify where preloading and paging can occur, and add loading animations where appropriate. Imagine your application on the slowest connection possible and consider how a screenful of loading animations would impact the user experience. Above all, be flexible. Sometimes a really cool interface item will weigh an application down, and you’ll need to cut it loose.
 

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.
 
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).
 

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!