Comments on The Best Browser is the One You Have with You

24 Reader Comments

Back to the Article
  1. Nice article, Stephanie.

    Thanks for reminding us “don’t prevent mobile users from accessing your desktop site. If you offer a stand-alone mobile site, it’s perfectly acceptable to detect and redirect mobile users to that URL”. You mention that you can’t rely on people staying there. Absolutely true.

    It’s also important to note that “detecting” mobile devices is nothing more than old-fashioned browser-sniffing, now calling himself “Mr Device Detection” and wearing a shiny suit so you don’t know that he’s done time in jail as “Mr Browser sniffing” for crimes against the Web.

    Detecting a mobile device is simply comparing the User Agent string against a list of known mobile devices’ UA strings. And, of course, as a new device comes on the market approximately every 2 seconds seemingly, the list of “known” mobile devices is *always* out-of-date. Thus, you will send people to the “wrong” URL, which is why it’s vital that they can always choose the other one.

    Copy & paste the code below to embed this comment.
  2. Having your future (and hopefully current) websites be accessible by any mobile device is going to be a design standard soon, if not already. I’m guessing multiple device support will likely be just as important as cross browser compliance…

    Oh the joy of new technology!

    Copy & paste the code below to embed this comment.
  3. Sorry for being a comment slag, but I was interested in the source of the stat “61% of users said they were unlikely to return to a website that they had trouble accessing on their phone” as the article you reference doesn’t have a citation.

    I couldn’t find a 61%, but I did find a similar stat from a Compuware PDF called What Users Want from Mobile and dated July 2011.

    “A bad experience on a mobile website leaves mobile web users much less likely to return to, or recommend, a particular website. Nearly half of mobile web users are unlikely to return to a website that they had trouble accessing from their phone and 57% are unlikely to recommend the site.”

    So not 61%, but a significant number.

    In other words, if you assume your mobile users are coming from WebKit browsers on iPhone/ Android and you penalise them if they aren’t - which is very likely, as Opera [my employer] has a huge market share - then they won’t come back. Better to design for all mobile browsers and test everywhere.

    Another interesting stat from the same research:

    “What is the most common problem you’ve encountered accessing websites
    or applications on your mobile phone?”

    Slow to load: 38%, Crashed/froze received and error: 18%, Formatting made it difficult to read and use: 15%

    From this I’m reading that the biggest problem isn’t line length, fonts, media queries and viewports. It’s speed of loading and site robustness.

    From problem #1, it seems like it might be time to make sites lean and mean - fewer massive JS libraries to do the heavy lifting and more well-crafted HTML?

    Problem #2 suggests to me that a bit of testing sites on the browsers that people actually use would be advisable.

    (Trail for the stat: Searching on the phrase “61% of users are unlikely to return to a mobile site” led me to Google Mobile Ads Blog which cites “Compuware and Brand Anywhere and Luth Research”. As there is another paper by the latter two organisations ( Anywhere Study), a further search unearths the Compuware PDF)

    Copy & paste the code below to embed this comment.
  4. Hi Stephanie,

    Lots of good ideas in your article, and I appreciate all the work you’ve been doing with the “long tail” of mobile (if I can put it that way), and the pragmatic approach you’ve taken to try and meet the needs of a vast group of users.

    However, one thing that has been bugging me a bit in discussions about mobile lately is the sloppy use of statistics that seem to paint a picture of mobile as a bigger deal than it really is.

    For example, your article starts with:

    _"The web as we currently know it (and therefore build it) has primarily been accessed from the desktop. Current trends indicate this is about to change. The ITU predicts that in the next 18—24 months, mobile devices will overtake PCs as the most popular way to access the web. If these predictions come true, very soon the web—and its users—will be mostly mobile.“_

    However the ITU report, which is two years old, actually says:

    _"With current growth rates, web access by people on the move — via laptops and smart mobile devices — is likely to exceed web access from desktop computers within the next five years.“_

    A few points:
    * The ITU is including laptops in its count, while you refer solely to “mobile devices” (which I take to mean mobiles and tablets).
    * The ITU’s predictions from two years ago would still have 36 months to run.
    * The ITU seems to be extrapolating from global mobile subscriptions. If you factor in mobile usage in developing countries, sure, mobile vs desktop PCs is likely to look quite different, but that’s due to the absence of PCs. In the developed world, the PC vs mobile statistics would still be dominated by PC (including laptop) usage.

    And indeed that seems to be the case. If we look at “StatCounter’s mobile vs PC usage in the US”:, we see as of February 2012, mobile usage was just 8.72%. Crucially _recent growth has been flat,_ too. Mobile usage was in the low 8%s in May, June and July 2011, then dipped into the 7%s, and only reappeared in the 8%s in January 2012. Sure, in the longer run growth may continue, but the idea that in 18-24 months mobile usage will exceed 50% seems extremely far fetched.

    Obviously, caveats apply. StatCounter is just one data source, maybe it underreports mobile usage (I don’t know), and as people like to say in web analytics circles, averages can hide the truth. Maybe Company A has a huge amount of mobile traffic, and maybe Company B has hardly any. That’s fine, but if we’re talking in overall terms, the claim that “mobile devices will overtake PCs” to access the web, and that “Current trends indicate this is about to change”, as far as I can tell, doesn’t seem to be supported by the data whatsoever. (In fact, mobile has yet to hit double-digits, and growth seems incremental.) I’d like to think the article could be updated to reflect this.

    Maybe you intended to link to a different press release, or data set, I don’t know, but to me the premise of your article is flawed if this is what it is based on.

    The thing is, I don’t think mobile needs sloppy statistics to make its case—it’s a significant, and growing segment of the audience base for many organisations, and that alone is enough to take it seriously. Plus, many of your tips about reaching older (or newer, slower) devices are valuable regardless of mobile’s size.

    Luke (@lukestevens)

    Copy & paste the code below to embed this comment.
  5. Stephanie, as usual, this is a great piece. Thank you for publishing it.

    I also appreciate your followup on device detection with Bruce.

    As someone who is often cited as a critic of the practice, I think it’s good to clarify the current state of where it’s needed (particularly within Responsive workflows) and why many of us seek alternative means of detection as a preferred approach. These days, I find myself using UA on occasion in piecemeal negotiation situations where a more agnostic means of detection falls short, such as “undetectable”: properties that fail disgracefully in many popular platforms, such as “position: fixed”: and “overflow: auto”:, or even perhaps in use cases that may one day be addressed with flexbox, but currently need some sort of “RESS” workaround on the server.

    In these cases, UA is used as a workaround after all other more agnostic approaches fall short, but even with such restrained use, we’re already seeing — in jQuery Mobile, for example — the massive downside of maintaining these UA workarounds as new devices come out (complete with outdated browser builds or new ones with unexpected quirks): essentially, UA workarounds are crazy hard to do well even by those of us to have been doing this stuff for years and have access to the best device labs in our field.

    It’s for these reasons that I think we need clearer advocacy on how/where to use UA to work around issues today, while not feeling comfortable that its presence in our code is future-friendly.

    Advocating new means of detecting the undetectable properties (like iOS5 and Chrome Android’s -webkit-overflow-scrolling: touch for detecting overflow), and new elements like PICTURE, which remove the need for device detection workarounds for a majority of use cases, are big steps toward alleviating our reliance on UA for standard features.

    To me, it’s not that UA should be discouraged from use — it’s a tool I’d rather not do without when everything else falls short — but 5 years from now, would any of us actually prefer to still need it for the reasons we need it today?

    Copy & paste the code below to embed this comment.
  6. You say we, designers, have to keep in mind that internet can be slow/not there on mobile phones.
    But, where dial-up is removed from the culture and more and more WiFi comes in, why should we keep that in mind?

    As designer, we cant do a thing about that.
    Yes, keep the page small in KB, but i think your worries about slow internet is something like going back to the dial-up-internet 10 years ago. And see where we are now (3G or even 4G everywhere, a lot of free WiFi-hotspots etc).

    The rest of your story makes sense, but isnt that new or refreshing. We designers had always kept our pages small (except the huge amount of Javascript sometimes).
    The thing of less HTTP-calls is a good point, where i did have 10 CSS-files, i grab it now in 1 php-file and give that to the browser.

    I wish there was a good php-script that fetched, compresses and cached the (needed) CSS.

    Copy & paste the code below to embed this comment.
  7. Stephanie, to take you up on this point:

    bq. Don’t presume everyone is using the best or latest device. Always check your analytics. In the UK, a typical site may receive 60% traffic from iOS, with the remaining 40% spread between 70 Android devices and half-a-dozen Blackberries. Also consider that the iOS traffic may include multiple versions of iOS, at least two different screen sizes, differing pixel densities, and greatly varying CPU power (Have you ever tried to run a CSS animation on an iPhone 3G?).

    Design and development for the desktop has always traditionally been about taking into consideration the lowest common denominator, particularly when it comes to browser choice: What happens if somebody views my site using Internet Explorer 6 or 7?.

    But do we really have to worry about this on the mobile platform? The speed of technology change is so fast that what is cutting edge today will very quickly become obsolete.

    Indeed, it may well make commercial sense to only design for the latest devices because in a years time the other manufacturers would have played catchup, and nobody aims to redesign their mobile site annually.

    Copy & paste the code below to embed this comment.
  8. I find it very interesting. After reading your article and seeing your comparison, I think mobile designer or mobile industry should have standard size(pixel) on fonts and features that involves text. But we can’t control that for the competition is so tight! Atleast the mobile designer provides client’s customization.

    — Marlo from “Kids Dentist”:

    Copy & paste the code below to embed this comment.
  9. Thanks for that response. I understand where you are coming from.

    Just another point:

    bq. Buy some devices. Seriously. Do it now.

    bq. We regularly speak to agencies that feel they can plan, design, and build for this new environment based on extensive desktop testing coupled with a few tests on the boss’s iPhone, and an emulator.

    There are a seemingly endless multiplicity of devices on the market. Have you thought about writing an article on what you consider essential devices to test on? An intelligent list won’t be primarily based on popularity but that which demonstrates the spectrum of technology and user experience currently available.

    Copy & paste the code below to embed this comment.
  10. Thanks Stephanie! Great feedback - agreed all around.

    In regards to whether we’ll always be using device detection to work around support for “the next new feature”, I agree it’s unclear and impossible to predict.

    I think one thing in our favor is that at least the browser developers and dev-rels that we’re in touch with are very aware that new features need to be detectable, particularly when their unqualified use is dangerous.

    Many of the features I find most problematic for unqualified use today were first implemented long ago and never really evolved, such as the CSS2 properties I mentioned earlier. As a gross observation, it seems that new features these days tend to arrive with more graceful fallback plans and are often either easy to qualify through detection, or simply apply without worry of negative effect. Or at least, a new HTML or CSS feature might arrive paired with a JavaScript API, giving us several ways to tap in to play it safe.

    The main challenge I see with UA use today is applying it in a way that kills itself off once it’s no longer necessary. With position: fixed, for example, we’re fortunate to be at the stage where almost every major mobile vendor (with the exception of Opera Mini/Mobile as of last check) has a functional position:fixed implementation, so we could write UA logic under the assumption that future versions will as well (fingers crossed). With other properties, it’s not always so clean, but these workarounds are becoming the exception rather than the norm, I think.

    I’d cite as an example of one site that works fairly well in most any browser, and nary a line of device detection is used, yet all sorts of future-ific features are in play (offline browsing, etc). The site could certainly be improved (fewer image requests on big screens, better Ad loading logic, better content loading, etc) with a little server assistance, but it’s encouraging that we’re able to get 90% of the way these days with future-friendly detection methods if we want to.

    Anyway, thanks for the privilege of hijacking your comment stream. Once again, great post - please keep it up!

    Copy & paste the code below to embed this comment.
  11. It is necessary to give special attention to navigation of mobile website
    Phones don’t have mouse but only the small touch screen and the digital keyboard for management. all it does interaction with a site more difficult, rather than on PC.

    Copy & paste the code below to embed this comment.
  12. Thanks for the articles. Actually they are difficult to understand. Tks again.

    “bàn ghế văn phòng”: | “vách ngăn”:

    Copy & paste the code below to embed this comment.
  13. “model railroads”:
    “n scale trains”:

    Copy & paste the code below to embed this comment.
  14. With the explosion of devices and browser variability, our recent projects have all tended to reign in design/UI complexity so that the page will render on nearly any platform without requiring browser detection.

    That said, we still implement specific browser/device sniffer to deliver more targeted experiences (specifically iphone/ipad).

    Copy & paste the code below to embed this comment.
  15. Absolutely true Stephanie. As you said smart phones and pocket devices are next gen devices. Really important point that sites need to be designed for all kind of devices especially handheld because people are moving on to that, a large number.

    Copy & paste the code below to embed this comment.
  16. I think the key point is that the web is becoming divergent.

    On the one hand we are seeing super fast broadband coupled with ever increasing screen sizes which allows for an immersive multi-media experience, and on the other hand the mobile web, typified by lower bandwidth and smaller screens, but arguably greater functionality (phone / text for example).

    And to make it even more complex, all the mobile browsers are doing their best to emulate full blown desktop browsers in terms of rendering capability…

    So where to aim for?

    Myself, whilst I don’t aim for the lowest common denominator (looking at IE6 here), I do aim for several aspects of core web page design, these being:

    1. Functional commonality - use technology that has a high takeup, and allow for fallback (so that would be basic JS, server side processing, CSS3 (with CSS2 fall backs), HTML5 with suitable hacks for non HTML5 browsers)

    2. Page weight - less is definitely more. Whilst a heavy page might look fantastic, even fast broadband users will have contention and latency issues.

    3. HTTP lookups - the less the better.

    For those clients not wanting a specific mobile site, if the above are followed (and tested), the site should be perfectly usable on the majority of mobile browsers (Blackberry’s apart ;-)).

    Also, it’s worth understanding what users use their mobile devices for when browsing. It’s a different user experience on mobile than on a desktop - and people browse different things on mobiles than on desktops. So for example social media sites / news sites etc will be more heavily browsed by mobile, but other, more information intensive sites possibly not.

    But at the end of the day good web design - with a consideration for the user - should always win out.

    Keep up the good work….

    Copy & paste the code below to embed this comment.
  17. An ALMOST perfect piece (and I say such things very rarely). One issue: “Don’t Presume” (Point 4) is not OK.

    You MUST presume ... something(s). That’s your job as a ... (well, now this gets hard to discuss ...)

    As a DESIGNER, you’re right, you can’t presume; you follow a specification. Maybe (let’s hope!) you offer input, and it’s taken seriously.

    As a “closet” (or otherwise) anthropologist, you presume nothing. Your job is to observe.

    As the person responsible for the goal OF the web site, you MUST presume ... something. Let me give you an example:

    At, we now used a design that was created with a specific set of parameters in mind. These parameters include guesses about user behavior, AND about search engine behavior. We PRESUMED that Google, et. al. would react to our design and the placement of content within that design in specific ways. We made the same broad presumption about our visitors, albeit with different goals in mind.

    We HAD TO presume these things. In fact, while the site is broadly identical to what our designer submitted, it was these presumptions that drove the changes we made to her design ... and she and I fought tooth and nail over some things. I won, both because I have that power and because she, as a designer, DESIGNED, without giving thought to many issues beyond the first tenet of our business case ... and of course there are many more.

    She did a magnificent job (although we’re already working our way toward what we’ve starting referring to as Answer Guy Central 3.1). But PRESUMPTION mattered—and we were correct. Google is treating us well, and our average pages per visit have more than doubled.

    Now, onto Part 2:

    Our design ignores “Responsive”. This would be easy to overcome in one of several ways:

    +We could build an App to obviate the need (umm .. you know, if we marketed that app).

    +We could add software to the site that picks out only certain parts of the site to BE us when visited on non-desktop devices (and trust that browsers interpreted that correctly, which they often do not)

    +We could flip on the built-in functionality of our site’s programmatic framework to make the site Responsive—which just isn’t ‘good enough’.

    +We could write new code, at great expense

    +OR, we can PRESUME that the percentage of devices that people visit us on which provide a reasonable facsimile of our desktop made-for-design is growing such that we don’t HAVE TO do anything.

    If you haven’t already visited us using a mobile device to confirm, you can probably guess which choice we’re going with, so far. And I PRESUME that we’ll have to tweak or change that choice at some point moving forward. I also PRESUME we’ll have to do that based at least in part on variables that don’t really exist yet effecting the market.

    Presumption, after all the other tenets of what you’re saying are applied, is the basis for success or failure. Don’t PRESUME? Wrong. You MUST presume.

    Copy & paste the code below to embed this comment.
  18. Sorry, commenting is closed on this article.