First and foremost, thank you for spending time on this issue. Much appreciated. I am one of the commenters on the github issue linked above by Keunes and I had offered to make a donation for this feature to be implemented.
I wanted to share my user story because it differs in focus somewhat from what the title of that issue might suggest and I am sure many would-be-users share my thoughts.
My own personal use case is that I stream nearly all of my podcasts and I am rarely out of reception. It is nice to be able to download episodes when I know that I will not have connectivity, but this is a very distant second to my main scenario that this simply streaming. I have next to no need to keep any episodes at all on my device.
The core of what I really want is a UX issue, and this is the experience I want:
I want to be able to browse to my chosen series, sort the series from old to new (or the other way around), and hit play on the episode I choose. No more clicks/taps than that.
Then when the episode is finished, I want the player to automatically play the next episode (considerate of my sort) without any more interaction from me, and to continue doing so until I tell it to stop, or content in the series is exhausted.
Ideal default download behaviour for me would be for antennapod to silently cache the current episode plus ~3 episodes ahead and silently delete the episodes from cache once they are listened to. I do not want to involve myself with queues or downloads or playlists at all 99% of the time. All of these things obviously should exist but they should (in my opinion) be in the background to the core experience, and a new user should not even have to know of their existence to listen to the podcasts they want. This is the experience delivered by spotify and apple music and others and is simply the mental model of a media app that users now have, rightly or wrongly. We can help new users by meeting these expectations
Currently a new user to AntennaPod must educate themselves about queues and downloads and even after they do, they might not get the behaviour they expect, which could be a barrier to uptake.
I understand that my own use case does not match everyone’s use case, but I think it is a now common one. This use case might not be common to the current user base, but I think it is worth considering that the reason for this is that any new users with my use case would have left the app when it did not meet their needs.
Finally I want to say that I hope this does not sound like a huge whinge. It is hard to describe a problem you perceive without sounding like you are complaining and being very negative. I am so grateful that people like you put the time in to make open source apps like this. Antennapod is very powerful and has lots of great features that clearly serve its user base well. I hope that my story can make it even better.
Leaving it until @ByteHamster and @keunes are in agreement is the way to get major changes done. I am also a contributor to AntennaPod and I find being collaborative is the best way to get changes in. Being agressive is NOT going to work well.
Contributors come and go, but the @ByteHamster and @keunes are here to support the users and product longer term.
Contribution to code is just as important as UX (UX is even more important most of the time)
As a podcast user who largely listens while out on the road I am not so fortunate to have rock solid streaming connectivity and in some areas the reception is patchy or non-existent and I think that this is also the case for many users for whom download functionality is very important and should be front and centre in podcast app design.
A second factor is that many users have limited data available to them - yes even these days. Personally I have only comparatively recently moved to a package which allows a comfortable amount of mobile data but force of habit means that I still prefer to download content while at home if possible. Presumably people want AP to be available and usable wherever in the world they are and whatever their circumstances?
A third factor is that sometimes older episodes of some podcasts are purged from the feed. If you do not have them downloaded then you no longer have access to them.
Thanks Gomez, I think our use cases can both be catered to with a good design. I do not intend the implementation of my design to remove any functionality, or to replace the queue/playlists which 100% need to be retained and improved, I am just aiming to reduce friction for as many users as possible and make the app easy to use for beginners and others who are used to other apps but would prefer something open source.
I’m not being aggressive. I’m am a contributor that is just more ACTIVE than other contributors. And I have never said that I don’t want collaboration.
But as a contributor (voluntarily i should add), I am entitled to voice my opinion on project matters.
@gomezz I agree, but it seems that the moderators feel like it is a second rate feature and want to take they’re time to get it implemented (most of the current issues were brought up years ago).
I’m offering to help the implement it, but they are slow to respond and seem to want to get the UI/UX perfect before even beginning.
Hi @dunc0, thanks for joining the AP forum and being an active participant.
I’m glad you share the my enthusiasm and urgency to improve AP that I feel is lacking in the rest of community as of late.
I appreciate an respect any user that takes the time to suggest ways of improving an app. And so regardless if the idea is any good I do try to accomadate their suggestions as much as possible. Which I can’t always as not all are good.
Luckly, your suggestion is one of the good ones.
I also am nearly a pure streamer. I hardly use the queue or downloads. And one my own personal complaints against AP is their lack of continus playback from the playlist of a feed. It is only supported in the queue.
As much as I would like to help you with your concers, I don’t think it will get into AP any time soon. I’ve been working on other features and they have been very slow in their responses, which they seem to have a history of.
Therefore, I have been considering forking this project and going my own way. I wish it didn’t have to come to this but, my enthusiam to make AP better and help give users the voice they deserve has grown to much.
I’m not sure what to name it. Do you have any suggestions?
Yes, I agree that download management is still important. That is why I volunteered to help get this feature shipped. But the maintainers have been slow at responding.
That is why I have decided to fork AP. If this fork is successful, then I can help accommodate and improve the download feature and have it shipped within a reasonable deadline.
Any name suggestions?
@peakvalleytech instead of forking is there a way to do something like an experimental branch where it would be possible to let you manage it ?
So it could include edge features and available to advanced users. Then based on it big features could be polished before being merged to main branch?
@ByteHamster what do you think, is it possible if it would satisfy @peakvalleytech ? Or it is better that a forked version exists ?
I’m sorry for not being more active reviewing recently. I have quite a few things going on in real-life currently, that’s why I have limited time working on AntennaPod. Even though I still spend about 8 hours a week on AntennaPod, it should probably be more (maybe 10-15 like it was a few months ago). The largest problem probably is that I am the only one reviewing PRs. If there would be more developers leaving comments about the code structure, I would have more time to think about new features.
I’m reviewing one of your PRs at a time, starting with the oldest one. You are working on quite a few “large” issues (at the same time), so it takes a while to review. Over the past years, I have invested quite a lot of time to untangle spaghetti code, which is why I am rather picky with large PRs and their code structure.
I would prefer to not discuss forks on the official forum. This just leads to confusion when users cannot be sure what features are available in what app.
Having branches to polish features is already the workflow we use. The branches are on peakvalleytech’s repo, though, because giving access to individual branches is not supported by GitHub.
With two apps, a lot of the “external” tasks (managing a forum, social media, releases, translations, website etc) is twice the amount of work (in total). I would encourage you to keep working on AntennaPod instead of forking. We all have the same goal - making the podcast experience better for users - and working together instead of alone will help to achieve that.
My main problem is the speed of development. I respect that the maintainers devote as much time as they want to. But it is just not satisfactory to me. I do not want to have to be tied to someone else’s schedule. At the same time, I agree that the goal is to improve AP. With this solution, I can develop on my own terms while still helping to improve AP (on the maintainers terms).
Maybe there is a misunderstanding here due to different understandings of the term fork and the consequences of creating one? A classical understanding of the word might contain elements of burning all bridges and stopping co-operation with the forked project. This is obviously not what was suggested, given point two immediately following the suggestion.
Given the following quote, it seems to me that a fork is suggested for the purpose of aiding the discussion with reviewable code. A possibly younger interpretation of fork from the GitHub era, where forking is simply the uncoordinated approach allowing to throwing stuff on the wall to see if it sticks.
Please compare this with the following suggestion:
I believe there is common ground to be found here. My understanding is that @Matth78 is actually suggesting something with closer integration to the project than the unsanctioned clone that @peakvalleytech could already create at any time. Both sides seems to believe the conversation has gone on enough to require more concrete input in order to progress, but there is a difference of culture and approach? Would reviewable and discardable prototype code be welcome?
I cannot argue with that. However, I believe in the younger interpretation as a grew up with Github era.
Therefore, I don’t see how the compromise I proposed is not viable.
No, you’ve just quoted me out of context. I have no plans to merge whatever i’ve written for my fork into AP. If you would like to use the code from my fork, do so at your own peril. Alternatively, like I said, I can continue to contribute to AP, and can help implement similar code that as been agreed upon by the community. I’m am all happy to continue to improve AP.
However, abiding by open-source protocol, I still have the right to fork maintain my own fork.
No need to reread. You in fact made such a claim. Clear as day.
FYI illegal is a synonym of unsanctioned. I would never have mentioned it if you were to have omit the word. Calling a fork unsanctioned does not help at all.
No worries. I’m not too keen to discuss matters not related to the original topic anyways. So if you don’t have anything to say about the auto download feature than please don’t posts here.
