Choice is not necessarily a good thing although it can superficially seem positive. “Would you like a choice?”, “Oh yes please”. Without quality or real purpose behind the choice it can easily become just so much noise. There is a lot to be said for choosing a restaurant with a short menu. They will tend to concentrate on getting these few dishes just right. If you are lucky the food will even be freshly prepared. An extensive menu on the other hand might indicate a lot of freezer space and a bank of microwave ovens.
When we are designing software it is all too easy to implement too much choice. There is a constant stream of decisions ranging from the aesthetics of how to lay out a dialog to parameters that control data flow and the underlying program operation. Often it is tempting, easier, to defer these to the user. With layout decisions the programmer can completely duck issues such as creating a balanced look. What color should this line be? I don’t know so I’ll let the user decide. In one sense this is more work, certainly there is more code to written. But this is easy stuff for a programmer, it is what they do and this can be a more appealing path than stepping outside of the comfort zone and taking an external perspective. Adding more user choice may seem like empowering the user. Sometimes this is true but not always. It is always bad to clutter up the user interface because this will detract from the real purpose of the application. There is always the risk of a combinatorial explosion of optional parameters leading to many that simply don’t work. The control bar gets moved off the screen or the text becomes invisible or an unanticipated configuration simply causes the program to crash. In earlier versions of Windows it was perfectly possible to set the color scheme to something completely unusable, to make the task bar vanish, to stop the mouse dead in its tracks and to get the keyboard to generate gibberish. Actually some of this may still be possible but I have learnt to stop fiddling.
Some user options are essential – but which? One guideline is to think about what the application is trying to achieve. An accounts program would probably be equally useful if it had a grey border or a blue one. It doesn’t matter too much. On the other hand a fashion conscious teenager might consider the skin color of their iPhone application to be a fundamental expression of their personality. Often it seems to me one of the many by-products of age is a preference for things that ‘just work’ over trendier considerations, but that is not the point here. The point is ‘can the program work just as well without this option?’ because if it can then maybe the choice is just clutter.
To me the worst choices are those I don’t understand. ‘What allocation size to use for the secondary backup cache?’. I don’t know. I don’t even know what color the cache should be so now this software is starting to make me feel stupid. Configuring a network connection used to be a minefield of difficult questions like this. Fortunately, after possibly diverting some funds from the helpdesk to the development team, this has now become mostly automatic. It just works. That’s much better. If the program can work it out for itself then it should. Even, and this can often seem the case, if it involves loads of code to do something that the programmer thinks should be ‘obvious’ to any half informed user.
Another good way to spot the better restaurant is by how crowded it is. Confident and keen to impress, I once led the way into a very promising and packed Parisian eatery only to find that the sole occupants were in fact a visiting rugby club and their supporters. We chose to leave shortly before the first course but just after the singing started.