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

List:       kde-usability
Subject:    Re: RFC: Restricting mouse in popup menus
From:       "Diego Moya \(a.k.a. TuringTest\)" <turingt () gmail ! com>
Date:       2005-05-19 13:36:15
Message-ID: 11ee049405051906366cdc8bf5 () mail ! gmail ! com
[Download RAW message or body]

On 19/05/05, Lubos Lunak <l.lunak@suse.cz> wrote:
>  Hmm, I we're having a mostly theoretical discussion. Has anybody actually
> tried the patches?

Yes, this is theoretical. But I have good imagination, and I'm pretty
good at figuring out how an interface will "taste" before using it.
;-)

Truth is that it doesn't matter what I or you would think of it, the
real test will be to throw this into some "real" users (i.e. non
programmers), because they don't *use interfaces*, they *accomplish
tasks*. They don't have consciously in mind the behaviour of the
widgets that they are using, and because of this their subjective
judgement is a much better indicator of their quality .


> On Wednesday 18 of May 2005 20:06, Diego Moya (a.k.a. TuringTest) wrote:
>  ??? I completely fail to follow you here. Popups always grab input. The only
> actions that are possible with popups are selecting an option or cancelling
> the popup. You cannot do anything else while a popup is open. How exactly
> should limiting mouse area only to the popup change anything about that?

It's no different. Popups that capture the user and lose her input are
also bad. That's why modal dialogs are now regarded almost always as a
bad thing in interface design.

When watching normal users, I've seen many initiated actions being
lost because the user forgot to close a previously open context menu
before starting the new action.

A single error like this is not severe, but many of them are
annoyances that add up and cause frustration at the end of the day,
making for an unpleasing interface. Joel on Software describes it
well:

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html


> > So, if you're going to restrict the movement of the cursor over the
> > screen, do it *only while the user is actively requesting it with the
> > mouse button*. As soon as the user releases the button, the cursor
> > should be able to move freely again.
> 
>  The user actively requested doing so by opening the popup, that should be
> good enough. 
But then you're overloading the user short memory with that
information. In the (not so rare) cases when the user changes her mind
and wishes to start a different task, she first must remember that she
is inside the "restricted mouse movement" mode and dismiss it.

This is bad interface design, according to cognitive science: the
interface gets in the way of the user's task. The user's memory is not
a First-In-First-Out queue: a change to a new goal will wipe out all
previous short-term contents, and this will cause problems if the
interface forcing her to do something that now is not in her mind.


>  Actually, the original intention was to design this for the (*cough*) perfect
> user, or at least for the user who'd be capable of finding the option and
> turning it on. 
There is no such thing even as a *cough* perfect user, because 1)
humans do not perform always at their maximum, and 2) humans shouldn't
be expected to follow exact procedures/methods/subroutines. An
interface difficult to use should only be activated when actively
requested (and this means *only as long as the user's attention is
centered on it*), not turn on once and then always present. That's why
I think that your special mode should only be active while the button
is pressed.


> not to help developing RSI. Just try navigating e.g. in the K-Menu for a
> while with the mouse button pressed, and you'll see what I mean (well, at
> least now my hand hurts a bit). Also, it's also simply not technically
> possible - if the mouse button has to be pressed, how will one click in order
> to open the submenus? Otherwise the advantage is lost.

Agreed that my "quasimode" proposal would be best for small context
menus, and maybe not so good for the bigger application main menus or
the K-Menu.


>  I thought you found changing/hiding the cursor good enough to avoid this
> perception problem.
> 
Hiding it would be enough, because then you aren't "capturing the
cursor". Although it's still a mode, with all the related
task-switching problems.

Just changing the cursor shape won't be enough if you allow the cursor
to remain captured after the initial click is released: restricting
the mouse to a small area causes a BAD, BAD impression, is terrible
for consistency and user's sensation of "staying in control".


>  People do actions noticeably more often than just select, if I'm not
> mistaken, so they probably wouldn't be very happy to right-click all the
> time. Moreover, I personally have doubts about double-click replaced with
> compulsory press->select->release in menus being an improvements.

Press->select->release won't replace double click but "persistent"
context menus. "Double click the left button" would be replaced by
"Press->release the right button". My hypothesis is that the later is
easier than the former, and it's supported by the fact that double
click is difficult (and this is a direct result from usability
research).

My significant other ALWAYS selects first the desired object and then
invokes the action (either by double click or by opening a context
menu). This is not optimal, but I understand it: this behavior reduces
uncertainty on the resulting action. Is I previously said, left-click
is overloaded with too many meanings (single click to select, double
click for action, drag to move, and all of these change whether the
object has the focus or not).
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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