The Scroll Up Bar

Dear website developers,<p>I&#x27;m sorry your feelings were hurt when I declined to install your wonderful app that offers access to your website. Perhaps I just wasn&#x27;t open to the awesome possibilities your app was offering me, but I already have a web browser that works just fine and couldn&#x27;t be arsed to install more stuff. It&#x27;s not you, it&#x27;s me. I&#x27;m a bad, bad person. I get it. Now, about your &quot;Scroll Up Bar&quot;... It is indeed a very fine looking user interface, but my web browser already has one. I just can&#x27;t seem to stop doing things that hurt your feelings, but could you please give me the option to turn that thing off?<p>If you&#x27;re really having trouble justifying your job, perhaps I can help you out with a small suggestion. You may have noticed a trend towards wider aspect ratio screens over the last few years. Screens have gotten so bloody wide that practically nobody wants to read a column of text that is fully as wide as their screen! People were designing websites with UI elements on the sides even back when screens were slender 1.33:1 twigs instead of the McDonald&#x27;s super-sized behemoths we have on our desks today. Perhaps you should take your bar, rotate it 90 degrees, and stick it on the side where there&#x27;s space for it!<p>Sincerely,<p>An ungrateful, lazy, bad person who just can&#x27;t be pleased.

Am I the only one who prefers to read websites in &quot;desktop&quot; mode?<p>I always feel totally alienated by the mobile page, there is information left out, annoying badly-implemented JS scrollers, etc...<p>The &quot;desktop&quot; site looks always more nice and familiar, and you can zoom and scroll around as you wish to read everything.

I used to call these type of things, short-lived fads really: User Interface (UI) element of the week. Fortunately, UI isn&#x27;t changing that often anymore. However, Javascript and the &quot;mobile&quot; platform are bringing &quot;User Interface element of the week&quot; back.<p>I am seeing lots of weird scrolly things these days. And, pages that blink out and then reappear, as they get rendered and rerendered and rerendered again by Javascript. Lots of other annoying Web 2.0 thingies that do little more than annoy. If I was a better writer, I could probably write a weekly WTF about &quot;User Interface element of the week.&quot;<p>Yes, &quot;fixed bars&quot; are annoying. We&#x27;ve had &quot;fixed bars&quot; on non-mobile for as long as I remember: Main Menu Bar, Title Bar, ooh and now a &quot;Tab Bar&quot; which is just the modern version of Windows MDI, maybe Windows MDI, Navigation bar(s) which sometimes takes up a quarter of the screen height I kid you not, the Bookmarks Bar which gets hidden the first time I open the browser and all corporate links get deleted what a pain.<p>Including your &quot;bar&quot; in the contents and letting it scroll away might be easiest, and the author noted medium&#x27;s clever idea.

Fixed bars are annoying and should rarely be used. But what&#x27;s even worse is when the mobile version helpfully removes the content or feature that you&#x27;d like to see.<p>Please just have one site, make it efficient, and be done with it.

They&#x27;re a problem on non-mobile, as well. If the bar is over content, but the scrollbar isn&#x27;t adjusted for it, pressing space or pagedown doesn&#x27;t move down one page worth of visible content. I don&#x27;t get why breaking pagedown is acceptable. It&#x27;s my preferred way to read long text.

Firefox Browser for Android&#x27;s default settings requires you to scroll up somewhat rapidly on the page you&#x27;re currently reading to reveal the browser&#x27;s auto-hidden URL bar and menu. I tend to loathe this functionality because it means slightly losing my place every time I want to multitask when reading something.<p>I suppose it wouldn&#x27;t be so bad as part of a website when viewed from a desktop environment, because you can easily highlight where you left off on the page much easier than you can on a tablet, for example.

I don&#x27;t get why these bars are being used everywhere, personally I find them annoying. Scrolling up takes like half a second...

Worse than taking up screen space, these bars often exhibit laggy scrolling behavior and cause other UI bugs. There are very few well working implementations of such fixed bars, partly due to difficulties like the position:fixed implementation in Mobile Safari[0] - unless that has been changed in iOS7.<p>I highly recommend to refrain from using position:fixed on mobile devices.<p>[0] <a href="http://remysharp.com/2012/05/24/issues-with-position-fixed-scrolling-on-ios/" rel="nofollow">http:&#x2F;&#x2F;remysharp.com&#x2F;2012&#x2F;05&#x2F;24&#x2F;issues-with-position-fixed-s...</a>

What&#x27;s worse is some sites that do this can&#x27;t seem to differentiate between iPads and iPhones and seem to use percentages everywhere in their CSS. As a result, you get a <i>huge</i> header (which feels larger in landscape orientation).

The problem is that he&#x27;s assuming the primary goal of the site&#x27;s UI is to make reading the content as enjoyable and efficient an experience as possible.<p>Sadly, that&#x27;s rarely the case.<p>A site like Forbes gets paid every time you click through to another article. Once you&#x27;ve landed on an article and you&#x27;re reading it, your value to them has been expended. Thus they have almost a diametrically-opposed interest to yours- you want to read the content uninterrupted, and they want you to click another link.

