In this chapter, we'll present case studies in the wrong and right ways to do GUI design, highlighting the application of the design rules from the Philosophy chapter. Where possible, we will contrast pairs of applications with similar functions — one with a good UI design, one with a bad one. All case studies are open-source code.

We don't mean to imply that the applications with bad UI choices are necessarily worthless — because designers tend to write from the inside out in the Unix world, even inferior UIs are often wrapped around engines that work quite well. Nor do we mean to suggest that any program with a good UI is necessarily a superior choice; indeed, we will try to point out situations in which a well-designed GUI is coupled with a weak engine.

The central point of this chapter is that, though Unix programmers often choose to be oblivious to it, there are in fact such things as good and bad UI choices. There may not be any way to guarantee making good choices, but if we bear in mind the design rules from the Premises chapter there are ways to avoid making bad ones.

Given the speed at which open-source development moves, it is possible that some of the blunders we'll dissect here will already have been fixed by the time you read these case studies, even possibly as a result of pressure from these case studies. We have, therefore, carefully referred each criticism to a specified software version; and we have tried to frame these studies so that each lessons will remain useful even after its subject ceases to be a conspicuous example.