Slashdot Mirror
The Command Line - Best Newbie Interface?
An anonymous reader writes "This essay describes the surprising results of a brief trial with a group of new computer users about the relative ease of the command line interface versus the GUIs now omnipresent in computer interfaces. It comes from practical experience I have of teaching computing to complete beginners or newbies as computer power-users often term them."
I'd wager that computer literacy amongst people who've tried Linux would be twice what it is today if when you typed help foobar bash would perform a man foobar if 'foobar' wasn't a builtin command. And it'd probably be double that if you incorporated some kind of search facility too. Type in help disk space and get a hit on the df command, for instance.
I find it amazing how many computer "experts" are dead in the water when the mouse doesn't work or the GUI doesn't come up as expected.
Too bad only the "old-timers" seem to appreciate the power of the keyboard.
To Terminate, or not to Terminate, that's the question - SCSIROB
Apprentice: "What is that, Master?"
Master: "It's a command line. The instrument of a Unix Programmer. Not as random or clumsy as a GUI. An elegant interface for a more civilized age. Before the dark times. Before...Microsoft!"
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
I believe it is because the command line is very simple and compact, single-threaded and simple to understand.
Modern GUIs have many things going on at once, which can confuse people who have no idea what is going on. Windows pop up, there are icons to deal with, they have to search through endless menus to find what they want.
The command line however has simple command to remember instead of complicated graphical procedures, and the status of the command line really never changes. If you mess something up, you are still back where you started, but in the GUI, a user could close a window to open another one which obviously confused people who don't understand what they mean.
...as part of its Win95 hype machine. Microsoft likes to point out that pointy-clicky is sooo much easier than the "arcane" and "cryptic" command prompt, and tried as hard as possible to hide it. Microsoft certainly didn't try to improve its command prompt much, and even in modern version of Windows it still retains a lot of its retardedness inherited from the early days of DOS.
The question is, why? Sure, newbies hate it, but it's really useful to have a powerful command prompt, so it wouldn't hurt to include it. Even Macs have them now. Windows would be much more tolerable if it had a Unix-style command shell out of the box. Yet Microsoft feels the command prompt should die and it seems (at least from my point of view) that it's included only grudgingly in the OS.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Now that's newbie friendly.
READY.
#
Before, I was concentrating on the syntax of control structures. Like having:Rather than: I could think about adding in a better help system as well. I've got a few months left of design work.
And I need to fix the lexer, too. In a recent presentation, I found a rather embarrassing bug. The concatenation operator in my shell is the same as perl's, the full stop, or period, ".". Cleverly, the shell can also treat numbers as strings and strings as numbers.
Unfortunately, it was all a bit too clever.
The expression 3.0 + 2.0 was parsed as (("3" . "0") + 2) . "0"). Giving 320. Oops!
But given a little more work, maybe I could get it to solve some of the problems mentioned in the article above. Could be an interesting thing to do.
The issue here is that while you have no desire to find out how your computer works, YOU STILL NEED TO. The common analogy is that people rarely would think it makes sense for someone to buy a car with no clue how it works, even if you only understand fail conditions.
Before you say you have no idea, if you live in the US, you did have to a test before you were allowed on the road, if you recall, and in that bank of questions there are fail conditions, such as driving on ice, perhaps even dealing with bug related Emergencies ( The long test to pass driver's ed around here included some very amusing questions about what to do when you discover a bee in your car )
However, people rely heavily on their computers and never try to learn basic fail conditions, like file location, full disk problems, uninstalling undesired programs, checking for updates. I'm not saying everyone needs to have a nitty gritty look at their kernel source, but you should know the difference between an ISP and AOL. You PAY for this stuff, you should have a vague idea of how it works and first steps on how to fix it when it breaks.
If you happen to be a supreme fool that knows so little about your car that you can't tell how fast it's goings, whether the engine is running hot, how to tell if your brakes need servicing ( waiting for the grind counts ), or the meaning of any of those "little flashy lights" on your "long window thing the steering wheel is hooked under", I pity you and your genetic tree.
The pity is that GUI usability peaked sometime in the late eighties and has declined since then, as the rise of "computer literacy" has created an expectation that users will master complex UI's, and the rise in computing power has removed any barriers to marketing-driven featuritis.
The most telling point was the discussion of "discoverability." "Discoverable: The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features."
In the 1980s, GUIs were intentionally designed to facilitate discoverability were far more "discoverable" than CLIs of the day. They were also intended to be forgiving. The user was supposed to feel empowered to try things, confident that there was always an "undo" to bring them back. On the Mac in the 1980s, "Undo" was far more prevalent and worked far more consistently than in today's software, in which many operations commit you to something whose effects you may not understand.
As for "dialog," UI designers understood that well. Why do you suppose that what are now called "screens" were once called "dialog boxes?"
What the article is really saying is not that CLIs are better than GUIs, but that a) modern UIs are not catering to the needs of the average user, and that b) modern UIs have gotten so badly designed, cluttered, and complex that they have become less usable to beginners than CLIsbecause GUIs have deteriorated, while CLIs have benefitted from benign neglect.
"How to Do Nothing," kids activities, back in print!
Build it, and they will come^Hplain.
At risk of just sounding argumentative, I actually disagree on almost every point you have just made. My background has led me through assembly and machine code in the days of 6809, 68000, Z80 and 6502, through Pascal, Forth, VB, C++ etc etc so I have had a fair amount of experience of various platforms, and the one thing I have learned above all others is how inferior a GUI usually is.
I agree that word processing is generally easier with a WYSIWYG word processor, but there are damn few of them. If it comes down to needing a specific layout, I know LaTex will work where MS Office often fails. And any graphical manipulation should be easier using graphical tools.
But your other points:
CLI = Dialog? The article mentions the notion of CLI as a dialog. But this is a misleading metaphor because so many CLI commands create invisible effects. A GUI has far more invisible effects, as you can't even tell what commands it runsYou tell the computer to do something and all that returns (in most cases) is a command prompt. A Unix command which returns a prompt implies it completed. Error codes are output from almost everything, and if you want to see them you can.At best its like teaching someone to to do a job while speaking through a door. You give a command to do something (e.g., move a file from directory to another) and then you have to give a command to see the results (ls).Or alternatively, you give the command and trust the agent to perform its duties and only return an issue when there is a problem
Discoverability: GUIs also provides visibility on to the set of available commands and functions. By browsing through the menus (which are usually nicely organized)Some are nicely organised, and to be fair, this is an area where there is great improvement, but in general I find it a nightmare to have to drop down through menu after submenu, sometimes in unintuitive places, to carry out a simple command., you can learn the functions of an application. In contrast, a CLI-only machines provides no obvious way to learn about commands that you did not know existed -- at best you can access an alphabet soup of cryptic vowelless cmmnd names and then access the man page on each command. Therefore, GUI applications tend to be self-documenting, CLI commands require that you first know of the existence of the command and then you must read the man pages (grepping the man pages sometimes works if you know the jargon for what you are looking for).There is an argument for simpler documentation than 'man' pages, but in reality, all that I think would be required is some indexing system.
Undo command: Most well-behaved GUI applications further support user learning via experimentation by having an undo command (and a revert command). CLIs tend to be irrevocable with no possibility for undoing inadvertent damage by a novice user (short of reloading the entire machine from a backup). Erm...novice user...should not have access to anything other than their own files, so should not cause irreversible damage. If they do have root, well, that's kind of the same as letting newbies have administrator access on Windows machines...a very bad idea. There should be no need. Its no wonder *nix people get upset at the thought of novices on computers. But this lack of an "undo" is the fault of *nix CLI (it could easily be remedied with automatic file version tracking and journalling). What do you mean by undo anyway? An undelete? Easy. A 'revert back to before I overwrote that file with this one' option? Does your GUI give you that?
GUI is the superset of a CLI: Some people complain that GUIs take too long and I agree with them. CLI does offer a faster interface for experienced users. Yet a good GUI offers keyboard shortcuts that let experienced users invoke commands from the keyboard. While it is easy to have a keyboard shortcut available and shown in a mouse-oriented graphical GUI menu, it is hard to have a graphical menu shortcut in a keyboard-or