Linked by Richard Wareham on Mon 8th Mar 2004 20:49 UTC
Graphics, User Interfaces 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.
Order by: Score:
Comand line interface is a good way of interacting
by debman on Mon 8th Mar 2004 21:06 UTC

but the interface has to be simple to get most work done.

a nice mix might be the task bar, and rather than the desktop, you have a CLI to type in your commands. when you launch an app, it creates a button on the taskbar and moves on top of the CLI and it is off to pointy-clicky.

the best command line iterface would be one that can identify a subset of natural language so you can ask it to open a certain document, or display a list of documents that meet certain criteria and it will do it.

I'd give my opinions, but...
by tw on Mon 8th Mar 2004 21:10 UTC

I'd give my opinions about the article, but for some strange reason I couldn't finish it due to a sudden urge to go make a cup of tea. :-)

I have often wondered if it may be true that the command line is a better place to start. Even as early as elementary school myself and my friends were learning a great deal about what was REALLY going on with the computer by interacting with the command prompt. Now, the complexity has increased to such immense levels that the safe sandbox to play and learn in just doesn't exist.

Re: Comand line interface is a good way of interacting
by BartS on Mon 8th Mar 2004 21:18 UTC

I do not think a subset of a langue is a good comand line language. You will always have to learn the commands, the computer will never really "understand" you. And I dont think it would make sense to translate the commands to other languages. (it would make it a lot harder to find documantation over the internet)

Commands should be short, distinct, and they should mean something. (It is easyer to memorise "rm" if you know it stands for "remove"). A real language only causes confusion.

v Command line is fine even for newbies
by Huh on Mon 8th Mar 2004 21:22 UTC

I think you've missed the point.

What you're describing is a power users interface that combines the best of both worlds, it makes things faster, and the expense of being more complex, not less. Prehaps something like (slightly modified though) screen would be more apropriate.

One of the key problems he pointed out that people have is when it is apropriate to use the mouse or keyboard. Apple has enjoyed a partial success here, since everything is mouse drive, except when explicitly entering text.

The natural language thing is... well, it's a nice idea. AI research has been grappling with this for quite some time. The main problem seems to be that everyone has very different ideas about what constitutes a natural language. For me, saying something like;
"xmms recursive enqueue /home/edward/music/"
makes perfect sense, where as for other people they may expect something like;

"play all my music files"

Does that mean all the files in the music folder? Including music videos? What about other music files on the computer? Perhaps they have a broadband connection with a subscription to a music channel/station.

Given enough time, a natural language interface may work, but I don't think we understand the process enough, nor do we have enough processing power or memory. Nice idea though.

by dacloo on Mon 8th Mar 2004 21:26 UTC

Interesting, and perhaps even true. The article doesn't compare with users that use their computer creativily. Personally I don't give squad about newbies, so I'm a different target audience, I must say that in front.

Every tasks: video editing, music making, Photoshoppin', etc has a GUI and it's damn neccessary too. It's a metaphor for real uses. Photoshop has the canvas, a music program has columns, music 'pages' or with audio processing, a visual representation of a synth (input/output/connectors).

So it depends. Controlling a computer may be more simple with a CLI for beginners, but actually *USING* software requires a GUI, because it works faster, and you need a customisable workflow.

I simply would not care if I had to make install every single app on my box, but the problem is that packages and even make installs often fail or break other software. When I am installed there is not one database that tracks what was installed and where.

If there was one method of packaging and installing software in Linux that worked 100% of the time _anyone_ could learn and use it even if it were time consuming and complex.

apt-get (debian - but for the love of god use backports or the sid/'unstable' tree)
or if you prefer to compile;
emerge (gentoo - not that I use it)

Next Article
by Ricardo on Mon 8th Mar 2004 21:41 UTC

Using command lines to play video-games. ;) ))))))

re: Next Article
by debman on Mon 8th Mar 2004 21:46 UTC

umm...I take it you never played games on DOS like say....DOOM or Wolfenstein 3d, etc.

RE: but...
by alt on Mon 8th Mar 2004 21:46 UTC

>Interesting, and perhaps even true. The article doesn't
>compare with users that use their computer creativily.

writing is not a creative use?

but yes, when you draw it is useful to see the drawing.

>music 'pages' or with audio processing, a visual >representation of a synth (input/output/connectors).

well, i rather use a real synth with real knobs than hit virtual ones one at a time with mouse..

>but actually *USING* software requires a GUI, because
>it works faster, and you need a customisable workflow.

depends on the software.
renaming two thousand frames of animation is pretty slow with gui.

