
The Art of Unix Usability (2004) - diggan
http://www.catb.org/~esr/writings/taouu/html/
======
GuiA
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.

~~~
nnq
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?

------
Isamu
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](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.

------
acabal
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.

~~~
cbd1984
> 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:

[http://en.wikipedia.org/wiki/BANCStar_programming_language](http://en.wikipedia.org/wiki/BANCStar_programming_language)

[http://reocities.com/ResearchTriangle/station/2266/tarpit/ba...](http://reocities.com/ResearchTriangle/station/2266/tarpit/bancstar.html)

[https://github.com/jloughry/BANCStar](https://github.com/jloughry/BANCStar)

~~~
anon4
>
> [http://reocities.com/ResearchTriangle/station/2266/tarpit/ba...](http://reocities.com/ResearchTriangle/station/2266/tarpit/bancstar.html)

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.

------
roryokane
If you have the Stylish browser add-on
([https://userstyles.org/](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/](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:

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

I referred to [http://practicaltypography.com/summary-of-key-
rules.html](http://practicaltypography.com/summary-of-key-rules.html) when
choosing these numbers.

~~~
abathur
I'll note that you can also go to
[http://www.catb.org/~esr/writings/taouu/taouu.html](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...).

~~~
0942v8653
There's a Stylish extension for Safari too.

~~~
abathur
Good to know; userstyles.org doesn't mention it Safari on the page linked, at
least.

------
abathur
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.

~~~
abathur
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.

------
kabdib
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.

~~~
marvy
wow

