Be graceful when selecting a song that resets a manually made playback queue about auxio HOT 4 CLOSED

I'm aware of this issue already in #532. It is a bit of a shortcoming, but there's no strong consensus on what to do.

An undo snackbar or dialog is deeply intrusive, especially if you are just blindly jumping around and playing music. I also can't try to heuristically guess when it would be most relevant to prompt the user, since I can't psychically understand user intent by what kinds of edits they make to the queue. Vinyl had a big thing awhile back when they added a similar prompt, I want to avoid that.

From #532, I proposed these options:

• I could add some kind of "queueing" mode that's either dynamic or settings-controlled. Playing a song becomes equivalent to "Play next".
• If #407 is added, playing a song could spin up a new playback state. This way you could just jump back to your old one. This would probably be a setting normally, since if enabled by default it would lead to a lot of dead playback states lying around.
• I could add a menu, but not have enabled by default. A new setting is added to control whether you want to destroy the queue, add to the queue, or ask every time.

Let me know your thoughts on these, for now I'm closing this as a duplicate.

from auxio.

Oh, thanks! I'll track #532.

OK, here are a couple of thoughts:

• if the problematic case is when you blindly jump around to play music, then perhaps this makes a good case for differentiating automatic queues (user select one song, Auxio rightly assumes all other songs of given album/view plays after) and manual queues (user has at some point moved or added one or more songs using "Add to Queue" or "Play Next").
• A non-intrusive way could be to add an "Undo" menu item to e.g. the context menu (three-dot) of the now playing screen, which restores previous playback state. This is equivalent to your playback state idea (#407), but requires just tracking a single "extra" playback state.

Another way to deal with this problem is by further minimizing the possibility to misclick. I did not mention this, but it seems like Auxio requires a quiet accurate touch to open the context menu on a song? For example, if I press in-between two horizontal dot menus, a new song starts playing. I can also make a new song start playing by accidentically pressing slightly to the right side of the horizontal dot menu.

I tried to visualize it below, left-most image shows how it feels like the boundary of the horizontal dot menu is defined currently, whereas right-side image might be more ideal - it would create a "safe zone" if users intentionally dont want to play the song (and thus destroy their song queue).

VLC used to have this problem, but they recently fixed it, see e.g. how the context menu takes up the "full" height and right-most margin, leaving no space for accidental mispress.

from auxio.

Oh, thanks! I'll track #532.

OK, here are a couple of thoughts:

• if the problematic case is when you blindly jump around to play music, then perhaps this makes a good case for differentiating automatic queues (user select one song, Auxio rightly assumes all other songs of given album/view plays after) and manual queues (user has at some point moved or added one or more songs using "Add to Queue" or "Play Next").
• A non-intrusive way could be to add an "Undo" menu item to e.g. the context menu (three-dot) of the now playing screen, which restores previous playback state. This is equivalent to your playback state idea (#407), but requires just tracking a single "extra" playback state.

Another way to deal with this problem is by further minimizing the possibility to misclick. I did not mention this, but it seems like Auxio requires a quiet accurate touch to open the context menu on a song? For example, if I press in-between two horizontal dot menus, a new song starts playing. I can also make a new song start playing by accidentically pressing slightly to the right side of the horizontal dot menu.

I tried to visualize it below, left-most image shows how it feels like the boundary of the horizontal dot menu is defined currently, whereas right-side image might be more ideal - it would create a "safe zone" if users intentionally dont want to play the song (and thus destroy their song queue).

VLC used to have this problem, but they recently fixed it, see e.g. how the context menu takes up the "full" height and right-most margin, leaving no space for accidental mispress.

The issue is that there is zero differentiation from automatic and manual queues internally. There is no real dividing line between them anyway, a user might casually fiddle with some items, decide to play something else, and then get frustrated when they run into the same dialog again and again.

I also just don't like the undo UI flow. Undo is just not semantically correct in a playback context, it invokes edit/deletion connotations and I imagine it's confusing to most.

The more buttons uses a standard touch target size (48dp), growing it is possible but highly fiddly. Could do it though.

from auxio.

I think all those considerations regarding Undo/queues are completely fair.

The more buttons uses a standard touch target size (48dp), growing it is possible but highly fiddly. Could do it though.
Ah, that's unfortunate - I think keeping code clean is important.

In any case, I have found myself a workaround for these situations. Long-tapping activates selection mode and by consistently long-tapping whenever music is playing/manually queued, I can always ensure that the song queue is not destroyed, even if I mispress the context menu because it just selects/deselects the song.

When filing this issue I wasnt aware of this and never thought to try it, but selection mode clearly makes it much safer to queue music in inaccurate environments.

Just want to say thanks again for your super thoughtful replies and excellent program!

from auxio.