RE: dacloo (IP:
by BR on Mon 8th Mar 2004 21:59 UTC

Well IMHO I think the best compromise is a hybrid interface. Taking the best qualities of both, in a complementry fashion.
The interface that is teaching, without being patronizing.
Evolving as needed. Nonbrittle in design.

A GUI-fied CLI?
by Anonymous on Mon 8th Mar 2004 22:03 UTC

Maybe what is needed is a GUI-fied CLI?
For example, when you start typing a command and press Ctrl+r for recent commands, it would popup a list of the relevant recent commands in a non intrusive way.
Or say, when you put jobs in the background, and they finish, you could have a little space on top to show you the background processes.
Or tabs as a gui way for the screen command? (Yes this exsists)
And last, when I start to type a command, a non-intrusive panel could popup showing me a little help about the command (such as possible argument variables)

I am sure there are many more such enhancements that could be done to the CLI to make it easier for beginers.

Excellent article
by Richard Newman on Mon 8th Mar 2004 22:06 UTC

I've noticed many of the same things, even with undergraduates in IT that I teach. Every dialog box, switch to a mouse, or unfamiliar window causes a look of surprise. I've often thought that a little bit of grounding in the CLI would do wonders for productivity, now that the vast majority of people have only ever used Windows.

The comparison between Pico and Notepad is good.

Personally, I find that working in a CLI is very productive; with a good way of multiplexing, it's nearly optimal. As it stands, having multiple terminal windows open doesn't work as well as it should, because picking the right one and swapping between them isn't easy.

Nice ideas, thank you.

by yutt on Mon 8th Mar 2004 22:12 UTC

Pfft, Wolf3D? What about Zork and Hitchhiker's Guide to the Galaxy? That's true CLI gaming.

Very unintuitive, requiring a big manual and a lot of failed guess-work. I think there's an analogy somewhere here...

by feed on Mon 8th Mar 2004 22:25 UTC

I would imagine the number of people who use multimedia creation applications for even 10% of the time they spend on a computer is pretty minimal.

In defense of the GUI ...
by Kady Mae on Mon 8th Mar 2004 22:33 UTC

The thing about GUIs of popular, widely used OSes or Windowing interfaces is that they all use similar principles and once you've mastered the principles, they serve a user well, no matter the OS.

Yes, there are things that will hang a user and throw them for a loop the first time in front of a new OS or Windowing interface, but these are small bumps and easily overcome. It took me a day to teach myself Aqua and leaping over to KDE wasn't much harder. I'll just drop down menus and click until I find what I'm looking for. Heck, because I knew the system of icons in W98, I had no problems navagating my Mother-In-Law's computer ... despite the fact that alles war auf Deutsch. (Everything was in German.)

However, teaching me a headful of DOS commands and then sitting me down in front of a *nix CLI isn't going to help. Or Vice Versa. Yeah, I'll understand the concepts of heirarchy and file paths and how to open the manual files but ... I'll have to open the manual for every freaking thing I want to do.

And if my native language isn't English, most of the commands I'll be typing will be little more than gobblygook. "mkdir" equaling "make directory" is fairly intutive if my native language is English, but not, say, Russian or Hindi.

(Case in point about switching from dos to *nix, I'm always having to reference my cheat sheet to see if I want to type or / in a pathname depending on the task I'm doing and what file server I'm dealing with. [XP desktop talking to XP, Solaris, or Linux servers.])

Don't get me wrong, the CLI has several merits. (And I think that any OS should have both ways of getting a task done.) But there are very compelling reasons that the GUI has become the standard way of interfacing with a computer.

Thats wierd ...
by Kady Mae on Mon 8th Mar 2004 22:35 UTC

In my last post, I typed "want to type or / in a pathname depending" but the backslash didn't appear.

by monki on Mon 8th Mar 2004 22:40 UTC

I've done a clait course both LI and LII, and really the introduction about the courses is to introduce students to information technology, really its just an introduction to microsoft office.

CLAIT: computer literacy and information technology.

GOod article:)

my "newbies & GUI" experience at a demo booth
by bact' on Mon 8th Mar 2004 22:48 UTC

visitor: how to use this?

me: oh, very easy. you just 'click' on this button.

visitor: 'click' ?

me: (realized that he never use computer or GUI before)
i mean you use a mouse, here is a mouse.
(i point him to the mouse)
you use the mouse to 'push' on this.
(i point him to the monitor
-- i use the word 'push' bcoz what to click is a (GUI) button)

visitor: oh, great. very easy.

then he pick that mouse up,
and really 'push' it against the monitor.

i can't do anything -_-"

RE: when things go wrong?
by monki on Mon 8th Mar 2004 22:48 UTC

What about when things go wrong? GUI's can be more useful, and also what about people with certain disabilities, or even children.

Children like colours and graphics, I think there is a paper at Imperial college, where a student designed a child like interface in Flash, to sit on top of Windows. Her research was to make the desktop more interesting for kids.

And it proved a hit, with the local primary school over there.

By the way this was before XP, came out and my little bro prefers the big, blue interface that comes with XP!! I prefer the Win2k interface...

Excellent article
by Wee-Jin Goh on Mon 8th Mar 2004 22:49 UTC

This is definitely one of the better researched articles that OSNews has published.

I think the findings are interesting. People generally do want to feel like they're in control, and the thing I've noticed with newbies in the introductory programming class I tutor, is that they're afraid to experiment. There's this nagging fear that if you do something wrong, the computer will explode (or some other catastrophe). Once you make it clear to them that the worse thing that could happen is the computer crashing (not physically falling to the ground, but rather just locking up) they're off. Once they get the fact that the computer is dumb, and it does what they tell it to do, they start enjoying themselves.

This could apply to the command line too. I agree with the author that the command line does help keep the 'conversation' metaphor, and users feel like they're having a conversation with the computer.

by cheezwog on Mon 8th Mar 2004 22:50 UTC

The best feature of the CLI is that you can jump between very different commands very quickly.

For instance, to change my IP address, see the uptime and then back up my home directory I can...
ifconfig eth0
cp -R ~/important_files/* /home/backup

With a gui I would be hunting through menus, clicking 'ok' boxes and dragging things around. I just don't get the same feeling of agility and economy of thought when mousing about a screen.

For a gui equivelent to the CLI, you would have to have 30 (or however many letters are needed) windows on screen, each with 30 subwindows, and each one of them with 30 more, and so on.

The problem with the CLI (under Linux anyway, I don't really know about other OS's) is that the command's flags are inconsistent, so you can never be sure what a -r,-R etc will do with any command. My ideal would be a UI that combined the best of both CLI/GUI worlds. Ratpoison is a little like this, but I would *never* recommend it to a newbie.

"Very unintuitive, requiring a big manual and a lot of failed guess-work. I think there's an analogy somewhere here..."

Text adventures have moved on a long way since those days. ;) Try some more recent ones with bigger parsers. I don't remember any text adventures with a big manual either, the infocom freebies were more in the spirit of fun than documentation.

RE: RE: but...

">music 'pages' or with audio processing, a visual >representation of a synth (input/output/connectors).

well, i rather use a real synth with real knobs than hit virtual ones one at a time with mouse.."

And some of us like using Csound with the CLI too. ;)

RE: 4 letter words for CLI
by Ronald Crain on Mon 8th Mar 2004 22:50 UTC

Studies have shown that 4 to 5 letter words are the easiest to remember if they relate to something. That is why most of the "curse" words consist of 4 to 5 letters (please, I did not say all).

I personally like a CLI so please do not construe my commensts as negative. If one thinks about how language develops one will have to face the world of pointing, grunting, and visible objects. If a child points at the cookie jar and says, "Uh" you at least know that he is pointing at an object. If he says it twice then you know he wants an action to take place. This was the start of the single and double mouse click functions.

We learned words to describe objects first. But we do not refer to tables, chairs, windows, etc in our mind as words. If one hears the word, "gorilla" one does not see the spelled word. Rather, your mind pictures a gorilla. Words are used to describe what is in our minds.

The early man hunters did not need words to convey messages. They pointed and made gestures. Baseball players do the same thing today.

A GUI is useful when it reflects the world we already know. Those things that we see and interpret. It is easier to teach a person to recognize poison ivy by sight then to have them describe it. "I know it when I see it" approach.

To me, the main problem with a GUI is that none of the GUIs being used today is very consistant in the usage of objects. For example how do you whether an icon is a button and only needs to be clicked once while another icon needs a doubleclick? It was obvious when buttons "looked" like buttons but today not all buttons look like buttons.

A computer newbie will always be a better computer user when you give them a visual picture to understand some of the underlying structure (files, for example) whether they use the CLI or GUI. As some have already pointed out, the use of applications requiring command line commands will not be able to give the level of complexity required of most modern programs. Hence, the GUI is very helpful. On the other hand, I can type in a simple CLI command to copy or backup all the documents in Word and that is easier than using a GUI.

Pick your preferable interface but do not expect the world to follow your decision. Isn't it wonderful to have diversity.

by theblob on Mon 8th Mar 2004 23:22 UTC

In my experience, most new computer users want to learn as little as possible. The people in this study are an exception, they are taking a course on computers - they WANT to learn. Most people just want to get their mail or find porn. For this, clicking on icons is still the best solution. GUI design seems very stagnant lately, theres been more emphasis on fancy graphics and bright colours, but no new ideas, we're still stuck on icons and menus. Hopefully someday, someone will find a better way. CLI will always be a favorite tool for powerusers though.

Just my $0.02 CAD

Learning about computers
by A.M.H on Mon 8th Mar 2004 23:47 UTC

I really enjoyed this article, but I wonder if the success of the course was due, in part, to the fact that you were teaching these participants the details of the CLI, starting from the basics. Would you have had similar sucess if you had taught them the basics of using a GUI?

The fact is, most people have no real formal training in the use of the PC. Just as your participants had no clear understanding of directory structures at first, so it is with people who use GUIs and get equally confused by the plethora of files and folders and how to manage them.

I once worked on a software helpdesk. Many people would phone simply asking how to use an application or perform a particular task (rather than report problems). People would often exclaim in surprise when you explained basic operations like how to move files or copy and paste! I can still remember how one caller gushed with excitement when she discovered she could paste a picture from one application to another!

I think the activity of issuing a command to the computer by typing it in ("commanding the computer to do your bidding") does give people a sense of control they may not feel when using a GUI. GUI's are more complicated than they need be in many cases, but once a user gets over their fear of the PC (and knows the basics), a GUI at least gives them the opportunity to explore the application environment (by clicking through menus, viewing options and using the undo command should they make a mistake). A CLI doesn't really have this advantage in my opinion.

by Kady Mae on Tue 9th Mar 2004 00:13 UTC

bact sez:

"visitor: how to use this?

me: oh, very easy. you just 'click' on this button.

visitor: 'click' ?

me: (realized that he never use computer or GUI before)
i mean you use a mouse, here is a mouse.


ROFL. Have had the same experience here at work. It happens less and less, but it still happens. (And usually with patrons who ask where the card catalog is ... "Uh, well then, how do I look up a book?")

But even back when we had a CLI based interface to the catalog, with a menu of commands at the bottom of the screen, computer noobies still needed hand holding to get through navigation.

While this article indicates that lots of attention was put towards studying the situation, I don't think the conclusions are entirely correct. I think it is true that you can train most any computer user to work with the command line. Note that I am indicating that you can train them. The major difference between a command line and a GUI is that the GUI allows for FAR greater "self discovery" than a command line. Indeed the "menu" of choices is displayed for you, once you get past the initial bell curve of learning the interface's basic functions (and for most people, this too can be totally by discovery as long as they are not afraid of hurting things).

If users complain that there is too much on the screen with a GUI, this does not necessarilly indicate that ALL GUIs are bad and that a CLI is superior and easier. It only indicates that for THOSE users, the GUI of Windows (or Mac or whatever it was they were talking about) is too cluttered and confusing. Truth be told, the GUI of both Windows and MacOS is filled with confusion, contradiction, bad metaphores and inconsistency. This does not mean that the GUI concept is invalid or the wrong path to take.

Look at a Palm handheld. Lots of people who have problems with full blown computers seem to be able to "get" the Palm rather easily. Anyone who is a computer user can definitely get the Palm within a few seconds or minutes. The GUI of the Palm is simplistic, direct, and the device does not multitask or have movable objects.

Anyway... I could ramble on for ages here... the article was well written and I really REALLY liked the repeated statements of the users being people who were NOT stupid. Far too many tech people are lazy with this attitude and just assume that anyone who can't understand what they have known for years must be an idiot. I just take issue with the validity of the conclusions based on the suspecting same kinds of mistakes were made that lots of well meaning researchers make all the time: being unaware of important variables, not fully understanding the subject matter (be that the technology, the psychology or both and more), misinterpreting the results and even misdirecting the expiriments and subjects due to personal prejudice and bias (as much as we try to be objective, the most objective person can still be very subjective when the topic is something the person is very involved in personally - and yes, that includes me too; I have a bias towards GUI because my learning and working processes are extremely visual).

CLI/GUI integration
by de Selby on Tue 9th Mar 2004 01:13 UTC

These">shell in the A/UX GUI looks like something I would have always loved.

Just double-click on a command like 'ls' and it gives a window of options. Select options and it shows you the command line it builds. Much better than 'man' for learning, IMO.

(If that link doesn't work, it's halfway down page 3 of this "about A/UX".)

by Chris on Tue 9th Mar 2004 01:14 UTC

I think it all really comes down to fear. Whether it is GUI or CLI the user fears they will break their new toy and leave themselves stranded on their computer with no one to rescue their $600+ investment. It's a valid fear too. However, more than likely they will be fine, the same risk happens when you drive your car (except that your life isn't risked with the computer).

Making CLI even more exploration friendly
by de Selby on Tue 9th Mar 2004 01:21 UTC

If the CLI supported by design moving deleted files into a directory called "trash" or "garbage" and gave you commands like "empty trash" and "undel /all" (or unrm --all), that would make exploration very friendly.

But I don't know how overwrite safety might work... File versions? ('vi important.txt;1' to edit version 1?)

Control group ?
by drsmithy on Tue 9th Mar 2004 01:22 UTC

To validate this experiment, you need to perform a similar one and similarly educate the users with regards to how to use a GUI.

I suspect the biggest reason your users had historic problems with GUIs is because no-one had sat down and shown them the same basics that you have with the CLI. Most likely this is because everyone works on the assumptions that "GUIs are easy" and, hence, that no-one needs to be taught how to use them.

For example:
This was opposed to their experiences with GUIs where they were the ones that felt like children pushing buttons at random on control panels.

Clearly, if the users feel like this, then they haven't been shown how to use it. It's not like there's any more randomness to the average GUI than the average CLI.

Your conclusions relating to comparing GUIs and CLIs are unjustified because you don't have equivalent data sets. You're effectively saying X is better than Y based on what you'd observed about X but only heard about Y.

I would ideally like to extend my little trial into a full newbie computing course where I teach the command line first before moving up into GUIs.

To make your experiment valid, you need to gather data with GUIs also taught as the first UI. "Moving up" to a GUI from a CLI destroys any validity of comparing, as the prior CLI knowledge will have an influence (similarly if one were to teach GUI use first and "move on" to a CLI).

I feel that my experiences here show that the CLI provides a far better environment for first-time computer users to find their feet.

They don't, because you haven't performed a comparison at all (let alone a fair one).

I believe it also gives them a better idea of what is actually happening inside their computer.

Nothing in this article suggests evidence to support this belief. A text message saying "You have new mail in <whereever>" is no more indicative of what's going on behind the scenes than a picture of a letter appearing discreetly on the screen.

The biggest strengths GUIs have over CLIs, from a newbie perspective are a) discoverability and b) feedback.

Your conclusion asserting CLIs are more discoverable based on the man pages example, IMHO, very contrived. Users only made those "discoveries" *after* you showing them how, not by finding them themselves. Similarly with regards to "Locations" - which in unix are only in the barest and most zoomed-out top-down perspective grouped by similarity (and definitely not by task).

While I commend your interest and attempt to actually observe and report scientifically, I don't think you can justify your conclusions relating to a CLI and GUI comparison, given you don't have any equivalent data relating to GUIs (at least, not in this article).

Newbies and CLI
by Ashwin on Tue 9th Mar 2004 03:00 UTC

My dad is all of 64 yrs. When he started on computers a year ago - he started with Linux (the man does not know the "windows-way".
One of his early observations was that it was easier for him to learn the command line and keyboard shortcuts. He could list these on a peice of paper and run thro' whenever he ran into trouble/forgot. Of course now he is on KDE 3.2 and seems fine with the GUI...

Weird Science
by Sofashark on Tue 9th Mar 2004 04:12 UTC

drsmithy touched on something that really annoyed me about this "experiment". It seems that it was contrived at the outset to satsify the author's predisposition towards using a CLI.

Consider the following statements from the article.

Here a small script was written by myself called 'inbg'...
An appropriate man page was written...
A small addition was made to the user's .login file...

and much else, as well as a great deal of verbal instruction given to the CLI users. The users didn't seem to "discover" the CLI so much as they were subtly led to it.

Contrast this to the GUI users who, as inferred in the article, were left to their own devices. More importantly, their successes and failures were largely unrecorded, or at least only to the extent that they supported the author's hypothesis.

Really, the only conclusion that I can draw is that the users were not so much happy with the CLI as they were with the attention and contrived environment that was provided by the author.

RE: Excellent article
by Dave Poirier on Tue 9th Mar 2004 04:44 UTC

Richard: you should try the Ion window manager, its entirely keyboard driven and quite frankly, boosts multiple terminal manipulation a few times over.

I've been using Ion as my main window manager for well over a year now, there's no way I'm ever switching back to an overlapping window system.

Re: Ion
by mabhatter on Tue 9th Mar 2004 05:17 UTC

Dave, I took a look at the screen shots and it looks interesting!

Actually, in discussions like this I always bring up AS400's ugly interface.

True, it's ugly, but it works great. The key is not the "green screen" but the feedback! The only major problem most people have with CLI is the lack of ANY directions at all...and that is really just silly. The AS400 is a great mix of screen menus and command line options. The key being that part of the screen is deticated to letting you know what to do and part is still left to do what ever you want.

One thing that most users don't see is the REAL command line...most "green screen" apps are strictly "fill-in-the-blank". The command line is awsome, It's completely can even prompt for "blanks" to fill in to finish commands but there are menus if you want them also.

I've always wondered why there isn't an OSS analog to that format. I'd note too that it doesn't have to be UGLY to work...Autocad uses much of the same types of feedback. When you use the mouse to select things, you are really entering commands on the CLI. Seasoned users can enter commands from memory, often more complex than what you could ever enter with the mouse!

I'd have to agree with the article though. Espically supporting "older" users who really don't want to use computers, CLI is MUCH BETTER! They often can't manipulate the mouse thru all those becomes a excercise in fustration for them. Then you have upgrades and patches that change stuff around for no reason... they just want to complete a task, not play games...CLI instructions are easier to publish too. You know how hard it is to explain the GUI blindly to somebody new to computers...versus simply printing a sheet of commands to type in!!! I'd maintain that what's needed is to start over and choose the best of both sides. Frankly, I'd start with a goal of "mouseless" because removing reliance on WIMP is the first step to computer "freedom". I'd even go so far as to look for a replacement to the mouse as an input's not as useful as a simple pen, nor featured as a's hard to do anything USEFUL with it. You can't even write your name easily!!

My Thoughts
by Christopher X on Tue 9th Mar 2004 06:11 UTC

note I hadn't yet read the article, I will after I post. Perhaps a mistake? Well, based on the topic here is what I think - it depends. My mother, hardly a techy, was a complete wiz at her real-estate software back when it was purely command-line, but once the Windows, and later web version came out, she ends up calling me for assistance relatively fequently. Command-lines are not intuitive, and rarely obvious, but once you memorize the limited set of commands, thats all you ever need. She took a class, she learned the app, and that was that. In those early days she never, NEVER, once called for help. GUIs confuse the crap out of her, and shes been using Windows for at least two years now. Depending on the application, I think command-lines really are better for newbies. Insofar as unix newbies, yes yes yes learn the command-line first! Unixen remain, despite KDE and Gnome, quite command-line centric and knowing how to delve into terminal to fix something is gold. Now, to read that article...

Live CD
by GW on Tue 9th Mar 2004 06:21 UTC

"If I were to hold the trial now, I would probably recommend the Knoppix Linux live-CD so they could just "reboot into discussion mode"."

I'd recommend SLAX live-CD over Knoppix in this case, as SLAX defaults to a CLI, whereas Knoppix boots into a GUI unless you specifically stop it from doing so.

I had no idea, is there a link? Is that a feature of the normal links, or is that a branched off version?

More Thoughts
by Maelstrom on Tue 9th Mar 2004 09:43 UTC

We should remember what the 'I' in 'CLI' stands for. This was a test of the interface rather than the commands themselves. Linux/Unix commands aren't intuitive, and have to be taught, but that's not the point. The students were happier with the interface because of it's similarity to any human communication. Maybe it helped them understand the 'computer as tool' concept - giving them the control they could easily understand - rather than 'computer as helpful friend' - seemingly what is used to sell computers to the masses these days.
So why aren't commands intuitive? I think mainly because they were designed to make things easier for the programmer, rather than the newbie. Saving time by shortening make directory to 'mkdir' is all well and good when the function can be easily guessed, but for the more esoteric commands? Is there not space for a full text alternative? BASIC became widely known because of it's simplicity, but could be 'shortcutted' - simplifying the command line could help make it the tool of choice, rather than the daunting back-up to any GUI.

RE: More Thoughts
by Mack Sim on Tue 9th Mar 2004 10:25 UTC

perhaps a LOGO - like feature, where the command "power user" could be spelled "pwr usr" and "power user" alike? And you could conceivably also set an alias, like "1337", if you wished?
Yes, I have RTFA and yes, i know most shells support aliasing
these features badly need to be made transparent, tho'

by Treza on Tue 9th Mar 2004 10:47 UTC

Some tools produce "command line transcripts" for all GUI operations. By examining these transcripts, you can build scripts, repeat complex ( GUI-wise ) tasks, save logs, ...

Maybe the GUI has two functions : Visualisation and Interface.
For many tasks, a graphical presentation is an essential feature. On the opposite, the Interface part can be for most tasks a hack on top of or in parallel with some background command line interpreter. Basically, all dialog boxes, wizards and menu items should be handled that way.

Natural language
by Treza on Tue 9th Mar 2004 10:55 UTC

The "natural language" interface is an illusion. No human language is precise, consise, consistant enough for giving orders to a computer.

For a caricatural example, see COBOL.

A consistant computer language is much more senseful than any human language adaptation tweak.

On a book about compilers from R.A.Finkel, he writes :
"[ My father ] was learning a language that could be read and written, but not pronounced. ( see )

Re: Learning
by Don Cox on Tue 9th Mar 2004 11:04 UTC

"I once worked on a software helpdesk. Many people would phone simply asking how to use an application or perform a particular task (rather than report problems). People would often exclaim in surprise when you explained basic operations like how to move files or copy and paste! I can still remember how one caller gushed with excitement when she discovered she could paste a picture from one application to another!"

One reason is that computers no longer come with an instruction book. Back in the 80s, machines like the Mac and the Amiga came with full instructions on how to use the GUI, with screen grabs, and also an on-screen tutorial.

I'm not convinced that the Dummys Guides are a good substitute, and they cost extra.

GUI with "pipe" ??
by bact' on Tue 9th Mar 2004 11:34 UTC

you have several windows open.
you click on "output pipe" from one window and drag it to connect to another window's "input slot".

..then it works just like the UNIX pipe.

hmm.. feasible?

by paul on Tue 9th Mar 2004 12:12 UTC

Back before there were GUI's, CLI's (and crude ones at that: my college didn't have ready access to anything as advanced as a Unix machine when I was there) was all we had and it worked. I programmed mostly in DEC Basic (everything else was punched cards.) I played a lot of Zork and its relatives (long after college, of course.)

A GUI doesn't do anything that can't be done otherwise (though my vi is pretty rusty these days), it just does it tremendously faster and easier. I still use a command line for admin type things (the standard renaming thousands of files) but editing hundreds of source files that way just doesn't cut it. It's possible but not practical.

Thinking about it, a CLI feels claustrophobic now: a GUI presents and lets me handle a lot more information at once (and reduces the amount I have to memorize to do it.)

For complete newbies, the CLI makes sense because they have so little to keep track of. Once they start using more than a few % of the features of their new computers, they'll discover that there is a better way to organize things than memorizing commands.

man page searches
by Chris Capoccia on Tue 9th Mar 2004 12:31 UTC

>Perhaps some search command for man pages would be useful here

basic searching can be done with
man -k keyword | more

where 'keyword' should be replaced by the keyword you wish to search by. i include the '| more' because usually it returns more than 1 screen of results.

Re: man page searches
by Rich Wareham on Tue 9th Mar 2004 12:47 UTC

basic searching can be done with
man -k keyword | more

From my article:

Perhaps some search command for man pages would be useful here (not apropos, that has never produced sensible answer for me).

Apropos, at least for me, is identical to man -k (as indeed indicated by the man man-page). Neither have ever been remotely useful for me. Mostly because they a) don't sort results by relevance and b) don't have any obvious way of restricting search to particular sections. I keep a load of API docs in man on my machine and searching always brings up a metric truck-load of Tk and Qt docs.

rewrite the man pages!
by davido on Tue 9th Mar 2004 14:10 UTC

What we really need to do is entirely rewrite man pages to make them "newbie useful". I remember as a beginning CS student how some of the man pages were um.. opaque, and not because the concepts were that difficult for, say, the find command, but because the manual was written by engineers for other engineers.

How about a man -newbie option?


unix for english users
by bob on Tue 9th Mar 2004 14:17 UTC

The mnemonic nature of Unix commands was surprisingly easier to remember than if they had been spelt out in their entirety. Apparently the vowel-less words and phrases gave the command names a "quirkiness" that was easier to remember

even for non-english users ?
it's bloody stupid !

apt and backports? What for?
by ranger on Tue 9th Mar 2004 14:22 UTC

If there was one method of packaging and installing software in Linux that worked 100% of the time _anyone_ could learn and use it even if it were time consuming and complex.

apt-get (debian - but for the love of god use backports or the sid/'unstable' tree)

urpmi (and you don't need any backports)

Autocad does it right
by Thelonious Georgia on Tue 9th Mar 2004 14:39 UTC

Autocad, being an inherently gui-based application, in fact has a command line where every single command can be done, complete with history. If I want to create a square, I can merely type the command into the app and poof! I get my square. If I did something wrong, the command line tells me.

To me, if an application is complex enough, adding more menus and more buttons does nothing but confuse more. But if the application has a command line, which you know will allow you to get the full functionality of the application, then nothing seems so daunting anymore.

...and thank you to the pupils, who provided their experiences as well.

Taking up Anonymous, on his/her points in "A GUI-fied CLI?", my understanding of the article is that flyover hints, and such pop-up help were actually what they found confusing.

Imagine: as you type along, suddenly there's a list box full of auto-completion suggestions. We know that we can just ignore it and keep typing, but they may think that they *have* to interact with it, that they *have* to choose one of the suggestions, and what if what they want to do isn't in the list? That's distressing.

I think that the lesson to be learnt not just that if the user wants to know what background tasks are running, they can easily remember to type 'ps', but that they even prefer it, and if they don't know the name of the command, then they are also very happy to use man and apropos to find out. The 'txtspeak' analogy is quite fundamental - if they can jump the gap from 'ps' to 'processes', then what they are typing starts to make perfect sense.

Lots of food for thought.

Easy mnemonic "quirkiness"
by de Selby on Tue 9th Mar 2004 14:41 UTC

You might be able to "sound out" some commands like rm, ls or cp to remember what they mean. (I don't know why, but cp aways gave me trouble, though.)

But awk, cat, cron, dd, figer, grep, hash, ln, nice, ps, tac, tee, top, touch, and almost any program/command not clearly named after its function gives people some real trouble (even cups).

by daan on Tue 9th Mar 2004 15:06 UTC

A CLI might indeed be better than a GUI for file management... but how about the applications? Mail, Pine, Mutt, TRN, Links, VI and Emacs all work in a different way. That is also confusing. For example, I know how to compile a Linux kernel, made a Windows webserver with plugin support with Delphi, I have no problems in using Windows, MacOS, KDE or GNOME, not using Pine or Nano. But Emacs or Vi are just too confusing to me.
So how should applications be fitted into a sheme? Should they also be cli? I guess not, as that would effectively multiply the number of commands. I would still think that, to be user-friendly, you need a consistent interface, thus with all applications supporting either EXIT or QUIT, "mail" also supporting the CD command to enter mail folders, and so on. And of course, widgets (such as for text editing) should always behave the same.

RE: The Command Line - The Best Newbie Interface?
by Anon on Tue 9th Mar 2004 15:46 UTC

An interesting essay, one might also consider how much customer alienation is caused by these interminable telephone message systems; "If you want xxxx, press one."

Many years ago, my department needed word processing capability. The systems available were far two expensive. We had a Unix V7 system that was not heavily used and it was suggested that it be used for the task. Managers and engineers objected strenuously as the system was too difficult for the use of mere secretaries. The project went ahead in spite of the objections and the secretaries were taught vi and nroff. Much to the chagrin of the doubters, the secretaries were soon happily producing everything from technical reports to business letters and memoranda on the Unix system. Most became more proficient than the Unix gurus.

I surmised two things; 1) lack of a university degree does not imply stupidity, 2) Naysayers are either arrogant or insecure in their own abilities.

re: Daan
by de Selby on Tue 9th Mar 2004 15:51 UTC

Mail, Pine, Mutt, TRN, Links, VI and Emacs all work in a different way. That is also confusing.

I hear you. Common shortcut keys are different between apps (different paste keys, etc.) and even a lot of flags are different letters to do the same thing or same thing with different letters...

But I won't criticize Vi for being modal (should I?); I'll just criticize the whole package for not putting out a single united interface.


And apropos, while theoretically very helpful, has one of the worst names a command like it could have.

large programs presenting many commands
by Steve on Tue 9th Mar 2004 16:07 UTC

The 'renaming 2000 frames' comment earlier in the discussion made me think - what if big programs like Word or Photoshop could present a set of it's features to the shell, as though they were commands? So, imagine being able to call commands like

wd.auth "doc1.doc" "Steve"

to set the author of a word document, or

ps.scale 400 300 source.gif out.gif

to rescale a photo in photoshop.

It'd be far more useful to far more people than an API or javascript object model. You could write decent scripts quickly to use normally gui-driven apps as batch processors. Really useful.

WOW! You guys are missing the point . . .
by Mark on Tue 9th Mar 2004 16:28 UTC

Of course your not going to use the command line for playing games or editing videos! There is a place for a mouse driven user interface. However, basic commands to interact with a system often times is not it. The GUI we use today adds an overwhelming burden on the system that (plug your ears game nerds & video geeks)is often not necessary for basic functions such as accounting, word processing, spreadsheet, data entry applications, etc. Which, after all, is the core purpose for a business machine (computer). The GUI has driven us to have to purchase more computer than should be required. System admins have known this for years (plug your ears Microsoft admins) the command line is where the real work gets done. I would not want the overhead of a GUI to administer my system. I want to leave those resources to the system to perform its real work.

Re: presenting many commands
by Don Cox on Tue 9th Mar 2004 16:48 UTC

"The 'renaming 2000 frames' comment earlier in the discussion made me think - what if big programs like Word or Photoshop could present a set of it's features to the shell, as though they were commands? So, imagine being able to call commands like

wd.auth "doc1.doc" "Steve""

Yes, you can do that kind of thing with ARexx on Amiga, although it is more common to run a short script from within the program's GUI interface.

Maybe you can do it with Applescript too. Any OS X users here?

I don't know
by Joe Klimek on Tue 9th Mar 2004 17:00 UTC

People learn and process information in many different ways. For this reason. I am bothered by the notion that one single interface is the best. The other thing that bothers me is the confusion between methodology and bad design. The problem with cascading control panels is not a methodology (i.e. GUI) problem, but just bad design (see Microsoft <grin>). Thirdly, the author's own description of Tillie's enviroment is a description of a GUI interface. The existence of many graphical objects (properly weighted and organized) provides context not available in a command line interface. My experience is quite differnt than the authors. I teach newbies to use computers and most find GUI's to be easy-to-understand at the initial introduction. Then. with more experience, it becomes very apparent that the command line interface has significant advantage in certian instances. As many readers have pointed out, a mix of GUI and command line is ideal. Then, the user that will decide which to use, based on his/her comfort level. As a side note, if linux were to build better depth into its GUI interface, it would be more acceptible to the Newbie. Finally, the myth that a mouse is difficult to use (implied in the article) is just that, a myth. The only demographic group that I have have seen have problems with a mouse are the elderly or people who have dexterity problems. This group often finds it difficult to hold the mouse still while they click. In this case, I recommend a stationary ball mouse (or whatever they are called). This helps about 90% of the time.

by Anonymous on Tue 9th Mar 2004 17:08 UTC

I would also introduce students to lynx and irc on the command line. And like you, I would use pico (actually, the open source clone "nano") for text editing, but watch out for automatic line wrapping. Later you could show how to make an alias for "nano -w".

cd, cd .., cd ../folder

ls, ls -la

mv, cp, rm, rm -R folder, mkdir, rmdir

Some commands to find info about the system (free, du, ps, ...).

.login, .tcshrc, etc. shell scripts

chmod 700/644/755, chown, sudo

wget or curl for downloading stuff from the net (very important), along with tar xzvf and tar czvf

./configure, make, make install

apache web serving, .htaccess, htpasswd

That's like 95% of what most people use.

I agree, "man" is usually not very much help at all. I hate how they virtually never include an actual example of using the command.

by Ronald Crain on Tue 9th Mar 2004 17:25 UTC

In the beginning there was CLI and no other options for the general computer user. Each application provided its own secret usage of key strokes and very seldom did they match anyone elses special key strokes. Thus, with each application you had to mentally reassign key strokes to new functions (or replace old ones). This was very confusing and made learning new applications more time consuming (called a learning curve).

Then, along came the GUI. The company insisted that all developers use similar "actions" to trigger specific end results (eg., Command-Z, -X, -C, -V on a Mac OS and Control-Z, -X, -C, -V in MS OS). Suddenly the end user did not have to relearn new keystrokes for similar functions. Studies backed this up by showing that users of a GUI used, on a regular basis, more applications than those with the CLI. Please note that this was in reference to people who did not want to become computer gurus. They just wanted to get their work done.

The advantage of some consistancy in the user interface along with familiar icons to represent things is what really spread the use of computers to non-computer buffs.

The situation is now reaching the point where the software is doing so much more than the original applications with a resulting increased complexity in the interface. For the general user the GUI is still the preferred interface. MicroSoft did not develop one because they thought that the GUI was downgrading the user experience. They did it because they knew it would sell and make them lots of money. The same is true of Apple.

I can learn a new application using a GUI much faster than with a CLI which means that I am productive with less effort and less time. That is not to imply that a CLI is bad or has no further use. Obviously there are things which are very suitable for a CLI such a programming, file manipulation, etc. However, most of these are in the realm of "professional" computer folks and the masses are not interested.

I love driving my car but I have no interest in having to maintain it as a mechanic or electronics repairman. I jut want to go from point A to point B in an enjoyable trip (if traffic will allow that). I also want automatic shift even though there are advantages to a stick shift. And guess what. That is the consensus of the driving public.

Yes, the GUI needs some real work done on it. It is getting cluttered with obvious flaws such as inconsistant actions across applications. Personally, I am very comfortable with a CLI but I do not recommend that we go backwards for the general public. For the computer buffs - LONG LIVE THE CLI.

Discussion Mode Email
by Anonymous on Tue 9th Mar 2004 17:31 UTC

The best discussion mode email program would be 'mh', where all of the email commands are broken out into little stand alone programs.

by Rayiner Hashem on Tue 9th Mar 2004 17:45 UTC

@Ronald Crain: Yes, pointing and "grunting" is the easiest thing for a human to master without any training, but it is also one of the *least* expressive ways to communicate. The thing about the CLI is that it is extremely expressive. Thanks to the sheer power of human language skills, complex ideas can be specified succinctly. As computers become more integral to our lives, and schools start having computer training courses alongside mathematics and reading courses, we'll see more expressive (and thus productive!) forms of communication with the computer win out over the primitive "point and grunt" method.

As for integration of the CLI and GUI --- I've brought up the idea in a similar discussion awhile ago. I used AutoCAD as a wonderful example of this. AutoCAD is a piece of software that engineers used to do 2D drafting. Obviously, it needs some sort of graphical capability, since drafting is ultimately visual. However, it has an integrated CLI. Complex manipulations, such as bisecting angles or laying out certain verticies, are much faster using the CLI than using the GUI. What is also immensly helpful, and will be pretty much required for any CLI/GUI hybrid interface is a keyboard/mouse combo such as those found on laptops. Being able to do the occasional GUI task without removing your hands from the keyboard does wonders for productivity.

make bash report the bg status immediately
by Hiram Abiff on Tue 9th Mar 2004 17:46 UTC

Just put a set -b in your .login, or type it at the the command prompt.

Good comments... some responses
by Jace on Tue 9th Mar 2004 17:52 UTC

Great postings by drsmithy, Don Cox, bob and davido. I agree with just about everything you guys said. I'm glad I didn't ramble on as long as I might have in my other post because you folks said some of the things I would have said and said it better (esp drsmithy, who's comments were exactly what I was trying to get at in my clumsy and tired way).

I'm glad to see people thinking here...

Oh yeah... a little more food for thought:

Maelstrom said:
"We should remember what the 'I' in 'CLI' stands for. This was a test of the interface rather than the commands themselves. Linux/Unix commands aren't intuitive, and have to be taught, but that's not the point."

This is splitting of hairs along the lines of "Linux isn't an operating system, it's a kernel!"

That line of reasoning is merely passing the buck. It isn't *this* that's at fault, it's *those other people* who make *that other part* which is used by it [all the time].

You're trying to separate the methodology from the implimentation. I don't think that the author did that in this article. He ended up declaring that the methodology of the GUI is bad. Period. Which I disagree with wholeheartedly. Anyway...

The implimentation of the methodology ends up making the sum of the parts either good or bad. The perception on the part of the users could be "this is bad" or "this is good." The end result? Someone declares that methodology to be bad, as the author has.

All the programs and tools you use at the CLI which do not create their own interfaces, by *implication* ARE *part of* that interface. If they are there and are expected to be used by users, then they are the parts that make up the whole. If we say "The CLI is not at fault, it's every program and command that's used in the CLI that is at fault" what else is left?

Surely a better command line interface would be one that works via:

1. Commands that were made up of very common short words in each localization, along with a synonym process that responded correctly to similar words instead of throwing up "Bad command or file name"
2. Consistent syntax based on localization norms (noun -> verb or verb -> noun, etc) and an interpreter process that responded correctly to noun/verb placement changes (understand you I when placed words different order in, even if it reads poorly and sounds bad and is technically incorrect)
3. Tools that responded with USEFUL and MEANINGFUL non-geek messages
4. Good documentation written for users and not for developers or geeks.
5. Most importantly, the desire, within the developers, to make 1 through 4 a reality.

I don't see these coming true any time soon. Why? The people who WANT to use a CLI most often are also the ones developing it and they see no need to change it because it suits them just fine. But then, that's the real problem with all of this stuff, now isn't it?

@Ronald Crain
by Rayiner Hashem on Tue 9th Mar 2004 17:56 UTC

The car analogy is silly. Knowing more about the car will not increase your "productivity" because you are limited by the speed of traffic. Computers are not like that. Knowing more about your computer can mean spending less time in front of it.

In DC metro area, where I live, many have commutes upward of 60 minutes each way. You can bet that all of them would learn more about their car if they could turn that into a 40 minute commute!

Fundamental Problems
by kilarb on Tue 9th Mar 2004 18:21 UTC

The fundamental problem with CLI is that without instruction of some kind, a new user canít do ANYTHING. If you know no valid commands, CLI is useless.

GUI, OTOH, requires no instruction to overcome this hurdle. Once you figure what a mouse is for, you click things and the computer does stuff. Hopefully you are doing what you want to do... But remember that one of those clickable things "might" erase your files or crash your system.

GUI then is better for the uninstructed noob because they can make things happen.

The GUI Advanced Beginner knows how to run a few programs that they use every day. They know nothing else. The other 99.5% of their system is unexplored and dangerous. It contains clickable things of unknown function. One of them might erase their files... Sure you have a Help function... but HELP in Windows isn't particularly useful, and help in the various Linux GUIs is, if anything, worse.

The CLI advanced beginner is also able to use some every day programs. In addition, he understands the use of the few commands he knows. It is very, very difficult to "accidentally" do something in CLI to erase ones files. (Social engineering TYPE THIS disasters aside) CLI help isn't much better than GUI help... It wont tell you how to do whatever it is you want to do... BUT you can get a list of possible commands, and you can find out what those commands can do. At this stage, CLI is much more discoverable.

As users advance further, the fundamental flaws of both methods remain. GUI users may know what they want to do. They may even know that it is possible. They may have done it before. But before they can do it again, they have to remember or guss the correct sequence of menus to find the command they want to issue. (Sounds easy? Try moving to winXP from winME... you know what is possible, but where is the option...)

CLI users can simply command the system with no worries about submenus or "grayed out" options. If they forget the command, they can pull up a list of possible commands. If they forget what a command does, they can get help on that. But they must master and remember an often cryptic syntax. Also, while CLI help tends to be informative on the What of commands, it tends to lack instruction on the performance of specific tasks.

In general, I have found that users who understand and can use CLI are more computer literate in general. The CLI literate make better, or at least more confident, GUI users...

by Ronald Crain on Tue 9th Mar 2004 18:23 UTC

I obviously did not write a sufficient wordage (strived for some terseness) to properly explain the comment on cars. I was not trying to imply that one had to know how to repair a car to drive in traffic. Rather, I was trying to imply that the user (meaning the masses) are more concerned with "comfort" of using a tool rather than how its inner workings function. The statement was meant to be interpreted as one spends all of their time going from point A to point B.

It is also obvious that anyone who knows more about the inner workings of anything will be better able to use and adapt to new situations. However, that argument is as valid for a GUI as it is for a CLI.

IMHO my conclusion is still the same: The general computer user just wants to get the work done with a minum of effort. How do I know this. I have taught hundreds of students, and retired adults, using both interfaces. When properly presented either interface can be made to appear easy and logical. Some folks love the "verbal" approach but most prefer the GUI. If this were not the case then please explain to me why the GUI has a much bigger fan club than the CLI. (Consider the overwhelming XP and OS X users as contrasted to *nix users.}

When forums for Linux are discussed here I find that most are talking about getting a good GUI interface to make the OS more palatable for the general users.

that's how I learned
by Michelle on Tue 9th Mar 2004 18:28 UTC

I started out with a DOS box when I was 7. Now, at 7 years old, I didn't know and couldn't really remember a whole lot of commands. My dad told me had also installed the unix commands and how I could use either "dir" or "ls". He also wrote a script that allowed me to type "menu" and get a nice menu of the programs I could run and all I had to do was type in a number. Of course that wasn't good enough for me. He used vi to create the menu, and I watched him add entries a few times. He even tried to teach me the vi commands, but I kept forgetting them. Being 7, I didn't know anything about the man pages, so I simply opened files with vi, and when I couldn't get out using escape, I just rebooted and went back to using my menu. No harm, no foul.

When we finally got a machine running Windows 3.1, I picked it up pretty quickly. I realized that the whole drag and drop thing was just an easier way of typing cp or mv. And when you can't type very well, the mouse is way better than typing out those file names. I unfortunatly lost touch with the command line, and became reliant on the gui.

Now, 15 years later, I'm typing this post in Linux. Why do I prefer Linux? Becuase it runs over a command line, like good old windows 3.1. I can easily explore menus and click on stuff in the gui to figure out how to do things, but as soon as I do, I want to know the underlying commands. My thought process is something like "Oh, I can change that in that control panel there.....I wonder what config file that is modifying," becuase I know the gui will only give you so many options. If you want to really mess with things, you have to use the command line.

Of course, with just the commad line, you run into the same problems I did when I was's great IF you know the commands. I have recently saved an old 386 laptop running windows 3.11 from being simply thrown away. It has an external trackball, which is a pain, so simply playing around in DOS would be much faster, but I can't remember the commands. So I just boot it up to beat Solitare and laugh at how slowly the cards bounce around after you win.

I really like the idea of a hybrid system. Not only would you have the ability to open a terminal to tell the system what to do, but each program could have a hide-able command like built in (maybe at the bottom of its window) so you could either click on stuff to make the program do things, or just tell it what to do via its command line.

similar experience in public libraries
by Anonymous on Tue 9th Mar 2004 18:51 UTC

I used to be the library geek for an inner ring suburban public library, and I found that most people over the age of roughly 8 did better with a CLI than with a GUI. My senior citizens had a very difficult time learning to mouse. The idea of clicking on things was counter-intuitive.

My mother started using computers in her 60's. Her first exposure was to Macs, and she just couldn't understand them. However, she did just fine on my DOS computer, once I explained that computer crashes didn't generally involve shooting flames and explosions, and that she could get a game of bridge by typing 'bridge'.

As implied by the Aunt Tilly thought experiment, the first thing you have to do is to figure out what the person wants (or needs), and how the computer can provide it. Without that bridge game, my mother would still be writing out her recipes on index cards.

v proofreading?
by Anonymous on Tue 9th Mar 2004 18:57 UTC
Re: Re: Ion
by circuit_breaker on Tue 9th Mar 2004 19:10 UTC

While your argument may have some truth- what about crap like print queues- wrkoutq, strprtwtr, strrmtwtr, blah- all of the command names are shortened, and it can be hell trying to remember what IBM engineers use as terminology for some things. I realize if i lived on it, i'd remember them all but to someone who only rarely has to do tasks on an AS/400, it's pure unadulterated hell. i've been using unix for 10 years or so.. i keep my distance from as/400s. ;)

Aliasing made transparent for Mack Sim
by Martian_Bob on Tue 9th Mar 2004 19:43 UTC

Aliasing on the CLI is quite simple. For example, in tcsh (no shell wars, please!), simply type

alias what_you_want_to_type "what_you_want_to_happen arg1 arg2 etc..."

The alias sticks around for your entire session. To make it permanent, throw the same line into your .cshrc file, then type

source .cshrc

I'd teach it to newbs like this. You set up your aliases like they're code words, or slang. For example, if I "Google" something, it means I open up a web browser, and search for that thing on Google. An alias is the same thing; it's a word (standing for a command) that you make up, which stands for other commands.

Aliases can be made up on the fly - show the newbs (who I'd assume are proficient in basic CLI use at this point) a command line, and type

alias xyzzy "echo Nothing Happens"

Explain what echo is, how it works, why it printed out "Nothing Happens". Have them come up with their own aliases; if you're on a system that allows colorized output of ls, have them try making an alias for ls -G to show them that an alias can remember flags for you.

Next, explain to them that they can save their aliases for future use. Again, assuming tcsh, open the .cshrc file, put the alias line in, save it. If you don't want to mess about wtih the source command, you can just close the terminal window and open up a new one.

Just some thoughts, I'll likely be teaching a course similar to this one next year, got ideas bouncing around.

by Thomas on Tue 9th Mar 2004 20:13 UTC

I think Richard Wareham is exceptional in his ability to use computer terms metaphorically. Be it CLI or GUI nothing is better than having a talented, interested, intelligent person teaching the basics. This article reminds me of a book I read recently entitled "The Flickering Mind: The False Promise of Technology in the Classroom and How Learning Can Be Saved".

An interesting thought brought out in this book was that the digital divide will continue even if computer access is available to all. The reason; The rich will have tutors (live instructors such as Richard Wareham) the poor will have GUI interfaces and incomprehensible manuals.

Graphics can be made on the CLI
by Anonymous on Tue 9th Mar 2004 20:16 UTC

"Every tasks: video editing, music making, Photoshoppin', etc has a GUI and it's damn neccessary too. It's a metaphor for real uses. Photoshop has the canvas, a music program has columns, music 'pages' or with audio processing, a visual representation of a synth (input/output/connectors). "

What about writing, or since you are Graphics oriented PovRay?

CLI Standards for consistent switches/flags
by M Stieg on Tue 9th Mar 2004 20:39 UTC

When I was learning to use the CLI for many tasks, I wished that all (or most) CLI commands would use consistent flags across all apps. So "-r" or "-f" would mean and do the same thing regardless of which command you were using.

The way Grep, Awk, etc uses different syntax from other commands makes it much harder to learn. It seems to me if someone made guidelines for command flags/switches (much like Apple's or MS's guidelines), and of course redid all of the existing apps to conform to the new consistencies, we'd really be somewhere.

The command line would be much simpler to use. And people would quickly learn the common commands (just as ^x is cut, etc...) that work across the whole OS.

Of course everyone would have to re-learn the new commands! That's a problem.

@Ronald Crain
by Rayiner Hashem on Tue 9th Mar 2004 20:46 UTC

My point did not involve so much GUI vs CLI, but people trying to use things with "minimum effort." While getting trained might require more effort, it can allow huge gains in productivity. The reason, then, that the car analogy makes no sense is that learning more about the car won't let you go from point A to point B faster, wheras learning more about the computer will let you do your job faster.

As computers become more important, people will be forced to expend more than a minimum effort in understanding them. Already, millions of office workers and students spend much of their day working on a computer. Eventually, people will be forced to become proficient with computers, because their jobs depend on it. And as people get formal computer training, things like the CLI, which require more training but can boost productivity, will see wider use. It probably won't be the same sort of CLI we see today, but it will definitely be something along the lines of a conversational interface, vs a "point and grunt" interface.

I've personally trained more than 10,000 people how to use DOS, Windows 3.x and Windows 9.x, most of them elderly. Perhaps under certain highly constrained conditions the opacity of a a CLI might prove useful. But overwhelmingly it is much easier to build useful metaphors in people's heads with a GUI.

The author is an engineer, not a human factors expert. It's unsurprising that he thinks a command line is a useful UI.

by stephen on Tue 9th Mar 2004 22:09 UTC

To me this paper has demonstrated an effective approach to teaching the CLI. It's a tribute to the author's pedagogy. It doesn't say anything about the merits of CLI vs GUI though.

RE: Tom
by Ronald Crain on Tue 9th Mar 2004 22:28 UTC

Thank you Tom. You have said something that i was skirting around trying to be delicate. I agree that learning to type arcane commands to do wonderous things is great when you have expended the large amount of effort required to learn it. My experience in teaching others (I was being modest when I said hundreds) backs up your experience.

To all those who feel the power of a CLI I say, "Go for it". I agree that it gives you great power and control over your computer. You can even learn machine language and all the other languages, including scripting, and be even a bigger power user. However, most people are not interested in such things and really do not wish to spend the extra time that it takes to become that proficient (Yes, I can and have written programs in dozens of languages including binary). Just because I enjoy these things, including the challenge and satisfaction of learning them, does not mean everyone should be like me and enjoy them also.

I have a friend, a Ph.D. engineeer, who loves the written commands and finds the use of GUIs counterproductive. The difference is that he does not expect, or promote the concept that it is superior to others. He, like the author admits that it is teachable and learnable. Of course, so are almost everything else. He just prefers that mode of usage.

So, we agree that it is teachable and learnable. We disagree on the idea that the majority of users should prefer a CLI over a GUI. The facts supporting the popular use of a GUI are so overwhelming, supporting my own experience, that I fail to understand any arguments that try to claim that the CLI is preferable for a newbie. Roughly 95% of my newbies prefer a visual approach to computer usage rather than the memorization of arcane commands. Note: I do not claim that all keyboard commands are arcane. Nor do I claim that all GUI usage is logical.

Compare like with like
by Ian on Tue 9th Mar 2004 22:31 UTC

This article was not a GUI v CLI comparison. It focusses on "learning at the newbie stage". He taught them a few commands to start Thats all they saw. Easy to remember. not too complicated.
But once it gets beyond that, things start to look different. If you teach a gui user good practice from the word go, customise his/her workspace with commonly used programs and shortcuts (including the start up folder), then we are getting a better comparison.
We all visit strange websites regularly which can look and act completely differently, yet we can navigate all but the worst designed ones.
GUIs designers have examined our everyday tasks, making them very easy for us. Often a single click. CLIs often make you do them longhand, with lots of commands to type each time. cd .., ls, cd work, ls, mv test1.txt test2.txt.
This is not comparing like for like. The GUI has been fine tuned for everyday tasks. You have to be good (not a newbie) to keep up with a CLI. Sure you can type lots of commands in quickly, but you need to, to do the same task.

A graphical terminal emulator?
by ghakko on Tue 9th Mar 2004 22:46 UTC

Don't forget Mozilla's xmlterm. ;)

It's a simple idea: allow HTML and inline images to be embedded in the output of an otherwise VT100-compatible terminal emulator. It might, with a bit of tweaking to existing console apps, combine the best of both worlds.

Background jobs
by ghakko on Tue 9th Mar 2004 22:52 UTC

Another suggestion -- if users are being confused by output from background jobs being sprayed unexpectedly onto the terminal, you might want to have them use at(1) or batch(1) instead and receive the results by mail.

CLI as best for newbies
by Roedy Green on Tue 9th Mar 2004 23:54 UTC

I remember trying to teach a group of women who had been out of the workplace for many years. They were all terrified of computers. I asked them just to pound the keys randomly to prove to themselves the computer would not explode as in Star Trek at the first miskey. One woman burst into tears. "Which key should I hit?" "Lots of them. It does not matter". She complained to the government sponsor of the program that I had abused her by forcing her to choose.

Most people want to memorise recipies for every task with ZERO understanding of how they work. CLI works fine for them.

I think the author could have got some good GUI results as well, by the same techniques to teach fearlessness and an experimental attitude.

In teaching kids, I make them GUESS what a command does as a big game. It gets them in the early habit of experimenting and makes them not at all ashamed not to understand right off the bat.

Getting the cart before the horse
by Buck Martin on Wed 10th Mar 2004 01:11 UTC

As someone whose first encounters with computers involved user interfaces that relied entirely on flipping switches and punching paper tape on TTY and TTS units, it's painfully obvious that much of this discussion is entirely misdirected: A command line interface is just another GUI and is itself a metaphor for controlling the interactions taking place at the computer's (or network's) binary level.

While controlling binary-level behavior is the role of the user interface, differing skill levels really call for different, or better yet evolutionary, interfaces that reflect the computer operator's skill level as it expands.

A novice whose primary goal is developing computer skills has user interface needs that contrast sharply with the experienced computer operator's need to perform tasks efficiently. To meet a novice's needs, the computer should ideally boot into a task-oriented Help system, not into the computer's user interface. Initial choices like "How do I write a letter?" are far more useful to the novice than a bare command prompt or a collection of icons.

The modern command line interface is particularly poor at meeting a novice's needs because the Help system (such as Man files) requires the user to know which command or application is needed in order to access the relevant Help file. What is nowadays commonly referred to as a GUI (e.g., Windows) is only slightly better because the involved icons or menu selections may occasionally actually point to some relevant Help files. However, even the Windows Help system, which is far less fragmented than the Unix Man file system, is itself too fragmented to be useful to a novice. For example, selecting "help" on the Windows taskbar gets you help with using the operating system and doesn't offer a clue about our hypothetical novice who just wants to learn how to write a letter.

To me, all my years spent using computers strongly counsel that the utopian computer operating system for novices be centered on the Help system, not on the command interface. As the novice acquires skills, the system should focus more on execution of commands than on the Help system.

Along those lines, the best I've seen thus far is 4DOS, which allows a command line at the end of a scrollable help page tied together by a searchable and editable Help system. Even there though, there's no way to integrate application's Help systems with the operating system's, and the Help system remains largely focused on how to issue fairly--to the novice--abstract commands without answering such basic questions as "How do I write a letter."

To me, the future of operating systems is far more dependent on their ability to teach computer skills than on the metaphor employed in the user interface.

CLI GUI Hybrid?
by Tristan on Wed 10th Mar 2004 05:45 UTC

There are several things which can be done with a CLI much more easily than a GUI:

1. Note taking - a new user can *write down* what s/he did without drawing pictures of GUI windows. A lot of people (*caugh* me) can't learn anything without taking notes; most of us don't have photographic memories. It's also easier for others to write down instructions, as others have pointed out.

2. Scripting - not directly useful for a newbie, but if there's someone else whose job it is to get them productive, things can be automated easily.

GUIs are a lot better for presenting graphical information such as drawings or object relationships, and Windows Explorer is easier for copying files around than "cp", except for complex operations such as "copy all the .c files and no others"), though newbies won't find that too useful. GUIs are "discoverable", but it's often difficult to repeat discoveries the next day, because it's hard to take notes (you can, but you wind up with either an ambiguous sequence of directions which becomes meaningless if you misread a single one in the sequence, or else you spend a *lot* of time drawing pictures of the GUI as you learn - difficult if you're not artistic, or if some busy person is telling you what to do and they don't have time to wait for you to sketch everything).

The best UI I've seen is ModelTech's VHDL simulator, which has a GUI and a command window. When you do anything on the GUI, the command is printed. You can save scripts from it, and type in the commands, and use arrow keys to edit and reenter commands (someone else pointed out Autocad does this too). For any complex app this is the *only* UI type that makes sense - above a certain complexity limit, wading through six levels of menues to get to something whose name you remember is just too damned tedious. And try telling someone *else* what to do, over the phone. When I do something in Modelsim, I can *write down* what I did easily, and do it again later.

My mother, a lawyer, uses WordPerfect specifically because it's the only WP which has the "reveal codes" feature, which shows the formatting codes directly in a text window and lets her edit them. It allows her to fix fouled up formatting in a document directly. Man, I wish Word had that... when things get fouled up in Word, one's only option is to live with it or start over.

Seems like the OS itself is a "complex app" and ought to run the same way - a GUI with a command window. Linux is sort of like this, but not well integrated; what you'd really need is a GUI-shell designed specifically for this, so that every menu-command shows up as a command. Integrating it with keyword-search would be good too, for when you remember a word but it's not quite the name of the command (or menu option). It might also be useful to have some way to get back to GUI-actions from commands, i.e. to say, "show me what to do in the menues to do what this command does". People can remember (and write down) words. Hieroglyphics died for a reason. However, there really are a lot of things that are easier to do by drag/drop/point/click than typing in long commands. So I want to write down the command name, then type "show cp" and have it show me how to copy files (or whatever) in the GUI world.

Try Cygwin
by Flounder on Wed 10th Mar 2004 12:47 UTC

I would recommed that the author look at cygwin as an easy way to get users able to use bash on a windows machine. It has all the handy commmand line utilities and man pages. It also creates a semi-safe home directory for each login name. It is a great way for windows users to experiment with the UNIX CLI.

Everyone has a different computer-use history, and so learnt through a different progression.

Young children can grasp the use of a mouse, and its relationship to on-screen action quite swiftly! In contrast, they can fail to understand that different hardware may not offer them the SAME experience, or action/reaction, as their first access did!

THIS LAST CONCEPT may as well confuse adults!

I (through 22 years) progressed from C64-C128-Amiga-Mac-Win3.11-Storm/DebianKDE-Win95,98-DebianKDE(PPC).

My conclusion is that Amiga-to-Mac, and Mac-to-Amiga learning curves would likely be the easiest . . . . though the Win-to-KDE curve could well be almost as easy!
That said, I feel that Amigas and Macs would be easier to teach NEWBIES basic computer operations than most OTHER systems.

MOST computer-using workers are NOT taught more than a basic rudimentry concept past getting their work completed.

A VERY INTERESTING fact is that an Inbetween CLI/GUI Interface does (did) exist; that of the Canon Cat:
Jef Raskin, author of The Humane Interface, was its designer!
I am led to wonder if MANY systems' keyboards, other than that of the Amiga & the Mac, include a 'HELP' Key?

Re: Tristan (IP:
by drsmithy on Wed 10th Mar 2004 20:56 UTC

<i.GUIs are a lot better for presenting graphical information such as drawings or object relationships, and Windows Explorer is easier for copying files around than "cp", except for complex operations such as "copy all the .c files and no others"), though newbies won't find that too useful.[/i]

Uh, this is trivial in Explorer (and any other semi-decent GUI filemanager). Sort by type, shift- (or ctrl-)select files, drag to new location. Now, depending on exactly what you're doing and your existing config, it might take a bit _longer_ than doing it in a CLI, but it certainly isn't any _harder_.

My mother, a lawyer, uses WordPerfect specifically because it's the only WP which has the "reveal codes" feature, which shows the formatting codes directly in a text window and lets her edit them. It allows her to fix fouled up formatting in a document directly. Man, I wish Word had that... when things get fouled up in Word, one's only option is to live with it or start over.

Word has this feature (Format -> Reveal Formatting, Check Show all formatting marks) and has had it ever since I can remember (so at least Word 2ish for DOS). Heck, I can't imagine any remotely powerful wordprocessor *not* having this feature - I'd be surprised if even "consumer" apps like MS Works or Appleworks didn't have it.

CLI vs. GUI helpdesk..
by ondra on Wed 10th Mar 2004 22:57 UTC

Have you ever tried navigate somebody over the phone? CLI: Simple task: CLI: type 'mount /floppy' ok? Now type 'cp * /floppy'. Fine, now type 'umount /floppy' and eject the diskette.
GUI: Fina an Icon 'My computer'. Yes it is there. Over there on the top. Now double click the icon. Fine, now find an icon with diskette. There should be something like this, probably in the top-left part of the window. The window, you have just opened. Umm... have you double-clicked the 'My Computer'?? What do you see on your screen now? Ok, now we will have to get to the folder, where you store your documents.......

Even navigating somebody in 'vi' is easier ('press 'YY$Gp'), luckily most new gui programs feature keyboard short-cuts.

command line in GUI world
by bact' on Thu 11th Mar 2004 00:26 UTC

a graphic intensive program like AutoCAD still offers a "command line" interface to its users.
and many of them found that, the command line gives them more preciseness and it is quicker to work with in many cases (including routine work).

Re: ondra (IP:
by drsmithy on Thu 11th Mar 2004 01:29 UTC

Have you ever tried navigate somebody over the phone? CLI: Simple task: CLI: type 'mount /floppy' ok? Now type 'cp * /floppy'. Fine, now type 'umount /floppy' and eject the diskette.
GUI: Fina an Icon 'My computer'. Yes it is there. Over there on the top. Now double click the icon. Fine, now find an icon with diskette. There should be something like this, probably in the top-left part of the window. The window, you have just opened. Umm... have you double-clicked the 'My Computer'?? What do you see on your screen now? Ok, now we will have to get to the folder, where you store your documents.......

This happens because - for some reason I've never really understood - the way most people tend to be shown how to do things in the GUI is the longest and most tedious way possible.

For example, the quickest and easiest way to tell someone to open an Explorer window on their floppy drive is:

"Click on Start, click on Run, type in "A:", hit [enter]."

Yes, if someone's floppy drive is a letter other than A:, or they have two floppy drives, this might not work - but that's such an uncommon event that making *everyone else* do it the hard and slow way is just dumb.

Incidentally, the whole "CLI is easier because you can just tell people what to type" argument is rather specious, as anyone who has seen a user type in "peekay unzip filename dot zip" will attest.

Good Article
by JohnR on Fri 12th Mar 2004 22:39 UTC

I enjoyed your article a great deal. I think that it might not be a bad idea to start off newbies with a CLI because of the control factor. I cut my teeth on TRS-80 basic, and then MS-DOS, and by the time I started using Windows (kicking and screaming, I might add, ONLY because I wanted to use the cool typefaces available in Word), I had an excellent notion of what was going on "behind the curtain" of the GUI when I was using it.

To this day, the chief point of frustration of using Windows GUI's is the total disrespect the OS has for the user. Microsoft programmers think nothing of whisking away the "focus" from the user any time they see fit to inform them (sometimes understandably, sometimes not) of something that has occurred which may or may not have any bearing on the task the user was involved in. I could go on griping for hours in the vein, but no doubt the 90 predecessors have already covered this ground more than adequately.

The kind of hybrid I'd like to see is a permanent CLI at the bottom of the screen with an expandable window to show history, and another line or two for any sort of system messages (also expandable to show history) and a GUI with icons and so forth on top. Everything on the system should be equally accessible from icons or from the CLI, and ALL system and program messages should be restricted to the message window, showing the last message received, and requiring no acknowledgement to continue. It can ding if you're in danger of losing data from memory because of some failure, but that would be the extent of warning flags. But, hey, that's just me.