[Circle]: Improve layout

[bragefuglseth]

Breakout thread from the ongoing GNOME Circle review of the app.

The main layout of the app currently consists of one unified header bar, a main view with three panes, and a bottom bar with player controls. Things are generally shown all at once, with no pagination whatsoever, and this can make for a cluttered and confusing experience at times. One way to improve this would be by e.g. splitting the app up in separate views instead of presenting every element at once, and consolidating related information in one place. Here's a suggestion that you can use to stake out a general direction, taking advantage of modern GNOME design patterns and widgetry:

If you're interested, I can adapt the above to mobile as well.

[SoongNoonien]

Thank you very much! I appreciate the effort you put into this design suggestion. But I have to say that I don't like it while I know that the current design isn't perfect either. I'll try to list some of the problems I see with your proposal:

• MPD always manages its playback trough a queue. So it is not feasible to completely hide it and indicate within the browser/library what is playing. The queue has to be exposed and it should be separate from the browser as those two components are not related in any way.
• Turning the sidebar into a lyrics view is a very weird I thing. The sidebar is usually too narrow to read the lyrics and it wouldn't be possible to continue browsing while glancing at the lyrics from time to time.
• Allowing to show all albums of all artists has severe performance implications. When connected via network, transmitting the album covers is very slow. So even with a relatively small collection as mine (~400 albums) this can take up to several minutes. And MPD users tend to have collections which are way larger, a factor of >10 is not unusual.
• I think the cover of the current song is to small. One of the reasons why I started this project is that most players only show tiny covers. I consider covers to be an essential part of music. But maybe you portrayed a collapsed version of the player and with larger window sizes there could a bigger cover somewhere?
• I suppose the small circles next to the artist names symbolize artist portraits? I think almost nobody has artist portraits stored locally like album covers. So these would be empty most of the time or they would need to be filled trough some shady online service. And I'm always very confused when I open for example gnome music and see pictures of the artists which are 40 years younger than the music I have of them.
• The shuffle and repeat buttons in the lower right corner don't reflect the capabilities of MPD. MPD also provides a consume mode and a separate single mode. All four modes can be combined freely. So another client could configure a combination which is not representable by these two buttons.
• Displaying only the songs title and artist in the search results has the disadvantage that different versions of the same song are hard to distinguish.

[bragefuglseth]

Thanks a lot for the input! I'll attempt to make a revised suggestion.

Turning the sidebar into a lyrics view is a very weird I thing. The sidebar is usually too narrow to read the lyrics and it wouldn't be possible to continue browsing while glancing at the lyrics from time to time.

It would turn the main view into a lyrics view, similar to what Spotify does. If you think that's also undesirable, please let me know.

[SoongNoonien]

It would turn the main view into a lyrics view, similar to what Spotify does. If you think that's also undesirable, please let me know.

Ok, I see. While this solves the problem with the narrow width the problem with browsing while glancing at the lyrics remains.

[bragefuglseth]

I'll see if I can come up with something that's closer to the current app layout, but easier to approach and maneuver.

[rien333]

