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?