Usability: Volume Bar Fades Too Fast

[vencabot]

Share your bug report, feature request, or comment.

Owncast's video player is great and slick-looking, but I noticed today while watching Hatnix that changing the volume is pretty difficult.

When you hover over the video, the volume bar isn't accessible (why not? Playing with stream volume is a pretty common task, at least for me, as I do things in the background).

When you hover over the 'volume' icon, the volume bar fades into view. The real problem is that, if your mouse cursor floats off of the volume cursor / bar for even a split-second, the bar fades away and is inaccessible. In order to lower or raise the volume, you have to very carefully move your cursor exactly rightward without ever drifting off of the volume bar. It's like playing a game of Operation.

This can't be intentional. The solution would be to create a grace period, just like how moving your cursor off of the video doesn't immediately hide the player UI. I personally think a part of this solution should involve considering whether or not the volume bar should be hidden in the first place. It's a slick animation to see it fading in-and-out for sure, but it's not like it's saving much space in the UI and I think it's a little bit confusing, since clicking a volume icon will usually mute something (as it does here) and that's not what I want to do, so why would I move my mouse there except for, "wait, where's the volume bar? Oh, here it is."

Just my two cents! But either way, yeah I would say at the very least there needs to be a delay between moving your mouse off of the volume bar and it fading away.

EDIT 1: Just did some more playing with it. The volume bar fades away even if I move perfectly along the bar, going rightward (from the volume icon to the bar) if I go too fast. Maybe because, if I go fast enough, the cursor position maybe doesn't stroke along every position of the bar?

EDIT 2: Something is up with the volume bar. I don't think that it's only that it's fading too fast, actually (although that is still a problem). It seems like I can't touch anywhere about 55% volume without it fading away, no matter how careful I am? Here's a video: https://www.youtube.com/watch?v=dLuPk-BP4Mk

[gabek]

I honestly never change the volume, and nobody has ever mentioned any concerns, but if the volume control isn't optimal then maybe an entirely different volume control is required. Trying to fix all of these issues you have with the current bar sounds like a lot of work, and it would probably be better to come up with something better.

I know I'm a broken record, but I want to set expectations:

Tasks that require UI changes are unlikely to get worked on due to little to no design resources, and I'm finally getting to focus on backend work. So these kind of issues that require research, experimentation, prototyping, etc might take a while.

[vencabot]

I'm not convinced that this issue needs design, unless I misunderstand what you mean by design. To be clear (my last message was long because I wanted to preserve the process of me discovering issues), there are three issues by my estimation, in order of severity:

1.) The volume bar cannot be hovered over beyond 55%. This is a bug. May require additional testing (could it have been something with Hatnix's set-up?).
2.) The volume bar fades too quickly when it isn't being hovered over. Is this attached to a variable that can be changed somewhere? What is the time-out on the fade-away? This makes it very finicky to use.
3.) A possible solution to the problem above would just be to have the volume bar be persistent rather than fading away. For a player UI as simple as Owncast's, I don't see the advantage of hiding design elements behind hovers.

I have no expectations as to when you'll get around to addressing any issues; I just hope that issues are taken seriously. I know that you've got plenty to work on both with Owncast and outside of Owncast. Whatever fixes and features you choose to prioritize, I wish you luck; all that I can do is report problems as I come across them so that when somebody has that same issue down-the-line you can't say, "well, nobody has ever mentioned any concerns."

[gabek]

I just think a new design for the volume control would be better given the issues you describe. Maybe something more similar to

and not a slider. It sounds like the fact that it's a slider is the root cause of many of the issues you're encountering.

[vencabot]

I don't know if I agree. Do you not feel like that design is also just 'a slider', but rendered with a different graphic? They're used exactly the same: click horizontally along the bar to set your volume, or click-and-drag to set it while listening. The latter is just a slider that gets bigger toward one side.

I have no preference for either design, visually, but the problem would be the same if, like the current slider, that new slider would vanish before I could click on it -- either because my mouse actually drifted off of it for a split-second or because, for some reason, the latter half of it didn't register hovers.

It seems like the issue is a technical one: why doesn't the latter half register hovers (or does it and this is only a Hatnix issue), and why does it fade so fast when it's not being hovered (the UI is small and it's easy to fall off of it, so it should give you time to reallign the cursor before fading).

[gabek]

It's a little different. The reason why it comes to mind as a better solution to what you're talking about is you're mentioning mouse precision and having to move in a very specific way to change the volume. This other approach is less a slider, and more like the signal strength bar of a cell phone. The current slider allows you to be very detailed in your volume selection, but with this alternative, it would jump maybe 5% in each direction at a time, requiring you not to need to be precise at all. Click to the right, it goes up, click to the left it goes down. Keep sliding, it'll keep going.

It's also smaller, so it's less cluttered to keep it displayed the entire time. But I'm just throwing ideas out there. I'm certainly not saying my spur of the moment thoughts are better. There's likely a better design that after some discussion and thought would be a better solution than what we have now.

[vencabot]

I think the current slider is fine and the 'signal bar style' would also be fine. The current slider and the signal bar would be the same height (the height of the player controls bar), so equally easy to fall off of when casually moving the mouse. I've seen many signal-bar-style bars that were as long as Owncast's current slider, and I've seen volume sliders that were 1/4th the size of Owncast's current slider. If the fade-away delay were widened and if the latter half of the slider correctly registered hover events, there would be nothing wrong with the current volume slider.