#UX/UI topic - Volume Slider

1 messages · Page 1 of 1 (latest)

true estuary
#

The volume slider came up as a topic of discussion in a recent community submitted PR. https://github.com/music-assistant/frontend/pull/1343. We wanted to make sure there's a place here for discussion on this UI component that doesn't get fractured/lost in either PR's or single discussion channels.

I also wanted to help out and offer some guidance on what kinds of discussion/feedback is most useful for design/UI/UX.

Giving feedback that's useful for Design/UX/UI

for design, UI and UX in particular, feedback and discussions that start with or contain 'I like/dislike...' 'I prefer/do not prefer...' or 'My opinion is...' are not helpful in isolation. We need to know the why this is the case and if it's broadly applicable to as many users as possible to make a user-insight, data informed choice on design/UI/UX changes/improvements.

Examples of not helpful discussion/feedback: 'I like the blue colour for the slider, it 'pops'' or 'I like the black/grey slider colour because it looks the same as other music players.'

These are good starts but not as helpful as:

'The volume slider being blue reminds me that it's an editable area because anything that uses blue is usually clickable in MA, like the play button but the blue also reminds me of the Home Assistant brand.

'The volume slide being black/grey is better because I sometimes use my music players directly as well as Music Assistant to listen to music so the change from black/grey to blue i find really jarring. I also use my volume keyboard shortcuts more often than the slider so I don't look in that area much and the blue actually distracts me when i'm doing something else'

#

Topics to discuss/give feedback on the Volume Slide

  1. Does it benefit MA's volume slider to look similar to, or the same as other music players popularly used and why? (most popular music players have their volume slides black/grey/white/black)

  2. Is it useful for new users to have a blue coloured volume sliders to draw their attention to an editable area? Is it useful for users that have used MA for a long time for it to be blue/edit-colour why?

  3. Do either options improve or reduce accessibility for any kinds of disabled users?

  4. Does the volume slide have the most useful order of icons, text and interactive component? Does this volume slider tell you all the info you need to know in the place/order you expect it to be?

  5. Are the sizes of the circle-handle accessible for you aka do you ever mis-click the slide circle at it's current size? Would reducing the circle size affect that for you and if the hit area was still 'large' but invisible would that be expected by you if it changed from it's current functionality?

analog solstice
#

I find the blue volume slider particularly useful, as it is very easily glanceable info with direct feedback against the otherwise black/white UI components.
It also evokes a sense of belonging to the ohf family, which is important, without being too aggressively colourful.

The point you make about it drawing attention to an "editable" element is also important, and helps build a sense of cohesion to such interactions.

raw cipher
#

Hey @true estuary ,

I like your approach. And I want to write something about Point1.

A volume control is something so fundamentally important for controlling music. It must work consistently on all screen sizes, all Platforms. If you look about the function. But what’s about design? A volume slider is important but it’s not that important that you look at a screen and your 2nd or 3nd view sees the volume slider. It should be there if you need it. Currently it’s getting more traction than actual needed.

I would not directly copy a competitor but follow their design rules so the User is already used to the design.

Coming to the actual Design: We don’t need a knob - we have touch screens. Yes old devices had knobs, physical buttons but on a screen slider - I would say a knob is just useless space. As a direct example see my next message. This is a good way how to make a slider intuitively and not too obvious. The touch area is much wider than the visual space. You cannot miss it.

true estuary
#

@raw cipher Do you have thoughts on whether a knob is useful for gradual volume increase/decrease so for example, if a user click far on the right of the vol slider they might 'jump' to 80% volume and not gradually slide? same if they clikc/tap far on the left and mute/go 0%? where they would need to accurately tap/click on where the bart currently is set the tap/click-hold and slide for gradual increase/decrease?

#

(also thank you both for your thoughtful comments and responses 🙏 i appreciate your time and energy on this!)

raw cipher
true estuary
#

Do you think there's a way that a UI element can encourage/remind a user to tap and hold? in ref to your comment that the user must (remember/know) to hold their finger?

raw cipher
true estuary
analog solstice
#

A pulse that spreads out along the volume bar would look pretty slick and serve the purpose I think.
A press and hold and the resulting ripple gently, but not too gently, spreads each way. Could perhaps even subtly increase and decrease the size of the pulse in the corresponding directions.

