The limitations of terminals as an interface
threeriversinstitute.org
threeriversinstitute.org
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.
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.
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.
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.
"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."
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.
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.
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.
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.
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.
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
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.
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.
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.
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.)