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

Feature request
21

Great! Improving AP is why we are here. We could not be in more agreement on avoiding workarounds!

Of course! Please remember that no one has demanded or required you to do anything. What I have done is initiated a thread with a proposal for how to redesign episode states. In order to reach an agreement on a user experience and interface that makes better sense, as it is welcomed in the contributing guidelines on the project’s web page.

My intention is that we solve this problem, not my problem. As you can see in the opening post, it refer to several users having these issues. If I was in this purely to scratch my own back, you would possibly already have seen a PR for #445 which personally annoys me more.

This thread has been started because the current handling of NEW is the biggest usability problem AntennaPod currently has. Please reread the opening post with references, to see my motivation for that fact. (Admittedly, it also bites me.)

Why would you so say? That is the springing point. We know that users misunderstand the functionality, or completely fail to realize its existence. Yet no explanation or motivation for the current behavior has been given, other than that it’s currently implemented that way.

AntennaPod is a wonderful piece of software, and you current contributors can be rightly proud over making it what it is. What I’m suggesting here is bringing the app towards perfection.

Yes, of course. That was mentioned in my opening post, and me understanding that has been repeatedly stated in the thread.

Really? That statement rings clearly false to me, and makes me think I’m still not being clear enough.

Did you have a look at the state transition schemas posted?

It is obvious that discussing this purely using text is unsufficiently clear. That’s why I attempted to illustrate the state transitions with pictures.

Please feel free to adapt state_transitions.svg which I made available to clarify how to better model user’s intent for the primarily supported listening flows.

Or do we not agree that there even are a couple of problems which could be solved?

I’ll quote you out of context here, just to say that I very much agree to those principles.


I’ve intentionally tried to focus on a overviewable set of changes, scoping conversation for the clearly required modifications to episode auto-download to a not-yet-started thread. But I’ll briefly comment below.

Every FeedItem has a pubDate. Wouldn’t that be a more appropriate field to use to determine what is new? But please let us get back to those details at a later point?

Again, I consider ability to ignore to be mostly a separate functionality. Solving it as a state of read is one possible solution, but it really is unrelated to handling of NEW.

An importantant ending point is there is a difference between having a legitimate need to explicitly ignore episodes, and being confused about what to do because how NEW currently works.

1 Like
22

So before we go into debating this issue, let try to get on the same page.

What is your reason for wanting to mark episodes as new? You want to be able to control the inbox, right, which you use as a ‘waiting list’?

If this assumption is right, then you support the use of an Inbox.

I’ve read through the thread regarding the Inbox. It seems the main usecase is to allow users to quickly be able to access new episodes from all subscriptions. And @Matth78 pointed out that it seems like a revamped All Episodes screen. I think he is absolutely right. I am in favor of NOT using the Inbox. Instead, we should just improve the Episodes screen.

@keunes pointed out various problems which necessitated the reason for creating a new Inbox screen. I think those problems can be solved be simply changing the Episodes screen. It is a much better solution, in my opinion, for the following reasons.

  1. It is simpler as it uses an existing screen. Why not focus on improving what is already there? It does not make sense to keep adding to a subpar UI. By enhancing All Episodes screen, we avoid needing to have a another screen, which will please @ByteHamster.

  2. It is a better mental model. I think we have to remain focused on the user. @ByteHamster as mentioned before that we should not change the UI too much as that will anger and confuse many existing users. Current users are already familiar with an All Episodes screen, not just from using AP, but also from other apps like Podcast Addict. An Inbox screen is completely unique to AP and it isn’t necessary. Most users barely understand the Queue let alone by placing another mechanism on top of it. We have to remember that the average user is a casual listener and will not need or care to understand how to use an Inbox. The same benefits can be obtained by modifying the Episodes screen. In this way, we can accommodate both the average user and the power user.

Can you not achieve your same workflow with an All Episode screen that allows you to

  1. Filter episodes by New
  2. Mark episodes as Read/Ignored
23

Yes. But pubDate varies. Remember, the main usecase for New is to filter recently published. What is new is different for each feed. In order to keep track of what is new, we need to mark them with New. This occurs when the feed is updated after the initial download.

Well, why would you think that, as they are just different ways of filtering episodes?

24

The possibility to filter on NEW is half of what the thread is about! It is one of the two suggested changes and part of the thread subject. Does this mean we agree that filtering on NEW is desired?

