Sho Kuwamoto

1. RIAs should embrace the idea of "selecting" things.

Being able to select things is really important in desktop apps. You can't do anything in most apps without creating a selection. Selecting things is how you tell the computer what you care about. On the web, selections virtually don't exist. To select pieces of mail on yahoo, you have to click on a checkbox next to the piece of mail. Ugh.

fig. 1 - In this view, I am tempted to select things, even though there are controls in each item. Don't they look almost like icons? Wouldn't it be great to tweak this design so you could drag select five things and click "add to wish list"?

2. Come up with a consistent way to let people know what actions can be performed on selected things.

Computers were created to perform actions. The web, meanwhile, de-emphasizes performing actions and blurs the line between actions and navigation. On the Web, there are no menus or toolbars, only links and buttons. And yet the Web is the most successful app delivery platform known to man. Go figure. I think we can improve on this. All RIAs look different, but to be usable, I think we should aim to be consistent in how we show available actions. This could happen by fiat (e.g., UI guidelines) or by evolution and consensus (e.g., nav bars on websites.. remember the early days of the web when every website looked different?) Why is this important? Imagine what would happen if desktop apps didn't consistenly use menubars, and every desktop app had a different way to show you what actions were available. Ack!

For RIAs, we could expose actions as menubars, toolbars, context menus, navbar-like things, or something entirely new. I almost don't care which way we go, but if everyone does things differently, it will be that much harder for people to understand the basic operation of each app they come across.

3. Working with documents in a "one screen" app is hard. We need a way for users to conceptualize "documents".

Intranet apps often deal with documents of one kind or another (think order tracking, CRM, etc), and they are often a pain to use. In general, people who put together internal applications don't have the luxury of having design gurus on staff, and I think the impoverished UI vocabulary of the Web makes things worse, especially when it comes to dealing with multiple documents. Flex can change all that. "One screen" apps are inherently mysterious when dealing with context switching. When you work with multiple documents in a desktop app, they open in multiple windows. When you deal with multiple documents in a web app, you often lose context as you go from an index page to a specific document, or from one document to another.

I believe we can take a lot of the mystery out of it by creating a few simple rules for how to visually communicate the concept of multiple documents in a single screen app. One product I worked on that accomplished this well is Contribute. It's a desktop app, but all work happens in a single screen, and the product does a good job of giving the user a sense of what documents are being edited, and what state they are all in.

fig. 2 - The wrong way to represent "documents" within a web app. Documents need to feel physical, which means that they need icons and you need to be able to select them. This looks more like a report. Furthermore, when you drill down into a particular document, the list goes away so you lose context. BTW, there are other documents on other tabs in this app (in en route and completed), but some people never find them.

fig. 3 - Contribute is a one screen app, and they have found a good way to (a) work with multiple documents, (b) provide a space for actions, (c) provide contextual information. The list of available documents is on the left, and the contents appear on the right as you select them. All of these UI ideas would translate well into Flex. For larger, more process oriented apps, the documents on the left could be grouped in user-defined groupings ("Travel expenses") or app-defined groupings ("For my review", "Awaiting approval").

4. Managing space is important; screen real estate is expensive.

Managing space usually means packing more information in less space. In some shops, managing space may also mean using negative space to guide the eye. In any case, space is important.

HTML-based apps already surpass desktop apps for incorporating design into applications. They're like a cross between catalogs and applications. RIAs can take this to the next level because (a) you have much more flexibility and control over design, (b) you can pack more into less space by relying on interactivity, and (c) you can give the end user more control over how the screen space is to be used.

fig. 4 - This is Zagat's new site. It's beautiful, but isn't it a bit frustrating how little space there is for each section? Wouldn't it be nice to resize "Cuisine" to take more room if that's what you are interested in?

fig. 5 - In this case, I believe the best way to use the space would be to use an accordion, although a panel group would also have worked well.

fig. 6 - Callouts and tooltips are a great way to pack a lot of information into a small amount of space. By default, Flex uses these for form validation errors, but we don't give any guidance for other ways to use tooltips. Should there be a more general guideline for when to use callouts and tooltips?

5. Getting rid of page refresh is not about the blank white screen; it's about reducing the number of steps to accomplishing your task!

When people talk about page refresh, they're not talking about screen flicker. I bet our customers don't even notice the blank white screen anymore. If you took any of the popular sites - Amazon, eBay, etc., and did nothing other than get rid of the blank white screen, no one would notice. The flash of white between web pages is like the dial tone of the web. It's almost reassuring.

When people complain about page refresh, it's really about losing continuity (where am I now? what happened?) and losing time (why do I have to keep bouncing around between pages?).

Case in point: In the early days of Amazon, you had to go to a separate page to rate each individual product. Now, you can do it all on one screen. What used to take lots and lots of steps can all be done from a single page. What used to take minutes of back and forth now takes seconds. As a consequence, I now rate a bunch of things on Amazon whereas before, I never did.

6. Direct manipulation - This used to be the buzzword for desktop UI. Why isn't it the buzzword for RIAs?

There are lots of opportunities for us to add direct manipulation to the web. Unfortunately, some of them are gimmicky. For example, asking people to drag things into a shopping cart is a bad idea.

One obvious use for drag and drop is for rearranging things. There are lots of times when the user needs to specify the order of something. Rearranging might be the end goal, as in a photo album, but just about any list that the user creates is something that potentially needs rearranging. It might sound trivial, but I think these kinds of broadly applicable ideas are the most powerful. "Always allow the user to rearrange any lists that they create themselves" would be the slogan, and the framework should make that easy.

7. Provide feedback to help users make sense of the network

Apps on the web have the potential to be confusing because there is a server piece and a client piece.

Generally, people have figured it out for HTML: everything happens on the server, not my local machine (i.e., I can visit the site again from any other machine), except that sometimes, I need to log in again or redo some stuff.

In HTML, the blank white screen tells me that the website has been contacted. This tells me that my instructions have been sent to the website, or that new information is being downloaded.

Ironically, RIAs have the potential to make this world more confusing if we are not careful. Without guidelines for user feedback, we may not know when information is being submitted to the website (is it really looking for my flight info?) or when we have received new information.

At the very least, you should consider giving the user an indicator when something has been updated on the server. You would never think to change someone's password without saying "password changed". But smaller updates may also merit feedback. Ironically, the smaller the change, the more unsure you are whether anything happened.

fig. 7 - Take a look at the Amazon star rating widget. As soon as you click on the Amazon rating widget, it tells you that it has saved its info, which is very reassuring.

Summary

RIAs are incredibly promising, but we're still in the wild west phase of the technology. As people experiment, we should expect lots of great innovation as well as lots of confusing and weird RIAs.

Eventually, the best practices for RIAs will become clear, but that will take a few years. In the meantime, I'd love to start a discussion of how RIAs can help make better ideas. I've put down some of my thoughts. I'm sure you have thoughts as well.