After being into this field for quite a while now, I feel like there are no better web design than no web design.<p>Plain html works great on any device, is very readable, accessible and <i>lightweight</i>. There&#x27;s nothing to lose in having 0 loc css.

I was all ready to complain that I want some sort of nav&#x2F;menu thing always stuck at the top, but I&#x27;m actually OK with the solution presented where it just shows as soon as you scroll up without having to scroll all the way.

FIxed bars and JS pop-ups are the window pop-ups of the 90&#x27;s and really I&#x27;m just waiting for someone to make a chrome extension that takes care of &#x27;em in the same way.<p>The only real issue is that mobile browsers don&#x27;t allow extensions of any kind (at least the ones I&#x27;ve used don&#x27;t). So there is no real way to add such customizations to mobile browsers, and we&#x27;re left hoping they go mainstream enough that someone either creates a browser around that feature (ie useragent switch, which is kind of annoying to use because it means copying the url and switching apps), or a dev in a mainstream browser makes it their weekend project. Neither one of these options is ideal, in the first you&#x27;re left with a bunch of browsers that do one thing, in the latter you&#x27;re going to end up with a feature that will slowly stop working as the dev&#x27;s main work builds and his manager tells him to drop it.

<p><pre><code> An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up. </code></pre> This pattern is one of the many irritating things about the mobile Chrome and iOS 7 browsers that prevents me from using devices implementing either.<p>I typically stick to reading around the top of my device, and occasionally I want to re-read something I just read. Instead of just getting to re-read the hidden lines, I have to continue scrolling while stupid chrome or a fixed bar appears, and then finally lets me scroll the content.<p>It&#x27;s probably the case that a lot of people love this, but I hate it. If I want to see the browser chrome or navigational elements, I&#x27;m happy to tap the top of the window to scroll me there. I don&#x27;t want the browser trying to figure out what I want to do based purely on scrolling.

I was hoping to read about a usability study done when I clicked the link. I do agree for blogs and articles but for web apps I&#x27;m not sold.

I suspect this was influenced by the browser behavior in iOS 7. Almost all the browser chrome (full address bar and status bar) disappears when you start scrolling but reappears if you scroll back up quickly.<p>In fact, the iOS behavior is rather more nuanced:<p><pre><code> * Scrolling down hides chrome * Swiping up quickly reveals chrome * Scrolling up slowly does not reveal chrome * Scrolling to the top of the page reveals chrome * Over-scrolling past the bottom reveals chrome </code></pre> It&#x27;s often interesting to see how much consideration Apple puts into small details like this.

The thing about this is that there is, as far as I can tell, no good solution for the fact that it can take a long, long time to return to the top of a page with a lot of text on a mobile device. If I read 3&#x2F;4 of a lengthy story on my phone and I want to navigate somewhere else on the same website my only practical option is to revisit the main page of the site and start navigating from there.<p>Do any mobile browsers have a &quot;return to top of page&quot; function? My keyboard has a &quot;Home&quot; key, my phone does not.

Dear website users,<p>We feel your pain. It may not seem like it since we develop ever more complicated UI schemes to overcome the W3C&#x27;s frankenstandards (seriously, who comes up with a coordinate system based on a &#x27;nominal arms length away&#x27; from the screen and then creates another set of units for mobile. I know there&#x27;s a lot of smart people who contribute great data standards from the W3C, but when it came to presentation standards they either 1) completely forgot their linear algebra or 2) didn&#x27;t bother to look at Postcript&#x27;s coordinate system or both).<p>Some of us are reinventing the browser as it should have been written (with polyfills and shims), but this will take a while to get right. (For those that remember, Alan Kay originally said there should be no browser, just a code container, we are once again getting close to something he said decades before).<p>We understand that the W3C has set the expectation that everything bad on the web happens because of us devs not following their &quot;standards&quot; (even when alt changes to title changes to picture caption in as many years), but at some point it might be worth asking them &quot;why are your presentation standards so inconsistent and hard to follow?&quot;<p>Sincerely,<p>A webdev who is tired of cajoling CSS and JS to reinvent the same god-damned three column layout that should have worked in the 90&#x27;s (oh wait, you didn&#x27;t realize that Postscript predates the web? Yes, yes it did. So the W3C could have sought presentation layer experts of its time in drafting presentation standards, but didn&#x27;t).