Can I assume you’ve read the thread? Quoting myself:

So no, I do not have opinions on the Inbox, it’s design or even it’s existence. We’re not really talking frontend level design here, are we? But rather about the underlying conceptual models of what usage flows should be expected, possible, supported and endorsed. When having a sound structure, tweaking presentation tends to be possible.

As when it comes to my personal use, I’ve mentioned having 25k new episodes. I’m surprised you believe either the Inbox or All Episodes could be of any use for anyone with a heavy backlog. I always add to my queue from the lists of each individual podcast. Anything else is completely unmanageable.

Possibly so. However directly exposing that technical detail as a concept the user rightfully has another perception of is the mistake, and essentially what this thread is intending to address. Timely enough, the support request Download all back episodes was just posted yesterday.

I did not wish to unnecessarily confuse the conversation with implementation details at this point, but see at least a couple of reasonable ways to decouple the app-internal new state from what is presented to the user.

Fixing the handling of existing states is a fully independent activity from that of adding additional states. Right? If explaining it with graph theory; A fixed set of nodes can have edges added, remove or modified without necessarily needing to add any new nodes.

Although including a partial redesign and being a major change, modifying handling of new would essentially be a bug fix. It would make AntennaPod behave as users already expect it.

Adding a completely new state is a feature addition. It would make it possible to do something previously not possible with AntennaPod.

Are you seeing the difference yet?

I posted diagrams where every state, and all transitions between them, are named. My expectation was that doing so would open up for more initiated and specific questions and comments referring to those names.

What are your comments on those diagrams? Do you consider the three pictures to be representing their models, or would you prefer to illustrate the episodes’ cycle-of-life in some other way?

As currently implemented, the lack of F2I cripples the flow and prevents users to meaningfully use the Inbox (New) state for all episodes (minus one) posted prior to when subscribed.

To make it more clear; What’s crippled is that AntennaPod has a different perspective of new episodes than the listener’s perspective of new. An alternative would be; When adding a new feed, it should possible mark all episodes in the entire backlog as new. AntennaPod’s assumption that all podcasts are of the current-affairs or contemporary-extroverted-blabber kinds (when in fact the most listen-worthy content always age well) is the basis of the bug. However, making it possible to manually mark episodes as new is likely the pragmatic implementation.

Could we please, please, please defer this conversation to a separate thread in order to be able to focus on one distinct change set at a time? Do you really consider that conflating those details is necessary at this exact moment?

1 Like
25

The idea of “new” (to be renamed to “inbox”) is that you have never interacted with those episodes yet. As soon as you start changing their state, they can no longer be “new” - so marking something as “new” doesn’t really work.

If you want to mark all as “new” because you are interested in the entire backlog, you can just add all the episodes to the queue. If this is about auto-download, then we should change the auto-download feature, not work around it by manually changing the “new” state.

4 Likes
26

Welcome to the thread @ByteHamster!

Yes, exactly!

You seem to be making the assumption that New/Inbox can always be cleared in every sitting, when in fact new episodes might occasionally be coming in at a far too great pace for that.

Please compare this with how email is used. Some people tend to reset messages’ statuses to unread, until having had a chance to act on each one. Coretex has even had lengthy discussions about how being able to peek without changing read status is a deciding factor for some people when selecting email client. I believe manageability of the New/Inbox state should be considered a user expectation. So far I have not really seen any motivation to why that can not be made possible. I am fully aware it is currently not being implemented that way, and that any decision to allow a change will require (duh!) actually making changes.

That is not practical for at least a couple of reasons. Some podcasts are to be cherry-picked, lets get back to those. Even for the simple case where the entire backlog is interesting; adding hundreds of episodes to the queue creates the bigger problem of constantly needing to reorder the queue. Months or years might be required to clear the backlog of one single feed, and practically there is probably more than one such source to slowly progress through, all while trying to stay on top of other feeds listened to in real-time as new episodes are released.

Regarding cherry-picking. Please consider e.g. BBC’s desert island discs which has 2k5 episodes available to podcast, from eight decades of broadcasting. Few people would listen to all of those, but still it is the type of material which people find relevant to listen to selected parts of. Proof: podcasting wasn’t a thing in 1942, but BBC has bothered to make all these available. Is the recommendation for anyone wishing to sift through that treasure trove to add five years to the queue at a time? Do you truly find that to correspond to what makes AntennaPod more attractive than BBC Sounds? We have similar programs with timeless material from other public service broadcasters, and people do have interest in listening through such old material. Wouldn’t it be desirable if AntennaPod made that experience as pleasant as possible?

