Say you are developing a desktop application, and you want the user to be able to customize menus, buttons, keymapping, and other commands and components. How much customization should be allowed?
I like my environments to be pretty much infinately customizable. I also want the environment to have a good set of defaults so I can just tweak the settings I need rather than having to set up the whole thing. Does anyone have any user experience to point to to support or contradict my preference?
keep in mind that every option / customization you add is going to make for a more complex program, which will be both harder to use and to maintain. If it's something only a small percentage of people would use, I would ask if it is worth it.
When it will make a significant positive difference to the users to allow customisation.
Essentially it's like any other requirement - it needs to justify the cost / effort to implement it. That may be increased productivity or usability, or it may be some level of increased user satisfaction, but there should be some reason for doing it which justifies the effort involved.
As someone who likes customisation, the questions you should ask yourself are:
If I were paying, what would I pay for this level of customisation? How many people like me are there? And would that cover the cost of developing it?
What do my competitors do? What is the expectation for products in this area?
If instead of spending the effort making it customisable I were to expend that effort on other features, which would I prefer? Is this true for typical users?
Remember, everything you choose to implement is really something else you're choosing not to do (at least for now) so everything needs to justify the effort needed.
Ask yourself why you want to let the user customise each little thing. Is it to avoid making design decisions yourself, forcing them on the user instead?
Here's a good post by Jeff on the subject: http://www.codinghorror.com/blog/2005/09/the-problem-with-configurability.html
Users, in general, hate applications that are so poorly thought out that they have to customize to get their needs met. In my experience, most users are not as comfortable using a computer as an IT person and will not customize even when given the option.
If you are customizing in order to avoid doing a proper job of designing, you are customizing too much. If you are customizing because you like customization and not because it is a requirement, you are customizing too much. If you have a genuine requirement to customize, you should still question if it is a good idea and find out the underlying reason why they think they need customization. Often you will find a new requirement they hadn't mentioned if you use a requirement for customization as a place to start a dialogn with the person doing the requirements.
It Depends on the Application
This may sound like a cop-out, but it really isn't (or, at least, isn't meant to be).
The amount of customization should be, in part, dependent on the sophistication of the expected end user. Engineer types are much more likely to get in and tinker with the user settings than, say, my Grandma playing solitaire on a Win98 machine.
It also depends on what the application itself is. If the point of the application is ease-of-use, you don't want to muddy that with a bunch of user-configurable options.
Too many configurable options makes an application seem overly complex. If you create an application that has a lot of these options, I'd at least "hide" them in an "Advanced..." configuration screen or dialog, and only put a subset of things that the average user of that application will want to change on the "regular" options screen.
Another alternative is "skinning" something. That may mean the traditional "skinning" stuff (for example, the "Appearance" tab on Windows Display Properties), or it might mean a set of options that are set all at once (for example, the "Themes" tab on the same dialog).
I generally don't bother. I've had to work on a lot of different machines, and keeping them all customized would be more of a bother than it appears to be worth. If I do customization on one machine, I'll be annoyed when another machine doesn't have it. Making it easier to move customizations around would help somewhat (consider emacs users and their site-lisp files), but often I'd find that too much bother anyway.
If your app won't work well out of the box, but needs to be customized, you've failed.
I do want my favorite software on a machine, but I don't think that's what you mean by customization.
One issue with customizability is that it's a promise to each and every customer that you have to respect. You send out version A, and your customers customize. All well and good. Now, what do you do with version B? If you break your customers' customizations, they'll be upset, and if you do it more than once, they'll be very reluctant to customize, so you'll be left with customization functionality that very few people use, along with annoyed customers.
This means that you have to pay attention to what customization you've involved with each upgrade. This may give you headaches, when you want to restructure something that should be easy to do, except that it would mess up customizations. You have to pay attention to possible combinations of customizations that could interact badly.
A program is too customizable when any of the following is true:
There are no reasonable out-of-the-box defaults for things. Customizability is a lot more palatable if stuff works reasonably well even if you don't customize it. For example, I hate vi because its out-of-the-box behavior in terms of what the backspace and arrow keys do is so different from the convention on the rest of the machine. I know this can be customized away, but when I walk up to a stock machine it's basically unusable until I waste a bunch of time fiddling.
You've made your program so customizable that its look and feel is effectively different on every machine, Linux distro, etc. and you effectively can't "learn once, use everywhere". Again, see vi.
You've built an inner platform such that the user would be better off just using the outer platform to accomplish what he/she wants. For example, once a text editor or command line text processing tool gets too powerful, it's probably easier to just write a quick-and-dirty, ad-hoc Python script to do the more complex text manipulations than to learn how to do them using the inner platform. Similarly, once a plotting library becomes too powerful, it's probably better to just let the user directly interact with the GUI library it's built on top of to customize the finer details of the plot.
TL;DR: When your application becomes an intimidating framework.
From the application developer's point of view, that's when customization would allow the application to break in such ways that support becomes impossible, either because the user is unable to report how he set up the application or because various settings interactions become too tortuous to make heads or tails. Think the customization system thoroughly and allow for information to get back to you in a meaningful way.
From the application user's point of view, that's when the user feels like setting up the application is daunting, often because it's akin to programming, for a loose definition of "programming" (This includes GUI-oriented programming or Blinkenswitches).
Yes the line is a blur.
Yes sometimes a good code or GUI (re)design can make the application switch board even with the same customizable feature set.
Create a learning curve between "casual", "advanced" and "expert" settings. It could go all the way to providing an API and/or scripting. All users are not starting on an equal foot: a tiered system will make each one feel at home. It can also create a sense of progress and achievement when a beginner switches from "curated" to "advanced".
Good examples in various areas include Firefox (preferences, about:config, userchrome.css&al.), Chrome (basic settings vs "Under the hood"), Mac OS X (pref panes, "defaults(1)", applescript/automator), or even Vim's vimrc. Bad examples include any application whose settings pane feels like a maze. I'm sure you could name half a dozen from the top of your head (unless they traumatized you into forgetting them).
Firefox might be a good example - the user has the ability to customize the UI, and add on different extensions as needed. The core program is not customizable, but the rest is fair game.
When your application breaks too often for your customer's sake or your developer's sanity, you probably have too many.
I'm working with a .NET, SQL Server desktop client server app that allows:
Custom Tables
Custom Stored Procs & Views (These can have data modification capabilities as well)
Creation of custom data sources in the application (Inside or outside the 'live' database)
Creation of custom grid forms based on custom data source or combining of custom data sources
Creation of custom reports based on custom data sources
Creation of custom logic script on data entry fields
Customizable data import functionality
Customizable workflow process data entry and notifications
Customizable selection and placement of data entry fields/controls on standard forms
Detailed user security settings to all forms, data CRUD, app functionality and reports
Seriously, this company created a customizable beast. It's designed for a vertical market, but the other implementations could be limitless.
I like to design for customisability, but before I get around to implementing it, I would prefer to get everything else really solid. In fact I would probably like to get version 1.0 out the door where it can be handled by users before I started to think about adding user-customisable features.
Before that I just don't know what customisations are going to be useful to my real world users. It may be they're happy with how the interface works and would rather have more features available rather than having enough customisability that they can change the position of buttons or menu items.
I would rather have a really great interface that forces the user's hand a little, than have a lot of customisation going on, but wait an extra six months or year until my application can be released. Shipping is a feature!
The only definite exception to this is that if I am requiring keystroke combinations I would, in most cases, want to make those customisable, because you never know what else a user has running and it would be very irritating to collide with another application in a way that the user could not easily work around.
You could add the most basic and common sense configurations to a menu, so they can be directly tweaked from the user interface. Everything else, that is more complicated you can put into some configuration file or some other means that is accessible from a configuration tool or something.
That way, your most common, unspecialized users have access to the basic configurations they need to use the app, while your more specialized, expert or otherwise more interested users, can use the extra configurations to suit their highly specialized needs.
I think this is the best trade-off between having a user-friendly and highly customizable app. The success of this, though, is how you split the configurations. Which are the important ones, which are just for fancy tweaks? That's the hard part I think. And don't forget to add a reset to defaults button, in case someone messes something up.
