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

[cos]

Welcome to the thread @ByteHamster!

@ByteHamster

The idea of “new” (to be renamed to “inbox”) is that you have never interacted with those episodes yet.

Yes, exactly!

@ByteHamster

As soon as you start changing their state, they can no longer be “new” - so marking something as “new” doesn’t really work.

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.

@ByteHamster

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.

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.

[gomezz]

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.

[Matth78]

@cos

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.

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

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.

[keunes]

@gomezz

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.

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).

[keunes]

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 – 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?

[peakvalleytech]

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.

@cos

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?

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

@cos

So no, I do not have opinions on the Inbox, it’s design or even it’s existence.

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

@cos

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.

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.

@cos

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.

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.

[peakvalleytech]

@cos

What are your comments on those diagrams?

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.

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?

[Matth78]

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)

[peakvalleytech]

@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.

[keunes]

@peakvalleytech

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

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

[cos]

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.

[peakvalleytech]

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

[peakvalleytech]

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.

@cos

I honestly still think we disagree less on the major issue than it appears.

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 ).

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.

[keunes]

@peakvalleytech

However, you declined to offer your opinon (Thanks @keunes ).

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

[peakvalleytech]

@keunes

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

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

[bruno]

Hello, I am new here, so let me know If I am at the wrong place, or saying the wrong things.
It looks to me that there may be different needs based on different people, and the question is how to provide for most.
My personnal need is that I have my favorite podcast which contains both parts and the whole episode. My present podcast reader let me filter automatically on the length so it is easy to drop the whole episode to only keep the parts. To me that functionnality is vital for a proper use.
So I guess, there would be considered as ignored in what you describe.
But I have another podcast where I do not read all, in that case the Inbox/New would be welcomed to decide what I want to put in the queue.

[bruno]

Hello, Sorry, I found the filter on lenght… so I guess I can switch fully to AntennaPod now…
Still a bit difficult to clean the podcast when starting anew… It is getting things back up to 2015!!

[bruno]

Again I was wrong, only the initial one was old… So forget what I said!
Sorry about the bother

[cos]

@bruno

Hello, I am new here, so let me know If I am at the wrong place, or saying the wrong things.

Welcome to the forum!

Generally I’d say you’ll probably get better replies if starting a new topic. This thread has been marked as solved and should probably be considered to be closed.

[ByteHamster]

I just wanted to notify you that I finally wrapped up the inbox feature. You can find more details and a test build here:

Inbox: Looking for testers

At the hackathon last year, we decided to revamp the “new” screen. After @ueen’s contribution was open for nearly a year and my stab at it for half a year, I think we can give it another go now. Are you interested in testing the inbox? You can find a test build HERE. It installs alongside your existing AntennaPod app, so you can install it without changing your existing installation. What is the inbox? The inbox is basically the same as the “episodes»new” screen. Episodes that are newly relea…