3 ms·

Why would you be exploring the options of the popup blocker if you didn't have it enabled, let alone changing them?

barrkel 16y ago
Chris, 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 ago
  I 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 ago
    This 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.

Chris, 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 ago
I 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 ago
  This 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.