What makes a good options/settings dialog box?

I was browsing the Worst UI You’ve Ever Used question, when I realized that many of them involved the options dialog of some application. This is obviously an ar开发者_StackOverflow社区ea where a developer could get "lost" easily, since there are often a large number of options available which can be hard to organize. (Especially to the stereotypical programmer)

So since I'm getting ready to design an options dialog for my own application, I was wondering: what makes a good options dialog?

Tabs? A hierarchical treeview like Visual Studio that sort of acts like tabs? (I'm currently leaning toward this)

What do you think?

Options windows tend to be crowded, cluttered, and confusing, making it hard for the user to find the option she or he wants. They are often thrown together at the last minute of design without a whole lot of thought or coordination with the rest of the design. That’s what makes them a common target of ridicule. Here’s how to avoid that fate.

Restrict the number of options. The fewer the options, the fewer things to obscure what the user really wants.

• Limit options to those that accommodate known individual differences in your users. For example, if your users come from different legacy systems, you may have an option to emulate the keyboard shortcuts of each system.

• Even then, consider that forcing a small number users to make a small change in habit may be worth the usability savings in confusion associated with adding another option. Remember that having a single standard UI for all users helps users support each other.

• Unless your app has a “playful” side (like Facebook), avoid options for trivial aesthetic preferences. Focus on options that improve the task performance for select users (e.g., options that support accessibility).

• Don’t use an option to force the user to make design decision you yourself should make. For example, don’t have options for choosing control locations or color coding color-by-color. Your users are not UI designers and in nearly all cases, you can come up with a better design compromise than your average user.

• Don’t use options to set attributes of the data (e.g., the margins of a specific document). Options are attributes of the application and should apply by default to whatever data is shown.

Organize options by function as your users see it. Consider using a card-sort method to categorize your options. Do not hide less commonly used options on an “advanced” tab or dialog. You may have statistics on the use of each option but your users won’t. They’ve no way of knowing if the option they seek is “advanced” or not, forcing them to search the Advanced junk-drawer tab in addition to other tabs.

Move functionality off of the Options window, and make it proximal to the place where the user decides to set an option. Rather than having an option to set a default, use the same interface for overriding the defaults. You can have a “Make This Printer the Default” button in the Print dialog. Include a “Keep View” menu item in the View menu that preserves across sessions the sort order, filtering, and column selections the user set for the window. Alternatively, consider automatically preserving the view –even window sizes and positions -across sessions, and providing a Default View menu item to revert it.

If you have a very large number of options, consider having a dedicated pulldown menu for them on the menu bar, with each menu item opening a different dialog box for each major category of options. Multi-tiered tabs or trees in dialog boxes are nature’s way of saying your Options window is too complex.

A dedicated Options/Preferences pulldown menu is also a good place to put three or four adapting/variable menu items that anticipate the options a user would like to set in a given context. For example, when an email arrives, a menu item can appear that sets the alerting parameters for new email (e.g., sound given, notification shown). When the user changes the default printer to something else, a menu item can appear to make that the new printer the default printer.

Use web-style graphic design, small illustrations, and visual hierarchy to make options easier to find and understand on a given panel. Use font size, color, and/or weight to make commonly used options salient, while still organizing all options by function. Something like:

Encourage easy exploration and experimentation of options:

• The checkboxes and other controls for options in the Options windows should apply instantly on selection so user can immediately see the impact of each option as it is selected. There should be no OK and no Cancel buttons, but only a Close button (there may also be a Reset or Undo button). It’s frustrating to open the typical Options dialog, select an option and hit OK, only to find one has set the wrong option and has to start over. Also, if the user selects multiple options, hits OK (or Apply), and ends up with a totally wacked-out UI, the user won’t necessarily know which option needs to be undone; the user may not even remember all options selected.

• Include “What is this?” Help for each option so users can find out more about what an option does and when it should be used.

• Consider making the Option window modeless, so the user can pan around the primary window to better see what an option does.

• Be sure all option names and their synonyms are in your Help documentation, and be sure the Help documentation shows the user exactly where to find the option. Often users may not know if an option exists, or if it’s an “option” or other kind of command.

Make the most common options easy to find, and the advanced options "optional" to even look at... Hiding the options 99% of your users won't care about is very effective.

The main issue is not overwhelming the audience. Options dialogs tend to be crazy, just because people put every option available in there.

Having a good, clean logical grouping of options, with common options easy, and "advanced" sections making the obscure options less noticable is usually more important than a specific layout.

I think this really depends on how many options you will have, what their logical groupings can be, and where they can come from (the application, external plugins, etc.) The tree-style dialog used by Visual Studio is a good choice because of the large number of options and the many plugins/packages which provide options that are manipulated in this dialog.

The common patterns that I've seen are:

1. The Visual Studio type dialog (tree view).
2. The Word/Office options dialog (particularly in Office 2007/2010).
3. A standard tabbed dialog (only a good options with a small number (less than 4) of tabs).
4. A single dialog with options grouped using group boxes (standard .NET style or Office style). This is only viable with a small number of options.

Not having an options dialog is best.

If you do however have a lot of options, making it searchable is really helpful.