Re: GUI vs: CLI

From: Corey Murtagh (emonk_at_slingshot.no.uce)
Date: 04/01/04 

Date: Thu, 01 Apr 2004 13:15:05 +1200

MSCHAEF.COM wrote:

> In article <406B15E3.54F62940@Sonnack.com>,
> Programmer Dude <Chris@Sonnack.com> wrote:
>
>>"MSCHAEF.COM" wrote:
>>
>>> If all you want to do is activate the tenth option in a
>>> dialog box, that's 9 tabs and a space bar.
>>
>>Properly done, shortcut keys can move the focus directly to the
>>control in question. So it'd be one Alt+key then [Spacebar].
>
> Assuming you have enough obvious letters to pick from. There's no easy
> fail over to longer keystroke sequences, which, as you point out below,
> does exist in CLI tools.

Actually there is, as already discussed: tab to the control and activate
it with the spacebar, type in it, or whatever.

>>The same option on the command line might be as simple
>>
>>> as -v or -O3.
>>
>>Or --dont_include_alternate_libraries
>
> At least in GNU tools, the longer names are intended for use in scripts
> (to improve readability) or in cases of infrequently used options.

Ah, right. Just like in a well-designed GUI the infrequently used
options are less likely to have an obvious shortcut. I can't remember
the last time I had to hit tab 32 times to get to one of those options.

>>>If you make the dialog box simpler by breaking it up into
>>>multiple sub dialogs, you've just made it more difficult to
>>>discover your options, which was the point of the GUI in
>>>the first place.
>>
>>If the app is so complicated that it takes multiple sub dialogs
>>to configure, then I can't imagine the CLI situation is going
>>to be any prettier.
>
> I don't buy it. I find compiler/build process configuration to be far
> easier when configured via text files. The options I need 99% of the
> time, I have committed to memory. For the remaining 1% I don't mind
> hitting the man page or documentation, since I really should be thinking
> hard about the need to the obscure option in the first place.

Similarly the compile/build options I use most of the time I've set as
defaults in my IDE. On the rare occasion I need to change them I can do
so in a couple of seconds with a small number of key presses without
using the mouse at all.

> Every time I configure my builds in Visual Studio I have to wade through
> such useful options as "Suppress Startup Banner", "Treat wchar_t as built
> in type", and "Merged IDL Base File Name". These are useful if you need
> them, but 99% of the time I don't, and the "easy discovery" of these
> features that the GUI tool provides just gets in the way in the common
> case.

There's your problem then. Microsoft isn't known for building
user-friendly interfaces. I prefer development tools that aren't
actively user-hostile.

>>The GUI puts it all in one place.
>
> Which is both a strength and a weakness.

As indeed could be said about commandlines, config files, batch scripts
and so forth. If you look hard enough you can find a weakness in anything.

>>Oh gimme a break. When you change the command line options your
>>users have been typing in using their muscle memory you will have
>>**exactly** the same problem.
>
> Sure, but it's a lot more likely that an ordinal number (the number of
> tabs) will change than a name (the letter assigned to the option).

Just as likely that the GUI will retain the same shortcuts. Just as
likely that the CLI version will discard an unused option, or change
what it does.

>>Or potentially worse if they actually hit [Enter] with the wrong
>>options. The GUI is maybe more likely to prevent that.
>
> You could also argue that a GUI (particularly multi-window or tabbed
> interfaces) makes it more difficult to scan all the options for
> correctness.

Ah, but the majority of humans are pattern oriented. It's simpler to
look at a good config dialog and see the pattern of the options than it
is to view a 3-line commandline and /know/ it's right or wrong.

See the problem? I prefer a nice graphical UI, you prefer a
commandline. The weaknesses in the one we choose aren't so important to
us, or we don't perceive them as weaknesses. It's all down to personal
preference at this point, and neither you nor I is going to change the
other's mind. You'd get just as far trying to convince me to use EMACS. 

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Relevant Pages

  • Re: Shaken, not stirred (Mini-rant)
    ... doesn't mean you need to stick with an easy distribution. ... Linux way" but the darn distros insist on using their convoluted GUI. ... hour I knew *exactly* what every line in that config file did and why it ...
    (alt.os.linux)
  • Re: GTK, Qt - how much more graph. libraries?? (some reflections on Linux)
    ... > the usefull stuff run more smoothelly without lounching different config ... It's that freedom of choice thing again. ... Applications run slow? ... xterm is useless on a system without a GUI. ...
    (alt.os.linux.suse)
  • Re: [OT] Debian mailinglists [was: RE: Debian or Ubuntu?]
    ... With a CLI login ... I also often look at a problem via remote viewing *and*, if appropriate, ... hand-holding GUI config, we cannot close our eyes to the fact that so ...
    (Ubuntu)
  • Re: Linux, fast
    ... tend to assume that I am root on the computer. ... in a home directory. ... it is good for, and use tty applications for the rest, including GUI ... has excellent readable config files. ...
    (uk.comp.os.linux)
  • Re: Settng Up Shortcuts To Command Line Programs
    ... >I want to setup a shortcut on my desktop to bring up the command line ... > shutdown GUI but when I do the dos window opens when the GUI come up. ...
    (microsoft.public.windowsxp.general)