ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/29/91)
I've been using version 3.2b9 of the MPW Shell for about 3 weeks now, and I think I like the way the split windows work after all... Just one user-interface issue: the editor maintains the concept of an "active pane", which is the one that displays the insertion point or the selection. Even if another pane is displaying the same part of the file, it doesn't show the insertion/selection, though it does correctly update as you make changes. Also, when you do a Find or other command that moves the selection, the "active pane" is the one that scrolls to the new position. 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. Comments, anyone? It just seems to me the idea of an "active pane" adds another layer of modality we can do without. 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
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (01/29/91)
In article <1991Jan29.165442.2851@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > 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. > > Comments, anyone? I don't think this is such a great idea. When I split windows, it's usually because I want one pane to show a fixed part of the file (a typedef or so), and another pane to work in. Matthias ----- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
michaelh@uhunix1.uhcc.Hawaii.Edu (Michael A. Hoffhines) (01/30/91)
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
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (02/01/91)
Lawrence D'oliveiro, Waikato Univer writes in a message to All
LDW> Instead, you display the selection in all panes where it is visible.
LDW> And when the user executes a command (like Find) that would require
LDW> autoscrolling to keep the selection visible, you simply scroll
LDW> the pane that's showing a part of the file closest to the new
LDW> selection. In other words, autoscroll the one that would require
LDW> the least scrolling
But that would seem random to the user: afterall she doesn't know which pane
is closest, so she will likely see an unexpected pane scroll to her selection.
The other way seems more intuitive. Modality is only bad if it gets in the way
of doing what you want, when you want it. As you can only click in one pane
at a time, it should make no difference as to how "modal" the interface is:
you have feedback from your cursor location as to which pane you clicked in,
and hence, which pane you will use.
Lawson
Of course, an option to "unfreeze" the un-used pane while doing auto-scrolling,
might be useful (if they both happen to point to the same part of the text)...
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org