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."
Does anyone remember 4Dos? Between that and Qmodem, I learned a whole lot about computers.
Life is the leading cause of death in America.
But you think a command line would make using a digicam easier? A microwave? A thermostat?
The computer as a non-specific device is a fundamentally flawed (though useful) contraption. The command line, GUI, and other UI creations are all hacks to help users get around the problem of genericity of the machine.
As computers get more powerful and more 'intelligent', computer user interfaces like these will wither away and something more straightforward like controls for a camera, microwave, or thermostat become the primary UI of the computer. This means that innovations in computer operating system design must be made so that the OS can guess what the user wants to do and present an appropriate, simple interface.
I really look forward to the day when the concept of the PC disappears.
I have been pwned because my
In my experience, the command line is more consistent, especially if you are telling someone to do something. Once you get into it, it just a matter of saying "press A, then press ., then...."
With a GUI, there is a lot of hunting and squinting and guessing: basically, the stuff is never in the same place and never looks the same from one machine to the next.
Don't blame Durga. I voted for Centauri.
When she worked she worked with DOS based programs. I guess now these are so much easier to understand because you actually "talk" to the computer albeit through a keyboard and with a very limited command set. Maybe the mouse driven GUI is a bad inbetween step from the keyboard-only days to a time when computers understand conversation.
One of the things I really miss when I sit behind a windows computer is a bash shell, tab completion, gcc, vi... and you usually arent allowed to install cygwin on people's systems :)
Of those to whom much is given, much is required.
Had a Fujitsu laptop, like a P133, in 1998(?) and I loaded Redhat 6.0 and could NOT get the Xserver to work. I spent about 6 mos (now and again) at the command line putzing around on tryng to get the Xserver working. In that time I learned more about Linux AND Windows than I ever knew even existed. Suddenly alot of Windows oddities made sense... in the sense that I got what they were _trying_ to do. And it left me with a hollow feeling whenever I used Command... Why doesn't Windows have...
This
From the word go I had them "cat"-ing, "sort"-ing, "grep"-ing and "cut"-ing files, showed them how to combine commands on the command line and how to turn them into shell-scripts.
The guys I taught were, like me, support engineers on Linux-based telephony products and were keen on learning how to strip relevant info from log & text files.
Within a couple of weeks they were churning out pretty good shell-scripts that were extracting info from files all across the system, "gzip"-ing them up and mailing them off automatically in cron jobs. Many of the commands they used in the scripts I'd never even mentioned in the training but had showed them about man pages and "find"-ing files on the system.
The moral behind the story is that if you give people enough of the basics, they'll soon go find problems they need to solve and work out their own ways of doing it.
Gentoo Linux - another day, another USE flag.
I did some teaching of command line for non-English-speaking students and the biggest obstacle was the language barrier. They couldn't remember the command and they didn't understand the output of the command. Even if they knew some English, there were always some technical terms they couldn't understand and they felt intimidated. This way they were much more efficient in a localized GUI.
Save the bandwidth. Don't use sigs!
Sounds like the people here have no idea what makes GUI's so powerfull.
...
1. State. You can (should) always at a glance be able to see what state the system has. With a CLI interface, there's simply no state. It's a command execute cycle forever.
2. Exploration. Simply exploring a program, by seeing what it menu's contains, is a very easy, and intuitive way of exploring. CLI's have none of this.
3. Rote memorisation. There is no motor memory when using the CLI. You must remember the syntax of commands 100% accurately. GUI's support "knowlegde in the world", as Norman puts it. Consider a door handle on a door, it has an obvious way of being used. Staring at "~$", is so very different.
4. Easy reversal.
In fact, the benefits of GUI's over CLI's are so many fold, I won't bother with digging out the literature.
The command line has only one advantagde, it's speed, and the possibility of executing extremely complex commands. Both not things newbies are well known for.
"To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels."
Funny, I thought that was the same with CLI's. With a GUI, the GUI can at least support exploration of the interface. Click that arrow down, see what happens. A CLI can do none of these things, unless you consider adding random letters after a command, to be "exploration"
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.
When I was in highschool I switched my PC from windows 95 to Linux after my sister had damaged my windows install. After the initial horror at what I had done wore off, my younger brother and sister got used to the new system. Four months later I discovered they were both making extensive use of the command line. I hadn't tought them a thing so they learned on their own. By the time I moved out I had my mother using pine over ssh to read her email.
Most of the trouble of Linux is the inertia related to not wanting to learn new things and not being technically difficult.
look here http://slashdot.org/articles/02/12/29/1349230.shtm l?tid=109
.NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."
An anonymous reader writes "I found this while searching for Perl Jobs in India:
"The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the
Having done everything from assembly language programing for embedded systems to UNIX CLI (Command Line Interface) to Macintosh, I find that CLI is distinctly inferior to GUI (Graphical User Interface) for all but a few tasks. I challenge CLI users to do any form of word processing from a shell prompt. Even the most hard-core of them will resort to vi or emacs which use a primitive pseudo-GUI (and yes you can create and I have used a pure CLI text editor, but it is extremely painful). I don't want to even think about trying to replicate Photoshop with a CLI.
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. You tell the computer to do something and all that returns (in most cases) is a command prompt. 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).
Discoverability: GUIs also provides visibility on to the set of available commands and functions. By browsing through the menus (which are usually nicely organized), 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).
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). 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).
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-oriented CLI. With a GUI that shows the shortcuts in the menus, the user can learn shortcuts as they use the machine. Thus, I would argue, a GUI is the superset of a CLI.
Direct Manipulation: And CLI's inferiority is not just a matter of the learning curve (although that is a big disadvantage of CLI). For some tasks, a direct-manipulation WYSIWYG GUI is vastly superior. I challenge *nix people to build a CLI-only version of Photoshop. This is more that a matter of ease-of-use it is a matter of creating a coordinated interface between a person and a machine. While CLI forces the user to preform a completely defined action (e.g., type in a command that turns pixel 100,103 in file x to RGB value 128,128,200), a GUI lets the user try something (select a paint brush tool from the toolbox, test it somewhere, undo, use the tool somewhere else, etc.)
Control Panels vs. Config Files: The article claims that modern GUI-driven OS have too many control panels ("To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels." Yet how is this same functionality attained in a CLI machine? Config files are the absolute worst because they offer no form of input checking or potential for embedded help. Most config f
Two wrongs don't make a right, but three lefts do.
> Command output is problematic since users often expect feedback. For
:\\\); else echo :\\\(; fi\`\\\$ "
:) on the prompt if the previous command succeeded, :( if it failed.
> example when we grep on a file and don't find the pattern, grep does not
> generate any output.
Try this:
PS1="\w:\`if [ \$? = 0 ]; then echo
This puts a little
and a
It doesn't help if the command was part of a pipeline or some such,
but it's debatable what sort of feedback you want if something
in the middle of one of them is unhappy.
I loaded Linux on a Windows 3.1 machine for my kids to get mail (had a domain name) so they could all have their own mail accounts and login; didn't want the arguments from a 16 year old girl and 12 year old boy fighting over a common email account. The 16 year old liked Pine for email, she would rather exit X to read email under Pine, before she learned about xterm.
Infuriate left and right
It turns out that companies like Sun and IBM have researched this before. The results they came up with is that the new users found their way around and accomplished tasks faster with a GUI interface, but were more likely forget by the next time how to do it. With command line, it took a while to learn it, but then the retention rate was higher. The research, I believe, the systems used were running Solaris/AIX respectively with their X Windows vs. the command like on the same systems.
Sorry to dissagree.. Dos help was nice, but the dos TUI sucked for one reason: NO TAB COMPLETION! I am a Linux/Unix admin, and I can't function in environments without tab completetion without a fair amount of consternation, misstyped commands, web lookups and other crap.
:) Then again, someone probably already has.
Every user I've ever seen strugging with tab decompletion shells almost instantly became functional when tab competion was introduced.
Most people find that typing two letters and then tab can get them to anything they want to do faster than finding the mouse, finding the app, doubleclicking, etc.
No, I will not make the mistake of stating "I love man".. But I can't work well without it most of the time.
Maybe someone should write one for Linux, just for the heck of it. They can call it "woman".
-=fshalor
I think GUIs and the CLI both have there place. However, undoubtably, the CLI is simpler, faster, and more powerful in certain circumstances.
Just recently, a colleague (running Windows XP) and I (running Linux) took our laptops to a computer lab providing IP addresses via DHCP. My colleague, after spending literally 20 minutes fighting with his GUI receiving ambiguous error messages and having the OS seemingly do the exact opposite of what his intentions were, finally gave up. Some setting, hidden in XP, was refusing to let him use DHCP and insisted on trying to connect to his usual ISP.
On the contrary, after 3 seconds editing a config file, I confidently typed "/etc/rc.d/network start" and, as expected, had instant network access.
I think this is a simple example of the many (not all) areas in which the CLI is simply superior.
one single page shows up, gives all relavent info
And unfortunately, all the irrelevant info as well. Reading through a lot of manpage is truly soul-destroying, and it's hardly a surprise that they're not too popular with newbies. Try man cvs or man gcc if you don't believe me.
== Jez ==
Do you miss Firefox? Try Pale Moon.
Although I'm only 21, I grew up in a DOS, and, later, a Linux environment. I still prefer vi and vim to VS.net. I was using a Windows program a couple days ago, and it wanted the folder to rip music to, I went to type in the folder (q:\.......\music), and it wouldn't let me. When I realized that I would be forced to use a GUI folder selector for each of the three paths rather than copying and pasting, my heart sank: I realized just how horrible the world has gotten when even programmers expect me to use GUI for everything. My point is, a lot of us grew up on command line, and we turned out great. A lot of people grew up on windows xp/msn messenger, and I can't help but look down on them. When I say, "Your 40gb drive is full of spyware and installed programs/partially uninstalled programs/whatnot, it's time to format" they say, "huh?" because they aren't famalier with core computer concepts. When I was forced to learn what IRQ and DMA meant, and I had to use mscdex when I was 10, I ended up better for it. I understand how the machine works, and I am much happier for it.
http://www.skullsecurity.org/blog/
"I think the person doing the alias to man -k is the system administrator... | ... Ah, the "local customization" myth. This may have worked back in the day"
I think the person doing the alias to man -k is the distro maintainer
"look, I typed la and it did an ls for me! And it works when I type dir too!" [mandrake newbie]
I do _not_ find it fun to spend hours clicking through obsolete, incomplete help dialogue boxes just to find out that I need to click a checkbox in some obscure dialogue box and have to guess if its the customize menu option or the options option and then click through all 15 tabs searching for the checkbox. Bonus points if the option is disabled or expects some obscure registry key to set. More bonus points if clippy or some other annoying dialogue box pops up asking if i'm really sure i want to do that. Double bonus if my program crashes and without an error message, or i get a bsod which outputs some cryptic error messages like "1962 Short School Bus", that don't even tell me what the **** went wrong there. Not to mention customizing a shell script is a lot easier than customizing a gui. Not to mention you can't script guis.
Gimme a break. My time is too valuable to spend it on that kind of crap.
Give me a CLI which has prompts me for the stuff I need to enter. If it's a file name, don't give me a file selector dialog where i have to manually click through 20 directores to find it. If I'm supposed to enter options, don't 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 80's graphical user interfaces are better for the user, went instead into throwing together a simple user-friendly shell script or learning how to use existing cli interface we'd all be far better off than we are today.
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 help dialogues and trying stuff that fails for no obvious reason.
look. point taken that for some people in some situations, point and drool might be better. i'm a cli advocate, but not for every situation. but a lot of the things you mention are just poor program design. i like having man pages and open source because if something doesn't work i've got real in depth documentation and if i have to, i can figure out what the heck is wrong. with a gui in a closed source world, you are just sol. even with a gui in an open source world, the code is more complex and less accessible. granted this is not for newbs, but it does help non newbs. and it gives newbs an option to become non newbs -- they can learn if they want. if they don't want, then hey nothing lost.