From: johnsd2@vccnw03.its.rpi.edu.its1 (Daniel Norman Johnson)
Subject: Re: GUI+CLI= Good 4 U (was: Re: CLI advanta
Reply-To: johnsd2@vccnw03.its.rpi.edu.its1
Organization: Sun Microsystems, Inc.
Date: Fri, 18 Dec 1992 21:38:35 GMT

In article 9c1yVB8w165w@falcon.no, lfosdal@falcon.no (Lars Fosdal) writes:
>Warning. This is a long article on GUI vs CLI.
>If this is not your "cup of tea", please skip it.
>To those of you that actually plan to read it; Sorry about the length.
>

Heh heh. Ill be trimming liberally, if you don't mind.

>johnsd2@vccnw05.its.rpi.edu.its1 (Daniel Norman Johnson) writes:
>
>>In article oHcTVB1w165w@falcon.no, lfosdal@falcon.no (Lars Fosdal) writes:
>>>vlcek@mtl.mit.edu (Jim Vlcek) writes:
>
>FYI: Some parts of the postings had to be deleted due to mail restrictions
>This is me
>>This was Mr.Johnson
>>>This was me
>>>>This was Mr.Vlcek
>
>Here we go:

Do we ever. :)

>>>> The notion that you can't combine a useful GUI and an effective CLI
>>>> into the same system is nonsense, 

[not somehting I ever said, incidentally. Hope I dont get accused of
doing so because I am with someone who agrees with this]

[deletia- GUIS have nested dialog/menu overhead when done right]

>>>I would hardly call that "correctly"; I loathe nested dialogs. And I'm
>>not too fond of heirarchial menus. But who said everything had to go in
>>those? Drop the occasional control into your window for instance.
>
>I already did that.  The most commonly used functions are already in the
>toolbar, and so is all of the drawing functions.

Ow. Well, I don't know all the details of your interface. I'll still
try to come up with improvements, but some will surely be gibberish
and other obvious ones I'll miss. Oh well.

>The "correct" implementation of a GUI is often a matter of taste.

Yes, that's true. But some folx feel they taste BAD :) and blame it on
certain aspects which I ->also<- think taste bad. I just don't feel those
aspects belong in the UI.

>Personally, I use nested menus/dialogs when the amount of choices would
>cause the menu/dialog to be extremely large, rather than having a 40 item
>menu or a wall-to-wall dialog.  Why?  I feel that grouping commands/ 
>options logically, makes the GUI a bit less intimidating.

I tend to agree, but it still sounds like you are using a limited set of
user interface thingies. Lets see:

