Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!bellcore!spectral!sjs
From: sjs@spectral.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.windows.misc
Subject: Random UI issues
Message-ID: <18063@bellcore.bellcore.com>
Date: 26 Oct 89 17:03:16 GMT
References: <603@granite.dec.com> <1922@bacchus.dec.com> <1490@esquire.UUCP> <6564@ficc.uu.net> <17943@bellcore.bellcore.com> <6594@ficc.uu.net> <3400@crdgw1.crd.ge.com> <6647@ficc.uu.net> <3581@crdgw1.crd.ge.com> <6685@ficc.uu.net>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@bellcore.com (Stan Switzer)
Organization: Bellcore
Lines: 69

In article <6685@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> In article <3581@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes:
> > (I don't know what a "poke point" is.)
> 
> SCADA industry terminology for an active area on the screen, like a close
> icon on a window border.

Oh! A Button.  (Actually, "poke point" is a nice term: it's fairly
descriptive and unlikely to be confused with other things.)

> > 2) Many mouse based editors support single clicks to select a character,
> > and multiple clicks to select words, sentences, paragraphs or
> > entire documents.

Hmmm.  A closet SunView user.

> This doesn't have to be handled with timing, though. I use such a tool,
> and it works by seeing, on each click, whether you're still on the same
> character. If so it cycles the scope.

This is nice.  I assume that since a user coming back from coffee will
probably jostle the mouse a bit he won't be confused by an invisible
mode (i.e.: have already pressed the mouse twice, next press selects
sentence).

> > Any other action, like poping up a menu, really slows down the user
> > (With the exception of Don Hopkins Pie Menus, which can be
> > selected before the menu appears. You can even select an item
> >  from a nested menu before it appears!)
> 
> I've heard of these. They sound cool.

Make no mistake: they are.

> That's an implementation detail, then. On the Amiga, for instance, the
> menus don't go through the layers system: the screen is frozen while the
> menu is up, but because it's so fast the screen isn't frozen for very long.

Dubious advantage.

> Summary: let the user do whatever she wants, but don't require him to
> learn any more than select/perform/menu.

I'll buy this.

I had a friend in school who only had one arm.  You'd be amazed at
what a person can do with one hand if they have to.  I'm sure he loves
mice.  I doubt he's a fan of chording.

In article <3581@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes:
> I just had a flashback. I remember a conversation I had a year ago when
> someone was arguing that there was no need for more than one mouse button.
> My argument defending multiple mouse buttons is very similar to my defending
> chords and multiple clicks.

Here's an idea: just put wheels on the keyboard and use the whole
thing as a mouse!  You'd have plenty of buttons then. :-) :-)

A possible argument for the one-button mouse:  I just saw the new
lap-top Mac.  It uses either a trackball or a mouse (comes with both).
It is tricky enough to do pull-down menus and other click-drag-release
functions when there is only one button (on the lap-Mac, they have a
nice BIG thumb-button), on a three-button mouse you'd have to play
some ugly games to get this to work right.

Stan Switzer  sjs@bellcore.com
"Standing all in columns, / Waiting to make their pay.
 Makin' the nature scene, / Waiting for the day,
 There is no resistance to / the signs along the way."