Communicating with the User in RIAs

RIA interface design has provided a *somewhat* new challenge in communication with the user. In typical HTML-based applications, you could count on the "page refresh" to shoulder at least some of the user communication effort. The page refresh could communicate:

• "I'm navigating you somewhere."
• "Your changes have been saved."
• And just generally... "You can expect to see something new when this is over."

hus, when the page refresh is done, the user knows to search the screen for the "something new", whether it is an entirely new page, a failure/success message, or new data.

With RIA, the transitions can be so seamless and fast that the user may not recognize that something has happened, so it's on the user interface designer to make sure that the communication is clear. This article will focus on a few instances in which the application needs to communicate with the user and a few different concepts and examples on ways that it might be done.

Visual Display
If you were to display an error message in the same visual style as your page content, success messages, or any other text, your user would be less likely take notice. It is helpful to devise a way to visually differentiate all of the different messages. Validation errors or other messages which you really want the user to pay attention to should be called out while less important messages should be there, but unobtrusive. Some examples:

Pop-up Alerts
Pop-up alerts or dialogue boxes are the most blatant way to demand the user's attention. They can also be the easiest way to annoy your user into disregarding them. Used *very* sparingly and with visual styling to further increase the importance of the message, you can make it more likely that your user will not just immediately get rid of it. If you use too many alerts or use them under conditions that really aren't all that important, your user will be more likely to just close the alert without bothering to read the message. Another tactic to get the user to pay attention is to provide them with a succinctly worded Yes/No question and Yes/No buttons for answer. Don't give the user an easy, noncommittal out by using "OK" or "Cancel" buttons.



Color Codes
You can use colors to differentiate messages. I personally like red for errors, yellow for warnings, green for success, and blue or gray for help/instructions. Most of your users can just glance at the color and get the message. However, you should also consider color blind users or users in countries where the red/yellow/green code has a different meaning depending on your audience. It might be helpful to add an icon along with the color codes (such as an exclamation point or question mark). This allows the users to get the message without having to actually *read* the message.



Location
The location of your message on the screen can also signify its type and importance. I think that it's generally a good idea to display validation error messages near the related field, but what if that field is "below the fold" or otherwise can't be seen from the user's current location? It might be a good idea to display an additional message in a location that the user can't miss if it's important. Conversely, if the message is necessary, but no action is required by the user, it can be displayed in a less obtrusive location.



Flex has a built in component for form validation that displays error messages near the required form fields, but it comes with some built-in usability issues. First, the user must position the mouse over the field in order for the message to appear. I have performed usability tests on software using this validation and it fails miserably. The red border on the form field is too subtle and the users do not understand how to get the error message to display. Also, in scrolling situations, there is no top-level error message display built in to this component. The component might be useful if it could be extended so that the error message was displayed constantly rather than just on mouse-over. Someone has already done this (of course). See Aral Balkan's post: "Better form validation in flex".

Transitions
Page refresh in the standard HTML website is a type of transition and as mentioned above, can communicate change to the user. I actually found out how important this was after performing a usability study on a particular feature that I was adding to a web application.

This was a very data-intense application, so it was necessary to hide the feature until it was needed in order to free up the screen real estate for data display. So, I used a hidden <div> which was displayed when a link/button was pressed by the user. While completing this task during the study, very few users recognized what had happened after the link was clicked. Most assumed that they had navigated to a new page, when in fact, the data they had been viewing had just been pushed down so that the new feature could be displayed.

So, using the Yahoo UI library, I added resize and fade-in transitions on the <div> so that it appeared to be opening downward and pushing the data down below it (first resizing the to the appropriate dimensions and then fading in its contents). All of the users in the subsequent study easily recognized what was happening.

Let me know what you think
So I've obviously barely scratched the surface of all of the user communications that are required in a complex application nor all of the ways to address those I did touch on. Please feel free to comment back about challenges you have faced or other ways you have discovered work well to resolve these. And thanks for reading!