Wednesday, October 9, 2013

Critique of the Command Line Interface

No matter how complex the overall system, there is no excuse for not keeping simple tasks simple.” - The Humane Interface (Raskin, 2000)


Consider the following workflows for installing the popular open-source office suite “Libre Office”:


Graphical User Interface:
1. Open some sort of start menu (or apps folder, etc.)
2. Navigate to your browser.
3. Type “libre office” into your favorite search engine.
4. Find “libre office” in the results.
5. Navigate to the download page.
6. Locate the download link for your particular operating system.
7. Wait for download to finish.
8. Navigate to “downloads” folder.
9. Open installer.
10. Click “next” a few times.
11. Done.


Command Line Interface:
1. sudo apt-get install libre-office
2. Press “enter”.
3. Wait for download to finish.
4. Done.


Perhaps contrary to intuition, the task of installing an office suite is much easier and quicker without a graphical user interface. Of course, once one really begins to consider the nature of interacting with a machine, it only makes sense. By “speaking” to the computer directly through the command line, the user removes the abstract layer – the GUI – that stands between.


The command line interface (CLI) has been around since as early as the 1970’s, and is not likely to go anywhere soon. It serves as a natural progression of human communication (albeit in this case between human and machine). As Neal Stephenson put it in his treatise “In the Beginning Was the Command Line”:


“We possessed a human/computer interface a hundred years before we had computers. When computers came into being around the time of the Second World War, humans, quite naturally, communicated with them by simply grafting them on to the already-existing technologies for translating letters into bits and vice versa: teletypes and punch card machines (...) This way of working did not even have a name at the time, but when, much later, an alternative became available, it was retroactively dubbed the Command Line Interface.”


Despite the Command Line Interface’s longevity and it’s die-hard advocates (and the author counts himself among them),  with the advent of the graphical user interface (GUI) the CLI has seemingly fallen into a state of antiquity. “The command line is a crusty, old-fashioned way to interact with a computer, made obsolete by GUIs, but a small hardcore of people who refuse to move on still use it,” contends a user on the Tuxradar forums (Garling, 2012), and they are certainly not alone in this opinion. However, rarely does it seem that such criticism is accompanied by proper arguments based upon design principles -- and, thus, I offer my own analysis of the CLI as an interface.


“Interaction Design” by Rogers et. al. identifies five design principles: visibility, feedback, constraints, consistency, and affordance (Preece, 2011). It is by these five design principles that I evaluate the (*nix) Command Line Interface. Visibility


The Command Line has no menus, no buttons, and no labels. There are no visible indicators whatsoever as to what functions are available to the user. Instead, the user is presented with a blinking cursor and a blank screen. While a typical user reaction to this sort of minimalistic interface might be that of bewilderment, there is a perfectly good reason for it. A standard operating system ships with tens if not hundreds of thousands of commands -- and countless others are available through millions of user-developed packages. It is simply impossible to offer the user a graphical interface for every command. But, not to worry! Just as the English language with it’s million-plus words has a dictionary to keep track of them all, so does the command line have a manual. Simply typing “help” and pressing enter reveals to the user scores of extremely common commands with their various uses as well as instructs the user how to seek more information about each command. Of course, the downside to this “zero-visibility” approach is that there is a rather steep learning curve, and the fact is that there are only a handful of commands that get used regularly (such as rm, mkdir, cd, cp, etc.) -- a user is certainly at the mercy of whether or not they can access a list of commands -- and if they can find the specific command that does what they wish.


Feedback
In the command line interface, is generally immediate and obvious. For example, say that you wanted to change to a different directory, but you messed up the spelling of the command (say you typed “csd” rather than “cd”). You will get an immediate error: csd: command not found. Feedback is immediate. However, the command line is also very unforgiving. Say that you wanted to delete a file -- you’d simply type rm [file]. Now say that you mistyped the file-name: rm file1.txt rather than rm file2.txt. Unless you’ve explicitly programmed your CLI environment to ask: “are you sure?”, your file is gone -- immediately. While this sort of immediate feedback can be absolutely devastating for a user, it is also very convenient, particularly when there is a large number of files to be dealt with.



Constraints
A most obvious constraint that the command line puts on the user is the single mode of interaction -- that is the keyboard input and monitor output -- no mouse, no pointer. What’s more, in the case of a single command line window, the user is limited to a single task at a time. Unlike a Graphical User Interface which allows for many spaces of interaction at once, the command line gives only one. Restricting the user to deal with a single line at a time, it could be argued, provides for a paradigm that is much closer to the serial processing paradigm that actually takes place in most computing and, indeed, the human mind. It also could be argued, however, that this restricts the user from being able to multi-task and / or refer to different sources of information in a convenient way.


Consistency
The command line is, perhaps, the most consistent interface in all of computing. No matter the operating system or even the application that benefits from a command line interface, the commands are either similar or identical. Once one has come to grips with the command line in one context, nearly all command lines become available to the user.


AffordanceThe command-line affords the entrance of commands -- as that is the only thing that it allows. The rhythmic blinking of the cursor beckons the user, “I’m waiting”. And the keyboard provides a single mode of interaction -- to respond to the command-line’s call for input.  It is a simple and elegant solution as it is based on a simple and elegant machine -- the teletype which, in-turn is based on an even simpler machine -- the typewriter. The only catch is, it is not necessarily obvious what commands are acceptable in the first place -- as discussed under visibility. Unlike a typewriter, the key combinations the user enters actually matters to the machine. However, once again, the “help” command is available for those in need of guidance.

The command line is certainly not for everyone -- and there are some who will live their entire computing careers without ever seeing one. However, because of it’s sheer simplicity, elegance and power it remains relevant, after nearly fifty years.


   





References

           
Garling, C. 2013. Why the GUI Will Never Kill the Sacred Command Line | Wired Enterprise | Wired.com. [online] Available at: http://www.wired.com/wiredenterprise/2012/07/command-line/ [Accessed: 10 Oct 2013].
           
Preece, J., Rogers, Y. and Sharp, H. 2011. Interaction design. New York, NY: J. Wiley & Sons.
           
Raskin, J. 2000. The humane interface. Reading, Mass.: Addison-Wesley.
           
Stephenson, N. 1999. In the beginning ...was the command line. New York: Avon Books.