Be graceful when selecting a song that resets a manually made playback queue

[bastianilso]

Description

I suggest Auxio provides an undo button on a snackbar, when users press a song which then clears their existing manually made play queue - especially in situations where users manually constructed/manipulated the song queue. Users might not intentionally "overwrite" the play queue - it might be due to misclicks or poor conditions for performing touch input when travelling.

Problem solved

Misclicks happen when you're on the go.. Was on a bus ride the other day, made a nice long queue of songs lined up.. after lots of careful manual selection, just as I was about to press the context menu to add another song to the queue, we drove over a small bump and i misclicked. The entire queue I had made disappeared, replaced by the song I clicked, moving me back to square one (reconstructing the queue again from scratch).

The scenario above should be easy to replicate in other scenarios: clumsy sausage fingers, wet/moist environments, sweaty hands, unstable traveling environments like driving/flying/..

Other implementations

In general Android uses this "undo" snack bar pattern in many places where there are "destructive" actions - clearing items, replacing items, deleting items, moving items..

In terms of other music players, I faintly recall Spotify used to prompt you with a dialog are-you-sure style if you were about to rewrite a manually created song queue, however, prompting also adds a second step of interaction. Could not find a screenshot of it, but I did find this one shown when pressing "clear queue" which i guess is similar.

I tested the stock android player and VLC, but they seem both to happily overwrite your entire song queue with a single (wrong) press..(like Auxio currently). The stock android player even shows a snackbar with the title of the new song, but no "Undo" button (an oversight?).

The third pattern I have seen is that some photo editors provide more explicit undo/redo buttons in a toolbar or hidden away in context menus, but that might come at the cost of taking up precious space.

Benefit

I think an undo snack bar provides a useful pathway to remedy misclicks when they are destructive - i dont think it makes to have undo buttons for everything, but the case I present above is the situation where, for Auxio, it could make sense. It remedies a potential source of user frustration especially common on mobile devices where touch interactions add to the unpredictability of device usage. There are various approaches to this, but the "undo" snackbar solution I suggest here here could solve the problem, while getting out of the way as much as possible in other scenarios.
Not sure whether its necessary to differentiate between "generated song queue" and "manually made song queue" scenarios for the feature - but I mention it here to highlight that the latter category is arguably the scenario with most exposure to the problem.

Duplicates

• I have checked this feature request for duplicates.
• I have checked that this feature is not implemented in the lastest version.
• I have checked the Why Are These Features Missing? page.
• I agree to the Contribution Guidelines.

[OxygenCobalt]

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 Multiple saved playback states #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.

[bastianilso]

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 (Multiple saved playback states #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.

[OxygenCobalt]

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 (Multiple saved playback states #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.

[bastianilso]

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!