Title: On Configurability and Consistency

A question in a computer graphics course asked how a GUI could be adapted for colour-blind people. What better opportunity to air one of my pet annoyances? A user interface should not need to be adapted for any group, if "adapted" means tinkering with the system software. Instead they should be able to set the preferences, and those settings should be respected. In current software they are not respected; I think half the time they're not even tested properly. Etcetera.

My supervisor wrote "lots of arguments contradict this", and when I asked him he said that allowing much configurability breaks consistency. If I configure my system to be very much different from normal, you might be completely lost if you tried to help me out with a problem.

How can these conflicting aims be resolved? People who object to configurability on the grounds of consistency usually have no objection to localisations, such as the translation of messages into languages other than English or the complete re-mapping of the keyboard, even though these can cause the same problems when nationalities are mixed. Hence the issue is not as clear-cut as it seems.

There is a difference between a small number of discrete "themes" of presets (of which localisation is an example) and the much larger number of possible configurations you get when you allow the user to adjust everything in detail. Presumably the support and testing people can acquaint themselves with all of the themes in a similar way that in the days of DOS you could learn how to type "keyb uk" on all European keyboard layouts (which was much easier than you might think). However, it doesn't work like that, because programmers do not always test on every theme - not even the desktop themes in Windows 95 (just try setting "use high contrast" under Control Panel/Accessibility, or in NT "high contrast black" under Display Properties, and see which app you run into problems with first). A particular problem in localisation is programmers thinking they have exact control over the length of messages, or setting arbitrary limits on how much they can grow or shrink. And the fact that the messages in a localised OS are consistent is small consolation to a helpdesk that doesn't understand any of them.

One must be careful, though, not to lose sight of the purpose of a personal computer. Most of the time it is not being used by helpdesk personnel, or by people of several different nationalities crowded around the keyboard, but by one person, and if that person can use it more efficiently or comfortably by changing a setting, then their entitlement to change that setting is similar to their entitlement to change the layout of a personal office or a home bedroom - compromises for visitors need only be made on the rarer occasions when they are present. Saying that you can't configure your own system on the grounds that you might forget how to use a generic one is like saying you can't have an unusual room layout in case you become less familiar with other people's houses. (Of course you are less familiar with other people's houses!)

What, then, about the occasions when you need to use somebody else's system? In the ideal world, you should be able to change the settings on the fly (with all the programs still running) and restore them afterwards, in a similar way that you can use the key combinations Ctrl-Alt-numeric plus or minus to change the screen resolution on some X servers, or Ctrl-[ and Ctrl-] to quickly adjust the font size in Windows Netscape. If instead of producing "localised" and "adapted" versions of software, programmers allowed such on-the-fly switching, this would greatly benefit users who are away from their homelands and surrounded by computer experts who can't help.

Does on-the-fly switching, though, force some amount of consistency? When I try to help people with Windows 95 systems, I turn on the High Contrast option, because it is better than nothing even though it is a bit of a mess. I know the key sequence to do this so I don't need to read the small fonts while I'm doing it. However, in localised versions of the OS, that key sequence is different, which becomes a pain especially if the owner of the system does not know how to do it for me. I am reduced to squinting at icons, the one remaining consistency (although even they are in a different order). If the owners of these systems had done all these changes themselves, then likely they would know the differences, but changing settings is work and if sizeable groups of people are likely to want a common starting point (e.g. everything in Japanese) then giving them that starting point should save them a lot of trouble (although ideally they should still be allowed to tweak things themselves). The disadvantage is that they may then be blissfully unaware of the differences between their system and the one the people around them expect. But there is no reason why they should be, unless they're trying to help someone to help them.

How can this be resolved then? I would suggest making configurations switchable, and making a single "international break-out" key sequence that cannot be rebound and is unlikely to interfere with normal working. That sequence will temporarily set all key bindings to some standard (which does not have to be anything to do with English), so that other configurations can be changed by pressing memorised key sequences. However, all of this would have to be done at the system level; it would be of limited use if things were different for each application (unless one application is all that matters on the occasion). Programmers should make sure they respect the system settings even if these are changed in mid-run.

How can a program be tested under countless possible configurations? A robust testing procedure should at least change every setting in turn, since it is surprising how often programmers forget to think of them, but what values should be tried and what if there is a bug that is only evident when a particular combination of settings is in force? For any given set of variables, it may be possible to sit down and work out which combinations can possibly cause problems, but writing a guide to the general case is more difficult. Furthermore, many commercial software producers rely on automated testing methods, and automatic methods might not log such details as whether the text on the screen is actually legible.

I thought that this was the sort of thing that beta testing is supposed to do. As far as I know, companies releasing products for beta test do not advocate that the testers each use a different configuration. This means that most of them will start from the same point and probably run into the same problems, and the only extra information you get from large numbers doing it is statistics on how frequently an average new user will run into a particular problem. Well if you want your program to fall over when someone does something as simple as changing the colours, fine, but don't say it's a quality product. Incidentally, whenever I explain configuration difficulties to people who are unfamiliar with computers, they fail to comprehend how such complex machines don't "just do that automatically".

This article has been written from a user's viewpoint. The hobbyist programmer has no obligation to make anything right; anything they do is a contribution, and going on about what they didn't do could almost be taken as being hostile. But saying that a program won't work under a particular configuration is simply stating the facts. I came across some software once that actually said, "This program is not very configurable; if you have a special need then you may not find it useful." That's fine; I know where I stand. As long as I'm never in a situation when I have to use it, such as if the organisation I'm in refused to run anything else.