Suggestion: UI keyword in subjects.

Lukas 1lukas1 at gmail.com
Thu Aug 5 18:20:33 CEST 2010


On 5 August 2010 17:51, Thomas Lübking <thomas.luebking at web.de> wrote:

> I'm not really sure about the meaning of "accidental clicks", but 900ms is
> a
> quite long time.
>
Current default toolbar has a great feature letting users to drag songs to
do previous/next track thing. On some touchpads its realitviely easy to drag
too far away (one of the reasons I use USB mouse), thus getting over volume
control. In this case it's sometimes possible to click on it accidentally.
But its just a edge case, and animated increase (interesting idea, Thomas
:)) would solve this in a proper way. (0.9s was just an example time)



> > * displaying volume level in the centre of wheel, while hovering "active"
> > area, so giving additional feedback what wil happen if you click here
> You mean when hovering the ring area (currently only hinted by the cursor
> shape)
> ....
> I'd prefer to remove the tooltip and use the button area instead

+1 for button area


 The eardrum thing sounds resonable ;-)
> I'd however suggest to start an "animated" volume increase nevertheless (as
> long as the mb is down) @ eg. 1%/50ms resulting in 20%/second
>
As I've said, great idea + using a some sort of log (time) multiplier to add
some acceleration would be very intuitive way (sec


Notice that aside this (the coolbar draft includes a similar approach - the
> slider animatedly slides out of the icon and replaces the other content,
> don't
> think i've ever commited that, though) the _severe_ drawback of hover
> interfaces is that they o not work with "absolute" input devices like
> touchscreens or pens (in absolute, ie. not mouse emulating, mode)
>
> This is not a big deal for sheer feedback, BUT if the functionality of an
> elemene relies on this, one explicitly excludes a group of users.
>
As tablets getting into marker quite fast, is it really good idea to make
them eliminated?



>
> The flickeraffinity of hover sensitive elements (as the other Thomas
> pointed)
> is usually dealt with a timer and distance check (have a look at the
> coolbar
> in smaller sizes - that is committed ;-)
> This basically allows an unprecise movement "along" the slider and not
> really
> a problem.
>
I'll take a look, thanks for pointing me.

p.s. will it be possible to run Amarok (or any other KDE app) on
MeeGo/Android/Any other linux based mobile platform?

Lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20100805/52a0a6ce/attachment.htm 


More information about the Amarok-devel mailing list