Tom Chi  

On Unix Command Lines and Pianos

July 9th, 2004 by Tom Chi :: see related comic

In this week’s comic we have an example of an interface which probably shouldn’t be made easier to use. Although HCI folks will rarely admit it, there are quite a few situations where improved usability is uneeded and unwanted.

One that comes to mind for me is the Piano. I’ve played piano for quite some time and to me the interface feels perfect. The weight of the keys, the spacing between them, everything about it seems effortless and right. In reality though, if the goal is to help a person play music, the piano interface leaves much to be desired. It is a system that only a small percentage of the population ever master, and one where a newcomer can’t really accomplish much. For these reasons, I liken it to the Unix Command Line.Advanced Unix users feel at home at the command line. They can do anything and everything with just a handful of keystrokes. It is pretty much how a pianist feels being at a piano… they could kick out a jazz riff, or a lazy layered legato masterpiece. It is a feeling of incredible control. Thus when either community (pianists or unix users) hear news of people looking to “improve” their interface, the attempt is met with some skepticism. How could that experience possibly be improved?? “What’s with all these windows and widgets and knobs? Just give me the real thing so I can get work done!”

I call this class of interface “mastery interfaces”, and they are curious because they are amazingly unusable to beginners and effortlessly usable to “experts”. This characteristic creates something of an odd social dynamic amongst the userbase. The experts can barely (if at all) re-acquaint themselves with the frustrations that newbies face, and thus have very few (and skewed) insights on how to make the system more broadly usable. Within the Linux/GNU/Linux community there is disdain for people who can’t hang with the CLI. It’s a similar disdain to that of an experienced jazz musician who is forced to jam with a musical newbie. In both cases the comments are the same: “Come back when you’ve learned something.” “RTFM.” “Why am I wasting my time?”

I’d be interested in hearing what our audience thinks of this type of interface. Do they have a place in the world of usable design?

24 Responses to “On Unix Command Lines and Pianos”
Frank Spada wrote:

Are improvements to the piano and command line unwanted because they’re already ideal interfaces? I would argue no. I agree that they’re robust interfaces that allow for complex interaction; but that doesn’t make them optimal. A close analog to your piano example is the QWERTY keyboard. It’s a robust system that you could also say underlies the command line interface. The QWERTY layout was engineered around criteria that are no longer relevant today (i.e., the QWERTY layout was intended to slow the user down to prevent the typewriter from jamming). The same can be said for the piano and command line interface. There are far more usable and efficient keyboard layouts out there like Dvorak which are readily available on most computers, yet the QWERTY standard has been set. QWERTY is not optimal; but most of its users are ignorant of better alternatives (whether real or hypothetical). That said, I guess a simple, yet robust interface that’s “good enough” is a successful one in marketing terms. Which is maybe why there’s so much mediocrity out there in interfaces… even within your class of “mastery interfaces.”

Chris Adams wrote:

I think one of the underlying issues is that most usability efforts focus on ease of acquisition which is useless for experienced users - it can even be harmful if it limits everyone to novice-level features (e.g. the ever-popular mandatory 8-step wizards). The Unix command-line has all sorts of warts but it’s extremely popular among experienced users because it richly rewards learning with extreme flexibility and speed.

The “Unix is too hard” replacements have been rejected because they ignore the needs of experienced users. Some of this is no doubt due to condescension (ever sit in a project meeting where everyone agreed that customers are morons?) but I think it’s mostly a relic of the way our industry grew - when the computer-using population was growing exponentially, most users were rank novices; I’ve been waiting for that perception to change as the market matures.

Microsoft may have a good example of the right way to do this in Longhorn - they’re working on a shell-script equivalent but rather than getting rid of the concept it’s going to be less crufty with more consistent names/operations/etc. and rich data types so you can pipe more than simple text (e.g. I send you an Address object and you can just say theaddress.firstname rather than having to parse it out with cut/grep/sed/etc.) if you want. It’ll be interesting to see how it works out - it could be a great example of improving usability by giving people better tools to deal with complexity rather than assuming that the complexity can be avoided, which is so very far from true in the real world.

Arthur wrote:

Humans are remarkable creatures with the ability to learn even the most difficult of interfaces. With these “mastery interfaces”, there is a culture around preserving the interface so that it becomes a ritual to become part of the group. Sometimes sub-groups will distinguish themselves among the masters as well. For example, the UNIX interface changes when you type ‘bash’ or ‘csh’.
For people belonging to one group or the other, the organisation sets out the criteria for usable and efficient design which may run counter to what we might consider a scientifically bad design.

