Extended queue UI

[KraXen72]

note: these are just things that would be cool to have, but i understand if you don't want to implement them, as they solve small or potentially nonexistent problems.

Is your feature request related to a problem? Please describe:

problem:

1. the queue view is slighly confusing at the moment
2. it doesen't show songs that were played/full queue if repeat queue is on.
3. the queue button is hard to reach on tall devices (i have samsung galaxy m21)

Describe the feature you want to implement:

the queue view is slighly confusing at the moment:

• the first thing is a small suggestion: show the currently playling song in the top of the queue. This confused me at first when i thought the song i was playing was somehow not in the queue i set to play. something like this (the top, not the actual playing song in the queue) (screenshot from oto music):
  

it doesen't show songs that were played/full queue if repeat queue is on.

• queue doesen't show full "queue" i set to play when loop queue is on. this is kinda bad ux because if you're near to end, and wanna switch a song from the currently playling queue, you can't really do so untill the queue is restarted.
  this could be remedied by 2 ways:
  • have the queue work something like in phonograph, where it shows also already played songs. (and shows -1, -2, etc) (potentially bad ux, not a too big of a fan of this one.)
  • add the entries at the end of the queue after played (could be pretty confusing). this could be good if the queue items where separated from the currently playling ones by a horizontal separator/text and or grayed out (the text could be "next loop" or something)
    
  • have an extra view/button for the full "queue" (not a big fan of this one but it could work)
    

the queue button is hard to reach:

• move the queue button to the bottom: i know you said you didn't have companions for it, but you could add a sleep timer and favorite button there (i am not sure if these are implemented yet, just an idea)
• swipe from bottom opens queue. just like swipe from top hides playback view and returns to whatever was before, swipe from bottom would opent he queue drawer.

Why do you think this will improve everyone's usage of Auxio?

1. the queue view will make more sense
2. you can more easily pick a song from the currenlty playing subset of songs without haveing to unintuitively skip to restart the queue
3. it takes less time and uncomfortable finger movement to open the queue on a tall phone

Due Diligence:

• I have read the Contribution Guidelines.
• I have read the Accepted Additions and Requests document.
• I have checked for this feature in the FAQ.

[OxygenCobalt]

the first thing is a small suggestion: show the currently playling song in the top of the queue. This confused me at first when i thought the song i was playing was somehow not in the queue i set to play. something like this (the top, not the actual playing song in the queue) (screenshot from oto music):

I can add this. Simple as adding a header item and updating the item moving logic.

add the entries at the end of the queue after played (could be pretty confusing). this could be good if the queue items where separated from the currently playling ones by a horizontal separator/text and or grayed out (the text could be "next loop" or something)

This sounds like a good idea. The best balance between retaining the current sensible "only show the next items" while still allowing someone to play from the next loop.

move the queue button to the bottom: i know you said you didn't have companions for it, but you could add a sleep timer and favorite button there (i am not sure if these are implemented yet, just an idea)

I'm planning to add a like button to the side of the song name/artist name/album name UI elements. As for a sleep timer, that doesn't really benefit my usage. The biggest candidate for a companion is perhaps a "cast" button, but I have no idea how that would work. I'll put that idea on ice for now.

swipe from bottom opens queue. just like swipe from top hides playback view and returns to whatever was before, swipe from bottom would open the queue drawer.

Sadly there are too many touch events in the queue by itself to implement this in a nice way. I've tried to do it before, and what would happen is the following:

• You could scroll down and scroll up, but not slide down
• If I fixed that, you could scroll down, but not scroll up
• If I fixed that, you could not slide up as android would decide you wanted to pick up an item

