Hacker News Reader

Comment by lukifer | Hacker News Reader

I agree with one exception: fixed headers are an eyesore and a usability anti-pattern in most cases. Even regular users know how to scroll to the top.

View on HN

Fixed headers also break the pagedown behaviour: when you press the page down key, you miss some lines that are hidden below the fixed headers. (If we mean the same thing by fixed headers)

Nearly all desktop applications use a fixed header, it has fine usability there. For a web app, as opposed to a primarily informational site, I think there are definite cases where a fixed header is preferred. Gmail for example, it makes sense to have control butons for your message always visible.

tl;dr on your average blog I agree, but in a web app I don't.

Since lukifer wrote "in most cases" you're only disagreeing if you think there are more web apps out there than blogs or informational sites. He didn't say a fixed element is never desirable. I think you're agreeing.

Apps are a lot of cases and most of the cases for Bootstrap.

Even with apps, it varies. My frustration is that it often seems to be used thoughtlessly, by default.

How about taking the approach of the browser on android 4+? The top bar disappears as you scroll down, but pops into view when you scroll up. It is then aligned with the user's intention, a scroll up being a signal that they wish to go up to the menu. Combine with a reasonably speedy fade-out for cases where a user is simply scrolling up to re-read something, and I think it puts most of the usability issues to rest.

Sure, regular users KNOW how to scroll to the top, but why make them? I think that fixed headers add some good convenience, especially on long pages.

They were an anti-pattern for my site so I CSSed them away. But with 2.1 there's .navbar-static-top which does the same thing as my custom CSS. I think they should place it ahead of .navbar-fixed-top in the docs since it's better in most cases.

yeah it's amazing how removing that black fixed bar make it seem suddenly so... open.

I actually pulled it at the last minute, but I was considering removing it for 2.1. Perhaps in 2.2 when we continue to evolve the docs :).

I think it's a matter of personal taste. Since all the examples used to display the bar, people probably had a tendency to include the black-bar without thinking too much about it. However, nothing prevents you from building a very functional site without it (I know i have).

Either way, huge prop for the awesome work! The new doc is simply excellent and the whole framework is just remarkable, particularly if one considers how far you guys have pushed it in less than a year.

Yes, I use a custom class on my header that removes the rounded corners that appear on the navbar when you don't use the fixed class (don't know if it's still the same on 2.1).

Would you mind elaborating? Isn't it more convenient to be able to navigate without having to scroll to the top?

It's not always a bad thing; for something like API docs, a fixed header can make sense. But for blogs and brochure-ware, and even some web apps, it breaks the focus on the content and steals precious screen real estate.

If the most common use case involves many quick jumps across the page hierarchy, fixed header can be a good fit (though an affixed side-nav might be better for wide screens). But if the most common case is drilling down to a specific page and spending a little time there, then fixed headers just create noise and get in the way.

Reply on news.ycombinator.com