Usability of RIA with Flex

User Interface Design Principles

1. The Client Is Not The User
The client may think she knows what the user wants, but she cannot. This is because the client is not the user.
This brings me to the second principle:
2. Don't Give The Client What She Thinks The User Wants
If the client does not know what the user wants and you give her what she is asking for, you are doing her a disservice. You will ultimately be delivering an application that does not meet user's needs. Your client may initially be happy that you have given her exactly what she asked for but will she remain happy when the product is rejected by users?
I have seen too many designers and developers who are aware of these two principles but proceed to reach the wrong conclusion from it. Namely, that they know the user better. Which brings us to our next principle, which is, simply:
3. You Do Not Know What Your User Wants
You may be a user interface designer or developer with many years of experience but you do not know what users want. Which users? Those specific users who will be using the current application that you are building. Why? Because every application is unique. You may have built similar applications but, unless you have built exactly this application before, you do not know what the users of this application want.
So, who does know what your users want?
4. Only Users Know What Users Want
It's a basic concept but one that is alien to much of our industry. Only users of your application will know what works and what doesn't. It's surreal that, given this, most of us in our industry go out of our ways to delay asking them what they think of our applications. This brings me to the most imporant principle of all:
5. Test Early, Test Often, Then Test Again
Usability testing is not rocket science. In fact, it's quite a simple recipe:
Ingredients:

1. Two rooms
2. One or more representative users
3. A computer running your application
4. A usability tester
5. A video camera (no tape)
6. A TV screen

