From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: <None>
Date: 14 Oct 92 17:37:18 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct13.234943.2150@news.cs.indiana.edu>, "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu> writes:
> Thus said bcoleman@hayes.com (Bill Coleman):
>>In article <1992Oct13.013543.13749@news.cs.indiana.edu>, "Marc VanHeyningen" <mvanheyn@spinner.cs.indiana.edu> writes:
>>> 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 

But it is too late, because you've already started typing! You've already
input information with a flawed mental state. When the wrong (unexpected)
stuff pops up as a result of your typing, then you are confused.

If the list was displayed before you ever started typing, there's less
chance of confusion.

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

Once again, the CLI mavens are too narrowly defining "computer tasks"

Open up the task. The task isn't to match patterns.

The task is to input an existing filename (perhaps of a certain class). A
scrolling list works better than filename completion. Period.

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

Agreed. It isn't an improvement over the Mac way.

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

Well, if you already think you know what file to type -- you can always 
start typing. The selected file will quickly zero in to the file you want
(or at least something close to it). If the file name you want doesn't
appear after a few characters, you can quickly realise your mistake (like
being in the wrong directory)

What's more, you don't have to make the decision to commit to a match (by
typing <tab>), the computer matches continuously. As you type more characters,
it gets more specific.

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

I think that's a good assumption to make. After all, we are talking about
a computer interface to a user. Why not use the best thing available?

If a graphic user interface does a better job than a CLI, why not use it?
That's my original point. You don't find tcsh filename completion in a
Mac UI because it isn't needed.

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

Well, you used the adjective "lousy" in reference to the Macintosh.

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

I think I understand, depending on the model you are attempting to put
forth as "better."

Newton technology will probably take us to the next step in user interfaces,
where applications cease to exist, but blocks of "capability code" add
functionality to the interface. There's also a fundamental economic
problem here, since our computer software marketplace is gear to selling
applications. When we can break away from the application-context model,
computing will become more flexible. Agreed.

Now, if you meant to imply the Unix model of tools, I have to disagree.
The flexibility of Unix tools stems from the treatment of all data as
nominal text files. This was a giant leap forward in 1970, when all
data existed as text files. The same is not true today. By conforming
to the rigid, text in, text out model of applications, Unix tools can
indeed be combined in ways the programmer never anticipated.

But as soon as you throw graphics into the middle of that text stream,
the filters choke and die. New technology is clearly needed. The bar
needs to be raised.

> In principle, I suppose it might be possible to have lots of highly
> configurable drag-and-drop apps, and maybe even to add scripting.

Scripting is coming soon. I anticipate AppleScript shipping before the
next developers conference (May). Applications will still need to 
incorporate AppleEvent support to complete the utility of AppleScript.

> But the apps available today typically only perform the function "foo" 
> as an option on a menu without providing a good way to perform
> "foo" on a large number of files, or to automatically "foo" an entire
> folder at 6pm.

AppleScript should solve this problem. Frontier (from UserLand) and MPW
can partially solve this today.

> Whether this is an essential limitation of MacOS or simply a limit of most 
> existing applications is an intellectual point.

Good. Perhaps when AppleScript is available the Mac won't be quite so "lousy"
to oyu.

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

AppleTalk Remote Access combined with Timbuktu or CarbonCopy can achieve
this.

> I like being able to cut and paste without using menus or keyboards
> Another side effect of 1-button mice is that sometimes the target for 
> a mouse is very small and difficult to click on to drag successfully.

1-button mice are a feature, not a bug. I guess that's hard to grasp,
but it is true.

Targeting a small part of the screen is a matter of practice. Perhaps your
mouse speed needs a bit of adjusting to suit your taste.

Multiple button mice are available, as are alternate pointing devices 
(trackballs, tablets, light pens, touch screens) Perhaps one would be
more suitable to you.

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

If you have the extended keyboard (I don't) you can use them to move
the scrollbars, and sometimes you use some of the command-arrow combinations.
If a list is longer than the screen is tall, I don't see a real solution 
other than using a scroll bar.

As for proportional scroll bars, Apple looked into this. They did some
user testing, and found that proportional scroll bars confused users.
So again, it is a feature, not a bug.

Well, I'm glad to see that there isn't much about the Mac you find "lousy."
It makes me feel better. Perhaps in a short time, some of these problems
can be corrected.

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