

The limitations of terminals as an interface - KentBeck
http://www.threeriversinstitute.org/blog/?p=409

======
blahedo
His comments about cognitive load are valid, and a real concern---a good
interface needs to let you focus on the core stuff and not make you remember
everything about everything. There are two big weaknesses, though, at slightly
different levels of interface.

At the input level, he seems to forget that keyboards (with somewhere between
50 and 100 keys that I can strike exactly and digitally) are fundamentally a
better input interface for expert operations than the mouse/trackpad/pointer
(with a rasterised but basically more analog feel that makes me "look where
I'm going"). GUIs are great but there are relatively few that have the level
of keyboard control that you can get with a terminal-based app.

The second is that text apps let me give commands with arguments much more
straightforwardly; there is a _language_ I speak, where GUI-based stuff is
more like grunting and pointing. Clicking a mouse on a button or menu item is
like calling an argumentless function(). Maybe you highlight something first
and it's more like an argumentless selection.method(). Being able to type your
command out, if it's at all complex, is just simply more powerful, and so
text-based interfaces aren't going away any time soon.

~~~
ams6110
Exactly how I feel. With text-mode interfaces I have the feeling of telling
the application what I want it to do in verbal terms, which I find easier to
remember than which button or menu selection does what I want.

The author states: _The disadvantage I feel most keenly when using a terminal
is the cognitive load. I have to keep more in my head when using a
terminal/command-line-based interface._ Again I find the opposite to be the
case. When I use Visual Studio I feel overwhelmed by the GUI. Panels and
scroll bars everywhere, buttons, menus, etc. Contrast to Emacs, where I have,
very simply, one large area for editing text. I can focus on what I'm doing.

It's sort of a Feng Shui thing: the busy GUI is the cluttered room that drains
your positive energy and causes constant low-level stress. The text interface
is the well-organized room that has everything you need but it's out of the
way until you actually use it.

~~~
jcapote
I agree with you as well. However, this should be taken into account (wish I
could find a reference for this):

"A study done by Bruce Tognazinni when we was at Apple (a company that has had
a good track record of designing for the mouse) showed that using the keyboard
felt faster but was slower while using the mouse felt slower but was actually
faster."

~~~
blahedo
It definitely depends on what you're doing and how your interface is set up.
If you're editing text in a non-monospace font at a non-super-high font size,
and you want to insert between (say) two lowercase L characters, you need some
fairly precision mousework, and that takes time.

And it will almost certainly always be easier to do actually complex
operations via text (especially if you might be repeating them or slightly
modifying them). Just yesterday I was generating a PDF packet with pdftk, and
had a command line of the form "pdftk file1.pdf file2.pdf blank.pdf file3.pdf
cat output outfile.pdf" that I kept having to re-run (because I'd modified
file2.pdf) or tweak (because I added file4.pdf). It's possible that the first
pdftk would have been quicker in a GUI---though I'm not convinced---but in the
aggregate there's no _way_ a series of GUI ops would have been faster. And I'm
not even sure how I'd accomplish something like "mv *.jpg jpg_subdir/" in
something like Finder without a lot of manual finding and clicking and
dragging and making mistakes.

------
keyist
A seasoned CLI user will trump a seasoned GUI user every single time for the
majority of tasks.

Take a task like thumbnailing every image in a directory to a certain size.
With CLI it's just looping over convert(1). With GUI you have to clicky-clicky
to get to the directory, drill down to the options, swap to keyboard to enter
sizes, etc.

Not to mention the richness of CLI options mean that an equivalent GUI
offering would be insanely complicated. Try designing a GUI frontend for sed
or awk. Or a file rename utility that matches Emacs Wdired mode in power and
(interface) simplicity.

Configuration: changing a text file vs clicking on/off a checkbox. You can
write a tiny script that flips options between two configs you like, versus
more clicky-clicky. You can copy configs around, diff them, grep them.