If putting the user experience first, rather than being fixed at never allow changes to the current functionality, would it then not make sense to allow adding to Inbox/New? If not, I would really wish to understand the rationale behind why that suggestion does not seem to at all be considerable.

27

I stick with my view that just because there is a backlog of old, unplayed episodes that it does not make sense to call them new. Unplayed, yes. New, no.

3 Likes
28

Let’s make an “on hold” status to those episodes you want to decide on later!
Sorry I am kidding, couldn’t help myself. :sweat_smile:

More seriously for me the process relating to episodes is :

  • checking new episodes in new list when podcasts feeds have been updated / refreshed
  • deciding what to do : removing new or adding to queue (and downloading) ; action missing : marking episode as ignored to remove it from queue
  • later on if no many episodes left or if I wish to listen to a particular podcast : going to subscriptions and checking what is still available to listen

When adding a new podcast personnaly I don’t except to have any episodes in new list (even though right now you got the last published one). It makes perfect sense to me that of I want to listen to old episodes I have to go to this podcast subscription and choose which episode(s) I want to add to queue.
If it is a podcast I know I want to listen to all episodes from old to new, I will always remove new episodes from new when they got published and add old episodes manually as soon as my queue get a little low in number.

That’s it. I don’t know if my workflow is representative but surely there must be a lot of users doing the same as I don’t do anything particular.

About inbox it, as far as I remember what have been discussed about it, it is not supposed to be a rehash of new episodes but a way to get you back to old episodes or proposed you something new to keep you workflow going on with less effort.
I believe it is aiming to be a kind of inbox / homepage.

1 Like
29

Agreed. Which is why I proposed to change it to Inbox, (and possibly recycle the ‘New’ indication later on for recent episodes, regardless the Inbox).

30

To be honest it feels like we went in circles a bit (this topic has been discussed before and a solution was decided upon before). And these massive threads are making it difficult to follow (I know, I like to contribute to them too :sweat_smile: – I believe the only point under discussion really is whether one should be able to add episodes back to the inbox). So I would say we (can) discuss it again during the community call to see if the previously decided solution does not cover a use-case, and come up with a solution to it, then update the GH issue accordingly.

Would that work for everyoneone?

2 Likes
31

So before we go into debating this issue, let try to get on the same page.

What is your reason for wanting to mark episodes as new? You want to be able to control the inbox, right, which you use as a ‘waiting list’?

If this assumption is right, then you support the use of an Inbox.

I’ve read through the thread regarding the Inbox. It seems the main usecase is to allow users to quickly be able to access new episodes from all subscriptions. And @Matth78 pointed out that it seems like a a revamped All Epsisodes screen. I think he is absolutely right. I am in favor of NOT using the Inbox. Instead, we should just improve the Episodes screen.

@keunes pointed out various problems which neccessitated the reason for creating a new Inbox screen. I think those problems can be solved be simply chaning the Episodes screen. It is a much better solution, in my opinion, for the following reasons.

  1. It is simpler as it uses an existing screen. Why not focus on improving what is already there? It does not make sense to keep adding to a subpar UI.
  2. It is a better mental model. I think we have to remain focused on the average user.

Yes, I agree completely that filtering on New would be useful.

Ok, I apologize. I missed the detail about New being renamed to Inbox.

I agree that we need to have a good conceptual model that aligns with a users conceptual model. As stated before, the New state is currently used to indentify recently publsiehd episodes. Most apps that use a new like state also use it similarly. To use an analogy, one would not go to a blog and declare that old posts are new to them just because they started reading that blog. A new posts would be any post that is published from the date the user started reading it. I don’t think breaking this model by allowing it to be mutable is a good idea.

I believe this is where @Matth78 idea of an Ignore state is useful. The reason you want to mark episode as new is because you want to add into to the New Episodes list, right, as sort of a waiting list.
You then go though the list, in your spare time, and remove the New state from episodes you aren’t interested in, right? Well, can’t this work flow be substituted by using Unplated and Ignore state.

