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.
And isn't it nice that Mac OS X now gives you the best of both worlds :)
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
It seems to me that if you start someone on a command line versus starting them on a GUI they learn a little slower but acquire a deeper understanding of the computer.
point-and-click and drag-and-drop don't encourage any actual understanding of ways in which a computer interprets commands.
lysergically yours
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
Configure the DNS server address staticly:
/etc/resolv.conf
/etc/ directory. If any of these configs get corrupted you can edit them manually to fix them, or copy originals from packages, or copy them from another source and edi them to fit your needs.
In windows:
Goto start --> start --> control panel --> networking --> select the correct device --> options (or whatever I don't f-ing remember) --> select TCP/IP --> select options --> hit the DNS tab --> Select "I want to specify dns addresses bullet --> type in ip address in the boxes.
Networking specifications are spread throught 100's of dialogs and wizards. Some can set conflicting settings, some can override the settings of others. Some are grayed out to prevent these conflicts and you need to figure out why. All system wide configs are stored in the same place as program specific configs and user configs. If any program or installer corrupts this one binary file it will render the entire OS unusable.
In Linux (if the dns server is 192.168.1.1:
echo "nameserver 192.168.1.1" >>
Remember resolv.conf because DNS is to resolv the URL names into ip addresses. System wide configs are stored in plain text files in
from my web log, I think it's appropriate and strangely enough, quasi-religious...
We all strive to be big monolithic programs, with fancy buttons, big memory footprints, environments where people, if they want to do anything, must go through us. We strive to be pre-eminent on the desktop, world stage. We crave fame. Look at me we say. Look how important I have become. I am an Office Suite, hear me roar. Look how much I can do. If you want to do any work, you must come through me.
[snip]
We must teach our brethren the ways of the Unix shell, for if we don't we will forever be trapped handcuffed in that big shiny plastic bubble of modern life, where we see but we can't interact. We must go back, back to the beginning and learn the first lessons.
Toddlers are the stormtroopers of the Lord of Entropy.
That said, it would be rather helpful if command-line tools would actually communicate more in plain English. Most of the commands and responses were meant to save keystrokes and be brief, and were written by geeks for geeks (so to speak).
Why write "Segmentation fault: core dumped", rather than, say, "Sorry, this program has unexpectedly quit because of a programming error"? In other words, worry less about technical accuracy in error messages and concentrate more on making the computer and OS more understandable to non-technical people.
I'm not saying bash or the other shells should be re-written that way, but it would be nice if a more newbie-friendly CLI was around.
Cheers,
Ethelred
Everyone wants to be Ethelred. Even I want to be Ethelred.
I don't have either of those, but I often felt it would make the setup of my TV much easier:("S25" or "C35" being channels as listed on the cable provider's web site. Not sure if it looks similar in the US.)
or my VCR:But that will be easy when I replace my old VHS with a Linux PVR, I guess... (or will it?)
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!
A command line is easier for some tasks. It really depends what you want the newbie to do.
.mcx files from /mnt/cdrom to /scr/bea/tomes then the command line will be much easier.
If you ask her to copy all
If instead you ask the newbie to check her email then write a letter to the head office then a gui will be much better.
Matching the interface to the task is important, and most new users go for tasks that are easier with a gui.
Of course, the article is a bunch of nonsense where an EE PhD student attempts to prove based on theories that he made up that a command line is the most natural interface. His total disconnect from reality is obvious. Even though he's talking about something outside of his field, at least his academic tendencies should have caused him to look at related work and realize that he's spouting nonsense. Instead he (to put it academically) formed a nonsensical hypothesis based on complete ignorance of the field, logically extended it to encompass a lot more stuff. He created an experiment to prove his correctness; a key point included introducing computer newbies to a gui using only a keyboard for input.
This is academically dishonest; I might as well note that I've never crashed a car while drinking and extend that to say drinking doesn't change the likelihood of car crashes. Then I could put a car on a road and get a drunk person to turn it on and drive thirty feet straight forward. Seeing them complete that without crashing, I could declare that drunk driving is not dangerous. Based on his piece here, Dick Wareham would buy it.
This is certainly a very interesting idea, and has good points to it. I would hazard, however, that the CLI is most definitely not the way to go to get new users up and running with computers. The author is almost there in his article, but doesn't seem to make the leap...
Using the example that the author used, he says Tilly multitasks, but doesn't do more than one thing at once. When she wants to leave something for later, she puts it to one side. This is an almost exact description of minimizing windows. It isn't suspending programs, or moving them into the background, like UNIX. It's just putting what you're doing out of the way for the moment.
Tilly goes to the grocers and tells him what she wants. Why not point at what you want? I want my mail, click the big envelope. I want to type something, click the Word icon.
It's arguable that some of the easiest programs that run in a terminal are those that are like GUIs, just without the mouse. Pine is a perfect example. It has labelled buttons at the bottom, except you interact with them using your keyboard instead.
GUIs are still the best way of getting general users interacting with computers, it's just certain elements of GUI design that scares them witless. Working on a helpdesk for my University residential network, I reguarly hear what could almost be called fear in a voice when a dialog box or something pops up that I didn't expect, and warn the user was going to happen. GUI design is very imperitive. Boxes appear saying "DEAL WITH ME NOW" and giving themselves the utmost importance. This is what scares people. They think that because something took the time to alarm them in such a massive way, something amazingly bad must be happening. These windows often pop-up from applications that aren't being worked with. By preventing these, everyone would be a lot happier. The Mozilla new mail notification is an absolutely excellent way of telling the user something is happening, it pops up in the corner, says there's some mail, and disappears. It doesn't ding. It doesn't grab focus. It doesn't appear in the middle. It just gives you a quiet hint.
GUIs are also far too ready to boot up programs of their own accord. When users get notifications from something they didn't run explicitly, they get the fear. CLI doesn't do that, it only shows you output from things you've done.
The author says that users are scared to click buttons, in case of something going wrong. But they feel that a CLI can't do any harm. Users *do* want to point and click their way around buttons, and GUIs do complain of something wrong in essentially the same way as CLIs. Maybe it's because they have no visual feedback when they type sudo rm -rf / ? I think it's just a residual fear from the constant shouting that current GUIs do.
GUIs are currently too noisy, and the essential quietness are what these users are responding to. I would hazard that as soon as the users want to do something more difficult (that would need a pipe), they'll be desparate for a GUI interface instead.
By what does it mean "Best for Newbies?" The article doesn't even try to compare the user performance on a CLI to a GUI interface. The author made many subjective comments about what the users may think. A more objective experiment should be done with a control group that tries to accomplish the same thing using GUI. You then measure the task performance (like how long does it take to write an email or type a letter on either interface). Companies such as Microsoft and Apple spent a lot of money on research like this.
User interface is a field of active research and study, using actual performance comparisons on actual users, not on people reading slashdot. I think the general Linux community needs to recognize that it's not doing as much as it should. As Linux is moving to the desktop, this is becoming more and more important.
My computer experience started with ms-dos. I learned most of the commands while trying to scratch an itch (mostly trying to play games). I learned how to edit config.sys and autoexec.bat and by that the computer internal basics. It was simple and I learned many stuff.
Now newbies start mostly with windows. In order to learn how to use a computer you have to know how a computer works in general, and how a computer will respond to an action you take. Microsoft tried hard so this stuff is invisible to the user. In order to play a game you just have to put the cd in and "next" your way through the installation process. If users don't gain experience from simple things as that how can someone expect from newbies to learn how to use a computer?
I understand your frustration, but also disagree with it. Allow me to explain.
The concept you're bringing up is black boxing: a simple (or standardized) user-interface that hides a complex system.
The pros of black-boxing are obvious: black boxing makes it possible for many people to operate complex equipment (think cars, phones, computers). There is also a psychological factor at play here: as many people seem to suffer from self-learned helplessness when dealing with technology, black-boxing (e.g. think nice-and shiny i-POD, or automatic-transmission lady-car) helps them to overcome their physological aversion and acutally use the device.
Now, as already stated by another user, the main con of black-boxing is what happens when something goes wrong: black-boxing provides a very poor way of dealing with failure-conditions!. There is also another con, which is public perception: black-boxing makes people believe that the equipment they are operating is simple, while in reality it's very complex. But because they reason from their internal "simple make-believe model', they can make mistakes that they wouldn't have made, had they known a bit more about the equipment.
To provide an example: Here in Europe, most cars are manual transmission (typically 5 forward and 1 reverse). When driving 80 kph in a flat country like holland, it really doesn't matter that much whether you drive in 3rd gear of 5th gear. However, when some Dutch people drive through Switzerland during the summer holidays (with a big trailer behind the car), they persist in driving in 5th gear up-hill, their argument being: "Hey, don't worry man, the car maintains speed uphill, so what's the problem". Of course, had they known a bit more about how an engine works, they would have switched back to 4th (or even 3rd) gears, to allow the engine to run at a higher specific torque, and to allow the cooling fluids to be pumped around more quickly to cool the engine better. Our black-boxing people usually end up overheating their engine (and blocking traffic and creating big jams in the Alps, grumble! ;) You see: it pays to know at least a bit about what's under the black cover of your black box!
In the same way, your shiny XP thingy makes your computer seem a simple device. But of course, it is still a really complex device. We've all seen people do stupid things because they persisted in acting according to how they believed the computer works (their simple model), rather than basing their actions on how the computer actually works. Knowing a bit about the latter, however small, enables you to do better in times of failure, but also in general.
On a personal account: I learned C after I learning assembly. I experienced this as a big bonus, because after using asm, you know what pointers actually are and how they work. I've seen people program Java and doing stupid memory allocation things, because they had no clue about what happens when you do "new bla" or "delete bla".
To conclude: black boxing is ok, but you need to keep in mind that you are still operating a complex device!
Support a Europe-related section on Slashdot!
Yes. But the command itself is not localized ("cd = change directory"). There is no localized command "zk = zmien katalog".
Save the bandwidth. Don't use sigs!
The thing that this theory misses is the value of learning intuitively for most people. With CLI you have to be taught or teach yourself through research how to perform each task. With a GUI a few basic principles and you can learn as you go by reading on screen instructions in a context sensitive environment. Does CLI promote deeper learing...absolutely. Is it the best interface for learning quickly and achieving a minimum standard of literacy...nope.
Well, I'm an "old timer" who does _not_ appreciate the command line.
By "old timer" meaning, admittedly, not 60 years old and having started on punched cards and electronic tubes.
I did, however, learn programming in hex, not even assembly, on a ZX-80 with 1K RAM. In 1K you didn't even have space to run an assembler. I had a big old paper notebook with 1 page per command and a matrix of the registers involved. E.g., this is the page for "ADD", take the column for "A" and the row for "B", and there you have the hex code for "ADD A, B".
I continued through such mis-haps as editing source files on a CP/M machine with a hex-based disk editor, because the PHB forgot to also give us a text editor. Sad, but true.
You know what? I _don't_ miss those days.
The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't.
The time and effort to get past that learning curve is not fun, and not what Joe Average wants. Heck, it's not what _I_ want.
I do _not_ find it fun to spend hours digging through obsolete, incomplete man pages just to find out that I need to type some obscure command like "obscureProgram.sh -XFGXRmnq -i filename1 -o filename2 -c OBSCURE_COMMAND_CODE -p some_obscure_regexp -f unix-style-font-name" just to get something done. Bonus points if it expects me to already be in some directory, and some obscure configs to already be set right. More bonus points if it doesn't even do the whole job, but expects me to pipe it through other obscure programs. Double bonus if it outputs some cryptic error messages like "1962 Short School Bus", that don't even tell me what the **** went wrong there.
Gimme a break. My time is too valuable to spend it on that kind of crap.
Give me a GUI which has input fields for the stuff I need to enter. If it's a file name, give me a good file selector dialog, don't expect me to manually list directores 20 times to find it. If I'm supposed to enter options, give me checkboxes, radio buttons, or drop down combos. And, ffs, give me an up to date help for it. And clear, humanly understandable error codes.
And you know what? I'm surprised how much energy goes into defending the sacred right to produce crap code and piss-poor interfaces.
Here's an idea: if half the time that went into whining about how the 60's command line interfaces are better for the user, went instead into throwing together a simple user-friendly TK or ncurses or whatever GUI, we'd all be far better off than we are today.
And let me get back to the part where I've said "The command line is powerful and all, as long as you already know _exactly_ what you're doing. It is a pain in the donkey when you don't."
The problem there is that to get to know exactly what options to type there, you have to invest ludicrious ammounts of time into that. Which for most people isn't justified. If you'll configure printing on your home network maybe 4 times in your whole life, consider the following two situations:
1. spending 4 hours to learn how to do that with CUPS and only with command line tools. But then you can do that in 30 seconds flat each time.
2. spending 5 minutes each time doing the same in Windows, through the GUI
Believe it or not, solution 1 is _not_ an improvement. On the whole, the l33t Unix command line way took 4 hours from your life, while the point-and-drool Windows way took a total of 20 minutes. The winner is... the GUI.
Yearly millions of hours go into just learning to use some crap software. It isn't learning some l33t skillz, it isn't "getting a clue", it's just _wasted_. It's time when you're _not_ doing what you needed to do in the first place. Time where, like in the example above, instead of already having your file printed on that networked printer, you're still searching through obsolete man pages and trying stuff that fails for no obvious reason.
A polar bear is a cartesian bear after a coordinate transform.
In my experience there are two kinds of novice computer users (newbies, if you will), those you don't "get it" and those that do. Those that "do get it" will quickly understand that the "little blue 'e'" is not "THE INTERNET" and that they are free to change thier start page for that application (or choose another one altogether). The author choose a bunch of (his words) "the more advanced members" and gave them a little instruction on the command line, to kill a little time, while he tried to catch up the dense. At best, it is just a good way to interest the "soon to become power users", while the rest of the class catches up.
I use the command line frequently, and am very comfortable telneting (and SSH) to Solaris and Linux servers, but I don't think that most newbies will benifit from the extensive command line instruction, they would need to be truely "productive" on a system.
The grass is only greener, if you don't take care of your own lawn.
You're harping on a 'CLI Photoshop' is pretty retarded. Even before OS based GUI's were common, there were these things called 'drawing programs' that provided their own. Nobody I know of has EVER claimed a program like that, meaning one that explicitly deals with friggin graphics, would be better off as a command-line app.
Also, as far as config files go, ninety-five percent of the time there's no or little help available in settings dialogs. Not to mention multiple tabs, trees, checkboxes that can be overlooked, etc. With a config file you generally have one big list of settings that you can SEARCH, instead of clicking on shit for five minutes wondering where the hell that setting was.
File navigation is hit and miss on both sides of the argument IMO. I tend to work with the same paths enough to remember them, and I can guarantee I'm faster using the command line when I'm dealing with known paths. OTOH, when I'm not sure where something is or am kind of browsing, a GUI is better. Or 'pseudo-gui' as I think you called it - Midnight Commander. It utterly annihilates any and every gui file manager I've ever used. It has the best of both worlds, an extremely effective 'pseudo-gui' and a command line.
Finally, GUI as a _superset_ of the command line? Now I know you're high. Maybe on Windows. Under Linux it's a distant and pale subset. End of story.
Overall, it really just sounds like you have an axe to grind.
"The bottom line is I want to "use" my computer, not "learn" my computer."
And there it is.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
Look, if the car starts bouncing, I know I have a flat tire. If the engine is having problems, a red light on my dashboard tells me to take the car in. When the car struggled to shift gears, I knew it was a transmission problem. The CAR informs me of what is needed and I take it to the specialist. The basic maintenance schedule is given to you when you buy your car, there are no surprises.
Regarding a license... you need a license because with an automobile because the misuse of an automobile can endanger others.
Look, I'm a computer engineer by training, know my way around Unix, know my way around NT (MCSE, CCA from old career), and know my way around a CLI. Guess what, when I want to put together a business model, I want a graphical spreadsheet that is out of my way. Do I know ALL the Excel functions? No, but I know the ones I use regularly, and the help system gets me through the rest.
I have no desire to memorize arcane commands, I want to build the business model. Will I learn arcane commands to speed things up? Sure, but on MY schedule, NOT yours. I buy the machine to let me get my work done, and I pay the premium for a laptop to do so on the road, and I pay the (admitted small these days) Apple premium to have wireless support that is amazing and to be able to have my Unix applications on the road. These are all my choices.
Guess what, I don't pay Open Source programmers, so they don't have to listen to me. However, don't complain that I don't have an open source desktop when you put out bizarre GUIs that interfere with my workflow.
My Mac stays out of my way and lets me do work, MUCH faster than Windows or Linux would let me. In the end, that keeps Linux a step away from "global domination" or whatever the goal of the week is.
My computer should work for me, not the other way around. Sure, I had to demonstrate an understanding of traffic laws to get on the road. But guess what, EVERY car I drive is nearly identical, and the controls don't change. That consistent UI makes cars a success.
Windows has problems, no question. But it is "good enough" for most, and it is pretty cheap.
For a single-purpose machine, Linux is fine, I can train my people on 1-2 applications... If GNUStep was further along, or Qt didn't blow as a RAD tool, then our dedicated personnel would be on Linux machines and not eMacs. However, if you think that Linux is good enough for a business power user, you're sadly mistaken.
The integration of the Office Suite has been AMAZING for a few years, and the combination of Word, Excel, and Powerpoint is TERRIFIC for business users. Until GNU can mimick that power (NOT mimick the widgets, but the power and integration) then it is NOT a viable desktop system for the modern business power user.
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
Especially your last paragraph: 'Granted CLI is nice and powerful. When I used a UNIX machine more intensively, I liked CLI. But when I stopped using UNIX intensively (dropped below 5 hrs per week of Unix use), I found that I quickly forgot all the commands and spent most of my time grepping man pages. CLI is mega keen and faster if you're doing batch file transfer, but for single file transfer, I can drag and drop faster than I can try and remember and then type the correct command, path, and file name.
The bottom line is I want to "use" my computer, not "learn" my computer. Although *nix requires you learn before using, some OSes don't have such a steep learning curve. What I like is Bill Joy's statement in a recent wired article about Linux vs. Mac -- he chooses the Mac because it "just works."'
is what Stephenson concludes too, and basicly what the whole essay is about.
"Until you do what you believe in, how do you know whether you believe in it or not?" -- Leo Tolstoy
Nice troll. Looks like the mods went for it too.
All systems have a learning curve, if they didn't I wouldn't have the same Windows user calling me everyday because she forgot how to get her email.
CLI = Dialog? it depends on the command, and no one said some commands couldn't be rewritten to be more userfriendly. Besides it wouldn't take long for people to know which commands aren't going to return anything if they fail and come to expect that. In fact some of us with a bit more experience like these commands as they can be chained together to do even more useful and exciting things.
Undo command: Actual commands to the OS can't be undone in any environment. Once you click 'OK' in some dialog (commanding the OS to do something) That's it, there is no resetting from that point. The CLI is closer to the OS in most cases. So the fact that it has no undo isn't really all that surprising. Many (usable) command interfaces have a command history however so undoing something usually isn't all that hard. Many commands such as cp and rm have confirmation dialogs turned on by default so you are less likely to make a mistake in the first place.
GUI is the superset of a CLI: Can you operate the machine using Ctrl+This and Ctrl+That without the GUI?
Direct Manipulation: What a pointless argument. The CLI has nothing to do with the applications you are using. I think most people talk about using a CLI to get around their systems. No one is advocating making graphical image applications, web browsers or games go away! As for your challenge such a thing does exist, its called ImageMagick (the convert command) you can manipulate pictures from the CLI and you can do a lot with it. Of course its a command designed to filter things and program with (ImageMagick itself is an API) just like lots of other commands on the system.
Control Panels vs. Config Files: I'll keep my config files thanks. Very few widely used config files aren't littered with all kinds of comments telling you exactly what to enter. And of course there is input validation. Many programs have a 'check the config file mode', and even if they don't its probably not going to run with an invalid config file. Editors such as VIM help here too. When the syntax is supposed to be highlighted a certain way and suddenly its not, there's probably a problem.
Pathnames: Tab-completion?
Your argument about single files goes away with tab-completion too. Really I wish there were better ways to select groups of files (by type maybe) in a CLI for batch transfers.
Personally I want to "use" my computer without pretty pictures getting in the way. Bill Joy probably made those statements because he isn't familiar with Linux. I've set down in front of Mac OSX and whenever I have I end up looking for the Terminal.app so I can use the comptuer.
The Anti-Blog
Ever tried telling people on phone how to do a task in Windows?
"Click Edit, Options, and... err, wait, yeah, Page settings, Margins..." (5 minutes later, or 10 minutes if you don't have the same program in front of you) "Wha? I told you to click on OK, not Cancel!" (10 minutes fly by...) "So it doesn't work? What do you mean there's a setting like that? Why didn't you say so? I'm deaf and stupid. Sorry."
As opposed to:
"Just type '/sbin/ifconfig ppp0'. ...Wha? that's 'slash-s-b-i-n-slash...'" and a moment later "So it isn't even connected. Right. Try typing 'pon'."
The GUIs may be good to work with, but CLI is easier to explain. Especially if you're used to doing GUI things in one way and others do it the other way.
GUI is like a religion - you "learn" it, and only you can explain what it means to you. CLI is like science - you learn it, you can explain it, and it means the same thing to everyone - except people who argue about "useless uses of cat(1)" and proper order of parameters, and whether to use sed(1) or perl(1), of course.
And now I need the freaking coffee already.
Wow, recycled FUD from 1984. We've already had this battle. GUIs won, get over it. New user like to see what they are doing. Clicking is more intuitive than typing. CLI has it's place and use, but don't try and tell me Grandma is going to feel better using CLI over GUI 2 weeks or 2 years down the road. It just ain't true.
You make some good points about the Unix CLI, but the more I think about it a good portion of your points don't have to apply to an idealized CLI.
... embedded help Yah, those "#blah does this" lines really don't exist huh. But I digress, if we're talking about a conversational CLI we'd want a config tool to so you can tell it, "I want X, Y, and Z options set. " That would provide your input checking. Manually hacking the file would be for advanced users (just like today).
:)
I think the strongest point of this article is that a "conversational interface" which works synchonously is easier to get a handle on than something that is throwing asynchonous events at you all the time.
CLI = Dialog
This might be true, but I don't like your example much. cd simply does its job and tells you if there is an error. should it report the directory it changed to? I don't think it would be the end of the world if it did, but it would be a little more verbose that needed.
Discoverability
I mostly agree here. But even with windows or mac dialog box menus, you've got to navigate these often poorly sorted categories looking for... a cryptic command name. I think well written error messages and 3 stage documentation would help a long way here.* Also, an advanced CLI could present common commands or frequently used commands in a hint zone or upon request.
Undo
There is no technical reason why you can't have undo in a CLI. You even hint at this yourself. It would be a feature of the program or shell you are working with.
GUI is the superset of a CLI
I don't see the point of this. Sure, the G stands for Graphical, but by no means does that mean an advanced CLI can't incorporate graphics. Think driving ImageMagick from the CLI. Or curses, but going back to the point of the article, was that "conversation mode" was what his users liked. You lose that when you start glueing on menus.
Direct Manipulation
This is where I disagree the most. I've got pretty good motor control, but I still click on the wrong stuff all the time. Imagine a CLI-photoshop which fills the upper half of your CLI with the working image and and the bottom half with the input & command history. You can execute any arbitrary command on any region of the image and still see the changes in front of you. Here all the mouse becomes and extra selection tool. Stroking, filling, rotating, can now be driven by commands... which can work synchonously. I imagine the same can go for Word Processing, document layout, etc.
Control Panels vs. Config Files
no form of
Pathnames
Urgh. The other replys handled this pretty well. (BTW, typing pathnames on OSX is damn annoying. Why did they feel the need to start them off with caps? grr.)
And with a CLI, if I make one tiny spelling error then the entire command fails and I have to retype it Press the up arrow.
The bottom line is: this article was about introducing people to the computer. The most important thing that I saw was that the CLI lets a new computer user focus on ONE TASK at a time. To me this makes a lot of sense. This isn't to say either our GUIs or CLIs are rubbish, but that we have preconcived notions that GUIs make things Easy(tm) and that might not be always true, sometimes, but not always.
I spent way to much time writing this, and if I want to continue I ought to just to a full fleged essay
--------
* I don't know if this is a real term but i mean:
Stage 1: appname -h, provides a quick explanation of the app plus the most useful options and maybe an example
Stage 2: man appname: more through documentation, but still short and to the point. As others mentioned EXAMPLES are very useful. All the options can be enumerated here
Stage 3: info or some other hypertext documentation: the full manual that can be as verbose as it needs to be, but crosslinked for deeper investigation into the app
They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
RPM is supposed to be easy to use... but the dang man page is so long... Here's just the SYNOPSIS section at the beginning:
...
...
...
...
...
...
...
...
NAME
rpm - RPM Package Manager
SYNOPSIS
QUERYING AND VERIFYING PACKAGES:
rpm {-q|--query} [select-options] [query-options]
rpm {-V|--verify} [select-options] [verify-options]
rpm --import PUBKEY
rpm {-K|--checksig} [--nosignature] [--nodigest]
PACKAGE_FILE
INSTALLING, UPGRADING, AND REMOVING PACKAGES:
rpm {-i|--install} [install-options] PACKAGE_FILE
rpm {-U|--upgrade} [install-options] PACKAGE_FILE
rpm {-F|--freshen} [install-options] PACKAGE_FILE
rpm {-e|--erase} [--allmatches] [--nodeps] [--noscripts]
[--notriggers] [--repackage] [--test] PACKAGE_NAME
MISCELLANEOUS:
rpm {--initdb|--rebuilddb}
rpm {--addsign|--resign} PACKAGE_FILE
rpm {--querytags|--showrc}
rpm {--setperms|--setugids} PACKAGE_NAME
select-options
[PACKAGE_NAME] [-a,--all] [-f,--file FILE]
[-g,--group GROUP] {-p,--package PACKAGE_FILE]
[--fileid MD5] [--hdrid SHA1] [--pkgid MD5] [--tid TID]
[--querybynumber HDRNUM] [--triggeredby PACKAGE_NAME]
[--whatprovides CAPABILITY] [--whatrequires CAPABILITY]
query-options
[--changelog] [-c,--configfiles] [-d,--docfiles] [--dump]
[--filesbypkg] [-i,--info] [--last] [-l,--list]
[--provides] [--qf,--queryformat QUERYFMT]
[-R,--requires] [--scripts] [-s,--state]
[--triggers,--triggerscripts]
verify-options
[--nodeps] [--nofiles] [--noscripts]
[--nodigest] [--nosignature]
[--nolinkto] [--nomd5] [--nosize] [--nouser]
[--nogroup] [--nomtime] [--nomode] [--nordev]
install-options
[--aid] [--allfiles] [--badreloc] [--excludepath OLDPATH]
[--excludedocs] [--force] [-h,--hash]
[--ignoresize] [--ignorearch] [--ignoreos]
[--includedocs] [--justdb] [--nodeps]
[--nodigest] [--nosignature] [--nosuggest]
[--noorder] [--noscripts] [--notriggers]
[--oldpackage] [--percent] [--prefix NEWPATH]
[--relocate OLDPATH=NEWPATH]
[--repackage] [--replacefiles] [--replacepkgs]
[--test]
Each of the above options is explained in detail, but there are no FAQ-style examples. It's no wonder the distributions are putting layers on top of rpm (urpmi, yum, etc). I like yum, and largely because the man page is short and to the point! It only takes a few seconds to figure out what I need to do.
bp
CLIs are easy to use and very efficient for many tasks. However, that does not make them easy to learn. The discoverability of basic tasks with a GUI makes that approach very powerful for learning.
I actually think it's a good thing that unix-ish commands have wierd names.
For a beginner learning unix, there's a conceptual hurdle they have to jump: that commands are not "commands" at all, but specific named programs which can be used as tools.
Lack this understanding, and you're confused and trying to second-guess a nonexistent "designer". Gain it, and you can start to ask the right questions. Not "how do I get help" but "what program displays the help documentation", for example. Or, if one program isn't adequate for a task, might there be another which could do it better?
In that regard it actually helps that unix programs have idiosyncratic names. "grep" is grep, it's not some generic "search", and it's probably not the only tool on the system useful for "searching".
pbbt, that doesn't even come close to comparing. It took him two lines, and you a paragraph to describe what he did. Lets see, he types in a few commands (on a single line yet) and its done.
... this doesn't require the keyboard does it?
Now, I've never used ImageReady.. so if I'm off a bit forgive me.
You..
* create a history script
* need to use a sample image... seems like a kludge.
* Export the script to something called a droplet.. instead of use it directly like imagemagick.
* Set default options for file naming.
* Now, you switch from ImageReady to explorer, drag the files into the droplet.
and all of this seems easier then just giving imagemagick a handful of commands? I bet the original poster could of done what he did fifty times in the space of time that you did what he did once.
I'm at all convinced.
--SD
"Computers will never truly be free until the last windows user is strangled with the entrails of the last mac user."
Plus, having a command line tool makes it a whole lot easier to tell someone how to do something. For example if someone asks "how do I get the HR department shared files directory to show up as my S: drive every time I log on?" It's a lot easier to tell them "Hit start, run, and type '
'" than it is to walk them through the steps needed to do the same thing via the gui.Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Command line might be easier to teach, but hand two complete novices(as in never used a PC) a GUI system, a command line system, and a typicaly sparse new users guide.
See who makes effective use of their system faster. Idiot simple interfaces aren't for those who go out to be trained, they are for the secretaries and such who take a job and need to work right away, without training in how to use the computer.
Good points. I agree it's useless to debate which is better, GUI or CLI. Each has distinct advantages. What I'd like to see is more exploration of how to take advantage of the best of both with GUI/CLI hybrids.
Matlab and Maple offer pretty interesting examples of hybrid GUI/CLI interfaces. For instance, you type some graphing command, and then the graphical output appears right there inline in the console. Overall their UI is more slanted to the CLI end than GUI.
AutoCAD was another one, but with a more GUI slant than CLI. Actually several modern modeling packages, (e.g. Maya) have a sort of command line interface that lets you type in a scripting command, but it's basically just a way to run one-line scripts than a command line interface to the entire application. I think in AutoCAD it was more like a full interface. I could be wrong, though, not having used either extensively.
Anyway, there's no reason why the CLI type of interface can't be intermixed more cohesively with GUI. Think of the CLI as an interface for textual interaction of any sort. It doesn't just have to be a set of 'command ' syntax. It could incorporate much more than we think of as 'CLI' today in terms of natural language processing and especially pattern matching and searching.
Think about the best interface we've got for managing the complexity of the web: Gooogle. There's a similar problem with managing complexity in many application programs. What if in photoshop you could type "gaussian filter" and just click on the "I'm feeling lucky" button, and it would perform the gaussian filter. For many operations you do infrequently, that could be a big improvement over the frustrations of searching through all the menus to try to find the right thing. If the command needs parameters, the parameter sliders could even appear right there in-line in the app's console. If you need to tweak those same parameters again a few minutes later, the sliders would still be there in the console history.
Applications that have good searchable help give you some of the ability. But it's all set up to be really slow. With help searches, you have to open the help, search for the command you want, say "oh of course! it's under the format menu", close the help, then go open the "format" menu and click on the right menu choice. Instead, I'm talking about a CLI where the command/search area is always shown and is used to launch the commands directly (or present you a list of options if there's ambiguity).
Actually the Microsoft Office team seems to be trying to go in that direction. But their implementation in the form of Clippy is horrible. And it's still tied into 'help', which to me is basically like "exception handling" for application flow, rather than being a normal part of usage. It's too heavy handed. I _know_ what "kerning" is -- I don't need a whole window to pop up with a description of typsetting terms just to kern some text -- I just want it to execute the darn command.
Only on Slashdot is an entire article posted about the command line being the "best newbie interface."
If you despise Slashdot so much, why do you continually read and post comments?
This article was only posted to make Linux users feel better about the fact that 80% of setting up and using Linux still requires using arcane commands.
You are either lying, or have not installed a distribution aimed at newbies for about five years. Which is it?
And it gives assholes more of a reason to answer every single newbie question with "read the man pages."
Reading the documentation that comes with the program has nothing to do with command-line vs GUI. Stop trying to derail the argument.
this silly let's-justify-20-year-old-UNIX-philosophy is holding it back.
Once more, UNIX philosophy has never stated that command-lines are the most appropriate interface for newbies, so stop trying to derail the argument.
Anybody thinking of modding this guy up should read his posting history. He karma-whores until he has a +1 bonus, and then he uses that karma to troll people who read Slashdot at Score: 2 threshold.
PS: I don't think a command-line is a suitable interface for a newbie.
Another good thing about config files instead of dialogs is that the file can be copied from someone else's successful setup. Kinda hard to do with a GUI.