Dialogue on Practical User Interface Design for the Web

This article describes how to measure the quality of user interfaces.

How can one measure the quality of a user interface?

The quality of a user interface can be measured along the scientific vectors of time and distance.

Why are time and distance the measures of quality for a user interface?

The ultimate goal is to minimize the energy required to operate a user interface. The product of time, distance, and mass is energy. In this situation, the user represents the mass, and normally the designer of the interface has no control over the mass of the user. Thus, the designer must minimize the required time and distance in order to mimimize the required energy.

How does time apply to a user interface?

When a user interacts with an interface, one is measuring the time required by the user to move parts of his/her body. For example, the time required to read a word or symbol involves moving one's eyes. The time required to type a character involves moving a finger.

So I presume that distance applies to how far the user must move parts of his/her body?

Yes, that is correct. In the confines of a computer desk, the primary movements are by the eyes, hands, and fingers.

Can you give me a practical example of measuring a user interface by these attributes?

Suppose the user must make a "Yes" or "No" choice. The form below compares two form element types, a selection menu, and radio buttons.

In order to narrow down the analysis, assume the user is not using the keyboard, already has his/her hand on the mouse, has read the question that prompted the choice, and knows that the possible choices are "Yes" and "No". From this point, choosing with the selection menu requires the following actions:

1. position the mouse over the selection box
2. click and release the left mouse button
3. move the mouse straight downwards
4. click and release the left mouse button again

By contrast, choosing with the radio buttons requires these actions.

1. position the mouse over the desired radio button
2. click and release the left mouse button

Normally, the selection menu's initial value would not be "Choose".

This initial value allows the comparison to be fair. In practice, one would pre-select the most likely option. Suppose "Yes" is the most likely choice. The form elements are initialized to default values below.

In this case, choosing "Yes" requires no action by the user for either form element type, given the assumptions made earlier about where the user is. However, choosing "No" requires the same steps as before.

Okay, I can see that the maximal number of steps is two for the radio buttons and four for the selection menu, but that doesn't address time or distance. How do we know that two steps requires less energy than four steps?

We can assign difficulty points to each step. Let's suppose that 1 point is a trivial, easy task that requires almost no energy and suppose that 10 points is a difficult task that requires significant coordination and energy. The points translate directly to time and distance measures. Since we are more interested in relative difficulty rather than absolute difficulty, we do not need to precisely measure actual time and distance.

What points would be assigned to the tasks above?

One can observe the requirements simply by performing the task and paying attention to the time and distance involved. The following relative point estimates are suggested.

With these point measures, how do the above form element types compare?

The total difficulty can be obtained by summing up the difficulty points for each step.

I can see that the radio buttons are more than twice as efficient as the selection menu in this example. Are there any other considerations that should be made?

Yes, there are are several other considerations. First, consider that in the selection menu, all the options are not visible. If the user did not know the possible options, he/she would have to move the mouse to the selection box and click on it just to be able to read the options. For the labelled radio buttons, no action needs to be taken.

Second, consider that the user may be undecided when filling out the form, and may change his/her mind one or more times. Each time an option must be selected again, the full difficulty cost must be paid. This further increases the cost of the selection menu in comparison to the radio buttons.

This analysis seems to show that the radio buttons should always be preferred to selection menus. Is the advantage of radio buttons absolute?

As with most things, the benefits of the radio buttons comes at a cost. Radio buttons and their labels fill up significant amounts of space on the interface.

Can you give a more realistic example, perhaps a form element type with more options?

Sure. Choosing a date is a very common task on the web. Assume that the user must choose the month, day, and year of some event in the near future, such as an airline reservation. The radio button and selection menu versions of the date picker are below.

The total difficulties are three times higher than in our previous example, because there are three choices. The total cost of the selection menu is 42 and the total cost of the radio buttons is 18. Try to choose July 15, 2004 in both cases, and compare the effort required.

Yes, even if I just count mouse clicks, the selection menus require twice as many clicks. But I noticed a scroll bar in the day selection menu. How does this affect the analysis?

Good observation. Whenever the number of options in a selection menu exceeds a system-defined limit, the selection menu is automatically given a scroll bar. This allows expansion of the selection menu to be limited to a reasonable portion of the visible interface area. In order to choose an option that is scrolled out of range, the user must scroll the selection menu.

What are the steps required to scroll with the mouse?

Like any user interaction with a web interface, scrolling with the mouse can be broken down into a number of discrete steps. There are several ways to scroll with the mouse, but let's analyze one typical method.