Take two rooms and place a computer running your application in one of them. In that room, place a representative user and a usability tester who will ask the user to perform various tasks in your application. Place a camera in the room to relay your user's actions to your design/development team who should be watching from the second room. (Ideally, having the rooms next to each other means that you don't have to run too much cable between the two but you can just as easily use wireless technologies or even broadcast the feed over the Internet to a development team across the globe.)
Leave to simmer then repeat.
Notice that you do not even need to record the test. If you do, chances are those tapes will become paperweights like most artifacts that are created during development. Remember: Agile is good.
Doing usability testing does not involve a large upfront financial investment. You can put together the above setup for around $1,000 these days. What it does involve, however, is buy-in to a User-Centered Product Development (UCPD) approach from the highest levels at both your and your client's organization.
Following a UCPD approach involves capturing measureable Usability Requirements alongside your Functional Requirements. You will have to set aside time to carry out usability testing at every iteration in your development process. You cannot do this without a budget. And you won't have a budget unless you have buy-in at the highest levels.
The above principles are perhaps the most important ones as they will determine your development process and your development process will largely decide whether your project succeeds (is accepted by your users) or fails (is rejected by your users.)
Alongside these process-related principles are design principles. These do not, in any way, replace testing. They are intended to give you a good starting point when designing your user interface, before you go to your users and say, "What do you think?"
6. Talk One Language
There should only ever be a single term or phrase used to refer to any given item in the application. An item here may refer to a concept, a business function or task or even a widget or individual interface element. You will find that the use of a metaphor for the project, as advocated by eXtreme Programming (XP), will ease this task tremendously.
7. Respect User Effort
Try to limit the user's physical toil while using the application. Repetitive Strain Injuries (RSI) are a fact of life today and we, as application designers, have to accept responsibility for the ergonomics of our applications.
8. Make difficult decisions
It is your job as the user interface designer to layer the user interface and make important decisions about its organization. Don't leave these decisions to the user just because it makes your life easier. If your application has a huge preferences section, treat this as a Design Smell and review the design to see if you have left decisions that you can make to the user.
9. Let The User Work
Users must be able to perform their most frequent, most important tasks without any resistance. For an SMS Messaging application, for example, this would include reading, replying to and forwarding messages and quickly checking the various mailboxes.
10. Prevent, Don't Scold
Whenever possible the UI should prevent the user from making a mistake instead of alerting the user to the mistake after the fact. This must be achieved without the UI getting in the way of the user.
11. Give Sufficient Feedback
The UI should give the user sufficient feedback for user actions. (This ties in nicely with Steve Krugs "Don't Make Me Think" philosophy: The user should never have to think "did that work?") Related to Don't Lose The User.
12. Show, Don't Tell
Although this may seem to contradict the Give Sufficient Feedback principle, it is actually meant to compliment it. Whenever possible, meaningful visual cues (when appropriate to the audience) should be chosen instead of lengthy textual descriptions. This can also pertain to actually teaching a user to do something in an application by showing them.
13. Don't Lose The User
The UI should protect the user's sense of spatial positioning. The user should never feel "lost" within the application.
14. Don't Sell What You Can't Deliver
Users must not be given Graphical User Interface (GUI) expectations that cannot be met (or can only be partially met) within a Web User Interface (WUI). Whenever OS or GUI expectations are set, they must be fully met. That said, the application must try and meet OS expectations as much as possible, especially for ergonomic features such as keyboard shortcuts and navigation but also for expected auxiliary helpers such as tooltips.
Don't Sell What You Can't Deliver is the main principle behind why Adobe chose to create a new component style called Halo in Flash and Flex instead of trying unsuccessfully to emulate either the Windows XP or Mac OS X look and feel.
15. Don't Keep Them Waiting
The application must perform fast enough to be considered usable within the given engineering limits for the application.
16. Innocent Until Proven Guilty
The user should be warned about a validation error on a control only if they have had a chance to interact with that control. (In other words, you should not perform validation on controls that are in their initial state and initially display a form full of validation errors.) Similarly, resetting a form should remove all validation errors.
17. Usability Approach to Accessibility
There is a trend I am noticing in our field that I find very worrisome and it concerns accessibility. Many people appear to be on a quest for the Magic Button of Accesibility (MBA). This is how an MBA works in an ideal world:
You gather usability requirements for your application for a given target audience. This target audience involves people with good eyesight, hearing, and motor control. Based on the usability requirements for this specific audience, you expand resources in designing a good user experience for this specific audience. You then spend further resources in developing your application, going back to users within this specific audience to get their feedback and to alter your design accordingly. Finally, right before you deliver your application, you press the Magic Button of Accessibility.
The Magic Button Accessibility magically makes the experience of your application as good for various other audiences. These include people who have various levels of sight, hearing, and motor control. Isn't it amazing that the MBA can transform a carefully crafted experience for a single audience into equally pleasurable experiences for many other audiences.
Unfortunately, the Magic Button of Accessibility doesn't exist because it cannot exist.
The MBA is an extreme example of the check-the-checkbox mentality to accessibility that is pravalent in our field today. I call this Checkbox Accessibility: For the most part, we do not really care what sort of experience users with accessibility requirements will have with our applications as long as we can check a checkbox on some form that says that our application is compliant with a set of rules.
If we can run our applications through a program that checks for this, all the better. After all, software is cheap compared to devoting extra time to design and develop an equally good experience for various other audiences. Checkbox Accessiblity is head-and-shoulders better than no accessibility but it does not guarantee a good experience for users with accessibility requirements.
The other approach to accessibiltiy is to see it as usability with different audiences. In other words, you cannot make your application truly accessible for users with disabilities without designing for those users. I call this the Usability Approach to Accessibility.
Having a usability approach to accessibility means that you have to gather usability requirements for disabled users just like you do for users without disabilities. You have to usability test with disabled users. And you have to realize that "disabled users" doesn't refer to a single audience but to multiple audiences, including those with accessibility requirements in sight, hearing and motor function.
Of course, just like usability with an audience of non-disabled users, usability for disabled users costs time and money and will require buy-in at the highest levels of your organization. If you are serious about accessibility, however, anything less is just not good enough.
These are general points of advice that can apply to any application. Based on these overall guidelines, the following are examples of high-level design decisions that were taken and applied in Opal. Keep in mind that Opal was developed in Flash MX but the issues are the same regardless of whether you are building an application in MTASC/SWFMill/FlashDevelop, Flash 8, Flash 9, Flex 1.5 or Flex 2. Each of those tools and technologies provides different features, components, programming models and development workflows but the end result, regardless of which technologies are used, is always evaluated by your users.

