Mark episode(s) as NEW + filter on NEW episodes

Feature request
1

App version: 2.4.2 (F-Droid)

A problem users are having, or feature which would improve AntennaPod:

After having read through this forum, it is obvious that the functionality with new-flags is not as inituitive and visible as it ideally should be.

Every now and then there is a post such as: mark-all-subscriptions-as-played, a comment such as multi-select-played or an education attempt explaining that marking unplayed as played is not how AP is intended to be used. (There are more posts touching upon the subject, but these are fairly illustrative.)

These posts suggests that many people, me included (quite a while ago), do not immediately realize that the NEW state exist at all. Instead skipped episodes are reluctantly marked as played, as a workaround to avoid unintentionally queuing them.

No one should ever need to feel compelled to tell lies. Not even to an inanimate objects. Please consider making it easier to keep different states for what was listened to and what was skipped.

Suggested solution:

The way I see it, things would greatly improve if these three things were added to AntennaPod:

  • Make it possible to manually mark episodes as NEW (including mark all).

While only the newest episode are relevant for some categories of podcasts, it is also very common with feeds where one wants to listen to more. Possibly to every episode from the start. Even if not intending to hear every episode, one might want to explicitly make those decisions. (I realize this change interfere with the episode auto-download feature, which I would assume is disabled by many users? Maybe what is presented as NEW to the user should e.g. actually be represented by two states in the database?)

  • Make the episode lists filterable on the NEW Flag.

This is the feature I personally lack the most. If only that one got implemented, I would be happy not having to see uninteresting episodes once removing the flag. One relevant quote the forum here could be: It would actually solve this issue if it had a filter to show/hide episodes with the “New” flag.

  • Increase the visibility of the NEW state.

As I mentioned in a previous post, it would be helpful if the NEW items visually stood out better. The goal is to make users realize there is the third state new, not just played and not played. Making the background of new episodes yellow, or possibly AntennaPod blue foreground instead, might work in the light theme?

Screenshots / Drawings / Technical details:

Can be added if required. I believe the suggested changes are clear enough to be possible to take into consideration?

Would you agree there is an issue, and/or that the suggestions above could improve the user experience?

2 Likes
2

This is indeed an issue. We’ve discussed a solution also in the past, one that largely overlaps with what you’re suggesting here. It just wasn’t implemented yet: Introduce new screen/sytem: ‘Inbox’

1 Like
3

Interesting. I believe to recognize some of this conversation from the forum, but do not think I ever saw the related MSGH issues before.

Swiping, and the exact presentation format of the inbox, are fairly independent of how to handle episode states. With that said, I do not have many opinions on them. I do however wish for changes in state handling which would appear as improvements for every reasonable usage scenario.

Currently each episode has one out of three states which is technically stored in the field read in the FeedItems table of the database. This state can take the values: unplayed 0, played 1 and new -1.

It seems like the inbox post and #5267 suggests adding a fourth queued/will-possibly-listen and fifth ignored state there, alternatively another boolean field to model essentially the same thing. It is not clear to me what value these suggested new states would add, or how more complex state transitions would make app easier to use.

Reading through #5237 gives me the impression that not everyone are completely sold on the idea of an ignored state (regardless of name), and my opinion is that it seems to be a request to add unneeded complexity which could better be solved by improving how the states are presented and manipulated.

Wouldn’t my three suggestions be (the main part of) a much simpler solution, providing the exact same value to users? Three states is all that is needed to represent fresh, will-possibly-listen and wont-listen. Is there really a use case where it would be meaningfully interesting to separate will-possibly-listen into shall-listen and undecided as suggested? Isn’t such separation exactly what the actual queue is used for? What is the desired goal with adding an ignored state in the more complex way suggested?

One would of course need to redesign the auto-download feature, but that is a fact for all changes related to state handling.

4

My view is that Played / Unplayed and New / Not New are two different attributes and should be filtered as such. This is based on my use case of having a number of podcasts with a large backlog of unplayed episodes which I do not want listed as New.

5

What does that mean? You’re in agreement with the second point: Make the episode lists filterable on the NEW Flag?

