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.
Introduction
Around 2001 I spent some time working part-time at a local adult-education centre teaching CLAIT, a beginners computing course, to a wide variety of people. These were complete beginners; many had never turned on a machine before. It was as much an education to myself as it was to them.
The key thing to remember about these newbies that I taught is that they were not in any way stupid or slow. Many of them had mastered complex technical jobs and excelled in their chosen field. All these people felt that they were being left behind by IT and that there was some percieved intellectual barrier to entering the computer-enhanced world. This initial assumption on their part is key to the following discussion. These people are technophobic both in that they fear being left behind by the rapid advance of technology and that they fear the technology itself. The former fear is best addressed at the social level but the latter fear may have some justification based on their mental model of the world.
This essay describes some of the observations I made when giving some of the more advanced members tow brief session with a Linux session over SSH. A PuTTY window was made full screen and the users told that the computer was “now running in discussion mode”. No mention of alternate operating systems was made until the end of the trial. The users were given a brief talk at the beginning of each session and a ‘cheat-sheet’ of common commands. The advanced users were encouraged to work with each other while I spent time with the rest of the class.
A day in the life of Aunt Tillie
Human beings are simply not brought up to deal with the GUIs of modern day computing systems. Consider the level of training that used to be involved with teaching one worker how to correctly interpret and operate a single control panel on some machine. To master modern GUIs, one must recall the operation, layout and relation to each other of hundreds, if not thousands, of such panels. The hardest skill being recalling or discovering the correct sequence of operations on one control panel to access a control panel relating to a desired operation.
Compare this to modern day life. Such nested control panels are rare and single ones at least are uncommon (one example being ATMs). Instead, to discover the appropriate interface metaphor, we should consider one day in the life of the subject of many of Eric S. Raymond’s famous thought experiments, Aunt Tillie.
Aunt Tillie has spent all her life coping quite well without computers. She has, no doubt, had a high-flying intellectual job and now in her twilight years she has moved into retirement. Aunt Tillie is not stupid. She is perfectly capable of dealing with people, places and things that arise in her life.
A typical day for Aunt Tillie involves getting up, walking downstairs and checking for any post that may have been delivered. To do this she simply walks to the wicker box hanging under a slot in her door and opens it. She sees two envelopes and takes them to the breakfast table in the kitchen.
Being a typical English lady, she likes to start the day with a refreshing cuppa. Putting on the kettle to boil she sits down and opens the envelopes one-by-one reading the contents of each letter before opening the next. One is a letter from her nephew Eric letting her know that all is well in America and that he is enjoying himself. Aunt Tillie places the letter on the side-table to remind her to write a reply later in the day. The second is some circular advertising some credit card Aunt Tillie neither wants, nor needs. She opts to throw it in the bin.
By this point she realises that the kettle has boiled by the little click it made as it turned itself off. She goes to it and makes a nice cup of tea. Once she has finished her breakfast, Aunt Tillie sets off to do some shopping. Tillie always goes to the little corner grocer because she likes being able to talk about what products are on special offer and what she wants with the grocer. The conversations are usually restricted to fruit and veg but Tillie feels less intimidated talking to the grocer than having to go to the supermarket out of town and try to choose her shopping from the thousands of products on offer.
Once she has finished shopping she goes home and unpacks. She sees the letter from Eric in the kitchen and is reminded to write him a note. She does so and pops it next to the letter box in the hall to remind her to take it out to the post box tomorrow.
Features of Tillie’s mental model of the world
This is a natural day for most people and everyone is confident of how things in real life like letter boxes, kettles and grocers work. Let us try to extract some of the features about Tillie’s life that make her comfortable and attempt to match them to some user interface for a computer system. Firstly, Tillie doesn’t do more than one thing at a time. Certainly she ‘multitasks’, putting the kettle on while reading mail for example, but her attention is focused in one place at any one time. The indication to Tillie that the kettle has boiled is unobtrusive and effective but she defers dealing with it until after she has read her letters.
Another feature of Tillie’s life is known locations for known things. Letters have a certain place when they should be replied to and when they should be sent. Tillie does these things at different times during the day.
Finally we notice the importance of dialogue in her life, both implicit and explicit. Tillie has an implicit dialogue with the letter box, opening and looking for letters is equivalent to asking the box ‘Have you any letters’ and it replying, in this case, ‘Yes, two’. Tillie has explicit dialogue with the grocer while retrieving information about today’s products. Tillie’s life is rarely control panel driven. We don’t see Tillie ticking items on a list of products in the grocers and giving it to the grocer. We don’t see Tillie having to locate the open door button, navigate to the destination panel in her garden and remembering if she has to type ‘grocers’ or ‘grocer’ to get to the right place.
Throughout the entire day there is an implicit element of discoverability, be it road signs at the appropriate places, notices placed prominently or things in expected or known places. This feature of day-to-day life is often one we overlook but it becomes painfully clear when we are placed in an environment which is not readily discoverable, such as a foreign country with unreadable notices and signs, or one which is unexpected, again a different culture provides different norms of behaviour to which we are not used. One could consider a newbie a tourist in the land of the computer. We must remember the neither know the language or the culture.
Application of Tillie’s model to user interfaces
Before discussing a computer interface for Tillie, we need to find out why she is using a computer. She has heard that computers can make her life easier and quicker. She has heard she could communicate with Eric without paying international postage. Someone told her that she could get groceries delivered to her door using something called ‘online’. Basically she wants to see if she can do broadly the same tasks she does every day but quicker and easier. Tillie is not a gamer, a power-user or a hacker. She wants an interface that assumes you will be using the computer as much like a domestic servant as like a tool. We may assume that some knowledgeable user has initially set up her machine and Internet connection since Tillie will use the computer much like her washing machine, dishwasher and cooker. All of them are appliances installed, connected and tested by a qualified Engineer.
We may now design an interface for Tillie to allow her to move some of her daily tasks to the computer. Referring to the previous section we can specify the desirable properties of a hypothetical ‘perfect’ computer interface from the point of view of mapping easily onto Tillie’s existing model of the world:
- Dialogue
- Tillie is used to having dialogues with things or people. Such dialogues make her feel in control of what is happening and puts her at her ease.
Like most humans she (perhaps somewhat unfairly) feels happier when she perceives herself to be the most intelligent or knowledgeable person in the dialogue. - Tasks
- At any one time, Tillie’s attention is focused on one particular task. Other tasks may be progressing in the background but Tillie need not have to give them her attention until she wants to.
- Discoverable
- The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features.
- Locations
- Different task elements or objects have a place or method of access that is either well known or readily discoverable. Related tasks should be in nearby places. Tasks are related both by similarity and by concurrency; the letter to
send is placed near the door so that Tillie sees it when exiting the house. - Appropriate Notifications
- When tasks wish to inform Tillie of an event, the
notification level should match the importance of the event. The kettle boiling is a small audible click, the fire alarm is a constant loud ringing. Tillie may choose to ignore any of these without interrupting her task but is aware of the relative risks in each case.
The Command line – a ‘perfect’ solution?
In the remainder of this essay I will discuss why I believe that a command line interface (CLI) similar to that found in Unix and Unix-like operating systems is a surprisingly good match for Tillie. I will use some examples from the trial I conducted. I shall also describe how the existing Unix-like interface matches and extensions which could make it even better for Tillie. I’ll discuss each of the desirable properties above individually.
Dialogue
The command line is all about dialogue. Newbies communicate with the computer by giving it commands/asking it questions and reading the response. All interaction is done via the keyboard, something familiar to the users in the CLAIT class, often from their experience of typewriters. One can give the users the mental model of writing the computer notes, or talking to it via Instant Message (depending on the experience of the newbie, quite a few middle aged newbies were familiar with MSN).
The mouse was avoided initially. The command line is one-dimensional with a single point of concentration: the cursor. The vertical axis of the screen is always time and provides the newbie with a constant reminder of what they did along with a record to show their instructor when they have problems. Introducing a mouse causes the vertical axis to be both time and space depending on the nature of the program running. Also the users must get used to using a mouse, not easy for a new user let me assure you.
Users find the model of CLI dialogue with the computer natural. Indeed one user has, when instructed in the basics of the Unix command line, said “Oh I see! I talk to the computer in text [speak]” referring to the common practise of removing vowels from SMS messages sent to and from mobile phones, especially in the UK. Once she had noticed this, she progressed rapidly in remembering the command names now pronouncing commands like ‘mkdir‘ as ‘muk-dear’ as opposed to ’em-kay-dee-eye-ah’.
Experience with the CLAIT class above showed two things about the CLI method. One was that it mapped very naturally onto existing models for interaction. Users very quickly picked up on the ‘<verb> <subject>’ syntax for commands and found it very useful. The second, most important, thing was that users reported that they felt more ‘in control’ with the CLI.
This should possibly be discussed further. It was explained to the users that computers were stupid and would only do as you told them. They understood a special restricted form of language “as if you were talking to a child”. “Much like children,” it was said, “they should be told specifically what to do and if they don’t understand they will ask for more detail”. Users were assured that no effect they could have on the computer by typing could harm the PCs and that any accidental “removals” of files could be repaired.
With this knowledge in place, the users immediately felt more in control as they perceived themselves as more intelligent, having to phrase their request in simple enough terms for the computer. This was opposed to their experiences with GUIs where they were the ones that felt like children pushing buttons at random on control panels. Since they were afraid that pushing the wrong button could cause disaster they were less inclined to experiment. With the CLI they could experiment secure in the knowledge that if the computer didn’t understand, it would complain.
This superior attitude encouraged experimentation because it gave the users the impression that they would actually have to state specifically how to break the computer if they were to make the machine do something wrong, something they were confident they were unlikely to do.
Tasks
It was noted by the users that the CLI was less confusing because “not everything is on the screen at once”. The CLI allows the user to concentrate on one task at a time and they were happy not to have interruptions from other tasks. The users reported that with a GUI they were always getting distracted by having to swap between the mouse and keyboard and click carefully less they bring up the wrong window and interrupt what they were doing.
Some users asked if it were possible to make the computer do some tasks “without waiting for them to be done”. These users were introduced to the job control features of the bash shell. Here a small script was written by myself called ‘inbg‘ which was functionally equivalent to the ampersand (&) modifier in bash. It is worth noting that the user who made the “text speak” remark immediately started pronouncing this “in background”. The users were initially confused by the termination messages given by bash when a background task terminated but once it was explained that this was the computer saying that it had finished the task they found it very useful.
At this point the users started to diverge between those who wanted their finish notifications to be printed as soon as the task finished and those that liked the way “the computer waited for me to finish what I was doing before telling me”. This will be discussed further in the section dealing with extensions.
Discoverable
This was the most pleasing part of the trial. Here the users were instructed that they could get help on a particular command with the ‘man’ command and were given a brief description of how to read them. They particularly liked the clear, consistent layout and references to other useful commands. Many users went ‘man-page surfing’ by looking at interestingly named commands referenced in other man pages. This increased their knowledge of the commands immensely.
A message of the day was set up informing the users that the command “man commands” would get them a list of commands to get started with. An appropriate man page was written with a list of useful file access, modification and documentation commands along with information on how to move up and down in the file and to “get back to the discussion” (exit the man page reader and return to the command prompt). This was an important bootstrapping step as it got the users over the ‘what-do-I-do-now’ question when first confronted with the machine.
Users were encouraged to maintain a list of interesting commands using the pico editor in their “personal space” (home directory, see ‘Locations’). A brief competition arose between the users for who could find the “coolest” command. This also encouraged users to explore the system. All users reported that they found the pico editor easier to use than Word or Notepad because “it just tells you what to press”. It is worth noting that earlier in their teaching they had been informed of the Control+key method of accessing menu options and the caret (^) notation. If I had been more brave perhaps some variant of the vi editor with its two modes would have been better — remember secretaries used to use it in AT&T to type patent applications.
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. I suspect the wide-use of shortened mnemonic words in “text speak” helped here.
Finally, all users were given a “rule of thumb” that often if they forgot how a command worked, the option ‘–help’ or ‘-h’ would print out a mini manual. The users were also very happy when told about Tab-complete. Especially the ability of bash to list all possible completions. Users reported that this was really useful when they forgot how to spell a command. One likened it to looking a word up in a dictionary where you know how is starts but forget some spelling in the middle.
Locations
Users were at first unsure of a hierarchical file system. They all seemed to adopt the room and mentality for file access. They understood the concept of a “file” as a name of a box where the computer will store some data which is placed in their personal “room” but directories proved a difficult concept for them to handle.
One user grasped the concept rather early on and usefully described it to the others as “a box with other boxes in”. He nicely demonstrated it by showing them he had created a “Remember box” with files inside outlining things he had to do. He illustrated how he could “look in the box” to remember what he had to do and could “open one of the boxes inside with pico” to remind himself of the details. This is something akin to Tillie placing letters near the door to remind her to post them; if you put things to remember in a single place then you only need remember where to look.
When asked if the user did this at home he replied that he didn’t because he never sees any “boxes” unless he opens “My Computer” and he would have to remember to do that every time he switched the machine on. He said that the “discussion mode [was] better because [he kept] seeing the Remember box as [he did] things”.
A small addition was made to the user’s .login file which listed the contents of the Remember directory on login. The user was very pleased with this. The user asked how I had done it and I pointed him to the file. I said “this box holds a list of commands for the computer to do when you first turn it on”. He was extremely excited by this new toy and the rest of the users quickly customised their own files to print out various messages and perform various tasks.
It was pointed out that GUIs often have features to allow them to perform actions on login but the users were unaware of this. The couldn’t visualise how to configure it because “you can’t just tell the computer to click the right buttons in a file”.
Appropriate Notifications
For the second brief session users were set up with mail accounts which could send messages to other users of the system. Their familiarity with pico lead me to attempt to use pine as their email client. This went well although users complained that they had lost some of the discussion ability. They asked if there was some program that could read mail “by discussion”. Time constraints meant I avoided attempting to teach them old-school Unix mail but I suggested they read the man page. By this point the users had come to enjoy the command line interface because they “always know whats going on” as opposed to GUI or GUI-like interfaces where “everything happens at once”.
The e-mail system is easy for users to accept as it is has a direct analogy to the usual postage system. One interesting thing that I saw a few users do independently is to save important e-mails into their Remember directories. This strongly showed the importance of a known location for different classes of object in the interface. The culture of human-readable files in Unix helped here a lot because the users got used to just opening the Remember files in pico to check what to do.
The bash shell has the option to inform users of the presence of new mail in a similar manner to how it notifies users of task termination. Again the users split into those who liked it that way and those who wanted to know immediately.
All users preferred the bash notification to the alert box style used in GUIs. The users seemed to dislike sudden unexpected interruptions of what they were doing, preferring the computer to ask for clarification or repetition in its reply. Indeed many users said they were actually frightened when an alert box appeared.
The large number of times the alert box was for some small, unimportant thing also annoyed users leading to the habit of just clicking ‘OK’ to get rid of them. The users reported that they often didn’t read the alert boxes but always read notices on the command line because “they don’t interrupt what you are doing”.
Conclusions
So what can we conclude from these experiments? Certainly the CLI had many advantages to the GUI in terms of the important areas I identified. The CLI had certain drawbacks to the GUI however which were reported by the users. Chiefly was the lack of any graphics or pictures. Should time and resource have allowed I would have liked to test the users with the graphics enabled version of the links web-browser to see if the hybrid CLI/GUI it provides would be better.
All users, after an initial bootstrapping phase, preferred the CLI “discussion” method for interacting. All reported that they felt more in control and better able to find things out. This probably was due to the higher amount of interface consistency and more task-based interface that the CLI tends to encourage.
It is far easier for programmers, naturally task based people, to code a useful, easy CLI program than a GUI. GUIs take more work to code than standard command line option processing and this is often reflected in the relative quality of interface between them. CLI options force the programmer into a more restrictive interface which is actually good for the newbie. Also the barrier to providing self-documenting discoverable programs is smaller. Documentation for each option is, in many cases, written as a side-effect of implementing the command processing.
Extensions
That being said, there is room for improvement in the CLI. A general notification system would be useful, much like bash‘s mail and task notification system whereby background tasks could communicate events to users without interrupting their flow. Such a system would present the notifications either when the current command terminates like bash currently does or in some ‘status area’ of the terminal display, probably based on user preference.
Perhaps these things could be combined into a new shell. One that also had a more unified method of job control, perhaps introducing ‘inbg‘ as a built in function.
The trial also highlighted the need for a ‘bootstrapping’ step in the CLI to provide new users with a command or list of commands they can use to get started. The hypertext-like nature of man pages also encouraged discoverability by referencing other commands for the users to investigate. Perhaps some search command for man pages would be useful here (not apropos, that has never produced sensible answer for me).
For the future
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. I feel that my experiences here show that the CLI provides a far better environment for first-time computer users to find their feet. I believe it also gives them a better idea of what is actually happening inside their computer.
Subsequently many of the users in the trial contacted me with questions of how to get their computers at home into discussion mode. It appeared that while, in the space of two sessions, they had become quite the CLI power-user they were still struggling with the GUI. At that time the Mandrake Linux distribution seemed a useful suggestion and I burnt a few CDs to take into the next class. What became of these after they left I don’t know. I hope that at least one is still a CLI power-user.
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”.
Please note that I made very few notes during these trials and they were a couple of years ago. They were never expected to be particularly scientific so please note that your newbies may vary. However the conclusions I draw here are the same ones I drew at the time and I would expect a similar trial to give similar results today.
About the Author
Rich Wareham is a 2nd year PhD student in the Signal Processing Group of
the Cambridge University Engineering Department. When not playing with Geometric Algebra and proving theorems he enjoys learning about technology, experimenting with new Unix technologies and teaching undergraduates about Software Engineering.
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 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.
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.
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.
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)
Using command lines to play video-games.
))))))
umm…I take it you never played games on DOS like say….DOOM or Wolfenstein 3d, etc.
>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.
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.
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.
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.
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…
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.
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.
In my last post, I typed “want to type or / in a pathname depending” but the backslash didn’t appear.
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:)
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 -_-“
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…
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.
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 192.168.0.30
uptime
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.
RE: DOOM?
“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.
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.
Conclusion:
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.
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
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.
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.
[snip]”
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).
These http://www.applefritter.com/ui/aux/images/cmdo-ls.gif“>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”.)
http://www.applefritter.com/ui/aux/index.html
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).
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?)
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).
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…
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.
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.
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 free-form…you 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 buttons…it 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 device…it’s not as useful as a simple pen, nor featured as a keyboard…it’s hard to do anything USEFUL with it. You can’t even write your name easily!!
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…
“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?
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.
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’
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.
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 ftp://ftp.aw.com/cseng/authors/finkel/apld/ )
“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.
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?
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.
>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.
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.
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?
david
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 !
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, 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.
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).
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.
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.
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.
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.
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.
“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?
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.
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.
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.
The best discussion mode email program would be ‘mh’, where all of the email commands are broken out into little stand alone programs.
@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.
Just put a set -b in your .login, or type it at the the command prompt.
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?
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!
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…
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.
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 7…..it’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.
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.
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 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”
xyzzy
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.
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.
“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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I would recommed that the author look at cygwin http://www.cygwin.com 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:
http://www.digibarn.com/collections/systems/canon-cat/page_01.htm
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?
<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.
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.
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).
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.
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.