9 ms·
Headroom.js – hide your header on scroll
- WickyNilliams 12y agoI've previously submitted this link, but given the interest in the pattern with yesterday's article [0] I thought it appropriate to post again. Hopefully someone finds it useful. Happy to answer any and all questions [0] https://news.ycombinator.com/item?id=7799687 https://news.ycombinator.com/item?id=7799687
- danso 12y agoThanks for posting it...I think we've reached a point where there are so many good libraries on Github that even a 1,000+ star repo may be unknown to many of the people who would find it useful. This is something I would've tried to build on my own...but after seeing a repo with not only 3,000+ stars, which is more than the number of the library's bytes (in development), but also fewer than 5 open issues out of 60+...I'm happy to just use your solution. Nice work!
- WickyNilliams 12y agoI agree. I am continually finding repos on github that are massively popular, yet I've never come across them. Does anyone know any sites which are devoted to curating high-quality repos on github/elsewhere¹? Obviously high quality is a subjective metric, but some mix of popularity, file size, whether under active development, number of issues etc. should suffice. GitHub's explore feature is too time-sensitive to use for this purpose. ¹ I know there's unheap.com, but that's focussed specifically on jQuery plugins. I'm thinking something broader, any language, different parts of the stack etc
- eduardordm 12y agoIt's pretty nice. In my ipad the header only shows/hides if I scroll up/down AND stop touching the screen. Maybe that needs to be changed.
- WickyNilliams 12y agoUnfortunately, this is a limitation of the scroll event on iOS. It does not given intermediate results - like it's debounced - only firing the scroll event when scrolling has stopped. This is a well-documented shortcoming of iOS. As Apple puts it [0], "One-finger panning doesn’t generate any events until the user stops panning—an onscroll event is generated when the page stops moving". There is no workaround at the moment. [0] https://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariWebContent/HandlingEvents/HandlingEvents.html https://developer.apple.com/library/safari/documentation/app...
- deleted 12y ago[deleted]
- wiresurfer 12y agoI remember coming across this limitation while working on a canvas drawing mobile app. The work around was binding to touchmove, keeping a buffer of previous touchX and touchY values and then measuring the gradient of change for the values. If the gradient was mostly flat for both X and Y in a given window of touch movements you can assume the scroll has stopped even though the finger has not been lifted. Here is a jsfiddle which approximates the solution. [0] This is a very quick reconstruction of the code and has some heuristic values which I remember tuning to get the best response on the ipad. As an aside, this one has the mouse move event mapped too. But i have never found it very reliable with the same tolerance settings as touchmove. Sorry if this is useless code info. just thought of sharing. [0]http://jsfiddle.net/R6yLb/3/ http://jsfiddle.net/R6yLb/3/
- WickyNilliams 12y agowiresurfer, don't understand why you were down voted into oblivion, but now I can't reply to you. Anyway, massive thanks for that, really helpful starting point
- wiresurfer 12y agoTill the time its seen by the right pair of eyes :) Will try and see if I can fork a version and add the "inferred " touchend hack to it. Have a good day.
- diminish 12y agowhile reading the source for implementation, as a non-primary JS developer, I can't help but think that the actual functionality could be implemented in around 10 lines of code if we remove all js oo-ization and customization code.. actually I need the minimum lines of code to implement this inside to paste in my project.. any help would be appreciated..
- WickyNilliams 12y agoIt started out a lot smaller! But as with most code, it starts out nice and pretty but get disfigured over time as corner cases and bugs are unearthed. There is also some necessary ceremony when dealing with scroll events to ensure good perf, otherwise you end up with stuttery scrolling which will annoy users to no end. However, my plan has always been to trim the fat for the next release. I won't drop any features, but I'll definitely drop bytes! Feel free to fork and strip out any code you don't need though
- thathonkey 12y agoDidn't work in iOS Chrome or Safari (the header remains fixed at the top regardless of scroll behavior). Cool effect for desktop but if you can get it working as a responsive solution I think it would be a lot more useful to people!
- WickyNilliams 12y agoSee my other response (https://news.ycombinator.com/item?id=7805748 https://news.ycombinator.com/item?id=7805748). This is a shortcoming of iOS, it works perfectly on other platforms. IIRC, you reduce the tolerance value (an options you can pass to headroom) it will work on iOS also, it just isn't quite as sensitive as it should be. I'm waiting for my development iPhone to charge so I can confirm this. I'll report back :)
- thathonkey 12y agoAh. I'm not super familiar with that "bug" - is it that "touchmove" events don't get fired for single-finger scrolling (panning)? Perhaps you could make it work (albeit less gracefully) in iOS by reconciling the header visibility state once "touchend" finally gets fired though? Assuming "touchstart" gets fired as you'd expect, you can do a bit of manual calculation to determine if the y-position changed enough to warrant header hide/show.
- WickyNilliams 12y agoTo be honest, when i first developed the library I didn't have an iOS device I could test with, so just went with the simplest solution (that is, not do anything :D). Also, I'd always kind of viewed it as a progressive enhancement - if it doesn't work, it's still a fully functional header. However, now that I have an iOS device (which is still charging!), I should spend some time seeing if I can get it to work better there. I'll look at various touch events as you suggest. Currently it only listens to the scroll event
- yogo 12y agoDoesn't work for me on Android 4.2. Edit: version 4.2 Android Browser. I scrolled a good enough distance down the page.
- veesahni 12y agoFrom the tagline, I thought this was a joke.. since "hide your header on scroll" implies default browser behaviour (i.e. position:static)
- pyrocat 12y agoKind of odd that if you scroll slowly the header never disappears.
- WickyNilliams 12y agoThat's intentional actually :) The library allows you to supply a tolerance value, to reduce sensitivity of the effect. On the project site, I have it set to 5px (i.e. you must scroll > 5px for the effect to trigger). You can try out the various options in the interactive playground [0] [0] http://wicky.nillia.ms/headroom.js/playroom/ http://wicky.nillia.ms/headroom.js/playroom/
- OutThisLife 12y agoWhat's the point of this?
- sehr 12y agoTo only engage the header when you're scrolling up? Identical to the way Safari on iOS handles it.
- mrweasel 12y agoAnd this is good because? I don't get the point of this, you get pretty much the same thing by doing nothing. Fix the menu to the top of the page, when you scroll down it goes away, scroll back up and there it is. Almost no one is going to care that they'll need to scroll back to the top, I'm sure of it.
- wallawe 12y agoFrom HN front page yesterday: http://usabilitypost.com/2014/05/24/the-scroll-up-bar/ http://usabilitypost.com/2014/05/24/the-scroll-up-bar/
- gtirloni 12y agoBecause apparently we've run out of hard problems to solve in computing (as demonstrated by the amount of useless stuff we create) and need to think of the next UX trend that will give our users 0.0001% more satisfaction and increase productivity by 0.000009%. </rant mode="full">
- jblow 12y agoJust 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.
- DenisM 12y agoActually, 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.
- danielweber 12y agoA completely static site also has this property. When I scroll to the top, I can see the top. When I scroll away from the top, I cannot see the top. I've just stated a tautology, so I'm missing something. EDIT I'm seriously wondering whether this whole thing is a joke I'm not getting. Is there a jQuery plug-in that lets me click on text to go to other pages, too?
- deleted 12y ago[deleted]
- sehr 12y ago> When I scroll to the top, I can see the top. Instead, when you begin to scroll to the top you can see the top. If you have an iphone, it's navbar behavior is identical to this. http://usabilitypost.com/2014/05/24/the-scroll-up-bar/ http://usabilitypost.com/2014/05/24/the-scroll-up-bar/
- hnriot 12y agoon the iPhone you can just double tap the top of the screen to scroll to the top quickly.
- yogo 12y agoIt would be nice to have it where after scrolling up it can disappear after a certain amount of time. Very useful for scrolling back up to re-read something, versus scrolling up for navigational elements.
- dhawalhs 12y agoI haven't tried it out, but this is how you make it work with bootstrap 3 http://stackoverflow.com/questions/20648451/how-do-you-use-headroom-js-with-bootstrap-3-navbar http://stackoverflow.com/questions/20648451/how-do-you-use-h...
- Theodores 12y agoThankyou so much for that. I had got as far as including animate.css in trying to get things working and I was just about to write here about how it didn't bl00%y work!!! All is working now, thanks for your well-spotted tip.
- bbx 12y agoFYI, this UI pattern is called "Quick Return": http://www.androiduipatterns.com/2012/08/an-emerging-ui-pattern-quick-return.html http://www.androiduipatterns.com/2012/08/an-emerging-ui-patt... I had been looking for this pattern's name after having seen Chrome on Android implementing it for their navbar. I find it useful on mobile where scrolling a long distance can be laborious.
- diminish 12y agoI guess "quick return" is a remedy for "infinite scroll" making you lose top and bottom navigational elements, too.
- k__ 12y agoI liked the ExtJS4 implementation most. They kept the data in a div with hidden overflow so you could alway see header and footer (not that useful for mobile). But they also deleted old nodes when they were far enough away from the visible space in the div.
- SimeVidas 12y agoI've seen it being referred to as "scroll up bar".
- jraines 12y agoCool - do you (or anyone) have a favorite reference or catalog of UI patterns?
- keeran 12y agoWhen I scroll away from the top of the page it makes the header disappear, then reappear when I scroll back up to the top of the page. Isn't that what scrolling does? :)
- Zarkonnen 12y agoThis is what scrolling does. But this option is fancier and IMHO pointlessly visually distracting.
- sredmond 12y agoI really enjoy this feature because it gives users who read long posts (especially on mobile) quick access to the navigation bar when they need it, but without the screen-hogging characteristic of older position:absolute nav-bars. With regards to the visual distraction, I find that I almost never scroll up unless I'm done reading. Continuously scrolling down feels natural, and in this case, the header will stay hidden regardless.
- filearts 12y agoWhether or not you are a fan of disappearing/reappearing headers, this is clearly a well-thought-out bit of code that will be useful to someone. The docs also appear clear and concise. I like that it is not a jQuery plugin by default, but does provide the option. Even better (for me) is an Angular directive ready for immediate integration. Well done and keep up the good work!
- WickyNilliams 12y agoThis is my preferred way of developing JS stuff. Build an object that you can use in pure JS, then integrations with other frameworks are nothing more than simple wrappers around that object. Check the code for the jQuery plugin [0], it's tiny! By the way, I'm not an angular user, the directive was added through a PR. If you hit any problems or have any suggestions to improve it, please get in touch on github! [0] https://github.com/WickyNilliams/headroom.js/blob/master/src/jQuery.headroom.js https://github.com/WickyNilliams/headroom.js/blob/master/src...
- AlexanderZ 12y agoGreat job! How about adding an option of showing the header when the users moves the cursor to the top of the window? Just like http://lyst.com http://lyst.com are doing it.
- cmpb 12y agoAh, thanks for pointing us there. That's pretty slick
- lukasm 12y agoHere is an example with bootstrap 3 http://firestartr.co/ http://firestartr.co/
- hiphopyo 12y agoSee http://ux.stackexchange.com/questions/57990/how-usable-are-bars-that-disappear-reappear-on-scroll http://ux.stackexchange.com/questions/57990/how-usable-are-b... for more. > I admit, it's quite genius. And I bet that if Apple could, they would have patented it.
- automatthew 12y agoOnce upon a time, there was a town that had a severe rat problem. They imported a large number of cats, and soon the rats were gone. Now the town had a cat problem. They imported a large number of dogs, and soon the rats were gone. But now they had a dog problem. The town imported a large number of lions...
- pwenzel 12y agoDisa-pp-pp-pp-ointed by the lack of Max Headroom references on the linked site.
- ottertown 12y agoI really like this but I wish the documentation included recommended DOM structure / css styles... it's not as plug and play as the docs suggest
- filipedeschamps 12y agoThis is why I love open source. Amazing job, congratulations.
- druska 12y agoI hate the design of disappearing headers.
- alttab 12y agoWhy an entire js dependency for what can be accomplished with 10 lines of jquery?
- sleepyhead 12y agoAny example of that?
- filipedeschamps 12y agoIsn't jQuery a huge dependency?
- alttab 12y agoSure, but it provides more features than headroom.js.
- asadlionpk 12y agoFacebook should implement something like this for their mobile site. When I have scrolled too deep into the newsfeed, I find that refreshing the page is a better option than trying to scroll back up.
- cvrajeesh 12y agoCompletely hiding the main navigation bar - is this a UX problem?. Now I have to scroll back again to top just for seeing the navigation bar. Minor tweak will be to allow swiping from top to show it or when user moves mouse to top.
- tomhschmidt 12y agoDid you even try it? The header reappears when you start scrolling up - no need to scroll back to the top.
- benaston 12y agoGreat, so having previously suffered a rash of sites that permanently took up valuable vertical screen space with fixed headers, they now will all have headers that disappear whenever you scroll down and appear when you scroll up, with slightly buggy behavior on iOS. Has anyone considered what non-technical users will think of this UX idiom? The effect is exacerbated on mobile devices whose browser chrome follows this very same idiom (for arguably better reasons - at least it's not buggy). So you now have two "competing" user interface effects.
- vitalus 12y agoDidn't test it as much in other browsers, but seemed to be buggy w/ Safari 7.0.1 on OS X - wasn't seeing the header appear again while scrolling up.
- felipebueno 12y agoI don't like fixed headers at all and I dislike even more fixed headers that hide on scroll... it's too distracting and useless. A couple of years ago, when fixed headers became "cool", I'd write scripts for Greasemonkey just to get rid of them. Today I'm too lazy for that :D. But nice project.
- callinyouin 12y agoI really, really like this behavior on mobile, especially on sites that dynamically load new content as I scroll down. I honestly don't understand the harsh criticism I'm seeing in the comments here, because this really is a super functional way of giving the user easy access to navigation controls without having to scroll all the way to the top of a page. That said, I suppose I can understand criticism if this were being used in cases where there generally wasn't a lot of content to scroll through. I guess my point is, like all design decisions, it completely depends on the use case as to whether or not this is useful or functional.