This is so critical, and I'm so happy to see it on HN.
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.
Just curios, but... how do you frame the task of designing a text interface when evaluating an UI designer? ...and what's their usual reaction to the request?
I think it is important to remember, while this is instructive and has good pointers to the usability literature, it represents a particular point of view, not THE UNIX point of view of simplicity. In fact there is no one Unix point of view.
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.
Great read, and following these rules is so important when designing CLIs.
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.
> 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.).
Probably an artifact of the fact git was originally designed to be a kit others could use to make a DVCS with a nice interface.
Which might point to another maxim: Always expect that your interfaces will be used widely, even if you don't expect them to be.
An extreme, pathological example of this is the BANCStar programming language:
Note that a lot of the links in there don't work anymore and you'll need to use archive.org to view them. In which case I would also ask you to donate to help keep the archive alive, if you can.
If you have the Stylish browser add-on (https://userstyles.org/), you can make this book much easier to read with this custom style I just wrote: “The Art of Unix Programming, and … Usability – improve readability”, https://userstyles.org/styles/107208/.
Here is the main part of the style’s CSS, if you just want to use your developer tools on each page:
I'll note that you can also go to http://www.catb.org/~esr/writings/taouu/taouu.html for the full book at once, which makes it more feasible to add these styles via console without going nuts and without needing an add-on (or if you're in Safari...).
Much obliged. I'd not heard of Stylish but I'd been making these kind of adjustments (based on similar rules form another less comprehensive site) directly in developer tools, so you've made my life a little easier and I've learnt a little more about good typography.
And I had heard of userstyles.org, but not read any of practicaltypography.com. Many thanks for introducing me to a concise, well-presented collection of typography best practices.
Stylish is really nice (I use it for a lot of things), but Safari has a builtin Readability-type feature (I forget what it's called) that automatically loads the next pages up until the end of the chapter. Even better, and it works on iOS too.
Stylish, is really nice. It has been my only option so far of being able to force site to use my preferred fonts since sites started using icon fonts (which makes the "Allow site to use their own fonts" checkbox in Firefox useless).
I've a steady growing databases of styles to use for popular sites. The main problem I still have is I set "font-weight: normal" in a global style which disables bold text.
Holy cosmic coincidence, Batman. I posted an Ask HN about an hour after you first posted this seeking suggestions for discussions of information design for command-line programs.
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.
As a followup, after reading much of this and skimming the rest, the command-line side of things doesn't get much focus beyond the principles, after which the book turns to GUIs for unix. Neither TAOUP and TAOUU give much coverage to output for the human reader; most of the coverage of the topic is restricted to making the output useful for other cli programs.
I was browsing some old(ish) books in the computer science section of a used bookstore, and there was a popular book on Motif user interface programming. Curious, I started to leaf through it. Then I didn't believe my eyes and went through it more carefully.
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.
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.