Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rutgers!bellcore!dduck!michael From: michael@dduck.ctt.bellcore.com (Michael Muller) Newsgroups: comp.cog-eng Subject: Re: Multi-button mice (Re: Xerox sues Apple!) Summary: multifunctional cursor approach to multi-button scrolling Message-ID: <18787@bellcore.bellcore.com> Date: 11 Jan 90 13:27:19 GMT References: <172@comcon.UUCP> <7326@ficc.uu.net> <9320@hoptoad.uucp> <1989Dec18.081450.28019@psuvax1.cs.psu.edu> <4865.258f9c91@mva.cs.liv.ac.uk> <581@cadlab.cadlab.de> <14783@orstcs.CS.ORST.EDU> Sender: news@bellcore.bellcore.com Reply-To: michael@dduck.UUCP (Michael Muller) Distribution: usa Organization: Bellcore, Piscataway, NJ Lines: 89 In article <14783@orstcs.CS.ORST.EDU> rudolf@satchmo.UUCP (Jim Rudolf) writes: >In article wjh+@andrew.cmu.edu >(Fred Hansen) writes: >>On my favorite editor a click on the left button scrolls forward by the >>distance between the top of the window and the place where I click. A >>click on the right button goes the other direction. As a result, I can >>leave the mouse in one place and move about the document. > >Sure, this is a convenient setup to have, but what do you suggest for >folks like me who only use those types of editors occasionally and who >for the life of us cannot remember which button scrolls which way? Short >of labelling the buttons, I don't know of any way to intuitively assoc- >iate a button with a scrolling direction. In our multifunctional cursor work, we would not assume that we could figure out the "correct" or "intuitive" association of buttons with scrolling directions. Instead, we'd put icons indicating scrolling directions unambiguously in the cursor image (but only when the cursor was in the scroll bar area). These might look like this (as before, please pardon my character rendition of a graphical cursor): /\ ///\\\ /////\\\\\ +----+----+----+ | | | | | /\ | \/ | P | (P might mean "move Proportionately ...") | | | | +----+----+----+ (We'd also permit the user to rearrange the button functions according to her or his preferences.) This approach could also permit clear cuing of a double-click protocol, as well -- perhaps /\ ///\\\ /////\\\\\ +----+----+----+ | | | | | /\ | \/ | B | (Single clicks -- line-oriented scrolling) | | | | (B = Beginning of Text) ++----+----+----++ || | | || || /\ | \/ | E || (Double clicks -- page-oriented scrolling) || /\ | \/ | || (E = End of Text) || | | || |+----+----+----+| ++--------------++ But this would only make sense when the cursor was in the scrolling area. At other times -- e.g., when the cursor was in (one of the) work pane(s) of the application -- its button functions would be related to the domain of of that pane, and the button-specific icons would change to represent those (user-selected?) domain functionalities. Style note: I've drawn these cursor templates with the hot spot at the top, as in most of our work. But for scroll bar use, we might prefer a more "modern" styled, side-pointing cursor shape, with the hot spot at the upper right -- for example -----/ ----/| +--+--+|| | | ||| +--+--+|| | | | +--+--+ Hmn, this _really_ looks much better in a graphic rendition; lets try ...... ...... ......... . . ... ......... . . . ....... Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com