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.

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.

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.

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.

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.

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

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.