Some websites have a (usually rather small) header that hides when the user scroll down.

What I never understood is why it is shown again when scrolling up. Sometimes I want to scroll a bit up to read content a little higher on the page and it becomes really annoying. Here is an example.

Why is this done? What are web designers trying to accomplish by implementing this? It seems to be just really annoying.

  • 11
    It is really annoying. Usually it makes me quit reading the article. If you want to hide the floating navbar, consider: a) making it thinner and revealing it on mouseover (or tap - but the tap area has to be big enough); b) having a floating icon in a corner that reveals the navbar when clicked. – user31389 Mar 25 '16 at 16:04
  • 26
    It appears that they assume that scrolling up is mainly intended to get back to the navbar at the top. They probably think they're doing you a favor by revealing it immediately, instead of making you scroll all the way. – Barmar Mar 25 '16 at 18:29
  • 1
    The site you posted isn't really that bad...the content that gets hidden is basically a single line... – JonH Mar 25 '16 at 19:28
  • 6
    @JonH: Uh, no? At least for me, if I scroll until the first full paragraph (ending with "... fundamentally than perhaps either Harry or Hermione.") has just disappeared, and then scroll up again by moving the scrollbar thumb a few pixels up, the header pops up and obscures not only that first paragraph, but actually even the first two lines of the next paragraph, which were previously visible - and that already includes the vertical inter-paragraph spacing. – O. R. Mapper Mar 25 '16 at 21:33
  • 1
    Perhaps because this feature looks shiny to management. – immibis Mar 26 '16 at 4:17
up vote 48 down vote accepted

Why is nav-menu visible when you are scrolling up?

In content focused sites and pages, the users expect to scroll down if there is an engagement. If user is not scrolling down but up, it can be accepted as "not engaged user". Providing other options for engagement is the main goal of this behavior.

The same pattern can be also seen in mobile safari app. When user is scrolling up, the other functionalities become visible. If user is scrolling down, elements turn into invisible format to increase the area.

  • This behavior turns elements to invisible for reducing distraction elements when there is engagement
  • This behavior turns elements to visible for increasing options when there is no / less engagement
  • 28
    This seems to assume that content is not reconsumable. What if I scrolled up to get a better look at something I passed over before or wanted to go back to? Does that not also count as engagement? – JAB Mar 25 '16 at 14:36
  • 9
    Which goes to show that a goodly number of web designers clearly do not understand what a lot of the people viewing their sites want. – jamesqf Mar 25 '16 at 16:59
  • 16
    'If user is not scrolling down but up, it can be accepted as "not engaged user".' - but where does this assumption come from? I tend to constantly scroll a little bit while reading, after every few lines, so the couple of lines I'm reading are always close to the top of the viewport. Every so often (certainly several times per page), I slightly misjudge the number of lines that will be scrolled and accidentally hide one or two still unread lines. Hence, I try to scroll up slightly again, while being fully "engaged", and instead of seeing the obscured lines again, I get an annoying header. – O. R. Mapper Mar 25 '16 at 21:37
  • 3
    @O.R.Mapper - Like in physical books, constantly flipping the page, I am also doing it when the content is a bit tough. Not every scrolling up user is accepted as "not engaged user" but general pattern is scrolling down. Yes, it is distracting... – Abektes Mar 26 '16 at 10:44
  • 2
    @MarianSpanik It's not about the designers not knowing about the home key. It's about your mom not knowing about the home key. UX designers don't design for UX designers. Still, this annoying pop down should come with a close button. – candied_orange Mar 27 '16 at 15:47

Mobile focused design

This sometimes called the scroll up bar and is a product of mobile-focused design. It is a compromise between having a fixed navigation bar that is always on screen and flowing navigation bar that is only on the top of the page. The fixed navigation bar has the downside of taking up a significant portion of the smaller mobile screen, while the flowing navigation bar has the disadvantage of requiring a lot of scrolling to reach on even rather short pages.

On Desktop, neither of these is as big an issue. A fixed navigation bar takes up a smaller portion of the viewport, and can be smaller due to the higher precision of mouse control. And it takes much less time to scroll back up to the top of the page--both because the page is shorter, requiring less scrolling, and because the user can quickly scroll to the top of the page using the scroll bar and dragging the chevron.

It is also an alternative to the so-called "hamburger menu," which hide navigation elements behind a button the user is expected to press. Hiding the options behind a button makes them less discoverable, and often results in less usage of the options. (Though, as people get used to it, it is better than it used to be.)

By showing the navigation options at the top of the page, and then leveraging a natural action such as scrolling up to show the options again, the navigation options are more discoverable and thus get more use.

Why only on scroll up?

The navigation bar is shown on scroll up for two reasons: the first is that the user who is scrolling up is more likely to no longer be engaging with the page than one scrolling down. The second is that it is natural action: the user saw those navigation options when they opened the page, and thus will naturally begin to scroll back up to the top of the page to try and reach them.

As for those who are scrolling up for other reasons, the idea is that you merely have to scroll up a bit more, and then will naturally start scrolling down again as you keep reading, pushing the navigation bar back off the page.

However, as indicated in the comments here, this often annoys these users. My recommendation to deal with this is twofold. First off, don't make the navigation appear until the user has scrolled up more than a tiny bit. Second, notice how fast the user is scrolling and react differently. A fast scroll or flick on mobile is more likely to be trying to get back to the top of the page, while a slow scroll is more likely to just be adjusting the content.