New, Unplayed and Played are, as described in my previous post, technically different values of the same property. It would be interesting to learn how you think about them, in order to understand what it is that you value that I have not realized.

Why do you not wish episodes to be listed as New? Because of how AntennaPod currently download all those episodes when having automatic episode download enabled, or because it doesn’t fit some kind of mental model?

Personally, I currently have about 25k episodes marked as New, about 5k Played and 13k Unplayed. If more states were added, all the Unplayed would go to Ignored and everything else would stay the same. I find this to be all one might possibly need, so please help me understand the pros of an additional state. Is it perhaps more useful to explicitly differentiate between new and undecided episodes when only subscribing to a handful of feeds?

6

It seems I think of New as recently dropped not as recently subscribed to / downloaded. It sounds like you think of it as something different. You can have New / Played and New / Unplayed and Old / Played and Old / Unplayed. New and Played are two distinct attributes and it is logically wrong to have them as state values of the same attribute.

7

For me :

  • new : recent episodes I didn’t decided on what to do
  • unplayed : episode either in queue when I want to listen or not if I don’t want to play them (because I am not interested at all or not much and then maybe if I am short of episodes I would eventually listen to them)
  • played : no explanation needed I think!

So what is missing is a way to tell apart episode unplayed which eventually someday I want to play or those I would never listen to.
Right now there is no solution for episodes you want to never listen to : either they stay unplayed and appears in subscriptions unread counter or you mark them played but is not really true and If either I change my mind they will be hided inside played. So I tend to let them unplayed.

3 Likes
8

@gomezz Are you saying that you wish these properties were fully decoupled, or that you believe that they currently are? Could you please explain how to make an episode New and Played at the same time? I’m fairly sure that is currently impossible as that would mean read would simultaneously need to be both -1 and 1.

@Matth78 It seems the only difference between your and my use is that you seem to have your subscription counter set to unplayed rather than new episodes. Would adding a new and queued setting for the subscription counter, in combination with my three other suggestions, perhaps work just as well as adding a separate ignored state for you? When adding old unheard material to the queue, given that filters and views make it easier to find desired information, does it really make a difference to know whether an episode was previously rejected explicitly or just undecidedly skipped?

I definitely see the need to be able to ignore episodes. What I’m saying is that I believe the cleanest implementation would use the three states currently existing, and improve on how they are used rather than complicating everything by adding unnecessary states. Please remember that it is already possible to favorite episodes. Would adding silver favorites, and :poop: or :-1: “favorites” in addition to the currently existing gold stars be an alternative to an ignore state?

Further on somewhere in the distant future, I’ve gotten the impression that multiple playlists could possibly become a thing. Wouldn’t that both be complicated by a convoluted state model, and the real solution to some problems around how to treat undecided episodes?

9

IMHO ignore is really a state on his own.
I live without it with no problem but for managing episodes I clearly see it’s needed and don’t see how it could be accomplished using existing states.

For me what it boils down is what you visually see and can filter when looking at the screen of episodes for a specific podcast.
What is usefull is to be able to distinguish episode not played and not new so you can add them to the queue when you’re short on episodes to listen.
If no such episodes exists then is there ignored episodes you would play because there is really nothing else or because you spoke to someone who changed your mind about ignoring an episode.

Favorites is something entirely different which IMHO allow you to keep episodes from being deleted and / or allow you to quickly get to them.

1 Like
10

@cos I am saying that logically these two properties are decoupled. If and when AP becomes my main podcatcher I will find a way to use it that fits in with that as best I can.

@Matth78 I have no problem with using mark as played as a way of ignoring episodes that I do not intend to listen to. That is for newly dropped episodes. For the backlog episodes I have no problem in leaving them as unplayed until and when they pop up as the next old one to listen to and at that point either play them or mark them as played. If someone or something prompts me to revisit any episode whether already played or marked as played I can always find it again.

11

As you can see in the GitHub ticket (which summaries the forum + hackathon conclusions) only 1 extra state is introduced: ignored. New is kept and used for the inbox (or perhaps renamed accordingly).

Your proposal is pretty much the same as the one in the GitHub ticket: fresh=new(=undecided), will-possibly-listen=unplayed, wont-listen=ignored. This list is only missing the ‘played’ status. States could of course be renamed (e.g. as per your suggestions) to better reflect what they mean.

