Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Picking A Mobile Support Strategy For Your Website

The number of people browsing the Web from a mobile device has more than tripled since 20091, and it is sure to continue growing, with browser platforms such as iOS and Android offering mobile browser support that is almost identical to what we have come to expect from a desktop experience. As the mobile consumer market continues to grow, so will the aspirations of individuals and companies who look to embrace what the mobile Web has to offer.

With this in mind, many website owners have begun to develop a strategy for providing information and services to their mobile visitors. However, mobile strategies can vary massively from website to website, depending on what the company wants to offer visitors. For example, eBay’s strategy will be very different from an individual’s strategy for a portfolio website, which might simply be to improve readability for those viewing on a mobile device.

An inverted pyramid demonstrating the increase in support as you invest more time2
Increasing mobile support could lead to a better experience, but at what cost?

So, as website owners define the level of support they aim to provide, a scale of support for mobile devices emerges. Picking where on the scale your website should sit can be quite tricky; each level of support is not without its pros and cons. Let’s take a look at some of the more common approaches:

Further Reading on SmashingMag: Link

Approach A: Tweak What You Have Link

The most basic and, thus, quickest option is to do only what is required to get the website to work on mobile devices. I use the word “work” loosely here because it can be very subjective, but the main goal is to ensure that the website displays and functions properly on mobile devices and perhaps similarly to the desktop experience.

Sure, delivering a desktop experience on a mobile device is not ideal by any stretch of the imagination, but this option simply offers the minimum required to get the website to function and display OK. With modern mobile devices offering good CSS support and zooming functionality, visitors should at least be able to access the information they need.

How to Implement This Approach? Link

Simple tweaks could include adjusting the viewport and text size, which will affect the way the website displays on a mobile device. The default viewport dimensions should work well for most layouts, but we can make adjustments using the meta element:

<meta name="viewport" content="width=device-width" />

Text size can also be adjusted for some mobile devices using the CSS text-size-adjust property which specifies a size adjustment for displaying text content:

html {
-webkit-text-size-adjust: auto; /* Automatically adjusted for Safari on iPhone. */
-ms-text-size-adjust: auto; }

An example of three iPhone screens with text size adjust set to auto, None and 200%7
Different text-size-adjust values demonstrated on the iPhone.

More information on the text-size-adjust property is available in the Safari Developer Library108. With a small number of tweaks, you should be able to optimize your website to appear as usable as the desktop experience.

Be careful when making any adjustments to the CSS for mobile visitors: you do not want desktop users ending up with a 200% font size by default! If you think this might happen or you want to further improve the experience, consider putting the CSS in a separate file:

<link rel="stylesheet" href="…" media="handheld, only screen and (max-device width: 480px)" />


  • Quick to implement;
  • Minimal work required to replicate the desktop design;
  • Strong brand identification with basic consideration for mobile visitors.


  • Mobile users could suffer from a poor experience;
  • Slow due to users downloading styles and large assets;
  • Content and navigation path are not optimized for mobile visitors.

Further Reading Link

Approach B: Adaptive Layout (Media Queries) Link

Media-dependent styling has been around for a long time; you will almost certainly have used “media types” before:

<link rel="stylesheet" href="…" media="print" />

Media queries, on the other hand, have really started to gain popularity since browser vendors began to support the W3C’s CSS3 “Media Queries” specification13.

Most modern browsers, including mobile ones, should now be able to query such things as width, height, device width and height, orientation and more. This has led to more people using media queries to provide responsive designs to their visitors:

Screenshots of the Hicksdesign website, demonstrating adaptive layouts using media queries14
Hicksdesign demonstrates adaptive layouts using media queries.

For older browsers, including Internet Explorer 6 to 8, several solutions are available that add some level of support for media queries, such as Respond.js15 by Scott Jehl.

How to Implement This Approach? Link

We can target specific resolutions and device sizes. For example, we could target mobile devices with a maximum device width of 480 pixels, such as the iPhone:

<link rel="stylesheet" media="only screen and (max-device-width: 480px)" href="mobile.css" />

Or we could put the same media query in our CSS file:

