# Changed refresh

**URL:** https://forum.antennapod.org/t/changed-refresh/4325
**Category:** Support
**Created:** [March 29, 2024, 8:59pm UTC](https://forum.antennapod.org/t/changed-refresh/4325 "2024-03-29T20:59:02Z")
**Posts on this page:** 1
**Showing post:** 24

<div class="post-metadata">

### Author: ![keunes](https://forum.antennapod.org/user_avatar/forum.antennapod.org/keunes/32/61_2.png) [@keunes](https://forum.antennapod.org/u/keunes)
#### Post date: [April 5, 2024, 9:29pm UTC](https://forum.antennapod.org/t/changed-refresh/4325/24 "2024-04-05T21:29:44Z")

</div>

> [@goetz](#):
>
> **this change has been reported twice as a bug on GitHub** by users who also couldn’t understand it

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

> [@goetz](#):
>
> Beyond my particular usage pattern, anyone with more than say 20 podcasts in the queue probably will have a similar issue.

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

> [@goetz](#):
>
> If I could **set 3-4 times per day to auto-refresh, instead of or in addition to an hourly interval** , maybe I could fully automate it (e.g. for me this would be around 07:30 in the morning, maybe 12:30 in the afternoon and around 17:30 in the evening on most days)

That would be ideal indeed. As you found, it’s Android making this difficult, unfortunately.

> [@goetz](#):
>
> I’m wondering whether there has been any user research or user analytics to look into how often the “search” and “refresh” buttons have been tapped by the user base before this change? Are there any metrics available to guide such a UX decision?

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

> [@goetz](#):
>
> Personally, I’ve used the “refresh” button 2-3 times a day,

😯 Why, though. (Same question/thoughts as above, about the use given the long queue and queue-based listening.)

> [@goetz](#):
>
> the “search” button appears more important than the “refresh” button

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](https://forum.antennapod.org/t/proposal-smart-refresh-interval/2848) Search, on the other hand, can only be, is exclusively, an _active_ user intent.

> [@goetz](#):
>
> if you have a “Queue” list long enough to make the “search” feature useful

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

> [@goetz](#):
>
> everyone with a list over e.g. 20 podcasts is slower now than before, because refreshing is more difficult now than it was.

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.

> [@Listener](#):
>
> I’m also _more_ confused now, because I thought we were talking about refreshing the InBox

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.

> [@MCBuhl](#):
>
> I mainly use the Downloads screen. No pull to refresh there.

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.

> [@MCBuhl](#):
>
> tiny three dots menu

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

> [@MCBuhl](#):
>
> I’d opt for making the top bar customizable!

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?](http://neugierig.org/software/blog/2018/07/options.html)

So I don’t think a customisable top bar will land in AntennaPod any time soon.

---

_[View the full topic](https://forum.antennapod.org/t/changed-refresh/4325)._