IMHO if some kind of priority is needed it would be best to have a specific settings for each podcasts. I would suggest a numeric number to offer enough granularity, either 1 to 10 or to accommodate heavy users 1 to 100.
If not set it should be considered as mean between lowest and highest number so that would make it no specific priority. (If same number then subscription order could be used)
Subscriptions order impact display and do not reflect what you consider important. For instance mine is set to alphabetical because I find it more practical.
I would strongly advise to use that.
Ok, that is what I thought you were refering to. Yes, I hope to include a setting to âSort by priroityâ. I alos thought you were refering to a new drag and drop feature i have partially implemented (Github).
I would like to have the priroity be implemented with drag and drop versus a number via podcast specfici setting. I think it is better UX instead of twiddling with numbers. What do you think?
Right, and feed specific setting should solve this problem. But prioritizing downloads could still be useful.
I appreciate your suggestion, but I really donât think that is the best approach.
There is no way for users to easily compare the priorities of the current podcasts.
With a drag and drop, users can see immediately the relative priorities. And can quickly order the priorities through drag and drop rather than have to individually enter numbers for each podcast. Besides, I have already implemented drag and drop capabilities for the subscriptions screen (#5386, Feed drag drop by peakvalleytech ¡ Pull Request #5386 ¡ AntennaPod/AntennaPod (github.com).
Also once, feed specific auto download is implemented, then extra granulairty wonât be needed as theyâre wonât be a fight over which podcasts get to download.
Instead, it provide these two main benefits:
âit would be nice if these podcast could be download first, so i donât have to waitâ
it would provide a way to allow custom sorting, which many user have requested
Yes, that could be true. But âsort by priorityâ would only be an additional option. So users can have the option to change to whatever they prefer.
I really feel like we have the cart before the horse tho.
First step is de junking all the current download stuff, and just getting a working model that downloads and recovers or at least rejects the half finished downloadsâŚ
I havenât checked but it seems to me that most apps (not podcast) use the download app in android so that would be something Android would have already built and you just need to hit the api.
Then you can work on additional features to downloads. It will be a lot easier to test if we donât have 30 settings that can interfere.
Auto-download and download are completely different things. One part decides when to start a download. The other part handles the downloads, whether they are started by clicking or the auto-download feature. Both features can be developed independently.
I agree on this one Itâs a difficult thing to fix, and probably not suitable for a single forum thread. @peakvalleytech@ByteHamster (and anyone else interested), would you be fine with participating in a couple of âworkshopsâ (using our Jitsi instance)? The hackathon meeting earlier this year worked really well in hashing out some agreed next steps.
Wile @peakvalleytech seems to have done the analysis of all the issues listed in the relevant milestone, I havenât done that and I donât have a clear overview of all the user needs yet. I think itâd be very helpful to write out the different use-cases and take that as a starting point. Rather than starting with a solution, and then adding different opinions and considerations to the conversation.
By meeting a couple of times, we can follow a more structured approach:
identify different user needs:
describe the different user stories in the milestone issues
list the accompanying acceptance criteria
optionally, ask users (e.g. those that created & commented on the GH issues) for feedback
identify possible solutions:
draw up a âmatrixâ of elements/decisions to make (e.g. global vs local maxima; coupling vs decoupling auto-download & removal)
reflect on (list) other user requests and considerations (e.g. prioritisation)
define one or more solutions, by identifying one or more sets of mechanisms & features
write up (in slightly more detail than above) how each solution would work for the user
pick the solution (or combination of mechanisms/features) that we think will work best
write out & review the proposed implementation
write out for each user story how itâll work (what the user will do & experience), given the chosen solution, and if necessary, consider adapting the solution
prepare mock-ups & explainers
put the proposal with mock-ups for feedback to interested users
I realise this is a more work and will take a longer period of time. But Iâm convinced this will help us end up with a solution thatâs much more durable.
If you agree, Iâd be happy with trying to draft the user stories, based on all the milestone issues.
@keunes Sorry, iâll have to decline. As far as I know, iâm the sole developer that is going to be implementing the design, and I have alreayd done the required analysis and proposed my solution. And, for the most part, I am going to stick to that design.
Please remember that i work on this on my free time as a volunteer. I realize the importance of getting the design right, but I also realize that i am not getting compensated financially. I donât want this to feel like another job I have to take on, which it is starting to feel like.
So please critique my solution and offer suggestions, but please donât force me to do one I donât feel like doing, regardless if it is the best design or not.
Donât take it offensively, I just know I have thought long and hard about the issues and feel that my solution is fairly optimal. I really donât feel like going through more analysis. If you guys (excluding me) still want to meet, you can do so. Iâll be happy to hear your thoughts on the design.
Iâm super happy you offered to work on this. The thing is: AntennaPod is a collaborative project and right now I donât have a clue of all the analysis that you have done. If there were some communication earlier on we couldâve given some some input on the analysis. E.g. on the priority/weight of some of the feature requests/comments from others that you took as input for your conclusion.
If Iâm to spend time on carefully considering the usability aspect (which is how I can and like to contribute to the project) but you already know that you donât want to change approach based on it, then what can I contribute to the project here⌠I understand you donât want it to feel like a proper job, this is just to explain my feelings with this. Next time itâd be cool if you take us along on the journey
Yes, and so not all of us want it to be so structured. It really decentivzies me, as well as other potenential contributers, if we feel it is just another paid coding job, where we need to attend mettings and go through detailed designs. Designing is one thing, but implementing is another thing. And beggers canât be choosers. I will be glad to hear your suggestions on how to tweak my solution, but I am sticking to my proposal. Please meet at your own discreation and disccuss how to âimproveâ on my solution. Do not offer other solutions that are significantly different. If you do, you can find another developer willing to implement it. I apoligize if this comes off as angry or offensive. I just feel I have to voice my opinon.
Yes, it is collaborative, and excuse my bias, but I believe implementing requires a bit more effort and time. Do you agree? Well, then as a key implementer (if not the sole implementer) I feel my proposal and suggestions should be weighted a bit more. I am not against hearing others suggestions, but please remember that, as it currently stands, iâm the one going to be implementing this feature(s). Just saying.
Hmm, I agree that the person who implements something can definitely shape how the feature works. We do however need to consider large reworks like this critically. Just because the implementer is happy with something, it doesnât mean the users will be (and thatâs what AntennaPod is all about, in the end). Finding out what users like is a difficult process and not as fun as just starting to code (at least for me and you seem to feel the same). I still think that it is a necessary step to do.
@ByteHamster Well, like I said, i will be happy to hear your suggestions, but as the implementer, I would like to keep the design as close as possible to the original. And, like I said, iâve done my analysis and this is the closest thing we have at a complete solution. I wonât be attending the meeting, but please share what you want changed in my proposal and iâll consider it.
I disagree I guess just like people requesting features always tell developers âit is easy to implementâ, developers (in general) often seem think that way of UX design & studies. If done properly, interaction design & usability checks might should take as much effort and time as code implementation.
Youâre right. A bit painful to see black on white, though (Edit: thatâs because it reminds me I donât have the skills, even though Iâd like to be able to write code and implement some changes Iâd love to see.)
Anyway, thatâs beside the point. One concern that I have is how your proposal deals with the enormous issue Download oldest episodes first, specifically the differentiation between ânew-to-old (letâs call them the newsy feeds) or old-to-new (letâs call them the sequential feeds)â.
Iâm still up for a more structured (& documented) process. @ByteHamster, are you still interested?
I had made a note GH, but I agree the biggest frustration with how auto-download works is that existing episodes when you add a subscription wonât download automatically. They are not considered new.
This means any sequential podcast auto-download is completely broken. A book review, a show discussion will either start auto-downloading in the middle of the series or will not auto-download.
It seems like all the discussion and this suggested fix is to just decide when ânewâ episodes get downloaded, not fixing the issue of âoldâ episodes?
Thanks for bringing it up and pushing back so that all this hard work doesnât go into a solution that doesnât fully solve the problems.
Youâre entitled to your opinion, as we all are. I apologize if I came off as inconsiderate. I agree that UX/UI are important. That is why I wrote this proposal suggesting my solution. And this wasnât just done in one day. I did my own analysis (since nobody seemed to be really active on this milestone) and thought hard about how best to implement keeping in mind UX/UI. So as the one implementing, I would appreciate if we can keep my solution intake. Iâm open to considering and even adopting your suggestions as long as it is better than my existing solution. In short, what iâm really getting at is that I took the liberty to come up with a proposal so you guys donât have to. I will try to get you guys on board next time, but this time we going to have to use what Iâve already done. Sorry guys. Take it or leave it. This milestone is way overdue. I wanted to have the first iteration done by the end of last month, but that never happened. We canât afford to take another month just to do more design.
Iâve already considered that. We can include a setting to change the order of the âDownload N latestâ.
And âDownload N latestâ will download the latest âunplayedâ episodes, either including old episodes or from newest to older, or oldest to newest, depending on the setting.
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)
Itâs a difficult thing to fix, and probably not suitable for a single forum thread. 
