Suggestion: UI keyword in subjects.

[Thomas Lübking]

Am Thursday 05 August 2010 schrieb Lukas:
> What about (some brainstorm in the morning):
> * adding ~0.9s time frame between the moment user enters radial area and
> actual sound level change In those 0.9s click would be simply ignored
> (mouse wheel, of course, would work as usual).
> This way accidental click should be prevented
I'm not really sure about the meaning of "accidental clicks", but 900ms is a 
quite long time.
"Normal" user feedback awareness time is 250-300ms (ie. this is the time for 
the even most untrained person to realize a "non stressfull" event, the rest 
of the famous "shock second" goes for creating and realizing the reflex and is 
mostly caused by the requirement to get rid of superflous adrenaline) - a 
skilled quake gamer can btw. realize /and/ react in less than 100ms, being 2.5 
cinematic frames ;-)

> * 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'm not sure whether to display this in the center or in the tooltip (since 
there's one)
I'd prefer to remove the tooltip and use the button area instead, but if we 
keep the tooltip it should hint all information (+bonus: tooltip can easily 
contain "Change to n%", whereas the button area is "limited")

> * allow at most 20-25% increase of sound level per click thus preventing
> accidental 20 to 100% increases (leaving lowering sound level without
> limits - it can't explode you eardrums)
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
This should a) protect the user, b) get him closer to what he wants and c) 
hint the "dial" nature of the thing.
The animation needs oc. to be broken on "significant" slider dragging (which 
is kinda protected anyway)

> As for slider on hover approach, its also option, but when creating hover
> effect of size 100*20px over 80*80px element, it either creates blinking -
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.

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.

Cheers
Thomas (need to activate my KDE gitorious account...!)