That’s not how it currently works but I fully understand your expectation. This was one of the reasons to propose to get rid of the ‘New’ label.

No. And this is in line with the current proposal: when played the episode status changes to played, regardless its previous state (meaning you indeed loose the info that you mention is not important).

No, because it would be rather complex to have (new or custom user-created) ‘favourite’ values have an affect on/integrate with automatic download processes (1 extra state is much simpler).

We have seen that many users don’t mind and actually do this. I used to do it in the beginning, too. But it invalidates the statistics :slight_smile:

12

Can’t say I find the listening statistics of any more than casual, passing interest.

13

Another forum post seems to request making it easier to mark episodes as played.

14

I realize to have failed getting my point across. To simplify, lets drop the third of my suggestions for now and focus on the other two. They would be of value to have, regardless of whether an ignored state is added or not, right?

So essentially you don’t have any strong opinions on my suggested changes to functionality. Got it! Noted!

Would not adding filterability on new deliver exactly the distinguishability you’re after? After applying a filter of not new + not played + not queued, all episodes remaining are those which previously never got queued. Thus the ignored ones, if I understand you’re usage correctly. I’m suggesting adding improved usability with the states currently existing.

Regardless of whether adding one, two or ninethy five new states. Wouldn’t it be worth making it possible to filter on new and explicitly marking episodes as new? Are there any arguments against this, or is it mainly that no one has yet presented a patch?

My suggestion is to add filterability on new and the possibility to mark episodes as new. My claim is that it could mostly fill the same need as adding an ignored state, but realize that some people might wish to differentiate between unseen and undecided. Fixing the handling of new does not conflict with adding additional states, but it makes it possible for users to differentiate between played and ignored with less complexity (although requiring some discipline).

You’re right! They are different. Getting too deep into them might not be interesting enough now.

Adding an additional state does not come without added complexity, but I will not push for additional ‘favorite’ types. The point with this thread was to suggest making the currently existing state new more useful.

15

My afterthought after answering :

I wonder if what make this things hard for everybody to agree is because what people do with new episodes.
If your new episodes are your waiting list to listen then I can understand there is no need for ignored. (I think @cos is how you see it)
But if you consider your new episodes as a list to review and clean for what has just been released then an ignore state is needed because after reviewing your new episodes list is empty. (This is how I see it)

So “Not new + Not Played + Not queued” would amount to unplayed not new and not queued.
=> As far as I understand for episodes left you still won’t be able to tell apart the one you would probably never listen to (and want to ignore) to those no longer new and not queued but you put aside to listen for whenever.
=> What is needed is not to filter ignored episodes but to filter out those episodes so there is only episodes played or not but you would want to listen to.

Deciding to put aside an episode to whenever is not and edge case IMHO and it would be good if AntennaPod was able to make it easy. Reasons to put episodes aside for later :

  • you are not much interested in episode (for instance a topic you are not too keen on)
  • you have already too much podcast in your queue and you don’t mind skipping an episode
    => in both case you would probably listen those episode in future if you find yourself short to anything to listen to. (In fact you would probably have listened them if you had not much else when they had been released)

Worst case scenario with no ignored state is for podcasts releasing a lot of “episodes” which in fact are excerpts from real episodes. At least in France there is a lot of radio releasing their show as a podcast and doing this kind of thing.
=> getting back to the real episode you didn’t listen to is annoying, you would need to add additional filter like duration for instance. Yet if you could have marked excerpt episodes as episodes to ignore and it would be much simpler.

At last initially I marked episodes I wanted to ignore as played. I stopped to do so because it makes it impossible if you want to check if you truly listened to an episode and… it screws statistics :wink: :rofl:

2 Likes
16

Thank you @Matth78 for going this deep in trying to understand me. It seems you’re getting close to it.

I consider the Inbox list to be the waiting list of episodes to decide on whether to listen to or not. The actual queue is my waiting list for episodes to listen to. At the same time I also consider the Inbox list to be a list to review and clear. I’m well aware that I’ll never ever clear it globally, but I do keep it clear for feeds in some folders and work towards clearing the list for other folders. That is, I use different folders for feeds fully tracked, feeds to be cherry-picked, feeds to be caught up on from their starts, feeds to possibly consider in the future and finalized feeds.

