'Refactor' episode statuses & introduce 'Ignored' status

[keunes]

Checklist

• I have used the search function to see if someone else has already submitted the same feature request.
• I will only create one feature request per issue.
• I will describe the problem with as much detail as possible.

System info

App version: 2.3.0-beta2

App source: Google Play

Feature description

Problem you may be having, or feature you want:

• Wanted feature: Users (like in Feature : Add "Won't play"/"Ignore" option #2662, as well as my boyfriend and I) want to be able to indicate which episodes we certainly don't want to listen to (thus want to exclude from auto-download).
• Wanted feature: Users (like in Add option to automatically mark filtered episodes as played #6252) want to be able to automatically ignore episodes bas on search keywords.
• Problem: Users (like in manual "hide from list" command #5178 (comment), but I've seen it mentioned before, and also #1) mark episodes as played that they don't want to listen to. They do this because it excludes the episode from auto-download and/or makes the list item grey (indicating it can be ignored). This, however, makes that the status no longer reflects reality, and (depending on the user's settings) messes up the statistics.
• Problem: More generally speaking, we need(ed) a support page to explain the point of the different statuses. (This indicates unclarity of the statuses. It has since been rewritten in a human-friendly text.)

Suggested solution (Last updated: 21/09/2023):
1a. Main statuses remain as follows:

• Default/Unplayed: this is the 'main status' (it is not any of the other statuses), indicating that the episode has not been played yet by the user and might (or, if the user uses the inbox, will probably) be played.
• Played: Indicates that the episode has been played (listened to or watched). Mainly automatic status, but can be manipulated by the user (e.g. in case they listened to half an episode but don't want to listen the other half, or they listened and want to listen to it again).

Whether an episode is in the Inbox or not is not a 'status' per se, but more piece of metadata that might be set to true for episodes with the statuses New and Default/Unplayed (it cannot be combined with the statuses Played or Ignored). In a way it is similar to whether an episode is in the Queue or not.

The life of an episode typically passes three stages: from 'in inbox', to Default/Unplayed, to Played or Ignored. They are mutually exclusive (though I don't know if 'in inbox' is currently a status or a separate piece of metadata).

Nice-to-have: a separate 'New' label to indicate what episodes are recently found.

New: Automatic status, cannot be changed by the user. Can be based on either of the following criteria:

• published the last xx days
• published the last xx days and not interacted with (e.g. downloaded, played)
• published since I last opened the app/Inbox (e.g. I check my Inbox every two days, but don't manage to empty my whole inbox; only the episodes that are new since last I opened the Inbox have the new label, episodes that I (could) have seen last time don't have the new label any-more)

1b. A new separate status (boolean) gest added: Ignored.
It indicates that the user really is not interested in the episode. They might want to delete the episode, but this is not possible in AntennaPod. It is mainly a manual status; it currently doesn't get applied automatically (in future it can be set automatically based on filter keywords - see #6054).

Main status	In inbox	Is ignored
Unplayed	Y	Y: not possible
		N: displayed in lists
	N	Y: hidden
		N: displayed in lists
Played	Y: not possible	not possible
	N	Y: hidden
		N: displayed in lists

2. Interaction with the status

• a swipe action gets added to the inbox for this status, which will be the default for new installations
  
• an option to 'Mark as ignored' gets added in
  • the overflow menu on the episode detail page
  • the context-menu of episodes (long-pressing in a list), above 'Mark as played'
    • to make space, the 'Share' menu item gets removed (the only option that does not apply an action to an episode)
• a modal gets shown with the 'ignore' and 'remove from inbox' options when the 'clear inbox' button is used for the first time
  

3. If an episode gets set to 'Ignored' by a user:

• Its media file gets deleted
• It gets removed from the/any queue(s)
• It is no longer considered by automatic download mechanisms.
• It is clearly marked as ignored in lists:
  • it is greyed-out, like a played episode
  • it has a big thumb down in the background, like this: https://imgur.com/a/onhrdsw
  • for users of screen readers, it is as if a regular icon is added in the front of the metadata rows (i.e. before the other icons (queue, favourite or video), and before media file size.
• It is clearly marked as ignored in the detail page: below the horizontal line an 'info bar' is shown, starting with the 'ignore' icon followed by the text "You have ignored this episode"

Screenshots / Drawings / Technical details:
See also the Inbox proposal, to which this contributes (though this can also be implemented without the Inbox). Relates to #5191.

To be decided:

• Whether we call this 'ignore' or 'archive'
• Whether the icon is a thumbs down or an archive box (if we use the word archive, we should definitely use the archive icon)

[keunes]

Ping @ueen @ByteHamster :)

[ueen]

Hmm so just excluding episodes from auto download or delete download if swiped away in inbox wouldn't solve your use case? (Or turn off auto download and only download if added to queue - possibly through inbox)

My first impression is just that adding another status complicates things more than simplify them, also played and ignored then both look the same (greyed out) which also kind of defeats the point because then you could just mark them a played, if you want them to be greyed out.
And for the statistics, aren't they counted by played minutes? For an episode just marked as played that would be exactly 0, no?

Rather than played the state is more like read (as it's also called sometimes in the app), you've seen and maybe listened to it, and are done with this episode either way.

Sorry I don't mean to shoot down this idea form the get go, I do somewhat see your point about "reflecting reality", but I'm just not convinced it's worth the confusion about the states (the magic number is always 3 😂😇) and what they mean and the extra context menu, filter, swipeactions and database field this would require, while adding minimal functionality at best.

[ByteHamster]

To be honest, I agree with @ueen. Not really happy about adding more states.

New: Indicates that the episode is recent. Automatic status, cannot be changed by the user.

I think users will request a manual action there. Why highlight an episode that was already listened to, just because it was released at the same day?

Ignored: Indicates that the episode is not interesting enough for the user.

An episode that gets manually removed from the inbox without downloading or adding to the queue is already indication enough that one is not interested, in my opinion.

Ignored: Episodes with this status are not considered for automatic download

The same already applies to non-new episodes, too (eg. you swiped them away on the "new"/Inbox screen)

---

I think when moving the "new" screen to the sidebar and calling it "inbox", it is already a lot more clear that this is meant to be the place where you decide if you are interested in an episode or not. It seems

[ByteHamster]

Meeting decisions:

• Introduce new state "ignored" (==> greyed out ==> striked through or ignored icon)
• All episodes get ignore/unignore context menu items, except in the queue

• Remove "visit website" and "auto download" toggles from the menu

[peakvalleytech]

@ByteHamster @keunes @ueen
Hi, i have a suggestion. Instead of 'Ignored' how about we use 'Skip' instead. 'Ignored' seems ackward and harsh. Also 'Skip' is shorter and users are more familar with the term 'Skip' as it used by some apps for other features. I hardly ever see 'Ignored' used for anything, except for 'spam emails' :)

[ByteHamster]

"Skip" sounds to me like it would otherwise be played. That's not what the ignored state does: It is a way to remove an episode completely and never see it again - kind of what a spam filter does, so I think the context actually fits. Also, skipping is already an existing feature that goes to the end of the episode and plays the next one.

[peakvalleytech]

I still don't like 'Ignore' sounds too negative, as if the episode were spam. But that is just my opinion, you can do whatever you want. As long as others agree to accept it also. Maybe 'Pass' is better? That's my final suggestion. You can keep 'ignore' if you want.

[ueen]

I think you actually got the right association, I think it's supposed to be something like spam.
You could either listen/add-to-queue, leave it unplayed or if you don't want to see it anymore: ignore.

[keunes]

For me 'ignore' doesn't feel super negative, like 'spam' is. 'Pass' I think isn't clear enough. The only other terms that come to mind are

• Not interested (a bit longer, and not a verb - in the UI it'd have to be "Mark as not interested" which really is long) and
• Hide (also short, strictly speaking not correct as you'll still see it in the Podcast screens¹, but this could work for me).

¹ at least that's how I see it, but @ByteHamster seems to have a different idea

[peakvalleytech]

I think you actually got the right association, I think it's supposed to be something like spam.
You could either listen/add-to-queue, leave it unplayed or if you don't want to see it anymore: ignore.

So 'Ignore' removes the episode from the inbox? Accept my apologies for being so critical but i really do want to accept the term. However, my gut feeling just keeps telling me that there are better options. I realize keunes probably has more experience in UX, but I do have experience designing my own apps and my criticism is based on this experience. But I guess we can stick with ignore.

@keunes, ok maybe we keep 'ignore' for now.

[Matth7878]

I also believe "ignore" to be the better word as it would flag an episode as one you would never listen to.

It wouldn't be proposed to you in futur home screen for instance as an episode to catch up to. It would not be displayed as an episode you still hasn't listened to or one you have.
I guess it won't count either for subscription counter when set to display number of unread episodes ?

I don't perceive ignore as something negative, just something I don't care about. I don't like skip has it doesn't mean you're not interested. Hide is not good as you don't hide it. The only alternative (already suggested) is "not interested".
Or we could use "bench" as when you bench a player in sport! 🤔🤣

[keunes]

So 'Ignore' removes the episode from the inbox?

Yeap, that's the idea.

[antennapod-bot]

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

https://forum.antennapod.org/t/mark-episode-s-as-new-filter-on-new-episodes/1683/3

[keunes]

@ByteHamster Was this also covered by #5267? (just to know if this should be closed, too)

[ByteHamster]

No, that PR just renamed the screen. No status changes.

[antennapod-bot]

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

https://forum.antennapod.org/t/local-folder-corner-case-unplayed-count-not-updated-for-new-file/2229/6

[antennapod-bot]

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

https://forum.antennapod.org/t/inbox-vs-unwanted-episodes-2-7-0-beta1/2294/2

[matejdro]

From what I understand, only problem with just keeping "played" status for everything is the statistics?

What if we decouple statistics from the played status? So statistics would only count for actual playback with internal player, not episodes manually marked as played. Then we can keep existing played functionality and there would be no need to complicate things further with multiple states.

[ByteHamster]

From what I understand, only problem with just keeping "played" status for everything is the statistics?

Not just statistics. You simply haven't played that episode, so marking as played fills the database with wrong information. For example, if you later search for a specific episode that you know you played, you would be flooded with episodes that you sorted out by marking them as played.

[antennapod-bot]

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

https://forum.antennapod.org/t/mark-all-subscriptions-as-played/609/12

[e-t-l]

Not just statistics. You simply haven't played that episode, so marking as played fills the database with wrong information. For example, if you later search for a specific episode that you know you played, you would be flooded with episodes that you sorted out by marking them as played.

This hits the nail on the head. Ignored (or hidden, or unfavorite, etc) is a necessary additional status to help keep podcasts organized. And just in case this wasn't in the plan, marking an episode as Ignored should also delete/unqueue it (this would be especially helpful in the context of #6463 #5246, where potentially unwanted episodes might be in the queue without having been downloaded first).

[keunes]

marking an episode as Ignored should also delete/unqueue it

That's a good idea. I've updated the original post.

[caoilte]

Hi,
Just wanted to offer a couple of thoughts on this topic from a new user perspective as it seems to be at the center of a very large web of discussion.

First of all this is the state of discussion as I've read it

"Ignored" Status PROS

• It makes accurate statistics more possible because you don't need to include "ignored" podcasts
• It makes it possible to search for episodes you've never listened to because they would be flagged differently to episodes that had been played.

"Ignored" Status CONS

• greater internal complexity to manage
  • opportunities for bugs because some code will need to search for feed items that are either played or ignored. some may not. whether or not the right decision was made will be open to interpretation.
• greater UX complexity for user to manage
  • The word "ignore" carries cognitive overhead and baggage that most users will struggle with (negative connotations for some people and requires new learned behaviours around its use-case specific meaning, eg it isn't inherently obvious that ignore implies do not download.)
  • more buttons, eg "mark as unplayed" and "mark as not ignored"

These pros/cons are well discussed but there are a few additional points I'd like to make,

• even with an ignored status, "played status" is not a good source of accurate data on listening statistics
  • it doesn't take into account partial completion of episodes
  • it doesn't take into account episodes that the user listened to multiple times
• Knowing from the search screen that you played an episode is a nice feature, but how would you incorporate knowing that you ignored an episode without UX overload?
  • if its greyed out (current natural behaviour) it looks the same as played so the user can't tell the difference. if you introduce a new colouring then the user has to learn it.
  • it might be useful as a search option (i don't think you have any currently - so this feels like a big change)
  • if you add it to the details page, why not add additional information like when it was marked ignored, when it was played or how much was listened to before skipping? (answer: because you can't put those things into a single enum int)

My experience is all BeyondPod 2016 (apologies for being a broken record on this). I've spent the last ten years,

• happily marking feed items as played even when i hadn't played them (it's a naturally intuitive step)
• marking entire feeds as played when i didn't want to listen to the archive (there's a button on each feed)
• never wanting to search for old episodes or interrogate whether i physically played them or caring how much i've listened to overall. (but i totally get how this could be a killer feature for other people.)

I suspect other major podcasters are consistent with this behaviour and that this is why most new users are confused by AntennaPod. I feel a great deal of sympathy for the people on this thread and in linked forums who have to spend a lot of time manually marking large numbers of items as played individually or even running SQL scripts in some cases. That's certainly one thing discouraging me from switching currently.

However, I think the decision to implement an ignored status as a high level state creates more problems than it solves. It's possible that there are other good reasons to implement it in this way that were discussed on the 2021/07/10 call and then not shared but generally speaking when a feature has multiple conflicting use-cases the best way forward is to decompose them.

For example, consider what happens when the problem of what is/isn't played is broken into two parts stored in two separate ways,

• episodes that have been listened to
• episodes that the user doesn't want to listen to

The former is useful for calculating statistics and storing it can be tailored to its use-case (eg multiple entries per episodes, partial play data and timestamps become easier to store and make use of). The latter might be triggered by being played or because the user marked an episode manually. How doesn't matter, the important thing is that it is a very simple flag to mark the episode as greyed out and not to download.

Also, from a user point of view there doesn't have to be any UX difference introduced to support the two different use-cases. The least confusing thing would be for a user to continue to click "Mark as Played" (current behaviour) but for that to be stored in the database differently to if the user had actually listened to it (either using a different status flag as currently planned, or in a different database entry via my decomposed feature suggestion).

You could even make the played/ignored available to look at if the user clicked through to detailed information (which would be useful to power users without cluttering the UX for casual users)

Finally, if there is a consensus to continue with the new functionality, you could consider calling it "archive" instead of "ignore". There is a learned behaviour here that many users are familiar with here from RSS readers / pocket. It's a feature I struggle with even in those contexts and must add a lot of complexity for their development teams but the user flow is at least fairly natural.

Apologies for that being far longer than I originally intended. I was looking for a feature to contribute code towards and this looked like it would unlock a lot of other things I care about. But although the database change would be simple, the cascading UX impacts make me uncomfortable. I'm still hoping there's a version of the feature that gives everyone the functionality they're looking for without new cognitive overhead and would be happy to help break such a feature down into smaller chunks and contribute.

[Matth7878]

Actually I wonder if all that is really needed is just a counter of number of times an episode has been played. Ignore status could be a negative value.
Then It would make it simpler to offer an option to change this number or filter based on it. (Instead of having to do something like ignored / not ignored)

Number of play could be next to release date and size so it won't clutter too much the UI and displayed this way :

• ignored (standing for -1)
• never played (0)
• in progress (0 and having a read position ; this one is maybe not useful)
• played (1)
• played x times (x)

As it could be redundant with greyed / not greyed only displaying something when value is different from 0 or 1 could suffice.

To filter or change value I would suggest to have a drop down list with ignored, unplayed, played once, played x times (For this one I see not other way than popping up an input box for a number)

[keunes]

I have some thoughts on your arguments @caoilte but may be best to discuss over a call. Would you be up for that? If yes, please don't hesitate to reach out to me via [my username] @mailbox.org.

What I'd already like to share: I like the suggestion for 'archive'.

[antennapod-bot]

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

https://forum.antennapod.org/t/monthly-community-call/1869/53

[antennapod-bot]

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

https://forum.antennapod.org/t/new-episode-action-enhancement/3871/1

[antennapod-bot]

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

https://forum.antennapod.org/t/option-to-hide-archive-episodes/4641/9