Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The role of the command line in the modern GUI

By sawndust in Technology
Sun Feb 10, 2002 at 07:13:22 PM EST
Tags: Software (all tags)
Software

Not a particularly new innovation, in the last ten to twenty years the command line has seen its role steadily decrease -- losing in a big way to the modern graphical user interface (GUI). While few have been sad to see it go, or more to the point, sad to see it's functionality replicated in fancy 3-D depressible widgets with context menus and sub-dialogs, those who were and are familiar with the command line interface (CLI) and it's vast power often continue to favor it over it's flashy but often clunky nephew.


This is not an article on the merits of the command line nor of the merits of the GUI -- that I'll leave to someone else. The issue I would like to raise is to what extent can these two paradigms be combined synergistically. Now before you start in on how this is old hat, let me raise the point that Microsoft products have been moving away from the command line quite steadily since Windows 3.1 and have only recently released a version of Windows for the consumer devoid of its original 16-bit DOS underbelly. While Linux and Macintosh have both had a recent contrary effect, I think it is fair to say that historically due in part to the reluctance of Microsoft and Apple to emphasize the power of the command line, it's popularity has waned to the benefit of the modern GUI. I am not implying causality here, for in fact a strong argument could be made to the effect that the success of these two companies has been due in large part to their de-emphasis of the command line and consectary focus on the GUI. With the possible exception of macros, I am not aware of a case of any strong attempt by either of these two companies to synergistically combine the power of a command line with the power of a GUI. Is this because the modern GUI doesn't need a command line?

Modern GUI's emphasize the mouse as an input device. The user clicks on things and watches the screen change to reflect the action. This is an inherently limiting design in that for a program to represent its things (or actions) it must given them some sort of on-screen representation. This simple statement has several important implications and caveats, some of which are: (1) the human eye is only capable of differentiating things when they are of a certain minimum size, lets say 100 pixels on a normal monitor (2) vision is largely affected by human's innate preoccupation with aesthetics (3) the human mind is incapable of effectively dealing with a screen containing say 300 buttons (4) alterations to functionality can require reorganizing large portions of the UI.

Now if you've ever worked on user interface design, you know that screen real estate is a scarce resource. With all the functions you would like to express on a screen, sometimes you are left making decisions like choosing between slightly cryptic icons to represent your buttons; less cryptic larger icons; showing only half as many buttons with full text descriptions; or showing only one button "Tools," or some such, that lead to a page with more buttons.

This can be a very aggravating decision process as many people have their own (strong) opinion on the correct thing to do. My favorite is the 5-level deep chain of dialogs with "Advanced" buttons leading to one another. The reason this happens is that modern software can be complex and can have many "twiddle-able bits" or "options". You can't show 300 options the main page, so you throw a bunch of it into menus named after the "category" of the option (File, Edit, View, Tools). How many times have you hunted through the menus in a modern GUI looking for the darn function you want, trying to guess what "category" the software company wanted it in? Worse, you can't show everything in the menus either, there's just too much, you can only have 5-15 menus before that gets out of control, and only maybe 20 things in a given menu. So the menu selection pops up a dialog. The dialog can't have 300 buttons, so it only has 12, with 4 tabs and an "Advanced" button, etc.

When I want to add a new function to my program, I have to choose where in this labyrinthine system my new button goes. If there is no space, maybe we need another tab on a dialog, and maybe that tab puts us over the tab limit of 5 tabs, so we have to make a new dialog, etc

Much of this little hell that I have been embellishing and exaggerating to make a point, is sidestepped in a command line based system. Now command line based systems have their own drawbacks as well, including (sometimes nightmarish) path, version, and namespace conflicts. For the sake of brevity and laziness I will not delve into these problems other than to state that in some cases they are as damning as the limitations of a modern GUI. If this needs further elaboration, I will be happy to oblige, command lines are no panacea.

That said, in my limited experiences with GUI design I have often been tempted to plop in a text widget with a "GO" button. What would the user type in the text widget? That is the question every user would want to know when they saw it, and the one that is the most damning indictment of the command line in a modern GUI. Who knows what you should type? I might, and I might describe it in great detail in the documentation and even have a `?' help button there that also describes it. You could do all sorts of cool things in there if you knew the way it worked. The problem as I see it is that this concept does not particularly appeal to most end users, especially at sale/demo time. It is not flashy, it is not easy to understand, and it requires up front thinking rather than blind `poking around'.

Put more succinctly, modern GUI's use: "recognition rather than recall". I must admit that I almost always operate in "poking around" mode, (and sometimes pride myself on my ability to effectively do so) so I certainly am not going to denigrate it too much. Yes, I have before been encouraged to "Read the Fallow/ Faustian (insert your favorite F-word) Manual." Though at times "poking around" does seem sloppy and wasteful, sometimes it pays of big and a hard problem is solved very rapidly with little organized work and research as a result. Most people are all too eager to take credit for this sort of thing; it is a mark of ingenuity.

The trend then is away from user interfaces that require recall and towards those that require only recognition. If a GUI allows the user to intuit its meaning, then that is better than forcing the user to read the manual. While this is all well and good, and makes the sale, it may not be the optimal long-term solution.

Once I have used a system for weeks I develop a knack for it, I know where things are, I know what I want to do, I want to use recall not recognition, my brain has grown and the GUI has not allowed me to leverage my growth. Macros, keyboard shortcuts, and adaptive user interfaces are meant to address this issue, but what I am interested in is the introduction of the command line INTO the GUI, at a basic and fundamental level.

For instance, who is editing the 5th level of "Advanced" dialogs and how much time did they spend finding where the accursed check box is. Why aren't all the options named with simple names and editable with a text widget? For instance in Word, some default setting might look like this:

>ShowSettings Auto*
AutoSpellingCorrection "ON"
AutoPaperclipDude "ON"
AutoGreenUnderlines "ON"
AutoRedUnderlines "ON"
AutoFileCorruption "ON"
AutoSave "OFF"

Then if I was a great command line guy I could set all their values to their opposites in one line, but being a somewhat normal guy I might do this:

> SetSettings Auto* "OFF"
OK 6 VALUES SET
>SetSettings AutoSave "ON"
OK 1 VALUE SET

Say I want to export all of my settings to a text file so I can take them home:

>ShowSettings * > mySettings.txt

And apply them to my home machine:

>SetSettings -f mySettings.txt

