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.
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.
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.
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.
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.
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.
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).
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...
Seriously? Pretty sure this has been in iPhone Safari since 1.0 (tap top bar to scroll to top), or at least as long as I can remember. I realize other browsers/platforms may not have this but that's a pretty big one to leave out...
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.
"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.
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...
You can jump to the top of most native iOS scrollable content, including web content in Mobile Safari, by tapping the system bar at the top of the screen
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.
This really depends on the device. iOS devices with their fancy inertial stuff scrolling is very pleasant but if you're using entry level cheap devices, scrolling is not as easy or pleasant. Specially with the new trend of infinite scrolling sites where your scroll down for days...
Yes, most Android devices don't have that feature as far as I know. And it is possibly a bad time to introduce it, because by now users may have already learned that tapping the status bar (on recent Android versions at least) shows the time and date in bigger fonts, as if starting to open the notifications screen.
Infinte scroll works fine on deskop, but is not very useful on mobile devices with a spotty connection.
Though, personally I would like pagination (like Google) back for Facebook, Flickr and also Google Images - scrolling down a few "pages" is just buggy on those sites, and click on the wrong link and you have to go back and scroll all the way down!
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.
I suppose part of what lead to this was browser vendors pretty much eliminating the traditional title bar (by the time you have a dozen tabs open there's room for maybe 7 letters and a 16x16 icon per tab), so websites have had to start supplementing with their own title bars to help users figure out what site they're on.
And the more branding a site uses, the faster I reach for the "Read Now" Readability bookmark.
I realize I'm likely a very small portion of the demographic, by my prior two decades' experience with Web Annoyances tells me that my own sentiments aren't much different from those of the typical Web user, it's just that I'm aware of, and make use of, tools to fix many of the problems.
> I don't get why these bars are being used everywhere
I Blame it on the design patterns of (Twitter) Bootstrap. A lot of sites are put together with it. Although the default nav-bar is not bolted to the top it is easy to read how to do that in the docs and implement it because it seems like a good idea at the time. Others, not using Bootstrap then copy the 'new convention'.
Personally I believe that for some content, e.g. a Tumblr style blog, the nav-bar at the top (and fixed) makes a lot of sense. If you also have pet-peeve infinite scroll (as many do on Tumblr blogs + Pinterest), then it is helpful to have a fixed header as there is no footer.
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
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!
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.
Yes, this is quite a pet peeve of mine. Every other site nowadays seems to do this, even ones that I thought should know better (arstechnica is one that comes to mind)
It is also my pet peeve. It is a big disadvantage, and I haven't ever needed the top bar (or wished it was there when there isn't one) so for me top bars are a feature with negative score.
I guess we spacebarers are a minority and most people use the mouse wheel or the down arrow.
> I guess we spacebarers are a minority and most people use the mouse wheel or the down arrow.
I wondered recently if this doesn't bother other people; but all three of the other developers I sit with said they scroll via mouse/touchpad. One of them said he wasn't even aware of doing it consciously.
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.
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
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.
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).
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.
I've had helpful 'popups' on mobile sites that I couldn't close because the close button was perpetually out of screen, as they were not designed for the small screen. To my surprise, I've seen this on a number of big sites.
It baffles me that nobody ever noticed this bug, but on the other hand I can see how this would happen. The developers probably never noticed because they already had the cookie that prevents the popup from showing. Still...
Well I want to see the image for the article too. We're still figuring all this out anyway. I doubt that as long as people want to show ads on tiny space challenged screens (a very long time), reading news on a phone will suck.
I will also mention that I think having switched to an Android phone with a large screen (the Galaxy S5) has improved this problem for me. The iPhone screen is just too small and Apple really needs to make a larger screen phone because that tiny thing isn't competitive, but I'm a very big person with big hands and big pockets. The S5 is also a very good phone, the plastic casing is weird, but I just put it in a really nice case and I never even notice the cheap materials the thing is made with.
[text]
[image on new line, click to open in new window]
[text continuation]
I don't think the iPhone is too small at all. In comparison to others, yes, but standalone, I don't think so. I use pocket for reading anyways since all my articles are centralized.
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.
This is one reason In am delighted the Galaxy Nexus was abandoned by KitKat. I still have the one more mobile Browser that is capable of rendering text properly.
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.
I'm a fan of how my Windows Phone does it in 8.1 It gives me the option between mobile or desktop identification to sites, but then also gives me the option to use a Readability like function and constrict the content down so I don't have to side scroll. Seems to be the best of both worlds.
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.
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."
My general preference is the format that Readability will render.
Just the damned copy.
If you've got navigation elements, don't cram them into sidebars. Put them at the top of the page (but not fixed), or bottom (dittos).
For a huge number of sites, I disable presentation of headers, footers, and sidebars entirely. I'm not on the sites frequently enough to care to use them.
Some mobile sites do pretty well by removing extraneous elements, others cram in more fixed elements (top, bottom, or side), all of which send me running. There's simply not sufficient real estate to deal with that crap.
Increasingly, Web design isn't the solution, Web design is the problem.
I've suggested gently to the author of this site that he'd do better with balanced left/right margins, a 45em or so content width, semantic markup, and white backgrounds, but he's apparently not interested:
Seriously, when the easiest way to read content is to grab plain text via lynx or w3m, add Markdown, and re-export the page as HTML or PDF, you're doing it wrong.
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!
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.
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.
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!
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.
> 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.
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.
Why would anybody want to enable zoom in the first place? Properly designed mobile web apps should already have decent sized text and graphics. In addition to the iOS orientation bug you mention, there's also that annoying click delay.
A lot of people at StackExchange seem to recommend zooming though:
I may want to zoom to see an image up close, or just to change text size. Outside apple, phone screens vary widely, and so do text sizes. You can't hope to find one that works on all phones for everyone.
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.
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.
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.
> 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.
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.
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.
117 comments
[ 3.2 ms ] story [ 222 ms ] threadI highly recommend to refrain from using position:fixed on mobile devices.
[0] http://remysharp.com/2012/05/24/issues-with-position-fixed-s...
So, the advice not to use position: fixed on mobile may still be good, but iOS isn't the reason why.
http://ux.stackexchange.com/questions/33071/are-breadcrumbs-...
http://ux.stackexchange.com/questions/57990/how-usable-are-s...
Do any mobile browsers have a "return to top of page" function? My keyboard has a "Home" key, my phone does not.
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.
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.
If anything, these bars are worse on devices that have poor scrolling behavior, as I've found they tend to interfere with scrolling.
Though, personally I would like pagination (like Google) back for Facebook, Flickr and also Google Images - scrolling down a few "pages" is just buggy on those sites, and click on the wrong link and you have to go back and scroll all the way down!
I never have any problem remembering that I'm readding HN.
I realize I'm likely a very small portion of the demographic, by my prior two decades' experience with Web Annoyances tells me that my own sentiments aren't much different from those of the typical Web user, it's just that I'm aware of, and make use of, tools to fix many of the problems.
I Blame it on the design patterns of (Twitter) Bootstrap. A lot of sites are put together with it. Although the default nav-bar is not bolted to the top it is easy to read how to do that in the docs and implement it because it seems like a good idea at the time. Others, not using Bootstrap then copy the 'new convention'.
Personally I believe that for some content, e.g. a Tumblr style blog, the nav-bar at the top (and fixed) makes a lot of sense. If you also have pet-peeve infinite scroll (as many do on Tumblr blogs + Pinterest), then it is helpful to have a fixed header as there is no footer.
One place that didn't work is at Forbes.com because they're using CSS to implement that particular annoyance.
I guess we spacebarers are a minority and most people use the mouse wheel or the down arrow.
I wondered recently if this doesn't bother other people; but all three of the other developers I sit with said they scroll via mouse/touchpad. One of them said he wasn't even aware of doing it consciously.
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.
http://consequenceofsound.net/2014/05/stream-robyn-and-royks...
http://www.thewire.com/culture/2014/05/7-eleven-just-killed-...
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 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.
It baffles me that nobody ever noticed this bug, but on the other hand I can see how this would happen. The developers probably never noticed because they already had the cookie that prevents the popup from showing. Still...
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 will also mention that I think having switched to an Android phone with a large screen (the Galaxy S5) has improved this problem for me. The iPhone screen is just too small and Apple really needs to make a larger screen phone because that tiny thing isn't competitive, but I'm a very big person with big hands and big pockets. The S5 is also a very good phone, the plastic casing is weird, but I just put it in a really nice case and I never even notice the cheap materials the thing is made with.
[text] [image on new line, click to open in new window] [text continuation]
I don't think the iPhone is too small at all. In comparison to others, yes, but standalone, I don't think so. I use pocket for reading anyways since all my articles are centralized.
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.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=900564
I explain the feeling a bit more here: http://lelandbatey.com/posts/2014/02/shoot-your-mobile-site/
Just the damned copy.
If you've got navigation elements, don't cram them into sidebars. Put them at the top of the page (but not fixed), or bottom (dittos).
For a huge number of sites, I disable presentation of headers, footers, and sidebars entirely. I'm not on the sites frequently enough to care to use them.
Some mobile sites do pretty well by removing extraneous elements, others cram in more fixed elements (top, bottom, or side), all of which send me running. There's simply not sufficient real estate to deal with that crap.
Increasingly, Web design isn't the solution, Web design is the problem.
I've suggested gently to the author of this site that he'd do better with balanced left/right margins, a 45em or so content width, semantic markup, and white backgrounds, but he's apparently not interested:
http://www.billdietrich.me/Reason/ReasonConsumption.html
Seriously, when the easiest way to read content is to grab plain text via lynx or w3m, add Markdown, and re-export the page as HTML or PDF, you're doing it wrong.
http://redd.it/256lxu
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!
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.
And it's all for functionality I'm not even going to use!
Please just have one site, make it efficient, and be done with it.
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...
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
Yes... user-scalable=no
> From Google IO 2013 session https://www.youtube.com/watch?feature=player_embedded&v=Dujf...
Source: http://stackoverflow.com/a/16910559
A lot of people at StackExchange seem to recommend zooming though:
http://ux.stackexchange.com/questions/19464/should-mobile-op...
http://ux.stackexchange.com/questions/57990/how-usable-are-b...
The HN guidelines ask you not to rewrite titles. Especially please do not rewrite them to make them more controversial.
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.
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.
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.
In fact, the iOS behavior is rather more nuanced:
It's often interesting to see how much consideration Apple puts into small details like this.