I like the sort button in your suggestion! It would be nice to be able to sort by "Date added to library" when the required plumbing lands in mpd 0.24, but I can't think of a lot of other sorting options that fit plattenalbum's current UI. (I'm imaging that if an user sorts by date added, the artist to whom's discography you've made the most recent addition should be placed first)

Sorting by album release date would be nice in principle, but doesn't make a lot of sense in the context of plattenalbum, since the list to be sorted is actually a list of artist.

[bragefuglseth]

Hey, quick question about the MPD playback modes — what do they do, exactly? Repeat and Random makes sense to me, but what does Single and Consume do?

[bragefuglseth]

I finally had time to sit down and sketch out some revised layout ideas, taking your feedback into account. I also included an example of how Plattenalbum could hypothetically look at narrow window sizes; this would make the app more suited for e.g. tiling window managers and mobile phones. Relevant widgetry for making the app adaptive enough for this, is the upcoming Adw.MultiLayoutView and Adw.BottomSheet.

If audio format setting is on, that information could e.g. be shown right above the song lyrics view.

Let me know what you think about this; in particular I guess you'll have something to say about the way the queue and the song lyrics are handled.

[SoongNoonien]

Hey, quick question about the MPD playback modes — what do they do, exactly? Repeat and Random makes sense to me, but what does Single and Consume do?

Single will pause playback after the end of each song so you have to manually start playback for every song. Consume will remove each song when it's over. So this effectively clears the playlist song by song. Here are some details about them: https://mpd.readthedocs.io/en/latest/protocol.html#playback-options

I finally had time to sit down and sketch out some revised layout ideas, taking your feedback into account.

Thank you very much for your efforts!

I also included an example of how Plattenalbum could hypothetically look at narrow window sizes; this would make the app more suited for e.g. tiling window managers and mobile phones.

That's good, I'm working on that anyway, see #120.

Relevant widgetry for making the app adaptive enough for this, is the upcoming Adw.MultiLayoutView and Adw.BottomSheet.

Yes, those certainly will come in handy.

If audio format setting is on, that information could e.g. be shown right above the song lyrics view.

I'm not sure if it fits there. I'm not even sure if the lyrics view is placed right there.

Let me know what you think about this; in particular I guess you'll have something to say about the way the queue and the song lyrics are handled.

I'm not sure what's wrong with displaying the lyrics over the album cover whenever it is requested. I think displaying the queue inside the browser is not a good option. This prevents the use of drag an drop which is currently supported. And it also mixes the browser part with the player part for no obvious reason. You made progress on further separating them by moving the playback controls to the right. Which I think is a good thing, though this has the drawback that the seekbar is significantly shorter than before which decreases its accuracy. I do quite like the redesigned album view. I think one could save some vertical space in the right pane by removing the "now playing" title and replacing it by the current song title. This would allow to place the queue on the right again. Why did you place the playback controls right below the cover? Couldn't it be placed at the bottom? Also why did you reintroduce the volume control button (Which will be removed in GTK5 anyways.) and the playback mode button? I'm quite happy with the way they are integrated into the main menu now.

All in all I think this suggestion is much better than the first one!

[SoongNoonien]

I'm working on a new layout implementing some of the suggestions here. I hope I have something presentable soon.

[SoongNoonien]

So, here is what current master looks like:

Here is the album details view (with audio format enabled):

And here the search:

Maybe I'll find something better for the audio format.

[rien333]

I'm liking it so far! I do miss being able to go back by just pressing the album cover in the 'Album details view', but that might just be something I've grown accustomed to, rather than a good design decision per se.

[SoongNoonien]

I'm liking it so far!

Thanks for the feedback!

I do miss being able to go back by just pressing the album cover in the 'Album details view', but that might just be something I've grown accustomed to, rather than a good design decision per se.

I don't think it was a good design choice. There just wasn't a good place for a back button. I think using the default design pattern is a better solution.

[SoongNoonien]

Maybe I'll find something better for the audio format.

So, I've reevaluated the whole audio format stuff. It turns out that the "audio format" reported by mpd is not exactly what I've thought. It doesn't actually report the format of the audio file but rather the format outputted by the decoder. The file format was parsed by me in a very crude way, I simply cut of the file name extension. So both aren't as reliable as I wished them to be and I've decided to don't show them anymore and leave this to specialized external software like mediainfo. The only technical data I'm still showing is the bit rate. Hence the setting has also been renamed to "Show Bit Rate" which should now be much clearer than before.

Here is what it looks now when the bit rate is shown:

[rien333]

So both aren't as reliable as I wished them to be and I've decided to don't show them anymore and leave this to specialized external software like mediainfo. The only technical data I'm still showing is the bit rate.

I feel like the bitrate looks a bit lonely now, but I do completely understand dropping the other technical info on grounds of it being unreliable. My question is: was this more of a design decision, or rather, based on the fact that this information could be misleading?

I'm asking this because I've opened an issue over at the mpd repo about the possibilities of mpd delivering more technical metadata, such as the song's current encoding. I don't see this being implemented anytime soon, but if it ever is, would you consider re-adding some technical metadata?

My music comes from widely different sources, so I kinda like seeing something about its technical characteristics.

[SoongNoonien]

I feel like the bitrate looks a bit lonely now, but I do completely understand dropping the other technical info on grounds of it being unreliable. My question is: was this more of a design decision, or rather, based on the fact that this information could be misleading?

I was reconsidering the design of that feature while I noticed the inconsistencies. Then I removed all unreliable information which in turn made the new design easier.

I'm asking this because I've opened an issue over at the MusicPlayerDaemon/MPD#2118 (comment) about the possibilities of mpd delivering more technical metadata, such as the song's current encoding.

Yes, I've seen that ;-). I even subscribed to it.

I don't see this being implemented anytime soon, but if it ever is, would you consider re-adding some technical metadata?

I certainly would. But the design question about where and in which form to put it in the UI isn't really solved. It's just circumvented, now that there isn't much technical data left to display.

My music comes from widely different sources, so I kinda like seeing something about its technical characteristics.

Mine as well, so I do like that as well. For me the bitrate is currently enough. I just want to know if the music is CBR which is mostly MP3 in my case or if it's high resolution VBR which is always FLAC in my case. But I do know that this is a very easy usecase to cover.

[SoongNoonien]

I'm tempted to close this. I think all concerns and suggestions have been addressed and it works better than before. @bragefuglseth What do you think? Do you have any objections?

[bragefuglseth]

Hey, sorry for taking so long to get back. Seems like all outstanding concerns have been addressed. I’ll have a more thorough look at the app again soon, let’s just take the remaining stuff as we go 🙂