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

List:       kde-usability
Subject:    Re: RFC: Restricting mouse in popup menus
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2005-05-19 11:36:41
Message-ID: 200505191336.41615.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 18 of May 2005 20:06, Diego Moya (a.k.a. TuringTest) wrote:
> On 18/05/05, ziga@mail.ljudmila.org <ziga@mail.ljudmila.org> wrote:
> > I beleive modal interface such as this is
> > universally considered a bad thing from user
> > interface point of view.
>
> Yes, it is. That's why I suggested turning it into a quasimode.
>
> A quasimode is, roughly speaking, "showing the interface only while a
> key -or button- is pressed". Pressing the Shift key to enter upper
> letters is a quasimode. Using Caps lock is a full mode.
>
> > How does one cancel the operation with mouse only?

 Hmm, I we're having a mostly theoretical discussion. Has anybody actually 
tried the patches?

> You click outside of the active area. But the problem is not that. The
> problem is that you are capturing the user so that, while the mode is
> active, any action not supported by the dialog/menu/mode is completely
> lost. This should never happen, as all input from the user should be
> sacred (is the only thing that can't be recomputed). In order to
> perform a different activity she previously has to actively dismiss
> the mode, instead of just starting the activity.

 ??? 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?

>
> You shouldn't design for a perfect user, one who always knows the
> perfect action to do and has in her memory the whole possibilities of
> the interface. You should design for a user who changes her mind,
> forgets where commands are placed, don't know all the shortcuts or
> don't even know some "basic" techniques like "right click to open a
> context menu". An interface should always "degrade gracefully" when
> the most advanced techniques are not available for any cause (a
> dissability, a dirty mouse, a remote terminal).

 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. Users who wouldn't be capable of finding out clicking in the 
empty top area closes the menu (even if it would be somehow visually 
indicated) wouldn't be capable of turning it on either, so there's no 
problem ;). That said, I don't think this is rocket science (hmm, I'll have 
to try this with my sister, she'd make a good test user >:)  ).

> 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. And the main intention is to make navigation in popups _easier_, 
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.

 I thought you found changing/hiding the cursor good enough to avoid this 
perception problem.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
_______________________________________________
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]