Wouldn't the same argument (simplification, it's what other apps do) apply to the long-press menu? I have the impression that differentiating single-select and multi-select is the exception nowadays.

If the top bar is too crowded or hard to reach, there are examples of apps using a bottom sheet or bar (e.g. Google Photos uses a horizontally scrollable bottom sheet with fully labelled icons, which is overlaid on top of the bottom navigation).

I'm personally impartial to removing SpeedDial. I like the current speed dial multi-select actions, but I wouldn't be against switching to just using the top toolbar.

Obviously the users are going to be the ones you have to ask about this. I think this question should be asked on the AntennaPod forum for user feedback.

Wouldn't the same argument (simplification, it's what other apps do) apply to the long-press menu? I have the impression that differentiating single-select and multi-select is the exception nowadays.

Yes, that's one more reason to make it more standard compliant. Though I would start with multi-select for now because that's less intrusive. Changing the long-press menu will probably make some people not happy. Though I would say that most of the long-press options (except for maybe "move to top/bottom" in the queue) can be achieved with swipe actions anyway, so maybe it is okay if the options are a bit harder to reach.

I had a look at a bunch of apps on my phone where I can multi-select. Basically every app does it via the header bar, indicating the current selection number (not the total number of episodes. Some have 'selected', some only the number.

I like our FAB but cannot deny that the top bar is a common pattern. from the apps on my phone only Signal & FairEmail deviate from that pattern:

So I'm on board with this change. We just have to identify per screen which icons we'll put in the top bar, and which ones will be in the overflow.

I don't think we can show much more than just 2 icons by default. For these, I would use (consistently across all screens) the first single-select long-press actions "mark as played" and "add to queue" (because in the future, we might want to migrate single-select to always start multi-select).

This issue has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/mark-all-newer-older-episodes-as-played-after-selected-one/4236/8

@ByteHamster IIRC two reasons for moving from the library to the overflow menu was maintainability and accessibility. Doesn't the in #7093 applied approach (Signal modal) have the same issues?

Plus with bottom navigation limited screen estate is left.

The accessibility should be better because it immediately tells the actions when jumping to the next container instead of just saying "unlabeled button". Also Discoverability for visually able users should be better. I have heard from a couple of users who didn't realize they need to click the "apply action" button to get to the actual multi-select actions. This way they are immediately visible.

Two advantages over the toolbar buttons:

• Can show titles, so maybe a bit more clear than the toolbar icons (and fewer clicks than overflow items with title)
• Closer to the finger

Plus with bottom navigation limited screen estate is left.

I think there is still quite a lot of screen space left, so that should be okay I guess.

Hi @VoidCrater,

We initially agreed to move the multi-select actions to the top app bar, but @ByteHamster preferred the way that Signal implemented multi-select. I must say I quite like it too.

We were wondering, though, if you would mind checking if this approach is easy to use in combination with TalkBack. Would you perhaps be willing to test that, and leave any feedback on any improvements desired on that front?

There is a 'debug' version from AntennaPod that you could download and install, in which this approach is already implemented:
AntennaPod-debug-multiselect-action.zip

Please let us know (also if you'd rather not receive such requests from you any longer).

@keunes

We initially agreed to move the multi-select actions to the top app bar, but @ByteHamster preferred the way that Signal implemented multi-select. I must say I quite like it too.

I like this approach as well.

We were wondering, though, if you would mind checking if this approach is easy to use in combination with TalkBack. Would you perhaps be willing to test that, and leave any feedback on any improvements desired on that front?

Of course!
I installed and tested the debug version, and here are a few suggestions that I'd recommend:

• I think it would be helpful to make TalkBack announce where the toolbar actions appear on the screen. As soon as the user enters selection mode, TalkBack could say something like "Toolbar actions shown at the bottom". This would let the TalkBack users know where the actions are located and won't have to explore the screen to find them. A good example of this implementation is Google Messages multi select behavior.
• On the subscriptions, queue, downloads, playback history screens, when I enter selection mode and then perform the four finger swipe to get to the next container, TalkBack focuses on the first item in the bottom toolbar, however, this doesn't happen on the individual podcasts screen. Does this behavior have something to do with the issue material-components/material-components-android#3648?
  if not, then this is probably a bug that needs to be looked at.

Other than those suggestions, I think this implementation will work very well with TalkBack.

(also if you'd rather not receive such requests from you any longer).

I'm happy to contribute in any way possible. I'm also willing to test out features with TalkBack in the future :)

Thanks a lot for testing!

As soon as the user enters selection mode, TalkBack could say something like "Toolbar actions shown at the bottom".

Added.

TalkBack focuses on the first item in the bottom toolbar, however, this doesn't happen on the individual podcasts screen. Does this behavior have something to do with the issue material-components/material-components-android#3648?

Yes, I would guess that's the same issue :/