August 23, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

User Choice, Customization, and Confusion

  • January 18, 2005
  • By Mike Gunderloy
  • Send Email »
  • More Articles »

The Dreaded Tools...Options Dialog Box

All of the customizations that I've discussed so far in this article have been very generic. They apply equally well to a great many applications. Beyond that, of course, your application may require its own customizations. For example, there may be a default directory where you look for templates, or perhaps a set of colors that you use when portraying new objects on a drawing canvas. Such choices are typically wrapped up in an Options dialog box accessed from the Tools menu.

Many applications today expose dozens or even hundreds of customization options in this way (Microsoft Office applications are prime offenders in this regard). With software being as large and complex as it is, it's easy to understand where these choices come from. Developers look at their work and realize that they're about to hard-code something: a number of files, a path, a display status. Rather than placing a constant in the code (which we're all trained to think of as somehow inelegant) they decide that this is something that could be put under user control. And presto! Another user customization option is born.

The fallacy here lies in the assumption that just because something can be placed under the user's control it should be placed under the user's control. When faced with the opportunity to add another customization option to your application, you should consider three questions:

  • Is there a single best setting for this option that will be optimal for every user of the application? If so, you should code that setting and eliminate the option.
  • Is the option setting something that will only need to be updated only occasionally by power users, perhaps with the aid of technical support? If so, you should consider exposing it via a Registry setting rather than in the user interface. Alternatively, you can ship a separate utility application that performs the customizations, but which won't be obvious to the casual user.
  • Is the option setting something that the user will only choose only once? If so, prompt for it during installation rather than exposing it in the user interface.

Be Smart About Customizations

As with many other things choices in user interface design, there are tradeoffs here. The more users you have, the more likely it is that someone will appreciate the ability to change some setting that you thought should be fixed. But the more settings you expose, the higher your support costs will be, and the more confusing your application will be. Most users seem to feel that dialog boxes which spread dozens of option settings over several rows of tabs go too far.

It's all too easy to say "Oh, add an option" when you're developing an application. But keep the end user in mind before you do so, and try to decide whether there's another approach that makes better sense. That will help both you and your users in the long run.


Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his latest books, Coder to Developer and Developer to Designer (from which this article was adapted) from Sybex. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel