First off, props for the 2.3 beta, Amarok keeps getting better and better.

However I believe the UI designers have made a big error here adopting a thumbwheel style volume control, one that ignores previous usability studies.

They've fallen into the classic trap of replicating a real world physical interface onto a virtual interface. It looks pretty and sort of familiar, but it breaks std KDE UI expectations (new interface for std behaviour) but more importantly - using a mouse is *not* the same as using your fingers, its extremely awkward to rotate using a mouse and provides no extra functionality - form over function.

I refer the designers to this excellent article on the Apple QuickTime 4.0 player which made exactly the same mistake.


From the linked Article:

The QuickTime 4.0 Player contains many examples of how the software must adopt the limitations of the physical device it is based on, but the first example the user is likely to discover is the volume control. Since a real-world hand-held electronic device typically employs a thumbwheel to control the volume, the designers concluded that it would work just as well in a software application. What the designers failed to realize is that a thumbwheel is designed to be operated by a thumb, not a mouse. Watching new users try to adjust the volume can be a painful experience. The user invariably tries to carefully place the cursor at the bottom of the exposed portion of the control, then drags it to the top of the control and releases, then carefully positions the cursor again at the bottom of the control, drags upward, and well, you get the picture.

The thumbwheel is the control of choice for physical hand-held devices for a variety of reasons: it functions in direct relation to the potentiometer used to vary the electrical signal, it is inexpensive, it is unobtrusive and unlikely to get snagged on other objects, and it responds well to a simple move of the thumb. None of these reasons relate to the interaction between a user and an image on the screen. It was selected merely to mimic the appearance of the physical device, and in this case, was a poor selection for the human-computer interface

I urge the designers to restore the familiar scroll bar volume control.


Edit:Removed the poll questions

You can use the slim toolbar if you don't like the new one. So much for user choice . Also, what "previous usability studies" are you referring to?

FWIW: Amarok needs to be usable on touch screens as well and by far not all are multi-touch capable.

FWIW 2: I have no problem at all to change the volume in the new toolbar, be this with the mouse, the trackpad or the Lenovo Thinkpad button. And the scrollwheel of the mouse works on the volume button, too. And there is the volume icon of Kmix in the SysTray I really don't see where there is a problem, sorry.

I really liked the new volume button. Works quite nicely.

And the new toolbar is better than the 2.2.2 one.

I was going to bring up the exact same article. There are several other problems with the new volume control:

1. There's not enough contrast to see what the current volume level is (especially in its default, non-highlighted state). Of course the volume icon already shows the approximate volume level, but still...

2. Because of the large vertical line, it looks somewhat like a previous button in the muted state. At least that's what first came to my mind. It doesn't help that the volume icon is basically a mirrored play icon.

3. Clicking (and holding the mouse on) the button changes the cursor to a finger pointer, but dragging doesn't change the volume. The play button doesn't do this.

4. You can click the border of the button to set a specific volume level. Putting controls this close to each other is a bad idea, especially for a touchscreen interface. In addition, clicking the button outside its center (but still well within the button itself) seems to do nothing but hide the volume level indicator. It doesn't mute the music or change the button icon. This might be a bug, but it prevents accidental misclicks. It's not the ideal solution of course.

knn wrote:1. There's not enough contrast to see what the current volume level is (especially in its default, non-highlighted state). Of course the volume icon already shows the approximate volume level, but still...

Already fixed. This was a Beta, remember?

markey wrote:

knn wrote:1. There's not enough contrast to see what the current volume level is (especially in its default, non-highlighted state). Of course the volume icon already shows the approximate volume level, but still...

Already fixed. This was a Beta, remember?

Well, I installed the latest version from git, so here's an update:

1. The default state is blue now, but it's still barely distinguishable from the darker background at the top. The hovered state isn't much better either.

2. The same.

3. Fixed.

4. Now clicking outside the mute button manipulates the volume level. Which is even worse, because now you'll be setting the volume level when you intend to mute.

Look at this screenshot: Instead of muting like you would expect, this will make the music louder, even though the mouse is well within the button.

knn wrote:Look at this screenshot: Instead of muting like you would expect, this will make the music louder, even though the mouse is well within the button.

Yeah, this has been puzzling me too. I think it's a bug. Or if it's not a bug, it should be changed...

knn wrote:4. Now clicking outside the mute button manipulates the volume level. Which is even worse, because now you'll be setting the volume level when you intend to mute.

Look at this screenshot: Instead of muting like you would expect, this will make the music louder, even though the mouse is well within the button.

There's some contradiction between the both paragraphs, however:
you should get a pointing hand cursor whenever* you can manipulate the volume level (by sliding as well as a single click to jump to the exact position, default dial behaviour) - otherwise the button toggles mute, so clicking from the state in ths shot should definitly toggle mute.
If this is not the case, there's a bug that i cannot reproduce here.

Does the pointer change it's shape during _unpressed_ hover moves?

*approx. the outer 3rd of the radius

thopmasl wrote:

knn wrote:4. Now clicking outside the mute button manipulates the volume level. Which is even worse, because now you'll be setting the volume level when you intend to mute.

Look at this screenshot: Instead of muting like you would expect, this will make the music louder, even though the mouse is well within the button.

There's some contradiction between the both paragraphs, however:
you should get a pointing hand cursor whenever* you can manipulate the volume level (by sliding as well as a single click to jump to the exact position, default dial behaviour) - otherwise the button toggles mute, so clicking from the state in ths shot should definitly toggle mute.
If this is not the case, there's a bug that i cannot reproduce here.