Someone has already mentioned my JS lib to handle this below, but as the author I feel compelled to mention it myself with some additional explanation.<p>I built headroom.js [0] to handle exactly this. It simply adds classes at scroll up or down so you can be as fancy as you want (or not!) with the show hide effect. You can set a custom offset (eg. Don&#x27;t invoke the hide&#x2F;show mechanism until 100px down the page), you can set a tolerance (eg. Must have scrolled more than 10px before hide&#x2F;show) and a few other features for more advanced usage.<p>And for fun I built a little playground so you can explore the various features and find a configuration you like [1]<p>[0] <a href="http://wicky.nillia.ms/headroom.js/" rel="nofollow">http:&#x2F;&#x2F;wicky.nillia.ms&#x2F;headroom.js&#x2F;</a><p>[1] <a href="http://wicky.nillia.ms/headroom.js/playroom/" rel="nofollow">http:&#x2F;&#x2F;wicky.nillia.ms&#x2F;headroom.js&#x2F;playroom&#x2F;</a><p>(meta: I submitted it here, but it never gained traction, someone else submitted it to designer news and it absolutely blew up, can&#x27;t believe it almost has 4000 stars!)

I honestly loathe the &quot;scroll up bar&quot; feature in Chrome browser because it throws off my instincts about how to interact with the UI. If something auto-hides into the top of the screen, my instinct is to pull it down from the top if I want to see it again. That just brings up the Android notification system.

For me, the ideal solution is just get rid of the fixed bar, and have a clickable menu drop down.<p>I don&#x27;t want a page to analyze every of my behaviors and try to predict what I want to do. Sometimes I just like to scroll up and down to look for stuff, and I don&#x27;t want some bar flashing in and out.

I don&#x27;t know if Android has the feature where you just tap the status bar to scroll to top but iOS does. With that feature I&#x27;d rather nav bars just stay at the top of the page, I&#x27;ll just tap the status bar if I need to get back up there, which is almost never anyway.

&gt; An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.<p>No. When I scroll up, that&#x27;s what I usually want to do: scroll up, see some content that is currently out of view. If that bar appears first, I have to swipe an inch more, which doesn&#x27;t sound that horrible, but it results in an inconsistency between mental model (swipe down 1 inch, see what is 1 inch above) and technological reality (sorry, you need to scroll 2 inches!).<p>In the eBay Android app, where I want to quickly compare search results, this annoys the hell out of me.<p>One of the best things about touch interfaces is the natural mapping between mental model and technology. Let&#x27;s not break this.

I see no problems at all with fixed top bars. They take what? 20pixels? 50 pixels at most. It&#x27;s really not a huge loss. I&#x27;m more annoyed by lateral bars since I already use the horizontal space with tree style tab.

I loathe what The Verge has done when browsing the site on an iPad. That awful little black box stays stuck in the middle of my screen, and even selecting close just makes it a smaller black box in the middle of my screen.

We reverted the title. The submitted title was &quot;Fixed bars are becoming a new nightmare on mobile&quot;.<p>The HN guidelines ask you not to rewrite titles. Especially please do not rewrite them to make them more controversial.

The solution presented there is the same used by Google Chrome on Android, it might surprise a totally new user, but one gets used to it pretty fast. Seems like it&#x27;s the best solution all around.

The worst implementation I&#x27;ve seen was for a desktop only web application. The navigation bar was only expanded when the scrollbar was at the very top. For very long pages they implemented a button that scrolls the user back to the top of the page so the navigation bar expands and the user can navigate. In the meantime, the horizontal space went mainly unused. The boss saw the IBM page and wanted the menus like this.

FYI one plugin that does that is <a href="http://wicky.nillia.ms/headroom.js/" rel="nofollow">http:&#x2F;&#x2F;wicky.nillia.ms&#x2F;headroom.js&#x2F;</a>

Fun pattern, but is it more <i>useful</i>? I think its hyperbolic to call losing 160px of reading space on top of a desktop browser a &quot;nightmare&quot;. Something a user can see all the time has greater affordances than something that is hidden. Especially if that something is as essential as navigation. Honestly, I think this is more style than usability.

I&#x27;m quite surprised to see anybody suggesting this pattern be used, because it&#x27;s exactly why I had to stop using Firefox for Android. It makes no sense to need to scroll up and lose your place in a page to access the menu. Whichever designer suggested those two actions be bound together doesn&#x27;t have any business designing.

Vimeo has an odd top-bar that hardly shows up at all when you first load the page, but if you scroll <i>up</i> (when you&#x27;re already at the top of the page) it unfolds and shows you more videos. e.g. <a href="http://vimeo.com/28408829" rel="nofollow">http:&#x2F;&#x2F;vimeo.com&#x2F;28408829</a>

i agree with the post. but i just noticed on my desktop chrome browser that medium also applies the same behavior on here. i believe this is not necessary, as on a desktop i have plenty of reading space and this way im actually experiencing a less usable version of a website....

Am I the only one hating Twitter&#x27;s Android app behavior in terms of fixed bars?<p>I tend to read tweets from oldest to newest, and the &quot;Home&#x2F;Discover&#x2F;Activity&quot; bar always gets on my way. Moreover, I don&#x27;t even need the top blue bar. Just gimme the content!

&quot;Creeper&quot; nav bars (an appropriate term, I think) are partly a consequence of mobile devices not letting you instantly jump to the top of a page. Mobile devices should offer a snappy, intuitive way to jump to the top or bottom of a page.

Is it weird that the title of TFA is &quot;The Scroll Up Bar&quot; and the title of this post is &quot;Fixed bars are becoming a new <i>nightmare</i> on mobile&quot;?

Simpler solution: every keyboard has a &#x27;Home&#x27; button -&gt; MAGIC. ;)