These are some really good suggestions. After I try to tackle some of the technical debt [Notably #72], I'll try to work on this. My current plan will be the following:

• The currently playing item is always shown at the top.
  • This is mostly just decor. It has no interaction.
• The next queue items in this playback cycle are shown afterwards
  • These can be played, removed, and moved around.
  • Playing them will simply move the queue to that position.
• The next cycle of queue items are shown after those
  • This will either be Auxio's prediction of the next queue, without any edits that may have been made, or simply the current queue repeated again. Can you tell me which one you prefer @KraXen72?
  • This will not be editable simply to preserve sanity. They can still be played however.

[KraXen72]

Thanks!
i see now that the swipe from bottom can't be implemented nicely. bummer but it's alright. i see about the like/fav button, that's a good placement 👍. I don't know where else you would put the queue button, (maybe tap on album cover?) or see how other apps do it ig.

as for the next queue cycle, as long as you have repeat queue on, it should just put played songs from this queue at the end, so the queue stays the same after any amount of playback.

• if you have shuffle on, the queue should probably get re-shuffled each full loop to give more of a shuffle experience rather than just shuffling once at the start.
• if you don't have loop queue on, then the next queue can be whatever auxio thinks will play after this queue as you suggested

as for next cycle items not being editable, that's okay and probably simpler ux 👍

[KraXen72]

you could put the queue button like this (retro music):

[OxygenCobalt]

as for the next queue cycle, as long as you have repeat queue on, it should just put played songs from this queue at the end, so the queue stays the same after any amount of playback.

Yeah, that's what I'm going to do. Seems the most straightfoward.

if you have shuffle on, the queue should probably get re-shuffled each full loop to give more of a shuffle experience rather than just shuffling once at the start.

That would probably require me to keep a separate copy of the next queue, which is not great. I'll think about it when I get to it.

if you don't have loop queue on, then the next queue can be whatever auxio thinks will play after this queue as you suggested

The only difference between no looping and looping is simply whether Auxio continues playing once the queue loops. For the sake of consistency, the next queue cycle will probably always be the current queue.

[kendfss]

if you have shuffle on, the queue should probably get re-shuffled each full loop to give more of a shuffle experience rather than just shuffling once at the start.

If this is ever implemented, could it be optional? I suppose its somewhat of a niche issue, but if you're planning something like a DJ set it can be helpful for a shuffle to persist. Ideally, this consideration would be reflected by allowing queues to be saved, but even then (especially if the queue has new music) it's not always clear that a shuffled queue is worth saving before you've heard it.

[KraXen72]

interesting. 1) why would you use auxio as your dj software lol? 2) how is one shuffle better than another one?
if you have a particular order you want in the songs, just reorder how you want them and turn of shuffle. hopefully once playlists are a thing you could order the songs how you want and without shuffling you will get your desire queue.

[OxygenCobalt]

I thought I've already ruled out re-shuffling the queue like that? It would be a bit of a technical nightmare, and besides, if you wanted to re-shuffle the queue you could just turn the shuffle button on and off.

[KraXen72]

fair enough. that's kinda what i've been doing with other media players so far, just tapping the shuffle button twice.

[kendfss]

why would you use auxio as your dj software lol?

I wouldn't, sometimes it is helpful to listen to music before chucking it into a mix. You've never been inspired by a jolly good shuffle?

just reorder how you want them

You don't always know what order you want ahead of time (hence shuffle 😜 ). The idea is being able to capture what the shuffle did and revisit it later. This could also be done by manual seeding, but I guess most users wouldn't want that either (ignoring the pain of implementation).
A related use case could be planning out a new ep/lp.

[OxygenCobalt]

