Design error message

Displaying error message is one of the most basic functions of an application, but can also be easily overlooked because we are often focused on the core functions of the application. There are numbers of ways to present the error messages, but in my opinion there are basically 3 objectives we want to achieve with error message and as long as the design can fulfill those, it is a decent one.

Objectives of error message

The 3 objectives of error message are to make it easier for the users to:

  1.  Know there is an error
  2.  Know what is having error
  3.  Know how to correct the error

In my past projects, form page and listing page are 2 most common pages that display error messages. I will share some ideas on each of them below.

Error message on form page

On a form page, I have pretty much used the following 3 ways to represent error messages:

Error message on top or bottom

Good for a simple form. For example, login page.

2-18-2015 12-33-30 PM

Error message next to a field

Useful to help users to find the fields that need to be corrected, but if the correction instruction is long, page’s layout will suffer.

2-18-2015 12-33-40 PM

Error messages all displayed in a single block on top

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.

2-18-2015 12-33-48 PM

I feel these 3 ways are sufficient to cover all scenarios. I can just pick one of them based on the actual situation.

Error message on listing page

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 needs to be accounted for – whether we need to maintain the current view of the user.

allows user stay or return to where she was

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 to find where the original record is.

2-18-2015 12-35-03 PM

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.

2-18-2015 12-35-30 PM

But of course 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.

2-18-2015 12-37-55 PM

There are downsides, however, the pop-up dialog requires the user to click the close button in order to continue, and the ‘link’ approach scrolls the page back and forth. But I will say they are decent designs as they fulfill all 3 objectives of error message.

Listing page does not always require 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 the case, displaying the error message next to the action button is more common.

2-18-2015 12-38-25 PM

In this post I shared 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.

How flexible a system should be?

Flexibility has a real cost

It is common for people to ask UI designers to design a system as flexible as possible. Many believe that it is always better for something to be flexible. They think the more flexible the system is, the better the overall experience of the system. However, it is not always true. When we say this design is more flexible than the other one, we are saying that this design can handle more use cases, conditions, or scenarios. In other words, it performs more functions than a less flexible system. But, because it can do more, it often is more complex, which in turn decreases the usability of the system.

A great example from Universal Principles of Design about this tradeoff between flexibility and usability is the comparison between a Swiss Army Knife and corresponding individual tools. Swiss Army Knife has many attached tools that increase its flexibility, but in order to put all those tools in one tool, it sacrifices usability – users spend more time looking for the needed tool and then carefully digging out the tool. The complexity also has impacts on the Swiss Army Knife’s size and shape, which results in a less comfortable handle than corresponding individual tools.

Below diagram shows that the more flexible a UI is, the more it costs.

2-5-2015 10-07-39 PM

So why flexible?

Knowing this relationship, it seems that flexibility only decreases usability — what benefit does it bring to the table? In my opinion, perhaps it is only beneficial to build a system flexible when you can’t anticipate future uses of the system. The flexibility helps to accommodate any unexpected future uses so the system does not need to be modified as much as an inflexible system. On the other hand, if you can clearly anticipate the need, flexibility is not needed. Why would add features you know that you are not going to need? There is a cost for keeping unneeded things, e.g. higher maintenance, more complex structure that makes changes difficult, etc. ‘You aren’t gonna need it’ (YAGNI) principle also presents several reasons for not adding features until deemed necessary. To list a few:

  • The time spent is taken from adding, testing or improving the necessary functionality.
  • The new features must be debugged, documented, and supported.
  • Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.

About building a flexible system vs. a specialized system, a really great example from Universal Principles of Design is a comparison between personal computer and video game console. We use computer to do all sort of things and can’t anticipate the future uses of the computer, thus the flexibility of it. Game console, on the other hand, is built merely for the need to play games. It is a specialized system which does not need the same level of flexibility as PC because we can fully anticipate the uses of it.

How flexible?

Knowing about these key factors, when approaching the problem of how flexible a system should be, we can tackle the problem via the following practices:

1) Clearly define the uses of the system.

Only when we clearly define the uses, can we know whether flexibility is needed. Requirement analysis itself is a topic that will require a whole series of posts, but knowing that this has to be done is critical.

2) Compare levels of flexibility with the costs in mind

As mentioned previously, increased flexibility has a cost in terms of usability and development effort. So we have to look at all factors together. What I often do is put design candidates with different level of flexibility side by side. Play with the different UI just as if I am a user to actually feel the pros and cons of each design.

An example involves a screen for setup of sending system notification emails, e.g. error reports. Should the flexibility to be provided to allow the From Address and Sender Name to be edited?
2-5-2015 10-11-33 PM
Things like From Address and Sender Name, once are set up, may never change. Allowing these to be changed like in the first design below introduces more user errors and longer setup time, thus reduces usability. The second design does not allow these to be changed, but could cause some confusions – why these are read-only? Do I need a higher permission level to edit them? The third design allows these to be editable but also provides default/suggested values, which increases the flexibility without reducing much of the usability. By comparing these 3 designs together, a decision can be quickly made.
2-5-2015 10-14-11 PM
Aside from usability cost, we also have to deal with the cost of time and money. Consider the same designs above. If the first design costs $1, the second $100, and the third $1,000, the first design is mostly going to be favored. Development cost like this can have a great impact on the decision. What I often do is presenting all the cost factors to stakeholders and work out a decision together.

 3) Stop when you have to

