The Best Browser is the One You Have with You

by Stephanie Rieger

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. @bruce-lawson Thanks Bruce.
    Misguided use of UA string detection is a certainly a problem, but the reason it’s going to keep happening is that it addresses a real need (the detection bit…not the misguided bit) . The only way to stop it would be to:
    a) ban all standalone (i.e. context-specific) sites ;-P
    b) come up with a more appropriate and accurate means of detection (for those times when you may still need to loosely group similar devices) or
    c) continue educating people about the fact that the benefits of UA sniffing are limited, and that their existing “detection strategy” may be doing more harm than good I would tend to vote for a combination of b) and c).
    Copy & paste the code below to embed this comment.
  4. 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 http://e-commercefacts.com/research/2011/07/what-usrs-want-from-mobil/19986_WhatMobileUsersWant_Wp.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 http://googlemobileads.blogspot.com/2011/11/gomo-helping-businesses-create-mobile.html which cites “Compuware and Brand Anywhere and Luth Research”. As there is another paper by the latter two organisations (http://www.luthresearch.com/Brand Anywhere Study), a further search unearths the Compuware PDF)
    Copy & paste the code below to embed this comment.
  5. @bruce-lawson
    The link to the 61% is right next to the word 61% in the article :-( Is the link not working for you (...have they redirected you to another page because you’re accessing it on a phone?) And you’re totally preaching to the converted regarding problem #1 and #2. The level of bloat is really getting out of hand (and the only thing worse than bloat, is bloat that doesn’t even work on the browser you’ve just served it to!)
    Copy & paste the code below to embed this comment.
  6. 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”:http://gs.statcounter.com/#mobile_vs_desktop-US-monthly-201102-201202, 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. Cheers,
    Luke (@lukestevens)
    Copy & paste the code below to embed this comment.
  7. 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”:https://github.com/Modernizr/Modernizr/wiki/Undetectables properties that fail disgracefully in many popular platforms, such as “position: fixed”:https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.fixedToolbar.js#L28 and “overflow: auto”:https://github.com/filamentgroup/Overthrow/blob/master/overthrow.js#L13, 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.
  8. 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.
  9. 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.
  10. @AndyWalpole Hi Andy,
    I think the biggest problem with an approach that relies on “other manufacturers playing catchup” this is by no means a linear path, with only one possible end result. Let’s say we take a base set of features and call those “modern”. At the moment, the smartphone market place may consists of maybe (random number) 50% modern and 50% who “need to play catch up”. The problem is that by the time the 50% have caught up, the definition of modern will have changed once again (due to Moore’s Law, lower cost of certain materials, progress of web standards, new APIs and different idea around what ‘modern’ means). The second problem is that mobile devices (and to be honest, many other products such as cars, fashion etc.) are designed to suit very specific price points and their featuresets vary a fair bit based on the value proposition and intended price point of each device. Take the Kindle 3 for example. Amazon is selling this device at such a low price point that they’ve had to make decisions around where to focus the bill of materials. In the case of the Kindle, the product focus was obviously on reading books so the browser took a back seat in favour of high battery life, a lightweight device, and a fairly high dpi display. They made sure the browser was however “good enough” as one of the means of buying books is using that same browser on that same device. And although the new Kindle Fire is a much better device, Amazon is still offering the prior model (as a matter of fact they released yet another cheap model when the Fire was released) because their priority is to get one of these readers into the hands of every Amazon customer (to the point where some analysts are suggesting that the base Kindle models may eventually be free with a minimum Amazon purchase). These types of tradeoffs are occurring all the time (especially with Android devices which are being sold at anywhere from £50-£600+) but it’s not always immediately obvious how these changes in materials and overall spec impact web development. For example, the choice of an ARM6 vs ARM7 processor (which has repercussions in overall device cost) can also impact performance to such an extent that web animations and transitions may be unusable. I’m pretty sure we will continue to see this type of diversity…if anything it will get worse as it becomes easier and easier to add internet connectivity to almost any device.
    Copy & paste the code below to embed this comment.
  11. 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”:http://gd4k.com
    Copy & paste the code below to embed this comment.
  12. @Scott Jehl Thanks Scott
    Completely agree that this is currently the primary benefit of UA strings in the dev process. We’re finding that lately, we most often consider using UA detection in regards to Android…in particular the ‘diversity’ in implementation from one OEM to another. I should be clear here that we *consider* using them, but often choose not to. This type of constant tweaking can easily get out of hand and you have to be pretty sure your ‘small’ tweak won’t have crazy unintended consequences somewhere down the chain. What i’m not so sure however is if we will ever be rid of this type of detection. The reason it’s been so persistent (despite tons of industry conversations reprimanding those who use it) is that it’s the ultimate hack. If it were only being used to deal with one or two gaps in spec that would be fine, but it’s such a diverse tool (...unless i’m mistaken, a fair number of large tech-focussed businesses would be in big trouble if the information found in UA strings suddenly disappeared). I also bet 5 years from now someone will release some crazy product we can’t yet even conceive of, and within days someone will be using a UA string to (attempt to) monetize/target/detect/root around it. (Sounds a bit like a chapter in a Cory Doctorow novel :-)
    Copy & paste the code below to embed this comment.
  13. @Luke Stevens
    I totally agree that the ITU statistic is misleading. The original source was I think Mary Meeker during Morgan Stanley’s State of Mobile Internet presentation in 2010 but this number has been re-quoted so many times it’s becoming a bit meaningless. “This article”:http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/ by Om Malik does a pretty good job of outlining the data but the real stats are in the ~100 page “slide deck”:http://www.morganstanley.com/institutional/techresearch/pdfs/Internet_Trends_041210.pdf and accompanying white papers. I’ll be perfectly honest that there are *lots* of crap statistics out there lately when it comes to mobile. This is actually a big pet peeve of mine as I find the industry is being quite stingy with their information. We all know full well that Google, Facebook and many other ‘digital-first’ companies with massive user bases are pouring money into mobile development. Some are even starting to say that the key driver for their businesses is or will be mobile from now on. What none of these businesses are doing is sharing any sort of meaningful mobile usage statistics (“Google’s Our Mobile Planet”:http://www.thinkwithgoogle.com/insights/tools/our-mobile-planet-tool/ site, while lovely is just an excuse to provide lovely charts and sell people on SEO and mobile search advertising). So we are all left scraping around for whatever stats we can find on public sites such as Statcounter (which only release a fraction of their data as well) and the stuff we’ve all seen in our client’s analytics *but can never discuss publicly*. I’ve spoken to many companies who are seeing sustained, month on month growth in mobile traffic (and an average of 100 distinct devices a day). It may not yet be 50%, but it’s often a good 10-20%, and what is freaking them out is how fast it’s growing (some have seen a rise of 10% in less than 6 months). This is backed up by “articles such as these”:http://www.engadget.com/2012/02/07/statcounter-mobile-web-usage-doubling-every-year-nokia-leads-t/ about year on year growth (Statcounter once again…use with caution) and the general trend of more smartphones now shipping per year than PCs. (...sorry, no clickable hyperlink, for some reason this link keeps breaking when I use ALA comment syntax http://www.engadget.com/2012/02/03/canalys-more-smartphones-than-pcs-shipped-in-2011/) What we could all really use is some good industry conversation about *the realistic usage that is going on*, how fast is it really growing (country by country, and within certain verticals like travel where it’s apparently now growing at close to 20% a year), what devices people are actually using (...as opposed to my other favourite misleading statistic which is the number of device shipments). Thanks again for the comment!
    Copy & paste the code below to embed this comment.
  14. 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.
  15. @Andy Hi Andy, my ALA article links to a few good sources for this type of information, although admittedly none of the articles recommends specific devices (Brad’s come the closest by discussing platforms.) What all articles recommend however, which I think is really important is to begin by looking at your analytics (or your clients’) to see what is popular in your region. Unless the site is hugely global in reach, you will get a pretty representative sample from the analytics, and these will often be in line with current top platforms and device shipment numbers. “My article from a few weeks back”:http://stephanierieger.com/strategies-for-choosing-test-devices/ provides a list of steps you can take to turn these initial insights into a list of suitable devices. The key is to *understand why you’ve chosen to test on a particular device/browser/platform*, rather than focus on specific devices because they are currently popular. As I see you’re UK based, here is what i’m currently seeing in regards to UK traffic and popular devices. iPhone/iPad often account for 50% of traffic (or higher). Many people already have one of these for personal use which makes it handy (although sometimes a bit too handy :-)
    The balance is mostly Android (by a long shot) but in this case you will easily see 100s of devices. Look at Google’s platform stats to see what the top platform versions are (2-3 versions account for 90% of the install base), then look for some cheap, popular devices in each of the top platform versions. If your budget permits, make sure you buy one that is cheap (£50-70) and one that is mid-range (>£150). The rationale being that this is what most people are using, and if it works on those, it will likely work on the much more expensive ones. The Huawei Blaze (cheap) and HTC Wildfire (midrange-popular) or HTC Desire (midrange-popular) are usually good choices in the UK. You can find some cheap used devices at CEX (check their website for devices that can be shipped from regional branches) and several other UK sources are mentioned in “this article”:http://tinnedfruit.com/2012/01/11/your-mobile-mileage-may-vary.html And be sure to install Opera Mini and Mobile so that you can test on something other than WebKit (Opera Mini is quite widely used as well so is a great choice regardless). Hope this helps!
    Copy & paste the code below to embed this comment.
  16. Oops…meant to link to this in the last comment:
    “Android platform version”:http://developer.android.com/resources/dashboard/platform-versions.html - regularly updated chart showing distribution of each Android platform version.
    Copy & paste the code below to embed this comment.
  17. 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 BostonGlobe.com 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.
  18. 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.
  19. Thanks for the articles. Actually they are difficult to understand. Tks again. “bàn ghế văn phòng”:http://noithatminhha.com/noi-that-van-phong/ban-ghe-van-phong | “vách ngăn”:http://noithathanoi.net/vach-ngan-phong
    Copy & paste the code below to embed this comment.
  20. “model railroads”:http://www.modeltrainclub.org/model-railroad-info/planning-your-layout-from-day-1.html
    “n scale trains”:http://www.modeltrainclub.org/model-train-videos
    Copy & paste the code below to embed this comment.
  21. 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.
  22. 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.
  23. 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.
  24. 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 http://answerguy.com, 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.