[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Popup Menu Behaviour
From:       "Steven D'Aprano" <dippy () mikka ! net ! au>
Date:       2001-10-13 16:24:47
[Download RAW message or body]

First a disclaimer: I haven't run your simulation, and unless somebody
takes pity on this user (not developer) and tells me how to get java
working, I'm not likely to.

David Golden wrote:

> > How do you lose your place? I don't understand why this is a problem for
> > you.
> 
> It's not much of a problem.  Not a catastrophic end-of-the-world thing.  Just
> a minor niggle.  C'mon, you obviously _do_ lose your place momentarily, if
> the mouse pointer was in one place, and then is in another.  You need to save
> the state in your mind, then recall it.  That's work.

That's work? Oh boy, be glad you don't have a real job :-)

But seriously, no, you don't lose you place, because at all times the
mouse pointer is under the user's control. Your place might not be the
place you want it to be, but that's ok: using a mouse UI always means
moving the mouse from where it is now to where you want it to be. Its
not like you can't find the mouse for an instant or two.

I've seen enough programs that take control of the mouse out of the
user's hand (literally) that I'm extremely skeptical that your idea
could be a good thing.

> > Popups really should only be used for object-oriented type graphics
> > design, where the entire object is "my place".
> 
> And half the time, you pointer still ends up outside the original object.
> It's still annoying.   The "flying" popup could definitely be useful.

I don't like the idea for two reasons:

(1) its modal: the mouse works differently depending on whether there is
a popup menu on screen or not. The mouse is such a basic device that it
shouldn't be modal.

(2) how do you change you mind and back out of the pop up? You can't
move the mouse off the popup, because you can't move the mouse. Maybe
hit the Esc key, which should be supported anyway, but that turns an
optional extra for powerusers into a must-know for beginners. Or maybe
all popups should have an item "Cancel" or "Close popup menu", which
might not be a bad idea. But then you turn a natural action into
something relatively difficult: to make the popup go away now, you just
don't click on it. Under your system, you have to actively search for
the Cancel command and specifically choose it.

> > The GIMP's UI is an abomination, I *hate* it,
> 
> Yes.  I have introspected upon  my own usage patterns, asked people around me
> about it, and came to the conclusion  that _one_ of the many reasons I find
> the GIMP jarring is because of the way the menus work (having grown up on
> packages like DPaint, there's a whole host of other reasons I find the GIMP
> UI annoying...)  Even subconsciously, perhaps - one of the first things
> people I've watched seem to do after using a popup is move the pointer back
> to where it  was, even momentarily, as if they're trying to pick up their
> train of thought again.   Always remember that not everyone is as smart as
> you are. Thinking of it in computing terms, you're making the user's brain do
> a push/pop to it's short-term memory stack, which is more taxing.

Its always dangerous to make that sort of analogy. Have you considered
the possibility that users will still push/pop a location on the stack
*anyway*? It may be even slower, if the user subconsciously checks to
see if the mouse has moved before returning it, which means in computing
terms an IF THEN ELSE and one 2-D spacial comparison. Remember, our
brains don't run optimally compiled code...

This line is now moving out of the realm of useful discussion and into
ideal speculation. Without user testing, we won't know one way or the
other.



> > > The other possibility, simply warping the pointer back to where it
> > > started, also works, but feels/looks clunkier than holding the pointer
> > > and scrolling the menu underneath, IMO.
> >
> > What about mapping arrow-keys to the pop-up menu? That would have the
> > advantage of matching the behaviour of ordinary menus, and
> 
> Certainly.  There's no reason that can't be done too - except that the arrow
> keys are often customairly used for panning operations.

That's not an issue. Almost all operations that involve a selection (eg
click on a file in a file browser, select a file icon in Konq, etc)
allow you to change the selection with the arrow keys. Standard menus
support this behaviour. Why shouldn't popups?

> Hell, there's even a
> "menu" key on most keyboards these days - I have indeed used many
> applications in which it's most comfortable to use that key to bring up the
> popup, then use the arrow keys to make the selection 

I've yet to find an app that supports the menu key, so I don't miss it.

> -  but why not make it
> comfortable to use the mouse too?

I don't feel that its uncomfortable, except in the sense that pop-up
menus themselves are misused by many programs, *especially* GIMP but
others as well.


> > not introducing modal mouse behaviour, which is a bad thing. Sometimes the
> > mouse moves, and sometimes it doesn't...
> 
> The mouse still looks like it's moving, because its background is scrolling
> at exactly the rate the pointer moves - you'll have to try the demo to see the
> effect.  In fact, that's why it's less jarring to scroll the menu than warp
> the pointer - the _feeling_ of continuous mouse behaviour is preserved.

With the proviso about, I have to say: No, the mouse doesn't look like
its moving, because its NOT MOVING. Its still in the same place. The
menu underneath it is moving, not the mouse.

> In short, I'm not some mad popups-must-fly guy, I'm just pointing out a neat
> feature that one might want to think about making an option in some KDE/Qt
> applications.

And I'm not some reactionary conservative who is against any new UI
feature :-) Its just that I've seen lots of UI misfeatures become
implemented because they look "cool", and then become standard because
users get used to them. So I'm naturally skeptical about anything -- 

-- 
Steven D'Aprano

[prev in list] [next in list] [prev in thread] [next in thread]