User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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.
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 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.
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.
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.
The intent behind this functionality is to support the user's assumed intent:
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.
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.
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:
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.
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.
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.
