Hacker News Reader

Then why do I spend many seconds trying to find certain buttons that are right in front of me ("Where the hell did that ordered list button go?") and even longer trying to find buttons that aren't even there?

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

No one is arguing that guis turn you into some kind of unerring productivity robot instantly navigating through huge sums of interface magically.

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.

Likewise, nobody is saying those kinds of tasks are served better by a terminal program. However, I would argue that adding an autocompleting command line to any of those kinds of programs would make them better, but that is a different point.

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.

GUIs are great for getting responses from the computer. CLIs are great for telling the computer what to do clearly and effectively.

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 example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).

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.

It's not quite right to imply that because a command line isn't graphical it isn't using human visual recognition - we still see CLIs.

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.

> […] gives the skilled UX designer the ability to convey a lot of information without making people think.

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.

An environment shouldn't enforce thinking for the sake of learning. The average user will need to think enough to figure out what to do, they don't need brain-training puzzles as to how to do it.

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.

> An environment shouldn't enforce thinking for the sake of learning.

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.

Graphical interfaces by definition don't have a chance to communicate with each other, but I'd argue nowadays we have quite strong import/export functionality everywhere, so this problem disappears in most cases.

On another note, you're also stuck with defaults if you happen to use a badly written CLI (takes input from files only, etc).

Given your first paragraphs about forced learning, your last one about how you don't know how to fix your problem in Windows so you just leave it broken is a strange contrast.

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

And if you do need sed and regexes, get sed for windows: http://unxutils.sourceforge.net/

That's just a cached thought: "Windows CLI sucks, don't even bother". In hindsight that sounds a bit silly. And I know Bash better (along with sed, grep, find…). Anyway, thank you, I'll try this command.

Nevertheless, I think there is a reason for my erroneous cached thought: the overwhelming emphasis on the GUI.

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

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.

I recommend installing Strawberry Perl on Windows machines. It's a great substitute for sed, awk, etc. and is even as powerful as Perl. :)

Use of a computer shouldn't be a visual experience for most tasks. You have a mental model of what's going on, and then poke stuff to verify the model and to affect state.

    > However, 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 a good point. Visual recognition helps with the first hurdle of learning.

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.

GUI tools can scale well for complexity. Just look at how an experienced user can drive CAD or finalcut. It is just a matter of learning the interface, and understanding the domain it targets.

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.

> Humans are visual animals, GUI's are a result of our evolutionary history.

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 is a task done so fast and effortlessly by the human brain, that we don't even think about it.

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.