To make an analogy back to the piano, would the Casio keyboard be seen as an improvement to a well known design? The weight of the keys are different, spacing can be different, but it is much easier to make music. The world may never have seen Tiffany’s “I Think We’re Alone Now” had it not been for this device that took the complicated task of learning to play a piano for making music into pressing a few buttons for chords and beats.

Kevin Cheng wrote:

the QWERTY layout was intended to slow the user down to prevent the typewriter from jamming

I don’t have a 1999 Economist to confirm this but apparently, they published an article that debunked the myth of the QWERTY vs Dvorak keyboard efficiencies.

Bob Salmon wrote:

I think that one area where the analogy breaks down is the complete novice. Even a cat walking over a piano’s keys can produce some sounds, but sit a newbie in front of a blinking cursor… At least with a piano you can experiment your way to something like chopsticks.

One of the features of the UNIX command line that I like is how you can describe much of it with a few concepts. For instance, nearly everything is a file, including (in some shells) your command history, so you can search back through it as if it were a file, rather than typing:
!?email client recommendation?:s/Notes/Thunderbird/

S Woodside wrote:

The usability of the command line must be balanced against the interface constraints. It MUST be a text-only interface. Text-only interfaces have a long and proud tradition and the usability of text-only has been incorporated in many great tech advances. HTTP is text only. SMTP. HTML. XML. So make sure you are comparing apples to apples here.

Oluseyi wrote:

HTML is no longer much of an advance, and XML is largely superfluous. Equivalent systems have been in use for a long time (RTF, for instance); the difference lies in the agreement of several parties to use it consistently. Text-only interfaces are not necessarily better, and when they are parsed and generated far more frequently by machines, they become downright inefficient. HTML’s usage parameters have outgrown its original objective, such that its text basis is arguably now a defect.

The Unix command line is intractable because of its limitless extensibility. What we consider the CLI now is a combination of the shell and several common utilities - of different origin, thus explaining the interface inconsistency. Given that no firm can adequately predict all possible user needs, every attempt to regularize the CLI will falter at some point as user extensions are created.

Sally wrote:

I would add that something to think about when considering improvements to a CLI is how the system will be accessed. Unlike a piano, a computer can be accessed remotely, where the underlying network will affect the user’s experience. Instead of sending many packets across the network to update a GUI, a CLI sends fewer packets to transmit the command and its result. Over a slow or congested network, the performance difference becomes quite noticeable.

Euman wrote:

Lots of myths been promulgated here !

1) There is no evidence that QWERTY was developed to stop keys sticking. The fact TYPEWRITER is the longest English word you can make out of the top row is rather significant don’t you think?

2) I believe that the debunking of QWERTY v Dvorak has itself been debunked. However all the world typing spped records are held by QWERTY typists

3) In the early days of UNIX everyone, not just the geeks, used the command line. They didn’t find it hard or particularly difficult. Why has the introduction of windowing systems made people incapable of learning a CLI? There is a strange myth that good systems have to be easy to use - actually systems that have a reasonable learning curve are much better in the long run. Try doing anything complicated on a GUI and you see the problems straight away.

euman wrote:

Oh, and the Piano is a poor choice of example - the piano interface has had lots of people working on it over hundreds of years and nobody came up with anything better. A more useful example would be the Bassoon which has a horrendous user interface or the evolution of woodwind systems from the various simple systems to today’s more effective but harder to implement systems. And in fact these systems illustrate my point about learning curves - a tinwhistle is very easy to pick up and play but if you want to play (well) in another key it is very hard indeed, so you need something that requires some learning of complexity but lets you go further in the end.

Bob Salmon wrote:

I think a general area where we don’t want unconstrained usability is security (as hinted at by the cartoon). There are three sub-areas:

  • how easy is it for the permitted user[s] to use
  • how easy is it to control who’s permitted/excluded
  • how easy is it for excluded users to crack (either attempting to break the security, or by breaking the system that controls the security i.e. masquerading as a permitted user).
This isn’t just in things like cryptography, but in concrete things too: door locks, medicine bottles and baby stair gates. Medicine bottles are interesting - it’s assumed that physical ability and age are the same, but as a child my wife used to have to open her grandmother’s medicine for her due to grandmother’s arthritis.

With computer security, passwords are a pain as you’re burdening the permitted user to exclude others. Something like biometric appears to be easier as the user just needs an eye scan / fingerprint etc. which doesn’t need remembering and claims to be hard to crack. Some people, however, disagree.

Jake Cressman wrote:

Short cut keys are another good example, particularly for visual design pros who would otherwise be pushing a mouse ten hours a day. With an extensive set of short cut commands, in a program like Photoshop, a designer can work the program like a piano, via the keyboard, and use the stylus or mouse only when drawing.

The cool thing is that this mode of working is neither command line or strictly GUI, but somewhere in the middle. Also, the fact that their is a novice and advanced method, makes the program accessible at different skill levels. …more like a Casio than a piano :)

Josh Johnson wrote:

This type of “mastery interface” isn’t limited to the GUI/CLI schism. In the past I was intimately acquainted with 3D animation software interfaces. When I started out about 10 years ago, there were basic entry-level iconic interfaces for software like 3D Studio and Lightwave, and then there were advanced text menu-based interfaces for software like Softimage, Houdini, and Power Animator. When people tried to move up to the advanced stuff, there was the same sort of disdain and “Come back when you’ve learned something.” rhetoric.

What I found interesting though, was that as the software progressed, there was a blending of the two into the next generations of software. Alias Maya and Softimage XSI maintained the underlying power of their advanced interfaces, but they wrapped them in dressing similar to the previous generation’s entry-level interfaces, but which could be customized by advanced users.

I like Jake’s observation, in that it mirrors my own observation that the entry-level interfaces tend to be very mouse-driven, as opposed to advanced interfaces that more often utilize both hands and even gestures.

I think the same hybrid evolution is slowly occuring with desktop interfaces even now, with the advent of usable GUI’s living harmoniously with CLI’s (Mac OS X), and I’m looking forward to seeing how GUI’s and CLI’s can be used in unison within certain applications.

As far as the security aspect is concerned, I think that’s a burden that’s slowly shifting away from interface design and onto technology. The problem is simple: Can you prove you are who you say you are? Forcing the user to answer 20 questions is easy to implement, but no more (or less) secure than a single biometric or RFID scan, but as Bob points out there’s a ways to go before it’s completely trusted.

Helena Mentis wrote:

Great point, Tom, regarding pianos. A friend of mine was in a graduate digital media class where their final assignment was to design a new electronic instrument. When he presented his preliminary designs to his professor for approval she told him the design was too complicated to use and that he needed to address usability. So, of course he came to me for help. I heard his argument for his design, took a look at his sketches and told him to go back to his professor and tell her that she had no idea what she was talking about and hand her Cziksentmihalyi’s book on Flow. My point to him was that one of the beautiful things about learning to play an instrument is the struggle to learn it and then the ability to show off your skill to others. Why would you want to play an instrument that just anyone can play (that might be why the recorder never took off). In the end he made this argument to his professor and she accepted his designs. But it made me wonder…have we been extolling the virtues of usability so much that professors and practioners have been applying it without any regard for its usefulness in particular situations? I don’t think HCI as a profession wants a bunch of mindless robots squawking usability at every turn, no matter how much we want the word to be spread.

JP wrote:

Uh, isn’t “mastery interface” just a term for “interface that may or may not actually be ideal, but has become deeply habituated”? Game design has taught me that any interface, no matter how godawful, will become deeply ingrained on a user if they’ve spent enough time with it.

Admittedly, the Piano’s UI is probably pretty good at making its functionality accessible, and it’s had a long time to be perfected. But even to an amateur like me it seems extremely dangerous to call a UI good just because millions of people have invested the time to become really, really comfortable with it.

Lada Gorlenko wrote:

Gotcha! I don’t think that members of public want on their roads a bunch of brainless humpty-dumpties who drive automatic cars being totally incapable of the simplest hand-foot coordination! Shouldn’t command-line virtuosos feel sick driving automatics? Why would you want to drive something that just anyone can drive?

Back to the original comic. What security has to do with usability? Nothing. At least, it shouldn’t. Don’t take from usability to improve security, just improve security. A fire alarm with “Please enter a 12-digit PIN” is toddler fool-proof - anyone cares to suggest one for use in a nursery?

Good point made by Jake about the mix-mode of use, such as in Photoshop. That’s exactly what true usability is about - providing a variety of methods for the same functionality. I am neither anti-GUI nor anti-command-line. I am pro-choice: no one should force the user to believe that sliced bread is the best thing in the world. GUIs can be as efficient as command line interfaces, with a little extra thought required from designers. Command lines can be as usable as GUIs, for those who are tuned to them. Just let the users see the world their way, not ours.

Oh yes, there is such thing as belonging to a higher race of Masters of Something or Other, sure: http://www.theatlantic.com/issues/2002/11/brooks.htm

By the way, is your car manual? :-) )

