Multiple Queues Impact and Feature Mapping

Hi everyone! Saturday Keunes, ByteHamste and I meet and decided the beginning of a deep mapping of all changes needed to be done in order to implement Multiple Queues on AntennaPod.

So here we will begin to list the Features impacted by Multiple Queues or New Features/Behaviors needed to be considered for implementation. Disclaimer: We are going to begin the implementation by adding simple and “dumb” queues that need somehow have the be manually managed by the user.

In general, today AntennaPod expects the existence of an unique queue, all features based on this unique queue need to be changed to expect the existence of multiples queues and so, we need a rule to decide which queue to use.

I will start listing here what are those features that I have detected until now.

A brief context about my personal implementation: I have created the capability for queue creation, where all queues having a name. I have kept a default queue, so I didn’t touched any current behavior of AntennaPod regarding to queue. All failures on identifying a queue, fallback to the default queue usage. Even so, I have some unexpected bugs. I have created multiple queues in order to be able to specify a automatic/smart queue, so I don’t really use multiples queues, considering that, I haven’t explored all, if any, aspects of multiple queues. I don’t consider my fork code to be directly used for the final implementation. I will use it only as a reference to implement multiples queues from the scratch on a clean branch.

Queue Attributes: All queue should have a name specified by the user and an id for AntennaPod work with it. In case of a default queue should it have a name modifiable by the user? Where to place the feature to do Queue renaming? Are there any other attributes?

Queue creation: Today we have a default and unique queue. Should AntennaPod expect the existence of a default queue? So if the user don’t create any additional queue, all the existent behavior should be preserved. This way the Multiple Queue feature would be added without changing the usage complexity for current users that don’t feel this need. Where should be placed the commando for queue creation? Should it be able to create queues from the queue screen menu? If we start without any queue, should we automatically create one once users begin adding Podcasts? Should this first queue creation be transparent or explicitly to the user? Note: If we choose to keep a default queue we could cold install AntennaPod with this queue.

Queue deletion: Where to place the command for queue deletion? Once a queue is deleted, what to do with the play items added only to it? Should they be deleted? Should the user to be prompted to choose between the deletion or to move to another queue? Should user be prevented to delete all queues? So if the user try to delete the last existent queue, should we block the action and suggest the user to clear the queue instead?

Drawer Menu: Needed the definition if we will show the Queues directly in the drawer or just change the item name to indicated that now we are talking about QueueS instead of Queue. In case of listing all queues from the drawer, we need to specify what to list on a clean install (see queue creation). If we list the queues on the drawer should we show how many items there are for each list?

The Queue screen: Should it have a switch capability for changing between queues or should exists a intermediate screen listing all queues to be accessed by the user. In the case of a screen with switching capabilities, what is the rule to define the queue to be opened by default? Should it be the last used by the user? If the drawer has the capability to list the queues, it should send the parameter to the queue screen to open the requested queue for listing

Playback state: Today AntennaPod store its playback state without queue information. It should now begin to store this information to resume from the previous queue used by the user.

Android Notification Panel Item: Should we show the current queue for the user? Should we provide a way to switch between queues from there?

Cover Screen: Should we display the current queue also on this screen? That seems to make sense for me, so user know from which queue that item is being played, that way the user know what to expect after it.

Android Auto: All Android Auto screens and layouts need to be changed to comply with multiple queues.

Episodes Screen: Today we show an icon that communicate to the user that a episode is queued. Should we show the queue name? In case of a episode be placed on multiple queues, what should be displayed?

Episode Queuing: Should user specify the queue destination for an episode once the user click it to download? In case of existence of an unique queue, should we fallback to this queue, without asking any action to the user? Or should we prompt it with an option for creating a new queue or use the existent one? Once a Podcast have automatic download enabled, which queue should be used for the downloaded episodes? Or should we keep them in the inbox for the user to choose a destination queue? Here we are beginning to deal with a kind of smart configured queues aspects. This aspects should be considered when user hold click on any episode and then select “Add to Queue”.

Queue sorting: We should keep the current behavior, but the code now need to know which queue is being sorted. I haven’t changed the sorting capabilities so any time any sorting algorithm is triggered AntennaPod does update the Queue table by moving everything to default queue.

Listened episode (and mark as played): What to do when user listen to an episode listed in more than one queue (or hold press over it and selects mark as played)? Should we remove and/or mark as played from all queues? Should we remove/mark only from the current queue? If so, the automatic deletion needs to be aware of how many queue holds reference to an episode.

Episode deletion/removal: The same as above needs to be considered when user holds a episode and choose “Delete” or “Remove from queue” from any screen.

Reset Playback position (or even the track of current playback position): Should it be done for every queue or globally? So if an item if half played on a queue and its reached on another queue, should we start over or should we resume it? This one will be a kind of polemic since it depends on what user wants from multiple queues.

