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.
The Scroll Up Bar
71–80 of 118 posts
Re: The Scroll Up Bar
#72Earlier quoted context omitted.
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…
[deleted]
Again, I'll reiterate - scrolling is frictionless.
> Secondly, even if I am changing tasks, that doesn't mean ruining the state I leave in it is an acceptable side effect. Your browser history isn't corrupted when you leave Firefox.
That's a stretch. Ruining? You can still scroll down. The affordances of these actions means, at most, you're going to have to touch the screen once more to "get back to where you were." If you're using an application that doesn't provide the menu after a short swipe, that's a fair enough issue to raise with the implementation of the pattern, not with the pattern itself. It doesn't surprise me that you encountered it on FF Mobile, because FF has a longstanding tradition of ripping things off from successful UIs and getting them wholly wrong in their implementations.
> I can hardly believe the question needs to be asked, but it would be more appropriate to say "what logical sense does it make to bind scrolling to menu actions?" (The answer is none, which is why we didn't have this feature until now, and won't have it for long.)
That's your opinion. Unfortunately for you in this case, it's wrong. Try it on iOS Chrome / Android Chrome or Safari and see how it's done properly before making a sweeping judgment on the interaction pattern itself.
Re: The Scroll Up Bar
#73I 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…
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.
Re: The Scroll Up Bar
#74I don't get why these bars are being used everywhere, personally I find them annoying. Scrolling up takes like half a second...
I disable them in most places by simply turning off Javascript (with the Quick Javascript Switcher chrome extension).
One place that didn't work is at Forbes.com because they're using CSS to implement that particular annoyance.
Re: The Scroll Up Bar
#75FYI one plugin that does that is http://wicky.nillia.ms/headroom.js/
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!
Re: The Scroll Up Bar
#76Someone 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/
[1] 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!)
Re: The Scroll Up Bar
#77Fixed 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.
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 It appears that Amazon is doing this on purpose... Yes... user-scalable=no
> 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...
Re: The Scroll Up Bar
#78Am 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.
The best is when the desktop site fully loads and then some loading page comes up so that it can further load the "mobile experience" and then that "experience" turns out to be a total travesty.
Re: The Scroll Up Bar
#79Am 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.
I completely agree; what's more I find it really ironic that at the birth of the smartphone, Steve Jobs said (paraphrasing) "Great, now we have phones that can view the desktop web! Now we'll never have to write mobile specific sites again."
I explain the feeling a bit more here: http://lelandbatey.com/posts/2014/02/shoot-your-mobile-site/
Re: The Scroll Up Bar
#80Earlier quoted context omitted.
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 It appears that Amazon is doing this on purpose... Yes... user-scalable=no
> 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 exper…
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.