From: "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu>
Subject: Re: <None>
X-Quoted: 37%
Reply-To: mvanheyn@whale.cs.indiana.edu
Organization: Computer Science Dept, Indiana University
Date: Tue, 13 Oct 1992 23:48:52 -0500

Thus said bcoleman@hayes.com (Bill Coleman):
>In article <1992Oct13.013543.13749@news.cs.indiana.edu>, "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu> writes:
[ speaking of filename completion ]
>> It does exactly what I expect.  
>
>Then you must not be human, because you are so infallable.

Not at all.  I expect it to inform me whether what I have typed so far
matches 1, >1, or <1 filenames.  It does that.  The way it does it is
clever in a CLI context.  It's not particularly so in a GUI context.
It hardly requires infallibility.

>> If you expected something different,
>> then, well, I'm sorry.  If you mean "it is not possible to fully predict
>> its behavior in advance unless you have a fully accurate mental model of
>> the system", that applies to a pop-up list too.  
>
>No it doesn't. Because when you look at the list (which is sorted, BTW)
>you quickly recognize if it doesn't match your mental model. With a CLI,
>you never have that benefit until its too late.

And, when you look at the list (which is sorted, BTW) that the shell
puts up of the possible completions (which is a lot easier to look at,
because it only includes the few files which are possible completions of
what you've typed so far instead of all of them and making you scroll
down in the window to find the right one and...) you quickly recognize
if it doesn't match your mental model.

>> Well, the "waiting for response" thing is silly, since it's typically
>> instantaneous.  
>
>The computer response might be measured in microseconds (perhaps a few
>dozen milliseconds, but the human recognition of that response takes a lot
>longer, particularly if you don't know exactly what to expect. Indeed, if
>you get an unexpected response, then you sit dumbfounded for a moment trying
>to get a handle on the situation.

Depends what level you want to consider it on.  The basic task I expect
it to perform is to inform me of whether the pattern matches 1, >1 or <1
files.  The algorithm for that is simple

If it doesn't beep at you, n=1 and you win the alleged slot machine.
If it does, if there is no other output on tab, n<1 and you screwed up.
If there is output, n>1 and you need more characters to disambiguate.

Recognizing the presence or absence of audio and of text is not a very
slow task cognitively.  Reading the text, if it's necessary, is a little
slower, though it isn't always necessary.

This, however, is a slightly arcane and weird ritual for typing
filenames.  It's an improvement over simply typing stuff in a CLI.  It's
probably not an improvement over the Mac way, at least for a typical
user.

>> It's much faster than the delay a Mac gives you after you pull down the 
>> cute menu and select "Open" and it takes a while to draw a nice window 
>> and put some spiffy buttons and an adorable scrolling window with the files 
>> in it.
>
>(Hang on to that cute, nice, spiffy, adorable thought)
>
>Not at all. While you do have to wait for the list, once you get it, there's
>no confusion. You know exactly where you are, what files are available,
>and if you are specifying a file to read or write. The lack of ambiguity 
>more than makes up for the time needed to display the list.

And the time to read the list, and to scroll up and down the list to
find the appropriate item because the darned window is too small to show
all the files in that folder even though it's only using a little
portion of the middle of the screen and should be able to be big enough
to display everything at once...

>You seem to be measuring the wrong things. It appears that any delay in
>the computers response is unacceptable, regardless of how that response
>may subsequently delay the HUMAN response.

Not really.  It's just that scrolling lists are not practical within a
CLI, whether they're desirable or not.  I've already said that I think
the Mac way is better for many purposes and for most users, if you
assume that you have the luxury of a high-bandwidth graphical interface
between you and the user.

>> Do you really mean GUIs make things simple for all?  So, X is simple for
>> all? :-) 
>
>Smiley noted.
>
>Perhaps I should condition that as "good graphic user interfaces make things
>simple for all."

Oh, I thought you were going to rephrase it as "Proprietary,
hardware-dependent graphic user interfaces make things simple for all."
:-)

>> Anyway, I was just trying to mention that some untrue things about
>> completion were being said, and some opinions about it (e.g. it's
>> worthless in case X) being presented as fact.  There are lots of reasons
>> why Macs are lousy, but lack of filename completion a la tcsh is not one of
>> them.
>
>While I agree that lack of filename completion a la tcsh is not a Mac
>fault, I cann't agree with the prior assertion.
>
>Exactly whay do you think Macs are, as you say "lousy."
>
>And don't you dare say, "because there's no command line interface." Grrr.

The reasons I think that the Mac is not the Optimal Computer Which Will
Guide Us To Enlightenment are not terribly pertinent, but here are a few
if you really wanted to know.  I'm not particularly interested in
talking about them at great length though.

Well, I suppose the things that bugs me the most is the way that most
Mac applications are, in essence, applications.  They tend not to be
designed to be utilized as parts of larger tools, and they tend to be
designed such that non-interactive use is not a possibility.  They tend
to make it impractical to perform tasks which the programmer had not
anticipated at design time.

In principle, I suppose it might be possible to have lots of highly
configurable drag-and-drop apps, and maybe even to add scripting (I'm
not extensively familiar with the state of scripting on Macs, though I'd
be a bit surprised if there existed scripting that worked across all
applications.)  But the apps available today typically only perform the
function "foo" (where "foo" is a way of changing a file) as an option on
a menu (or a keyboard shortcut), without providing a good way to perform
"foo" on a large number of files, or to automatically "foo" an entire
folder at 6pm (because foo is so slow that I don't want to have to wait
for it to finish.)  Whether this is an essential limitation of MacOS or
simply a limit of most existing applications is an intellectual point.

I like being able to use computers remotely.  I should be able to cancel
batched print jobs from my home, for instance.

I like being able to cut and paste without using menus or keyboards
(i.e. I think mice need >1 buttons.)   Another side effect of 1-button
mice is that sometimes the target for a mouse (esp. in, say, MacDraw) is
very small and difficult to click on to drag successfully.

I think scrollbars are a waste of screen space in many cases, and make
it awkward to look at an entire long list.  The lack of proportional
scrollbars makes this worse.
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted

"James equal frothy DNA"        "Joyful Qatar headsmen."
		- my favorite anagrams of "James Danforth Quayle"