Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!spool2.mu.edu!samsung!munnari.oz.au!uhccux!uhunix1.uhcc.Hawaii.Edu!michaelh
From: michaelh@uhunix1.uhcc.Hawaii.Edu (Michael A. Hoffhines)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Another MPW 3.2 Shell wish...
Message-ID: <11189@uhccux.uhcc.Hawaii.Edu>
Date: 29 Jan 91 22:06:59 GMT
References: <1991Jan29.165442.2851@waikato.ac.nz>
Sender: news@uhccux.uhcc.Hawaii.Edu
Organization: University of Hawaii
Lines: 62

In article <1991Jan29.165442.2851@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
>[description of MPW3.2b active panes deleted]

>There is another way of doing this, and that's not to have an active
>pane as such. Instead, you display the selection in all panes where
>it is visible. And when the user executes a command (like Find)
>that would require autoscrolling to keep the selection visible,
>you simply scroll the pane that's showing a part of the file closest
>to the new selection. In other words, autoscroll the one that would
>require the least scrolling.
Disclaimer: I have not had a chance to play with 3.2b yet, so my comments
are based on LDO's description and imagination (or lack thereof). If I have
a couple of panes with the same file and do a find, I consider it a modal
activity on my part. My attention is on the active pane and I would not
like to have the 'non-active' pane start scrolling just because it happened
to be closer to the text searched for. These two panes may be on separate
monitors, one may be obscured by the other, or I might have the other one
carefully placed on a critical portion of the code I am looking at only to
have it scroll out of sight. If we are voting, I vote no.

This does raise a point in the more general context of IAC. If you were
editing a document in two different applications, would you expect the
selection and edits to occur in both of the panes as you describe for multi-
ple panes in MPW? 

Another thought. I can see all sorts of interesting expectations arising
when, for example, you have published a graphic from your
spreadsheet program and have subscribed the graphic in a word-proc doc. As
you edit the graphic you expect to see the changes in the wordprocessor's
copy naturally enough. Equally understandable, but in error (at least in 
the short term), is that you will also try to edit the graphic in the WP.

>Comments, anyone? It just seems to me the idea of an "active pane"
>adds another layer of modality we can do without.
Do you mean in general 'active panes' are an idea we can do without, or
just in MPW? In the same program? 

Modes are 'bad' IMHO only when they impeed us from accomplishing
our goal, by making us go thru lenghty back-out procedures, etc. In this
case, the 'mode' serves to direct my attention via visual cues - insertion
points, active scroll bars, etc - to, in this case, the destination of our 
keystrokes. The modal cues are key to working with all these windows, 
I wouldn't care to be without them.

This multiple window stuff is only going to get more complex. When we have
multiple windows from various applications, each with their own menus, I 
can't see how we can get rid of these cues without creating instant vertigo 
on the part of users - as long as keyboards are the principle input device,
that is.

Just my thoughts, Mike

 ---------------------------------------------------------------------------
 Michael Hoffhines               | INTERNET: michaelh@uhunix.uhcc.Hawaii.Edu
 ICS Department                  |                                           
 University of Hawaii            | Hey, hey, hey. Don't be mean. B. Banzai 
 ---------------------------------------------------------------------------

>Lawrence D'Oliveiro                       fone: +64-71-562-889
>Computer Services Dept                     fax: +64-71-384-066
>University of Waikato            electric mail: ldo@waikato.ac.nz
>Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00