Principles applied: examples

Respect User Effort: eliminating scrolling
The message preview textbox displays a full SMS message without scrolling. It meant that sacrifices had to be made with some of the other form elements on the Message Tabs. Reading an SMS message is both an important and frequently-performed task and so the other sacrifices were justified (also see Make difficult decisions.)
Give Sufficient Feedback: SMS character count
A custom SMS character count widget shows users exactly how many characters they have left before they need to send a message as two or more SMS messages. This is an especially important piece of information for users as they are charged for each SMS message sent.
Prevent Don't Scold: Form validations
All forms implement client-side validation. Submit buttons (such as "Send Message" or "Add Contact") gray out until the form passes client-side validation. This does not remove the need for server-side validation and all form submissions are validated server-side for correctness and security before being processed. Client-side validation exists solely to improve the user experience and does not provide any security whatsoever.

Let The User Work: Mailbox Tabs and Message Action Tabs
A composite tab-based interface exposes the critical, frequent tasks to users. Mailbox Tabs give users single-click access to their mailboxes. They also expose context-sensitive message actions for each mailbox. Users can immediately see the actions that they can perform on a message in a given mailbox tab.
Implementing a context-sensitive menu that hides possible actions until it is triggered would have ranked at the opposite end of the usability spectrum and been ignored by most new users.
Show, Don't Tell: Menu Bar and Tool Bar as teaching methods for migrating Outlook users.
A menu bar and tool bar remind users of the ones in Outlook without creating operating system specific expectations.
The menu and tool bars implement Show, Don't Tell.
When an Outlook user first changes to a given mailbox using the menu or tool bar, the Mailbox tab animates to the chosen mail box, thereby showing the user that they could also have clicked on the tab (although the tab control is a well-known GUI component in its own right.) The same goes for when the user selects a Message Action (eg. Reply).
Don't Lose The User and Don't Sell What You Can't Deliver: Screen-based RIAs vs. Multiple-Window-based RIAs.
It is very important to note the differences between Graphical User Interfaces (as used by desktop applications such as Outlook) and Web User Interfaces (as used by Rich Internet Applications such as Opal). It is equally important to manage client's expectations as to the limitations of Web User Interfaces, even those termed "Rich" and developed using Flash.
The greatest difference between a WUI and a GUI is usually the most overlooked: WUI applications run from within a GUI application which, in turn, runs inside a window-based operating system. Past usability studies have shown that especially beginning users have problems with the concept of multiple windows, preferring usually to keep a single window up at a time. Even in multitasking operating systems like Windows XP or OS X, novice users sometimes prefer to start up a single application, shut it down and start another application and so on. The perceived complexity of the system is heightened when the user is confronted with an interface (an RIA such as Opal) within a GUI application (the web browser) that itself contains windows.
Firstly, we rob our novice user of the comforts of his single window existence. Secondly, the new windowing system works in a different way and contains its own rules and limits. It is thus important to implement a screen-based interface in RIAs so that you Don't Lose The User and Don't Sell What You Can't Deliver.
Even if an RIA developer takes pains to develop a Multi-Window Interface that mimics a certain dominant OS, the interface is still being presented to the user in the document area of a GUI application (the web browser). This is contrary to OS expectations wherein users expect not to see windows within documents. Perhaps this is one area where application browsers such as Central will have an impact on user expectations. It remains, however, that the only way a multi-window interface can provide a high-level of usability in an RIA is if the application can run in its own OS window and not as a document within a web browser and thus access the windowing abilities of whatever OS it happens to be running on. As this is currently not a possibility with Flash, we decided to go with a screen-based system in the application.
Although modal pop-ups are sparingly used due to issues of screen real-estate and Outlook migration expectations, users are visually shown that these dialog boxes are modal screens via the graying out of lower screens. Although this removes the OS expectations surrounding non-modal multiple-window interfaces, the graphic similarity of the dialog screens to windows still leads certain users in testing to attempt to move windows around.
Don't Keep Them Waiting: The name of the game is performance.
If there was one issue we kept running into during development, it was performance. Flash is not the fastest kid on the block and it is possible to run into issues when client's expectations are not managed as to the limitations of RIAs. Although RIAs can recreate a lot of the desktop application experience from within a web application, there are limits.
Flash 9 and ActionScript 3 have made great strides in performance and it is important to keep in mind that this project was being published for the Flash 6 player.
One issue, for example, was that the speed of the setSize() method on the Macromedia DRK Data Grid was resulting in unacceptable redraw times when the application was resized. This resulted in a very risky two-weeks in which I wrote a completely new Data Grid component that implemented the DRK Data Grid interface and could be plug-and-play replaced into application. The resulting Data Grid offered a 10x performance boost and brought redraw rates back within acceptable limits.
I hope that this article has challenged how you think about usability and accessibility and that you will find it to be a useful resource in designing and developing web applications. As always, I value your feedback so please feel free to leave a comment and share your thoughts.