Tom Chi wrote:

Wow. Lots of comments. I really haven’t had much time to respond to all this discussion but I just wanted to clarify one thing: I called them “Mastery” interfaces not because I believe that they are superior UI for all occasions, but because it requires mastery to be able to use them well.

A lot of traditional GUI interfaces don’t allow the possibility of mastery, but they *do* allow any Joe Blogs off the street to buy a car online.

Clearly there is a place for both, but I’m definitely fascinated by the ability for some interfaces to afford mastery. I think the main attribute is that they offer a collection of hardware-based primatives that map to atomic actions inside the machine (and provide feedback). The mastery component comes from being able to build up layers of these atomic actions in spontaneous user-created structure.

Contrary to an earlier comment, I don’t think that it all needs to be text-based (btw HTTP, XML, etc are not interface standards and QWERTY/Dvorak are just small permutations on the same HW interface). After all, a piano is not text-based.

I *do* think it needs to give the user continuous feedback based on the atomic actions that they have put forward. On a piano it is sonic feedback, but mastery interfaces could just as well be visual or textual (or tactile, but no good HW infra for that yet). Anyhow, great discussion this week.

Moi wrote:

> the organisation sets out the criteria for usable and efficient design which may run counter to what we might consider a scientifically bad design

My organisation makes us use Lotus Notes, but it is still shit.

> The Unix command line is intractable because of its limitless extensibility

Its “limitless extensibility” is also its power. How I’ve longed for GUIs which allow the kind of composition which a CLI gives. I look forward to see what Longhorn appears to promise (Chris Adams’ post), though it would be kind of funny if Microsoft (a GUI company) produced a CLI as good as it sounds.

J. Scott wrote:

The criticism of Dvorak as a better layout is that:

“It is impossible to tell from the original study if it was properly controlled”

and

“Dvorak did the study himsef so it must be biased”

Maybe it wasn’t properly controlled. Maybe Dvorak was biased and faked the results.

But there is no evidence of that. The Economist has disproven nothing.

I use Dvorak. I type faster than I did on QWERTY. And my carpal tunnel is gone.

Pizar wrote:

“If they have to read a manual, you designed it wrong.”

A friend of mine with a degree in CS was explaining that of “expert level” or “mastery interfaces” could not and should not be simplified into a convenient GUI system because of the nature of the complex tasks the database is used for. I dissagree. Sure, a super user who has trained and knows all the commands and buttons can be amazingly efficient at using the database. However, anyone who has not taken the official class can get absolutely nothing accomplished. Why is that? Because it does not make allowances for different user levels.

Take any modern OS. Anyone who uses Windows for any amount of time knows control-c and control-v. Or control-s to save, control-o for open. New users aren’t experienced with those shortcuts and I often watch them manually select those options from the menu. They learn eventually but in the meantime they can still cut and past without having first learned those key combos.

Despite its power, a newbie is still left staring at a CLI with no clue what options are available or any indication of how to perform even the most basic actions. The first time at a restaurant people look through the menu. Once you are a regular, you know what’s offered and can order without even looking. It’s a system that you can gain “mastery” of, while still being easy enough for an inexperienced user to get what they want done. If something like getting a baja chalupa is that flexible, can’t we ask the same of software?

- Nathan Pizar

Paddy Mullen wrote:

From what I remember keyboard speed records committees (?) have disalowed dvorak keyboards from competition. Shortcuts are great. I normally just stumble onto them, but once I’m familiar with the keyboard shortcuts of a program I am many times more efficient.

Euman wrote:

WRT piano design, check out the history of keyboard design and you’ll see that many designs have been tried, particularly wrt implementing different kinds of temperament. None of them succeeded for the simple reason that they were just too hard to play compared with the “standard” keyboard. Which is also why equal temperament won the temperament wars - it’s just more musically usable.

Johan wrote:

Monad (the CLI) will not be in Latehorn according to Microsoft.

Greg wrote:

Mac users may, for example, check out iTerminal which is a GUI for Terminal.app ( www.seraphimsoft.com ). But there also are of course file managers such Midnight commander or krusader.sf.net (which i think is also available for Windows). There are some very useful one-line commands to be sure, but to me the big win as to the CLI is scripting (for some Unix script examples just go to www.shelldorado.com ; and for a CLI-centric book see In the beginning was the command line at www.cryptonomicon.com/beginning.html ). My personal piece of advice to anyone who likes to learn shell scripting is this: also take a look at learn.perl.org (at least on Unix-flavor systems you may execute a shell command/script from your Perl script: see man perlfunc & system).


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?