ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (02/26/91)
> ... Now "Reply" is a real common function in a mail program. ...
When the user is comfortable enough with the command set of the tool to
know immediately which command they want, keyboard accelerators should
be provided. I don't want to my hands to have to leave the keyboard.
Waving the mouse around is in my opinion the last option of a desparate
user ;-)
-----------------------------------------------------------------------
Benjamin Ellsworth | ben@cv.hp.com | INTERNET
Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP
1000 N.E. Circle | (USA) (503) 750-4980 | FAX
Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE
-----------------------------------------------------------------------
All relevant disclaimers apply.
-----------------------------------------------------------------------nazgul@alphalpha.com (Kee Hinckley) (02/27/91)
In article <100920299@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: > >> ... Now "Reply" is a real common function in a mail program. ... > >When the user is comfortable enough with the command set of the tool to >know immediately which command they want, keyboard accelerators should >be provided. I don't want to my hands to have to leave the keyboard. >Waving the mouse around is in my opinion the last option of a desparate >user ;-) And accelerators are provided. However I still have to put the entry somewhere on the screen. And I still want the buttons, because mousing is actually somewhat faster when you are reading mail, since otherwise you have to tab to the message list window and scroll it when you want to browse around, and tab to the mail view window and scroll it around. All that assuming you know which keys on the keyboard scroll, since most times they aren't labeled as such. But we do make heavy use of accelerators (something which several GUI independant toolkits don't allow, I might add). However that still doesn't solve the problem. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
garya@Solbourne.COM (Gary Aitken) (02/27/91)
> Let me give a very simple demonstration of how a trivial > difference between GUIs can result in major changes to the underlying > application code. > Today I got mail from someone who had just played with another mail system > (with an OL GUI). She rather liked the way that some of the features worked. > In particular she liked the fact that it was easy to select Reply Sender or Reply > Every (or a few other options). This was done with an Abbreviated Menu > which showed the current default. The user can easily either just click and > release to get the default, or hold down to change it. > Now most GUI-independent interfaces implement this under Motif using an > OptionMenu. And in fact the two are very similar in concept. There is however > a major difference. In Motif there is no way of instantly selecting the > default option. If you just click, it uses the click-wait-click model of > menu selection. The menu pops up and waits, and you then select the item you > want (which will be under the cursor). Alternatively you can use the > press-drag-release model. You press, wait for the menu to popup (again with > the default under the cursor), and then release to select the item. > Now "Reply" is a real common function in a mail program. It's something the > user does a lot, and they don't want to have to think about it. Waiting > for a menu to popup requires thought. Not only that, it takes too much > time on older/loaded machines. As a result we've made Reply a button and > we'll probably allow the user to specify elsewhere whether they want it to > do a Reply Sender or a Reply Everyone. > A generic API is *not* going to paper over things like this. The generic API can certainly not decide to do this mapping for you. However, one needs to back off a bit and analyze the real problem. The real problem is, the user wants a mouse accelerator to an underlying menu. This could be the underlying menu in the abbreviated/option menu, or the underlying menu in a pulldown. Motif provides great support in terms of keyboard accelerators, but lousy (i.e. none) support for mouse accelerators in this case. It would be fairly easy to do, simply extend the paradigm to allow some modifier of mouse button 1 to fire the default, and some other modifier could be used to set it. It would also be easy to do by allowing a resource to be specified which caused click to fire the cell rather than bring up the menu, allowing the menu to come up only on a press. Wake up, OSF! What to do about it in an application given the current toolkits? 1. If splitting out the extra button looks good and you have the screen space, do it in both models. The primary reason for using an abbreviated/option menu is to conserve screen space/clutter. If it looks good, expand it out. You could claim that is "least common denominator", but it is actually just good design in this case. 2. If you have clutter / screen space problems, you don't have much choice if you really are concerned with the clutter/space. You have to use the abbreviated / option menu and live with its limitations in each model. Beat on OSF to provide a spec, even if they don't have time to do it themselves, so other toolkit vendors can to it right. -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: !{boulder,sun}!stan!garya
garya@Solbourne.COM (Gary Aitken) (02/27/91)
> When the user is comfortable enough with the command set of the tool to > know immediately which command they want, keyboard accelerators should > be provided. I don't want to my hands to have to leave the keyboard. > Waving the mouse around is in my opinion the last option of a desparate > user ;-) Unless, of course, you can't type worth a damn, in which case what you want is MOUSE accelerators. For some things, like certain scrolling situations, it's far faster than keyboard accelerators. Ever used the middle mouse button in a Motif scroll bar to get you somewhere fast? -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: !{boulder,sun}!stan!garya
nazgul@alphalpha.com (Kee Hinckley) (02/28/91)
In article <1991Feb27.001706.22673@Solbourne.COM> garya@Solbourne.COM (Gary Aitken) writes: >What to do about it in an application given the current toolkits? > >1. If splitting out the extra button looks good and you have the screen space, >do it in both models. The primary reason for using an abbreviated/option >menu is to conserve screen space/clutter. If it looks good, expand it out. >You could claim that is "least common denominator", but it is actually >just good design in this case. > >2. If you have clutter / screen space problems, you don't have much choice if >you really are concerned with the clutter/space. >You have to use the abbreviated / option menu and live with its limitations in >each model. Beat on OSF to provide a spec, even if they don't have time to >do it themselves, so other toolkit vendors can to it right. Clutter is definitely a problem, and of course beating on OSF is something I do all the time :-). My main point still stands. Virtual toolkits do not solve the problems created by a complex application. The designer must look at the L&Fs *and* the implementations provided under each GUI and made the design and/or coding tradeoffs that are necessary. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/01/91)
> Unless, of course, you can't type worth a damn, in which case what > you want is MOUSE accelerators. Learn to type; you'll never regret it ;-) I hate mouse driven interfaces. They exacerbate my tendonitis in my wrist. I think that the "drag" operation ought to be outlawed by OSHA. > ... Ever used the middle mouse button in a Motif scroll bar to get > you somewhere fast? As a matter of fact, I have. I wrote that code (the motif scrollbar code which allows that behavior). I'm glad to hear that you like it. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/01/91)
> ... And I still want the buttons, because ...
The traversal model provided needs work. I think that a well written
traversal interface coupled with a keyboard proficient operator will
beat a mouse interface every time.
Unfortunately the style that Motif emulates in this regard is not what
I consider very good (barely adequate is my opinion).
#ifdef _BROAD_TANGENT
What occurs to me is that what we really need is to attach the X
"focus" to the user focus. The focus ought to go to where I'm looking.
The ideal traversal model needs to use some of the same technology that
the military uses for targeting.
Anybody out there want to build and market such an input device? I'll
buy at least one.
-----------------------------------------------------------------------
Benjamin Ellsworth | ben@cv.hp.com | INTERNET
Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP
1000 N.E. Circle | (USA) (503) 750-4980 | FAX
Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE
-----------------------------------------------------------------------
All relevant disclaimers apply.
-----------------------------------------------------------------------pds@quintus.UUCP (Peter Schachte) (03/01/91)
In article <100920299@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: >When the user is comfortable enough with the command set of the tool to >know immediately which command they want, keyboard accelerators should >be provided. I don't want to my hands to have to leave the keyboard. That's true, bug it goes both ways: sometimes I don't want to have to take my hand off of the mouse. But I don't want to have to pull down a menu, drag down to the item I want, and release. Too slow and clumsy. I think Open Look's solution is good, or else pop up menus that come up with the mouse near the item you often want. In the case being discussed (replying to a mail message), it's probably not so important since you're going to have to type a reply anyway, but often it's a nuissance to move your hand from the mouse just use a keyboard accelerator. Ideally, an application provides for both convenient keyboard-only operation and convenient mouse-only operation. -- -Peter Schachte pds@quintus.com ...!{uunet,sun}!quintus!pds
nazgul@alphalpha.com (Kee Hinckley) (03/02/91)
In article <100920304@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: >What occurs to me is that what we really need is to attach the X >"focus" to the user focus. The focus ought to go to where I'm looking. >The ideal traversal model needs to use some of the same technology that >the military uses for targeting. > >Anybody out there want to build and market such an input device? I'll >buy at least one. They exist. It's a mouse substitute that straps to your head. I believe that someone has also made one that sits on the monitor and tracks your eyes - but that's a lot more expensive (and probably jitters around too much). -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
adrianho@barkley.watt.berkeley.edu (Adrian J Ho) (03/02/91)
In article <100920304@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: >What occurs to me is that what we really need is to attach the X >"focus" to the user focus. The focus ought to go to where I'm looking. >The ideal traversal model needs to use some of the same technology that >the military uses for targeting. Here's a few situations when it's *not* suitable: 1) You're not a touch-typist. Then you'd be looking at the keyboard and that's where the focus will be. 8-) 2) You're a secretary, or anyone who *can* touch-type but has to transcribe printed matter to electronic form (you only need to do this once for user focus to become a *major* annoyance). Then you'd be looking at the printed matter, with the same effect as (1) above. 3) _____ (fill in the blanks, there are probably more examples) For user focus to be truly workable, you'd have to be able to lock and unlock it at will. Means a footswitch, probably, or a key-combination (urk!) unless someone can come up with a working, *remote* biofeedback sensor (no way you'll catch me sticking wires on myself at work 8-). Of course, everything I've said could be hogwash, but I'm sure there's a kernel of truth somewhere in there. 8-) >Anybody out there want to build and market such an input device? I'll >buy at least one. I probably would, too, provided the engineering problems outlined above have been solved.
marbru@attc.UUCP (Martin Brunecky) (03/03/91)
In article <100920304@hpcvlx.cv.hp.com> ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) writes: > >The traversal model provided needs work. I think that a well written >traversal interface coupled with a keyboard proficient operator will >beat a mouse interface every time. > >Unfortunately the style that Motif emulates in this regard is not what >I consider very good (barely adequate is my opinion). > Well, better something than nothing -). Without digging in your broad parallel, I have done something that may be close to your suggestion of moving the keyboard focus with the user's attention focus. I have written (several)subclasses of XmPushButtonGadget and other widgets which attempt to "merge" the "Explicit" and "Real Estate" focus models. For lack of better names, the resource which controls this behavior is called WsNpointerTraversal. How it works. Focus is controlled with Motif traversal in "Explicit" mode, i.e. one object in my application has the focus and I can use arrow and tab keys to move focus from one object to another. Normally, Motif in this mode ignores mouse/pointer motions (unless I click == select something), and keyboard input is delivered to the "focus" object no matter where the pointer is. With "pointerTraversal", when I manage to find a mouse on my cluttered desk and move the pointer to another traversable object, the focus "moves with a pointer" - without clicking/selecting. But contrary to the "real estate" driven focus model, the focus ONLY moves to traversable objects. If no such object is hit the focus remains unchanged. The latter prevents situations like one where you want to enter data into a text field, but your pointer "slid" into it's prompt (label) which does not take it. Note that as soon as I quit moving the mouse, I can revert back to my keyboard and do the further focus moves with the keyboard. Which allows me to use mouse as an "accelerator" - to move fast where the kyboard traversal would be slow, difficult or not intuitive - and use the keyboard traversal for fine, local control. Gee. This is just an *idea*. But I should probbaly patent it, so I can later sue the company owning the Backing Store in case it catches on. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/09/91)
> Well, better something than nothing -).
Absolutely, and for displays with few controls, the model works just
fine.
---
Ben