Neat, right? Useful, fast, better than digging in options dialogs. Now I cheated in that all these options started with "Auto" and there were these nice "Get" and "Set" settings calls that I somehow knew all about, but the idea is that if I were an advanced enough user I could learn these things and actually be able to leverage them.

As a perhaps more interesting example, suppose I could access grep, awk, and xargs (or anything in my bin or system32 directories) in Word instead of using the silly find and replace dialogs? Clearly there are some issues to be overcome in terms of Word supporting such a feature. Right now to do this I would need to save my Word document in text format or copy and paste or something like that. Most people probably don't have any idea what grep and awk are, but that is ok, because the command line interface does not require screen real estate to present these functions.

The goal is to try to increase people's productivity by leveraging their scalable recall and not inherently limited recognition skills. This must be done in a way that does not provide a barrier to entry, but does provide a stepping-stone to greater usability. The command line interface is inherently flexible and extensible, and as such can and should be used synergistically with the modern GUI.

Once I receive feedback on this article, I would like to follow it with one exploring more recent and future developments in the CLI/GUI area with the continuing emergence of the Web, XML, Email, Instant Messaging, and Web Services. But for now, I'll leave it at that.

Some interesting links on this topic:

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
How would you like to interact with your favorite applications?
o Mouse Only 3%
o Keyboard Shortcuts Only 7%
o Keyboard Shortcuts and Mouse 15%
o Command Line Only 10%
o Mouse, Keyboard, and Command Line 47%
o I don't have any "favorite" applications 5%
o I would like to not have to interact with my "favorite" applications at all 2%
o That is not information that I feel comfortable sharing right now 7%

Votes: 110
Results | Other Polls

Related Links
o recognitio n rather than recall
o GUI and Command-line -- Conflict or Synergy?
o XML Term
o XML Term Screenshot
o Also by sawndust


