
The Scroll Up Bar - muloka
http://usabilitypost.com/2014/05/24/the-scroll-up-bar/
======
beloch
Dear website developers,

I'm sorry your feelings were hurt when I declined to install your wonderful
app that offers access to your website. Perhaps I just wasn't open to the
awesome possibilities your app was offering me, but I already have a web
browser that works just fine and couldn't be arsed to install more stuff. It's
not you, it's me. I'm a bad, bad person. I get it. Now, about your "Scroll Up
Bar"... It is indeed a very fine looking user interface, but my web browser
already has one. I just can't seem to stop doing things that hurt your
feelings, but could you please give me the option to turn that thing off?

If you'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'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's space for
it!

Sincerely,

An ungrateful, lazy, bad person who just can't be pleased.

------
Aardwolf
Am I the only one who prefers to read websites in "desktop" mode?

I always feel totally alienated by the mobile page, there is information left
out, annoying badly-implemented JS scrollers, etc...

The "desktop" site looks always more nice and familiar, and you can zoom and
scroll around as you wish to read everything.

~~~
barrkel
No, you're not alone. I almost always choose desktop mode where available,
primarily because mobile sites disable zoom and choose settings for margins
and font sizes that make their text almost unreadably large - frequently only
two or three words per line, with masses of whitespace all around.

Reading such articles feels claustrophobic, because you're stuck in this long
tunnel of text, with little visual indicator of how long it lasts, inducing
anxiety about wasted time. If you're somewhere in the middle, it's a long trip
back up to the top.

The close to optimal mobile browser for me was the original (AOSP) Android
browser around 2.3. It rewrapped text on double-tap to fit in the visible page
area, meaning you could choose what effective font size worked well for you.
And zoom still worked, so you had a good handle on where you were on the page,
and an easy way out of it.

Neither Firefox nor Chrome on Android are as good a browser for me.
Unfortunately, getting the AOSP browser back is awkward, unless you want to
use Dolphin or similar, and besides, it no longer has the rewrap
functionality.

PS: Google are the evil people here. They deliberately removed this feature
from Chrome and AOSP browser, and are punishing sites that don't serve mobile-
specific content - i.e. content that is less usable for people who prefer
zoom-based navigation.

~~~
rockdoe
The feature is still in Firefox for Android. "Text Reflow" in settings.

~~~
derobert
It's not there any more. See Bug 900564[1]. Basically, they removed the pref
from beta and release builds last fall because they don't believe it works
nearly well enough.

