Five guidelines for feedback messages in Rich Internet ApplicationsNovember 29th, 2012
In an earlier posting, I outlined five guidelines to help improve communication with the user: The first is to give feedback upon interaction. The next is error prevention, followed by easy error recovery if an error could not be prevented. You also need to make sure that you communicate consistently across the application and, finally, provide help or more information where necessary.
Here are some more details on each point:
1. Give feedback
We all thrive on receiving feedback. Take the example of radar speed signs: they not only show you whether you are under or above the speed limit, but also give you a smiley or a frown. We have one close to home and my kids always urge me to make the sign smile – so of course, I slow down to a snail’s pace! This is a lot more enjoyable than “real” radars, which are punitive and not at all playful.
When it comes to applications, these personal speed signs are a good example to follow, and the more immediate the feedback, the better. This includes simple things like :
- Roll-over effects on clickable items such as icons, images, buttons, links, rows (I know, basic stuff!)
- Visually showing focus on form fields
- Validating errors line by line and
- Providing additional progress indicators, such as checks for accomplished task or indicators for password strength.
Once the user has finished a task, it is important to show system progress (if needed) and success confirmation. For example, when clicking the save button, a little animation can show that the information is actually saved (when staying on the same page). If the action is tied to a workflow, it makes sense to display a clear success message that will also communicate what will happen next.
2. Prevent errors from happening
As with drugs – prevention is better than recovery. Different techniques help to prevent errors from occurring in the first place:
- Required fields: Indicate them clearly (I know this is basic again, but still worth mentioning)
- Progressive disclosure: Only show what the user needs to see at any given time, so that they can focus on the task at hand and not skip important steps.
- Responsive enabling: Do not allow buttons to be clickable when they are not (yet).
- Forgiving formats: Allow different formats for entering data – especially for dates and numbers (e.g. I can enter 11-01-2011 or 11.1.11)
- Default values: Whenever possible, provide smart default values.
3. Allow for easy error recovery
Let’s face it: as long as there are humans and machines, we will have errors. The key is to allow the humans to recover easily from their mistakes and for the machines to not get in their way.
Go back: You should always allow the user to go back when they get stuck somewhere. This should be obvious, but is not always so. Especially with rich Internet applications, the back functionality does not always work the way the user would expect it; this is because the notion of “multiple pages” often does not exist anymore. So if the user is in a wizard and needs to go back to correct some information, he should be able to do so and not lose any information before or after.
You should enable users to edit or delete items whenever business processes allow them to. When workflows are involved – e.g. a document approval process – there comes a point where editing is no longer an option. However, to simply enforce that you cannot modify your review once you have submitted it is an easy way out. A more “user-friendly” system would allow you to modify until the next person in the review process has opened the file.
If an action is critical and irreversible, always ask for confirmation, usually in the case of deleting or closing unsaved items. However, for less critical events it becomes annoying to the user to always be asked whether they are “really sure” they want to delete – so it’s a fine line to walk. Consider using a “don’t ask me again” option.
4. Communicate clearly and consistently
So how can you avoid this kind of message? It helps to create general UI standards on when and how to display alerts, errors, confirmation messages and help text, to define the tone of voice and syntax to be used, as well as to identify common messages used throughout the application. It also helps to have some common sense
Communicating clearly means:
- Be specific
- Use common, non-technical language
- Display errors in a visible way and in proximity to their source
- Give constructive advice when possible
- Offer a clear path of what to do next
5. Provide access to more information
Opinions are divided when it comes to help and additional information. Apple for example has opted not to display any help information on their devices. (They do provide support on their website though). It is common knowledge that very few people actually consult the global help or user guide section, however, contextual help can be very useful, especially if the users are new to the system or use it infrequently.
However, it is usually a better idea to make these messages visible only upon request, since too much information tends to clutter up the screen, as you can see on this screen capture from ebay.
Field level help is probably the most effective, because it is directly in the context of the user’s action. Input prompts and hints are very useful – prompts are displayed in the input field and hints appear upon focusing on the field. If well executed, they provide the users with the comfort of knowing that they are not alone!
Here is a good example of displaying information when you need it without cluttering the screen. On top, the active text field is highlighted.
To sum it up, I believe messages should be contextual, useful, and consistent. They may even be entertaining! But remember, depending on the application you could be speaking to your grandmother, a teenager, or the CEO. So if there is any doubt, be sure to err on the side of meaningful rather than cute.
Share and Enjoy: