The Art of Unix Usability (2004)

When I was a PhD student, I TA'd an HCI class my advisor taught, where he gave a project a week. The very first project was to design a text interface - the subsequent weeks then ramped up to designing applications for 1024x768 mouse driven computers, then touch screens, then 80" screens viewed from 50 feet away, etc. I think any good UI design class should proceed in this manner.

Now that I've left academia, when I need to assess an interactive designer's skills, the first thing I do is ask them to design a text interface because all of the core principles exposed in the posted piece are foundations of any good interactive design - regardless of whether it's in a terminal, in a GUI, or for a gesture driven application (conversely, UI designers who dismiss textual interfaces as irrelevant to UI design are probably mediocre designers).

Most of the fundamentals of interaction design are present in good textual interfaces, and there's no fluff to hide behind if you are a mediocre interaction designer. I commonly see UIs with lush graphics, beautiful animations, the perfect quirky copy - and yet it all falls flat because one of the rules listed in the posted book aren't respected, but when you try to tell the designers that they just point at all these things as signs of how great their interface is.

The truth is that all this crap doesn't matter if your interaction model is shitty. Just like a great artist should be able to make beautiful pieces using just a piece of charcoal regardless of their Photoshop skills, a great interaction designer should know how to design effective text interfaces - and if they can't, no amount of CSS skills or blog posts on "skeuomorphic vs flat" they've read will matter.

Some of original Unix authors are of a particular opinion, that Unix itself has gone wrong by becoming too complex. (see http://harmful.cat-v.org/cat-v/unix_prog_design.pdf, see also Rob Pike's critique of BSD sockets, etc.) If I were to summarize their apparent position on simplicity, it might be that the design should be structurally simple throughout, not just on the surface.

For contrast, note that ESR uses the X window system in his discussion of GUI interfaces. The X system was famously heavyweight and complex (at the time.) If I were to summarize ESR's apparent view of simplicity, it might be that simplicity is something you present to the user.

It's such a shame that for all its popularity, Git spits in the face of so many of these rules (least surprise, reversibility, failure, silence, predictability, etc.). It can be argued that understanding Git's plumbing obviates some of these violations, but I'd counter that I have better things to do than memorize intricate plumbing and byzantine combinations of commands and flags just to get usable source control. In either case, it's a fine VCS saddled with a tragic command-line interface, and it's become so popular that we're going to be stuck with that CLI for ages now.

Just goes to show: The command line is so elegant and pleasant when programs follow these rules. Make an effort to get your CLI right from the get-go, because if your program becomes popular you won't be able to change it later.

Here is the main part of the style’s CSS, if you just want to use your developer tools on each page:

    body {
        font-size: 20px;
        line-height: 1.3;
        max-width: 700px;
        margin-left: auto;
        margin-right: auto;
    }

Even more funny, valaruca1 suggested that "The Art of Unix Programming" by Eric S Raymond might be a good place to start. I was a little disappointed when I checked it out; perhaps he just mis-remembered this keyword.

Thanks for posting this--it looks like where I need to start.

About 350 pages. Lots of APIs and descriptions of options and stuff, but exactly one diagram. In the whole book. For me, this pretty much sums up why Unix UIs were so bad.