Does the pointer change it's shape during _unpressed_ hover moves?

*approx. the outer 3rd of the radius

Yes, most of the time the pointer correctly changes to a hand when you're over the slider's hotzone. In this case, I think clicking it changed it to the standard pointer.

Regardless, that's not the point. The pointer changing doesn't provide enough visual feedback, and until you figure out that hand == change volume you won't know where to click. It also looks like you're clicking the button, yet you're not, so the more obvious visual feedback is contradicting the actual behavior.

This post seems more and more to turn into bikeshedding.

To solve this, we can add a tooltip: "Volume: 95% / turn the wheel" and "Mute: 0% / Click the icon" in two lines. The current tooltip for Mute says "Volume: 0%" which seems misleading anyway. Does that make everybody happy? But keep in mind that we are in string freeze, so this has to wait for 2.3.1 anyway.

Mamarok wrote:This post seems more and more to turn into bikeshedding.

To solve this, we can add a tooltip: "Volume: 95% / turn the wheel" and "Mute: 0% / Click the icon" in two lines. The current tooltip for Mute says "Volume: 0%" which seems misleading anyway. Does that make everybody happy? But keep in mind that we are in string freeze, so this has to wait for 2.3.1 anyway.

No. Clicking on the button should click the button.

Besides, you ignored my original post. For example you said "Amarok needs to be usable on touch screens as well". How is this usable on a touch screen where clicking (with a finger) is less precise than with a mouse?

i like the wheel but i think it should work a bit different.

the mouse wheel should work as is by changing the volume.

a single click anywhere on it should mute unmute

a click hold should allow you yo change the volume.

when changing the volume you should have to move the mouse in a circle around it just move the mouse left or right or up and down.

for example that a look at applications like pro tools that use lots of knobs they use all of theses functions and are quite accurate and work well.

knn wrote:Besides, you ignored my original post.

Noone ignores anything here :-P

knn wrote:1. There's not enough contrast to see what the current volume level is (especially in its default, non-highlighted state). Of course the volume icon already shows the approximate volume level, but still...

The main purpose is to change the volume, i.e. act as slider, not as indicator (what's just a "nice-to-have")

Reason: the important and only valid indicator for the current volume are your ears, as the actual volume depends on
a) amarok's volume
b) the master volume
c) a gain flag on the file
d) the gain of you line/hp out
e) pot. gain of a receiver
f) the speaker hardware
so it's nothing like a slider to set timings in an animation.

Aside this and frankly - i've no problems with the contrast in your screenshot.

knn wrote:2. Because of the large vertical line, it looks somewhat like a previous button in the muted state.

Despite I doubt someone will mess up this, please notice that the initial attempt was an "X" behind the speaker, what QtSvg/KSvg can/could not render at this design
(i think it was because of the outline, not tested with Qt 4.6, but that's no option anyway)
But hey. Still some time left to try a smaller line

knn wrote:3. Clicking (and holding the mouse on) the button changes the cursor to a finger pointer, but dragging doesn't change the volume. The play button doesn't do this.

This is no more (and at this description actually never has been - you saw the finger, you could alter the volume) true.

knn wrote:4. You can click the border of the button to set a specific volume level. Putting controls this close to each other is a bad idea, especially for a touchscreen interface.

knn wrote:For example you said "Amarok needs to be usable on touch screens as well". How is this usable on a touch screen where clicking (with a finger) is less precise than with a mouse?

Nothing in amarok is touchscreen compatible. Period. Sorry.
Far too many too small elements. If you can however (for low resolution) handle one of the treeviews or scroll the playlist w/o dragging the entries, the volume dial should be no problem either. (regardless of this, a click-and-drag attempt will never toggle mute, even if the slider is missed)

No idea how Mamarok gets to multitouch in this regard, iirc KDE/Qt has _no_ mpx support at all anyway.

For classical pointer driven interfaces this should be no (more) a problem esp. w/ the pointing hand pre-hinting the function.

passerbycmc wrote:a single click anywhere on it should mute unmute

Breaks fast volume changes. Also you'll have to ignore minimal movements (because of touchpads) thus could not perform minimal changes

passerbycmc wrote:when changing the volume you should have to move the mouse in a circle around it just move the mouse left or right or up and down.

This is (probably) the default behaviour of dials but leads to what was described as "jumpyness".

In case you meant _incremental_ raises on up/right moves and _incremental_ decreases (inc dec... on left/bottom moves, this gets dead areas in the angles and pretty short ways (thus low resolution, 48px for 100% in doubt)
Aside there only weak relation between the input and the reaction in such setups.

(personally i prefer the default behaviour w/o circle control, but i see why some ppl. experience jumping positions as well)

thopmasl wrote:

passerbycmc wrote:a single click anywhere on it should mute unmute

Breaks fast volume changes. Also you'll have to ignore minimal movements (because of touchpads) thus could not perform minimal changes

passerbycmc wrote:when changing the volume you should have to move the mouse in a circle around it just move the mouse left or right or up and down.

This is (probably) the default behaviour of dials but leads to what was described as "jumpyness".

In case you meant _incremental_ raises on up/right moves and _incremental_ decreases (inc dec... on left/bottom moves, this gets dead areas in the angles and pretty short ways (thus low resolution, 48px for 100% in doubt)
Aside there only weak relation between the input and the reaction in such setups.

(personally i prefer the default behaviour w/o circle control, but i see why some ppl. experience jumping positions as well)

i guess just moving the cursor up or down to change the dial is just something im used to from working with DAW applications day in and day out.