Display: Sort:
The role of the command line in the modern GUI | 68 comments (51 topical, 17 editorial, 0 hidden)
Big Workstation Apps (4.16 / 6) (#3)
by BonzoESC on Sun Feb 10, 2002 at 01:37:23 AM EST

There are already a good deal of large workstation apps with a CLI for quick tasks. AutoCAD comes to mind, where the usual method of interaction involves one hand indicating positions and activating/deactivating snaps while the other quickly taps out commands. Likewise, 3DS MAX 3 and up have a script interpreter in the bottom-left to perform boolean operations faster than you could with the GUI.

The real problem with implementing something like this in a word-processor would be confusing the users over what mode they were in. If they thought that they were in document mode but were actually in command mode, they might inadvertently type their entire graduate thesis in the command line, which would probably start debuffering after 50-or-so lines. A visual and audible indicator could be used to prevent this, but it still might confuse people.

I'd buy a program with it, though.

--

Normally, my sig is an image.

What I would have expected to be discussed (4.75 / 12) (#4)
by Anonymous 242 on Sun Feb 10, 2002 at 01:48:52 AM EST

Scripting.

While prior to Mac OS X, the venerable Macinthos was lacking a native command line interface, its embedded AppleScript functionality more than made up for it. Even Microsoft eventually saw the light and created the Windows Scripting Host (WSH).

Put bluntly, most things that can be done better through a command line can be done through proper use of integrated scripting. The largest trade off being that most CLI syntax has less steep of a learning curve. The upside is that (barring shells that are full fledged programming languages) scripting allows potential actions that a CLI simply cannot approach.

Another interesting, but easier to miss discussion is tools that integrate a CLI into a GUI. A good example of the promise this offers is SMIT from IBM's AIX. Leaving the discussion of SMIT's quality (or lack thereof) to another day, one of SMIT's more ingenous ideas is to display the command to perform all actions taken by point and click. Hence, the user can learn the CLI by using the GUI.

Also, many kudos for not portraying the discussion as CLI and GUI being mutually exclusive. I tend to use my terminal window in conjuction with my windowing environment. My biggest complain about the CLI in Microsoft Windows is its lack of integration into Windows. Starting with the fact that cut & paste between Windows apps and terminal session apps is a royal pain and leading up to the fact that Windows terminal apps are second class citizens to the Windows task master, the integration is sadly lacking. (Fortunately, Cygwin ships with a build of rxvt that can run native in Windows! Free software to the rescue.)

Regards,

Lee Irenæus Malatesta

A little (partial) integration in KDE (4.66 / 3) (#6)
by krogoth on Sun Feb 10, 2002 at 02:13:59 AM EST

KDE has some command line integration, but it doesn't go quite as far as the article discusses. Both KDevelop and Konqueror can display a shell in a frame, which you can use alongside the GUI. They can't interact with the GUI contents (now that I think about it, I would like to be able to control the program from the command line or filter the text through my favorite regexp processor), but they are useful for doing small tasks that would be slower in the GUI, displaying a completely different task alongside your current one, or even going on IRC :)

The KDevelop integrated shell is more integrated than it may seem though; since some of the KDevelop commands simply call other programs (make, make clean, the binary...), those can be done from the command line within the IDE.
--
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
:wq
[ Parent ]
macros and scripting (5.00 / 3) (#7)
by sawndust on Sun Feb 10, 2002 at 02:18:47 AM EST

The macro reference was an allusion to scripting, but you're right that could have used some more investigation. In my experience, the scripting world generally does not provide the same ease-of-use, awareness of other systems features as a CLI, but you are right in the assertion that scripting is more powerful than a traditional shell (especially given WSH, etc). One problem with it though is that you often start to get locked into COM somewhere in there. CLI is a nice clean text-based interface technique, which has it's own advantages. I like the SMIT idea, reminds me of how windows encourages keyboard use through inconspicous underlines and right justified shortcut keys in menus. It's there for when you want it, but it doesn't get in the way otherwise. And yeah, cygwin is a great little tool!

[ Parent ]
Modern applications are scripts (4.25 / 4) (#10)
by Weezul on Sun Feb 10, 2002 at 03:29:34 AM EST

I know the last time I used Microsoft wWord I got a Visual Basic error. I laughed. Lots of things are done with interpreted GUI langauges like wish now. It's also true that the GUI development world is driving hard in the direction of objects. I think these two developments will eventually bring us to the point where there is no reason not to have a command line attached to *every* program. It would just let you execute VB, Wish, Haskell, etc. commands within the running program. Indeed, you could perhaps remove all menu functionality and simulate menus with a good cut and paste functionality, i.t. you would cut and paste hidden commands to the command line with a single click. This would help to bridge the gap between learning to use a computer and learning to program a computer.

"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
[ Parent ]
VIM's menus are like this (none / 0) (#48)
by BJC on Mon Feb 11, 2002 at 06:06:35 AM EST

Indeed, you could perhaps remove all menu functionality and simulate menus with a good cut and paste functionality, i.t. you would cut and paste hidden commands to the command line with a single click.

This is how VIM's menus seem to work.

[ Parent ]
Windows Command-Line Cut-n-Paste (4.00 / 1) (#44)
by EuroBryce on Sun Feb 10, 2002 at 11:14:20 PM EST

If by "Terminal Session Apps" you mean the command-line... All W95- and NT- derived OSes support something called "QuickEdit Mode". Bring up the command prompt properties and select the "Options" tab (surely there is a registry option to set this, but I do not know it off-hand). Once enabled you are able to select text with the left mouse button and copy/paste with the right.

Command-line apps (to me) do not seem to be second-class citizens under Task Manager in the NT-derived OSes. You can kill them and change their priority just like anything else. Task Manager in the W95-derived OSes is near-useless, so if that is what you were referring to I would suggest you consider XP.

-Bryce



[ Parent ]
Quick Edit and second class citizenship (none / 0) (#50)
by Anonymous 242 on Mon Feb 11, 2002 at 09:07:05 AM EST

Quick Edit mode breaks a lot of command line apps because these apps hang their stdin when pasted to while in Quick Edit mode.

Terminal session programs, among other issues, do not accept a terminate signal when sent by Windows.

Regards,

-l

[ Parent ]

Blame the programmers. (none / 0) (#55)
by EuroBryce on Mon Feb 11, 2002 at 03:11:11 PM EST

In my experience, very few Win32 console applications experience problems with pasting or being shut down. There are some, but the problem isn't with the Win32 console. The problem is with programmers who do not create well-behaved Win32 console applications.

MS still ships a few such programs, the most egregious being ftp.exe, but the majority are well-behaved. The GNU utilities for Win32 are a fine example of a large collection of well-behaved, ported console apps.

-Bryce



[ Parent ]
Preferences (4.85 / 7) (#9)
by 90X Double Side on Sun Feb 10, 2002 at 03:28:11 AM EST

Mac OS X already encourages people to use the .plist format for their preferences, so that they are plain text XML files that you can grep them to your heart's delight. Here are some parts of my com.apple.finder.plist file as an example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
... ... ...
<key>AppleShowAllFiles</key>
<false>
<key>AutoplayAudioCD</key>
<true>
<key>AutoplayDVD</key>
<true>
<key>BurnProgressWindowLocation</key>
<string>523, 425</string>
<key>ClipboardWindow.Location</key>
<string>274, 322</string>
<key>ComputerOptions</key>
<dict(there should be a slash here, but it won't display in the context of an HTML page)>
<key>CopyProgressWindowLocation</key>
<string>90, 85</string>
<key>CreateDesktop</key>
<true>
<key>DesktopViewOptions</key>
<dict>
<key>ArrangeBy</key>
<string>grid</string>
<key>BackgroundFlags</key>
<integer>0</integer>
<key>BackgroundType</key>
<string>DefB</string>
<key>IconSize</key>
<integer>76</integer>
</dict>
<key>EmptyTrashProgressWindowLocation</key>
<string>163, 46</string>
... ... ...

</dict>
</plist>

Not everything is human readable, since you can embed data in the plist if necessary, but this essentially shows an implementation of what you describe, although it uses XML rather than some new language and sticks to OS X's approach of offering both GUI and CLI ways to do things rather than your idea of having textual interfaces embedded in GUI apps. You should note that in many cases Apple doesn't put options listed in the plist in the GUI if they would never need to be accessed by a normal user, solving the problem of too many options while also leaving the values open to change by power users.

There are also many cases where there is nothing to blame but bad UI design; anything more than two layers deep needs to be seriously re-thought :)

“Reality is just a convenient measure of complexity”
—Alvy Ray Smith

Your XML is broken (3.40 / 5) (#14)
by juahonen on Sun Feb 10, 2002 at 08:40:09 AM EST

None of the "false" and "true" tags were terminated correctly. That XML won't parse. They should read <true /> or <false />. All tags must be closed in XML. Read more at W3C.

Slashes are displayed in HTML pages. The HTML parser just doesn't mind about them if they're inside tags.



[ Parent ]
Won't display in HTML (3.75 / 4) (#20)
by 90X Double Side on Sun Feb 10, 2002 at 12:29:21 PM EST

Trust me, they're there; a slash at the end of a tag will not diaplay on a Kuro5hin page, just try it: <thereshouldbeaslashafterthis>

“Reality is just a convenient measure of complexity”
—Alvy Ray Smith
[ Parent ]
There can be a slash at the end... (3.00 / 1) (#52)
by rasilon on Mon Feb 11, 2002 at 10:13:14 AM EST

<thereshouldbeaslashafterthis/>

[ Parent ]
Programs not for Programmers (3.77 / 9) (#19)
by SPrintF on Sun Feb 10, 2002 at 12:02:20 PM EST

You mention the "power of the CLI," yet fail to describe it.

You give one example, SetSettings Auto* "OFF", and yet don't explain how the ordinary user learns how to do this. Since, as you noted, the user begins by "poking around" in the GUI, how does the user "grow" into using the command line? Sure, you can say RTFM, but in reality people don't, which is why designers resorted to the "poking around" method in the first place.

Is there a way to logically transition from a neophyte who relies on a GUI to an expert who uses the command line? I doubt it, since using the command line implies an understanding of concepts like "command syntax," "switches" and "parameters." That is, it requires some degree of the programmer mindset.

But the simple truth is, most users aren't programmers and will never learn to use the CLI.

It isn't even clear that you would want them to. Do you really want Mike Marketing-Weasel to be issuing commands like SetSettings Auto* "OFF" when you know damn well that the guy won't know the consequences of issuing this command, and it will be up to some poor shmoe in IT to repair the damage?

We don't always need to be spoken to like babies (4.66 / 3) (#28)
by greenrd on Sun Feb 10, 2002 at 02:48:06 PM EST

You mention the "power of the CLI," yet fail to describe it.

It is presumed that most k5ers are intelligent people who know the value of interacting with computers in a more advanced fashion than the technological equivalent of "point-and-grunt". Anyway, the article explicitly stated that its purpose was not to advocate either the CLI or the GUI, but both together. If you don't see the point of CLIs (or GUIs), you don't meet the prerequisites for this article.

But the simple truth is, most users aren't programmers and will never learn to use the CLI.

True, most users aren't programmers. I disagree with the latter - but in any case, it would be useful for some users, so what's your problem?

Do you really want Mike Marketing-Weasel to be issuing commands like SetSettings Auto* "OFF" when you know damn well that the guy won't know the consequences of issuing this command, and it will be up to some poor shmoe in IT to repair the damage?

Simple solutions: have an option for the admin to disable it, or have a company policy against marketroids using it, or whatever. Just because some people would shoot themselves in the foot with it, doesn't make scriptable apps a bad idea.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

For me it depends on the application (4.66 / 3) (#21)
by Talez on Sun Feb 10, 2002 at 12:58:04 PM EST

When I'm working in Opera, the only time I touch the keyboard is for putting in a URL or typing into forms. All my navigation is done 100% mouse via Opera's Gesture Navigation System (which is the most brilliant thing I've ever used for lazy surfing).

When I'm doing file management, I do the faithful Ctrl-Esc, R, Command/CMD, Enter and then start ripping through my directory tree. The only two thigns I miss from linux over a dos command line are the tab autocomplete and symlinks. Both those would make things so much easier.

When I'm working in an app, I tend to change things so I have to switch between mouse and keyboard as least as possible (eg, Aliases in Mirc). Its not that I cant use a keyboard one handed, its just that if I'm using a keyboard interface, I can work much faster with both hands on the keyboard typing in a stream of commands rather than clicking my way through menus and using the occasional shortcut (which I can actually reach with one hand).

I suppose in the end it all comes down to personal choice.

Si in Googlis non est, ergo non est
Windows has shortcuts too =) (4.33 / 3) (#22)
by Jel on Sun Feb 10, 2002 at 01:01:58 PM EST

Try Win-R =)
...lend your voices only to sounds of freedom. No longer lend your strength to that which you wish to be free from. Fill your lives with love and bravery, and we shall lead a life uncommon
- Jewel, Life Uncommon
[ Parent ]
shortcuts != CLI (none / 0) (#47)
by Macrobat on Mon Feb 11, 2002 at 01:58:11 AM EST

Keyboard shortcuts are still part of a GUI. A user interface is both an input and an output system, remember, and although you can bypass the mouse, you're still using a window-ey interface for output. In a sense, even a green tube interface is visual, what with different intensity settings for text representing different things, and programs displaying column-oriented output.

To me, the advantage of the command-line shows itself when you can bypass the "user" altogether. Piping the output of one program into another is a lot faster than cutting-and-pasting between applications. Setting things up to run in the background by writing scripts and scheduling events with the crontab make your computer almost like a living, breathing entity (if you have a vivid imagination :)

That doesn't mean I think GUIs are bad at all. I'm browsing with Konqueror on a KDE desktop right now. Sometimes I want my computer to slow down to the speed of my pokey typing and rambling thought process. But I think it's a fundamental design question for programs, whether the work is done chiefly by the human, or by the computer. (On a related note, does it seem to everyone else that we use the word "applications" to refer to GUI products, and "programs" to refer to command-line oriented tools?)

Just my two cents worth.

"Hardly used" will not fetch a better price for your brain.
[ Parent ]

I know that =) (none / 0) (#56)
by Jel on Mon Feb 11, 2002 at 04:47:14 PM EST

I know that. I was simply telling the guy that he can type Win-R to get directly to the run dialog, instead of Ctrl-Esc R, which brings up the start menu, highlights an item, closes it again, and then brings up the start menu.

...lend your voices only to sounds of freedom. No longer lend your strength to that which you wish to be free from. Fill your lives with love and bravery, and we shall lead a life uncommon
- Jewel, Life Uncommon
[ Parent ]
No offense intended (none / 0) (#58)
by Macrobat on Mon Feb 11, 2002 at 06:45:38 PM EST

Right. All I was saying was that, in response to Talez' post, GUIs comprise both input and output, and that command-line redirection and scripting sometimes enable you to do away with both. (I may have responded to the wrong post; for that, accept my apologies.)

"Hardly used" will not fetch a better price for your brain.
[ Parent ]

Auto-Tab completion (4.00 / 2) (#24)
by nebby on Sun Feb 10, 2002 at 01:45:39 PM EST

You can get auto-tab completion to work in cmd.exe .. I think it's turned off by default though. I forget exactly how to turn it on (some registry value) but a quick search on google should suffice. Try looking for TweakXP or Tweak2k, I think you can turn it on using that.
Half-Empty: A global community of thoughts ideas and knowledge.
[ Parent ]
WinXP & Auto-completion (4.50 / 2) (#32)
by GreenHell on Sun Feb 10, 2002 at 05:25:10 PM EST

I don't know about Win2k (I can't really remember much about it), but in WinXP the command-line auto complete using Tab is enabled by default (I don't even know if you can disable it).

The only annoying part is the quotes it puts around most of my directory names, forcing me to hit backspace to get it to auto-complete on a sub-directory.

-GreenHell
This .sig was my last best hope to seem eloquent. It failed.
[ Parent ]
Auto-completion and other Command-Line Wizardry (5.00 / 3) (#43)
by EuroBryce on Sun Feb 10, 2002 at 10:49:29 PM EST

Set "CompletionChar" under "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" to the ASCII value you wish to use (9 for Tab). This has been available since at least NT 4. As for spaces, under XP you can place a blackslash are the closing quote and continue using command completion. My recollection is that W2K also supported that behavior, but NT 4 probably did not.

To me, this is one of those often ingored features that demonstrates that Microsoft has not ignored the command line, at least under NT and it's successors. Cmd.exe has been extended in other cool ways, do a "cmd /?" and look at the "Command Extensions" section. There is some cool stuff documented there, and there is other stuff that isn't documented (try "dir *.exe *.dll").

The Resource Kits that Microsoft offers provide many additional command-line utilities. IMO, they are worth their weight in gold, and no NT Administrator should be without them. Toss in WSH and WMI, add a pinch of ingenuity, and there is very little that cannot be accomplished from a Windows NT/2K/XP command line.

-Bryce



[ Parent ]
Ironically (4.50 / 2) (#33)
by X3nocide on Sun Feb 10, 2002 at 06:14:48 PM EST

I tend to rarely use the mouse with Opera, since mou1se gestures tend not to map well to a trackball. The window management system is fairly straightforward and almost one handed.

pwnguin.net
[ Parent ]
Great example of this (5.00 / 5) (#23)
by Jel on Sun Feb 10, 2002 at 01:17:07 PM EST

For the best example of shell & gui integration, ask any remotely technical (ex-?)Amiga user about how they used their machines on a daily basis.

Most of the screenshots I have seen of working desktops consisted of a standard GUI desktop, with a small (say 3-5 lines) shell window at the bottom. Even when I didn't have a shell window around all the time, it was bound to a hotkey, bringing it up nicely in a little box at the bottom of the screen. This system worked especially well on PAL machines, since the video timing got you extra space at the bottom of the screen, beyond what most early GUI apps built for NTSC would use. Of course, any decent app resized to whatever you wanted anyway.

Since Amigas where born with full multitasking, good GUI, and CLIs as standard features, shells were only used for what didn't suit a GUI, and scripting.

Systems initially booted into a shell *window*. If you wanted your shell to fill the whole screen, that took extra work (although was simple enough).

In short, the system you hanker after has been around for 20 years. I don't think I've ever been as productive as when Try UAE, if you want a feel for it.

...lend your voices only to sounds of freedom. No longer lend your strength to that which you wish to be free from. Fill your lives with love and bravery, and we shall lead a life uncommon
- Jewel, Life Uncommon
amigas may be cli friendly, but not all apps are (4.00 / 3) (#30)
by sawndust on Sun Feb 10, 2002 at 02:54:36 PM EST

Yes, good example, I love amigas, got a 1000 when it first came out. Great machine, a good example of a system that tried to encourage CLI to end users and failed.

Emphasising CLI has proven to be a mistake in consumer marketing. There is no doubt that focus on GUI is a win in this world in terms of sales and adoption.

As you point out, Amiga did over-emphasize CLI and was eventually effectively erased from the landscape. Focusing more on their multitasking, graphics, and GUI would have made the product seem more relevant to people starting out.

CLI is something people use once they are comfortable with the system -- when they move from recognition mode to recall mode.

The issue of this article is not so much that this is a system issue as an application issue though. A modern Word 2000 for Amiga if such a thing were to exist would still not have integrated CLI support, despite the OS's predilection.

[ Parent ]
Done right, it probably would (4.50 / 2) (#39)
by Jel on Sun Feb 10, 2002 at 08:56:08 PM EST

I wasn't aware of any Amiga OVER-emphasis on the CLI. I saw it as a nice balance - GUI used for anything that needed a GUI, CLI for a few low-level things and scripts, where graphics would help little if at all.

Come to think of it though, I did end up using the Amiga equivalents of norton commander quite a lot =)

But on the topic of Word GUI/Shell integration.. basically all major apps began to add Rexx scripting interfaces towards the end, allowing you to access all of their major functions. That, and the access to all shared libraries, which were used quite prevelantly on the Amiga anyway, made for a very comprehensive scripting system. I doubt there was much you couldn't script on the Amiga, if you really tried.

...lend your voices only to sounds of freedom. No longer lend your strength to that which you wish to be free from. Fill your lives with love and bravery, and we shall lead a life uncommon
- Jewel, Life Uncommon
[ Parent ]
any emphasis on CLI to the masses in questionable (none / 0) (#68)
by sawndust on Sun Feb 17, 2002 at 11:54:33 PM EST

My point there was not that it was an un-useful emphasis on the CLI for some users, just that to _most_ people who are buying their first computer, ANY emphasis (or even mention) of CLI is a turn off.

[ Parent ]
Modern User Interfaces (5.00 / 3) (#34)
by schrotie on Sun Feb 10, 2002 at 06:58:48 PM EST

Hi,

if a significant part of end users would be willing to profit from CLIs in the apps they use, there would be CLIs in those apps. CLIs are cryptic power user tools that yield their power only to the most persistent of users. To those guys who also tweak their registry and stuff like that. Those are too few and far between to be of market significance. They also tend to use Latex instead of Word.
Face it, you're a geek. User interfaces are welded by the mainstream. Ever went to your mum and wondered how she managed to mess up her entire system without having the slightest clue how to mess? She's market power, you're not. This secratary who still does not know how to get these mgegs into Power Point for her boss' presentation. Well and then there's the boss himself who can't tell a checkbutton from a radiobutton. All those students using word for their thesis. For how many thesises did you do the layout, because the author couldn't?

I think the immediate future of UIs lies in components. You know your VIM? Fine embed it to anjuta or evolution as your editor there. That origin clone needs a spreadsheet? Fine, use a gnumeric component. These two and some more examples work already. Many many more will follow. You learn the interface for a certain task once and can use it in all your other apps that need equal functionality.
And end users could - in many cases (progs using libglade which is a widespread approach in gnome) - even lay out/adapt their favorite GUIS themselves with a drag and drop interface without ever touching code. Naturally nobody does that, let alone use CLIs.
Then there are standards being developed. If you find your way in one app, you find it in another.
The problem you described - the problem of having hundreds of options in a program - is not a gui problem, it's a design problem. Word is broken. So are many other proprietary apps. Having hundreds of option in one app means that app tries to do too many things at once. Word can do almost anything that is about publishing information including the generation of websites, professional magazine layout, statitics ... you name it word has it. And most people use it to write letters. That is nonsense. Utter madness, no wonder people get lost. Word is about a dozen apps for a dozen problem domains - in one messy gui.
The Unix philosophy has always been, that an app does one thing and does it well. If you need something more complex, write a wrapper that uses the various tools as backends. Then you can even use the command line if you like. Now the two most used Unix desktops march towards components to bring guis the power of command lines and I think that is the way to go. Beyond that may be speech interfaces but we are still far from there.

One more comment: I am indeed much in favour of the command line. The program I use most frequently is probably bash. Well no, it's actually my IDE but then comes bash. I just don't think there is a huge market for your idea.

Regards

Thorsten

complexity yields options (none / 0) (#67)
by sawndust on Sun Feb 17, 2002 at 11:48:04 PM EST

This has got to be a law or something. If not I hereby declare it one.

It's not a design issue per se, it is an issue of I have this beast that does 8000 things and I want to be able to fiddle with it. Saying that this is a design issue is dodging the question. When you hook all of your components together into a system that does things, it will start to gather options.

Humanity needs to understand but has not yet understood the concept that software systems will soon be amazingly more complex than any system humans have ever created before.

Technology is warping society to it's needs, people are gaining familiarity with computers and software

We refuse to acknowledge the inherent complexity of software, often analagizing it to physical things, especially hardware. I think in the next 20 years it will become increasingly clear that software is not like anything else people have made. I will even go so far here as to suggest that Windows XP may represent the most complex thing any human has ever made in all of time, and I'm including the space shuttle and nuclear submarines in that list. The amount of raw knowledge and inter-workings in that program alone are absolutely staggering. It will only get more complex.

Humans deal with complexity through abstraction and local familiarity. As we develop these things in our brains, we become stronger, better able to work with our environments. Sometimes it takes years. As we develop understanding, we should be able to leverage that understanding to do things better. I don't think traditional GUIs are good at that, and I think the command line is better.

[ Parent ]
EFM (5.00 / 4) (#35)
by der on Sun Feb 10, 2002 at 07:20:43 PM EST

Anyone ever use EFM (the preliminary code tree for the file manager to be in Enlightenment 0.17)?

It had a great feature (IMO) where you could type sh commands into any file manager window (inc. the desktop) and they would be executed, the results updating in the window immediately.

For example, if you type "*.txt" all text files will be selected in the window, and you can type real commands like "rm *.jpeg" and see all your jpegs dissappear, etc. etc.

Awesome integration of command line and GUI there, it was incredibly useful and addicting.

"EFM" is dead, so you can't try it out, but I believe the functionality is supposed to be in E17 once it gets released, although it's not in the current CVS tree AFAIK. :/



Handhelds: the command line shall return (5.00 / 3) (#37)
by psicE on Sun Feb 10, 2002 at 07:40:36 PM EST

Handheld computers have a design question that most computers don't have: how should input be done? Up until now, handhelds have been designed around a limited WIMP (Windows, Icons, Menus, Pointer) interface; there is only one window at any given time, and the pointer doesn't appear on the screen, but the icons and menus are there. However, handhelds are the perfect application for spoken commands. Given the choice between writing letters and clicking things on the tiny screen, with an even smaller stylus, or speaking into a wireless microphone what they want to run and have the handheld open that, I believe most users would choose the latter.

This also provides the perfect combination between recognition-style GUIs, and recall-style CLIs. A list of commands can be shown on the screen, as just a list or as icons as they are now, but if an advanced user wants to run something that's not on the list and they know the command for it, they can say it without having to flip through lots of tabs.

As voice technology develops for handhelds, eventually it will become advanced enough that it can be deployed as a standard feature on home computers. Hopefully (probably), someone would make a voice-enabled version of bash. Then, the CLI vs. GUI debate would be settled forever - they're one and the same.

interesting (none / 0) (#66)
by sawndust on Sun Feb 17, 2002 at 11:31:55 PM EST

Do you know of any work on voice-enabled command lines? I can imagine them having a special way to express pipes and regexs, etc.

[ Parent ]
How to fully leverage the command line (4.66 / 3) (#38)
by calimehtar on Sun Feb 10, 2002 at 08:09:52 PM EST

As a newcomer to c programming, I have been shocked and fascinated at the extent to which the CLI interface has been integrated into the language. One gains an enormous amount of efficiency from writing a simple command-line app in c by comparison with writing the same for a GUI , even in a dead simple and fully GUI-optimised language like Objective C.

It's also interesting to see people like my mother for whom computers are either tools or obstacles (or both) and nothing more -- people don't know there's any other way to open a file than by double-clicking on it -- look back with nostalgia to the days of MS-Dos and WordPerfect 5.

I believe that if all command-line tools had a common, standardized interface (I know, the sacrilege) -- something like the XML preferences format in OS X described by another poster -- the learning-curve would be reduced and GUI apps could be easily built on top of the CLI with no loss of usefulness.


+++

The whole point of the Doomsday Machine is lost if you keep it a secret.


Optimised for CLI (5.00 / 3) (#40)
by iwnbap on Sun Feb 10, 2002 at 09:04:17 PM EST


C wasn't optimized for command lines; C is built to look a lot like a very high level assembler, and so deals with user interfaces in a similar fashion to the hardware - pulling bits out of a buffer here and shoving them into a buffer somewhere else.



[ Parent ]
MPW (5.00 / 4) (#41)
by Oblomov on Sun Feb 10, 2002 at 09:25:22 PM EST

I haven't touched a mac in years but I remember liking the Mac Programmers Workshop a lot, it came a long way in integrating command line and window apps. Some nice features I remember:
  • You could select and execute any text in any window
  • You could end each command with "..." and it would then show you a GUI dialog box with checkboxes and radiobuttons for all switches
  • Output and Input could be redirected to/from other open windows (or open a new one). Ideal for sed/grep etc.
Near perfect.

Support..... (4.50 / 2) (#42)
by Skinny Puppy on Sun Feb 10, 2002 at 10:25:35 PM EST

Support for a GUI has always been trouble-some in my expenice. Attemting to have a end user check which proxy server they are using or evan if they are. Goes something like the following.
  • Click on the start button.
  • Now go to Setting Menu item.
  • In the Sub-menu select Control Panel.
  • This should open a new window.
  • In the new window look for and Double click on the Intetnet Options icon.
  • You should have a Internet Properties window now.
  • Now go to the third tab Labeled Connections in the this window.
  • In the lower right you will see a Button Labeled "LAN Settings"
  • A new window labeled Local Area Network settings should have been opened.
  • The this window is the Check Box Labeled "Use a proxy server for your LAN checked?
  • Read me the contents of the Addess Field.
All that just to find out what Proxy server IE is currently using. Now if I have had a command line way of doing this. I could just ask for commands to be typed in to a command window. Now this of course has it short comings itself. But I find i easy to tell a end user to type something and read it back to me.

Skinny Puppy
and what if they're on win me and not win xp (none / 0) (#65)
by sawndust on Sun Feb 17, 2002 at 11:30:02 PM EST

That is really true. I use this ridiculous ... notation in place of slashes when I describe gui navigation in email because I don't have the patience to talk people through it. The things between the ...'s are always also equally ridiculous:

Start...Setting...Control Panel...Network and Dialup Connections...Local Area Connection...Properties...Internet Protocol (TCP/IP)...Properties..Advanced...Options...TCP/IP Filtering...Properties...Click Permit Only above TCP IP Ports..Add...80...OK..OK...OK...OK..OK...

God damn, How much more complicated could it possibly be!

And the only way I can possibly cons up this description is by doing it and seeing what I do when the problem comes up. Plus, it won't work on different versions of the OS. Sheesh.

[ Parent ]
M$ Visual FoxPro (4.00 / 1) (#45)
by farmergiles on Sun Feb 10, 2002 at 11:39:51 PM EST

Visual FoxPro comes to mind. Granted, it's a fairly narrowly focused app, being a database management tool. I haven't used it in a while but I remember it being one my favorite M$ apps.

It has a Command Window you can type commands into. Any commands run from a button or menu are echoed to the Command window as cmdline input. Instant history. Learn by observing. Click the cursor on a previous command and <enter> to re-run. It re-echoes in the list. Click the cursor on a previous line and edit to run with different args or flags. Slick.

Now, I've gotten pretty good at manipulating history, up arrow and middle-button pasting in an xterm (love that middle button) but the folks who wrote the FoxPro Command Window wrote a sweet tool.

Output, you ask? FoxPro is one of those Windows apps you typically run full-screen, just because you have so much going on. It has its own desktop space. Output (stdout/stderr) goes there. It's just a big blank window underneath.

FoxPro is not the usual user-level app, I admit. But plenty of people struggle through making things work in Access, don't they? Anyone with a good grasp of Access can learn FoxPro. You can use a GUI to build sophisticated SQL statements and see them echoed to the command line. You can then cut-and-paste those. You can manipulate databases with a GUI and see the corresponding command-line in the little window. Who knows? A user, with a bit of encouragement, just might begin to enter the odd bit of command-line.

Anyone who wants to see a command-line built into a Windows app should take a look at FoxPro. It builds executable database apps. Or non-database apps. You get all your Windows system calls. It's not Perl/TK, but it is VB with balls. And a command-line. You can build those graphical executables on the frickin' command-line, if you want. It's the perfect front-end to M$ SQL Server.

Microsoft bought it to kill it and they can't. To know it is to love it.

---- "Hah!!" - James Brown ----------------------- farmergiles@prokyon.com ----
GUIs Considered Harmful (4.00 / 1) (#46)
by nr0mx on Mon Feb 11, 2002 at 01:42:56 AM EST

Go here for an article on the same topic by Tom Christiansen.

Concise and extremely well written ( as we have come to expect :) . IMHO, a must-read .



Not recognition versus *recall* (4.00 / 1) (#49)
by martingale on Mon Feb 11, 2002 at 06:59:45 AM EST

You describe the difference between the GUI and the CLI as recognition versus recall. I think you're not quite comparing the two paradigms equally. The first is, as another poster described it, a "point and grunt" interface. It's by definition limited to act upon objects that can be pointed out to the machine. The second (CLI) certainly requires recall, but I think you're missing the most important part: a basic form of regular expressions. Take these away from the shell, and you have a much less powerful, still recall-based, system. To paraphrase your example, with the reduced system, you'd have to type

> SetSettings AutoSpellingCorrection AutoPaperclipDude AutoGreenUnderlines AutoRedUnderlines AutoFileCorruption AutoSave "OFF"

instead of the simpler SetSettings Auto* (which requires a basic form of regexps). You'll note that without regexps, the CLI is a lot more similar to a GUI, which might require you to open a dialog and tick all the options that apply. This is also imho a much fairer comparison.

AFAIK, there is no GUI concept for representing object families in an abstract, non-interactive way, which the regexp gives us on the CLI. That's why the GUI feels to me and many others like we're stuck in babytalk. You can say things like: "I want to eat this", but not "I want to eat things like this every day".

The other vital thing that you missed and which the CLI offers, though here the GUI has a semi-equivalent, is hotkey-completion. In a shell, if I'm stuck, I type tab and the machine tries to guess what I'm trying to say. It's a bit like a conversation, when you're stuck on a word, and people around you try to help: do you mean this word, or that word? The GUI can't do this, but it can fill in defaults for the various elements in a dialog box, which is somewhat equivalent. If I'm honest, I'd have to say that I like tab completion slightly better, because its a more unified concept - a single key works for paths, program options, program arguments etc. With a GUI dialog containing default values, sometimes I must open a combobox, sometimes I choose a checkbox, sometimes I edit a text box.

Finally, and I'm just reminded of this by reading the title of my comment, both the GUI and the CLI depend on recall. For the CLI it's obvious, but for the GUI, think about context dependent popup menus bound to the left or right mouse button. They keep changing depending on the context (duh!), and it's quite a mental effort to remember how to find the particular menu with the particular option or command you want to execute. I'd say that's recall for you.



good points (none / 0) (#64)
by sawndust on Sun Feb 17, 2002 at 11:17:02 PM EST

regex and line completion are two nice things that many shells provide and have no direct GUI equivalent. To this list I would add many other things if we were to get down in the details. I chose not to hype up the command line because the benefits of a good shell are numerous and multifarious -- we'd be writing for weeks.

But while we're on the topic <grin>, one benifit that I feel is particularly fantastic is the general ability to pipe or route information from one system to another without worrying too much about the things that programmers tend to think about, such as data types, endianness, signed/unsigned, ...

Most of this crap goes away because we're dealing with text. Now it's no panacea, there's all sorts of problems with my last statement, but I think there is a little pearl of trutch buried in there somewhere. Ok, I've got to pull out of this or I'll be expostulating on the benefits of command lines all day.

Finally, your initial (and final) point about the importance of recall in a GUI is quite valid.

[ Parent ]
Keyboard Commando (3.00 / 1) (#51)
by priestess on Mon Feb 11, 2002 at 09:45:52 AM EST

The command like and the windowing system are already integrated aren't they? XFree was invented so I could run more Xterms surely?

On another, more relevent, note I can think of at least one really beautiful example of a CLI and scripting being integrated deeply into a graphical environment. One where a single key-press will take you from the graphics-and-mouse system into a keyboard-and-terminal system immediately, and take you back just as quickly. Everything that can be done with the mouse-and-graphics can also be done, though often with impossible levels of effort, in the console and the console offers extra power not available in the menus.

This example is Quake, and a good proportion of the game engines developed since Quake. It's probably worth taking the system and putting it into other apps. Pressing ~ in your browser drops down the console which lets you redefine what buttons do, lets you run JAVAscript and RegExp subsititions on the page. Use the console to pull out common entries into WebForms, and no doubt much more. Perhaps we should make that ~ key a global standard for 'Give Me A Damned Console'? Menu's become shortcuts to Console Commands, Button Clicks the same. It's how I'd build an application if I weren't just a web-monkey these days.

Pre..........

----
My Mobile Phone Comic-books business
Robots!
How I use a GUI (3.00 / 1) (#53)
by X-Nc on Mon Feb 11, 2002 at 10:15:21 AM EST

The platform I work on most is X11/UNIX (Linux & Solaris) but I also work with Win2k systems & the occational Mac. This is my normal environment -
  • Under X I tend to have at least one browser window open and a minimum of 6 xterms. I use the xterms for everything except browsing (vi for editing, pine for email, etc.).
  • Under Win2k I have one browser window open, one instance of Outlook (because I have to) and I've installed cygwin so I have at least 6 xterms open and do most of the work from them.
  • On the rair Mac box (MacOS 9 or OS X) I have... yes, you guessed it, one browser window and 6 or more xterms.
I work using ssh and command line tools mostly because that is what I've always been doing. When I started with Linux (v0.12) it was on the HJ Lu Boot/Root floppies so X wasn't an option. Now, I have been trying out Evolution for email on my main Linux system and it does have some niceties. It's almost ready to make me switch from pine.

Still, I can work faster and better from a shell prompt mostly because that's what I know best.

--
Aaahhhh!!!! My K5 subscription expired. Now I can't spell anymore.

Look at Maya (3.00 / 1) (#54)
by SIGFPE on Mon Feb 11, 2002 at 01:18:28 PM EST

An interesting piece of CLI/GUI integration is the compositing package Shake by Nothing Real (their web site is down as Apple just bought the company). Although everything looks, on the surface, to be drag and drop, at its core is a script driven engine. Every action you perform within the GUI translates to something in the scripting language and hence can be carried out from the command line down a vt100 (and occasionally is). A key reason for doing this is that work previewed in the GUI will then be run for real on a distributed "render farm". The internal state of the GUI tool must be reproducible in these remote machines without a GUI and hence the need for scripting. Something similar is true of Maya and other graphics packages used in the visual effects business. For any kind of bulk work a tool like Photoshop is completely useless
SIGFPE
Eariler discussion on the issue (4.00 / 1) (#57)
by Apuleius on Mon Feb 11, 2002 at 05:47:31 PM EST

can be found here.


There is a time and a place for everything, and it's called college. (The South Park chef)
humans have low bandwidth but can mak abstractions (none / 0) (#63)
by sawndust on Sun Feb 17, 2002 at 11:02:25 PM EST

Nice exposition. You could call that the "drying of the GUI", I guess someone has probably already coined that. It's getting less and less goo-ey and more and more solid.

Your concern about the limitations of the input and output devices being a driving force is interesting, and one that I have had as well. I wonder how much more capable humans are of spewing information though. Our exporting information bandwidth is only so large. For exporting text, I can type quickly -- I suppose talk faster if I talk real quick -- but not that much faster. And the faster I go, the less information per word there is, eventually it's just drivel, I can't produce (good) words that fast.

For communicating images and 3d geometries I can see potential for HUGE improvements in human bandwidth. I have no trouble conjuring up a nice scene or complex object in my head. But a very hard time communicating that to the computer.

I can also see HUGE potential in 'batch work' or tools, or abstractions. This is what I am driving at with the command line - the ability to link small useful things together arbitrarily at run time to do higher level tasks and possibly store them away.

The command line presents the ability to improve markedly through construction of higher level constructs and increased understanding over time -- the development of TOOLS. Modern GUIS tend to not have this concept. While that makes them simple for the beginner, it means there is a glass ceiling to how productive you can get. I think the command line excels here and with proper integration could allow productivity gains.

[ Parent ]
BeOS had this (4.00 / 1) (#59)
by Rizzen on Wed Feb 13, 2002 at 02:37:34 AM EST

Virtually everything in BeOS could be controlled via the CLI using BeMessages. You could write scripts to do anything you could think of doing with a mouse. You could poke applications for there settings interactively. You could change things on the fly. You could store virtually anything and everything in the filesystem's attributes and parse that from the commandline. The ultimate in "synergy" between the CLI and the GUI was attained in BeOS.

Byte Magazine has some great articles on BeOS by Scott Hacker describing the wonderful things you could do in BeOS using the bash shell, BeMessages, and some ingenuity. Too bad it never caught on. :(


The years of peak mental activity are undoubtedly those between the ages of 4 and 18. At age four, we know all the questions; at eighteen, all the answers.
Scot Hacker BeOS links (none / 0) (#62)
by sawndust on Sun Feb 17, 2002 at 10:36:27 PM EST

I went ahead and did some digging around based on this comment and scrounged up the following Scot Hacker Byte articles on scripting in BeOS: This list is not complete, but these are the ones that seemed most relevant to this topic from my quick perusal. To see all of Scot's articles for Be View you can go to Byte's Be View page.

While I would hesistate to say BeOS represents the "ultimate in 'synergy'" as you say, some of their features such as the "database-like" file system do seem like they could help patch some CLI/GUI rifts.

[ Parent ]
Ergonomics: which hand to use for the mouse (4.00 / 1) (#60)
by brenfern on Fri Feb 15, 2002 at 02:21:57 PM EST

I used to really hate GUI applications until I realised that, even though I am right-handed, I worked more productively using my left hand for the mouse.

Now not only is the QWERTY more central (reading from the left, I used to have QWERTY-numerics-mouse, now I have mouse-QWERTY-numerics) resulting in a better typing posture, but the distance from QWERTY to mouse is shortened, and I can use the computer whilst on the phone (the right ear is generally stronger in most people). Also I can tell when someone else has been using my computer as they always forget to put the mouse back to the left.

I would be interested if anybody knows of a foot-operated mouse.

I still heavily use the keyboard when I can as one can touch type, the CLI can be more declarative, less screen-state-dependent etc.

dvorak (4.00 / 1) (#61)
by sawndust on Sun Feb 17, 2002 at 10:04:58 PM EST

Have you tried Dvorak?

Though I've never tried one, I've heard some great things about the ergonomic benefits of Dvorak keyboards over Qwerty ones. Interestingly, Dvorak also designed one-handed keyboards for right- and left-handers. I wonder if you could somehow mount a track ball to the right or left of the one-handed keyboard for some high-power interaction.

[ Parent ]
The role of the command line in the modern GUI | 68 comments (51 topical, 17 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!