1. position the mouse over the scroll thumb
2. click and hold down the left mouse button
3. move the mouse straight up or down, while holding down the left mouse button and scanning the options
4. release the left mouse button
5. position the mouse over the desired option
6. click and release the left mouse button

Wow! I never noticed there were that many steps. What is the difficulty cost of these steps?

Using relative difficulty weightings as before, we can assign the following difficulty costs to each task.

In this example, we are assuming that the selection menu has already been expanded by a click. The repositionings in step 1 and step 5 are less costly than in the previous examples because the distance the mouse must move is less.

Why is the scroll in step 3 so difficult?

The scroll requires reading the list of options while simultaneously applying pressure on the left mouse button and moving the mouse at a controlled speed in an up or down direction. The combination of actions requires a sigificant amount of hand-eye coordination and reading ability. Avid gamers and professional graphics artists have developed this skill to high levels, but the average user does not have this skill. The average user today has decades of experience using a pen and paper, but little experience using a mouse. To overcome the hand motion habits of using a pen requires a great deal of energy. This is why older people and adults have great difficulty with computers. Young people do not have ingrained habits, and that is why learning this skill requires them less energy. These stereotypes arise not from a difference in ability, but a difference in required energy.

But there are other ways to scroll using the scroll bar. How do these compare?

Scrolling can also be accomplished by repeatedly pressing and releasing the left mouse button on the arrow icons or by clicking in the thumb track. These movements scroll the selection menu by one item at a time, or by a page at a time. In most selection menus, these methods are either too fine or too gross to be useful, and that is why the typical method is to use the thumb track method described above.

Another method of scrolling with the mouse is to use the special scroll wheel middle mouse button. This feature is only enabled in certain applications, and generally does not work for selection menus. Because of the lack of widespread support and lack of visual indication of support, it is unclear to the user when the wheel is available to use, and so the user is less likely to even try the method. Even where it is possible, the method suffers the same problem of being too fine or too gross in many circumstances.

Sometimes, there are so many options that radio buttons would take up too much space. For instance, how about a date picker interface for choosing a birth date?

While a selection menu may seem unavoidable in that situation, some creativity can go a long way. For birth dates, the year choice presents a problem since the labelled radio buttons for 100 years requires more space than the interface can accomodate. But consider the two examples below.[]

Try choosing your birth date and compare the effort required by each method. In this case, the verbosity and size of the radio button labels slightly narrows the benefit of the radio buttons, but the selection menu still requires a difficult scrolling action.

Year of birth happens to be suitable to this trick. What can be done for a long list of options that can not be represented by labelled radio buttons, such as a list of names?

Yes, in this situation the scrolling action seems completely unavoidable. However, consider that the scrolling is significantly more difficult with long lists as opposed to shorter lists. Instead of helping, the usefulness of scroll bars actually declines. But hope is not lost, in order to work around this problem we must make some more observations.

What observations are needed to avoid scrolling in a long list?

The first observation is that, in most circumstances, the user knows the name of the item to be chosen. If the user doesn't know the entire name, the user will usually know a part of the name or a related name. Rarely does a user interact with a lengthy selection menu simply to browse the list of choices. Where the user does browse, the selection menu is small enough that it can be replaced by radio buttons.

To prove this point, consider the following real world examples. A person walking into a large office building asks the receptionist for what he/she is looking for by name. A person calling a telephone directory service asks for the intended party by name. A person calling a retail establishment begins by asking their question. A person looking in a dictionary has in mind the word to look up. In short, most business-oriented interaction necessarily requires the user to know the intended choice in advance. This carries over to web user interfaces almost directly.

The second observation is that today's computers can process millions of operations per second. A typical computer can search through a non-indexed list of tens of thousands of options within a fraction of a second. A computer can perform this entire search even between the time it takes the fastest typist to type just two characters.

The third observation is that typing the name of an option is a common and relatively easy task. In particular, typing part of the name of an option requires only the typing of a few characters. This task might only get 3 points on the difficulty point scale, especially when compared to scrolling. The effect is magnified if the user's hands are already in home position, or touch-typing position.

What interface do these observations suggest?

The complete example below is a list of about two thousand nine hundred programming functions in the PHP language. Click your mouse in the input box and type in "htmlent", and then press the "Enter" key.

How does this interface work?

The text typed by the user into the input box represents a search string. Immediately after each keystroke, the entire list of functions is searched for function names that match the search string. The matching functions are then shown in the selection menu, which has been fixed in size. When the list has been narrowed down to a single entry, the option becomes selected. The user can then press "Enter" to view that function's reference page. Alternatively, once the desired option comes into view, the user can click on the option to jump directly to the selected function's reference page.

