Life on the Command Line
lenz.unl.edu
lenz.unl.edu
<Quote>
...but I’ve seldom heard a usability expert end a discourse on human
factors by acknowledging that graphical systems are only really
the “best” solution for a certain group of people or a particular
set of tasks. Most take the graphical desktop as ground truth –
it’s just the way we do things.
The Human brain has estimated 2 billions nerves in the V1 & V2 region. Those regions are responsible for rudimentary visual recognition, of objects with different: Form (grouping, orientation, size), Color, Motion, Spatial position. This is one of the most powerful parallel computational systems known to men. It takes humans about 10 milliseconds to recognize an object standing out in those respects (e.g. gray text and one red word).
Why am I putting this down? / What are GUI's good for:
scan 1.3 million pixels (1280*1024 screen)
ignore all text fields
find all buttons
identify a symbolic representation of the task at hand (e.g. save)
Humans are visual animals, GUI's are a result of our evolutionary history.
I am not stating that GUI's are the fastest way to get the job done. You still have to move the mouse, etc. A skilled Command Line user can get the job done without a 40 milliseconds delay and moving the mouse might take longer than typing the command. However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
Graying a button out, making it red, green,... gives the skilled UX designer the ability to convey a lot of information without making people think.
We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.
Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.
Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
The point is that well-designed GUIs can make better use of a large subset of the human brain. Poorly designed ones will not.
And, some tasks are so inherently visual that they're not even up for debate. For example, there simply is no opportunity for a command line tool to enable what Lightroom or Aperture enable. It's simply too visual a task.
The core issue at hand is this: people should really look at the tasks they do and consider whether a command line interface could be beneficial for the task, they might likely be in for a very pleasant surprise if they try it.
I want a command line that can draw the output graphically. I want a GUI that can be driven through text.
If anyone's ever used Rhino3d, it has a command line at the top of the window. That was probably the single most productivity boosting feature of the entire UI.
A primary non-example is Ubuntu, where $PS1 is colorless, and `grep --color=auto` is not aliased to `grep`. It is the least user friendly distro if you use the command line.
What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term.
More specifically, a GUI environment may be easy to manipulate at first, but if you need anything odd (but dead simple), then you have to find a program to do it for you, or do without it. The CLI, on the other hand, by forcing you to write your commands (suboptimal in the short term), gives you the idea that maybe, just maybe, you could write those 2 or 3 commands in a file so you don't have to type them every time. The next thing you know, you want to automate everything. And you can.
Even more specifically, take me. I use a laptop under Gnu/Linux (for serious work), and a Desktop under Windows (mainly for games and videos). I often download English subtitles for English or American films (I'm not a native speaker). But those subtitles often comes with annotations between brackets for the deaf (things like [Predator growling], [wind blowing]…). I want to get rid of them. That would be one line of sed… But it's for films, and therefore on my Windows desktop. Migrating it to my laptop is tedious, so I haven't written the damn script yet.
imo, we should be thinking about the task we are working on, not the interface we are using to accomplish our task, so the best interface is the one we don't even notice.
Many GUIs fail to deliver in the long term, but it is not true in all cases. Take Adobe Photoshop for example; its interface is good enough in the short term to play around and intuitive so that the user can issue a very sophisticated command.
Graphical interface is a huge and blurry combination of science and art, and it still cannot solve every possible problem. Your subtitle editing case is specifically a command-line one - but there are good GUIs that can help you with search-and-replace in text files.
I agree. However, I'm not sure the environment should bend over backwards to not make you learn. Probably depends on both the task at hand and the user. If only I could extract some generally useful heuristic…
Photoshop is an inherently graphical application, because (i) it works on images, and (ii) it is essentially an interactive program. If however I suddenly wanted to do automatic image processing, I would very much like to have access to some programmatic interface, most probably batch sub-programs that one could pipe together from the shell.
> Your subtitle editing case is specifically a command-line one
Yep. My point was, those cases exist, though I recognize the GUI is sometimes equally useful, if not outright superior. But the problem of GUI-only environments (and Windows specifically) is that if you don't even know what is a command line, you can't think of CLI tasks as CLI tasks. In my example, my first reflex was "sed", followed by "crap, Windows". On the other hand, a purely GUI user would have a "does a program does this?" reflex if he has any reflex at all.
GUIs make it very hard to combine programs. So in practice, they don't. They don't even tell the user about this concept. Instead, they tell the user that functionality is given from above. If no program does this, you're out of luck. I fear this contributes to the sense of helplessness of many users. CLI, on the other hand, quickly makes very clear that programs can be combined, that 5 lines scripts can be very useful. Sure, there will be a point beyond which one will need the help of a geek friend. But he would at least think of calling her.
Another point where GUIs easily fail hard is user customization. GUI programs tend to embed every functionality, leaving very little for external programs. For instance, Emacs or vi won't replace the built-in editing functionality of Thunderbird or Firefox (barring dedicated extensions). So I'm kinda stuck with the defaults.
On another note, you're also stuck with defaults if you happen to use a badly written CLI (takes input from files only, etc).
If the subtitles are plain text with annotations on their own lines, a one line command will strip them out:
for /f "delims=" %x in subtitles.txt do @echo %x | @find /V "[" >> subtitles2.txt
Nevertheless, I think there is a reason for my erroneous cached thought: the overwhelming emphasis on the GUI.
It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.
teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition
This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.
BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.
> However, teaching the average person to use a new
> piece of software is near impossible without
> utilizing their incredible brain power for visual
> recognition.
But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.
There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.
I would argue that the real hurdle to learning is accessing and understanding the documentation. In this respect CLI has the advantage with man pages. With UI the easiest way of understanding is to ask another human, which has obvious limitations.
Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.
And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.
But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.
And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.
> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.
But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.
Any thought that goes into the interface of a terminal-based program goes toward the keyboard interaction; there isn't a GUI to think about. Because of this, terminal-based interfaces are usually much better than any graphical application.
From the command line, I can navigate the filesystem, install software, search, edit text, download files, play music, and send email all without even looking at the monitor. Once you're comfortable with it, you can just close your eyes and let your brain and your fingers do all of the work.
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
And that, my friend, is modern day integration between gVim and GMail on Windows.
Actually, there's no reason for this to depend on the cli. In Firefox, there are plugins which give you a button to click under every text box which open your favorite text editor with a buffer already open containing the contents of the text box. Edit the buffer and save, and your changed appear in the text box. (This is, in fact, how I am editing this comment.) On Unix systems, a graphical mail program could easily use a shell call to get text from an external program. The only problem is, this just doesn't really happen. Vendors prefer proprietary interop with their own products rather than more universal interop methods.
Personally, I type the above sequence pretty much instantly, though, so... I don't mind: http://screencast.com/t/jw0LFrlBg
command line mail clients dont need any of that. you edit it in vim and send it from vim. or you edit it from your email client THROUGH wim and send it also directly.
No utterly long key combo. No app switching. No delay. No complexity. No cut-and-paste.
That is the actual point.
He gives the example of _nmh_ for email reading. I've been trying it out all morning. I think the stock _mail_ program seems to be better (although I use alpine on the CL). I need to do extra work to see gmail messages with _nmh_ (not with mail).
>mhshow: don't know how to display any of the contents > (content multipart/alternative in message 2)
Also, the _comp_ command for composing a mail launches vim (unable to stop that) which gives an error on what_next. I tried pico, that works.
Not sure _nmh_ is the way to go today. If I had to use the CL, I'd use _mail_ instead.
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
In the Beginning was the Command Line
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.sht...
> This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
I now find myself trying to do as many things as possible in emacs, but emacs + terminal + browser is extremely powerful. I'm not yet to the point of running a shell (elisp shell or otherwise) in emacs, but this troika is very powerful, and I'm extremely happy with it.
Sent from my VIM.
# By default up/down are bound to previous-history and next-history,
# respectively. The following does the same but gives the extra functionality
# where if you type any text (or more accurately, if there is any text between
# the start of the line and the cursor), the subset of the history starting with
# that text is searched.
"\C-p": history-search-backward
"\C-n": history-search-forward # not relevant on osx
#$include /etc/inputrc
$if Bash
# append a '/' to show a dir is a dir
set mark-directories on
set mark-symlinked-directories on
# no audible or visual bell
set bell-style none
# use ls -F style highlights for completion
set visible-stats on
# go right to showing multiple options
set show-all-if-ambiguous on
# ctrl-p cycles through options
"\C-p": menu-complete
"\C-x\C-x": exchange-point-and-mark
"\ew": copy-region-as-kill
# easier back and forth by word
"\C-b": backward-word
"\eb": backward-char
"\C-f": forward-word
"\ef": forward-char
$endif
# Two silly macros
#
# Insert double quotes & set cursor between them
"\C-x\"": "\"\"\eb"
#
# Insert single quotes & set cursor between them
"\C-x'": "''\eb"I get shell access on one of my webhosting companies (DreamHost), so I scp data up to it a lot, but the path is a bit of a pain to type, except for this shortcut:
# ctrl-d ctrl-h is a mnemonic for DreamHost
'\C-d\C-h': login@mysite:login/path/to/mywebsite/data etc. # map "page up" and "page down" to search history based on current cmdline
"\e[5~": history-search-backward
"\e[6~": history-search-forward
More importantly, and what most people missed out is that, this history searching works on ALL command line interfaces, including bash shell, ipython, and psql.
Seriously, a command line advocate who doesn't know about this can't be serious.
Unfortunately, I've never found an email client I liked, whether console or GUI, so I just stick to Fastmail's web interface.
I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).
That's why I came to despise the MUA/MTA schism of Unix so much: If I reply to an email on my laptop, I won't know it on my desktop. The only solution is to have a central server you can ssh into. Clunky solution at best.
Solution: use Mutt's semi-new IMAP interface. Nothing is stored locally, and I can see whether I've replied to emails, and I can delete/move emails regardless of the computer I'm currently on.
There's any number of ways I can find and filter files using the find command, and then with xargs I can pipe them all through a sequence of simple operations.
In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite.
Often we consider the command line to be for expert users, and consider it our job as system designers to hide it from the rest. But when you consider that most people are able to learn basic calculus at school, a skill that has practical use in real life in only a limited number of professions, why don't we teach people to use the gnu tools at school? A skill that would enable them to use computers in powerful ways for the rest of their lives?
whilst i certainly agree with this, i would speculate that 80-90% of the average user's time is spent carrying out a handful of simple operations that are better catered for by guis. for the other 10-20% we have our virtually infinite space: the shell.
I map 'xc' to 'xclip' and 'xp' to 'xclip -o' (paste) with shell scripts.
Copy to/from clipboard via pipes.
Though X11 copy/paste works pretty well also. There are the odd occasions where a mouse is the right tool for the job.
besides "easier to understand" (which depends on an individual's experience and knowledge) I thought those were pretty much acknowledged / obvious. Not bold at all.
no?
This is why, even though I disagree with many of the things Apple is doing with the OS, I think Apple is on the right track with the app lifecycle model with Lion. Most computers ship with far more memory than people actually use these days; why should you constantly open and close apps when you can just leave them resident?
Most of the reason people even bother closing apps anymore has less to do with the resource-juggling that made it necessary in the past, and far more to do with workflow and window management.
For me and people I know, the mail client is the first app open after boot and it is always "open". It takes me less than 2 sec on my 3 year old computer to display new mail.
I see no evidence that designers are opposed to command interfaces given that many of the graphical programs I use incorporate them where appropriate.
The world isn't black and white. GUIs can be fast and pointing can be faster than typing. In other cases, a written command is fastest way to get exactly what you want.
It would be perfect solution if all OS/applications would have command line but with visual output. Instead of "menu" at the top, just command line.
There some good modern approaches to this problem, for example gleeBox for control of internet browser is nice way of integration of console style control to GUI application.
Otherwise, terminal + browser gets me through 90% of the day.
One might say it's slower then a spreadsheet. I don't know. I can type an one liner awk summation/average, faster then it takes OpenOffice to load. This is to me the most common spreadsheet operation.
For more complex task, I feel that I'm working faster in awk (it's a full blown high level programming language, after all). I'm not sure it it's actually faster or if it's only my opinion though.
I'm happy with this setup.
In the event that I need a visual prototype to work with, together with a client or business partner, I don't think it's all that horrible to prototype something in Excel, and later port it to Haskell if necessary. But that's of course because I already, at some point, reinvented the wheel to make this possible. So now I'm mostly just reusing code which I already have available.
That said: strings are lists of chars, and Haskell is strong at pattern matching (esp within lists) in a bunch of different ways, so trivial text parsing tasks are trivial and intuitive in Haskell. For anything slightly more complex, there are regular expression and enumerating libraries which can do the job alright (and efficiently if I may say so).
EDIT: I'm sorry, can you give me an example of a problem so I can give you an example of a solution? :-)
[haven't tried it yet]
Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.
[1]: http://www.gnu.org/software/oleo/ [2]: http://www.syntax-k.de/projekte/teapot/
Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.
http://www.jnd.org/dn.mss/ui_breakthrough-command_line_inter...
A real CLI warrior uses sh, ed, and mail. :-)
Building high quality productivity tools that are able to exceed the expectations of expert users is both difficult and time consuming... and there is almost zero market incentive to accomplish the task properly for consumer-class applications.
[edit] this is not to imply that consumer apps are trivial -- I think I once saw Minsky discuss an early attempt at AI that started by interpreting children's books, thinking that would be easier than understanding journal publications, etc. -- it quickly became clear that the task of parsing a children's story requires an immense store of implicit context and as such, was completely intractable at the time. The challenge of writing 'simple' things like email, text editing, and spreadsheet apps seems related to that.
i used to use the command line for everything but recently switched to using guis.
switched mainly because gui applications seem nicer to me for completing common desktop tasks, for example listening to music, i can just click the rhythmbox applet and select a song as opposed to something like "mplayer ~/Music/some\ artist/some\ album/*" or manipulating files, it seems a lot nicer to me to be able to pull a file onto my desktop than type out (even with tab-complete) "mv foo ~/Desktop". ofcourse, there are exceptions when using a shell is much easier, for instance if i want to copy a large number of files whose filenames have some similar pattern.
it's also very nice to be able to install some new program and just use it, why should i have to read long poorly written man pages?
at the same time i still use a shell everyday, but as a programming/administration tool.
OF course, for manual control ncmpcpp - which is ncurses - is easier to use.
That said, I find offlineimap is a better tool than mutt's built-in IMAP support.
When you think about it, the fact that command-lines are text-only is really just a historical artifact and it's nothing inherent to the notion of command-lines.
I find Neal Stephenson's 'In The Beginning Was the Command Line' to be a nice overview of why GUIs became the dominant paradigm over the CLI. I understand the desire to be 'user-friendly' to less tech-savvy people, but it's a real shame that we've equated 'functional' with 'has a good-looking graphical front-end'.
Even a few weeks after I began using the CLI (almost) exclusively, I couldn't imagine going back.
Anyways, I think icons are overrated, and the text hyperlink rules the universe.
> Type pine or mutt (for example), and your mail is before your eyes in the time it takes a graphical user to move their mouse to the envelope icon. Type q, and it’s gone.
Not quite. I need to wait for "fetching message headers". It takes a while. mutt and IMAP.
I have more than 10k emails sitting in my inbox and with this option mutt loads the headers in around one second (over the Internet).
And of course I could fetch all the emails in the background and use mutt locally, but I didn't bother yet.
Using mibbit or bitlbee with an IRC client works for me.
EDIT: Not mibbit, I meant minbif (http://minbif.im/)
There's POP, IMAP and SMTP support in mutt for convinience, but that has to be enabled explicitly at compile time. However, this means that mutt will fetch all the mails when it starts and this is slower than having it already locally fetched.