kcombobox wheelmouse scrolling

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 29 September 2002 02:53, Thomas Zander wrote:
> On Sun, Sep 29, 2002 at 01:09:24PM -0600, Aaron J. Seigo wrote:
> > On Sunday 29 September 2002 12:08, Thomas Zander wrote:
> > > I don't believe the solution of automatic definition of
> > > scrollwheel-scope will work; the solution presented (by Aaron) will be
> > > too subtile to become something the user learns as logical. If the user
> > > does not learn the 'mental-model' behind the GUI (s)he will not be able
> > > to forsee when to expect. In other words; the user will sometimes get
> > > unexpected results, and loose confidence in the GUI.
> >
> > the point is not to get the user to learn, but to have the UI react in a
> > way the user would expect it to, namely:
> >
> >  o if scrolling the web page, continue to scroll it
> >  o if purposefully positioned over a combobox, scroll it
>
> And my point is that you can never get software to follow the intentions of
> the user correctly; and if you can't do it correctly then your users will
> not like the way the system behaves.

can you please counter the reasoning offered above as opposed to generalizing? 
i offered a specific set of use cases which i modelled the solution around. 
either the use cases are incomplete or innacurate or the solution doesn't 
meet the use case requirements; please provide which it is.

i can see a possibility of a user using the scroll wheel to position the 
cursor over a combobox in a web page and then not be able to scroll within 
the combobox immediately; i can also see someone scrolling the web page and 
stopping directly over a combobox and then starting to scroll again later 
resulting in a scroll of the of the combobox instead. i'm not sure if either 
of these are common enough use cases, though.

i would offer that what i suggested would probably solve most of the issue 
without removing the nicety of combobox scrolling as it exists.

> Remember the excellent point Mathias said in relation to kwin 'I intent to
> implement focus follows mind soon'

no interface (using current technology =) can compensate for every user foible 
and mistake. people will click the wrong thing, people will move things they 
don't mean to, etc... user interfaces aren't like coding: unmet corner cases 
are almost always unavoidable. this doesn't mean we stop trying to make the 
interfaces useful.

> The mouse positon is not where the focus of the user is.

i beg to differ. the mouse position is the focus of the user when it is being 
moved. the mouse positoin is not the focus of the user (in the case of khtml) 
when the user is mouse wheel scrolling. that is why i used that as the 
differentiating factor in the use cases.

> > > And what about comboboxes that have a javascript 'onchange' event?
> >
> > if you position over them and scroll, they change...
>
> So, take the www.cnn.com site. It has a combobox on language selection. Do
> you think the scrolling via the mousewheel can be done in such a way that
> the user gets what he expects?
> Hint; waiting to think is not an option; the site allready refreshed to the
> language of 'your choice'..

that's why i suggested the following:

> > that said, the best would be if a selection is only made after a certain
> > period of innactivity, allowing the wheel to act like "spinning a dial".
> > the text entries would change as the wheel is spun, but only when the
> > wheel stops (as defined by a timeout period) would that selection cause
> > an effect to occur.
>
> Again; the changes that a mistake is made is high, the mistake will in lots
> of cases lead to a big confusion since lots of website go to a different
> page on selection.
> I don't think this is appriciated.

again, they would only spin the combobox if they positioned the mouse over it 
(avoiding accidental spin) and the selection would only take effect on a 
wheel event after a delay (a temporal manhatten length, if you will). 

and what if you click on the wrong item in the combobox because they are all 
stacked one on top of another? that happens too, yet it is accepted as a user 
mistake. we simply provide enough space between items to limit the accident 
to within reasonable tollerances.

right now, wheel selections have no such "spacing" (in this case temporal) and 
therefore are causing problems.

> I remember you once said that the choice should be made on merit. Does the
> addition of this feature (mousewheel in a webpage) give enough merit to
> allow potential confusion and the inevitable inconsistencies to exits?
> I tend to say 'no'.

except that i think it can be done such that there are few and perhaps in 
practice no perceived inconsistencies. between a spacial and temporal 
"manhatten length" we should be able to let the interface respond with good 
accuracy to where the users intended focus is.

saying "no mousewheeling in comboboxes" is simply another type of 
inconsistency (breaking with other scrolling widgets), so it isn't like we're 
getting away w/out inconsistency altogether.

barring any new information, i've said all that i have to offer on the 
matter.. anymore replies will just be reiterations of what i've already said 
=) so decide away...

> And I read enough Slashdot comments to know lots of
> people agree with me.

i don't know if i'd admit to basing my opinions on /. comments ;-P

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9l2+91rcusafx20MRApoPAJ4+Cjert6HgJdC+EyrDcfa3M1Pp6ACfaGV+
QoYvE8mnZswfatbF/r2ILW4=
=rx/O
-----END PGP SIGNATURE-----