Usability for Rich Internet Applications

After struggling for years to design Internet applications around the limitations of HTML, I have been very excited by the recent release of a range of Internet applications with increased richness and interactivity.

The key challenge in designing part-page updates is making sure people see them.

Rich Internet applications (RIAs) can provide opportunities to design much better user experiences. They can be faster, more engaging and much more usable. However, this improvement is not without its downside—RIAs are much more difficult to design than the previous generation of page-based applications. The richer interaction requires a better understanding of users and of human-computer interaction (HCI). Although there is a lot of HCI material and research available, it can be difficult to determine how it applies to this new environment.
In this article, I provide some practical tips for designing usable RIAs, based on fundamental principles of HCI.

What’s an RIA?

According to the Wikipedia, RIAs are “a cross between Web applications and traditional desktop applications, transferring some of the processing to the client end.”
The key difference between RIAs and other Internet applications is the amount of interaction in the interface. In a traditional page-based Internet application, interaction is limited to a small set of standard controls such as checkboxes, radio buttons, form fields and buttons. This severely limits our ability to create usable and engaging applications, and most Internet applications have been clumsier and more difficult to use than their desktop counterparts. An RIA can use a wider (and hopefully better) range of controls to improve users’ interaction with the interface, allowing efficient interactions, better error management, feedback and overall user experience.
Some of my favorite sites with RIA-style interfaces include:

• Flickr
• Google Maps
• Basecamp
• Backpack
• Odeo
• Gap

Many are built with Flash or using Ajax techniques.
The key features of these applications include:

• The user interacts directly with page elements (inline editing, drag-and-drop, panning a map)
• Part of a page is updated (instead of reloading)
• More detailed information is available on the same page (instead of on a new page)
• Feedback, confirmation and error messages are provided within the page

These rich features are also those that provide the most challenge for designers who wish to ensure applications are highly usable.

Challenge #1: Deciding How Much Richness to Add

When designing RIAs, it is tempting to design many new features that add a lot of richness. Don’t give in to this temptation! Regular folks who have been using the Internet for a number of years are comfortable with the existing page-based model and limited interactivity, as clumsy as it may appear to designers and developers. It takes time for people to adapt to new approaches. It will be some time before conventions emerge and users are comfortable with the new generation of applications. Go slowly, adding richness where it significantly improves usability, and relying on traditional models where these better suit your user group.
Good user research (and a focus on users throughout the design process) and regular usability testing will help you determine how much richness is appropriate at a point in time.

Challenge #2: Interactive Page Elements