You are making a strong point for having some kind of way to ignore episodes. What I’m opposed to is making ignore a too central part of the work normal flow.

As of currently, I would describe the state transitions as in the following picture:

antennapod_current
antennapod_current745×648 74.6 KB

On Feed Addition the user currently has no control to place episodes new to the listener as new to AntennaPod. One single episode pass through F2I into the Inbox, all else forcefully goes through F2N to Not played. I realize increased ability for placing episodes in the Inbox would also require fixing automatic download of episodes, but reworking that is another ongoing other thread. I, who do not use automatic episode downloads, have manually placed new episodes into the Inbox ever since folders were introduced through modifying the database with some SQL. That has been fully successful and an improvement for my usage, even considering the hassle of manually exporting and re-importing the database whenever adding a feed.

What I’m suggesting is making it possible to manage the Inbox so that most people would be able to get a simplified state diagram such as this:

antennapod_manage_inbox
antennapod_manage_inbox696×648 32.8 KB

Generally people would know when adding a feed whether they intend to listen from the start or skip all old episodes only caring about newly released once. Please consider e.g. RTHK’s eating smoke or CBC’s a death in cryptoland. Those two are short series, who everyone adding them would want to hear from first episode to last. No new episodes will ever be released for either of them. (They are also essentially timeless and I would recommend them.)

My attempt to illustrate how I understand what is suggested in GitHub with adding a Skipped (or Ignored, renamed to keep initial letters unique) state is as follows:

antennapod_ignored_state
antennapod_ignored_state973×648 86.6 KB

It becomes a hell of a lot more complex, with all those state transitions for normal use. The more I think of it, the more I’d consider Skipped to be handled and implemented more like Favorites. That is, as an external flag.

What’s missing in the sketches above? I could make the source svg file available if someone is interested in adapting them with details.

2 Likes
17

While being at it with pictures. Here’s my illustration of adding Skipped as a separate attribute, rather than encoding it within the read field.

antennapod_hide_attribute

This is supposed to indicate that any episode could be hidden without affecting state, just as any episode can independently be marked as a favorite.

Hey, I would even be tempted to suggest that a skipped episode could be forever lost from the user interface. But I leave it to those more interested in it to have opinions on whether to have Skipped as a filterable property, make them gone until resetting hidden episodes per podcast or whatever seems appropriate.

18

@cos Your “simplified” diagram seems to be missing a transition between Queued and Unplayed. For me I would want that to be there and to be a two way transition. I often add something from my backlog (Unplayed) to the current playlist (Queued) to pad out the total playing time for a listening session then sometimes move it back again if there turns out to be less time than anticipated.

19

@gomezz Thank you for pointing out the purpose of my diagrams was unclear. The idea is not to present every possible action, but to illustrate the normal state transition of episodes. Starting when they first enter the flow, until they reach their final state. Individual operations to transiently regress episodes backwards should of course be possible to do, but such deviations are not what the diagram is intended to capture.

As for an Errata, Skipped should have been depicted using a significantly smaller pile.

20

Hello.
I haven’t been following this, but recently decided to see what all the fuss was about.

Here is my ten cents.

@cos, I appreciate your desire to improve AP, but your solution seems to just be a rehashing of the same problem as using ‘played’. Neither new or played actually distinguishes the users real intent. By implementing this, instead of using played, were just switching over to new.

Marking episodes as new doesn’t really make sense.

  1. It is supposed to be used to identify recently published episodes (which interests some users)
  2. Autodownload depends on new state to download episodes. Having too many new episodes will
    cause auto-download to behave incorrectly.

It takes a lot of effort and testing to realize a feature. The last thing one wants to do is add a workaround that sort of does what needs to be done. If we are going to solve your problem we should do it the right way.

I agree with @Matth78, ignore would solve your problem and Matth78s. It is a valid use case. I’m surprised more apps don’t have it.

Regarding the inbox. I don’t think it is necessary. It just adds extra complexity. However, I haven’t read much on it. I might change my mind later. For now, i don’t like it.

1 Like