Hate dialogs, love user interaction?

This article was first published on 1 November 2005. This type of interaction crystallised thoughts I'd had for a long time. It is now commonplace though the first were introduced long before this article so I cannot take any credit for them.

Hate dialogs, love user interaction?

“What’s that? What do I do here?”


If you’re like me, you probably dislike dialog boxes as a necessary evil. I know that they are ubiquitous and appear in almost every application, but still I find myself considering new ways to implement what they do. Here, I propose a different way to implement dialogs for applications that doesn’t use awkward boxes.

Let’s start with a definition of what a dialog box is. A dialog box is a GUI element separate from the main window of an application that provides information to the user, and may (but not always) require information in turn. The need behind them is important: programs will
“I have to go back - can I keep the dialog on screen to remind me what I’m looking for?”
occasionally need to interact with a user before an action can be continued, for example, changing the font of a word in a word processor. However, these bits of information are not required often and presenting the communicative components (the bits that actually interact with the user) on-screen all the time wastes screen space.

“Yuck! - Dialog boxes!”

I dislike dialogs for two main reasons.

1. Dialogs interrupt work. When a dialog appears, the user will pause to try and understand what it wants and what they have to do to get rid of it and complete the task they wanted. This means taking time off from their task. A complex dialog can severely affect whether the task is accurately recalled. I have observed and experienced myself how I can forget what I was doing because I was concentrated upon a dialog too much. Reminders such as dialog box titles can help, but they only inform the user as to what their subtask it and not what their main task was. But sometimes programs require lots of information, and that is unavoidable. This is where the demands of an interface should be kept as low as possible; to prevent an interruption that forces recall from long term memory. The designers task is to ensure that the interface presents as little challenge to the user as possible. Try this dialog to see how some designers feel that
2. They are not always but commonly modal - the window from which they came cannot be interacted with. This is a problem if the dialog needs information that can only be gotten from the main window but isn’t visible. In that case, the user needs to consider the information need, memorise it, cancel the dialog, find the information, memorise it, remember the way the dialog was created in the first place, do that action to produce it, remember where the necessary information was supposed to go, remember the required information, and put it where it was supposed to go.

Though this is a long description of what happens, it seems onerous to do this. Further problems arise if the dialog box is overly complicated and more information is required. Then the user needs to remember what is now needed, cancel the dialog, find the information, re-create the dialog, find where the new information is supposed to go, input it, and then input all the information that was required before. This begins to put an unreasonable strain on the user when the user shouldn’t need to remember all this information. Computers are good at recalling information and we should use them for that.
Some dialogs are not modal and allow interaction with the main window. However, modal dialogs are sometimes necessary, but I feel they are used far more often than they should be.

The second point is difficult to deal with - when a program requires infrequently used information, the associated interface will probably be rarely encountered. The first point, however, can be dealt with.

Integrated dialogs

Here is a mock-up of an interface that I’ve worked on. This interface uses the typical modal dialog box and is of a commonly encountered type for a rich text editor. The dialog is a search function for finding text.

As you can see, this is nothing new, but the dialog obscures the content. User can move it of course, but this requires user intervention that is not task related; other things will be obscured too.

The next interface though is of what I call an “integrated dialog". Instead of using a separate dialog box, the interface is embedded into the main window of the program. What happens is that when the program needs extra information, the main interface moves down (gently scrolls, but not too slowly) to reveal the information needed.

Screen space for the main windows contents is reduced when the dialog is on-screen, but this is only for the duration of the dialogs existence. Once the user has provided all the necessary information, the dialog appears and the screen returns to normal operation. This above dialog mock-up is simplified, but the space taken can be increased as needed.

Benefits

What benefits are there of using this type of interface?

1. The main window is still open manipulation. If the user needs to retrieve some information from the main window to complete the dialog, they can just interact freely with the window.
2. The dialog can be completed piecemeal instead of having to do it in one big chunk. This lowers the memory demands of more complex dialogs.
3. The dialog remains on screen when the user is retrieving this information. I have sometimes seen users re-create dialogs just to refresh themselves of the information needed to complete the dialog.
4. Coloured guides can (if relevant) point to and remind the user of what part of their content is being manipulated. For file dialogs, they will not be needed, but for changing the font or style of a piece of text, this information can remind the user of the content which might provide cues as to the context of their task. This will help the user recapture their task if it is forgotten.
5. Only a relatively small amount of screen space is used, possibly less intrusively than the normal dialog because it uses the width of the application.

There are situations when such a dialog should not be used. The most obvious is when the program demands that the user not change or view the contents of a screen; the second is when the dialog requires a large amount of information from the user and too much screen space would be taken. For the second one, it may be better to break the dialog into separate pieces or find some other way of getting the information from the user.

Conclusion

Computer programs can perform complex tasks, but these in turn have complex information requirements from users. Interfaces that elicit this information from users may have to be complex, but reducing the cognitive load to the user can often be beneficial to the user completing their tasks.