[1]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=900564](https://bugzilla.mozilla.org/show_bug.cgi?id=900564)

------
mmphosis
I used to call these type of things, short-lived fads really: User Interface
(UI) element of the week. Fortunately, UI isn't changing that often anymore.
However, Javascript and the "mobile" platform are bringing "User Interface
element of the week" back.

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
"User Interface element of the week."

Yes, "fixed bars" are annoying. We've had "fixed bars" on non-mobile for as
long as I remember: Main Menu Bar, Title Bar, ooh and now a "Tab Bar" 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.

Including your "bar" in the contents and letting it scroll away might be
easiest, and the author noted medium's clever idea.

------
masterleep
Fixed bars are annoying and should rarely be used. But what's even worse is
when the mobile version helpfully removes the content or feature that you'd
like to see.

Please just have one site, make it efficient, and be done with it.

~~~
nostromo
It's so much easier to fuck up mobile than it is to do it right. And if you're
not doing it exactly right, don't do it at all.

Here's what the EC2 console looks like on mobile:

[http://i.imgur.com/MfbCdhU.png](http://i.imgur.com/MfbCdhU.png)

It appears that Amazon is doing this on purpose...

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-
scale=1, user-scalable=no">

Yes... _user-scalable=no_

~~~
MattHeard
> Disabling user-scalable (namely, the ability to double tap to zoom) allows
> the browser to reduce the click delay. In touch-enable browsers, when the
> user expects the double tap to zoom, the browser generally waits 300ms
> before firing the click event, waiting to see if the user will double tap.
> Disabling user-scalable allows for the Chrome browser to fire the click
> event immediately, allowing for a better user experience.

> From Google IO 2013 session
> [https://www.youtube.com/watch?feature=player_embedded&v=Dujf...](https://www.youtube.com/watch?feature=player_embedded&v=DujfpXOKUp8#t=1435s)

Source:
[http://stackoverflow.com/a/16910559](http://stackoverflow.com/a/16910559)

~~~
ehsanu1
I doubt that's why. In this case, as the site doesn't appear to render well at
all on mobile in the first place, that meta tag was probably just blindly copy
pasted from somewhere else that did have a responsive page.

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

~~~
pimlottc
Thank you! It is a huge peeve of mine as well. There needs to be a good post
somewhere to publicize this issue. Something you can point to when you find a
broken site that lays out the solution so it can be fixed.

But I'm not sure exactly what the mechanism is that causes this; I thought it
was simple a case of forgetting to add top padding to the page body, but that
doesn't always seem to be the case. Last time I saw a site that did this, it
already had the padding but still misbehaved in Chrome. Yet the paging worked
correctly in Firefox! Further testing showed Safari worked, so (in this case,
at least) it seemed to be webkit-related.

But that's just one scenario. I suspect there's a number of ways people get
this wrong, and it's unfortunately not just a single simple fix for all cases.

~~~
CmdrKrool
Adding top padding would push the beginning of the content down nice and clear
of the fixed header, but that's not enough to avoid the page down problem
because for paging purposes it's normally the height of the box from border to
border that is used - which seems right and consistent with (vertical)
scrollbars normally being drawn from border to border. And top padding's only
at the top of the first page of content anyway, not every page.

Anyway Firefox did make some effort to work around this common web design
error (that being what I'd call it) which is probably why it behaves
differently to Chrome:
[https://bugzilla.mozilla.org/show_bug.cgi?id=780345](https://bugzilla.mozilla.org/show_bug.cgi?id=780345)
but I still find it hit and miss between from one page to the next. As you
mention there are many scenarios - what if the fixed header only goes across
say half the width of the page? What if it's less than 100% opacity? What if
it varies in height? The browser makers have to resort to "heuristics" and now
we're off into the land of deep unpredictability.

While writing this I've also just noticed that - fixed header or no - pressing
space / page down doesn't go exactly the same distance (in Firefox) as paging
down by clicking on the scroll bar. Which is also a bit disconcerting.

------
rl3
Firefox Browser for Android's default settings requires you to scroll up
somewhat rapidly on the page you're currently reading to reveal the browser'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.

I suppose it wouldn'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.

~~~
0h139
You can disable this behavior by unchecking the checkbox in Settings ->
Display -> Scroll title bar.

~~~
rl3
Good point, thanks!

------
pera
I don't get why these bars are being used everywhere, personally I find them
annoying. Scrolling up takes like half a second...

~~~
vertex-four
The sole reason is branding. Websites don't want you just reading content;
they want you reading content _on their site_. The most obvious way to remind
you that you're reading it on their site, and thus convince you to come back,
is a fixed header bar.

~~~
marcosdumay
Funny thing that they make a site that looks exactly the same as every other
site, and then they discover that they have a branding problem.

I never have any problem remembering that I'm readding HN.

~~~
Atroxide
Branding problem, or a content problem?

------
pfalke
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.

I highly recommend to refrain from using position:fixed on mobile devices.

[0] [http://remysharp.com/2012/05/24/issues-with-position-
fixed-s...](http://remysharp.com/2012/05/24/issues-with-position-fixed-
scrolling-on-ios/)

~~~
badman_ting
Mobile web moves too quickly to care about what was true 2 entire years ago :)
iOS got position: fixed a couple versions back, and iOS users upgrade rapidly.

So, the advice not to use position: fixed on mobile may still be good, but iOS
isn't the reason why.

------
SoftwareMaven
What's worse is some sites that do this can't seem to differentiate between
iPads and iPhones and seem to use percentages everywhere in their CSS. As a
result, you get a _huge_ header (which feels larger in landscape orientation).

~~~
tambourmajor
Another big annoyance is when the mobile mode is solely based on the user
agent string and there is no way to deactivate it other than changing the user
agent (for example Google Search). It’s almost as if no Google employee has a
tablet device. I would be genuinely interested in seeing behind the curtains
of decisions like this one.

~~~
judk
Google believes tablets are mobile. Heck, with the new maps, Google thinks
desktops are mobile!

------
dkrich
The problem is that he's assuming the primary goal of the site's UI is to make
reading the content as enjoyable and efficient an experience as possible.

Sadly, that's rarely the case.

A site like Forbes gets paid every time you click through to another article.
Once you've landed on an article and you'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.

~~~
dredmorbius
One of the many insidious ways in which advertising (and the business
practices resulting from it) is overtly harmful.

------
fdsary
After being into this field for quite a while now, I feel like there are no
better web design than no web design.

Plain html works great on any device, is very readable, accessible and
_lightweight_. There's nothing to lose in having 0 loc css.

~~~
err4nt
I wouldn't say 0 loc CSS is nothing to lose, I've been using Markdown to
format some really basic notes, and here's my stylesheet for styling markdown
documents:
[http://staticresource.com/styledown.css](http://staticresource.com/styledown.css)

It's still a work-in-progress, but it's great for documenting my code as I
work on websites. Here's a demo page with some tests of the markdown output I
generated on the command-line using pandoc:
[http://staticresource.com/misc/demo.html](http://staticresource.com/misc/demo.html)
I'm grabbing web fonts from Google. It's responsive and reads well on desktop,
tablet, and phone. The styles still work offline (with no web fonts)

There isn't a whole ton of CSS there (I work with files 500 loc CSS up to 5k
or 7k a a time. I whipped this up in one morning because I was tired of my
IDE's markdown live preview, so now I have folders on my server that are
watched, and any time I save a markdown file it automatically regenerates the
HTML in the same folder.

Anyway, you can't say there's NOTHING to lose having 0 loc CSS. Here's what
that same markdown demo that looks like with no CSS:
[http://staticresource.com/misc/demohtml.html](http://staticresource.com/misc/demohtml.html)

Think they are equivalent?

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

~~~
jrajav
This is exactly how Chrome for Android works with its toolbar and I think it
works very nicely.

------
vxNsr
FIxed bars and JS pop-ups are the window pop-ups of the 90's and really I'm
just waiting for someone to make a chrome extension that takes care of 'em in
the same way.

The only real issue is that mobile browsers don't allow extensions of any kind
(at least the ones I've used don't). So there is no real way to add such
customizations to mobile browsers, and we'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're left with
a bunch of browsers that do one thing, in the latter you're going to end up
with a feature that will slowly stop working as the dev's main work builds and
his manager tells him to drop it.

------
erso

      An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.
    

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.

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.

It'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'm happy to tap the
top of the window to scroll me there. I don't want the browser trying to
figure out what I want to do based purely on scrolling.

------
dmalik
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'm not sold.

~~~
dj-wonk
Right. Breadcrumbs and/or nav bars on apps are nice.

~~~
hiphopyo
Indeed:

[http://ux.stackexchange.com/questions/33071/are-
breadcrumbs-...](http://ux.stackexchange.com/questions/33071/are-breadcrumbs-
still-in)

------
pimlottc
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.

In fact, the iOS behavior is rather more nuanced:

    
    
      * 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
    

It's often interesting to see how much consideration Apple puts into small
details like this.

~~~
rrrx3
This is also the best implementation. I think there's some stuff lost in
translation when done on the web. Dollars to doughnuts these UI patterns don't
have a speed function in them to adjust for intent.

------
JamisonM
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/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.

Do any mobile browsers have a "return to top of page" function? My keyboard
has a "Home" key, my phone does not.

~~~
micampe
I don't know what mobile phone you use, but on iOS tapping the status bar
scrolls back to the top of the page (or anything else that scrolls in the
system).

~~~
farmdawgnation
Aside: Is there a way to detect that happening in JavaScript? Just thinking
that detecting the user doing that and then showing the site's nav bar again
would be groovy...

~~~
micampe
I don't know, but I don't think it's wise to override a system behavior in
ways the user doesn't expect. Better just put a button on the page.

------
coldnebo
Dear website users,

We feel your pain. It may not seem like it since we develop ever more
complicated UI schemes to overcome the W3C's frankenstandards (seriously, who
comes up with a coordinate system based on a 'nominal arms length away' from
the screen and then creates another set of units for mobile. I know there'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't bother to look at Postcript's coordinate system or
both).

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).

We understand that the W3C has set the expectation that everything bad on the
web happens because of us devs not following their "standards" (even when alt
changes to title changes to picture caption in as many years), but at some
point it might be worth asking them "why are your presentation standards so
inconsistent and hard to follow?"

Sincerely,

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's (oh wait, you didn'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't).

------
WickyNilliams
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.

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't invoke the hide/show
mechanism until 100px down the page), you can set a tolerance (eg. Must have
scrolled more than 10px before hide/show) and a few other features for more
advanced usage.

And for fun I built a little playground so you can explore the various
features and find a configuration you like [1]

[0] [http://wicky.nillia.ms/headroom.js/](http://wicky.nillia.ms/headroom.js/)

[1]
[http://wicky.nillia.ms/headroom.js/playroom/](http://wicky.nillia.ms/headroom.js/playroom/)

(meta: I submitted it here, but it never gained traction, someone else
submitted it to designer news and it absolutely blew up, can't believe it
almost has 4000 stars!)

~~~
hiphopyo
Keep it up!! Honestly you deserve more stars..

------
Pxtl
I honestly loathe the "scroll up bar" 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.

------
xux
For me, the ideal solution is just get rid of the fixed bar, and have a
clickable menu drop down.

I don'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't want some bar flashing in and out.

~~~
derwildemomo
Well, you must have missed the discussion a few days ago about the evilness of
the hamburger button.
[https://news.ycombinator.com/item?id=7794505](https://news.ycombinator.com/item?id=7794505)

The main argument against using a menu-button is that it hides the contents
behind it, which makes them hard to discover and interact with.

------
jasonkostempski
I don'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'd rather nav bars just stay at
the top of the page, I'll just tap the status bar if I need to get back up
there, which is almost never anyway.

~~~
jrajav
Android doesn't have that by default, you need an app for it, and I'm pretty
sure you also need to be rooted. Definitely not something you can depend on
users having.

------
currysausage
> An interesting way to solve the issue is to hide the bar when scrolling
> down, and show it when scrolling up.

No. When I scroll up, that'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'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!).

In the eBay Android app, where I want to quickly compare search results, this
annoys the hell out of me.

One of the best things about touch interfaces is the natural mapping between
mental model and technology. Let's not break this.

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

~~~
nevir
40-50 pixels is generally what you want (for decently sized touch targets)

------
bobbles
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.

------
dang
We reverted the title. The submitted title was "Fixed bars are becoming a new
nightmare on mobile".

The HN guidelines ask you not to rewrite titles. Especially please do not
rewrite them to make them more controversial.

------
lobo_tuerto
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's the best solution all around.

------
emsy
The worst implementation I'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.

------
lukasm
FYI one plugin that does that is
[http://wicky.nillia.ms/headroom.js/](http://wicky.nillia.ms/headroom.js/)

~~~
WickyNilliams
Thanks for the shout out :) I built this after enjoying the pattern in the
Android browser on honeycomb (3.0). They eventually added it to chrome after I
suggested it to Paul Irish!

------
jasontsui
Fun pattern, but is it more _useful_? I think its hyperbolic to call losing
160px of reading space on top of a desktop browser a "nightmare". 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.

~~~
SilasX
Yes, losing 25% of the already-scarce vertical space is a nightmare, to the
extent that UX can be a nightmare. Plus, I've seen sites where the nav bar
locks the URL bar in position and keeps me unable to scroll away from it,
making it more like 50%. It's like I'm looking at the site through blinds!

And it's all for functionality I'm not even going to use!

------
nilved
I'm quite surprised to see anybody suggesting this pattern be used, because
it'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't have any
business designing.

~~~
rrrx3
Scrolling has long been established as a transient action. It makes total
sense to submerge the menu until such time as it's needed. This pattern is
prevalent in plenty of mobile apps. Google Chrome on iOS is a shining example.
Safari, as well.

You can make a reasonable assumption that users scrolling down are reading
content, and thusly have no need for the menu bar. What I'm seeing from your
perspective is that you're failing to recognize that "losing your place" in
order to reveal the menu is a complete change of task. By bringing back the
menu, or even using it if it were in place statically, your task and intent
has shifted. If you've decided to abort your menu task and revert to reading
content, it provides less cognitive friction to let the user scroll themselves
back to their original place.

My question to you is - what logical sense does it make to stop reading an
article midway through and begin interacting with the menu, unless your intent
is to navigate away from the content itself? And if it makes sense to you to
do this, why do you find yourself changing and aborting tasks so swiftly? Are
there other interactions that you've failed to discover that might be
beneficial (tap and hold to get a menu, for example)?

TL;DR - you're bitching about an edge case.

------
sp332
Vimeo has an odd top-bar that hardly shows up at all when you first load the
page, but if you scroll _up_ (when you're already at the top of the page) it
unfolds and shows you more videos. e.g.
[http://vimeo.com/28408829](http://vimeo.com/28408829)

------
wurzelgogerer
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....

------
julenx
Am I the only one hating Twitter's Android app behavior in terms of fixed
bars?

I tend to read tweets from oldest to newest, and the "Home/Discover/Activity"
bar always gets on my way. Moreover, I don't even need the top blue bar. Just
gimme the content!

------
dj-wonk
"Creeper" 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.

~~~
avel
Opera on mobile had an awesome implementation of "jump to top": You scroll
upwards twice or just quickly enough, and if you still have a long way to go,
a button pops up for scrolling automatically to the top. I wish this was
implemented universally in Android. [http://lifehacker.com/5784500/opera-
mobile-11-is-a-zippy-bro...](http://lifehacker.com/5784500/opera-mobile-11-is-
a-zippy-browser-for-android-and-symbian-phones)

------
jessaustin
Is it weird that the title of TFA is "The Scroll Up Bar" and the title of this
post is "Fixed bars are becoming a new _nightmare_ on mobile"?

------
_cipher_
Simpler solution: every keyboard has a 'Home' button -> MAGIC. ;)

