Live data from Hacker News

Headroom.js – hide your header on scroll

wicky.nillia.ms

91–99 of 99 posts

Re: Headroom.js – hide your header on scroll

#91
post #16

Just get rid of the damn headers. Users don't want them. They are just misguided ways of trying to raise retention, but really what they do is make your site less pleasant to use, which then makes me not want to come back later.

I absolutely loathe fixed headers, but I think this script is pretty cool. The headers stay out of your way when you are reading, and when you actually want to use the navigation you don't have to scroll all the way to the top. I really see no downside, except "more JavaScript." (People who are complaining about JavaScript: you really aren't going to like the Web in 5 years)

Downside: more javascript (another file to load, to break, to parse, to wait on, etc)

Downside: unusual behaviour. Users fully understand how to scroll to the top of a page to find the header. This hack already requires them to scroll up to get to the header. Also, there's a decent chance that if you're trying to find the header that you're going to leave the page, so it doesn't matter if you lose your spot.

It's a cutesy feature, but it's cumbersome and pointless, and doesn't add any real usability (unless you count getting rid of fixed headers, which also don't add any real usability).

Re: Headroom.js – hide your header on scroll

#92
post #19
post #16

Just get rid of the damn headers. Users don't want them. They are just misguided ways of trying to raise retention, but really what they do is make your site less pleasant to use, which then makes me not want to come back later.

Actually, it's not as bad as the headline implies. Header stays hidden once it disappears, giving you the entire screen to read, but if you scroll up a bit it appears again, so you can use it to navigate. It acts the same as iOS Safari header - once you get used to it, it's really nice.

Except that Safari uses it to hide important browser chrome. Websites use it to hide headers that really don't need to be there in the first place.

Re: Headroom.js – hide your header on scroll

#93
post #16

Just get rid of the damn headers. Users don't want them. They are just misguided ways of trying to raise retention, but really what they do is make your site less pleasant to use, which then makes me not want to come back later.

I absolutely loathe fixed headers, but I think this script is pretty cool. The headers stay out of your way when you are reading, and when you actually want to use the navigation you don't have to scroll all the way to the top. I really see no downside, except "more JavaScript." (People who are complaining about JavaScript: you really aren't going to like the Web in 5 years)

There are two kind of significant problems with headers that hide as you scroll, in my experience. 1) You can't easily get to the navigation when you do need it—have to scroll up some uncertain amount that varies by site (this unknown makes simply using scrollbars more reliable)—and 2) you get it when you don't need it, as in you're simply scrolling back to reread a portion of the text above.

In short, this element feels always somewhat out of user's control.

Much more usable on mobile would be putting such navigation in a kind of sidebar that many apps already employ (often accessible by swiping from the left edge of the screen), while on desktop a great solution is simple “top” links, strategically placed.

Plain fixed headers, possibly somewhat collapsing in height as you scroll, also seem better than vanishing headers from the point of control.

Unless there comes out some positive research on usability of this particular UI element, I personally am not convinced.

Re: Headroom.js – hide your header on scroll

#94

Earlier quoted context omitted.

I absolutely loathe fixed headers, but I think this script is pretty cool. The headers stay out of your way when you are reading, and when you actually want to use the navigation you don't have to scroll all the way to the top. I really see no downside, except "more JavaScript." (People who are complaining about JavaScript: you really aren't going to like the Web in 5 years)

There are two kind of significant problems with headers that hide as you scroll, in my experience. 1) You can't easily get to the navigation when you do need it—have to scroll up some uncertain amount that varies by site (this unknown makes simply using scrollbars more reliable)—and 2) you get it when you don't need it, as in you're simply scrolling back to reread a portion of the text above. In short, this element f…

    > Plain fixed headers, possibly somewhat collapsing in height as you scroll, also seem better than vanishing headers from the point of control.
That's doable with this library btw. What happens in response to scrolling is entirely dependent on your CSS. So when scrolling down, have it apply a class which reduces the height, and when scrolling up, restore the height.

Also, it's worth noting, that whilst the obvious use-case for the lib is headers; it can be used on any element, to have it react to scroll direction and distance. For instance, I've used it to make a sidebar fixed after scrolling past a certain point on the page (classic sticky sidebar pattern). Also, I've used it to only show a "back to top" link when a user is > 50% down the page and scrolling up quickly - so unless you're deep in a page and scrolling towards the top, the link will never be visible/distracting.

It works well for these scenarios too!

Re: Headroom.js – hide your header on scroll

#96
post #89

Earlier quoted context omitted.

What then? You tap the bottom of the screen to bring up the chrome instead.

There's no snapback to where you were reading if you double-tap the top. Which sucks and makes for a bad UX if you only need the top bar for a moment (for a share button, for example).

I said tap the _bottom_ of the screen, not the top.

Re: Headroom.js – hide your header on scroll

#97
post #89

Earlier quoted context omitted.

There's no snapback to where you were reading if you double-tap the top. Which sucks and makes for a bad UX if you only need the top bar for a moment (for a share button, for example).

I said tap the _bottom_ of the screen, not the top.

And I'm pretty sure you lost the plot, because this thread is about the header library in the OP, not the browser chrome. Your suggestion to double-tap to the top (with a menu that doesn't follow you) means I lose my place. And so it's not a good suggestion.

Re: Headroom.js – hide your header on scroll

#98
post #97

Earlier quoted context omitted.

I said tap the _bottom_ of the screen, not the top.

And I'm pretty sure you lost the plot, because this thread is about the header library in the OP, not the browser chrome. Your suggestion to double-tap to the top (with a menu that doesn't follow you) means I lose my place. And so it's not a good suggestion.

The context of this sub-thread is

    on the iPhone you can just double tap the top of the screen to scroll to the top quickly.
Which is all about browser chrome.

Re: Headroom.js – hide your header on scroll

#99
post #97

Earlier quoted context omitted.

And I'm pretty sure you lost the plot, because this thread is about the header library in the OP, not the browser chrome. Your suggestion to double-tap to the top (with a menu that doesn't follow you) means I lose my place. And so it's not a good suggestion.

The context of this sub-thread is on the iPhone you can just double tap the top of the screen to scroll to the top quickly. Which is all about browser chrome.

Dude. The iPhone was a comparison, not a concrete part of the discussion. Did you, like, read the posts before it in this subthread that are whining about how this thing is useless because you can "just" scroll to the top of the page to see the menu bar on the page? And, now, how tapping to the top isn't a good solution? There are enough upvotes on my posts here that I don't think this is that unclear.
Post reply on HN