During the system design, we will apply the first 2 steps and create designs with high flexibility and low cost. When design phase is over, we will hand it over to development team. Whatever level of flexibility we have in design at that point is the level the system will have. Every project has a time constraint. Even if you don’t want, it is going to decide the level of flexibility for you.

I covered a basic introduction to flexibility and a few practices we apply to our projects. There are numerous discussions on software flexibility out there. Many of them are around flexibility on software architecture, but the basics are still the same – Flexibility has a cost and it is beneficial when we can’t anticipate future uses. I hope that knowing about these basics is helpful!

Create a fixed and interactive navigation sidebar with Axure 7.0 (Part II)

In my previous post, I talked about, as part of building a interactive navigation menu, how to detect the section the current view is in and highlight the corresponding navigation menu item. This post is going to finish the work by adding actions that make the navigation menu stay on top of the view.

First, let me start by saying that a new feature is recently added to Axure that can pin a dynamic panel to browser. Right click the panel and you will fine the option.

11-11-2014 1-16-13 PM

However, this always keeps the same top margin between the panel and the top of the view. What we want is to only pin the panel in place when it is about to be out of the view. In other words, we want the panel to start moving along with the page when it is about to be scrolled out of the view.

So how do we know if the panel is about to be scrolled out of the view? This can be detected by checking whether the distance scrolled vertically is greater than the y position of the first horizontal line (our panel’s top edge aligns with the line). This is going to be the condition of our action.

When the page is scrolled past the first line, part of the panel will be out of the view. How do we pin it in the view instead? We just need to immediately move that outside part back in. In other words, we need to move the panel down by a distance that equals to the height of the part that is out of the view. Below diagram shows how we can calculate this distance. Scroll Y is how much has been scrolled. Panel’s Y value is the distance from the top of the page to the top edge of the panel. The difference between these 2 variables is the distance we need to move the panel down, so that the green part is back in the view.

11-11-2014 1-41-08 PM

Once we are clear on the approach, we can add a new action on ‘OnWindowScroll’ event that moves the panel back in when it is scrolled out of the view. The Target here is the panel itself because we are moving it. It is a quick way to get a widget’s property.

11-11-2014 2-03-30 PM

Note that I added 20 pixels of top-margin at the end. It is not necessary. But if you added some margin, you need to remove the margin once the view is back to the initial position, so that the panel is also back to its initial position. Below I have another action that moves the panel back to its original position when the page is scrolled back to top.

11-11-2014 2-08-17 PM

Here is a demo of the navigation menu.  Hope this helps!

Create a fixed and interactive navigation sidebar with Axure 7.0 (Part I)

UI design is part of my daily work and I use Axure to build mock up screens all the time. Recently I have updated the tool to its latest 7.0 version and noticed that some of the new features it offers are quite useful. What I found to be the most useful are the ability to pull or push adjacent widgets when a widget is hidden or shown and the ability to break away the first state of dynamic panels.

My wife, a UX designer, thinks Axure is really counter-intuitive and she prefers to use Adobe Muse. I have to agree that in terms of building animation and graphic intense web apps, Adobe Muse is a better choice than Axure, but I think they are focused on different things. Axure is more focused on building a prototype for tools and enterprise applications. Just look at what it offers – page and widget events, repeater, dynamic panels –  all of these make it easier to build up pages with complicated logic.

In this article I am going to describe how to use Axure to build a navigation sidebar that stays on the page and  highlights the section the user is current in, which seems to be a feature that requires some logic controls. Ironically, my wife says this can be done easily with Muse.. I hope it is not true! On the bright side, this can still be done with Axure, just with a little bit more effort.

So this is what we want to achieve – a navigation sidebar that first appears on the right top corner. When page is scrolled and the sidebar is about to be out of the view, it starts to stay on the top. The menu items in the sidebar become selected/highlighted when the page is scrolled to the corresponding sections. Here is a demo.

10-13-2014 10-56-00 PM

Instead of jumping into the detailed steps, I think it is beneficial to firstly explain the solution a bit. To make this work, the central idea is to store the Y position of each section as the text of a hidden widget, which is the rectangle to the left of each section on my demo, and then when the window is scrolled, compare the Window.scrollY with the hidden widget’s text to determine whether the page is current scrolled into that section. The trick here is that you can compare a variable value with a widget’s text.

Now, the first step is to of course put all the widgets on the page including the widgets for storing the Y positions. They will later be hidden. I put the widget on the top of each section so that their Y position is the section’s Y position. Then on the onPageLoad event listener, save the Y position of each widget. In the below screenshot, I named these widget as PosA, PosB, PosC, and PosD. Note the ‘Target’ here is the hidden widget itself. It is a new feature introduced in Axure 7.

10-13-2014 10-31-22 PM

These actions effectively store the Y location of each section. Next we will add more actions so that when the page is scrolled to a section, the corresponding menu item is selected.

First assign menu items with a selection group to ensure only one item can be selected at a time.

10-13-2014 6-56-51 PM

Also set the menu items’ Selected style by selecting ‘Interaction Styles…’ in the above menu and go to Selected tab to define a Selected style.

10-13-2014 10-50-06 PM

Here comes the most important step. On the page’s OnWindowScroll event listener, add the following actions. These actions compare the Window.scrollY (how much the page has been scrolled) with the position of each section to determine whether the page is currently scrolled in the section

10-13-2014 10-50-54 PM

These steps are the essential parts for achieving the interactive navigation sidebar. However, without the sidebar staying on top of the view, we cannot see the end result (because the side bar is out of the view). Next time I will finish the tutorial with steps of making the side bar fixed in place. Stay tuned!