I also personally recommend not trying to shoehorn mobile design on desktop. There are ways to detect that a user is on desktop (or otherwise doesn't have touch controls) besides checking the viewport width. If the user is on desktop, fall back to a fixed navigation bar, and keep its size reasonable for mouse use.

  • 1
    And, to think. I originally planned on adding more about how this originally came from mobile webbrowser which used this technique for the URL and tab bars. I'm all ears for anyone who can recommend how to shorten this and make it more clear and to the point. – trlkly Mar 26 '16 at 1:37

Many people do this because other people do this and no other reason.

Their purported reason might be to give maximum space to their content while minimizing the header which they read about somewhere. I agree with you, though. Having the header expand when scrolled up is annoying. It wouldn't bother me if it waited till you got to the top before doing that, while not covering up content, but few do this.

  • To add on to your point about maximum space, in our companies website I took the decision to hide the navbar (on mobile only) when scrolling on pages where you can view our articles and stories for reading. If you don't touch the screen or scroll back up, the navigation bar instantly appears again. This means that even if the user decides that they want to try and navigate again, the option is instantly available but still allowing them entire screen space for browsing. I'll never understand why it's required with a larger screen size though – Alex Mar 25 '16 at 16:13

The intent behind this functionality is to support the user's assumed intent:

  • If the user is scrolling down, they must be reading the content -- so help them by getting the header out of the way.
  • If they are scrolling up, they must be done reading, and are trying to get back to the navigation at the top of the page -- so help them by bringing the header back into view.

That's the ideal. Where this becomes a problem is when the UI's attempt to guess the user's intention fails, and shoves the header into the way when the user was just scrolling up a bit to reread the previous line.

Frequently this is simply a matter of poor implementation: it's easy to simply trigger the header to come back into view on any upwards scroll event. Many sites (including the example you linked to) do that bare minimum and call it a day.

A much better implementation would wait until the user has scrolled up a significant distance -- far enough that they've clearly signaled their intent to head for the top of the page -- before bringing the header back into view. (Though not so long that the user reaches the top of the page before the trigger!) This isn't rocket science difficulty, but it's significantly more involved than the naive method. And even if it's attempted, there's some judgement involved in tuning it to the right duration, for specific content lengths, or etc. All of this takes time, attention, user testing, good communication between design and code teams, and so forth -- all of which add up to it not getting done properly all that often and the bare-bones inferior method being far more common in the wild.

Well, they want the navigation menu to be always present so users can quickly switch through pages. The designers aim to increase pageviews and time on site. Thats why they put the sticky header.

However, I found 1 A/B test where the results were not very impressive: only 11% more page views on tablets, on desktop and mobile devices there were no significant gains.

Scroll AB test

In the example website you've specified the designers have done it bad because the top bar is too big and hides the main content.

  • 1
    I'm specifically asking about the ones that hide the main content. – Kevin Mar 25 '16 at 14:07
  • 3
    They're ignorant and probably don't know that the main content is more important than providing options to navigate the site which is secondary – Kristiyan Lukanov Mar 25 '16 at 14:13
  • 3
    I would say 11% improvement on one device type, while remaining stable on other devices types, is quite impressive. – Stephan Bijzitter Mar 27 '16 at 21:28
  • 1
    Indeed, your source is nice, but it defeats the point when you suddenly draw a totally odd conclusion from it. 11% more pageviews on mobile will - depending on the site - translate to quite the increase in revenue and it's far too much to put it down to 'simply chance' – David Mulder Mar 27 '16 at 22:25
  • I just added relevant research. – Kristiyan Lukanov Mar 28 '16 at 7:26

Well I guess that when you decide that you need to hide navigation (for whatever reason), you also have to find a way to show it again. This designer choose to hide navigation on multiple scroll down. And then I guess it seemed logical to show it again on scroll up. But it certainly could have been made nicer. Like to leave some kind of navigation on top but make it smaller. And maybe use mouse movement to trigger navigation expanding again. But Yes this is not the perfect way to do it.

In this particular case, the design is flawed for two reasons:

  1. It's too sensitive. Even one step on the mouse wheel pushes the whole header in. As others said, there should be a certain threshold / speed limit for showing the header.

  2. The header is unnecessarily huge. You know what site you're at, so the logo is completely superfluous. If the header were only the one-line bar, the user would get all necessary contents of the header.

With these two point combined, any scroll up would also lead to the viewports top moving up in all circumstances, therefore responding to both types of wishes that trigger a move up (show more contents, show the header).


Actually (if I can share my personal experience), what truly distracts me is the "jumping" of the header, more than the fact it covers a part of the page. This happens both on showing the header and on hiding it.

It's all about content focusing, kind of UX design for improving engagement, user experience.

  • When users are scrolling down, they are about reading.
  • When users are scrolling up, they are not about reading.

This behaviour is more to talk, some sites even display extra options when in scrolling up.(Check the post page in medium.com)

Currently I am working on a project that is definitely designing this way, we hide all the interface only displaying the content when reading, and displaying extra options when scrolling up.(like Nav, heading, share buttons, comment, social links,...etc)

One other thing I haven't seen anyone mention is that it reminds me of the "oh wait, before you leave" popup schict that sites used to use when you made a screen movement interpreted as an exit move. This association is quite negative to me, but I assume I'll adapt or just avoid such pop-down sites where possible.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.