5 ms·
If a change is not immediately visible, how would a Cancel button help? Preferences dialogs on Windows are modal, if a change is not visible you can't see the d
by chrisbolt 16y ago
If a change is not immediately visible, how would a Cancel button help? Preferences dialogs on Windows are modal, if a change is not visible you can't see the difference until you have committed the change. Especially so if a change requires a restart of the application or reboot of the OS, both of which would remove the Rollback button and the dialog it was attached to.
Also, the default font for an application is an appearance preference.
- barrkel 16y agoMy point about the font is that even when it's an appearance preference, and you have a nice preview, it's still a pain in the neck to get it back to the way it was before. There's also another aspect to settings. Many settings are logically tree-shaped: certain settings only apply if a dependent setting is in effect. A very simple example: Firefox's popup blocker has some settings - the Exceptions. But the Exceptions only apply if the popup blocker is actually enabled. You can't fully explore the configuration space of an application most of the time without running into these things. But you don't want to have committed to changing these settings just to explore the configuration space. The Cancel option on the dialog lets you explore without commitment. Now, you won't get an argument from me that the Apply button is useful. I think preference dialogs shouldn't be modal where reasonable, and that changes should be previewed across the application. That's not always the case in Windows, and it should be better. But on topic here is the Cancel button, and that's what's missing on OS X, and where I believe Windows has it trumped.
- chrisbolt 16y agoWhy would you be exploring the options of the popup blocker if you didn't have it enabled, let alone changing them?
- barrkel 16y agoChris, I brought up the popup blocker specifically because it was a very simple demonstration of the conditional / predicate nature of exploring the configuration space, not because of its intrinsic configuration worth. Your response makes me think you're not responding in good faith, and have little interest in honest discussion. The reason for exploring the configuration space? Are you serious? In order to discover what is possible to be configured, of course! Take another example. I'm interested in protecting my privacy, but not at the cost of too much convenience. So I'm interested in clearing some history when my browser shuts down; but not things like cookies or saved passwords. In order to discover what options are available here, in Firefox I need to enable the "Clear history when Firefox closes" option in order to discover how configurable it is. But I don't know how complicated things are going to get when I click on that Settings... button, and I certainly don't want my cookies etc. cleared prematurely, but I can comfortably stride forth into it, because I know I can hit cancel at any time and back out.
- chrisbolt 16y agoI do admit it was wrong of me to suggest that you would not explore the options of the popup blocker if you did not have it configured. Maybe this is because the predicate nature of exploring the configuration space is less common on OS X. For example, when configuring Secondary Click for my Trackpad there is a dropdown that is enabled whether or not the checkbox is checked, allowing me to explore the options without checking the checkbox. Why disable these options? This seems like a better solution than having a Cancel button. I also suspect that the Cancel button is just masking another problem, that settings dialogs get nested so much that you forget what you changed.
- bricestacey 16y agoThis is definitely a problem. If you apply/ok a submodal but then cancel the parent modal, I believe the original apply/ok sticks. This tree-like UX is bad and should be avoided.