Human Interface Guidelines (HIG) for the Unix shell

As a command line person myself, I was very intrigued when I saw Klaatu's talk, HIG for the Unix Shell, on the upcoming All Things Open schedule.

While I have always been attracted to the Unix/Linux shell because of its beautiful simplicity—yes, really—it is always nice to connect with someone who shares that appreciation. Klaatu, however, has gone further than mere appreciation by defining some of the attributes that contribute to the elegance of the shell.

In this interview, he gives us a very brief glimpse of his ATO talk, where I plan to hear what he has to say about it in person. There is little available on the Internet about HIG, so I asked Klaatu to tell us what it means and how it affects the user interface of the Linux shell. And, yes, Klaatu will tell us about his name.

I have to ask for myself as well as many others, is your name, Klaatu, an homage to one of my favorite movies, The Day the Earth Stood Still? And would you care to elaborate?

It's a double homage! First, to the (original, not the re-make) The Day The Earth Stood Still, but also to Army Of Darkness. The former is a great film on all counts, but I think its greatest power is in how it uses expectations and cinema tropes to convey a message that is in complete opposition to what the individual elements represent. I will refrain from being too specific for fear of spoilers. The latter, of course, is just a great movie, especially for its in-depth analysis of how forking and branching affect software projects.

When I first got involved in Unix and open source, I was choosing a pseudonym for a little podcast that I do called GNU World Order. I naively thought that in a community that values technology and, frequently, speculative fiction, the name "Klaatu" would be a quaintly obscure reference to my favorite movies. Of course, I have since learned that "Klaatu" as your handle in the tech community is rather like "Bob Smith" in the real world, so online I am also sometimes known as "notKlaatu" to set me apart from the other Klaatus.

How did you get started in Unix?

Well, I was never a Windows user. The cumulative time spent on Windows in my entire life has probably been 15 minutes, if that. I grew up on that other commercial operating system (OS). The leap from that to Unix proper was not really that difficult.

That said, I was not looking to go into computers, but rather film. I was secretly pretty geeky anyway, but I went to school for film production.

One day, during my commute to film school, I was reading a trade magazine and there was an article in it about how visual effects houses used Unix, and it said that they had the mysterious ability to launch programs without starting up the interface. From that moment on, I was fiercely curious to learn how I, too, could use applications without bothering with the actual UI of the thing.

When I learned that the OS I'd been raised on was "based on Unix," I purchased a book on how to learn Unix (it was A Visual Quickstart Guide to Unix, specifically). I started applying everything in the book to the terminal I found in that OS. In the documentation for Emacs, which I was mainly using at the time as a Tetris engine, I learned about the concept of open source and the GPL. Eventually I got frustrated with constant compiler errors and the inability to not launch a desktop unless I wanted one, so I switched to Slackware Linux and never looked back.

Incidentally, I now work in visual effects.

What most attracts you about the Unix shell?

Efficiency. I seem to have no patience for things standing between me and an identified goal, and the shell is the one thing in all computing that just lets me do exactly what I want to do.

A close second is the ability to create my own working environment. It took a while, but once I learned the basics of scripting, the ability to write custom commands and scripts flat-out changed my life.

There are plenty of other good reasons to love the shell, but those are the two that resonate the most for now.

What does HIG stand for?

"HIG" is a term I learned from GNOME. It means "human interface guidelines", and it is a set of specifications that advise developers how an application should present its functionality to people.

How did you become interested in Human Interface Guidelines?

Broadly speaking, I don't think I am very interested in the topic, at least not in the same way that UI designers are. But all computer users are a little interested in Human Interface Guidelines, because it's how we use computational devices. For me, it's just a question of how we should all collectively, at least in a more-or-less kind of way, agree that computers should work. It's our effort to form a common trend in the way applications are used.

I don't know how car manufacturers do it, but generally if you get into a car, even the ones in New Zealand (which have the driver seat on the left), you basically know where everything is located. But as far as I know, no one is forcing that common design on anyone. It's just what we have all agreed on. I think the same pragmatism is useful in computing.

How does HIG apply to Unix shell applications?

To some degree, a HIG is forced upon shell applications by the libraries they use and the environment they run in. If I write a Unix application that runs in BASH or (t)csh or a similar shell, then argument $0 pretty much has to be the name of the executable (which does not mean that the first string typed must be arg $0, as in the case of passing ENV variables to a command in BASH). That's a good thing, and it's one of those pragmatic guidelines that just sort of exists without question. If someone designed a shell that looked for the argument first, I guess that would be something new, and it would probably initially confuse most of its users.

Other than that, though, there's a lot of flexibility, like the order of options and arguments, the expectation of being prompted for confirmation or not, and so on. There are some things that most Unix users expect, but that isn't always how things work out.

I think it helps to get together and identify what "makes sense" and what makes the most sense when designing applications, whether that application is a simple BASH script for personal use, or Python, or C++.

I think it's especially important now that open source and the free Unix and Linux traditions are becoming so popular. There have definitely been some poor implementations of Unix out there; I'd like to think we can collectively agree to avoid that with a bit of intelligent design.

Should HIG apply to CLI commands and applications that use arguments and options, as well as to menu-driven applications?

Not the same HIG, but there should be some non-enforceable guidelines.