@media only screen and (max-device-width: 480px) {
    // insert styling here…

Adaptive layouts need to work with the content already available on your website. This means that the source order and mark-up can play a vital role in providing a logical order to content when linearized for narrow layouts. You will also need to take into account that images will need to scale to fit as their containing elements adapt to different layouts. One way to achieve this is to specify a maximum width:

img { max-width: 100%; }

You could consider providing the mobile experience as the default and the desktop experience through media queries, an idea discussed by both Luke Wroblewski16 and Peter Gasston17. Combining this approach with something like Adapt.js18 or 320 and up19 could improve performance for mobile visitors.

However, making the mobile experience the default isn’t without its own problems. Always consider your audience, and review visitor data before finalizing your approach.


  • Quick to develop, especially when considered from the start;
  • Cheap to produce because minimal additional design is required;
  • Can result in improved readability and experience for mobile visitors.


  • Older mobile and desktop browsers, including Internet Explorer 8, do not natively support media queries;
  • Visitors could face a short learning curve if the navigation and layout are altered;
  • Rendering could potentially be slower as images and non-critical content in the HTML are being downloaded.

Both approach A and approach B beautifully embrace the “One Web”20 philosophy which sees the Web as one universal medium that should adjust itself to the different environment of its users. Using mobile tweaks and media queries can help to keep the website a standalone, universal entity optimized for both mobile and desktop user experiences. As Jeremy Keith writes in his article,

“Recent developments in areas like performance21 and responsive design22 means that we can realistically pursue that vision of serving up content at a URL to everyone to the best ability of their device. At the same time, the opposite approach—creating multiple, tailored URLs—is currently a popular technique.”

— Jeremy Keith, One Web23

We will discuss the latter approach in the next sections of this article.

Further Reading Link

Approach C: A Dedicated Mobile Website Link

A website dedicated to mobile users aims to deliver an optimized, and often very different, experience to visitors. These micro or mobile websites can take on a life of their own and often require a lot of research and analysis in order to prioritize and deliver the most important content to users.

Mobile websites from the likes of eBay and Amazon show a very different strategy than their desktop equivalents because screen space and file sizes are at a premium.

How to Implement This Approach? Link

A dedicated mobile website will normally reside on its own domain or sub-domain, such as mobile.twitter.com28:

The full and mobile version of Twitter demonstrated on an iPhone29
The main Twitter home page and the mobile version on an iPhone.

Redirecting mobile traffic to a dedicated website ensures that visitors arrive in the right place. But if you do this, provide a link to allow visitors to access to the full version! Also make sure that mobile users are redirected to the correct page when deep linking from another source.

Assets such as images should be kept to a minimum. And popular content, common tasks and key navigational paths should be highlighted to give users exactly what they want. More often than not, there is no room for advertisements in mobile versions.

Despite the extra work, the result can be a faster, more streamlined experience that puts the most important features and content at the user’s fingertips.


  • Greatly improved performance;
  • Optimized paths make it easy and fast for users;
  • Enhances your support of and appeal to growing mobile consumer market.


  • Relatively expensive to build and maintain;
  • Time-consuming because assets must be optimized and content prioritized;
  • Higher learning curve if the layout and content are very different from the desktop versions.

Further Reading Link

Approach X: Native Apps Link

Finally, another option to consider is a native app. Apps can be the ultimate in an optimized, streamlined journey for visitors, and they often have native controls. Several properties, such as eBay, Twitter and Amazon, have clear user goals and have therefore invested time and effort into creating native apps that provide the best possible experience on a wide range of devices.

How to Implement This Approach? Link

A native app should provide the best possible experience for users on the go, while taking full advantage of device-specific features and controls. This approach is very different from the others described, and the project could be considered “ad hoc” development, correlating more closely to the user’s goals than the content or features on your website.

If this appeals to you, consider using an SDK, such as the ones available from PhoneGap and Appcelerator. These SDKs enable developers with a Web background to create applications and tap into native APIs that are not always available in the browser. Native app development can be quite bespoke and is sometimes undertaken parallel to the main website.

Facebook, which offers a native app, is a good example of how a integrated approach can ensure that content is accessible through full, mobile, touch and app versions, each optimized for the best possible experience.

Screen shots demonstrating the full, mobile, touch and app version of Facebook as seen on an iPhone33
Facebook can be accessed through full, mobile, touch and native app interfaces.


  • Streamlined journeys;
  • Device controls are native and optimized for platform in terms of speed and performance;
  • Incredibly lightweight, with minimal bandwidth usage.


  • Requires bespoke development;
  • Creating and maintaining apps for a range of devices is time-consuming;
  • Third-party approval is required before the app is available in stores.

Further Reading Link

Which Approach Is Right For You? Link

Approach A and Approach B offer varying levels of support and often could be considered as a “quick win” strategy. Consider them if you want to improve the experience and optimize readability for mobile visitors at minimal cost.

A strongly related design strategy would be to start with a mobile layout of the website first, having a strong focus on content and navigation and then extend the mobile experience to larger desktop experiences. You can find some interesting workflow techniques for this strategy in Luke Wroblewski’s conference notes of Ethan Marcotte’s talk The Responsive Designer’s Workflow37. For instance, you might need to consider using server-side media queries as well as fluid images in the development process.

Approach C requires considerably more time to develop and maintain but results in a faster, more streamlined website for task-oriented visitors. Approach X requires significantly more time to develop and approval from third-party app stores. But it might be ideal if your brand has many mobile users who expect a flawless experience. The main problem with these two approaches is that they aren’t scalable as new mobile devices might require new versions of the websites which increases costs and makes maintenance more difficult.

Ultimately, your approach should be guided by your content, objectives and visitors. What might work in theory doesn’t necessarily work in practice. A bit of digging in your analytics might show that a large proportion of visitors are on mobile devices, and so the extra time spent improving their experience would be worth it. Once you have all of the data, you can make an informed decision about which approach will benefit you — and more importantly — your visitors.

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37

↑ Back to top Tweet itShare on Facebook

Matt Lawson is a passionate web developer, blogger and mountain bike enthusiast living and working in the beautiful city of Bristol, England.

  1. 1

    yashodhan deshmukh

    July 11, 2011 4:50 am

    This is what I was looking for a long time, thank you, it is realy useful!

  2. 2

    Adam Fellowes

    July 11, 2011 5:06 am

    Also to note option c is built upon all the good work from option a and b as the screen available to the mobile.domain vary considerably so you need the ‘responsiveness’ offered in the previous examples.

    • 3

      Great point Adam!
      As you mentioned, there is no harm in combining these approaches to deliver an experience optimised for your audience.

  3. 4

    Benjamin Ulrich

    July 11, 2011 5:15 am

    Good head-to-head, this, and much appreciated.
    One consideration I always tend to make is to check the content. Options A and B are only really feasible if you’re not “enriching” too much.
    My approcah is normally to focus entriely on what the site is about, make that as simple as possible. Then look into the “extras” that the full shebang is going to have. If that makes the site a lot bigger, then option c is the right way to go. Otherwise, options A and B are more effective.

    Option X comes at rather serious expenses, monstly. Specifically when looking at time investments, licensing, requirements for the various app-stores and different platforms.

  4. 5

    This is a good and honest reading. As i don’t have experience in building pure mobile apps I approach this issue in 2 ways (using Drupal as CMS) :

    (the ‘fast and dirty one’) I created a php parse that gets feed from RSS (xml) from my drupal site and i display it using JQuery Mobile and configured apache to serve this version of the site after sniffing the device type (this can dsiplay any kind of content such as news,blog posts, picture videos etc etc)

    (the painfully slow and well made one) I’m using/customizing/creating a responsive theme for Drupal in order to serve the same content on 4 differents frames (and this one is still a work in progress as should be done in HTML5)

    I guees with Drupal you should be able to create different presets of images (using imagecache ) and serve the correct one based on windows screen dimension saving filesize load (and therefore loading time)

    I suggest also have a look at the abookapart responsive web design yellow book ….

  5. 6

    There are quite a few advocates for ditching native apps, but I don’t agree. There are certainly services where a truly tailored experience are crucial to success, but for sites – not web apps, the whether you want to serve mobile domain or dynamic page layouts I think it comes down to what you can maintain.

  6. 7

    Mike J. Zserdin

    July 11, 2011 6:13 am

    There is so much debate about mobile site vs. app…I think it’s like debating “what’s better a hammer or a saw?” It just depends. You did a great job illustrating the options and use. I would add this, Approach C may or may not be “relatively” expensive based how efficiently a mobile web platform is leveraged. There are a lot out there, ours being (disclosure). It is a challenge getting site owners to realize that they do have another medium to maintain–that being the mobile channel. But, that is where the users are or are heading. New channel, new work, new opportunities to connect with the audience in meaningful ways. Great article.

  7. 8

    Great overview of the available mobile web strategy options. I think this does a good job highlighting what options are available, however I’m surprised to hear that responsive web design is on the “easy” list, especially considering the mobile-first mention. It’s incredibly challenging to meet the needs of users in multiple contexts (mobile, tablets, desktop, tv, with even more to come) from a singular solution. All the tools you mention (Adapt.js, Responsive Images, etc, etc) are fantastic tools, but the real challenge is meeting user goals in the context they are in. These goals can vary from context to context, so please keep that in mind when beginning any project.

    • 9

      Hi Brad, glad you liked the article. The difficulty of each approach is certainly subjective and will depend on the ability of the individual(s) and the project. As you mention, the key is to think/plan for mobile support at the beginning whenever possible. That’s not to say you cannot realign your stategy later, but it certainly help to plan ahead!

  8. 10

    Your search – -ms-text-size-adjust – did not match any documents.

    Even Google hasn’t seen that before. Care to elaborate?

    I actually just found it:

    Microsoft – should’ve figured that out. :) Just find it hard to believe there is no reference to that specific attribute on the web.

    • 11

      Zach Mathews

      July 11, 2011 2:55 pm

      You have to leave off the first “-” or google looks for pages without that string.

  9. 12

    Matt, at the end of your article when you are talking about the responsive designers workflow, you mention server-side media queries. Can you elaborate on what these are and how to use them?

    • 13

      Vitaly Friedman (editor-in-chief of Smashing Magazine)

      July 11, 2011 10:40 am

      Actually, this note was added to the article by our Smashing Editorial Team. You can also use PHP with tools like WURFL to adjust the design depending on the context in which it is being displayed. You can find more information about server-side media queries in Yiibu’s talk: (Slide 57 and onwards).

      • 14

        Brett Jankord

        July 11, 2011 11:16 am

        Ah, I’ve seen Yiibu’s presentation on slideshare. It truly is excellent and answers a lot of the issues when trying to a create a maintainable desktop and mobile site. WURFL is a nice solution, but I think checking against a defined list of devices is limiting when one begins to think about future devices. I think about all the new web capable devices which WURFL does not have in its list and prefer Yibbu’s method of creating a profile of device capabilities, then rendering content based on that information. “Server-side media-queries” do seem like the best method to make sure content is optimized for the view-port but I can’t find much information about them. Thanks for the link to the slide though Vitaly!

      • 15

        Thanks for including this information! I like to see that the Editors are aware of the discussions in their articles. :)

  10. 16


    July 11, 2011 8:55 am

    There is a 4th option, which is to leverage a mobile optimization engine platform that also offers drag and drop interfaces & CMS integration for building and maintaining sites. They also offer the ability to build it once for the highest common denominator and then their engine degrades and optimizes for whatever mobile phone, tablet, kindle, Nintendo DS, Google TV, etc… try to access it. I am not going to promote any here, but licensing, building and hosting will run a little less than building from scratch. And as an FYI the brand you talked about in the intro uses this type of service.

  11. 17

    Daniel Waisberg

    July 11, 2011 10:52 am

    I think website owners should very carefully analyze the data they have available before they choose where to invest. Here is a piece of research on mobile data and how different platforms usually have different conversion rates:

  12. 18

    Excellent article. I work for a large e-commerce company and like Amazon and Ebay we went with Option C. With all the searching and refining of results e-commerce sites require, it just makes sense to optimize the web site so people can find stuff faster (both from a user interface and page weight perspective).

    For something like a blog however, I could see Adaptive Layout being a far better option. Like the author says, it’s all about the content and objectives of the web site.

    Once again, great article.

  13. 19

    Kashif M Qasim

    July 11, 2011 9:20 pm

    Great one! This is what many of us were waiting for :) Keep them coming…

  14. 20

    Payam Rahmani

    July 11, 2011 10:23 pm

    Great article. Thanks.

  15. 21

    Jitendra Vyas

    July 12, 2011 7:47 am

    For Approach B

    Mobile First approach is a good strategy

  16. 22

    Garth Braithwaite

    July 11, 2011 11:38 pm

    I’m a fan of PhoneGap for the html and css to native solution. I also recommend looking at AIR for mobile development.

  17. 23

    Great Article. Very well articulated. :)

  18. 24

    Great article and a great topic.

    Not sure I agree that the adaptive layout is less time consuming than building a dedicated mobile site. With adaptive (“responsive”) layouts you are essentially trying to accommodate every possible device – sometimes writing triple the amount of CSS. Just saying that it isn’t as easy as it first appears.

  19. 25

    This is a wonderful explanation of the different levels of mobile design! This article will come in very handy for me to explain to my boss why we shouldn’t spend the extra money for to design an app. Thanks!!

  20. 26

    Matteo La Rosa

    July 14, 2011 6:15 am

    Thank you so much for this very interesting article! We’re goign to realize a native app for iPhone and Android for our startup, and we evaluated these pros e cons few time ago. BTW we still think our decision for the native app is the best one for us, even if we will be aware of our decision later on when we will improve our web application and then will have to adapt the apps to the improvements.

  21. 27

    Nicole- Designing Signs

    July 15, 2011 11:10 am

    It’s a very Useful article for inexperienced people regarding in new applications, and explains the levels, thanks for extra pages.

  22. 28

    Great article, the rugby stuff as i was going through mobile web technics! But is There a technique to combine “adaptative layout” to Some kind of adaptative content as mobile web does ont always requiers to display the entire content of a large screen website! That would mean managing a website différent versions from a unique backoffice with the advantage of unique URL and adaptative layouts. Any wp plugins or cms that allows this ?

  23. 29

    Thanks for this post, it is very useful.

  24. 30

    Theresa Neil

    July 17, 2012 8:28 pm

    Nice article Greg.

    Here are some more considerations and examples for selecting a mobile solution as part of a larger cross platform strategy:


↑ Back to top