I don't keep a "dick bar" that sticks to the top of the page to remind you which site you're on. Your browser is already doing that for you.
A variation of this is my worst offender, the flapping bar. Not only it takes space, it flaps every time I adjust my overscroll by pulling back, and it covers the text I was trying to adjust. The hysteresis to hide it back is usually too big and that makes you potentially overscroll again.
Special place in hell for those who hide the flap on scroll-up but show it again when the scroll inertia ends, without even pulling back.
Can’t say here what I think about people who do the above, but you can imagine.
Another common problem with overlayed top bars is that when following fragment links within a page, the browser scrolls the page such that the target anchor is at the top of the window, which then means it’s hidden by the top bar. For example, when jumping to a subsection, the subsection title (and the first lines of the following paragraph text) will often be obscured by the top bar.
Funnily enough for years I would say the general consensus on HN was that it was a thoughtful alternative to having to scroll back to the top, esp back when it was a relatively new gimmick on mobile.
I remember arguing about it on HN back when I was in uni.
It can actually be done correctly, like e.g. safari does it in the top-urlbar mode.
- When a user scrolls content-up in any way, the header collapses immediately (or you may just hide it).
- When a user scrolls content-down by pulling, without "a kick", then it stays collapsed.
- When a user "kick"-scrolls content-down, i.e. scrolls carelessly, in a way that a when finger lifts, scroll still has inertia -- then it gets shown again. Maybe with a short activation distance or inertia level to prevent ghost kicks.
As a result, adjusting text by pulling (including repeatedly) won't flap anything, and if a user kick-scrolls, then they can access the header, if it has any function to it. It sort of separates content-down scroll into two different gestures, which you just learn and use appropriately.
But instead most sites implement the most clinical behavior as described in the comment above. If a site does that, it should be immediately revoked a dns record and its owner put on probation, at the legislative level.
Most mobile browsers lack a "home" key equivalent (or bury it in a not-always-visible on-screen soft-keyboard). That's among the very few arguments in favour of a "Top" navigation affordance.
I still hate such things, especially when using a desktop browser.
On iOS, tapping on the top ”status” area will bring you to the top under any browser. It’s an iOS-wide functionality on any vertically scrolling view. I sometimes miss that on Android, but on the other hand the scroll acceleration is so much faster on Android that you can always scroll to the top quickly.
I think some, if not most, mobile browsers - even apps - used to implement it via a space near the top of the window/screen. That seems to have gone away, though.
In Firefox you can disable this behavior under Settings -> Customize -> Gestures. If your browser does not have an equivalent setting, get a better browser.
I do have Firefox (Fennic Fox F-Droid) installed on that tablet. The reading experience is so vastly inferior despite numerous capabilities of Firefox (most especially browser extensions) that it's not even funny. Mostly because scrolling on e-ink is a disaster.[1]
Chrome/Chromium of course is an absolute disaster.
EinkBro has incorporated ad-blocking, JS toggle, and cookie rejection, which meet most of my basic extension needs. The fact that it offers a paginated navigation (touch regions to scroll by a full screen) works far better with e-ink display characteristics.
I'll note that on desktop I also usually scroll by screen, though that's usually by tapping the spacebar.
--------------------------------
Notes:
1. The thought does occur that Firefox/Android might benefit by an extension (or set of same) which address e-ink display characteristics. Off the top of my head those would be:
- Paginated navigation. The ability to readily scroll by a full page, rather than touch-and-drag scrolling.
- High-contrast / greyscale optimisation. Tweaking page colours such that reading on e-ink is optimised. Generally that would be pure black/white for foreground/background, and a limited greyscale pallette for other elements. Halftone dithering of photographic images would also be generally preferable.
- An ability to absolutely freeze any animations and/or video unless specifically selected.
- Perhaps: an ability to automatically render pages in reader mode, with the above settings enabled.
- Other odds'n'sods, such as rejecting any autoplay (video, audio), though existing Firefox extensions probably address that.
I suspect that much of that is reasonably doable.
There is an "E-ink Viewable" extension which seems to detect and correct for dark-mode themes (exceedingly unreadable on tablets, somewhat ironically), though it omits other capabilities: <https://addons.mozilla.org/en-US/firefox/addon/e-ink-viewabl...>.
Max Lumi, which is now a couple of cycles old. It's the 13.3" tablet.
Looks as if its current rev is the Note Max, Android 13, and a resolution of 300 dpi (the Max Lumi is 220 dpi, which is already damned good). That's pretty much laser-printer resolution (most are effectively ~300 -- 600 dpi). I wish they'd up the onboard storage (Note Max remains at 128 GB, same as the previous device, mine is 64 GB which is uncomfortably tight).
The Android rev is still a couple of versions old (current is 16, released December 2024), though I find that relatively unimportant. I've mostly de-googled my device, install few apps, and most of those through F-Droid, Aurora Store where that doesn't suffice.
If the Max is too spendy / large for you, the smaller devices are more reasonably priced. I went big display as I read quite a few scanned articles and the size/resolution matter. A 10" or 8" display is good for general reading / fiction, especially for e-book native formats (e.g., ePub). If you read scans, larger is IMO better.
I'm aware and not happy with the GPL situation, but alternatives really don't move me.
Onyx's own bookreader software is actually pretty good and sufficient for my purposes, though you can install any third-party reader through your Android app repo you prefer.
My main uses are e-book reading (duh!), podcasts (it's quite good at this, AntennaPod is my preferred app), Termux (Linux userland on Android). For Web browsing, EinkBro and Fennic Fox (as mentioned up-thread). The note-taking (handwritten) native app is also quite good and I use that far more than I'd anticipated.
If you're looking for games, heavy web apps, video, etc., you won't be happy. If you're looking for a device that gets you away from that, I strongly recommend their line.
I've commented on the Max Lumi and experience (positives and negatives) quite a few times here on HN:
Thanks! Frankly so long as I can get a browser and install some reader apps (Kobo, Manga-one, etc.) that would fit my needs fine, and as long as they support older versions of Android for enough years (or I can avoid upgrading the app version) then things should be fine. The 10.3" Boox is 80k JPY which is a bit pricey, though, but I'll consider it vs the Kobo device next time I upgrade e-readers.
FWIW, I also hear good things about Kobo, though I don't have direct experience.
Those are based on Alpine Linux rather than Android, AFAIU, and if you're into Linux are apparently more readily customised and hacked.
(The fact that BOOX is Android is a misfeature for me, though it does make many more apps available. As noted, I use few of those and could replace much of their functionality with shell or Linux-native GUI tools. I suspect battery management would suffer however.)
It works since forever on ios in most (native) apps, including the browser. Tap on the "clock" to scroll up - that is the home button. In safari you might need to tap again, if the header was collapsed.
The ACM's site has a bar like that, though it's thin enough that the issue is with the animations rather than the size: it expands then immediately collapses after even a pixel's worth of scrolling, so it's basically impossible to get at with the "hide distracting elements" picker.
I've yet to encounter a "dick bar" that doesn't jerk the page around when it collapses. Not smooth at all. I'm surprised that it hasn't been solved in 10 years.
Hm, is that really the same thing? It's not doing the "it flaps every time I adjust my overscroll by pulling back, and it covers the text I was trying to adjust".
It may not be such an egregious example as what GP comment was referring to, but it was the first thing that came to my mind. Maybe the Medium UI has improved somewhat since I was last annoyed by this.
A variation of this is my worst offender, the flapping bar. Not only it takes space, it flaps every time I adjust my overscroll by pulling back, and it covers the text I was trying to adjust. The hysteresis to hide it back is usually too big and that makes you potentially overscroll again.
Special place in hell for those who hide the flap on scroll-up but show it again when the scroll inertia ends, without even pulling back.
Can’t say here what I think about people who do the above, but you can imagine.