Is it possible to make a "good" options dialog?

Question

One thing I'm struggling with, and have yet to see an example I'm happy with, is an options dialog (in a desktop app, if that makes any difference.) I'm having difficulties with my own, but they all seem to have the same problems. To take a more generic example:

There's a few common problems that I see:

• Discoverability is poor; even when grouping into categories. The most common method of finding something in an options dialog seems to be Googling what to click on!
• Grouping is poor - the "Advanced" tab seems to be a huge culmination of "I don't know where this goes".
• Explanation of individual functionality is poor in many cases, as it would require a lengthy explanation that doesn't fit on the label.
• Not to do with the above screenshot, but they're not even named or launched consistently. Years ago, it always seemed to be Tools -> Options. These days it seems it's either under the "Tools", "File" or "Edit" menus for those apps that still use traditional menus, and could be called "Options", "Preferences", "Settings", or anything else vaguely relevant.

Some of the better "options" screens I've seen are those in browsers; Chrome for example allows you to search, which arguably improves the discoverability:

However, even in this case you have to search for the exact phrase or word that you're after. Searching for "Do not track" for example will get you the option to send a "Do not track" request. Searching for "disable tracking" will leave you empty-handed.

The solutions that I can think of aren't really feasible:

• Slim down the options dialog and put only the most common options there (it always starts small, but many of the options present are there at user request!)
• Do without the options dialog and find other places to put customisation, such as a toolbar or ribbon (anecdotal, but I've found this just makes it even more annoying to find what you need);
• Use help icons for longer explanations of option functionality (surely no-one would actually use them?)
• Create more categories to get rid of an "Advanced" or "General" category (then you just end up with a whole heap of categories you can't really navigate, some of which only have one option in them.)

Are there any good examples that I'm missing, any known solutions to these problems, or any relevant literature in the field for creating an options dialog that doesn't completely suck?

Answer 1

Software development IDEs have some of the most complicated settings pages I've ever seen, and IntelliJ IDEA does a great job with discoverability. Not only do they offer a search to narrow down the left "tree" to matching pages, they also have a special highlighting effect for matching options. This is similar to your Chrome example, but even better since it doesn't lose the original layout and hierarchy of the unfiltered options.

To your solutions:

(All quotes are from the OP)

• Slim down the options dialog and put only the most common options there (it always starts small, but many of the options present are there at user request!)

Please don't slim down too much! certainly you could make a "common" settings page but we power users hate it when there's no way at all to change something

• Do without the options dialog and find other places to put customisation, such as a toolbar or ribbon (anecdotal, but I've found this just makes it even more annoying to find what you need);

This is always good practice, but in addition to the options/settings dialog. It should be a one stop shop for all customization of the software.

• Use help icons for longer explanations of option functionality (surely no-one would actually use them?)

I think people would use them, and more importantly, it would be additional text that could be matched by the filter at the top of the dialog. If the option was "Export to CSV" and the help text was "Export files to comma-delimited files that can be opened in Microsoft Excel", then that allows for queries "csv" and "excel" to match that option.

• Create more categories to get rid of an "Advanced" or "General" category (then you just end up with a whole heap of categories you can't really navigate, some of which only have one option in them.)

Yes, to an extent- no categories with one option, but removing "General" and "Advance" and organize in a tree (if there are too many for a simple list like Firefox or your Word example).

Answer 2

Root Cause: Implementation Driving UI

The whole idea of a single consolidated Options dialog seems to be a consequence of programs having configuration files. The Options function would read the configuration file, present it to the user in a dialog for editing, then save the changes back the configuration file. Perhaps some other programs do the same thing, only reading and writing to the Registry. The implementation, rather than the user’s tasks, is driving the UI design, which often a bad thing. It makes it convenient for the programmer, but not the user.

With the possible exception of when a user first installs a program, a user generally doesn’t think, “Today I’ll change my options.” What happens is the program is doing something specific that isn’t what the user wants (e.g., by default pasting to match source format). So users (if they’re savvy enough) think, “Maybe there’s an option for it,” and embark on a major safari to hunt it down in a jungle of options, assuming it exists. No wonder it doesn’t work.

Addressing Discoverability: Options Proximal to Affected Features

The solution is to put the options with the feature it affects. Don’t have all options in one massive dialog. Distribute them around your menus and dialogs. For example, for changing the default pasting, the Edit menu has a Paste Options menu item below the Paste menu item. Paste Options opens a simple dialog to select the default pasting behavior. Or there’s a Paste Special dialog that includes “Make this Default” so when users select special pasting behavior for a particular instance, they can also make it permanent. This improves discoverability. Or maybe there is simply "Editing Options" if there are also options for Copy, Undo, and Delete (otherwise, your menu has nearly as many "options" menu items as all the other more important ones). When the user executes the command in its menu or ribbon tab, they see there are options for it. It reduces workload, because the users don’t have to search through a zillion irrelevant and questionably organized groups of options to find the one they need. Options are organized exactly like (with) the associated features, which the user already knows or else couldn’t be using the features.

Options by definition are preserved between sessions, so they are most appropriate for things that are very rarely changed. For this reason, it’s important not to clutter your UI with Options menu items and command buttons since they’ll get in the way of what users are usually looking for. You probably should have no more than one Options button per dialog and one Options menu item per menu or ribbon tab. That may not be as strict as it sounds. Going through MS Word’s options in your example (which is among the more extensive), I see there would be:

• A Cut/Copy/Paste Options menu item on the Home tab.

• A Format Marks Options menu item on the View tab.

• A Proofing Options menu item on the Review tab.

That’s about it.

The rest of the options are either put under an Options button in a dialog/page (like Save and Print options), or they are options that aren’t associated with a menu or dialog, so they have to be handled differently (see next paragraph).

Addressing Inconsistent Locations: Have a Preferences Menu

There will be some options that don’t have an associated menu or dialog box, such as “select entire word” in your example. So you still need some kind of centralized place for setting them. However, they are fewer than the total number of options, so it makes them more findable, assuming it isn't best to have the same options both proximal to their associated feature and in a centralized location to maximize their discoverability.

You are correct that there is now no standardize place for them. Microsoft had “Tools” as a standard for a while, but “Tools” is like “Advanced” –a junk drawer of things that don’t fit anywhere else. Apple’s standard of putting Options in the application menu (the menu with the name of the program) sort of makes sense given the paragraph above because these are options of the entire program, not just a specific feature.

However, my advice is to have a Preferences menu at the top level (a pulldown menu or ribbon tab). The place for options is their own place, not under any other menu or tab. This maximizes discoverability: the users see “Preferences” (or “Options,” or maybe “Customize,” depending on your users) every time they open the app. It doesn’t matter if the user is expecting Options to be under Tools or Edit or the application menu. They immediately see it at the top, and don’t bother to look anywhere else.

Space or clutter is generally not an issue especially for menu bars. After File, Edit, View, and Help, most apps don’t have a whole lot else. If there are only a few options (eight or less), the Preferences menu has toggling menu items to set them directly –there is no dialog box. If there are a lot of options, split them up into separate dialogs and access each with a separate menu item (rather than have separate tabs within a dialog). For in-between numbers of options, have a mix of toggling menu items and a dialog or two.

Addressing Poor Explanations: Active Help

As addition to, or perhaps as a better alternative for, a Preference menu, give Help the ability to change preferences. Take “smart paragraph selection” in your example (whatever the hell that is). A user is not going to think, “This dang smart paragraph selection! I wish I could turn it off!” They’re thinking, “This selection is doing something weird; why is that?” So they naturally go to Help to learn more. If the index and search are decent, and the content clearly written, they find out about this smart paragraph selection, and how it works. Maybe once they understand it, they want to keep it. However, if they don’t, then Help should provide the means to turn it off right there in Help. It doesn’t direct the user through multiple steps in an Options dialog to effect this. It’s not like users need to learn that –they’re only going to turn it off once then forget about it. Let them do it right there.

Putting options in Help means searches don’t have to match the options name exactly –it can match any part of the explanation. They can also match any synonyms, assuming your search provided for that. Users get the whole explanation, so they can better determine if it’s the option they want or not.

And Installation?

Consider on installation presenting the user with a list of commonly change options, showing what is default, and allowing the user to alter them right there (e.g., default folders, devices, and such). However, often users need to use a program before they discover what does or doesn't work for them. Thus, it's important to make options reasonably discoverable after installation too.

Answer 3

I posted a related question recently as I have been struggling with a similar problem. From what I have mustered there is no clear and clean cut solution, as these kinds of "options" are often very contextual. This article briefly covers and provides some well known examples.

However, I still feel that there is much to be done in terms of design solutions for these types of menus.

One other article, which I found to be useful, covers the redesign process of the Firefox Options menu. I believe the underlining message is that we need to get our design thoughts and iterations in the face of the users and see what comes up. That is what I will be doing and I'm hoping for an unexpected "Eureka" moment.

Answer 4

Grouping can be improved by drawing a line between "Configuration" and "Preferences". Everything that the user has to configure to get your app running should go to "Configuration". Everything optional, which can actually be a matter of preference, should go to "Preferences". For example, I hardly have a "preference" for the default printer (it has to be the one in the same physical office as me) or the path to my autosave folder (it has to be somewhere I always have write access).

The next step is to take a good look at your preferences. Do they actually need to be there? For example, I can't think of a single good reason for "Use Ctrl+Click to follow hyperlinks" to be a preference. If the user doesn't want to follow hyperlinks, all he has to do is not to click. Or "Use smart cursors". If they're really smart, why on Earth would I want to disable them? And if they're not that smart after all, why are they implemented at all? Bottom line, try to make your app as intuitive and easy to use as possible, and remove the option to make it less intuitive.

Finally, learn to refuse user requests. This may cost you some customers, but believe me - a cluttered Preferences dialog costs you just as many, only those users are not vocal about it. Next time a user asks you if you could make a smart cursor which magically jumps to the other screen when the user claps their hands, just say "No".

Answer 5

A modern solution could leverage a neural network, trained with various commands and the associated menu items. Think about how Cortana, Siri, Alexa, Omega, and Google function. You type in a command or speak something, and your device does it for you (or at least pulls up the place where you can do it). You can offer an "Advanced" menu for people who want to just find their items in the normal manner (category/sub-category/items). Given your example, a user could say "I want to disable tracking", and the neural network would divine that they are looking for the Do Not Track flag.

Even if you're using an omnibox sort of solution, like Google Chrome, simply implementing a neural network can give the users a better experience, especially if they allow uploading anonymous usage statistics. For example, a few users type in "disable tracking" and then clicked on Do Not Click, so this would be trained in to the neural network. Over time, as more anonymous statistics were collected, the options dialog would actually get smarter the more the users interacted with the options dialog.

Even without crowd-sourcing your data, you could still pre-train the neural network with multiple phrases/keywords for each menu item, and as each user starts using the menu system, the options dialog would eventually be tailored for their specific use patterns. The entire point is that the menu could learn from how its used, rather than forcing users to learn how to use the software. There would still be something of a learning curve, but I think the eventual end goal would be worth the effort.

Answer 6

Without reinventing the wheel or blowing up the idea of Preferences dialog box, I think the single most user-friendly improvement is to have an area within the options dialog box where a paragraph-long explanation of each option appears when you select it or hover on it. One of the things that makes Preferences difficult is trying to cram the explanation for a program-wide change into a few words. "Enable Smart Quotes" is easy to understand, but even it could benefit from a longer explanation. I've admired the way Adobe in some programs implemented in-depth Preference explanations.

Answer 7

As I see it, there are really only three major goals in an Options menu:

1. Find what you want quickly and with as little exploration as possible.
2. Understand what a given option does as easily as possible, preferably without resorting to dedicated Help windows or web-searches.
3. Make changing the option as clear and direct as possible. (usually a given, you can't go too far wrong with a tickbox)

The first task, finding what you're looking for is one of the most variable I've seen, some systems present you with a wall of options with some organisation by category or even alphabetically. Some provide only a questionaire-style FAQ system. Search boxes are popular because it allows for natural-language queries.

Personally I'm most comfortable drilling down by category until I find the one place that has exactly what I need. I believe that a system should support someone searching, but it also needs to be quick for someone who knows exactly what they're doing. No need for a quiz or natural-language search when you already know how to get where you're going.

A good Options menu will have natural-language search, but also lay out all the options in a navigable fashion, clearly organised by function. The human mind is built to visualise locations, not key-phrases. So a mappable menu is very intuitive. If I make a search, it should show me the results, I select one, it navigates there and I can see where I am in the menus on a side-bar.

If I then want to find that place again, I can navigate quickly through the side-bar until I get there, or I can use a History system to find my previous searches.

The second major task of comprehension is rather simpler. Provide a plain-text explanation of functionality with a link to a more in-depth explanation if they need it. I suggest using the common convention of a ? symbol in a circular button, this can reveal a floating textbox which has the full explanation, either when clicked or when rolled over.

Beyond that, clear partitioning and use of iconography will be of great help.

Associating the specific options with buttons the user is already familiar with (eg: the ones in the main UI of the application) will help them find what they want too.

For an example, if I'm looking for an option to affect Fonts in a word-processor, I will be greatly assisted by seeing the Font button's icon in the Options menu and being able to follow that.

One could also add a context-sensitive options system into the UI itself. So if I right-click a button in the main UI, it should include a link to the appropriate section of the Options window in a context-menu. Instantly doing away with the need to navigate from any sort of landing page.

Further to that, adding buttons for toggling the most common changes (either by that user, or from anonymous usage data) to that same context menu would also be of great help.