shut bronze
#

  1. At least with the bright theme on the mobile bottom bar player, the slider is very prominent. It's the largest UI element and also the only colorful beside the playing-indicator. Letting it step back a bit in visual terms wouldn't hurt.

  2. New users most likely don't need color on such a large and well known UI element to recognize it. The other point, about the familiarity of the color to make it more visible as a part of the OHF software brand, is a much stronger argument. But I'm not sure if it's the right UI element for this, because of the reasons in point 1.
    And a reason why many audio player most likely don't use colors on the player UI: It should be all about the music. So the artwork and maybe color matching UI elements should take center, rather than the UI itself.

  3. Accessibility should not only be about changing volume I guess?
    If this should be really adressed, a zoomed UI mode (which most mobiles allow with their PWAs and the browsers, so it's more or less already built-in) and a high contrast theme might be a better way.

  4. The current size seem large enough for me. I haven't had missed clicks so far. Same with the old slider that is still used for the track position (only difference: the knob isn't visible without hovering). This one seems to have a similar sized hit target, but with a way smaller visible knob gprahics. Even at this small size, it never made me feel like I might miss it. Most likely because we are used to such UI effects since quite some time.
    But still, the tiny knob of the track position slider might also not be the perfect solution and something in between might be a better match.
    A size that looks not oversized on smaller screens where the UI elements are closer together, but still not so tiny that it looks weird otherwise.

shut bronze
# raw cipher

This thicker, knob-less design is also interesting.
The only downside I see here, is that it's easier to get confused which slider is for the track position and which one for the volume.

In fact there are apps where I had to think about this for a few seconds when the track position was in a similar horizontal position.

MA so far used a knob-less (when not hovering) design for track position and one with an always visible knob for volume.

So I would vote to keep this pattern, but would also see no real problems in case it would be changed ...

shut bronze
# true estuary Do you think there's a way that a UI element can encourage/remind a user to tap ...

If the current behavior of the mobile app is kept, this might already be quite intuitive.
If you click on the slider here (different to a desktop device without touchscreen), it only changes for a small step.
So the user will get quite quickly that he can tap a few times to increase the volume further for fine control (and use the knob to drag).

Trying a hold-gesture on the slider (not the knob) is a natural next step for many users I guess.
(But not needed to use the app, it would just be a shortcut.)
At least I tried it when this tap-step feature was added to the mobile user interface.
This is why I already knew that a hold-feature is currently not implemented (or not working on iOS). 😛

dusty star
shut bronze
#

Indeed. 👍

But I always thought that the different colors for the slider would only be a temporary thing, as the progress slider still uses the old library.

At least to me the different colors look a little bit weird. If the volume stays blue, I would prefer the progress bar in the same color. (And if it stays knob-les, a indicating color „this is user interactively“ might make even more sense here).

But this isn’t really an argument, more a personal opinion.

glad bloom
#

Are we also talking about using the mousewheel to adjust the volume slider when hovering over it?

true estuary
#

re. the volume slider and the progress slider.

the main different between these two UI components is one is actionable/clickable/editable by the user (vol slider) and the other is not (progress bar)

I don't disagree that the progress bar could be blue, i just don't think it should be solid blue since it doesn't have the same interaction context. I would test blue but like striped? blue but with a texture?

Our spinner/loader has blue too. Blue tends to also indicate across MA that 'hey something important is here/happening!' so yeah the subject of what colours mean in the UI is a connected but independent topic for sure.

(this being said, most computer literate people are aware you cannot interact with a loading bar/spinner but we should also consider less computer literate people here too 💙 )

#

On this ticket topic generally, I've come up with some usability tests that i want to quickly mock up to test outside our usual pool of power users. I'm checking in with the wider HA team and the research lead on how to do this but will update here when i've compiled the test and the results!

analog solstice
#

Just a quick note to say that the progress bar is indeed also interactive, it's possible to click or slide the progress to a given point.

#

One may be less inclined to use it on a regular basis though

true estuary
#

OH ah so y'all are talking about the music track progress bar

#

i'm talking about the loading progress bar

#

crossed wires

#

both are grey, the music track progress bar you for sure can click. The loading progress bar is similar but no click-y allowed

analog solstice
#

I at least assume this is what we're all talking about, but to assume is to make an ass out of u and me so perhaps we should all agree that this is what we're all referring to.

shut bronze
#

Yes, was also talking about the song position. So the reason for my thoughts about same coloring was also, that they are both (volume and song position) actionable. 🙂

mellow girder
#

@true estuary I have nothing particular to say on the point 1. to 5. but I'm going to add a 6. because I like chaos 😅

  1. Do you find the volume slider predictable? Is there any behavior you find unpredictable and why.

Honestly I love the slider in most cases!

I like how the slider behaves on click device with the simple Click to set behavior
I like how we try to prevent accidental and sudden volume jump on touch devices with the Click to increment/decrement and drag to set behaviors.

There is ONE scenario where I think we could do a bit better.
It's the case

  • Touch device
  • You click on the slider, far away from the handle
  • You sligtly drag your finger

Here it jumps.

o : handle
x : finger 
> : drag

Input:
---o----------------x>----

Result:
---------------------o----
true estuary
#

"Where it is and not where my finger is"<<< yes yes yes this for tap+ drag 100%

a single tap and release can and should jump to the tapped point.

I like that second app's visual animation feedback for what is happening there, a slight magnification of the entire volume component, brighter colour to focus on but a set back standard grey for when it's not being interacted with. Perhaps we can also do this but instead of the 'focus' colour being white it can be our brand blue?

I'll take these thoughts and jam on them