One way to add richness to your application is to allow users to directly interact with page elements: editing text inline, dragging and dropping graphic elements, panning a map.
A primary challenge is to communicate what can be done with page elements and how to use new controls. People must be able to identify that a control exists and easily determine how to use it.
In The Design of Everyday Things, Don Norman popularized the idea of perceived affordance (the perceived and actual properties of a thing that determine just how the thing could possibly be used). For example, the original 3D button has great perceived affordance. By highlighting the top and shadowing the bottom, people perceive it as popping out of the screen and easily understand that it can be pushed by clicking.
One way is to use controls that mimic things people are familiar with from the physical world, such as the slider on Fidelity Labs Mortgage Search.

Another is to change the appearance of the element or show the controls when the mouse hovers over it, showing what can be done without cluttering the interface. Backpack uses this to indicate elements that can be edited or deleted.

In addition to ensuring your controls have good perceived affordance, you should:

• Remember how valuable a demonstration can be. In the initial stages of a new interface, use a small in-page tutorial video to show the interaction.
• Ensure controls and interaction models are used consistently throughout the interface and are similar to other sites that your users visit. This helps people easily learn what to do and build on previous experiences.

Challenge #3: Refreshing Part of the Page

There is significant advantage in updating part of the page instead of refreshing it or opening a new page. It allows us to create faster applications, improve feedback to the user and manage errors better. Error management and feedback are critical to improving usability, but it’s particularly difficult to do with the page-based model. Users have become accustomed to taking an action (such as clicking a link), waiting for the action to complete, and checking the result of the action.
The key challenge in designing part-page updates is making sure people see them. We can use what we know about visual attention and visual processing to ensure people will see that part of the page has been updated:

• Visual attention is attracted by movement and high color contrast (that’s why bright, animated banner ads are so distracting—our eyes are constantly pulled toward them). We can use this to our advantage and draw the eye to the updated part of the page.
• When we take an action such as clicking a button, our eyes remain fixed on that point for a short time, then release to look somewhere else. By making sure the change occurs quickly and as close as possible to where they are looking, we can ensure the eye is drawn to the appropriate place.
• Visual attention can only be focused on one thing at a time. Make one update at a time, and don’t use high-contrast, moving images elsewhere on the page. 37 Signals were one of the first to do this, popularizing the yellow fade technique. Odeo provides effective feedback by using color, movement and placing it right where the user is looking:

Challenge #4: Breaking the Page Model

As we interact with the world, we develop a mental model of how things work. Most users have developed a mental model of the Web based on pages—every click takes you to a new page. Clicking on the back button takes you to the previous page. This is a strong mental model, and is reasonably accurate for the majority of content-rich sites. Users will continue to apply their page-based mental model to RIAs unless they can clearly identify that the RIA uses a different model.
The first part of this challenge is to think very hard about where to use individual pages and where to use in-page richness. Think about the entire interaction of your application and break it up appropriately. Don’t try to put everything into one “page” just because you can.
One factor is the likely use of the back button. Consider when people may need to go “back”—this will give you clues about where to use pages. Don’t disable the back button, reducing users’ control of their situation.
Another challenge is how to visually express the difference between pages and in-page changes. You may need to design different visual navigation models so people can identify when they are getting a new page. It is likely that some new navigation methods will emerge over time.
Google Reader manages pages very poorly. The buttons in its traditional top navigation bar (Home, Your Subscriptions, etc.) imply navigation to individual pages, but actually change the content in the body of the page. When I first used Google Reader, I frequently tried to use the back button to return to the home page but was thrown right out to the last page I visited before reaching Google Reader. This was so frustrating, I stopped using it.

In contrast, Yahoo! News manages pages and in-page updates well. It has traditional top tabbed navigation to individual pages and in-page panels that change based on the news source:

Review Usability Best Practices

Don’t forget the usability basics. Jakob Nielsen’s Ten Usability Heuristics are as relevant now as they were in 1999. I stress this because I looked at the Flex showcase recently, and it looks like many of the applications are not built with these best practices in mind.

1. Visibility of system status (Feedback)

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

1.0 BaseCamp by 37signals
The upload button is enabled, until clicked. Then it is replaced with a progress indicator until the file has finished uploading