Having said that, though, there are some guidelines we take for granted in both. The fact that many GUI applications strive to work from top left down to bottom right, that's a guideline. Similarly, we do tend to structure commands from left to right, often assuming that the order is COMMAND > SOURCE > DESTINATION. Is that necessarily the best way of structuring things? Should an order be implied? Food for thought!

What are some of the most important HIG guidelines for a Unix shell application?

The most important considerations for shell applications include:

• Does the command work in plain text? or does it have an interface (ncurses or otherwise). Can it do both?
• Does the application force a specific order of options and commands, and if so, how does the user know that? Is there some kind of human-friendly delimiter to help humans remember which side of the equation an argument needs to be in order to produce the expected results?
• Does the command accept input from stdin?
• Can the command write to stdout?
• Does the command provide useful feedback upon obvious errant syntax? Can the command provide useful feedback to prevent errant syntax?
• Is the command interactive? Is there a switch to turn that on or off?
• Can I override, as part of the command, the location of important data such as config files?
• Does the command offer unique responses to signals (HUP,USR,and so on)?

What examples can you cite of Unix shell applications that conform to HIG and why?

The short answer is to come to [my] talk and find out!

The long answer is that a HIG is a big thing, and applies uniquely to each command depending on its goals. So there are lots of commands that, I feel, are a pleasure to use. They roll right off the fingers as you type them; the syntax almost reveals itself. Then again, the thing that you are doing with the command might be confusing, so it may not feel very friendly, simply because you don't really understand what you are doing.

So it's a complex thing, and I don't think the answer is to point to a real or imagined "perfect" command, but to define a sensible set of expectations and apply them as they fit into the command's self-proclaimed goal.

It's a little like reviewing a video game. You can compare a puzzle game to an RPG, but you can't really base your judgment of one off the other, because they both strive toward something unique. Unix commands are the same, to some degree; not everything should work the same, but everything should make sense according to their own established set of rules.

And mostly, everything should work like a shell application is expected to work.

Do you have particular a Unix shell application that exemplifies a complete disregard for HIG and why?

I have one or two, but there's no point in naming names, not just because I might (or might not) know their authors, but also because the commands themselves might be doing amazing things. Hopefully, in those cases, the devs will attend my talk and go home and give some thought about how their commands measure up to other commands.

I will call out the little-known [and purely hypothetical] command `hijinx`, however. It is a reviled command that I dread using, and since its author perished in a freak accident involving an overzealous CPU fan and an overpowered multimeter, it does no real harm to criticize it.

For instance, let's say we use hijinx, which confusingly provides the executable `hijink` not `hijinx` (I think the author believed the singular "hijink" was more logical than the plural name of his project):

$ hijink bar baz

It works great as long as we use it exactly in that sequence: command, option, argument. But if we do

$ hijink baz bar

It fails. That's annoying because what if the 'bar' value is the one I find myself changing most frequently? It seems petty for the author to force me to hit the up arrow, and then alt-b, and then alt-d, and type in a new option.

Think of how much nicer it might be if I could:

$ hijinx -baz -o bar
$ hijinx -o bar -baz

And get the same results both times?

Does a Unix shell force the human interface to conform to a limited subset of guidelines compared to a GUI and, if so, how?

Off the top of my head, I'd say it wasn't even a sub-set. I think it's more likely a different set. I'm sure there's an argument either way. I've never thought about it in that way.

The point is a lot less about a specifically defined HIG and more about what that stands for: human interface guideline. It's about thinking about your users, what they expect from the interface, and what developers might want to do in order to make the interface less of a barrier and more fun to use.

What sorts of user interface limitations are imposed on a Unix shell by the underlying OS?

I don't know enough about non-POSIX operating systems to know for sure, but the only one I can think of are Unix signals, and possibly dealing with stdin and stdout with pipes (I have read that Powershell has pipes, but from what I have seen they appear to be technically different from Unix pipes, but I have not, obviously, looked at the code or even used Powershell, so I can't be sure). Everything else that I can think of at the moment gets handled by the shell itself (BASH or tcsh or ksh or zsh), or the method you use to parse arguments (if/else checks, parsing libraries, when arguments are processed, and so on).

How does HIG affect the daily tasks of system administrators?

It depends on what the sys admin in question is doing. The beautiful thing about usability is that once you learn something, usability sort of fades away from view. You know how to use the application, you know how it works and what you have to work around.

That falls apart when you are learning something new, though. That's when usability tends to matter the most.

Repetition also, sometimes, reveals poor interfaces. Obviously if you are having to do something over and over and it's imposing awkward work-arounds, then you start to wish for some human interface sanity.

What do you hope to accomplish with your talk at ATO?

I'm hoping that developers and soon-to-be developers attend the talk and think about how their applications can be strengthened through careful consideration of interface design. What's good for the goose may not be good for the gander, so a flexible command with sensible syntax that at least balances good internal logic with a shell user's expectation, is a command that people and, ideally, distributions will happily adopt.

Where can our readers go to learn more about HIG?

Nowhere, since there is no HIG for the shell...yet. To learn about how the shell has developed, and why we tend to do things in the way we do things, I highly recommend both The Unix Philosophy and Linux and the Unix Philosophy by Mike Gancarz. They aren't directly about interface design by any means, but these books explain, in part, why Unix so successfully works the way it does, and a lot of that can be considered when programming an application for a Unix shell.

This article is part of the All Things Open Speaker Interview series. All Things Open is a conference exploring open source, open tech, and the open web in the enterprise.