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 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!

How to access inspected element in browser console

Today I would like to share a very useful trick I learned the other day – how to access previously inspected element in browser console.

Web developers do inspection on web pages almost all the time – Find the ID of an element? Inspect it. Find the size of an element? Inspect it. Find the type of an element? INSPECT IT!


Once you get what you want, often times, the next step would be to manipulate it with JavaScript, right? Some developers, including myself, like to test the JavaScript in the browser console first before putting it in the code. To find the inspected element, are you still using getElemenetById or using jQuery’s ID selector? These are NOT very productive! You have inspected the element already, so the console should know what element you are looking for, right? Yes, it does! Just type in $0 (dollar sign and zero), and hit Enter. It will get you the element you just inspected:


Now you can do all kinds of things with this handle. To demonstrate this, I just used jQuery to hide the element inspected.


Hope you find this trick useful!

Fade in and fade out elements with jQuery

As a mostly backend developer, I am shocked at how long it could take to adjust page layout and transition with CSS/jQuery and try to learn the stuff on the go. I have struggled for probably an hour just to get a logo to display the transition effect that when you move the mouse closer, it turns to a menu button.

So I setup a div containing both the logo and the button, using jQuery’s fadeIn and fadeout method to hide the logo and show the menu button when the mouse moves into this div, and show the logo and hide the menu button when it is out.

<div id="toggle">
   <div id="logo"></div>
   <div id="menubutton"></div>

And I want one to disappear first before the second shows up. So in the Javascript code, I does this, which is causing problems.

$('#toggle').hover(function() {
    // After logo fades out, fade in the menu button
    $('#logo').fadeOut("slow", function(){
}, function() {
    $('#menubutton').fadeOut("slow", function(){

The problem here is that if you move quickly inside the interactive zone and move out quickly, jQuery will have some weird behavior. This is what I think is happening.

  1. Mouse moves in,
  2. Logo fades out, menu button is going to fade in next,
  3. Mouse moves out,
  4. jQuery tries to fade menu button out, but it is not there yet, so jQuery thinks it’s faded out already, and starts to fade in the logo.
  5. menu button now fades in
  6. So both menu button and logo are shown.

A live demo is here.

So I have to give up the ability to hide one first and then show the second because of this. Here is what I come up with.

$('#toggle').hover(function() {
}, function() {

However, this solution is not complete, because jQuery queues up animations. Moving in and out quickly a few times and you will see the queued animations are being executed after you stop.

A live demo is here.

At this point, what we need to do is just to stop jQuery executing queued animation, which is made easy by the stop() method.

So here is a complete solution for this. I also replaced fadeIn and fadeOut with fadeTo. But both work.

A live demo is here.

$('#toggle').hover(function() {
    $('#show').stop().fadeTo("slow", 0);
    $('#hidden').stop().fadeTo("slow", 1); 
}, function() {
        $('#hidden').stop().fadeTo("slow", 0);
    $('#show').stop().fadeTo("slow", 1); 
#toggle {
    height: 200px;
    width: 400px;

#logo {
    position: relative;
    top: 0;
    left: 0;
    height: 200px;
    width: 200px;
    background: blue;

#menubutton {
    position: relative;
    top: 0;
    left: 200px;
    height: 200px;
    width: 200px;
    background: red;
    z-index: -1
<div id="toggle">
   <div id="logo"></div>
   <div id="menubutton"></div>

Note that using CSS to change the opacity of the elements can achieve the same thing with, though not much, a better performance, but I would prefer to just use jQuery to solve a problem as simple as this and it provides a better cross browser support.