1.1 Picnik
Progress message and indicator shows while the application loads

1.2 Tick
A feedback message is displayed when an action is performed

1.3 Windows Live Account
Password strength is shown as the password is entered

2. Match between system and the real world (METAPHOR)

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

2.0 iTunes
Organized as a library that contains your media library: music, movies, shows, audibooks. Beneath the Library is the Store where you can buy more media to put in your Library.

2.1 Mindomo
The branches and hierarchy of a mind map can be easily reorganized visually in a non-linear manner. An outline would never work, but this matches the paradigm exactly.

3. User control and freedom (NAVIGATION)

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Supports undo and redo and a clear way to navigate.

3.0 CollabFinder
Search is easy to open, enter info, execute or cancel.

3.1 Wufoo
Clearly marks where the person is and where they can go by showing the selection in each menu

3.2 Pages (Apple’s Word Processing Product)
Cell editing shows row and column ids, and the cells used in the equation. The equation can be saved or canceled.

3.3 Balsamiq
Undo and Redo buttons are available in the toolbar, and can also be accessed with the standard keyboard shortcuts

4. Consistency and standards (CONSISTENCY)

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

4.0 Gmail
When Gmail was designed, they based the organizational folders on the same ones used in client email applications: Inbox, Drafts, Sent Mail.

4.1 Microsoft Office
Word, Excel, and PowerPoint all use the same style toolbar with the same primary menu options: Home, Insert, Page Layout… Consistency results in efficiency and perceived intuitiveness.

5. Error prevention (PREVENTION)

Even better than good error messages is a careful design, which prevents a problem from occurring in the first place.

5.0 Yammer
Disables the update button after it is clicked, so the person cannot update the post twice by accident

5.1 Example from “Web form Design:Filling in the Blanks” by Luke W.
Make the primary action prominent with a larger click area. Cancel and secondary actions are just shown as links

5.2 Google Auto Recommend
The auto recommend feature cuts down on mis-spellings

5.2 Wikpedia
Auto focus on input prevents a common source of frustration, typing only to realize nothing is displayed because the field did not have focus

6. Recognition rather than recall (MEMORY)

Minimize the user’s memory load. Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

6.0 Quanta IDE
Type ahead for coding in a development environment

6.1 Keynote
Previews the fonts you can pick from, instead of just the font name

7. Flexibility and efficiency of use (EFFICIENCY)

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

7.0 OmniFocus
List of keyboard shortcuts and accelerators

7.1 Numbers- Apple’s Spreadsheet product
Previews common function results on the left when a column is selected, more efficient that clicking on an action in the toolbar

8. Aesthetic and minimalist design (DESIGN)

Dialogues should not contain information, which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Visual layout should respect the principles of contrast, repetition, alignment, and proximity.

8.0 Kontain
Kontain’ search menu exemplifies the four principles of visual design:
Contrast: bold text is used for the two labels in the search
Repetition: the orange, blue, and green text match the media types
Alignment : strong left alignment of text, right aligned drop down
Proximity: a light rule is used to separate tags from the other options

8.1 Harvest
Sufficient padding and spacing keep this timesheet from being a visual nightmare. Header and footer rows, as well as the summary column use subtly different colors to indicate they are distinct from the content

9. Help users recognize, diagnose, and recover from errors (RECOVERY)

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

9.0 Digg
Provides immediate feedback with specific instructions

9.1 Humorous ‘ Page Not Found’ Error
Uses a funny image and copy, but provides viable alternatives (article listings and blog link) and a course of action (report it)

10. Help and documentation (Help)

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

10.0 Picnik
Contextual help (this is an example of help in the ‘Collages’ module) tips in Picnik are clear and easy to navigate

10.1 GoodBarry
Embedded videos can be used to showcase features as well as get people started using the product

10.2 Zenoss
Help tips are displayed on hover, answering the most likely questions about a field or instructions

10.3 BaseCamp by 37signals
Help opens a new browser window/tab with a full set of help resources: search, FAQ, video tutorials, customer forums