tl;dr - yes CLI has more cognitive load (in that you need to be more familiar
with your tools vis-a-vis GUI equivalents), but you get so much more in
return.

EDIT: quick list of CLI utilities if anyone is interested

* feed reading: newsbeuter

* music playing: ncmpcpp+mpd

* irc/im: irssi+bitlbee

* torrents: rtorrent

* git browser/pager: tig

Many more here: <http://cli.homelinux.net/CLIapps.html>

~~~
lanaer
If a GUI tool is written where you can just select items in the
explorer/finder, launch tool (from keyboard), enter thumbnail sizes, then GUI
may win, since you won't have to switch from file browser to CLI in the first
place.

Problem with GUI is that you need a new tool for each such task; we don’t yet
have a generalized way of handling such things.

------
redcap
There's stories about tablets and so on recently, so that got me thinking a
little bit about what input devices would be like N years into the future?

For programmers, are mouse and keyboard still going to be king? I can imagine
that maybe the mouse could be replaced or supplemented by a camera that
matches where you're looking at to a cursor position. This should be faster
than mousing around.

For text input the options are a keyboard or voice input/brain input. I don't
think the majority will move from QWERTY anytime soon, and voice input may not
take off for the simple reason that you're making noise. Brain input might be
interesting.

As for any fancy ways of generating programs (plugging components together),
you will likely still need to go to a textual level to capture all the detail,
so no real application for anything touch sensative there.

As for what form a keyboard might be, your touchpad could generate a virtual
keyboard when you need it (and have smart materials to give tactile feedback)
and fade back to a touch system when you don't need text input.

I imagine you'll still need an ergonomic setup and regular breaks to avoid
occupational overuse syndrome.

~~~
blahedo
Science fiction gives us all sorts of ideas for futuristic interfaces, and I
think (and hope) many of them come to fruition. But cursor position dictated
by eye movement will be tricky or impossible---we can more or less do this now
with the right equipment, but your eyes saccade all over the place,
subconsciously, even when you think you're looking at just one thing. You've
noted the biggest problem with voice input: it'd suck anywhere other than a
private office! (Not to mention the homophone errors. True voice recognition
is AI-complete.) Finally, look up the fate of the IBM PC Jr keyboard to find
out why a fade-in touchpad keyboard will be less than ideal for fast, reliable
text entry....

~~~
redcap
I think I've seen the a picture of an PDA attachment that uses a laser to
project a keyboard on a flat surface. Of course no tactile clickyness, but
it's got to be better than 2 finger typing that happens with most smartphone
inputs these days.

------
jeremyswank
what i find interesting are the places where cli and gui are merged in such a
way that uses (at least some of the) strengths of each. on the mac, i use
quicksilver, which is kind of a gui for text-entry commands. adobe indesign
and netbeans ide each have a drop-down field that's invocable by keyboard
shortcut that allows you to directly access options and settings hidden in
various menus and palettes by typing a few letters and arrow keys. the firefox
plugin ubiquity also has these qualities, and firefox has find while you type
built in. these are not terminal equivalents by any stretch, but they are real
time-savers, and show the mouse up for the burdensome appendage that it is
(forgive my exaggeration). i think if more gui designers and gui programmers
would adopt this approach, computer interface design would move forward, imho,
in a more useful and more interesting way, instead of slavishly using real-
world object metaphors such as the desktop.

------
jrockway
I disagree with this. If you have a GUI, sure, you have fun buttons to click.
But if you don't understand what those buttons actually do, you will mess
things up if you click them without thinking. The solution to this is to read
the documentation and understand what you are doing.

If you don't have a GUI, then you will have to read the manual to find out
what to do.

The end result is the same; you have to read the manual.

(Also, you can have discoverable interfaces without graphics. Open a file in
Emacs and type M-x describe-mode. From there, you have a description of the
commands available, and links to follow for more details about any aspect.)

