So let’s say you have an Outlook Add-in that needs to be disabled. How to do it? Simple… Tools > Options > Other Tab > advanced options button > add-in manager > uncheck the appropriate add-in > click “OK” - Done. That, is unless it was a COM Add-in, or a custom form… in which case you do a different thing. At this point you might start wondering how such a monstrosity was ever designed.
Well a funny thing happened on the way toward shipping the product. Somewhere along the line, two people disagreed. One said feature X should work like this, and the other said it should work like that. A developer raised his/her hand and said: “how about putting it in tools > options?”. The parties looked at each other:
A: “So how many people will this effect?”
B: “Probably less than 10% of our base…”
A: “Heck, ok then - Tools Options.”
If it didn’t happen that way, then it might have happened this way:
Developer: “I know people who would want this feature to work either way… I’ll just put in an option. That’s the most democratic approach.”
Oh and lastly:
Product Support: “If you change that option, customers will have to retrain their staff to go through those other dialogs - let’s just keep it like that for one more release.”
You can see how this might lead your options dialog to distress. Add on top of all this, that the fundamental interaction of an options dialog makes it difficult to understand how your adjustments will be represented… and over time you’ll be left with a user experience disaster.
To avoid all this, you must simply:
1. Do fewer features.
2. Place options and settings in context (many people do not right-click either, but at least when the option is adjusted, you know what will be affected)
3. Pick a right way of doing things - don’t leave it all to “user preference.” Sometimes cutting off one pathway hurts less than providing an option, because removing that path means one less thing for *everyone* to understand.