Then this would allow the All Episodes screen to function as a an automatic waitlist. I say automatic since you don’t even have to manually ‘mark’ anything. All episodes automatically go through this waiting list. This would avoid having to rework the automatic download feature as the New state is left alone.

Well, that is assuming that your assumption of users’ expectations is actually true. I am afraid there isn’t really much data to support your claim. So, for now, I wouldn’t really consider it a bug. Maybe if you can provide some data then I would reconsider.

I prefer to add a feature along with the extra effort if it avoids modifying and potentially breaking an existing feature. If it ain’t broke, don’t fix it.

32

Those diagrams represent the models in discussion very well. Nice work.

LIke I said, I don’t agree that a markable New state will work or whether that is desired by the majority of users.

I’m not saying you’re workflow is not a valid usecase. In fact, it is similar to my own usecase and how I use the app. I believe you have the wrong approach. I’ve considered this problem and feel that using ingnore state would solve my own workflow.

Below is a modified version of your diagram.

antennapod_manage_inbox_modified
antennapod_manage_inbox_modified696×648 92.2 KB

Maybe this will illustrate my view more clearly. If you could compromise with this solution. Then your workflow as well as mine can still be implemented. In addition, we can implement the new Ignore/Viewed state. Everyone will be satisfied. Will this work for you?

1 Like
33

On @peakvalleytech modification I would just rename some terms :

  • unplayed → not decided on (aka new / recent)
  • and for viewed / ignored in truth it’s the unplayed episodes so I feel it would better to name it : on hold (for future listening) / ignored

Edit : I am not against having an inbox / home instead or on top of all episodes. It might be a good idea to offer a bette workflow and to ease app discovery for new user (for instance inbox / home can offer to link you to add podcast when you are a new user)

1 Like
34

@Matth78
I don’t think we should just throw name changes so casually. We should try to introduce as little change as possible espcially when UI is invovled. Users enjoy familiary.

Changing to much to soon, will alienate and possibly even anger some users, especially power users that whose probably a hardcore workflow they follow. In short, we should try to keep the same workflow as possible.

I think my suggested workflow, which is a good compromise between what has been already been discussed, achieves exactly that. All that needs to be changed is to modify the Episodes screen to use only the All Episodes tab, add swipe actions, filter for new, and a new ignore state.

I’ve made my case pretty clear. So does anybody have a cogent argument on why this is not the best solution?

I won’t accept anything less than a complete decisive counter. Do not give me your perspective or your suggestions because you have a certain personal workflow.

35

I proposed to discuss the issue, not debate it :wink: The discussion is also intended to get on the same page.

1 Like
36

I’m commenting briefly and on a high level here now, respecting what @keunes suggested.

We are clearly flying all over the abstraction layers, and thus misunderstand each other because we are discussing completely different things. I see points in what many of you are saying. Minor ones are difference in opinion, but I honestly still think we disagree less on the major issue than it appears. I have just not managed to express myself clearly enough in this forum yet.

Having read the forum I know you @peakvalleytech are not a fan of video conferences and having to adapt to other peoples schedules. I can definitely understand and highly respect that. I’ve had working-remotely as a show stopping requirement for payed work since before the pandemic hit! Still I’m stating once, and just once, that I would much enjoy to see you on our Community Call #1, and believe that occasionally doing such things could be of benefit.

37

I was hoping for something more constructive. But yes i guess it is wrong choice of words.

38

I’m sorry, but what abstraction layers are we talking about? I assumed we were all discussing it at a high level business oriented layer (the conceptual model). In fact, you were the one who mentioned lower-level details.

Well, yes, that is why I modified your diagram so that we could get on the same page. However, you declined to offer your opinon (Thanks @keunes :slight_smile:).

So what do you think? Do you think the modified diagram can achieve the same workflow as the former?

Yes, i’m not a fan of video conferences. That is the great thing about being a volunteer contributor. I can decline to attend meetings.

I believe that forums are superior to video conferences. If we cannot resolve it through detailed written communication where we can elaborate our thoughts, what makes you think we can get it resolved in a 1hr video conference with everyone talking?

So, no, i’m going to decline.

Note: I partly attended the previous community call. If I remember correctly, we had 3-4 topics that were to be resolved. I think the only one that got implemented was swipe actions.

39

Sorry, is this meant to be a snark? Or how should I interpret this?

40

Can we try to keep the posts relevant to the thread?