This is definitely the wrong crowed to present following facts, but I feel it might enrich the conversation.
<Quote>
...but I’ve seldom heard a usability expert end a discourse on human
factors by acknowledging that graphical systems are only really
the “best” solution for a certain group of people or a particular
set of tasks. Most take the graphical desktop as ground truth –
it’s just the way we do things.
</Quote>
The Human brain has estimated 2 billions nerves in the V1 & V2 region. Those regions are responsible for rudimentary visual recognition, of objects with different: Form (grouping, orientation, size), Color, Motion, Spatial position. This is one of the most powerful parallel computational systems known to men. It takes humans about 10 milliseconds to recognize an object standing out in those respects (e.g. gray text and one red word).
Why am I putting this down? / What are GUI's good for:
scan 1.3 million pixels (1280*1024 screen)
ignore all text fields
find all buttons
identify a symbolic representation of the task at hand (e.g. save)
The whole thing took ~40 milliseconds and most importantly: it is a task done so fast and effortlessly by the human brain, that we don't even think about it.
Humans are visual animals, GUI's are a result of our evolutionary history.
I am not stating that GUI's are the fastest way to get the job done. You still have to move the mouse, etc. A skilled Command Line user can get the job done without a 40 milliseconds delay and moving the mouse might take longer than typing the command. However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
Graying a button out, making it red, green,... gives the skilled UX designer the ability to convey a lot of information without making people think.
Then why do I spend many seconds trying to find certain buttons that are right in front of me ("Where the hell did that ordered list button go?") and even longer trying to find buttons that aren't even there?
Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
It's not quite right to imply that because a command line isn't graphical it isn't using human visual recognition - we still see CLIs.
We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.
Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.
> […] gives the skilled UX designer the ability to convey a lot of information without making people think.
What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term.
More specifically, a GUI environment may be easy to manipulate at first, but if you need anything odd (but dead simple), then you have to find a program to do it for you, or do without it. The CLI, on the other hand, by forcing you to write your commands (suboptimal in the short term), gives you the idea that maybe, just maybe, you could write those 2 or 3 commands in a file so you don't have to type them every time. The next thing you know, you want to automate everything. And you can.
Even more specifically, take me. I use a laptop under Gnu/Linux (for serious work), and a Desktop under Windows (mainly for games and videos). I often download English subtitles for English or American films (I'm not a native speaker). But those subtitles often comes with annotations between brackets for the deaf (things like [Predator growling], [wind blowing]…). I want to get rid of them. That would be one line of sed… But it's for films, and therefore on my Windows desktop. Migrating it to my laptop is tedious, so I haven't written the damn script yet.
Use of a computer shouldn't be a visual experience for most tasks. You have a mental model of what's going on, and then poke stuff to verify the model and to affect state.
> However, teaching the average person to use a new
> piece of software is near impossible without
> utilizing their incredible brain power for visual
> recognition.
This is a good point. Visual recognition helps with the first hurdle of learning.
But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.
There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.
> Humans are visual animals, GUI's are a result of our evolutionary history.
Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.
And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.
But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.
And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.
> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.
But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.
it is a task done so fast and effortlessly by the human brain, that we don't even think about it.
It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.
teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition
This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.
BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.
Being able to script a program is amazingly powerful, but I find the reason I like terminal-based programs is primarily due to the interface. The interface of a terminal program (both command-line and interactive) is the keyboard, which is a vastly superior input mechanism than the mouse for most things.
Any thought that goes into the interface of a terminal-based program goes toward the keyboard interaction; there isn't a GUI to think about. Because of this, terminal-based interfaces are usually much better than any graphical application.
As someone with a severe visual impairment, I use the command line as much as possible. It's easier to see and there is less I need to see. If I can type a command instead of having to hunt for a button, it means I can work that much faster and anything I'm looking at will be text, uncluttered, and high contrast.
From the command line, I can navigate the filesystem, install software, search, edit text, download files, play music, and send email all without even looking at the monitor. Once you're comfortable with it, you can just close your eyes and let your brain and your fingers do all of the work.
The fundamental part of this isn't the CLI/GUI conflict, IMO, it's this paragraph:
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
I suppose this is what Apple had in mind with their object-oriented, drag-and-drop philosophy for the Mac: a GUI which would allow people to pipe things visually with as much ease as possible, reaching a compromise between the UNIX philosophy and their notion of software design as making things "magic."
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
> When Ronald Reagan was a radio announcer, he used to call baseball games by reading the terse descriptions that trickled in over the telegraph wire and were printed out on a paper tape. He would sit there, all by himself in a padded room with a microphone, and the paper tape would eke out of the machine and crawl over the palm of his hand printed with cryptic abbreviations. (...) His listeners, many of whom presumably thought that Reagan was actually at the ballpark watching the game, would reconstruct the scene in their minds according to his descriptions.
> This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
Last year I decided to get back to basics and to dive into using emacs for as many things as possible. It's been extremely difficult and disorienting at times, but it has a non-quantifiable "feels right" quality to it.
I now find myself trying to do as many things as possible in emacs, but emacs + terminal + browser is extremely powerful. I'm not yet to the point of running a shell (elisp shell or otherwise) in emacs, but this troika is very powerful, and I'm extremely happy with it.
You'll also like this little bit I yanked from my .inputrc:
# By default up/down are bound to previous-history and next-history,
# respectively. The following does the same but gives the extra functionality
# where if you type any text (or more accurately, if there is any text between
# the start of the line and the cursor), the subset of the history starting with
# that text is searched.
"\C-p": history-search-backward
"\C-n": history-search-forward
I've found myself using console applications more and more recently. The only GUI applications I use out of necessity are Firefox, Keepass and VirtualBox. I use the console for everything else: Cmus for music, Newsbeuter for news feeds and podcasts, TaskWarrior for to-do management, Vim for coding, etc. The Ratpoison window manager helps me make the most of screen space and allows me to manage my windows with keyboard commands like GNU Screen.
Unfortunately, I've never found an email client I liked, whether console or GUI, so I just stick to Fastmail's web interface.
That's me right here. I love Ratpoison, although I think Evilwm is really good as well.
I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).
VirtualBox does have a command line interface. You can start up headless images and such pretty easily. You could even start images with a VNC server, and control the machine from your browser. One less visual tool.
The key advantages of a command line tool over a gui are power and flexibility.
There's any number of ways I can find and filter files using the find command, and then with xargs I can pipe them all through a sequence of simple operations.
In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite.
Often we consider the command line to be for expert users, and consider it our job as system designers to hide it from the rest. But when you consider that most people are able to learn basic calculus at school, a skill that has practical use in real life in only a limited number of professions, why don't we teach people to use the gnu tools at school? A skill that would enable them to use computers in powerful ways for the rest of their lives?
"... In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite."
whilst i certainly agree with this, i would speculate that 80-90% of the average user's time is spent carrying out a handful of simple operations that are better catered for by guis. for the other 10-20% we have our virtually infinite space: the shell.
The biggest issue I have with the text-manipulation capabilities of the CLI is the inability to select text in the prompt with the keyboard. Shift+navigation buttons is standard to do this in GUI text boxes, but the CLI's slightly different notion of the cursor (box v. line caret) comes with the inability to select text keyboardly. How do others solve this problem? Are there e.g. readline replacements that have this capability?
This is why X allows you to copy text by highlighting it, and to paste text by middle clicking. The problem was solved a long time ago. Just grab the mouse and stop being a keyboard elitist.
Besides using yank/paste keyboard shortcuts, you can always use screen or tmux copy mode. If you need the output of a command sent to the clipboard, there's several ways, xclip is one of them.
"I find the CLI to be faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible ... that’s a bold series of claims"
besides "easier to understand" (which depends on an individual's experience and knowledge) I thought those were pretty much acknowledged / obvious. Not bold at all.
When I am using a Unix based system, there are three graphical programs that I use: X11, Firefox, and Feh. Everything else I do can be accomplished inside of a Xterm.
Unless you keep the app open all the time (I’m assuming you do that because you have the focus of a guided missile), this is a program that you open and close several times a day. So why, oh why, does it take so much time to load?
This is why, even though I disagree with many of the things Apple is doing with the OS, I think Apple is on the right track with the app lifecycle model with Lion. Most computers ship with far more memory than people actually use these days; why should you constantly open and close apps when you can just leave them resident?
Most of the reason people even bother closing apps anymore has less to do with the resource-juggling that made it necessary in the past, and far more to do with workflow and window management.
A pure CLI is an arbitrary constraint on program design. CLIs and GUIs are not adversaries or mutually exclusive.
I see no evidence that designers are opposed to command interfaces given that many of the graphical programs I use incorporate them where appropriate.
The world isn't black and white. GUIs can be fast and pointing can be faster than typing. In other cases, a written command is fastest way to get exactly what you want.
Keyboard is ideal for entering data, but GUI is superior to console for data output and visualization.
It would be perfect solution if all OS/applications would have command line but with visual output. Instead of "menu" at the top, just command line.
There some good modern approaches to this problem, for example gleeBox for control of internet browser is nice way of integration of console style control to GUI application.
I never got into using mh, but have experienced a similar inversion when I switched to mpd, where what was a monolithic interface for playing music was replaced with a broad set of tools that center around the command line. It's exhilarating to enter that kind of environment, I found myself writing dozens of little utilities to control mpd in short order.
Personally, I use R. Importing and exporting CSV files in R is trivially easy (it's what it's made for, after all). Doing transformations on an entire column or row at a time is also very simple.
Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.
I do all the things one might use a spreadsheet for in awk :-).
One might say it's slower then a spreadsheet. I don't know. I can type an one liner awk summation/average, faster then it takes OpenOffice to load. This is to me the most common spreadsheet operation.
For more complex task, I feel that I'm working faster in awk (it's a full blown high level programming language, after all). I'm not sure it it's actually faster or if it's only my opinion though.
I end up using Python. In the end it's much more powerful and less error-prone (the oops factor of spreadsheet apps is ginormous). Quality plot, graph and stat modules abound.
Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.
Tangentially related to post. Don Norman's essay on how command lines are better suited in a graphical world for various reasons. (of course a lot of us here feel this here already).
Every now and then I have similar complaints, but I don't think it boils down to cli vs. gui - the situation is actually far worse.
Building high quality productivity tools that are able to exceed the expectations of expert users is both difficult and time consuming... and there is almost zero market incentive to accomplish the task properly for consumer-class applications.
[edit] this is not to imply that consumer apps are trivial -- I think I once saw Minsky discuss an early attempt at AI that started by interpreting children's books, thinking that would be easier than understanding journal publications, etc. -- it quickly became clear that the task of parsing a children's story requires an immense store of implicit context and as such, was completely intractable at the time. The challenge of writing 'simple' things like email, text editing, and spreadsheet apps seems related to that.
[+] [-] emanuer|14 years ago|reply
<Quote>
</Quote>The Human brain has estimated 2 billions nerves in the V1 & V2 region. Those regions are responsible for rudimentary visual recognition, of objects with different: Form (grouping, orientation, size), Color, Motion, Spatial position. This is one of the most powerful parallel computational systems known to men. It takes humans about 10 milliseconds to recognize an object standing out in those respects (e.g. gray text and one red word).
Why am I putting this down? / What are GUI's good for:
The whole thing took ~40 milliseconds and most importantly: it is a task done so fast and effortlessly by the human brain, that we don't even think about it.Humans are visual animals, GUI's are a result of our evolutionary history.
I am not stating that GUI's are the fastest way to get the job done. You still have to move the mouse, etc. A skilled Command Line user can get the job done without a 40 milliseconds delay and moving the mouse might take longer than typing the command. However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
Graying a button out, making it red, green,... gives the skilled UX designer the ability to convey a lot of information without making people think.
[+] [-] planckscnst|14 years ago|reply
Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
[+] [-] jodrellblank|14 years ago|reply
We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.
Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.
[+] [-] loup-vaillant|14 years ago|reply
What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term.
More specifically, a GUI environment may be easy to manipulate at first, but if you need anything odd (but dead simple), then you have to find a program to do it for you, or do without it. The CLI, on the other hand, by forcing you to write your commands (suboptimal in the short term), gives you the idea that maybe, just maybe, you could write those 2 or 3 commands in a file so you don't have to type them every time. The next thing you know, you want to automate everything. And you can.
Even more specifically, take me. I use a laptop under Gnu/Linux (for serious work), and a Desktop under Windows (mainly for games and videos). I often download English subtitles for English or American films (I'm not a native speaker). But those subtitles often comes with annotations between brackets for the deaf (things like [Predator growling], [wind blowing]…). I want to get rid of them. That would be one line of sed… But it's for films, and therefore on my Windows desktop. Migrating it to my laptop is tedious, so I haven't written the damn script yet.
[+] [-] cturner|14 years ago|reply
But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.
There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.
[+] [-] Goladus|14 years ago|reply
Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.
And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.
But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.
And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.
> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.
But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.
[+] [-] tygorius|14 years ago|reply
It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.
teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition
This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.
BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.
[+] [-] planckscnst|14 years ago|reply
Any thought that goes into the interface of a terminal-based program goes toward the keyboard interaction; there isn't a GUI to think about. Because of this, terminal-based interfaces are usually much better than any graphical application.
[+] [-] kellishaver|14 years ago|reply
From the command line, I can navigate the filesystem, install software, search, edit text, download files, play music, and send email all without even looking at the monitor. Once you're comfortable with it, you can just close your eyes and let your brain and your fingers do all of the work.
[+] [-] zdw|14 years ago|reply
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
[+] [-] palish|14 years ago|reply
And that, my friend, is modern day integration between gVim and GMail on Windows.
[+] [-] rufibarbatus|14 years ago|reply
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] kqr2|14 years ago|reply
In the Beginning was the Command Line
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.sht...
[+] [-] ysangkok|14 years ago|reply
> This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
[+] [-] craftsman|14 years ago|reply
I now find myself trying to do as many things as possible in emacs, but emacs + terminal + browser is extremely powerful. I'm not yet to the point of running a shell (elisp shell or otherwise) in emacs, but this troika is very powerful, and I'm extremely happy with it.
[+] [-] rimmjob|14 years ago|reply
[+] [-] zobzu|14 years ago|reply
Sent from my VIM.
[+] [-] mise|14 years ago|reply
[+] [-] ordinary|14 years ago|reply
[+] [-] Auguste|14 years ago|reply
Unfortunately, I've never found an email client I liked, whether console or GUI, so I just stick to Fastmail's web interface.
[+] [-] RexRollman|14 years ago|reply
I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).
[+] [-] joelhaasnoot|14 years ago|reply
[+] [-] justinhj|14 years ago|reply
There's any number of ways I can find and filter files using the find command, and then with xargs I can pipe them all through a sequence of simple operations.
In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite.
Often we consider the command line to be for expert users, and consider it our job as system designers to hide it from the rest. But when you consider that most people are able to learn basic calculus at school, a skill that has practical use in real life in only a limited number of professions, why don't we teach people to use the gnu tools at school? A skill that would enable them to use computers in powerful ways for the rest of their lives?
[+] [-] richardk|14 years ago|reply
whilst i certainly agree with this, i would speculate that 80-90% of the average user's time is spent carrying out a handful of simple operations that are better catered for by guis. for the other 10-20% we have our virtually infinite space: the shell.
[+] [-] william42|14 years ago|reply
[+] [-] gue5t|14 years ago|reply
[+] [-] j-kidd|14 years ago|reply
[+] [-] dredmorbius|14 years ago|reply
I map 'xc' to 'xclip' and 'xp' to 'xclip -o' (paste) with shell scripts.
Copy to/from clipboard via pipes.
Though X11 copy/paste works pretty well also. There are the odd occasions where a mouse is the right tool for the job.
[+] [-] slug|14 years ago|reply
[+] [-] njharman|14 years ago|reply
besides "easier to understand" (which depends on an individual's experience and knowledge) I thought those were pretty much acknowledged / obvious. Not bold at all.
no?
[+] [-] RexRollman|14 years ago|reply
[+] [-] pyre|14 years ago|reply
[+] [-] commandar|14 years ago|reply
This is why, even though I disagree with many of the things Apple is doing with the OS, I think Apple is on the right track with the app lifecycle model with Lion. Most computers ship with far more memory than people actually use these days; why should you constantly open and close apps when you can just leave them resident?
Most of the reason people even bother closing apps anymore has less to do with the resource-juggling that made it necessary in the past, and far more to do with workflow and window management.
[+] [-] shuwu83|14 years ago|reply
I see no evidence that designers are opposed to command interfaces given that many of the graphical programs I use incorporate them where appropriate.
The world isn't black and white. GUIs can be fast and pointing can be faster than typing. In other cases, a written command is fastest way to get exactly what you want.
[+] [-] jiri|14 years ago|reply
It would be perfect solution if all OS/applications would have command line but with visual output. Instead of "menu" at the top, just command line.
There some good modern approaches to this problem, for example gleeBox for control of internet browser is nice way of integration of console style control to GUI application.
[+] [-] joeyh|14 years ago|reply
[+] [-] danohuiginn|14 years ago|reply
Otherwise, terminal + browser gets me through 90% of the day.
[+] [-] chimeracoder|14 years ago|reply
Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.
[+] [-] 4ad|14 years ago|reply
One might say it's slower then a spreadsheet. I don't know. I can type an one liner awk summation/average, faster then it takes OpenOffice to load. This is to me the most common spreadsheet operation.
For more complex task, I feel that I'm working faster in awk (it's a full blown high level programming language, after all). I'm not sure it it's actually faster or if it's only my opinion though.
I'm happy with this setup.
[+] [-] keeperofdakeys|14 years ago|reply
[+] [-] icebraining|14 years ago|reply
[1]: http://www.gnu.org/software/oleo/ [2]: http://www.syntax-k.de/projekte/teapot/
[+] [-] lloeki|14 years ago|reply
Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] m0hit|14 years ago|reply
http://www.jnd.org/dn.mss/ui_breakthrough-command_line_inter...
[+] [-] enneff|14 years ago|reply
A real CLI warrior uses sh, ed, and mail. :-)
[+] [-] sgerrand|14 years ago|reply
* http://www.pbm.com/~lindahl/mel.html
* http://xkcd.com/378/
[+] [-] rch|14 years ago|reply
Building high quality productivity tools that are able to exceed the expectations of expert users is both difficult and time consuming... and there is almost zero market incentive to accomplish the task properly for consumer-class applications.
[edit] this is not to imply that consumer apps are trivial -- I think I once saw Minsky discuss an early attempt at AI that started by interpreting children's books, thinking that would be easier than understanding journal publications, etc. -- it quickly became clear that the task of parsing a children's story requires an immense store of implicit context and as such, was completely intractable at the time. The challenge of writing 'simple' things like email, text editing, and spreadsheet apps seems related to that.