The limitations of terminals as an interface

http://www.threeriversinstitute.org/blog/?p=409

by KentBeck • 17 years ago

22 22 17 years ago

blahedo3• 17 years ago

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.

ilaksh4• 17 years ago

"At the input level, he seems to forget that keyboards (with somewhere between 50 and 100 keys that I can strike exactly and digitally)"

A GUI does not preclude the use of the keyboard. Keyboards are terrific for entering text and many other things.

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

This is fundamentally incorrect. See the millions of Photoshop, Visual Studio, Notepad++, GEdit, Eclipse, Microsoft Office, Autodesk, Blender, Visio, Labview, Mathematica, Quickbooks, SAP, Oracle and other users of proprietary application-specific software. Do those users consider themselves to be experts? Do the accountants working at your company consider themselves to be experts? Do you really believe they would be more productive if they had to work in a terminal all day?

"GUIs are great but there are relatively few that have the level of keyboard control that you can get with a terminal-based app."

You suppose that this level of keyboard control is required without providing any basis.

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

The way this works in interactive GUI applications is that they provide input forms and status indications to communicate with the user.

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

Textual command systems and scripting languages are frequently integrated into GUIs. Another natural progression though is for frequently used commands to be represented by interactive widgets and dialogs. The fact that interactive graphical controls for many commands are missing often is simply the case because they have not yet been implemented.

I think that there is definitely some work to go in integrating textual language-based communication with visual interactive systems and exactly what form that will take I cannot say. But I think its important not to throw out the visual, two dimensional, interactive and even multi-user collaborative capabilities we have now but rather to integrate them with finer-grained language-oriented features of textual languages.

lanaer3• 17 years ago

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

-------------

Um, isn’t that particular quote you have there about keyboards vs. mice, rather than command-line vs. GUI? (Next paragraph he talks a bit about one advantage of command-line, but it is a different point than this one).

Expert photoshop users rely quite heavily on the keyboard (keyboard shortcuts specifically), for many operations. The mouse is also used heavily, of course. The keyboard just can’t select portions of an image very effectively, or help you point at a pixel you want different, etc. Whenever I see a Photoshop expert do something to the image, though, they’ve used the keyboard, where beginner users (like me) just use the mouse.

For most of the others, I expect expert X users are similar to expert Photoshop users. Then there are the rest, which are very text-oriented and therefore mostly keyboard-driven by default.

On to the actual GUI-vs-command-line argument.

You say “The way this works in interactive GUI applications is that they provide input forms and status indications to communicate with the user.” His argument was that this is less straightforward than just typing the arguments next to the command. I do not think you have refuted his point.

The simple fact is that both interfaces have their places. I do a lot of work in both, and I think it will pretty much always be that way (for me).

I do not think text-oriented command interfaces will go away while we still read & write, though hopefully they will indeed become friendlier with graphical interfaces.

ams6110• 17 years ago

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• 17 years ago

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

ilaksh4• 17 years ago

The Visual Studio GUI probably is suboptimal. You may be distracted from the editing window sometimes by the other controls. One thing you can do is disable or hide many of the Visual Studio controls.

However, the cognitive load of this distraction is lower than that of having to remember keyboard commands.

Once you have spent a certain amount of time in EMacs, (a very long time) most of those keyboard interactions will become subconscious. Its a long time though. Also, the most frequently used keyboard commands are available in the GUI interface for people that choose to learn them. And environments like Visual Studio are often fully customizable, enabling users to add their own keyboard shortcuts, macros, etc.

One feature in most GUI environments that you may not have discovered is the 'Tool Tip'. By hovering your mouse cursor over various toolbar buttons you can cause a short textual description to appear.

yycom• 17 years ago

Trite as it is, both text and GUIs have strengths and weaknesses. I don't understand why we can't have both. I'm pissed that I'm forced to use the mouse in Firefox (losing focus bug for many years) and Mac OS (why can't I tab to the button I want to press in a dialog), and I have to dig around the manual to learn the arcana of vim.

IMO the best interface is one where I can point and grunt to do arbitrary things, and while doing so the interface teaches me its own language with prompts and contextual help.

blasdel• 17 years ago

Hit ^F7, or System Preferences > Keyboard & Mouse > Keyboard Shortcuts > Full Keyboard Access > All controls

You know how the default action in a dialog is a solid blue aqua button, and hitting enter presses it? When this preference is turned on, there's an additional blue tab-selection halo that fires its button when you hit spacebar, and it always defaults to the cancel/don't button.

azakus• 17 years ago

There is Vimperator, a plugin that applies vim keybindings.

keyist• 17 years ago

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

lanaer3• 17 years ago

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.

KentBeck• 17 years ago

Whether a CLI will beat a GUI depends on whether the operations are at the right level of abstraction. When watching Gary Bernhardt's refactoring session, he was using text editing operations to refactor. Text editing operations aren't an effective basis for refactorings. Building refactorings out of AST rewrites is much more reliable, then offering those refactorings as atomic operations. I don't see how to offer such refactorings from a CLI, but that could just be my narrowness of vision.

ilaksh4• 17 years ago

Mogrify is easier.

But you are comparing someone that knows bash scripting to someone that apparently can't write a script at all.

If there were a Windows program that added an item to the windows explorer context menu 'Mogrify' that would be easier than typing mogrify.

One thing I can do with file system explorer windows is leave a couple of them open and then switch from one to the other or copy and paste between them. You don't get all of that with cd and cp. There are some CLI tools that improve the standard situation with bash or whatever but you don't get all of the advantages of the GUI.

The advantage of GUI config dialogs is that they provide immediate feedback and prevent the user from inputing invalid configuration or having to look up config options. Those things waste time, even for experienced users.

redcap2• 17 years ago

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.

blahedo3• 17 years ago

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

redcap2• 17 years ago

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• 17 years ago

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• 17 years ago

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

The limitations of terminals as an interface

Related Stories