I appreciate the recap.
I’m also more confused now, because I thought we were talking about refreshing the InBox. I never refresh the queue and the only reason I can think of for doing that is if you’re syncing the queue between multiple devices. Is that what we’re talking about?
1 Like
Well, I mainly use the Downloads screen. No pull to refresh there. But refresh button away. So instead of tapping one on a button, it’s either two taps on a tiny three dots menu and select refresh or “back” gesture to switch to Queues and pull to refresh gesture.
I’d opt for making the top bar customizable!
My usage of search is only in podcast view to search for a specific episode.
1 Like
Yes, we should have made it clearer. It was a a change that was more impacting than I personally thought it would be (biased of course by my own use pattern). It’s on me that it’s not mentioned in the release notes. Based on the feedback, I did include it in the social media message.
At the same time neither is the holy grail: most users don’t read or even care to read them. What we don’t want either is – as some other apps do – put an in-your-face notice to all our users with release notes after they’ve updated their app. This blocks your flow (and would probably be equally dismissed without reading by many users).
I have more than 20 episodes in the queue and am pretty much always, like you, in the middle of it. I don’t have this issue, however (because I use auto-refresh). I suspect also that most users (non-power users) don’t care as much as you about getting the the latest episode as you open the app. (That need seems a bit odd to me btw, with so many episodes in your queue – do you really jump to the end of the queue to listen to the newly released episodes and then jump back to the middle?)
That would be ideal indeed. As you found, it’s Android making this difficult, unfortunately.
Nope, such metrics are not available, and thus this decision wasn’t based on such data. Privacy is a core value of the AntennaPod project, and user tracking (even if for a good purpose) doesn’t align with it.
We do have the beta program, community calls and this forum as venues for feedback (though of course it doesn’t provide the same info/data).
Why, though. (Same question/thoughts as above, about the use given the long queue and queue-based listening.)
I would say both are more or less equally ‘important’. But the big difference is that refresh should not be something that the user needs to bother with; it should be automated and in the background as much as possible. Hence efforts are made in that direction: Proposal: Smart Refresh Interval Search, on the other hand, can only be, is exclusively, an active user intent.
Not sure why you make a link between search and the queue length. Search is global, and it’s just accessible from many screens – the search button doesn’t only search the queue (in which case you would have a point).
Well, as said above: it’s not everyone. And let’s not make things bigger than they are: the 'more difficult ’ is just one extra tap – to open the overflow menu.
From where you refresh, it doesn’t matter. The same set of podcasts are refreshed, whether you trigger from Queue or Inbox. If you trigger it on a specific podcast’s screen, only that podcast gets refreshed.
There is no link with synchronisation.
I think that’s our oversight. Thanks for bringing it up. I’ll create an entry on the issue tracker, so that this can be implemented.
Minor relief, probably, but the size of the dots doesn’t matter. As per Google’s standards, all buttons have the same touch area (meaning you don’t have to be super careful to tap exactly in the middle of the dots).
That would of course be possible but would come at a high cost of maintainability – making it harder to get bugfixes and improvements out (and there are plenty of things with higher priority). Every user choice we add also has a cost of cognitive load, which we need to consider. Here’s a good blog about this point: Tech Notes: Why not add an option for that?
So I don’t think a customisable top bar will land in AntennaPod any time soon.
3 Likes
Hello everyone,
It looks like we’re all learning something in this conversation, which is a good outcome in any case 
Agreed. I usually don’t read release notes for app updates.
It’s a different matter for dependencies I update as a developer in projects I’m working on. But as an app user, I usually don’t check the details - only on my iPad where I can see the first 2 lines of the release notes on the update screen, I sometimes have a quick look at the changes.
Honestly, I don’t know if my podcast app usage habits are odd or common. I also don’t particularly care how other people use podcast apps in general (I probably would, if I would develop a podcast listening app though). And until now, I thought I don’t need to know how other people are using the app - this is the first time I’m engaging in any way with AntennaPod beyond just installing the app and occasionally getting annoyed by a small change here or there, but usually I would probably forget about the change within a few days and just get over it.
I’ve been listening to podcasts since about 2007 when I got an iPod nano. Maybe that explains my more manual approach to managing my queue and refreshing my podcasts even almost 20 years later 
Back then you had to download podcasts and transfer them to the device using a cable. It was slow and annoying. But, maybe surprisingly, quite a few podcasts I still listen to today, I actually started to listen to back then.
Yes, I do really jump up and down in my queue. This might have to do with the mix of podcasts I have subscribed, which will be useful when getting to the significance of updating at certain times. I would group my subscriptions into a few categories:
- technology podcasts, updated once a week, or once a month, or whenever they record a new episode
- other special interest podcasts, updated maybe once a month, maybe less
- talk and interview podcasts, updated once a day or once a week mostly
- current affairs commentary/entertainment podcasts (if that’s your kind of entertainment…), updated once a day, maybe twice a da, or once a week, or twice a week, once a month
- news podcasts, updated once an hour, or 3-4 times a day
I’ve set up AntennaPod to append newly downloaded episodes at the end of my queue.
I actually never use the “Inbox” and just a few days ago saw the setting to customise the drawer items and now only have “Queue”, “Subscriptions”, “Downloads”, “Playback history”, “Add podcast” and then the list of subscriptions below.
And the only item I actually use regularly is “Queue”. I rarely need any of the others at all. That’s why my AntennaPod opens “Queue” as default screen, a very useful setting for me! 
The “Inbox” isn’t useful for me, because I don’t listen to all episodes of all podcasts. for many podcasts, I actually listen to all episodes, but sometimes I might listen to the episodes months or years after I’ve downloaded them. So the “Inbox” is just too noisy and not really useful for me.
So why do I jump up and down? Again, we all probably listen to podcasts at different times in different situations, I almost exclusively listen to podcasts when I’m out and about, on my commute, walking to the gym, on my way to a gig or anywhere else. When I’m moving out of my home, I’m most of the time listening to some podcast.
I’ve just done a quick count:
- I currently regularly download and listen to about 47 different podcast feeds.
- Every now and then (maybe once a month, maybe once a year, depending on my mood and time), I listen to another about 10 podcasts.
Since I recently discovered that you can hide podcasts from the list in the drawer (another great feature! ), I’ve skipped all the discontinued ones or the ones I don’t need quick access to. I would estimate that I might have another 10 in my subscriptions which I either lost interest in, are no longer updated or I don’t want to delete completely for whatever other reason I might be able to come up with if asked why I keep a specific podcast in my subscriptions. It also doesn’t matter, really. 
The 5 broad podcast categories technology, other special interests, talk and interview, current affairs commentary & news age very differently. There are only about 5-10 podcasts from the current affairs commentary & news categories where refresh times matter. But especially for news podcast subscriptions, I don’t want to listen to the episode from 05:00 when there’s already the 07:00 one out by the time I leave the house. Also, at certain times, the news are more detailed, so if I have the choice between a short episode from 06:00 and 09:00, or a longer one from 08:00, I’d want to pick the longer 08:00 most of the time. And if I don’t want to refresh >50 podcasts every half hour just to get the get the latest list of episodes for 3-4 podcasts automatically via the “periodic auto refresh”, I simply use the “refresh” button before I leave for my commute, for example. If I do that once or twice a day, it doesn’t bother me too much that it refreshes all >50 and I only need 3-4. But I wouldn’t want this overhead every 30 minutes, it would also drain my battery and create completely unnecessary network traffic and use up everyone’s resources for no good reason.
Then I can go to the 3-4 podcasts with many new time-sensitive episodes per day and pick the ones I actually want to listen to on my commute.
Sometimes, less frequently, I also refresh podcasts individually. For example, when I just refreshed but now that in 5 minutes a new one should be released for one of the podcasts. Then I don’t want to refresh everything again, maybe because I actually want to leave soon and don’t want to wait for all to get updated (it doesn’t take too long, but when you want to catch a tube or train or bus, you sometimes want to get out quickly without having to wait another 1-2 minutes).
Of course, before this change, I just used the refresh button on the podcast view (I’m not 100% sure, but I think it was available in those views as well).
Ok, so now I have a few podcasts at the end of my queue. But I have also a half-listened podcast that I was listening to last time I used the app. So I manually reorder the episodes in my queue a little bit, move some of the new ones up, that age quickly, and move some of the other ones in my list down, because I now find they are less relevant to me right now. So that’s why I’m jumping around. Often I’m actually around the same position, but then there are times when I have less time to listen to podcasts, so more episodes accumulate somewhere in the queue and at some point I decide to shift my “active listening window” further down to get closer again to the newer episodes, but keeping the older, less time-sensitive ones for later.
You can probably tell that I never used the search! I assumed it would search the current list, not just everything.
Yes, but it breaks a UI/UX that was working perfectly for no immediate benefit I can think of - besides “less clutter” maybe (or “cognitive load”), but has anyone had an issue with this? Did any user not manage to do what they wanted easily because there was another button next to the search button? Are people really so confused by seeing two or three buttons?
Now, I fundamentally disagree here and think this line of reasoning is misguided. Sometimes a user (me) actively wants to refresh. The user (me) is bothered by not being able to do that easily.
Now I think, this is at the core of the problem. You’re making assumptions about your users based on your own usage patterns and routines, without knowing how users actually interact with the app.
As developer, it’s easy to think that of course everyone uses the app exactly as intended. But users wouldn’t be users if they wouldn’t use an app in different and creative ways that were never imagined (I have to deal with some such users myself ;).
In this case, it’s not even too surprising that many (?) users regularly used a button that was readily available for many years. Somebody placed the button there some time ago for a reason. And I believe that reason is still valid today. Removing it makes the app more difficult to use, from my perspective that change doesn’t reduce “cognitive load”, it just makes my life harder than it needs to be.
Judging from this thread and the Github bug reports, I’m not the only one who prefers having a “refresh” button over having the same functionality buried in a submenu.
That’s sad, as this would be the obvious solution and would be in line with so many of the other excellent customisation options AntennaPod already offers.
If the button isn’t coming back, maybe I should look into installing the app directly myself, then I could just revert that change or make it customisable and install my own version without going through the store. Yes, it would be a pain to set it up once and I wouldn’t benefit from new features (if I wouldn’t maintain a fork, which I probably wouldn’t), but maybe I also wouldn’t need them. I mainly need the features I actually use.
3 Likes
You make some good, well thought-out points in your latest post, but I also think you make this same assumption as to how many users overall may use the app the way you use it. My use case is entirely different than yours, although we both have the Queue as our default screen.
2 Likes
For me, I rarely have a long queue. I believe 15/20 episodes would be max for me.
What I do is only adding episodes I know for sure I will listen and then order manually my queue.
If there is a lot of episodes I want to listen but it would make my queue too long I leave them in my inbox. So inbox is were I would check new episodes and immediately choose what to do : remove, download and add to queue, keep for later.
For podcasts I want to catch up on old episodes, depending on how is my queue, I would just go to podcast list and add episodes to queue. Same for episodes I removed from inbox because I wasn’t interested right now but still could be used later if there is nothing else.
So swipe down to trigger refresh works well for me.
About refresh turning on notification for my favorite podcasts helped me to change how I looked at new episodes. Before each evening I set to check for new episodes but as it’s no longer possible I know rely on notification to decide when to look at inbox.
The only difference is know I set it to check 2 times a day (each 12 hours) when before it was only once. I want to avoid starting a new episode when one more interesting come out.
But more on topic, I agree that if for each 3 dots menu there was a customize function to allow choosing which buttons to use (respecting for each screen how many have been decided to display).
After all why let users choose home sections orders and not that. Doesn’t seems different for me.
2 Likes
That suggests to me that the way to use AP efficiently in your use case is to have a Tag / Super-Category for those podcasts which are time critical then flick to that Tag view and do a pull to refresh as and when convenient and deemed necessary. Then flick back to the Queue view which as it happens remembers where you where in the queue.
This sounds to me like a case where it easier for the user to adapt their way of working to how the app works than to expect the app to be changed to work the way the user was previously used to. After all if you get a new car and find the turn indicator stalk is on the other side of the steering wheel you would not expect the manufacturer to modify the car back to the way you were used to.
1 Like
Thank you for the idea. I started using tags just recently, mainly to reduce the number of podcasts in the drawer, I can easily ignore the list of tags below the subscriptions that are most relevant to me. But I have no idea what you mean when you write “flick to that Tag view”. Maybe it could be a solution, maybe not. When I go e.g. to “Subscriptions”, scroll all the way down to my tags, and tap on a tag - is that the “Tag” view you refer to? Sorry, that’s already lots of scrolling and tapping just to get there. It was a single tap before.
That’s not an argument, that’s a distraction. I haven’t bought a new car. I’m trying to continue using an app that I’ve been using since 2017 without much trouble. Until now.
It’s more like that while driving, suddenly the indicator stalk jumps to the other side without warning. I doubt many drivers would accept such a random behaviour in their car, it would also seriously affect road safety for everyone around them.
I’ve found the commit that made that change (in the GitHub repo commit 34fb2050b257d81438374bd39d4625be4b580325 - forum doesn’t allow a link) and am still considering forking and compiling a version just for myself. Or maybe I change to another app altogether if I can’t be bothered to create my own version.
I’m very surprised how such a decision is being made - based on the comments made above - without consulting actual users or collecting any metrics about what features are being used. I still haven’t heard an argument why the new UI is better and what the new UI enables, that the old one didn’t Nobody in this thread said they ever used the search feature, for example.
If there are more changes like this in the pipeline, AntennaPod might soon become completely unusable for me.
On the specific issue, I do agree that having to switch screens, scroll to the top or tap twice can be an inconvenience, albeit a minor one.
However, I still find it somewhat amusing that people are more annoyed by having to pull to refresh than by having a refresh indicator in the middle of the content for extended periods of time (which still seems a lot more disruptive to me).
Re-reading how this decision came to be, my main lessons learnt are:
-
If part of the UI is removed to make space for other features, then those features should be present in the same release. Removing something without an apparent rationale will just annoy people much more.
-
Watch out for maintainer burnout: some contributors can be extremely annoying/argumentative in pushing their ideas without seeing the bigger picture (just to be clear - I’m not talking about anyone in this thread). Don’t be afraid to push back in those situations. They can always fork if they disagree.
-
Do use the alpha/beta testing phase to discuss the feedback received, and extend the phase if needed. I had actually provided some feedback on this and related behaviour changes and would have been available to discuss the topic in more detail.
2 Likes
My contribution to the thread has been to point out not that it’s better or enables anything new (at least yet) but that sometimes changes are going to affect SOMEONE regardless, good or bad.
I respect that for your use case this change to refresh functionality appears to be a major issue for you.
It’s interesting to me that you have been using the app for almost 7 years and this is the first actual complaint you have voiced on the forums (based on the fact you joined just a few days ago) and that’s a complaint that may cause you to fork the app. I understand it’s a major change for you, but you are just one user.
I know when we are considering changes to an app certain UX issues have to hit a threshold and affect X or X% of users in a negative way before we decide not to implement them.
3 Likes
I do read the release notes, but I concur with @keunes earlier observation that adding release notes to the app flow isn’t useful.
This explains why your experience is foreign to so many of us. I now believe your app is configured to automatically download all episodes of the large number of podcasts that you are subscribed to. I can imagine how that would create a mess in the queue, calling for much scrolling and/or searching. Hopefully the tag option suggested by @gomezz will make that more manageable.
I found the refresh butting very useful. I have set timed refresh but also regularly used the refresh button before leaving the house. I regularly have more than one screen’s-worth of podcasts in the queue and pulling the list scrolls the list. Pull down on the top banner doesn’t refresh - it does nothing. The change is intended to only work when pulling down on the list but pulling down on the list is an action that is already used for another function - scrolling the list.
I happily used AntennaPod for many years and I only joined the forum when I was frustrated enough by this change to want to find out why it was done and whether the old function can somehow be recreated.
1 Like
Might go comment here if you agree with the idea. It might help in the future for stuff like this (I don’t really have a vested interest in this particular change as my use case for AP isn’t affected by it)…
That is correct. Pull down on the page, not the top banner. If you have a long queue and work from the end of that queue you may find it easier to pull down on the home page.
I was also a frequent user of the refresh button. I also signed up to this forum just now to comment about this frustrating change after I don’t know how many years of using AntennaPod happily. I will still use AntennaPod regardless of the eventual fate of the button, but I want to add my voice to the small choir of those asking for it back.
Thank you for a great product!
1 Like
That’s exactly my take on the “issue”. Best app. Long time user, will continue regardless…
Thank you guys. And also many big thanks that you answer so quickly and frequently in this forum!
It seems everything was said. I miss the refresh button, too, especially because I virtually never use the filter and favorite buttons that are always visible (although now that I think of it, I should… :- ) and there is a lot of free space om my screens. But I also see that some devices lack screen canvas and development has to go on. I am curious which new buttons will come up and I will try out automatic refresh without automatic download.
Keep on with the good work!
2 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.