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.