So, would you guys be okay with queue editing becoming a toggle? Basically, you would have to click an edit button to put it into an editable mode, and then once you are done, you would confirm or drop your changes. I say this because it would make gapless playback feasible (for internal technical reasons that are hard to describe), and also reduce the internal complexity of the new queue UI (I could remove the next loop and current playback items in the edit mode, so I don't have to deal with how those items react to queue edits)

[KraXen72]

like, you would need to click an edit button before you're able to drag and drop queue items?

[OxygenCobalt]

Yeah, on the Toolbar. Then you would have to confirm the edits. This is to ensure that I'm only regenerating the internal player's queue once for a group of edits, compared to a bunch of times like it currently would be.

[KraXen72]

that's reasonable, but now i'm already reaching my finger to the top of the phone for queue and the i'd have to reach to click edit and confirm/discard again.
couldn't the edit button be in a bottom materialToolbar or a FAB?

[KraXen72]

or, don't save the queue edits and regenerate until either you go back from queue view, or a new song starts playing.
if a new songs starts playing, (the current one ended) you'd want to play from the new queue, but otherwise the users won't notice their changes aren't applied instantly to the player.

[OxygenCobalt]

I could use a FAB, actually. Only issue is how to handle saving/discarding edits, which are two distinct actions. The latter idea though is just asking for state issues however.

As a side note, this would actually benefit me a little, as sometimes I accidentally remove items I don't want to remove with a stray swipe. Separating the modes then is actually somewhat practical.

[KraXen72]

okay, so this is what i've come up with:
material guidelines allow 2 fabs, as long as the second one is the small one and is a secondary action, as seen here:

so what i suggest is the following:

google calendar is a nice example how a smaller fab appears from a big one

[OxygenCobalt]

Huh, I never realized that. I thought Material Design 3 actually forbade multiple FABs in one screen, but I guess not. I'll see what I could feasibly do here. One issue with this idea is consistency, as I think #93 will be Toolbar-based, and I would prefer consistency regarding that. I'll test out these ideas when I actually get to doing all of these reworks.

[KraXen72]

cool. well you could still use a lone fab <-> toolbar with fab and a discard action combo:

[OxygenCobalt]

Sure. This is my idea:

• One FAB exists to toggle the edit mode.
• When clicked, it becomes the save button (FABs do clear and constructive actions, cancelling is not clear or constructive).
• To drop changes, an cancel button will be on the toolbar, like the back button.

This seems to be the most coherent way to do this. Even better, it might make that "swipe up to queue" idea finally work. All those weird touch events from dragging items are now in their own mode, in which I could just disable swiping until the edit mode ends.

[KraXen72]

okay nice, i won't really discard queue edits anyway most of the time. this is good 👍

[OxygenCobalt]

Quick thing @KraXen72. While the swiping behavior is feasible now, I don't think it will arrive with the resolution of this issue.

This is mostly because I want to bundle it with a bunch of other ideas I have with the playback UI ¹ (Mostly #94, liked songs with #36, and maybe equalizer support). Assuming that I add another "destination" from the main playback UI (See: Equalizer), it would be far more likely that the swipe gesture would be configurable, hence it might take more time to implement. It would also be nothing like the existing swipe gesture so that I can make the UI a little cleaner, which also requires me to make a brand new implementation.

Sorry for making you hold out this long for what is very much an inferior UI flow. There is just a lot I am working on.

Footnotes

1. If you want an idea of what I'm planning, have this mockup ↩

[KraXen72]

okay, I don't quite understand this wall of text lol but it's fine if it's delayed, I get that you strive for quality over release date. Im not quite sure i like the mockup though, I really like how everything is right aligned now, I don't see it often in music players but it makes more sense.

[OxygenCobalt]

Sorry for not making myself clear @KraXen72. You're right in that I'm trying to go for quality over quantity.

As for the mockup, my idea behind it was driven by trying to increase information density and remove some of the non-standard text styles that I use, while still retaining the amount of information that existed prior. I will probably create a feedback thread when I actually start work on it.

[dmint789]

Hi, just wanted to chime in that I would also love to see the current and previously played songs in the queue and to be able to tap on a song in the queue to play it. I think once these are added this app will be better than simple music player in basically every way. Thank you, oxygen, for your work on this app!

[OxygenCobalt]

Some updates on this. I'm planning to ship the following in the next version:

1. Playing songs from the queue. This is already implemented.
2. The queue slide-up behavior. I'm getting tantalizingly close to having a good implementation here. It's probably going to be something akin to YouTube Music, where I'll add a second bottom sheet to the playback view that contains the queue list. When it's expanded, the main playback view will collapse back into the playback bar. I will need to implement this before the next release due to add Motion Transitions #191 more or less killing the old way I did queue navigation.

As for previous queue items, I'm holding that off until a later version. I'm having issues with the design we agreed upon, so I have to figure out another way to implement it.

[KraXen72]

nice, thanks for update!

[OxygenCobalt]

Turns out all I needed was a day to do everything I said in the last comment. The new queue design should arrive in 2.6.0, assuming all goes according to plan.

output.mp4

[KraXen72]

looking really good!
personally id set the closed drawer background to the same as playback view background, so it is cleaner. (the arrow already indicates it's a drawer) but i get if you want to keep material guidelines.

otherwise really clean! i like it

[OxygenCobalt]

personally id set the closed drawer background to the same as playback view background, so it is cleaner. (the arrow already indicates it's a drawer) but i get if you want to keep material guidelines.

My logic is that since the queue sheet does not go fullscreen like the playback view, it doesn't need to remove it's tint. I also like the visual separation from the queue and the currently playing item.

[OxygenCobalt]

Another update: I implemented the ability to see the previous items in the queue. Note that only items considered "Next up" can be edited. All items can be played however.

screen-20220730-093702.mp4

Every change you requested should arrive in the next version @KraXen72. I really hope there isn't some insane issue with this.

[KraXen72]

thanks a ton for implementing all of this !! good work 👍😄

[OxygenCobalt]

No problem. I mean, it did cost me around 2 weeks of my life of staring at google code, screaming at my computer every time I encountered some idiotic design choice, and patching the material design library TWICE to get seemingly simple behavior working, but I the result was worth it I guess.

[OxygenCobalt]

Don't really know where else to put this, but something really cool about the new queue UI is that I can actually implement a dual-panel view in landscape mode/tablet screens.

No foldable support yet, but it's definitely more possible now than it was prior.