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