The limitations of terminals as an interface(threeriversinstitute.org)
threeriversinstitute.org
The limitations of terminals as an interface
http://www.threeriversinstitute.org/blog/?p=409
22 comments
"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.
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.
" 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?
-------------
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.
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?
-------------
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.
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.
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.
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."
"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."
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.
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.
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.
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.
> However, the cognitive load of this distraction is lower than that of having to remember keyboard commands.
I do not find this to be the case. But then, there are various keyboard commands, both in Vim and on the command line, that I do not really have to call to mind before using. I just type them when needed.
It’s really weird how that works, actually, how with many things (I’ve noticed this with GUI interfaces, too) the mind will learn it to the point where you don’t need the conscious part of you to be aware of it anymore.
So I think this is really about what we’re most used to, what our mind has adapted to. I feel very clumsy if I’m editing in something other than Vim, because that’s what I’ve adapted to.
For a time, I had gotten used to typing correct apostrophes and quotes ( ‘ ” “ ), such that I could no longer automatically type a ' or ". I had to think about those primes if those were what I wanted, although the quotes are certainly harder to type.
So what am I saying here? I guess I’m saying that we can’t rely on our own experience too heavily — whichever interface we find we have to think more to use may be far more natural for another, and all of that may be entirely irrelevant from an objective standpoint.
I do not find this to be the case. But then, there are various keyboard commands, both in Vim and on the command line, that I do not really have to call to mind before using. I just type them when needed.
It’s really weird how that works, actually, how with many things (I’ve noticed this with GUI interfaces, too) the mind will learn it to the point where you don’t need the conscious part of you to be aware of it anymore.
So I think this is really about what we’re most used to, what our mind has adapted to. I feel very clumsy if I’m editing in something other than Vim, because that’s what I’ve adapted to.
For a time, I had gotten used to typing correct apostrophes and quotes ( ‘ ” “ ), such that I could no longer automatically type a ' or ". I had to think about those primes if those were what I wanted, although the quotes are certainly harder to type.
So what am I saying here? I guess I’m saying that we can’t rely on our own experience too heavily — whichever interface we find we have to think more to use may be far more natural for another, and all of that may be entirely irrelevant from an objective standpoint.
The point is that the windows/toolbars/icons/tooltips/buttons/mouse/etc. GUI is an interface you can learn and apply everywhere with minimal inspection required to get up and started using an unfamiliar GUI, whereas textual interfaces take much more investment in time to learn and effort to inspect.
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.
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.
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.
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.
There is Vimperator, a plugin that applies vim keybindings.
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
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
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.
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.
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.
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.
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.
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.
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.
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....
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.
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.
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.)
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.)
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.