Chapter 2: Changing the HTML Mindset (Part 1)
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.
