SeekBar is difficult to use on certain display resolutions

[Root-Core]

Hi there,

I've tested the music app and quite like it. There are some issues I encountered though. One of them bothers me on an older laptop with an odd resolution (1366x768).

The seekbar is way to small to make actual use out of it, plus I have not found a way to seek forwards / backwards without it. The arrow keys start the current track from beginning or skip to the next title. Long click on forward / backward does nothing (unlike the play button, which is on its own a bit counter intuitive to me and I use high playback speed all the time). It would be nice if the seekbar would span over the complete width of the player, as it sticks out of it anyways and therefore occupies the height.

Random "artist impression":

As there is a podcast functionality (which I use) you might keep in mind that one pixel could represent several minutes of content.

Feedback on this matter is appreciated. I could look into it and create a PR, but I don't know yet which implications such change would have on mobile, as it seems there is no seekbar at all atm.

Edit: // Okay, I checked the screenshots and the seekbar does not stick out on other resolutions. So I'm not sure if this would be a viable solution to the problem. // The seekbar sticks out only if the details panel is shown, but even if it's closed it is rather hard to use on large files.

[paulijar]

Okay, I checked the screenshots and the seekbar does not stick out on other resolutions.

Yeah, you have really found an edge case here. The time indicator is not really supposed to get divided to two rows and the seekbar ought not to hang below the controls pane, but it does happen when all of these conditions are met:

• Details pane is open
• Window width is approximately between 1357 and 1368 pixels
• The length of the playing audio is more than one hour

I once used a lot of time in manually tweaking all the break points in window width where each UI element gets hidden, in attempt to prevent the UI from ever looking weird or broken like this. But the thing is, neither podcasts nor internet radio were yet supported at that time and I never tested with content length more than an hour.

Long click on forward / backward does nothing

Integrating the fast forward/backward functionality to the long press of these buttons might be an interesting exercise. The benefit of this alternative would be that no significant layout changes would be needed. I kind of dislike modifying the controls pane layout because it has not been designed to be easily modifiable and there are so many slightly different layouts for various window widths to be tested and fine-tuned. So it always takes more time and effort than one would have expected. If the skip next/previous button would have the secondary function of fast forward/backward, then also their icons should be changed to something like https://thenounproject.com/icon/skip-forward-778418/ to indicate the dual functionality.

I don't know yet which implications such change would have on mobile, as it seems there is no seekbar at all atm.

This is also related to the very old issue https://github.com/owncloud/music/issues/204. The overlap is not as severe today as it was 8 years ago but the issue has not been completely solved either. And we can't change the fact that on portrait mobile screen, there's terribly little of screen estate to spare. One idea presented there was that the mobile layout could expand the controls pane (e.g. with an … button) to a second row and reveal additional controls, including the progress bar. But that would be significant effort to design and implement.

[Root-Core]

I once used a lot of time in manually tweaking all the break points in window width where each UI element gets hidden, in attempt to prevent the UI from ever looking weird or broken like this. But the thing is, neither podcasts nor internet radio were yet supported at that time and I never tested with content length more than an hour.

I have tested the responsive design a bit and it works quite good, the details pane created some problems though and not only with long titles in my experience. It is not easy to pin point the exact issues.

But the thing is, neither podcasts nor internet radio were yet supported at that time and I never tested with content length more than an hour.

No problem, everybody has different use cases. I also listen to audio books, so I would have encountered this issue without podcasts I guess.

Integrating the fast forward/backward functionality to the long press of these buttons might be an interesting exercise. The benefit of this alternative would be that no significant layout changes would be needed. I kind of dislike modifying the controls pane layout because it has not been designed to be easily modifiable and there are so many slightly different layouts for various window widths to be tested and fine-tuned. So it always takes more time and effort than one would have expected.

I understand the problem. It should be possible the integrate this functions, but it might be worth to add additional buttons for the biggest window widths. I assume this shouldn't affect most layouts, but I have not looked into the code and CSS can be iffy.

