Why do desktop applications place settings in one dialog?

Question

It's easier understand why web sites are doing it, but i'm not sure why desktops place settings in one dialog when, for example, multiple windows can be opened.

I once wrote an application with a Settings Topmenu and then as submenus the items which now always implemented at the left side in a icon list/tree. I liked it my way much better (it was a large program with lots of settings) and sometimes showing two different settings pages at once even turned out to be pretty convenient.

But the single-dialog settings box is so mainstream now, that I hesitate to implement it my way.

Answer 1

There are many reasons why UX designers make this choice

A few observations:

• Settings are usually "out of flow" from the main app. For example, a music app's main flow is selecting and playing music. Settings like file locations, album artwork settings, and themes are not in the main workflow of the app.
• Settings are visited less frequently, which means reducing their footprint in the main application to a single menu item allows the designer to simplify the UX and concentrate window space on more frequent functions.
• Settings can be complex to navigate and lay out:
  • There may be many settings, which often necessity their own layout hierarchy.
  • Settings may span diverse functional groups (formats, files, audio settings, simply settings, help, personalization, etc).
  • Settings often require some help text to explain how they work. Moreover, because they are used less often, the labeling needs to be clearer since users don't use them as frequently.
• Settings are often contained as a logical sub scope with in the overall application. That is, they can be separated both visually and functionally from the main application, which helps designers lay them out separately.

---

All of these observations help explain why settings are often placed in their own modal dialog box:

• It economizes space occupied in application menus since settings are less frequently used.
• Settings are often well scoped so they can be separated out visually into a dialog.
• Interrelated or dependent settings can be more easily visualized and understood by users inside a dedicated panel than inside the confines of a drop down menu.
• Modal presentation helps with the complexity and interrelatedness of settings since navigation can be specialized through wizards or tab controls which do not need to conform to the broader app or menu layout.
• The modal/dialog presentation helps visually separate an out-of-flow feature for users (this sounds marginal but it should not be underestimated).
• Dedicated windows/dialogs/pages give designers space and layout freedom to place labels and help interactions which wouldn't fit inside an application menu.

Different applications will meet some, none, or all of these points but this should help you decide whether modal presentation is the right layout for your specific application (the answer is not always yes).

Answer 2

I interpret your question to be the following - if that's wrong, forget this post :-(

Why are all settings put into one single dialog, with a left side navigation, instead of providing a menu structure which allows to open (amodal) windows for different kinds of settings (e.g., viewing preferences vs. file locations, "diverse functional groups" in @tohster 's answer)?

I can think of the following usage scenarios:

• Initial Configuration (user does not know any settings): Your users wants to quickly get an overview about all available settings (and default values). You can present a sequence of steps in the sequence of hierarchy nodes which is in some form logical. The user can see his progress while working down the list. Re-opening the settings menu to find the next step requires the user to keep track of his progress.

• Exploration (user does not know where to find a specific setting): This is easier when clicking through a hierarchy with details displayed on the side immediately. Opening and closing windows is more costly.

• Spot Changes: (user knows where to find the setting): Both the hierarchy and the submenu navigation support this equally well. There might even be a small advantage because there's less clutter when using your menu+window idea.

Now if I think about the relative importance of these three scenarios, I'd optimize for the first and second, since if the user doesn't find the settings he likes quickly in the beginning, my app may be uninstalled (I am quick with this :-). Even if there is a small benefit for the expert, I'd trade that for safety with novices.

I would guess that your idea of having multiple settings windows open can have some benefits when the settings interact somehow. But in this case, they belong into the same functional group, i.e., on the same page and not in different windows.

Hoping I answered the right question, nobi