[x ] I have used the search function to see if someone else has already submitted the same feature request.
[x ] I will only create one feature request per issue.
[x ] I will describe the problem with as much detail as possible.
System info
App version: 2.1.3
App source: Google Play
Feature description
Problem you may be having, or feature you want:
Swiping episodes in the âEpisodesâ screen is
complicated: swiping the wrong direction changes tabs
ambiguous: it doesnât indicate what happens when an episode is swiped
not customisable: you canât change the swipe action (e.g. âadd to queueâ)
limited: you canât swipe in two directions (each with their own action), and in the current design adding such option is impossible
More issues (incl user requests we can't meet)
Users are requesting new elements to be added to the (all) Episodes screen, while itâs already quite packed with elements. The multifunctionality comes at the cost of simplicity and usability.
The former is an indication of the ambiguity of the swipe action in the Episodes screen
Selecting âMark as playedâ is a bad workflow for ignoring episodes, as it will (or at least is perceived to) mess up statistics.
Many users donât seem to use the queue. For some this might be despite a thoughtful reflection, for many I suspect this is because it doesnât server their workflow currently.
Suggested solution:
Introduce a new screen/system called âInboxâ
The inbox displays the episodes until they are swiped away from the inbox or the inbox is cleared.
Episodes can be swiped left or right, and the user can set their preferred action for each. They can choose from four swipe actions, which they can change in the settings:
Add to queue: Adds the episode to the queue. It might be downloaded automatically, depending on your settings. Default right swipe action for users that have Automatic Download disabled.
Download: Downloads the episode.
Ignore: Excludes the episode from Automatic Download, so it will not automatically end up in your queue. Also greyes out the episode, as if it was played. Default left swipe action.
Remove from inbox: Simply removes the episode from the inbox. It might be downloaded and added to the queue automatically. Default right swipe action for users that have Automatic Download enabled.
Inspiration for swipe actions and screens was taken from Gmail, GitHub and Outlook.
More details: feature specifics, new statuses, affect on Episodes screen & Automatic Downloads
The number in the side menu displays the number of episodes in the inbox, and cannot be changed.
The inbox can be filtered by podcast (e.g. to review all episodes from a specific podcast), or publishing date (e.g. to review all episodes that are a year old).
In the process, we simplify/clarify episode statuses:
New: episode found since a) the last generic feed update OR b) last checking the Inbox screen
Normal
Ignored: episode was indicated as not-interesting by the user. These episodes are greyed out, and they are excluded from auto-download.
Played: episode has been (fully) played or manually marked as played. These episodes are greyed out.
âInclude in auto-downloadâ is not a status, but episode data that can be flipped (unless marked as ignored).
âEpisodesâ remains as a screen, but with the following changes:
The tabs are removed - it always shows âallâ episodes
It is no longer showed by default (for new installations)
The âEpisodesâ screen gets a dedicated âFavoritesâ toggle button.
A new âFavoritesâ screen is introduced, but disabled by default. If the screen is included in the menu, the âFavoritesâ toggle on the âEpisodesâ screen is hidden.
Automatic Download process prioritises episodes that are not in the inbox - i.e. episodes that have been âOKâedâ by users: user did âRemove from inboxâ. This way, the user doesnât end up with an episode in the queue that they would have ârejectedâ. Only when there are no âOKâedâ episodes left, the process will take episodes currently in the inbox into consideration.
Any âRemove new flagâ entry in episode contextual menu is removed - in line with the updated, automatic nature of the âNewâ status. This helps simplify the context menu. If so desired, this a new contextual menu item âIgnore episodeâ can be added (though that undo simplification of context menu).
This has the following benefits:
More & customisable swipe actions (not possible in current design) that support all above user flows
A cleaner UI, which at the same time allows for showing more information per episode & that creates space for adding some requested features (e.g. batch editing)
A new clear, single entry point for making a (pre)selection, regardless your workflow:
Users who that make use of âAutomatic Downloadâ will have a quick way to filter out any episodes they certainly donât want to listen to
Users that start playback of individual episodes (from the âNewâ tab or from the Podcast screen) will have a quick way to indicate which episodes which episodes they want to download. Also, these users are encouraged to using the queue, as there now is an easy way to select what you want to add (without any automatic process involved).
Users that manually add items to the queue, now have an easy way to do so (donât have to long-press episodes in the New tab or on the Podcast screens).
As the app gets data about which podcasts get ignored often, AntennaPod could in future better serve content relevant to the user (e.g. in Home screen, by displaying number of ignored episodes in the Stats)
Screenshots / Drawings / Technical details:
A few screens (Inbox, detail view, menu, new Settings screen, Episodes, and Episodes with favourites filter):
Please see the interactive mock-up to get a better feel of how it works and a couple more screens (e.g. âClear inboxâ dialog, episode detail view, swipe action explanation in the settings).
To see the interactive elements (where you can click), please click on the eye icon and select âShow interactionsâ:
Please,
provide feedback on this idea & the mock-ups
submit links to relevant questions, comments & feature requests from any GitHub issue or form thread that might provide evidence for or can help improve this idea
I will start saying I didnât thought about it enough but at first read my reaction is :
inbox seems to be episodes screen revamped
ignored status is a good idea but it will probably means we need to display tag in a podcast subscription to distinguish between read or ignored
why isnât it better to improve episodes screen ? Inbox is somewhat just another view along new, all and favorites episodes. Same for âto be watchedâ. And as it would make a lot of tabs maybe we could combine new/all and favorites/to be watched and have a kind of drop down or switch to change filtering. It could even be only one tab
For automatic downloads it could be useful to have a tabs in download screen (something like âplannedâ) to see what is queued to be auto downloaded ? And maybe be able to change it ? (But I donât use automatic downloads so I donât know if it would really be useful)
It seems to me that issues which it aims to resolve are not real issues. From my (small) experience with other more popular podcast app itâs the same. It could be good to know what they do to mitigate things but I believe itâs not a lot different
Again itâs a first reaction without really thinking it through.
Iâm really surprised by users not using queue. I am wondering if they are only casual listeners and so didnât look too much how things worked. Maybe instead of âqueueâ it would be better to use âplaylistâ ? (But it would work only for english users)
It is, kind of. I would say simplified and improved And the âEpisodesâ gets its own clear purpose: displaying all episodes. No distraction with hidden or secondary functionalities.
Not sure it matters to make the distinction - in both cases theyâre greyed out and are there to be forgotten If we do decide to have a label, it should probably just be spelled out just like the ânewâ label - I couldnât find a suitable icon.
Fair point. Few reasons for adding a new screen:
lists of new/not-yet-reviewed and of all episodes are used in different cases/purposes, which are currently mixed
it makes it easier to understand what the screens are for (by their name, and in-screen functionality)
it improving discoverability of swiping away features
the Episodes screen canât get more swipe actions, as swiping will switch tab
an improved Episodes screen wouldnât address the issues with the current âNewâ status and the âMark as playedâ option
I use auto-download. The process is currently a bit of a mystery - being able to understand the process would indeed be helpful. However:
It would possible to see what might be auto-downloaded in the âEpisodesâ screen, using the âAutomatic downloadâ filter
A âdownload queueâ wouldnât help me understand the functioning of auto-download (text with icons would be better for this)
It should not be possible to interfere in the auto-download process (thatâs what the queue is for, and otherwise the auto-download can get even more complicated). Also, I have no interest in this - I prefer to let the app do its work. If I want I can already interfere by adding an episode to the queue.
I understand this comment. While âsmallâ - what I describe in my first post does indicate there are actual problems with the user experience. I think this proposal will improve the user experience for all workflows (individual episode play, manually adding to queue, using auto-download).
This idea has been brewing for a long time. Different users have made requests over time to which I think this could be the solution (unfortunately I canât quickly find back those requests - hence the call for supporting evidence).
What do you mean? Did this app also have an inbox?
No I meant it was the same as AntennaPod : no inbox but queue and subscriptions. It was long ago and I quickly switched to AntennaPod. (For reference it was podcast addict)
But maybe things changed and I was wondering if other apps have some sort of inbox or if every apps is basically the same.
How would this work together with the home screen? I fear adding more screens will not make the app easier to use.
To me, it sounds like the inbox would basically be the same as the current âEpisodes » newâ screen, just that it is displayed in the main drawer menu.
Different options. We could display the 4 latest episodes from the inbox. We could display 4 random episodes that were OKâed (removed from inbox, not added to queue) yet. To be discussed - donât see a particular obstacle here.
The Episodes screen is multifunctional, I believe to an extent that makes it hard to use and its potential untapped. Better two simplified screens than one monster whose potentials users donât tap into.
Especially since users can disable the screens that they donât use (which would be one of the things to customise during an onboarding procedure).
As I said already to Matth78: I canât deny the similarities. However, again, I still do believe in the added value, especially that of more & customisable swipe actions and a cleaner âall episodesâ screen UI.
Iâve updated my initial post so that itâs a bit more readable, and to include some of the main screens.
By the way, my user testing subject (aka partner) said end last year they were missing a way to easily indicate what they wanted to listen to. After testing the initial mock-ups with him, he responded positively to the question whether heâd use it. Would be interesting to hear from others also.
Maybe we could just rename the ânewâ tab to âinboxâ to make it more clear what it is supposed to be used for? If we then show it as the first item on the new âhomeâ screen, I think that it is quite easy to understand for users.
To be honest, I donât like detailed onboarding screens. Users probably donât know yet what they will like. They do know the theme they prefer and maybe even if they prefer to download or stream but I think that on-demand configuration (like what we currently do for download vs stream) is a lot more helpful. Especially for the sidebar, Iâm not sure if users should be bothered with showing/hiding specific screens before they have even used them.
To be honest, that wouldnât solve my main problem: I want to be able to tag episodes that I (might) want to listen to, and tag episodes that I (certainly) donât want to listen to. This requires two-directional swiping.
Fair point. Not that onboarding the topic of this thread, but a question that could tackle quite a few things would be: Do you want to a) use an inbox to review each new episode b) let automatic download pick random episodes, or c) occasionally initiate playback for individual episodes.
This could have an affect on screens visible in the menu, automatic download settings, and maybe more.
To me, this feels like users will be more confused than assisted. They might never realize that specific features exist if we just never show them. Also, it increases the number of different configurations users could have, which makes support harder.
UPDATE: added all the suggestions from the mockup and more here Home screen proposal - #30 by ueen (settings are in a dialog, that can be opened from the toolbar and works on a per screen basis, so you can have different actions in the inbox, episodes and podcasts-feeds)
@ keunes Thank you for your attention and email (wrt my feature request). You understand my problem perfectly well. Now this said, I am always in favor of simple solutions, based on what a user does already know. In this case, simply another item in the already existing context menu what do just fine. Right now one can choose between
mark as un/played
add/remove from queue
add/remove from favs
visit website, and
share.
If you could add one more item called âignoreâ that would be perfect. Its function: remove this episode from the list of visible items - forever! remove it from queue (if already contained) too, delete it if it has already been downloaded. In other words : get rid of it in every context, with just one command. Non of the earlier listed commands can do this job efficiently as of now.
Hope this helps !
While thinking a bit more about the inbox lately, I noticed a possible problem: I fear that the users might have a hard time getting the difference between inbox and queue. So users will probably request adding things to the inbox manually and maybe even to organize items within the inbox, while this is actually not the purpose of the inbox. Any ideas on how to make the distinction between inbox and queue more specific? Maybe having âAdd to queueâ and âIgnoreâ as default swipe actions could help, even though âadd to queueâ does not really align well with the default to download things that one is interested in.
I believe reworking New/Inbox is deeply coupled with how to add an Ignored/Skipped state. I tried making sketches of what I see as problematic with the current state transitions, how I suggest them to be fixed and how the existing GitHub ticket suggests them to be fixed. Please see the post I just made containing them.
So yes, I am suggesting to be able to add items to the Inbox. Essentially because it makes sense to do so. The only reason for not allowing it is because the current implementation of auto-download has problems with it. Are there other reasons for preventing a simple model for episode state transitions?
The reason is that it goes against the idea of the inbox. The inbox is supposed to be a list of episodes that users did not interact with yet. Not some kind of manual playlist.
Seperating to Inbox the whole point was to clarify the concept, I think it makes sense, maybe for new users a small grey text could be added under the least New episode in Inbox like âYou received new episodes, decide wheter to add them to the queue and listen or dismiss themâ. Similar to the explain text in the empty queue.
In general I would focus on the actual feedback, this might never be a problem for the average user. The inbox concept is definitely way easier to understand than the current 3 tab episodes list!