Design Tidbits

back Tidbits Overview

Tools for Design and Visualization

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

From Dropdown Listboxes to Comboboxes

By Jens Heuer, SAP AG, Usability Engineering Center – September 1, 2000

Introduction

Sometimes, creating applications for the web can be a pain in the neck. Especially when you come to realize that things would be really easy if you were just using standard development tools.

As a matter of fact, web development leaves you with only the most basic interaction elements: buttons, input fields, check- and radiobuttons, and dropdown listboxes. So if you need something more than that, it's time for some workarounds.

Let's have a closer look a the dropdown listbox (DDL). In it's current implementation, a DDL is just that: a simple list that has a fixed number of entries and is not very helpful in selecting an item with the keyboard. Basically there are two ways to make a DDL a bit more useful: We can either try to extend it's positioning capability by typing more than the first letter of an entry; second, we can combine the selection of items with a way to let users add new entries into the list. In this article we take a closer look at the latter approach.

Note: There is a page with a working demo and the javascript code.

Comb'o'nations

Sometimes you get to the point where you just want to see that one entry that's not contained in the DDL. Well, if the developer had foreseen this, he probably would have provided a separate input field to allow you type an additional item number or description. You would, however, have to first select the radiobutton that tells the application to accept the input from the input field rather than from the DDL. And then it seems a waste of space to have this extra field in a separate row in your MiniApp - to enter something you maybe only need once a week.

Using two fields for input

Figure 1: Using two fields for input

A much sleeker design would result if we could combine the input and the selection into one interface element, as figure 2 shows (Note you could even omit the 'Go' button in this design).

Using the listbox extension

Figure 2: Using the listbox extension

In the next paragraphs I will explain how this works using a little front side javascript scripting. You can also see a working demo and the respective javascript code.

The Principle

An obvious solution would be to use a dropdown combination box ("combobox" for short). This combobox allows you to select values from the list as well as enter new values which subsequently get added to the list. The sad thing is that we don't have a combobox for the Web yet - it will available only with the upcoming XHTML standard and browsers that support that standard.
So the idea is to create a combination of selection of input and selection with the features HTML has to offer. We need three "ingredients" to achieves this:

  • An extensible selection - we can take the standard DDL here
  • An input for new values
  • A 'link' between selection and input

The actual idea is quite simple. We take a DDL that contains the items that a user normally selects plus an extra item called "new value." When the user selects this item, it means that she wants to create a new entry in the list. The DDL could look like this:

DDL

The next step is to create an entry prompt when the user clicks on "New value." To make the interaction as simple as possible, the prompt is displayed in a very small modal dialog window which looks like this:

small modal dialog window

After typing a value and either choosing "Enter" or clicking "OK," the dialog box closes and the value is added to the listbox in the application. Note that the newly typed value should be activated and displayed in the listbox, so that a click on the "Go" button immediately makes the correct selection.

listbox

Since this value is entered into the list, the user can make a selection rather than typing the next time the same value is needed.
Voila: Although it's still a workaround, the listbox now almost behaves like a real combobox - and you don't even have to wait for a new browser. However, there are a few things to note when you are planning to use this technique.

Checking for Errors

Essentially, errors can occur in two situations: the user mistypes a value (e.g. using letters instead of numbers) or the input has the correct format, but is not found in the referred database. The first category of errors are syntactic, while we'll refer to the latter as "semantic" errors. Depending on the type, there are basically two ways of avoiding or handling them:

  • Syntactic checking is possible if the input field has a simple and consistent format (e.g. only numbers). The check can be performed in the background even while the user types in a value. Error messages should be presented in the dialog itself and the user should be prevented from submitting an erroneous entry.

Example of an in-place error message
Figure 3: Example of an in-place error message

  • Semantic checking is a bit more difficult, since the correctness of the new value is only known after submitting it to the list and clicking "Go" (i.e. after querying the database). If an error occurs, a message should be issued and the value should automatically be deleted from the list.

Whatever kind of error occurs, you should always take care that the list itself only contains valid entries.

Remember Me?

So, now that the user has added some additional values to the list, the question is how long they should be kept in there. We'll call this the question of 'persisting' the entries. There are three different ways of handling this persistence:

  • Never persist. Means that the new values are used only once, immediately after selecting them from the popup. They would never be entered into the list, so the user is required to reenter the value every time.
  • Persist until the session ends. The values are kept in the list until the user exits the "session" (e.g. closes the workplace). All newly added values would be available while the session lasts, leaving a clean list every time the application or session is restarted.
  • Persist permanently. Values are always kept in the list, even after the end of the session. This requires some way of limiting the number of list items (a good rule of thumb would be to have no more than 20 items). If more items are added, provide some automatic "cleanup" that throws out the oldest or least used entries in the list. The initial items should always be kept; the cleanup should only effect items added by the user.

The type of persistence you should choose depends entirely on the task to be performed. If the new values are used rather seldomly (e.g. someone has to look something up for a colleague who's ill), the session-length persistence is a good bet. If the task is to maintain a sort of history or most recently used list, you should go for the permanent persistence method.

When to Use

As I've said before, this listbox extension is a workaround and may or may not fit a specific usage situation. Here are just a few rules of thumb where this technique might be appropriate:

  • If the number of list entries cannot be determined beforehand
  • The selection of values is the standard and entering new values occurs relatively seldom
  • To save space, especially in a MiniApp.

Obviously, there are a lot of alternative solutions to the same problem - and this is one of them. In my next article I will present a way to use the keyboard more effectively to search listboxes with many entries.

 

See also the second article about listboxes, "List Box Tweaks (Part II) ".

 

top top