If the skip next/previous button would have the secondary function of fast forward/backward, then also their icons should be changed to something like https://thenounproject.com/icon/skip-forward-778418/ to indicate the dual functionality.

This would certainly help and is hopefully understandable for the user. I have seen some remote controls using this kind of icons.

One idea presented there was that the mobile layout could expand the controls pane (e.g. with an … button) to a second row and reveal additional controls, including the progress bar. But that would be significant effort to design and implement.

I could absolutely see something like this could be folded out, but it might be too much effort as you always can rotate the phone. One thing though is that the progress bar would not take any screen estate horizontally if it was spanning over the whole width, like in my "artist impression". It affects only the vertical space, which is not that constrained and I have the feeling that screens are indeed getting longer and longer.

PS: While testing the app on mobile Firefox, the current "burger" button for the left navigation does only work the first time or if you don't use the button again to close it. Not sure if this issue is on my side, so I haven't opened an issue for it.

[paulijar]

One thing though is that the progress bar would not take any screen estate horizontally if it was spanning over the whole width, like in my "artist impression". It affects only the vertical space, which is not that constrained and I have the feeling that screens are indeed getting longer and longer.

You are quite right. Furthermore, even the required vertical space of the second row is rather limited if we don't place there any tall items. Maybe something like this could work on narrow screens:

This would also scale down to much narrower window widths than the one in the example, without having to sacrifice the "skip previous" button like we now do on the mobile-portrait layout.

Or this might be even more balanced:

[Root-Core]

They look good so far, I like it. The thing I had in mind with my quick draft was to keep the required implementation effort / changes to a minimum. As you said, changing the layout can be quite fiddly. On the other hand it might be even easier to implement, as less elements are in the width dimension. Far less permutations, less crammed, less things to consider.

[paulijar]

Here are a few screenshots from the actual implementation. The first image shows the narrowest window where the controls pane is still shown in one line and the rest show the two-line layout in various widths. As can be seen, we can now keep the progress bar and volume control available down to very narrow windows. The textual progress info can now always fit times longer than one hour but times longer than 10 hours still cause issues on some layouts. But probably most users will never find this out.

[Root-Core]

This looks good so far. 👍🏻

From the first look I would vote for the two line layout to be standard. It looks cleaner and is more logical, if you consider that all control elements are in one place. The one line layout is only active for bigger screens - if I understood it correctly - where the need of a tightly packed UI is less. I haven't tested it yet though, therefore my opinion isn't worth much.

Nevertheless, nice work.

---

EDIT: There are problems on higher resolutions (tested with Firefox).

EDIT 2: Okay.. not "problems", but the space is little used. I think it would make more sense, if the space was better used / more space allocated to the progress bar.

[paulijar]

I feel that using the two-line layout on large PC screen would make the progress bar a bit too heavy while leaving awfully lot of unused space on the first line. But more importantly, I don't want to have the two-line layout used on landscape mobile phone screen because there the vertical space is very limited.

With regard to higher resolutions, the latest version sets the max-width of the progress-info in one-line mode to 450px while it previously was only 350px. But you are right, if the pixel-width of the controls pane is as wide as in your example, then it would be better to have also wider progress bar. After a bit of experimenting, I feel that setting the max-width to 35% gives quite balanced result on all resolutions. Here, for example, a 4K-simulation by using 50% zooming on 1920p display:

[Root-Core]

But more importantly, I don't want to have the two-line layout used on landscape mobile phone screen because there the vertical space is very limited.

You are right, I haven't really thought about that.

---

The relative implementation seems to work okay so far, absolute wasn't future proof. Do we limit the width of the seekbar currently to prevent that it gets to wide to be usable or for optical reason?

[paulijar]

Do we limit the width of the seekbar currently to prevent that it gets to wide to be usable or for optical reason?

It's mostly optical reasons. Unlimited progress bar width could look something like this and I feel that this would make the controls pane to be too full of progress bar: I rather want to have some margin areas between the UI elements, unless the screen is so narrow that we cannot afford that.

[paulijar]

All the improvements discussed here have now been released in Music v1.7.0.