From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI  (there, I changed the subject ... )
Date: 12 Oct 92 18:22:30 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct10.004042.17093@news.cs.indiana.edu>, "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu> writes:
> Thus said bcoleman@hayes.com (Bill Coleman):
>>In article <1992Oct8.235008.14355@news.cs.indiana.edu>, mvanheyn@spinner.cs.indiana.edu (Marc VanHeyningen) writes:
>>> Thus said bcoleman@hayes.com (Bill Coleman):
>>>>Big deal. All it appears to do is save a bit of typing. Worse, it doesn't
>>>>help you unless you know how many characters to type to get a unique name.
>>
>>I was incorrect in my understanding, but my assertion still holds. (see below)
> 
> If you don't know how many characters to get a unique name, there are
> two possibilities:
> 
> - You type too many.  No problem.
> - You type too few.  The shell expands as many more as it can, beeps at
>   you, and gives you the chance to add more.  Slight inconvenience.
> 
> In neither case does filename completion "not help you" at all.

Except that it doesn't do what you expect. So to use this feature properly,
you have to type like a madman, then hit <tab> then what you see what you
got. In my mind, this is the user interface equivalent of a slot machine.
Sometimes it pays off, often not.

>>>>And what would happen if you had "Letter to Fred" as well as your
>>>>"Letter to Bob". This completion stuff wouldn't help you at all.
>>> 
>>> Yes it would.  It would complete "Letter to ", as much as could be
>>> completed unambiguously.  
>>
>>Ah! But that wasn't what you wanted. You wanted "Letter to Bob." You
>>typed "LE<tab><return>" thinking that it would be unique. It wasn't. Uh
>>Oh.
>>
>>This type of keystroke-saving "feature" is only useful if you have a
>>perfect image of what is in the current directory in your head, and can
>>compare the names to determine what is unique. Humans are notoriously
>>bad at these tasks.
> 
> This is only a problem if you hit <RETURN> too fast, before receiving
> the notice (often a beep) that the partial filename could not be
> uniquely completed.  

And that's exactly the problem. You might as well type out the whole
thing rather than waiting. This would be a simpler process than typing
some of the name, hitting tab, waiting for the response if that was enough,
typing more, hitting tab, etc, etc. You're better off just typing the
whole name.

> Any filename selection method can fail if you
> make the assumption that the user will blindly accept things without
> looking at them for even a nanosecond.

WRONG!

There's one file name selection method that doesn't suffer from this. If you
shown the file names in a list, or as symbols (perhaps icons), and select
one using a pointing device. 

You end up looking at the file name, but your view doesn't change, as it
would while you type, tab, type, hoping to hit the jackpot.

>>> You could then bring up a list of "Bob" and "Fred" with another keystroke 
>>> and type "B<tab>" to get it to work.  
>>
>>Oog. 
> 
> I'm sorry, that word is not in my vocabulary.  Is it some weird Mac term?

It is an onomatapea. (I hope I spelled that right) Sound it out. That was the
sound I made when my stomach churned after reading your description.

>>> Have you ever even used filename completion in a shell?
> 
>>Yes I have. The one I helped design didn't require a charcter to do the
>>matching. All matching was done continuously and instantaneously. (The way
>>it should be)
> 
> I take that to mean "Yes, but it was totally unlike the system being
> described."

Not unlike at all. But certainly simpler and easier to understand.

>>Yup. Sometimes you don't need to open things up. For example, go into any
>>Mac application bring up the standard get file dialog with File / Open. 
>>You can type in a name there, or use the mouse on the list, or type,
>>mouse and arrow keys in any combination.
> 
> For opening and manipulating just one file using just one application,
> yes, this is probably usually superior.  As the old quote goes, GUIs do
> make simple things simple.

I hate the term GUI. But yes, graphic user interfaces make things simple for
all.

However, in the example where you use file name completion, you were just
selecting one file (it could be an application).

>>With a visual interface, typing is eliminated. So, features to reduce
>>typing make no sense. Your original posting indicated that file name
>>completion was a feature that CLIs had that visual interfaces do not. Feature
>>counts don't necessarily help, since the feature not make sense in the other
>>interface.
> 
> That was not my posting, that was someone else.  Not all people who
> think there exist tasks for which existing CLIs are superior to the
> Macintosh GUI are the same person, thank you.

Sorry. I get confused sometimes.

> I generally agree with you that filename completion is much less
> applicable to a GUI than it is to something like tcsh, and that
> selecting a single file is, for the average user, often easier in a
> Macish way.

Ah! Thanks!

>>In both user interfaces, attempts are being made to streamline the
>>interface. If a visual interface requires lots of redundant pointing and
>>clicking, I'd say it was defective -- it would appear to need methods to
>>streamline use. 
> 
> So, how does one do composition of functions on a large number of input
> files on a Mac without redundant pointing and clicking?

The pointing and clicking is necessarily redundant. You aren't clicking the
same files, right? You are clicking a different thing every time.

Part of the solution to this problem isn't necessarily built into the system
(yet). If you want to do repetitive processing, perhaps Frontier can help
you. The best solution is to eliminate the repetitive processing in
the first place.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Newsgroups: comp.sys.mac.advocacy