Queue lock: The lock behavior should be enable/disable by queue. Today if I enable it, AntennaPod locks all queues.

Queue Swipe Actions: Should also be configured by queue or should it be configured globally? Personally I think it makes sense to be a global configuration.

This is everything that I have found for now, and also that I can remember from our meeting. If I remember anything else, I will add.

Ps.:
Automatic Queuing: This is for future implementation. Should user be able to ask a Podcast to be always queued in a certain queue? Should it be possible to specify more than one queue? Where to place this configuration? Should it be related to the Podcast or should it be the queue? Consider the delete cascading: Podcast deletion will cascade the deletion of this configuration. While Queue deletion will cascade to this configuration, leaving Podcast without the configuration. My current implementation use the second approach and I haven’t implemented any treatment for what happens when a queue is deleted and a Podcast and up without any queue configured to use it. There are many other aspects to be considered on automatic queue so we will not dive into it for now.

3 Likes

Hi @igor,

As mentioned via email, many thanks for you initiative here!

Long overdue, but I’ve just uploaded the recording of the user research presentation, which I think is quite relevant. In case you want to watch it: AntennaPod Community Call 2022 10 22 (part 1) - UX research - YouTube

Tomorrow I’ll be working again on the mock-ups & flow.

2 Likes

Let me reply to some points that I’m not already covering in my UX work, or I think need additional information:

I’d say so, yes.

For now I can only think of the the ‘source’ podcasts. When queues might become ‘smart’, I’m sure there’ll be more attributes.

Yeah, I think this should be kept for consistency between versions.

I personally prefer to list all queues; I think it’s more transparent. But we can also make a mock-up for the other option (1 queue screen, with selector to determine queue).

Yes. Maybe that’ll make it easier to implement Continuous playback if initiated from podcast screen (+ reversed) · Issue #1533 · AntennaPod/AntennaPod · GitHub.

I think that’ll be a bit much. The notification is full enough already I think.

Hmm. Again, the full player screen is quite full already, especially on smaller form factors. But, something to reflect on.

Not sure what might be needed there. Should we expose the different queues? Or do we only expose the current queue? Might not be a bad idea from a security perspective (force user to pick a queue before departure). @tonytamsf any thoughts? (welcome back :tada:)

Again: I would keep current behaviour to not clutter the interface further. If there is a clear rationale for why this would be needed, we can think about this later.

In my mock-ups I’ve added a ‘source queue’ selection per queue. If a podcast is a source for multiple queues, an episode is/can be placed in multiple queues.

Yes, actions apply to the episode, whichever queue it is in. I think this is the most predictable, and avoids having to apply the same action multiple times. Also, generally (known exception: langauge learning) you’ll want to listen to an episode only once - regardless the queue it is in.

Hmm, as ‘Remove from queue’ is an action to an episode in the context of a queue, I think it should apply to the current environment (queue) only. If it should be removed from all queues, the user can use workarounds in the beginning - dedicated functionality could be added later.

I think that indeed this should be queue-specific. Also because there is a link with Sorting (in case ‘keep sorted’ is active) and this may differ between queues.

Agreed - global configuration.

Allright, my prototype is pretty much ready. I think I might need to fix some flow mistakes, but all the screens are ready to show. @igor, @ByteHamster; would you be up for a meeting where I showcase the screens & design? If yes, would next weekend Saturday work for you?

Thanks for pointing me to this recording Keunes! I’ve just watched it and it was very enriching. I found myself on many behaviors maped by Howard’s research!

I have availability for the next Saturday. It could be on my early morning like last time or a bit latter (skipping my lunch time for sure), if you have any other scheduling preference.

Since we are almost at the weekend, I suggest to schedule a meeting to the next one.

@igor when can we expect an update with the ability to have multiple queues?

@anon45685503; @igor, @ByteHamster and myself had a meeting two weeks ago, where I presented the mock-ups (designs for all the changes in the user interface). They gave some valuable feedback that I need to follow up on (adapting the mock-ups). Unfortunately I haven’t found the time to do so yet, as I was busy with personal stuf and needed to prioritise work on the 3.0 release (changelos, press release).
There are many different parts & pieces that together make the multiple queues feature, which all need to be developed. In our meeting, Igor and ByteHamster said that as I’m updating the mock-ups they could start thinking about the order in which the code for all these different pieces could be written and reviewed. I guess that like me they haven’t found the time to work on it.

Once AntennaPod 3.0 is fully released I think we’ll have more time to work on the multiple queues again. However, to get back to your actual question: it’s a big project and it’s impossible when or in which version this will become available.

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.

@ByteHamster When you’re back from holiday, would you be interested in picking this up again? @igor, are you still up for working on this if we put our shoulders behind it from our side?