Hacker News Reader

Comment by joosters | Hacker News Reader

This is my most useful bookmark, I use it everywhere (it's even practical on an iphone)

So many sites have a top banner that disappears as you scroll down a page, but as soon as you scroll upwards even a little bit, it pops up again. This is immensely frustrating because I tend to read at the top of a page and scroll down as I'm reading. So if I scroll down slightly too far and then correct myself, the banner will instantly obscure the bit of the text I'm trying to read. It's very satisfying to be able to click on the bookmark and fix the site's crap design!

View on HN

One of the banes of my existence! There's no place for these stupid effing banners when browsers have inertia scrolling and infinite-scrolling sites have fixed headers (or footers) visible all the time. Maybe I wouldn't be so frustrated if the tolerance for what makes a header reappear wasn't ~3px, which is what I often perceive it to be. It totally misunderstands human behavior, which isn't to read an article word by word all the way through like a robot but to reread things to better comprehend them and jump around an article to make sense of connected ideas.

Also useful for nuking paywall overlays. Works great at The Atlantic, one click and you're in.

Just disable javascript in ublock origin for the site and you don't have to even worry about clicking anything. Lots of news sites deliver the content and then try to block access to it using javascript.

You don't need uBo to block JavaScript, you can do that right in the browser.

But often blocking JS means parts of the article don't display or the site breaks in other ways. Washington Post for example only shows blurry placeholder photos with JS off.

The kill-sticky or the element zapper in uBo can sometimes do what blocking JS cannot.

Yes, yes, yes! I am so sick of sites putting fixed top bar, and fixed side bars as well. Add "clever" bar animation in as well, and you get the awful UX we have today. Classic case of people inventing a problem to solve.

For some ui, fixed sidebar is fine imo. The headers that scroll down with you, on the other hand, can go extinct

Fixed sidebar doesn't work well for mobile devices. A button to show them works, though.

yes I mean on desktop. Original comment was something along the lines of all position fixed is bad, which I don't agree with. If it doesn't cause distress, doesn't distract the user, I don't take issue with it.

It's not just the awful UX of today. It's the awful UX of yesteryear, except this time it's the website owner's fault. https://i.stack.imgur.com/pOAAU.jpg

Or those stupid floating bars that cover the top of the screen, so when you press space to scroll a line or two is obscured. What are they thinking?

I've heard them called "vanity flaps", which seems to describe them perfectly.

I guess they're useful when the content is of low quality but you're desperate to keep eyes on the name of your site.

I hate them.

About the only thing worse than self-hiding vanity flap is a floating side bar using a slow animation to slide back into your field of view, just terrible.

slow animation to slide back into your field of view

I have a special section in my uBlock user rules, and it is full of annoyances like this.

Another one is an element with popup on hover, but you can only close it by hover-unhover a popup itself. Fly across such element by accident and enjoy your semi-modal “no idea how to get rid of”-popup without even clicking anywhere.

I believe this is a collective failure. First, developers praise the web/html/css ways to do things and want nothing more. Then they meet a complex layout problem (page-scrolling of an element which is partially covered) and find no solution, because they got what they wanted and nothing more. Nobody reports it as a bug or a FR, or it gets scrutinized as “Do we really need it? Here is a complex way to do that, incompatible with most designs, but doable, right?” and then gets closed as inactive, cause nothing adequate can be commented upon it. Developers develop selective blindness to very obvious layout bugs. The cycle repeats.

So many hours spent on nothing when a simple `viewport-offset-{top,…}: 20px` could solve it once and for all. Instead we will support global nonsense described in the article for years, despite it stays nonsense at any angle.

> on an iphone

I was so happy to discover this. Went and tried it on Firefox on iPhone... Nope. Apparently it works on all other browsers on iPhone. Just not Firefox. Sigh. I found that the bug report for doing javascript bookmarks was already filed years ago, and Mozilla just ignores it. Mozilla has a bizarre decision making structure.

Why are front end developers like this?

I suspect most of them are not like this. But their customer is not you; it's the website manager. And that manager gets promoted not by providing a great user experience but by shoving the company's name into your face as much as possible. (And also by maximizing conversions, ad clicks, and engagement. Oof. Writing that sentence makes me want to throw up.)

It is okay and works as intended. The logical move is to fix the platform, which is obviously broken. Not to blame developers. If you have external rules which motivate people to do more X sacrificing Y, but your goal is more Y, make Y one-liner and only then they will follow Y at their workplaces. On a web scale everything becomes a market and you can’t regulate a market by “don’t do that because it’s bad”. They will never have enough time for that.

I'm an enthusiastic supporter of auto-hiding headers and have added them to sites. I don't understand the hate? It's easy to scroll back down again and have the header re-hide (ie overscroll when you see it happening and then scroll down).

To me, this is better usability. I agree - fixed headers obscure the page and it's bad. But simultaneously, it's nice to be able to access the header and navigation instantly. This seems like a good compromise?

How often do you really need to access the header and navigation "instantly"? In comparison, how often do you need to reread or verify information from a previous paragraph, or review a chart or graph you viewed earlier?

It's fairly obvious which one is actually more important in the majority of cases and it's going to be the actual information you're currently reading through. Obscuring the actual content in any form is a direct reduction to page usability.

I want to access the menu 100% of the time that I'm using the site I've added the header to, after some scrolling. I re-scroll 50% of the pages that I visit.

Seems like a definite win to me? Maybe your usability desires are different than other users desires? In the case of an autohiding header - it doesn't seem like a big reduction in page visibility?

I don't think I have ever clicked anything on one of those headers on a website in my life. In fact the anti pattern is so obnoxious I literally couldn't tell you what's even on them.

I don't get who clicks those at all, this design choice is mostly on like blog and news pages and it makes me mad every damn time I have to scroll weird to get it to disappear again.

Honestly, if they have those elements on a page, usually the content is not worthwhile enough for me to suffer through their design. I usually just leave the page.

It's invasive and takes up valuable screen real estate. On top of that, it's very distracting to keep having an element bounce into view. I have a very hide time dealing with even minor distractions on my screen, personally.

I straight up permanently remove most sticky headers with Ublock Origin. 90% of the sites I read content on, I didnt get there by internal site navigation, I got there from a kagi search or HN link. The rare exception are documentation sites; I use their internal navigation often. Thankfully, though, very few of these sites use sticky headers. I just quickly scroll to the top or use the pagination buttons at the bottom.

I mostly spend time on sites that I use multiple times a day. I prefer that those sites are designed for people who use them multiple times a day, not for people who visit once, from HN.

This might be targeting a minority of users - it’s design for power users. I’d expect HN to be supportive of this sort of design.

Why would HN be supportive of this toxic attitude towards users?

> This might be targeting a minority of users - it’s design for power users. I’d expect HN to be supportive of this sort of design.

You'd expect.. But please listen.

What's wrong with a small ▾ icon you could tap to bring up the menu? Then tap again to hide it? Crucially, without changing what content's scrollTop with either action? I'd expect (haha) power-users to be capable of tapping on an indicator to bring up (or down) the menu...

If I am on my pc with a mouse getting to top is either a click or button combo away, so this popping up stuff is a net loss.

Its even worse on the phones where you sometimes get header plus some commercial and maybe a cookie banner, interacting with each other trying to figure out how to close them in order is a puzzle.

There have been maybe 1 or 2 sites out of all that i have visited, that I didn't immediately hate the banner.

To me it become a "site smell". So if I have an option I'll go elsewhere for my needs.

Nobody likes it except developers of these annoyances themselves. It's not power, it's toxic annoying dickbar.

I can access the header and navigation instantly by pressing the home key on my keyboard, or near-instantly by flicking my phone's screen downward a few times. Having a navigation header appear is like reading a book that covers half my eyesight with a hologram of the index every time I look at the previous sentence.

I read from the top of the screen and scroll the page so that I'm always reading at the same position without much vertical eye movement, and occasionally flick back a sentence or two for context, which is why it's annoying for me. For a reader who read down the page and occasionally scrolled it would be much less annoying.

This method is just bad and annoying aff, even if that header makes sense to appear. Program in a hysteresis at least and only pop it up after 20-30% of upscroll.

Most implementations do the inverse: you overscroll a little, want to fix it, but the header appears. You want to scroll it away, but it persists for a while, so you lose track of where to start to make the line you needed to the top. Because user humiliation is a MUST for a modern site, I guess.

iOS Safari does it much better than a simple hysteresis for its URL bar, but I’m not sure web has enough event detail to implement its way: pull down does nothing, only “kick” down shows the bar.

>I don't understand the hate?

Why is scrolling tied to changing the visible state of an interface element anyway? Scrolling down to hide and up to reveal /makes no sense/ to anyone other than the guy who wrote it (read: you).

Interface elements that pop in and out are /bad/, especially for people who aren't completely familiar with computers. Elements that change, especially ones that do so seemingly at random, are very disruptive, distracting, and hard to grasp.

An interface that is easy to understand and use has as few changing interface elements as possible, the more static the interface the better.

It would be ok if the header was kept just above the viewport edge and kept there (ie. slowly getting into view) when scrolling up. You still have near-instant access to the header, but it doesn't jump out at you at the tiniest hint of scroll up. The problem with "scrolling back down to re-hide" is that most of the time, scrolling down enough to hide the header also scrolls the start of the content out of view. That means you need to scroll up enough to account for both the header height and the underlying, obscured content to stay within the viewport once the header disappears. I never once in my life got it on my first try, and it often takes 3 or even 4 tries to put the first line of the paragraph at the beginning of the viewport without it getting obscured.

To me, the idea itself is not that bad and there are some usability gains to be had, but the implementations are just horrible, lazy, and user hostile.

I neither need nor want animated headers for anything ever. On mobile I can top the top of the screen to scroll to the top, and on PC I can use ctrl+home (on OSX Cmd+Home) or hold down middle mouse and speed scroll to the top.

The only thing that auto-hiding header does is cover up something I was trying to see.

Interesting that `javascript:` bookmarklets work on iPhones, given Apple's track record of locking everything down. Neat!

Browser extensions are still notoriously difficult to get on mobile for some reason (even on Android, which is open source-ish). So far the best method I've found for injecting JS into sites on Android is the Bromite [1] browser, a Chromium fork that allows you to install userscripts (which are like "diet" extensions). It also enhances privacy and comes with an adblocker.

[1] https://www.bromite.org/

Safari on iOS has support for browser extensions, I think there are extensions for user scripts as well.

In that case I’d suggest having a look at Orion, its a webkit based browser just like Safari and it tries to be close to Safari. The big difference is that you can install all extensions from Chrome and from Firefox.

Whether all extensions work is a different story but its very neat!

Its available on MacOS and iOS, both supporting extensions.

https://browser.kagi.com/

I'm a Kagi subscriber and didn't know about Orion, so thanks for this!

Oh wow, I didn't know that! Kudos to Apple there.

Reply on news.ycombinator.com