What do the options "Starting With" and "Containing" do?

These control how the search string matches the function names. By default, only names that start with the search string are shown. But suppose a person knew that the desired function contained the word "html", but didn't know the complete name of the function. In this situation, the user could perform a substring match by selecting "Containing". In this case, all names containing the search string as a substring would be matched. Try it.

What does the "Load All Matches" button do?

By default, only the number of visible options are loaded into the selection menu, in this case ten. While searching is fast, adding all 2900 options into the selection menu is very slow for technical reasons.[1] Refreshing only the visible options is a workaround for this sluggishness. But it is reasonable since the user normally doesn't browse the list by scrolling, but begins by typing in the input box. For the situations when the user wants to scroll through the list, the button is provided to load the remaining matches.

What are the steps required to use this interface?

The first two steps are to position the mouse over the input box, and click and release the left mouse button once. These steps set the keyboard input focus to the input box. In most circumstances, these two steps can be automated, and therefore we can eliminate their cost.

We are assuming that user knows the item of interest, and that the user's hands are split between the keyboard and mouse. Thus, there are three steps required for this interface.

1. move one hand from mouse to keyboard
2. type the uniquely identifying portion of the item of interest
3. press and release the "Enter" key

What is the difficulty cost of the steps?

While step 1 and 3 are straighforward, step 2 requires some analysis. Obviously, typing an entire name is more time and energy consuming than typing a few characters of a name. In order to determine a difficulty cost, we need to calculate the average number of characters that uniquely identifies a name. Use the form below to run the analysis.

Some names are prefixes of other names, in which case the name can not be uniquely identified even if the entire name is typed. In this case, the user will take additional actions in order to select the name. Fewer than 10% of the names in the function list are prefixes, so we may ignore them in our estimate. Running an analysis showed that on average, 9 characters need to be typed to uniquely identify a function name. By comparison, the average function name is 14 characters long. [2] By using a substring match, we cut the effort required for step 2 by about 1/3rd as compared to having to type the entire function name. The table below lists the suggested difficulty costs.

How does this compare to scrolling?

Since scrolling cost about 23 difficulty points and this interface costs 10 difficulty points, the new interface is more than twice as energy-efficient as the scrolling interface. Try both methods with the functions "fprintf", "html_entity_decode", and "strlen".

Why is the default setting "Starts With"?

The default setting of "Starts With" is meant to prevent user confusion about how to use the interface. The confusion arises because the user usually expects to see that name being typed come up first. In actuality, other names containing that substring might precede that name and show first instead. For example, if the user is looking for "strlen", up until "strl" no functions that begin with the expected name show up in the list.

Why is it better to use the setting "Contains"?

The better matching strategy is to use the "Contains" substring match. This is because when the user is familiar with both the name and the namespace, the user can usually guess a shorter uniquely identify substring. For instance, to find "html_entity_decode", the user could type "y_deco" and arrive at the function name with only 6 keystrokes.

Can this matching strategy be improved further?

Taking this one step further, the user could type multiple substrings separated by spaces. In this case, the search would match every name that contains every substring entered by the user. Because longer names are usually concatenations of multiple words, it can be easy for the user to type parts of each word until the name is uniquely identified.

Where can I see an example of an interface that uses this matching strategy?

One popular application which uses this matching strategy is Winamp Classic 2.x music player. This application has a "Jump To File" dialog which allows quickly jumping to a song in the playlist. The dialog can be accessed by pressing the "J" key.

The Jump To Widget is an online version of this interface that is written in Java. It uses the same strategy described in this article.

Footnotes

(back to text)

Note the existence of the labels century, decade, year. These are important to signal to the user the meaning of the radio buttons on this unfamiliar interface.

1 (back to text)

Loading the options is slow because the selection menu is implemented poorly on most systems. What it does is recalculate the string width of each option in the displayed font each time an option is added. This calculation is very slow when multiplied by several thousand options. The calculated width is then used to either resize the selection menu width, or to determine if a scroll bar needs to be added. There are many ways to optimize this, but they must be implemented at the system level.

2 (back to text)

The average number of characters in a function name was 14.138073869520193. There were 228 prefixes out of 2897 function names. The average number of characters to uniquely identify a non-prefix function name was 9.296365680029973. The analysis was performed in Javascript using the obvious algorithm and took 25 minutes to run on a Pentium III 1Ghz. The code is embedded in the source of this document.