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.
As often happens in times of rapid change, we have no idea what all this really means. What we do know is that at the moment, the solution to our problem appears to be a mobile website (or possibly a responsive one).
But what exactly was the question, again? Is it that same question we asked last year? The one where the answer was to build a native app?
If so, maybe we should reconsider the problems we’re trying to solve.
My name is web design, and I have a problem#section2
They say that the first step to solving any problem is to accept that you have one. If that’s the case, our problem may just be that we still consider the mobile web a separate thing.
Not just separate from the existing web, but different enough that it can be easily quantified as a series of products, capabilities, form factors, or behaviors. This is appealing as it reduces the mobile web to a new “thing” you put on a list (of things to learn, vendors to hire, or budgets to secure).
The reality is, our transition to a primarily portable web will take time, and may involve a collection of sites, apps, and other platforms working in unison to serve our users in ways we can still barely describe. During this time of transition, it’s important to remember the relationship and trust built around our desktop sites.
Users are channel agnostic. They don’t care what site they access (or if they access one at all) they just want to get things done (even if some days “getting things done” actually means watching cats on YouTube).
Getting started#section3
Until a time when all content flows effortlessly from one context to another, users will continue to frequent whichever experience makes sense to them at that time.
- Some will prefer your desktop site as it offers familiarity.
- Others may not find what they need on your mobile site.
- Some may be redirected to the desktop as—ironically—the mobile site doesn’t work on their device.
- Others may access your desktop experience from a tablet-sized device, and choose to do so because (despite poor usability) it still “feels better” than a scaled-up mobile site.
- And many will simply dip in and out, accessing one site or the other depending on which device they have on hand, or which URL someone sends them in a tweet or an email.
The important thing to remember is that—for the foreseeable future—these behaviors are the new normal (except the bit about your mobile site not working on their phone — you need to do something about that).
So why not begin right now, by looking at your desktop site?
If you’re already in the midst of a mobile redesign, these tips will be useful, as they illustrate the many ways that designing for multiple screens, manipulation models, and capabilities should challenge your assumptions about the way you design for the web.
1. Lighten up#section4
Each kilobyte on your site should add value. Period.
And if this logic is good for small portable screens, there’s no reason it shouldn’t be good for larger ones (or any other context where users have to wait while things download).
Users assess value in many ways, so this doesn’t mean serving a lowest common denominator experience to all who visit. It merely reminds us that we can no longer presume to know how much time or bandwidth a user will have.
This realization comes at an inconvenient time given that our sites are now fatter than they’ve ever been. Since 2003, the top 1,000 websites have more than sextupled in size. And in 2011, the average website was a staggering 25% heavier than in 2010.
But page weight isn’t the only issue. Every graphic, style sheet or script causes an http request, reducing the speed at which your site loads. This includes http requests from handy third party services such as analytics, font hosting, ad services, and the many widgets, “Like” buttons, and assorted social objects we liberally sprinkle around our sites.
2. Let them choose#section5
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. Just don’t presume they will stay there. Unless you’ve managed to translate all desktop content, features, and functionality to smaller screens, your users will move from one site to the other—and if they don’t, consider that a sign that one of the sites may not be providing the value you (or they) expected.
When users choose to drift from one site to the other, make it simple for them. Ensure the path is discoverable, and where possible (this is important!) ensure the link to “desktop” or “mobile” doesn’t simply lead everyone back to the home page. If equivalent content doesn’t exist, consider providing a friendly and useful error page that includes suggestions for alternate content.
Remember that the paths users travel indicate the content they want to see. Your can use this data to inform your mobile strategy and ensure the most popular content is available to everyone.
3. Consider the journey#section6
Social media is one of the most common discovery mechanisms for web content. Studies suggest social networks now reach close to 70% of the worldwide internet population. In fact, up to 66% of Europeans log in to social networks every day. A large portion of this traffic comes from mobile. Twitter and Facebook already receive 30–50% of their traffic from portable devices.
Which leads to this all too common scenario:
A user (who happens to be using a mobile device) discovers an awesome product and posts a link to it on Facebook. In the ideal version of this scenario, the user’s friends click the link and access an appropriate product page—regardless of the browser or device they’re using. The product is awesome and some purchase it on-the-spot. Others click a handy “Share Me” link and forward the product to their friends.
Unicorns and ponies frolic. Marketers rejoice. All is well in the world.
This of course is pure fantasy. In reality, when people click that link, this is what happens:
- The mobile URL doesn’t redirect to an equivalent desktop URL, so desktop users are redirected to the desktop home page.
- Some mobile users are also redirected to the home page (because they’re using an “undesirable” browser).
- Some mobile users reach the intended product page (yeah!), but it renders poorly on their device. A small percentage of these users favorite the URL to view it later on their PC (hopefully that URL resolves gracefully once they get there).
- Some mobile users reach the product page, click “Share Me,” take the time to compose a message, but abandon the product when they find the “Share Me” form borked on their device.
- Other mobile users aren’t using a browser at all. They open the link in a web view within a native Facebook app. They reach the correct page but a product video begins to auto-play, crashing the Facebook app.
- Some mobile users reach the intended product page, click “Buy” but can’t get past the login authentication because it’s in a modal window that doesn’t load correctly on their phone.
- And so on.
These problems are common but are far from insurmountable. A bit of awareness, a bit of testing, and some refactoring are often all you need to significantly improve the experience for these users.
Bridge that gap#section7
And remember, sometimes the best solution (interim or otherwise) doesn’t involve the web at all. Some online travel sites have a discoverable “Call us” button for users who need that bit of extra help completing their transaction. The user can trigger the call right from the phone using an easy to recall reference number they can then relay to the agent. Once they complete the transaction, the site can send an email or SMS as confirmation.
Interactions that bridge the gap between online, offline, (and even in-store) transactions map well to the mobile consumer’s changing behaviors. A recent Comscore study of smartphone owners revealed 56% had made mobile purchases at home. Another 42% had purchased items on their devices while out, (at a variety of places including schools, and restaurants, or at work) while 36% had purchased items on their mobile while inside a physical store.
A customer that reviews a product on your mobile site today may do so again tomorrow on the desktop, then may bring their device with them to a physical store to compare prices. The final transaction point could be almost anywhere. Aligning all your experiences—be they online or offline—is therefore crucial. It’s not just about the “mobile web”; it’s about supporting the radical but exciting changes that are taking place in how consumers and businesses interact.
4. Don’t presume#section8
Mobile provides a great opportunity to challenge assumptions—in this case, about mobile itself.
Don’t presume your site works on mobile devices. Patterns designed for the relatively fixed and stable desktop environment can easily fall apart on devices where screen size, capabilities, and manipulation models vary. Each broken pattern creates an opportunity to annoy someone—or in the worst case, completely strand him or her mid-task.
In a recent study, 61% of users said they were unlikely to return to a website that they had trouble accessing on their phone. That’s an awful lot of missed opportunities and if you don’t take the time to test, you have no idea what problems your users may be facing.
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?).
Don’t presume the latest device is the most powerful. Android devices are particularly deceptive. Smaller and cheaper ($60-$100) Android devices are gaining in popularity. Manufacturers differentiate each product by carefully balancing features and materials. One device may have an awesome qwerty keyboard, but a slower CPU. Another may have the latest version of Android, but a less responsive, lower-spec display. Unless you consider their implications, these device characteristics may define the experience far more than you do.
Don’t presume everyone will have a touch screen. While it’s clear we now live in a world full of screens, how we interact with them is still highly variable. Close to 30% of touch devices currently support an additional manipulation method (often a keyboard or trackball). And although many feature phones now sport a touch screen, the arrival of Smart TVs is set to unleash a whole new generation of indirect and proxied manipulation models.
A new group of devices is even emerging with no default display at all.
5. Mobile users don’t do that#section9
With the internet in their pockets, users are no longer compelled to use the web only when a computer and a broadband connection are available. Instead, studies indicate an emerging pattern of frequent, short bursts of web use throughout the day. The length of these sessions vary, and are often related to time of day, user intent, and screen size (tablets being most popular for longer sessions). These new and decidedly varied behaviors clash with the traditional “mobile user” persona—a person who is primarily on the go and would never think of engaging in complex tasks on their device.
For each person who surfs erratically on a smartphone while dodging shoppers at the mall, there is another surfing for three hours on the sofa while watching TV, or while stranded in an airport using Wi-Fi. A growing number of users are also choosing mobile as their primary internet access point.
It’s therefore not surprising that to mobile users, any web content is fair game—even if small screen usability is dreadful. While some users may bail when faced with poor usability, it’s important to remember that those who persist—spending 30 minutes painstakingly completing a travel insurance application on an iPhone—are the very people you want to keep happy. In spite of the pain, they’ve proven they truly want to engage with your brand.
6. Know your materials#section10
Buy some devices. Seriously. Do it now.
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 plenty of reasons why this is unsustainable.
- Desktop browsers cannot help assess your site’s performance (or lack thereof) as they will almost always be more powerful than a mobile counterpart. They are also far more likely to be (auto-)updated so are more likely to reflect the latest features. Some mobile devices, including certain Android devices, cannot be updated at all.
- Modern emulators can get you closer than the desktop browser, as they provide a reasonable facsimile of common screen sizes, and (hopefully) offer the same browser (and browser versions) you will find on a device. They are however equally powerless to convey any hardware or performance related aspects of the experience.
- And lest we forget, most users will experience your content over an operator network. Testing a site on the desktop using (your super-fast) Wi-Fi network won’t reveal the real-life experiences users face with dodgy coffee-shop Wi-Fi, mobile network latency, or operator proxies and transcoders.
Besides—testing on an actual “held in your sweaty palm” device is awesome. Each time you test on a real device, with a real touch screen, real keys, and real user settings—you will learn something. Each thing you learn will help you design, plan, test, and budget more effectively the next time around. With frequent testing, you can also better determine which key browsers or devices are missing from your collection, thereby ensuring each new device purchase is money well spent.
Building a device collection obviously requires a budget, but with a bit of planning there’s lots you can do with even a modest sum. And although it may seem daunting at first, there are clear steps you can take.
I won’t lie and say buying devices is cheap. But they’re becoming a tool of the trade and a cost of doing business—just like that copy of Creative Suite or your Media Temple server.
7. Put content first#section11
In a world where each kilobyte must add value, each piece of content must surely do so as well. Wasting people’s time is no longer an option—users are but a click away from stuff made by someone else.
If it’s not blatantly obvious by now, what keeps the internet humming is content. While we’ve clearly moved past mere consumption, we still spend vast amounts of “online time” exchanging links to social objects such as books, articles, films—and of course, each other. Each day, more and more of these objects will have a presence (if not a permanent home) on the web.
In a post-PC world, it’s therefore hard to imagine a scenario where prioritizing content will not be the key to marketplace relevance. This will include:
- prioritizing content over chrome,
- removing unnecessary clutter and distraction,
- ensuring your content is widely accessible,
- ensuring links resolve gracefully regardless of platform, and
- delivering future-friendly markup that embraces whatever new context or container the world may throw at it.
It may also mean re-evaluating old assumptions about what makes content truly relevant—be it the look and feel, the editorial, the context, the structure, the metadata, or maybe the API.
Start today!#section12
The future may be unpredictable, but the opportunity is too big to pass up. Don’t get caught in the trap of “waiting for the big mobile redesign” to improve the way you engage with your audience on the web.
Creating a future-friendly online presence is not a line item in next year’s budget. It’s not about building a mobile site, or a responsive site. It’s about ensuring the relevance of your communications in an increasingly diverse and demanding environment.
This revolution is at least as big as the last one, and the last one changed everything.
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.
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!
@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).
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)
@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!)
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)
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?
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.
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.
@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.
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
@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 🙂
@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!
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.
@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!
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.
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!
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.
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
“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
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).
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.
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….
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.