Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Metaphors make the operating system (NewsForge)
Here's a NewsForge article by Lee Schlesinger, in which he dissects Neal
Stephenson's 1999 essay "In the Beginning was the Command Line".
"This is a key lesson for Linux proponents to learn. Linux is a
powerful operating system -- no one argues that. But Linux started out as a
difficult operating system for the average person to learn. There are far
more average users than expert users out there. To grow the community,
Linux must be as simple as possible to work with. A larger group of users
benefits both average and expert users, so even experts should support
"frills" like GUI utilities and package installation tools."
(Log in to post comments)
Metaphors make the operating system (NewsForge) Posted Apr 29, 2003 22:49 UTC (Tue) by iabervon (subscriber, #722) [Link] The main mistake I've seen is that people seem to think that GUIs are easier for people to use. This is not at all true. The average GUI is easier than the average CLI for some tasks, but this is mainly because GUI conventions, being somewhat more recent, are a bit nicer than the traditions for CLIs, which have not evolved significantly. CLIs suffer from the advantage that they are easier to write, which means that less advanced ones exist.There ought to be a project to modernize the command line. The main issue with the command line is that the user doesn't know what commands and files are available, what options are available for the commands, etc. Of course, doing it really right would imply having parsing information for command options available to the shell, which quickly gets quite complicated. On the other hand, having bash recognize the standard GNU utilities and provide assistance should be possible and useful. The simple case would be showing the option help for "ls" if you type "ls -[tab]", but you could also show something like the emacs *Completions* buffer whenever the user is typing a command (with, at the top, a message saying when the list is), where the list contains completions for whatever the user is in the middle of, if the shell knows. The command line is useful because it is an efficient way of getting user input. It was available before it was feasible to provide the user with a lot of useful information in real time in the same area, but now we can do better with providing the user with information. The advanced user isn't affected much (how often do you look at something in your shell window while you're typing another command and it isn't a list of the things you could type next or documentation for the command you're giving?), and the novice user is actually better off than with a GUI because keyboard input is more ergonomic, faster, and requires less dexterity, and text conveys information (including documentation) more effectively than icons. At the very least, the scrollback in the shell window should not move the prompt off the bottom, and the file list you get from the shell when you hit [tab] should disappear again when you're done with it.
Metaphors make the operating system (NewsForge) Posted Apr 29, 2003 23:19 UTC (Tue) by melauer (guest, #2438) [Link] >At the very least, the scrollback in the shell window should not move the>prompt off the bottom, and the file list you get from the shell when you >hit [tab] should disappear again when you're done with it. Without explicitly saying so, you're suggesting a break from the "terminal" model. These types of changes, and the "emacs completions buffer" suggestion you made, won't work in a command line which assumes one line of input and an unchangeable history.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 0:21 UTC (Wed) by iabervon (subscriber, #722) [Link] What's wrong with a break from the "terminal" model? Most interactive programs don't follow it anyway, from "less" (which tends to not affect the scrollback, even) to "vi" (which has a command line at the bottom which is independant of the file and disappears when not in use), to "emacs" (which pops up and hides subwindows as needed), to "screen" (which does everything).Nobody uses dumb terminals any more, anyway, or they quickly find they can't use any editor or pager they recognize. Bash already uses a number of VT features under normal operation; being a bit more extensive and clean about it wouldn't hurt anything.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 18:30 UTC (Wed) by dcoolidge (guest, #1390) [Link] Where have you been since windows 3.1?The reason terminal models are bad is that there is too much for a simple user to learn. For the tech savy command line utils are very usefull but you have to remember all the commands for those command line utils. A normal user's willingness to learn stuff is minimal. GUI provides a hunt and peck approach. You don't have to remember all the commands you just have to remember where they were.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 23:53 UTC (Wed) by tjc (subscriber, #137) [Link] The reason terminal models are bad is that there is too much for a simple user to learn.So what!!!? Just because my neighbor doesn't know how to drive a manual transmission doesn't mean that I have to drive an automatic. Just because he doesn't have the physical coordination to ski doesn't mean that I'm going to give it up. Just because he doesn't appreciate jazz, should I stop listening to it too? So now CLIs are "bad" just because he doesn't understand them either? If we're going to reduce the meaning of "good" to mean the lowest common denominator of what people understand and appreciate, then maybe we should all give up on computer science and go to tractor pulls instead. [/rant]
Metaphors make the operating system (NewsForge) Posted May 1, 2003 23:27 UTC (Thu) by melauer (guest, #2438) [Link] > If we're going to reduce the meaning of "good" to mean the lowest common> denominator of what people understand and appreciate, then maybe we > should all give up on computer science and go to tractor pulls instead. That's not the definition of "good", but it may be the definition of "good UI design". :) We're really getting off-topic, though. I don't think that anyone argued that the command line has to be easier to use. That's what GUIs are for. The argument was that we could make it more _powerful_.
Metaphors make the operating system (NewsForge) Posted May 2, 2003 1:38 UTC (Fri) by iabervon (subscriber, #722) [Link] The reason current CLIs are hard is that the user lacks any guidance as to how to use them. But there's plenty of window space available, and plenty of processor power to figure out what would be helpful and use some window space to help. For that matter, just having the bottom two lines taken up with a summary of fileutils (like the Pine command summary) would make the shell really easy for users; much easier than hunting and pecking in a GUI.Actually, since Windows 3.1, I've been using Linux (with bash) almost exclusively, because I couldn't figure out Windows 95, let alone anything since. Why anyone thinks that "Alt-F s TAB u ENTER" (IIRC, which I probably don't; subscript in Word, important for writing CS problem sets) or the equivalent mouse clicking is an easy-to-remember command, I have no idea.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 9:47 UTC (Wed) by amikins (subscriber, #451) [Link] I agree wholeheartedly. Nowadays, I mostly use X to hold a bunch of terminals in virtual desktops, to be able to switch around fontsizes and the like, with a webbrowser shoved off to the side.What I'm more interested in is a graphical CLI. I feel there's a possibility there for an alternate interface that isn't yet being explored, and there's lots of things a graphical interface can provide while still being a primarily keyboard oriented interface. More to your topic, the ability to do completions with a shell shouldn't be difficult from the shell-programming side, if one had a definitions file for each command.. Given the work that often goes into package management, this might be unliked by the folks putting things together, but theoretically it wouldn't be difficult, just.. tedious.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 14:09 UTC (Wed) by iabervon (subscriber, #722) [Link] The tricky thing with completions is things like "cvs c[tab]"; the shell needs to know that the completions are "checkout" and "commit", and then it needs to know what the options are after the command, and it needs to know that "cvs diff -D yes[tab]" is "yesterday", and "cvs diff -u" is an rcsdiff option, not CVS's responsibility at all, but still valid.Beyond that, the information really ought to come out of the program itself, so that it stays in sync with what will actually happen if you type it and hit return (even if you've changed your $PATH or put in something that the package manager doesn't know about, or are doing "./a.out -[tab]"). That's why I think it should start with GNU binutils and bash; it would then work for a lot of the simple stuff where it's most convenient and expected, and the same group is responsible for both sides. Probably cvs should be initially supported, too, so the solution is not too simplistic. I think a section or a symbol in the binary would be good, easy to support, and would stay out of the way of anything that didn't support it. For that matter, you could have an extension of getopt that would parse the command line inside the program based on the same information that the shell used to guide the user in creating the command line.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 12:08 UTC (Wed) by Wol (guest, #4433) [Link] Look at studies of learning. GUIs are based on the studies of Seymour Papert about how children learn. So they are excellent for the casual user, who dabbles and never really learns how to use a computer. BUT, and this is a HUGE but, the more somebody uses something, the more their behaviour becomes automatic and learned, and the underlying behaviour changes immensely.This is why GUIs are so frustrating to experienced users. There IS no way for their behaviour to become automated - GUIs *obstruct* the learning process, forcing users to remain stuck in "learning" mode. Take reading. As a kid, we read phonetically, we read aloud, and we hear what's on the page. As an adult, when we meet an unfamiliar word we still do this (even if we don't actually say the word out loud) BUT for most words we read in "symbol" mode - we see a blur on the page with spaces round it, and the meaning goes from page to brain without the hearing system ever getting involved. That's why TEXT ALL IN CAPITALS, or an unfamiliar font, or spelling mistakes, all jar and slow us down - they change the shape, or "feeling", of the blur and knock us back in to "learning mode" to understand what's being said. When I started computing, all I had for programming was a line editor. Later on I got a full-screen editor, but it used the same line-editor's syntax in its line mode (bit like vi, really). As soon as I wanted to do anything complex, I always dropped back into line edit mode. The modern editors I use are immensely frustrating, precisely because they either lack a line mode (most Windows editors) or I can't get to grips with it (vi, emacs for example). In other words, I'm stuck with the learning interface, not the doing interface ... :-( Cheers,
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 18:11 UTC (Wed) by tjc (subscriber, #137) [Link] What Wol said. :-)I worked at a place about eight years ago maintaining a UNIX-based character mode customer service application. This thing was so primitive from a UI standpoint that the built-in editor for entering comments into the database was a subset of vi. Users moved from one screen to the next and selected menu items by pressing a single key. New users hated it, because it was hard to learn, but once they got used to it they could fly around the app with one hand while talking to a customer on the phone. They had a few other apps (written in some 4GL that I can't remember) for doing things that were outside of the main application, and using them was like jumping from a speeding train into a swimming pool full of Jello(TM). BUT for most words we read in "symbol" mode - we see a blur on the page with spaces round it, and the meaning goes from page to brain without the hearing system ever getting involved. One could navigate the screens in the above mentioned application by just glancing at the "shape" of the text menues on the screen.
Metaphors make the operating system (NewsForge) Posted May 2, 2003 21:36 UTC (Fri) by Baylink (subscriber, #755) [Link] .. and the name of this syndrome isWhat You See is ALL You Get. It's the most common problem with graphical interfaces in the context of trained users. Really, since the primary thing that GUI's make easier is *training*, they're tuned for high-turnover situations, and this is really not the proper approach, from a business standpoint. What you *want* to do is train and manage for retention... and when you do that, you'll find out what lots of mainframe houses already have when they tried to build CUA interfaces atop 3270 networks: you don't gain much and you lose a lot. Allied Van Lines did this: AVS was *much* easier to learn than CAMIS. But it was *slower to use* and took 7 times as many screen-transactions, upping their processor and FEP load something considerable. Enabling fast turnover is *not* the proper solution.
Redesigning the command line Posted Apr 30, 2003 13:09 UTC (Wed) by sphealey (guest, #1028) [Link] There ought to be a project to modernize the command line. The main issue with the command line is that the user doesn't know what commands and files are available, what options are available for the commands, etc. Of course, doing it really right would imply having parsing information for command options available to the shell, which quickly gets quite complicated.Um, aren't you describing the basic behaviour of the TOPS-20 command line? sPh
Redesigning the command line Posted Apr 30, 2003 18:59 UTC (Wed) by cthulhu (guest, #4776) [Link] Yes! I knew if I read long enough to the replies someone would say it.If not, I'd have to myself. TOPS-20 is *the* most friendly CLI I've ever experienced. "?" immediately gets you a list of full-word options (not -t, -g -A, etc; the GNU-style options are nicer but more work to type). Then there were the "guide words" - words the CLI filled in if you hit escape (I think) prompting you for the next input. Etc, etc, etc. Too bad the last time I used it was almost 20 years ago. So tcsh is the closest we come to that in *nix, as far as I know. But tcsh needs a special help definition for every command that lives in a tcsh script completely divorced from the command itself, if you even want to try to keep up with commands. If the shell CLI did more than simply offer all executable files in the path as options, then we could have something like TOPS-20 again. And, if command line utilities were to adhere to some sort of convention to provide all these features, we'd have a CLI to the envy of all others. Oh well.
Redesigning the command line Posted May 1, 2003 13:36 UTC (Thu) by Wol (guest, #4433) [Link] Don't know how it's done on linux, but Prime had a standard (ie part of OS) system call that would parse a command line and shove the result in a PL1 struct. If there was a similar routine in a linux library, and a way for the app to pass the definition data back to the shell, then this would be a pretty simple way of getting what we want.Ie the shell can call the app with "here's the command line, off you go", or "here's a partial command line, what comes next?", and because it gets fed through a *standard* parser, you get standard behaviour across multiple commands... Cheers,
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 14:12 UTC (Wed) by busterb (subscriber, #560) [Link] I like to use the bash-completion package that comes with slackware. This is a collection of extensions to bash that allow it to give sensible completions to a wide variety of commands. For instance:"rmmod snd-<tab>" prints a list of loaded modules that begin with 'snd-' "removepkg <tab>" prints a list of all installed packages "installpkg <tab>" prints a list of .tgz files in the current directory There are a lot more. Have you ever watched the mozilla build process in an XTerm? Watch the title window. Improving the command line will take time, but there is definitely progress.
Metaphors make the operating system (NewsForge) Posted Apr 30, 2003 21:37 UTC (Wed) by yosch (guest, #4675) [Link] Yes, this collection of scripts really adds a huge amount of flexibility and speed to GNU bash. But it's available for any flavour of GNU/Linux, not just Slackware. In fact, I would say that it's a must have for any sytem with bash.The list of apps that it completes is huge. (man, ping, ssh, scp, urpm*, modprobe, cvs...) More over here: Just study a bit the various scripts, start crafting your own and put them into $HOME/.bash_completion. If they're good, then contribute them back to Ian's collection. Can you envision a FLOSS world where every command will have its fully descriptive completion script?
Metaphors make the operating system (NewsForge) Posted May 1, 2003 9:03 UTC (Thu) by amikins (subscriber, #451) [Link] Oooh! Oooh!*snag* NEAT! (happy user)
Bash Completion Posted May 4, 2003 18:16 UTC (Sun) by Duncan (guest, #6647) [Link] THAT'S what the bash completion package I've been seeing the changelogs go byfor on the Mandrake Cooker list is all about! Thanks! I'll have to go off and install it now!
Metaphors make the operating system (NewsForge) Posted May 5, 2003 0:17 UTC (Mon) by daenzer (subscriber, #7050) [Link] Or try the original, zsh. :) It has a lot of other nice and unique features as well.
In The beginning was the commandline Posted May 3, 2003 14:42 UTC (Sat) by stock (subscriber, #5849) [Link] Yes of course it was. or not really ? This book is briljant, its even discussing about Disney wanting to claim absolute exclusive IP rights etc.. Like creating their own reality, Disneyland. Now compare that to a methaphor alike thing as a OS :)Stevenson wrote a briljant essay. Its one of the rare books i read in 1 take for a single afternoon and evening. Robert
|
|||||||||||