>Actual study menu (CLI commands in ()):
>
[deleita- long menu, isn't it?]
>
>Put all these in a single level menu?  No way!

I was not suggesting it. That is one hell of a menu; I see why you
feel the CLI is faster in this case. It is, but I'd say that was because
your GUI was so awful here. (pardon me for being so blunt, but I've never
see a menu that nasty)

I dont understand what all these items do. Might I ask which ones produce
dialogs (modeless, no doubt)?

You say you have a toolbar; how big? Does it have menulike properties
(as some do)? tried floating palettes yet? Modeless dialogs that sorta
hang around alot? I presume if you've added any such, they know
enough to remember if htey were up when the program was quit, and
restore themselves. Or something along those lines.

It also seems to me that that menus deserves splitting up.

>Also, the CLI commands are abbreviations of the study name, so they are
>not hard to memorize.

This only makes it easier if you memorize the exact command names.

Its not a big improvement. imho.

[deletia- many commands = hard time]
>>Why? 40 commands isn't that many, in a good interface. You don't have
>>to keep your commands all in one place. Also, it may be possible to
>>consolidate commands and things like that. (depends on the app, of course)
>
>As you may have noticed, the 40+ commands are *study-only* commands.
>Cut/Paste/Print/Save/Load/Windowing/Setup/Drawing/Import/Export/housekeeping
>and so on are not included.

So I see; what are the other menus? (ie how many are there? Are the
just as bad?)

>>But perhaps you meant less elemental commands? (I was thining of things
>>as small as "add <x> to list views" or "lock file <x>" or "set window
>>color to <x>" or....
>
>These types of commands are (mostly) left to the menus/dialogs.
>There is no need to "clutter" the CLI with commands, so I've put in
>the commands relevant to the analysis of a price.

I was thinking of your GUI command count. I think you've got a very
similar idea of what a "command" is.

You've got quite a lot of them, but they do look like they could be
consolidated a bit- but perhaps not. I dont know enought about it yet.

>
>>Check. New improved command line. What's this "prompter" thing exactly?
>
>You guessed it: a "popup" dialog.  Just start typing your commands.

Yech. Why not modeles dialog? :/

(ps- I had not guessed that. Now I know)

>
>>>a typical command line would look like this: (prices are already loaded)
>>>                                  start 911231 1d lc ma 9 ma 18 w 2 2 v
>
>>Ah yes, command line interface at its best! :)
>
>Consider then, the number of mouse/menu manipulations you would have to do
>to execute the same commands ?  I'd call a CLI rational in comparision.

The sheer time requried to look up that junk easily outweighs it imho.
(as I no longer remembers what it DOES, I can't be sure but that's
how it seems)

Of course, Im used to rather quicker GUIs that the one you are talking
about. Perhaps it's different.

>Of course there are no absolutes.  I can't remember every available
>function in my libraries, but I can find them when I need them.
>As for *functions I use regularily*, I usually remember them.  Don't you?.

I remember them, yes, but I often must look up parameters etc.

>
>>>You still may go by menu, but for the experienced user, the CLI will
>>>be much faster
>
>>Why? Certainly it would not be for any operation they had not
>>memorized. Why would it be so for operations they had? All THAT
>>would mean is that they don't have to hit the manuals.
>
>Which would you prefer ?

[deletia- descriptions of CLI and GUI techniques in his prog]

I don't think much of your ui, as I said.

Minor nitpicks: why did you activate moving average, do something,
then close it, then do it AGAIN. Kinda kludgy. Why?

Im not sure but it looks like you should stick the "by days"
and "Line Chart" stuff ina floating palette, the layout dialog could
do that. What "style 2" is I dont know, but I am pretty sure it shouldnt
be called "style 2"; try a graphical representation.  Incidentally, why
do you have "Chart" and "Study" menus? Why not move everything up one
level?

I could probably come up with more, but not without a better
handle on your program.

>I can't be sure, but after watching our analyst, I'd guess the average
>broker would manipulate charts in similar way, up to perhaps 50-60 times
>a day.  That's a lot of mousing !

Yes. Its a great deal too much.

>If he does similar studies several times, the CLI commands will be in the 
>CLI history, which is shared across the windows/sections.

If he can figure out which is which.. :)


[deletia- macro? script?]
>>Sounds like a script to me. I'd rather have a somewhat friendlier way
>>to write one tho- those commands are rather cryptic.
>
>Script or Macro - the name makes little difference.

I think "recorded user mouse actions and keystrokes" when you say
"Macro"; perhaps you mean something else.

>I agree that the commands are cryptic at first glance, but as you could
>see above, every one is an acronym of the real study name, which should
>make it a lot easier  (Actually, we're have started to think about a
>"programming language", enabling the user to define his own studies).

As I said, I don't think it helps that much; it just means you must
memorize longer names, exactly so they can get the acronyms. And
they must remember the conversion rule.

>
>>>So, why not have the best of two worlds ?
>
>>I'm all for that, but I still don't like CLIs. My feeling is that the
>>"best" of the CLI worlds is CLI scripting, which I would certainly like.
>>But using a CLI as an interactive interface is a royal pain imho. I do not
>>see what is worthwhile about that.
>
>Well, I'm not trying to "convert" you, but I hope you see my point, even
>if we don't agree. GUI+CLI=Flexible ?

GUI+CLI = Flexible but Obnoxious in spots.

hows that?

BTW, are programs with GUI interfaces like yours commonplace 
where CLIs are availiable? I know X loves them, but its just awful
anyway. It looks to me like you feel you can use such a menu
structure because you have a CLI to fall back on. :/

>
>>>(Well, a CLI in Windows' Paintbrush might be a bit farfetched... :-) )
>
>>Save you from "mousitis" tho.. :)
>
>fill 40,80,100,100 with red color using blue border ?
>Naah! 8-} I'll just get Typitis Vulgaris Gravum ;-)
>

heh heh.

>
>
>>>Personally, I'd use any GUI or CLI, as long as it gets the job done,
>
>>But no preferences?
>>How can you flame without any preferences? :(
>
>Aha!  Gotcha :-D
>
>Perhaps I shoud add; "except the Mac GUI"...Naah...No. I don't think so :-)

heh heh.

>Lars F.
>
>- "Now... where was that article on voice controlled CLI's ?"

:)
---
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.os.ms-windows.advocacy