- Where appropriate mix configuration and data.
- Maybe GUIs and Wizards are the answer.
- Minimize the number of Options and Settings.
- Mixing Configuration and Data:
- A good example of this is the dot files used by most HTTP and FTP servers. If you want a welcome message for an particular FTP directory you place a ".message" file in that directory. This is a much better solution than putting all of the messages for all directories into some obscure file or registry entry. If you are using this technique for new systems I'd suggest making sure there are no collisions by using a name like ".ftpd.message" instead though.
- Maybe GUIs and Wizards are the answer:
- Bad software frustratingly forces us to use wizards and crummy GUIs for common tasks on a regular basis. Creating a new presentation in most popular office suites, for example. However,If you're working on a task you do only very occasionally or once then a wizard UI can sure be a boon. Often wizard UIs are provided only for installation. It's incredibly frustrating when you have to chose between using the provided wizard to build a new configuration from scratch and editing text files to alter an existing configuration. If a wizard UI is provided then it should be available for all reconfiguration with new configurations being treated as a special case only if necessary. I've got a lot more to say about wizard UIs, but I'll save it for another blog...
- Minimize the number of Options and Settings
- As software ages it is pretty typical for the number of options and settings to grow. For new software replacing an old implementation there is also the temptation to provide every option the old version provided. This way lies madness. One of the services I've been configuring for my new server is vsftpd, an apparently well-built ftpd service. The service is installed with a template configuration file which contains terse explanations of most of the 50 some options you can set along with those options in a commented out form. For my purposes I needed to configure six settings and options, five of which were documented/templated in the file and one of which I discovered in the vsftpd man page. So what about the 45 or so settings and options I didn't need to use and probably at least 20 more I could have added from the man page? It seems that perhaps 15 were legitimate options and settings, mostly for resource limits and such. The remainder were for handling compatibility with older ftp daemons and odd-ball system configurations. It appears that if you tried hard enough you could configure vsftpd to behave just like the very obsolete NT4 ftp service or wu-ftpd. Wow! Wouldn't that be an accomplishment! Software authors really need to consider carefully the value of each option provided and consider the cost to everyone who does not use that option. Options and settings are not "free". Every option requires it's own documentation, testing and the attention of everyone who will need to consider whether that option applies to their situation. If you are leaving an option your software for one user in outer mongolia who must have the latest version of your software, but won't upgrade from MS-DOS 3.1 then you are probably doing a disservice to the majority of your users. When I worked in the retail shrink wrap software industry there was a constant between tension between the marketing and engineering teams. Engineering always wanted to limit the number of supported OS versions for the application and marketing always wanted to support all of the OS versions that the previous application version supported, plus all of the new OS versions that had been introduced since the last release. No amount of argument seemed to sway them from this assertion. Even though our most likely customers were likely using current OS versions, even though surveys indicated that over 50% of all computer owners bought no software whatsoever more than six months after buying their computer (this has probably changed a bit now that more people are online), even though upgrade sales were a fraction of new unit sales, even though our support call records indicated that very few users were calling about OS versions more than 2 years old and that they were mostly calling about older versions of our applications and possibly most importantly, even though it was explained that large amounts of backwards compatibility came at the cost of limiting features and performance for users on current OS versions. The conclusion to the story is that by failing to focus on the OS versions and systems used by the application's most likely customers other vendors were able to gain market share by focusing on those same customers with specific features and additional value.
