|List Box Tweaks (Part II)|
|An Introduction to Designing User Interface Controls at SAP|
By Jens Heuer, SAP AG, Usability Engineering Center – September 1, 2000
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.
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.
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).
Figure 2: Using the listbox extension
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:
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:
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:
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.
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.
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:
Figure 3: Example of an in-place error message
Whatever kind of error occurs, you should always take care that the list itself only contains valid entries.
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:
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.
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:
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) ".