Quincy, Thanks for the feedback...right now I think I need to take some additional time and prototype some possible UI changes for more feedback.
Problem with this situation is that it is difficult to get feedback...so essentially I'm told "add options, and then keep it the same"...which doesn't really work. So when I make significant changes its not usually a good thing...so I may be fighting a losing battle anyhow. Thanks again, jeremy On Sep 1, 2011, at 4:42 PM, Quincey Morris wrote: > On Sep 1, 2011, at 11:48 , Jeremy Matthews wrote: > >> It's an internal app for "power users"...and its been a struggle to reduce >> it so far. >> I've been told that the current options need to stay put....so no reducing >> for the moment. > > There's no useful discussion possible without more information about what the > options represent. I don't mean proprietary information; I mean information > about how the options are used. > > Are the options theoretically independent? Independent in practice? Are they > preferences (adjust app behavior in advance), or optional sections of > processing (skip over things), or input parameters, or …? > > For comparison, I just looked at iTunes's column header context menu. The > purpose of this menu is to allow you to choose which columns you want to > display in library listing. There are 39 independent choices in the menu > (columns that may be shown or hidden independently), plus two "Auto something > or other" commands. > > This is not a case where the answer is, "There are too many options, reduce > them." (Though perhaps in a different discussion, that point could be > argued.) This particular UI works because users *typically* want to make only > a few choices different from the default, and that only occasionally. > > If it should happen that there was a practical need to change the column > display frequently (dozens of times per day), choosing individual columns > from a context menu would get very old very fast. In that case, the only > practical choice might be an array of 39 checkboxes. > > My point is that your usability requirements will drive your decisions about > how to present the options. We don't know your usability requirements, so we > can't do much more than sympathize with your dilemma. > > Don't forget to be creative in the UI variations you consider. For a set of > on/off choices, as well as checkboxes you can use menus (with checked items), > tables (with selected or checked rows), dual tables (with "off" options in > one table and "on" options in the other and the ability drag between them) > and text fields (with option names that can be typed in, instead of check > marks). Can you use presets for obvious combinations of options? > > If you're maintaining an existing app that has all these options, how about > modifying the app to collect statistical information about how and when the > options are used. Will that give you a clearer picture of what might actually > improve the app? > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
