Let's take this one step at a time
When you have a series of operations that simply must be performed in a specific order, it makes a lot of sense to make sure users can't do it any other way. A dialog box whose buttons must be pressed before any other part of the interface can be used is called modal; one that allows you to do other things is called modeless. Apple introduced modal dialog boxes in the original Mac user interface.
They were probably wrong.
The modal dialog box has become a way for shoddy programs to attempt to ensure consistency; it is a thorn in the side of any user trying to get real work done. To be fair, the worst of this is not the application modal widget (which keeps the application you're using from responding until you've handled it), but the system modal widget, which prevents you from doing anything with your computer until you're done with this widget. Application-modal widgets are annoying; system-modal widgets can be catastrophic.
The use of modal dialogs can be a usability nightmare, one that arises from the confusion of two different options: not letting the user do other things, and not letting the user see other things. Users may want to simply look at other parts of the display. Let them. They may also want to go complete some other task, and then return to your dialog box. Once again, let them.
This will not be an open-book test
For starters, you should not use a modal dialog box when asking a user to fill out any kind of form. Any kind of form. It doesn't matter how obvious you think the information is -- the user might want to look it up. (Don't think your user will need to look up his own name? He might not, but his secretary might.)
For me, the most frequently annoying of these is software registration. I start a program, I click on "register," and it asks me to enter a number -- a number that is in a window I am not allowed to bring to the front. I often have to quit the program entirely before I can go look the number up; in many cases, I end up having to use paper to enter the code. (How 20th century is that?) This is an example of something that probably doesn't need to be modal at all, especially in shareware programs.
Other forms are just as bad: home address, social security number, previous address, etc. Often, I need to look things up in a computer (I can't remember my last zip code, for instance), and it's very annoying when the computer refuses to let me look them up because it's waiting for me to enter them.
In general, an interface like this has a modal structure because (as it might tell you), "The program can't proceed until this information is entered." Think about this statement carefully. If I have two documents open, is it impossible to edit one until I've decided what format to save the other in? This doesn't sound impossible. Let the intrinsic limits of the task (for instance, you can't edit a document you haven't opened) constrain the user; don't add new limits.
Some programs lead you along a lengthy path of choices, not mentioning the most crucial ones ("Do you want to reboot now?") until the very end -- and not allowing you to do anything about the information you've just been given; there's no opportunity to go into another program to save your work before you reboot.
Apple is one of the worst offenders in this regard. Their installer is a marvelous example of an application that carefully, painstakingly does the absolute worst job it possibly can. First, it requires you to make all the decisions about an installation up front. Then it tells you you have to shut down all other programs to run this particular installer. Of course, the "stop/continue" dialog box is system modal. So, for instance, you can't go into another program, save your work, and return to the installer. If you choose "continue," most applications will offer you a last chance to save your work -- but if for some reason they fail to do so, you may not get a second chance.
Finally, often enough, the installer doesn't mention until it's finished that a reboot is required; worse still, the reboot often isn't necessary, especially if you're about to install other new software. This isn't modality per se, but it is an extension of the same problem: The installer is taking over the machine, and it shouldn't.
Dialog boxes that require you to respond to them before doing anything else are annoying, and, so far as I can tell, never reasonable unless it is the computer itself that's giving the warning. As an example of an interaction that could have justified a system-modal process, the Amiga used to emit the message: "You must insert the disk..." when a disk was removed before all of the buffers on it had been flushed. Amusingly, this wasn't modal -- the user could go do something else (such as close a window, finish a command) before responding to the dialog box. Amiga trusted the user to decide whether or not to ignore the dire warning and do something else. Trust is good.
There are a number of things you can do to keep modal dialog boxes from inconveniencing your users.
The first is don't use them. Don't fall back on making every interaction with the user an all-or-nothing fight to the finish. Allow him to fill out part of a form, check his e-mail, and come back to the form. Let him go into other programs and save his work when the program is about to do something drastic. Remember, always let the user do as much as possible.
Even the interface for opening a new file could usefully be non-modal. Imagine that I have a file open and I want to start a new one, so I select "new." While navigating the tree, I spot a file I had been looking for the other day, so I hit "open," open that file, and then go back to creating the new file. Does this sound silly to you? Ten years ago, the idea of having a word processor and a terminal program open at the same time sounded silly to a lot of people.
Design your interface around the idea that users might try to do multiple things with your program simultaneously, just as they might use multiple programs at once. Many modern users are multitasking and interrupt-driven (not to mention buzzword-compliant).
In the end, the purpose of a modal dialog box is to restrict the user's freedom. Don't do this. If you absolutely have to restrict the user's freedom, do so as little as possible. If you have to restrict it a lot, please rethink your strategy -- you've probably missed something.
If you can imagine the user having to get up and go over to another computer to do something before completing a task, chances are the task should not rely on a modal interface.
This week's action item: Pretend that each object on your desk is modal: Put down your pen before you take a sip of coffee; take both hands completely off the keyboard before using the mouse. If your friends are especially tolerant, or you already have a reputation for kooky behavior, try doing this with silverware. See how annoying it is?
- Get Apple's take on modal dialog boxes at Apple Developer Connection's Human Interface Guidelines.
- Usability expert Jakob Nielsen's useit.com site
features a range of articles, columns, and other resources on usability and Web design.
- Bruce Tognazzini is a recognized leader in human/computer interaction design. His AskTog site allows you to send him specific questions, and includes usability news and commentary from Tog himself.
- Usability First provides information and resources for key issues related to usability in Web site and software design.
- Read The cranky user: The principle of least astonishment for tips on how to meet user expectations and avoid unpleasant surprises.
- In the most recent Cranky User
column, Peter discusses how bad webmaster attitudes can stand in the way of a site's success.
- IBM's Ease of Use site offers new innovations, user-centered design, guidelines, stories, technologies, and other resources to help improve the total user experience for your products and services.
- Other installments of The cranky user column: Read about other Web and software usability topics.
- developerWorks Web
architecture zone: Get the Web development solutions you need.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
