some comments picked up
Well, I'm an "old timer" who does _not_ appreciate the command line.
By "old timer" meaning, admittedly, not 60 years old and having
started on punched cards and electronic tubes.
I did, however, learn programming in hex, not even assembly, on a
ZX-80 with 1K RAM. In 1K you didn't even have space to run an
assembler. I had a big old paper notebook with 1 page per command and
a matrix of the registers involved. E.g., this is the page for "ADD",
take the column for "A" and the row for "B", and there you have the
hex code for "ADD A, B".
I continued through such mis-haps as editing source files on a CP/M
machine with a hex-based disk editor, because the PHB forgot to also
give us a text editor. Sad, but true.
You know what? I _don't_ miss those days.
The command line is powerful and all, as long as you already know
_exactly_ what you're doing. It is a pain in the donkey when you
don't.
The time and effort to get past that learning curve is not fun, and
not what Joe Average wants. Heck, it's not what _I_ want.
I do _not_ find it fun to spend hours digging through obsolete,
incomplete man pages just to find out that I need to type some obscure
command like "obscureProgram.sh -XFGXRmnq -i filename1 -o filename2 -c
OBSCURE_COMMAND_CODE -p some_obscure_regexp -f unix-style-font-name"
just to get something done. Bonus points if it expects me to already
be in some directory, and some obscure configs to already be set
right. More bonus points if it doesn't even do the whole job, but
expects me to pipe it through other obscure programs. Double bonus if
it outputs some cryptic error messages like "1962 Short School Bus",
that don't even tell me what the **** went wrong there.
Gimme a break. My time is too valuable to spend it on that kind of
crap.
Give me a GUI which has input fields for the stuff I need to enter. If
it's a file name, give me a good file selector dialog, don't expect me
to manually list directores 20 times to find it. If I'm supposed to
enter options, give me checkboxes, radio buttons, or drop down
combos. And, ffs, give me an up to date help for it. And clear,
humanly understandable error codes.
And you know what? I'm surprised how much energy goes into defending
the sacred right to produce crap code and piss-poor interfaces.
Here's an idea: if half the time that went into whining about how the
60's command line interfaces are better for the user, went instead
into throwing together a simple user-friendly TK or ncurses or
whatever GUI, we'd all be far better off than we are today.
And let me get back to the part where I've said "The command line is
powerful and all, as long as you already know _exactly_ what you're
doing. It is a pain in the donkey when you don't."
The problem there is that to get to know exactly what options to type
there, you have to invest ludicrious ammounts of time into that. Which
for most people isn't justified. If you'll configure printing on your
home network maybe 4 times in your whole life, consider the following
two situations:
1. spending 4 hours to learn how to do that with CUPS and only with
command line tools. But then you can do that in 30 seconds flat each
time.
2. spending 5 minutes each time doing the same in Windows, through the
GUI
Believe it or not, solution 1 is _not_ an improvement. On the whole,
the l33t Unix command line way took 4 hours from your life, while the
point-and-drool Windows way took a total of 20 minutes. The winner
is... the GUI.
Yearly millions of hours go into just learning to use some crap
software. It isn't learning some l33t skillz, it isn't "getting a
clue", it's just _wasted_. It's time when you're _not_ doing what you
needed to do in the first place. Time where, like in the example
above, instead of already having your file printed on that networked
printer, you're still searching through obsolete man pages and trying
stuff that fails for no obvious reason.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
purely anecdotally (Score:5, Insightful) by Transient0 (175617) on
Tuesday March 09, @08:16AM (#8508747) (http://frankduff.com/) It seems
to me that if you start someone on a command line versus starting them
on a GUI they learn a little slower but acquire a deeper understanding
of the computer.
point-and-click and drag-and-drop don't encourage any actual
understanding of ways in which a computer interprets commands. ---
lysergically yours [frankduff.com] [ Reply to This ] Re:purely
anecdotally (Score:5, Insightful) by Ubi_NL (313657) on Tuesday March 09, @08:23AM (#8508816) Don't
you nerds get it??
I don't WANT to understand how my computer operates internally, just
as much as I don't give a toss for how my car or my phone works.
I just want to type a friggin letter.
(This is not a troll, but to show that slashdotters are not really a
typical representation of the worlds population)
Spambots listen up: sales@sco.com mcbride@sco.com info@sco.com
sales@sco.com. Enjoy
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I understand your frustration, but also disagree with it. Allow me to
explain.
The concept you're bringing up is black boxing [wikipedia.org]: a
simple (or standardized) user-interface that hides a complex system.
The pros of black-boxing are obvious: black boxing makes it possible
for many people to operate complex equipment (think cars, phones,
computers). There is also a psychological factor at play here: as many
people seem to suffer from self-learned helplessness when dealing with
technology, black-boxing (e.g. think nice-and shiny i-POD, or
automatic-transmission lady-car) helps them to overcome their
physological aversion and acutally use the device.
Now, as already stated by another user, the main con of black-boxing
is what happens when something goes wrong: black-boxing provides a
very poor way of dealing with failure-conditions!. There is also
another con, which is public perception: black-boxing makes people
believe that the equipment they are operating is simple, while in
reality it's very complex. But because they reason from their internal
"simple make-believe model', they can make mistakes that they wouldn't
have made, had they known a bit more about the equipment.
To provide an example: Here in Europe, most cars are manual
transmission (typically 5 forward and 1 reverse). When driving 80 kph
in a flat country like holland, it really doesn't matter that much
whether you drive in 3rd gear of 5th gear. However, when some Dutch
people drive through Switzerland during the summer holidays (with a
big trailer behind the car), they persist in driving in 5th gear
up-hill, their argument being: "Hey, don't worry man, the car
maintains speed uphill, so what's the problem". Of course, had they
known a bit more about how an engine works, they would have switched
back to 4th (or even 3rd) gears, to allow the engine to run at a
higher specific torque, and to allow the cooling fluids to be pumped
around more quickly to cool the engine better. Our black-boxing people
usually end up overheating their engine (and blocking traffic and
creating big jams in the Alps, grumble! ;) You see: it pays to know at
least a bit about what's under the black cover of your black box!
In the same way, your shiny XP thingy makes your computer seem a
simple device. But of course, it is still a really complex
device. We've all seen people do stupid things because they persisted
in acting according to how they believed the computer works (their
simple model), rather than basing their actions on how the computer
actually works. Knowing a bit about the latter, however small, enables
you to do better in times of failure, but also in general.
On a personal account: I learned C after I learning assembly. I
experienced this as a big bonus, because after using asm, you know
what pointers actually are and how they work. I've seen people program
Java and doing stupid memory allocation things, because they had no
clue about what happens when you do "new bla" or "delete bla".
To conclude: black boxing is ok, but you need to keep in mind that you
are still operating a complex device!
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
But you think a command line would make using a digicam easier? A
microwave? A thermostat?
The computer as a non-specific device is a fundamentally flawed
(though useful) contraption. The command line, GUI, and other UI
creations are all hacks to help users get around the problem of
genericity of the machine.
As computers get more powerful and more 'intelligent', computer user
interfaces like these will wither away and something more
straightforward like controls for a camera, microwave, or thermostat
become the primary UI of the computer. This means that innovations in
computer operating system design must be made so that the OS can guess
what the user wants to do and present an appropriate, simple
interface.
I really look forward to the day when the concept of the PC
disappears.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In my experience, the command line is more consistent, especially if
you are telling someone to do something. Once you get into it, it just
a matter of saying "press A, then press ., then...."
With a GUI, there is a lot of hunting and squinting and guessing:
basically, the stuff is never in the same place and never looks the
same from one machine to the next.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Only for English speaking newbies (Score:5, Interesting) by poszi
(698272) on Tuesday March 09, @08:36AM (#8508916) I did some teaching
of command line for non-English-speaking students and the biggest
obstacle was the language barrier. They couldn't remember the command
and they didn't understand the output of the command. Even if they
knew some English, there were always some technical terms they
couldn't understand and they felt intimidated. This way they were much
more efficient in a localized GUI.
Save the bandwidth. Don't use sigs! [ Reply to This ] Re:Only for
English speaking newbies (Score:4, Insightful) by poszi (698272) on
Tuesday March 09, @09:33AM (#8509405) user@server:~/> cd /root
/root: Permiso denegado.
Yes. But the command itself is not localized ("cd = change
directory"). There is no localized command "zk = zmien katalog".
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
from my web log, I think it's appropriate and strangely enough,
quasi-religious...
We all strive to be big monolithic programs, with fancy buttons, big
memory footprints, environments where people, if they want to do
anything, must go through us. We strive to be pre-eminent on the
desktop, world stage. We crave fame. Look at me we say. Look how
important I have become. I am an Office Suite, hear me roar. Look how
much I can do. If you want to do any work, you must come through me.
[snip]
We must teach our brethren the ways of the Unix shell, for if we don't
we will forever be trapped handcuffed in that big shiny plastic bubble
of modern life, where we see but we can't interact. We must go back,
back to the beginning and learn the first lessons.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The pity is that GUI usability peaked sometime in the late eighties
and has declined since then, as the rise of "computer literacy" has
created an expectation that users will master complex UI's, and the
rise in computing power has removed any barriers to marketing-driven
featuritis.
The most telling point was the discussion of "discoverability."
"Discoverable: The interface must, from first switch on, provide a
clear direction for a new user to go. At each stage it should
encourage experimentation while providing adequate notice of important
or key features."
In the 1980s, GUIs were intentionally designed to facilitate
discoverability were far more "discoverable" than CLIs of the
day. They were also intended to be forgiving. The user was supposed to
feel empowered to try things, confident that there was always an
"undo" to bring them back. On the Mac in the 1980s, "Undo" was far
more prevalent and worked far more consistently than in today's
software, in which many operations commit you to something whose
effects you may not understand.
As for "dialog," UI designers understood that well. Why do you suppose
that what are now called "screens" were once called "dialog boxes?"
What the article is really saying is not that CLIs are better than
GUIs, but that a) modern UIs are not catering to the needs of the
average user, and that b) modern UIs have gotten so badly designed,
cluttered, and complex that they have become less usable to beginners
than CLIsbecause GUIs have deteriorated, while CLIs have benefitted
from benign neglect.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This is certainly a very interesting idea, and has good points to
it. I would hazard, however, that the CLI is most definitely not the
way to go to get new users up and running with computers. The author
is almost there in his article, but doesn't seem to make the leap...
Using the example that the author used, he says Tilly multitasks, but
doesn't do more than one thing at once. When she wants to leave
something for later, she puts it to one side. This is an almost exact
description of minimizing windows. It isn't suspending programs, or
moving them into the background, like UNIX. It's just putting what
you're doing out of the way for the moment.
Tilly goes to the grocers and tells him what she wants. Why not point
at what you want? I want my mail, click the big envelope. I want to
type something, click the Word icon.
It's arguable that some of the easiest programs that run in a terminal
are those that are like GUIs, just without the mouse. Pine is a
perfect example. It has labelled buttons at the bottom, except you
interact with them using your keyboard instead.
GUIs are still the best way of getting general users interacting with
computers, it's just certain elements of GUI design that scares them
witless. Working on a helpdesk for my University residential network,
I reguarly hear what could almost be called fear in a voice when a
dialog box or something pops up that I didn't expect, and warn the
user was going to happen. GUI design is very imperitive. Boxes appear
saying "DEAL WITH ME NOW" and giving themselves the utmost
importance. This is what scares people. They think that because
something took the time to alarm them in such a massive way, something
amazingly bad must be happening. These windows often pop-up from
applications that aren't being worked with. By preventing these,
everyone would be a lot happier. The Mozilla new mail notification is
an absolutely excellent way of telling the user something is
happening, it pops up in the corner, says there's some mail, and
disappears. It doesn't ding. It doesn't grab focus. It doesn't appear
in the middle. It just gives you a quiet hint.
GUIs are also far too ready to boot up programs of their own
accord. When users get notifications from something they didn't run
explicitly, they get the fear. CLI doesn't do that, it only shows you
output from things you've done.
The author says that users are scared to click buttons, in case of
something going wrong. But they feel that a CLI can't do any
harm. Users *do* want to point and click their way around buttons, and
GUIs do complain of something wrong in essentially the same way as
CLIs. Maybe it's because they have no visual feedback when they type
sudo rm -rf / ? I think it's just a residual fear from the constant
shouting that current GUIs do.
GUIs are currently too noisy, and the essential quietness are what
these users are responding to. I would hazard that as soon as the
users want to do something more difficult (that would need a pipe),
they'll be desparate for a GUI interface instead.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Note: This content originated from a different site, not related to sicnarf.com. For removal, incase of copyright violation, please contact me and provide some evidence against.
####
Back to Startpage