From: lfosdal@falcon.no (Lars Fosdal)
Newsgroups: comp.os.ms-windows.advocacy
Subject: Re: GUI+CLI= Good 4 U (was: Re: CLI advantages (was Re: Mac. bigot))
Keywords: GUI, CLI, Windows, Macintosh
Date: Fri, 18 Dec 92 11:03:55 MET
Organization: Falcon Information Services AS, Oslo, Norway

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.


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:

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

>>I agree with Mr.Vlcek on this matter.  A GUI is practical and effective
>>when implemented correctly, but also give you the "overhead" of having
>>to traverse several menulevels and dialog boxes, unless you decided to
>>put every command in one menu (God forbid) or all input in a single 
>>dialog.  For singular options or commands, this is not a problem,
>>but if you need to issue several commands, you have to explore the menu
>>once for each of them, and you run the risk of getting "mouseingytis" in
>>you right elbow.

>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.

The "correct" implementation of a GUI is often a matter of taste.
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.

Actual study menu (CLI commands in ()):

  Study
    Price
      Line chart (LC), Bar chart (BC), Candlesticks (CAN), LC Open (LCO), 
      LC High (LCH), LC Low (LCL), Hi/Lo values (HLV), Index (100)
    Channel
      Price Channel (PC), Trading Band Weighted (TBW), T.Band Exp.(TBE),
      Pivot Point Ch. (PPC), Parabolic Time/Price (PTP), Volatility Syst.(VS)
    Volume
      Volume (V), On Balance Volume (OBV), Equi-volume condensed (EQVC),
      Moving Average Volume (MAV), Negative Volume Indicator (NVI),
      Positive Volume Indicator (PVI), Daily Volume Indicator (DVI),
      Price/Volume (PV)
    Trend
      Moving Average (MA), Weighted MA (WMA), Exponential MA (EMA),
      Moving Average Distance (MAD), Directional Movement Index (DMI),
      Variable Alexander's Filter (VAF), Moving Average Alexander (MAA)
    Momentum
      Momentum (MO), Stochastics (ST), Slow Stochastics (SST), Percent R (PR),
      Hi/Lo Oscillator (HLO), Majority Rule (MR), Relative Strength Index (RSI)
      Volatility (VOL), Rate of Change (ROC)
    Reverse/Stop
      Modified Colver Method (MCM), Runaway Gap (RG), Pivot Point Reversal (PPR),
      Island Reversal (IR), Key Reversal (KR), Bull/Bear Hooks (BBH)
    Compare
      Compare (CMP), Compare Index (CMI), Difference (DIF), Relative strengh (RS)
    by Days (1D)
    by Weeks (5D)
    by Months (1M)

Put all these in a single level menu?  No way!
Also, the CLI commands are abbreviations of the study name, so they are
not hard to memorize.


>>When you have 40+ such commands, some of them with one or more parameters, 
>>that all may be combined, it's obvious that this will give you a hard time
>>searching the menus, even if the commands are grouped in logical groups.

>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.

>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.


>Check. New improved command line. What's this "prompter" thing exactly?

You guessed it: a "popup" dialog.  Just start typing your commands.


>>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.

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?.


>>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 ?

start 911231 1d lc ma 9 ma 18 w 2 2 v<Enter>

or   ( -> indicates mouse move/click )

->Chart->Start->Dialog:911231<Enter or click OK>
->Study->By days
->Study->Price->Linechart
->Study->Trend->Moving average->Dialog:9<Enter or click OK>
->Study->Trend->Moving average->Dialog:18<Enter or click OK>
->Chart->Sections->Layout->Dialog:pick style 2<Enter or click OK>
->Chart->Sections->section 2
->Study->Volume->Volume

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 !
If he does similar studies several times, the CLI commands will be in the 
CLI history, which is shared across the windows/sections.


>>  (of course, you may put your regular cmd's in a macro,
>>and you may also have a default set of cmd's that are applied 
>>automatically every time you load a new stock, bond or currency).

>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 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).


>>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 ?


>>(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 ;-)



>>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 :-)

Lars F.

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

--
/ Mr.Lars Fosdal, Software Developer, Financial Analysis Systems  /
/ Falcon Information Services AS, Stranden 1, N-0250 Oslo, Norway /
/ E-mail:lfosdal@falcon.no  Tel:(47-2) 831310  Fax:(47-2) 831290  /
-- All opinions are personal and does not reflect company policy --