INTERNET APPLICATION DEVELOPMENT
MID MARKET ERP DEVELOPMENT
by Derek Du
Displaying error message is one of the most basic functions of an application, but it also can be overlooked easily because we often focus on the core functions of the application. There are many ways to present error messages, but in my opinion there are basically three objectives we want to achieve with error message and as long as the design can fulfill those, it is a decent one.
Error message should make it easier for the users to:
In past projects, form page and listing page are the two most common pages that display error messages.
On a form page, I use these three ways to represent error messages:
Good for a simple form. For example, login page.
This helps users find the fields that need to be corrected, but if the correction instruction is long, the page’s layout will suffer.
Useful when instruction for correction is so long that putting it within the form will break the layout. Combined with highlighting the problematic fields can help users find the fields quickly and view all instructions in one place.
I feel these three ways are sufficient to cover all scenarios. I can just pick one of them based on the actual situation.
Listing page is a page that contains a list of records. This page type is different than a form page because the page is often long, and each record often has its own action buttons, e.g. edit, delete, which could trigger error message. Because of this, there is one more thing that needs to be accounted for – whether we need to maintain the current view of the user.
Consider a page with a very long list of records. When operating on one of the records, an error occurs and the page scrolls to the top or bottom where an error message is displayed. After reading the error, the user will have difficulty finding where the original record is.
It is a good practice to always consider whether to maintain the user’s current view, for it is very likely the user will continue to work on the record or the records next to it after seeing the error. In order to maintain the view of the page, I use an in-page pop-up window to display the error.
There are other ways. For example, you can add a link in the error message to allow the user to go back to the problematic record.
There are downsides, however, the pop-up dialog requires the user to click the close button to continue, and the "link" approach scrolls the page back and forth. But, they are decent designs as they fulfill all three objectives of error message.
Listing pages do not always require one to maintain the view. For example, many listing pages offer action buttons, such as a Batch Deletion button. Users can select multiple records and delete them at once. In that case, displaying the error message next to the action button is more common.
These are my thoughts on the error message’s objectives, which can be a starting point to develop a good error message design. Also, I shared a few designs from my past projects. Hopefully these can inspire and help people on their own projects.
Tihs blog post originally appeared in Derek's blog, Stuff.