Menu Search
Jump to the content X

Why We Shouldn’t Make Separate Mobile Websites


There has been a long-running war going on over the mobile Web: it can be summarized with the following question: “Is there a mobile Web?” That is, is the mobile device so fundamentally different that you should make different websites for it, or is there only one Web that we access using a variety of different devices? Acclaimed usability pundit Jakob Nielsen thinks that you should make separate mobile websites. I disagree.

Jakob Nielsen, the usability expert, recently published his latest mobile usability guidelines1. He summarizes:

“Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

I disagree (mostly) with the idea that people need different content because they’re using different types of devices.

Firstly, because we’ve been here before, in the early years of this century. Around 2002, the huge UK supermarket chain Tesco launched Tesco Access—a website that was designed so that disabled people could browse the Tesco website and buy groceries that would be delivered to their homes.

It was a great success—heavily stripped down, all server-generated (as in, those days screen readers couldn’t handle much JavaScript) and it was highly usable. One design goal was “to allow customers to purchase an average of 30 items in just 15 minutes from login to checkout.” In fact, from a contemporary report2, (cited by Mike Davis), “many non-disabled customers are switching from the main Tesco site to the Tesco Access site, because they find it easier and faster to use!” It also made Tesco a lot of money3: “Work undertaken by to make their home grocery service more accessible to blind customers has resulted in revenue in excess of £13m per annum, revenue that simply wasn’t available to the company when the website was inaccessible to blind customers.”

However, some blind users weren’t happy. There were special offers on the “normal” Tesco website that weren’t available on the access website. There were advertisements that were similarly unavailable—which was a surprise; whereas most people hate advertisements, here was a community complaining that it wasn’t getting them.

The vital point is that you never know better than your users what content they want. When Nielsen writes that mobile websites should “cut features, to eliminate things that are not core to the mobile use case; [and] cut content, to reduce word count and defer secondary information to secondary pages,” he forgets this fact.

Tesco learned this:4

“We have completely redesigned Access so that it is no longer separate from our main website but is now right at the center of it, enabling our Access customers to enjoy the same features and functionality available on the standard grocery website. As part of this work we have had to retire the old Access website.”

Nielsen writes:

“Build a separate mobile-optimized site (or mobile site) if you can afford it … Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two websites, and cross-linking to make it all work.”

From talking to people in the industry, and from my own experience of leading a dev team, I’ve found that building a separate mobile website is considered to be a cheaper option in some circumstances—there may be time or budgetary constraints. Sometimes teams don’t have another option but creating a separate website due to factors beyond their control.

I believe that this is not ideal, but for many it’s a reality. Re-factoring a whole website with responsive design requires auditing content. And changing a production website with all the attendant risks, then testing the whole website to ensure it works on mobile devices (while introducing no regressions in the desktop website)—all this is a huge task. If the website is powered by a CMS, it’s often cheaper and easier to leave the “desktop website” alone, and implement a parallel URL structure so that is mirrored by, and is mirrored by (with the CMS simply outputting the information into a highly simplified template for the mobile website).

The problem with this approach is Nielsen’s suggestion: “If mobile users arrive at your full website’s URL, auto-redirect them to your mobile website.” The question here is how can you reliably detect mobile browsers in order to redirect them? The fact is: you can’t. Most people attempt to do this with browser sniffing—checking the User Agent string that the browser sends to the server with every request. However, these are easily spoofed in browsers, so they can’t be relied upon, and they don’t tell the truth, anyways5. “Browser sniffing” has a justifiably bad reputation, so is often renamed “device detection” these days, but it’s the same flawed concept.

On mobile, automatically forwards users to a separate mobile website.

More troublesome is that there are literally hundreds of UA strings6 that your detection script needs to be aware of in order to send the visitor to the “right” page. The list is ever-growing, so you need to constantly check and update your detection scripts. And of course, you only know about a new User Agent string after it turns up in your analytics—so there will be a period between the first visitor arriving with an unknown UA and your adding it to your detection scripts (in which visitors will be sent to the wrong website).

Despite all this work to set up a second parallel website, you will still find that some visitors are sent to the wrong place, so here I agree with Nielsen:

“Offer a clear link from your full site to your mobile site for users who end up at the full site despite the redirect … Offer a clear link from your mobile site to your full site for those (few) users who need special features that are found only on the full site.”

Missing out features and content on mobile devices perpetuates the digital divide. As Josh Clark points out7 in his rebuttal:

“First, a growing number of people are using mobile as the only way they access the Web. A pair of studies late last year from Pew and from On Device Research showed that over 25% of people in the US who browse the Web on smartphones almost never use any other platform. That’s north of 11% of adults in the US, or about 25 million people, who only see the Web on small screens. There’s a digital-divide issue here. People who can afford only one screen or internet connection are choosing the phone. If you want to reach them at all, you have to reach them on mobile. We can’t settle for serving such a huge audience a stripped-down experience or force them to swim through a desktop layout in a small screen.”

The number of people only using mobile devices to access the Web is even higher in emerging economies. Why exclude them?

Mobile Usability Link

I also agree with Nielsen when he writes:

“When people access sites using mobile devices, their measured usability is much higher for mobile sites than for full sites.”

But from this he draws the wrong conclusion, that we should continue making special mobile websites. I believe that special mobile websites is like sticking plaster over the problem; we generally shouldn’t have separate mobile websites, anymore than we should have separate screen reader websites. The reason many “full websites” are unusable on mobile phones is because many full websites are unusable on any device. It’s often said that your expenditure rises as your income does, and that the amount of clutter you own expands to fill your house however many times you move to a bigger one. In the same way, website owners have long proved incontinent in keeping desktop websites focussed, simply because they have so much room. This is perfectly illustrated by the xkcd comic:

A Venn diagram showing 'Things on the front page of a university website' and 'Things people go to the site looking for.' Only one item is in the intersection: 'Full name of school.'
A Venn diagram showing “Things on the front page of a university website” and “Things people go to the site looking for.” Only one item is in the intersection: “Full name of school.” Image source: xkcd8.

As I wrote on the website The Pastry Box9 on April 13th:

“The mobile pundits got it right: sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn’t mean that you need to make a separate mobile site from your normal site. If your normal site isn’t minimal, functional, with everything designed to help the user complete a task, it’s time to rethink your whole site.

“And once you’ve done that, serve it to everyone, whatever the device.”

In a previous article, Nielsen wrote in September 2011 that he dropped testing usability with featurephones:

“Our first research found that feature phone usability is so miserable when accessing the Web that we recommend that most companies don’t bother supporting feature phones.

“Empirically, websites see very little traffic from feature phones, partly because people rarely go on the Web when their experience is so bad, and partly because the higher classes of phones have seen a dramatic uplift in market share since our earlier research.”

This is a highly westernized view. Many people can’t afford smartphones, so they use feature phones running proxy browsers (such as Opera Mini), which move the heavy lifting to servers. This is often the only way that underpowered featurephones can browse the Web. Statistics from Opera’s monthly State of the Mobile Web report10 (disclosure: Opera is my employer) shows that lower-end feature phones still dominate the market in Eastern Europe, Africa11 and other emerging economies—see the top 20 handsets worldwide for 201112 that accessed Opera Mini. Since February 2011, the number of unique users of Opera Mini has increased 78.17% and data traffic is up 142.79%13.

A caveat about those statistics: not every user of Opera Mini is a featurephone user in developing countries. They’re widely used on high-end smartphones in the West, too, as we know that they are much faster than built-in browsers, and users really want speed14.

Nielsen’s dismissal of feature phones reminds me of some attitudes to Web accessibility in the early 2000’s. His assertion that companies shouldn’t support feature phones because they see little traffic from feature phones is the classic accessibility chicken and egg situation: we don’t need to bother with making our website accessible, as no-one who visits us needs it. This is analogous to the owner of a restaurant that is up a flight of stairs saying he doesn’t need to add a wheelchair ramp as no-one with a wheelchair ever comes to his restaurant. It’s flawed logic.

Developing Usable Websites For All Devices Link

The W3C Mobile Web best practices15 say:

“One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts.”

There will always be edge cases when separate, mobile-specific websites will be a better user experience, but this shouldn’t be your default when approaching the mobile Web. For a maintainable, future-friendly development methodology, I recommend that your default approach to mobile be to design one website that can adapt to different devices with viewport, Media Queries and other technologies that are often buzzworded “Responsive Design.”

Combining these techniques in a smart way with progressive enhancement allows your content to be viewed on any device (and with richer experiences available on more sophisticated devices), with the possibility of accessing device APIs such as geolocation, or the shiny new getUserMedia for camera access16.

Although many other resources are available, I’ve written “Mobile-friendly: The mobile web optimization guide17” which you’ll hopefully find a useful starting point.

Further Reading Link

(jvb) (il)

In your experience, what kind of “mobile websites” do you create most often?22

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

↑ Back to top Tweet itShare on Facebook

Bruce Lawson evangelises open web technologies for Opera. He co-authored Introducing HTML5, the best-selling book on HTML5 that has just been published in its second edition. He blogs at

  1. 1

    Matthew Lapidus

    April 19, 2012 6:03 pm

    Absolutely wonderful article! Summed up and explained things in a way I have been trying to get across to some high level business owners for a while. And the XKCD Ven Diagram, is a perfectly simple way to illustrate what you do and don’t need! Great Read!

  2. 2

    Why not just detect it via screen size? That’s all I do, redirect based off of a screen size of 320px.

    The only issue I am dealing with now is how to properly set a cookie to allow the user to view the Desktop if they like to.

    • 3

      This is a fundamentally flawed idea. My Galaxy Nexus is a mobile phone but larger than 320px. What about the Galaxy Note? that’s even bigger! The reality is “mobile” in any context is almost meaningless to us and implies nothing of the users context or intent.

      • 4

        @david: I totally agree with this! I’d rather know if the device is a touch screen (fat tap targets, swiping and draging come naturally), a desktop/laptop (precise pointing and clicking), or something else like a tv (most controls are unwieldy and need fat targets or expect arrow movements, user is sitting 10+ feet away) or if the interaction experience is way different than anything else.

        also, many people use their phones while just sitting around and might actually just want to read your long form articles and not get directions or anything related to being on the go.

    • 5

      By no means am I saying that 320 is the solution. I was just shooting an example of changing the site based on the users screen size. Of course mobile screen are not created equally.

      I personally like the idea of creating 2 sites. A mobile user is going to most likely have a different reason to use the website. More often than not mobile users are looking for important information fast. They do not want to be overloaded with useless information which can slow down their ability to find what they want. I haven’t seen this easily accomplished with only a stylesheet and js without causing more headaches then needed. IMO.

      But if they do want to enjoy the entire experience, just give them the option to go to the full version.

      • 6

        So what you’re saying is that its ok to overload desktop users with useless information and slow them down? How about turning things around and actually keep the website simple and to-the-point, so that everyone, no matter the device can find what they’re looking for, quickly?

        • 7

          Most of that “useless information” is stuff that I use on websites. Mobile sites often are missing things I need, so I have to turn off the mobile view in my phone’s settings.

      • 8

        “They do not want to be overloaded with useless information which can slow down their ability to find what they want”, Desktop users don’t want to be slowed down by useless information either.

      • 9


        I can’t believe i need to break this down… What I am saying is the desktop version of a website has much more real estate to work with when it comes to providing a user with information. When it comes to a mobile website, you need to understand the “WHY” for a users visit in a micro sense since you only have a small area to work with.

        Someone that wants to visit an airport website on their phone are most likely doing this to check flight delays, book flights, or modify existing flights. So providing the most useful and commonly tested on-the-go areas the easiest is important. So for some websites this is can be a hassle because their website has tons of extra areas that can be important for some, but will just get in the way for most on the go users. So I am simply saying that its important to look at your audience again in a mobile sense and see whats important and what isn’t. And for some sites having 1 website and modifying the css/js may not be as easy or needed in comparison to creating another version of the website.

        • 10

          You’re making the wrong assumption that desktop users run their browsers in full screen mode. Not sure about others, but I never do that – in fact I rarely have it at more than a third of the screen size, unless some thoughtless web designer forces me to blow it up.

          When I have more screen real estate available that in no way means I want the browser to use that. I have plenty more actually important applications that I want to put there!

          • 11

            I guess I am just not being clear in what I am trying to say. Do a Google Search on “Understanding Mobile Context” and read up about what I am saying about there not being a 1:1 web experience between Desktop and Mobile users. And perhaps I am reading these responses wrong but it sounds like people think that they should have the same exact experience no matter what the device is because apparently the people viewing the website fall under the exact same audience as a desktop user. This I do not agree with, so instead of further trying to put words together to explain why I do not agree with this, please just Google “Understanding Mobile Context” and read up. If you have a account, look into their Mobile Fundamentals course and they have a great chapter video that talks about Mobile Context.

          • 12

            I do notice that we may be talking about 2 separate things though, in a way. The future is with Responsive Design, so yes 1 web works and you can just modify it properly for mobile if you have set up your site to be responsive. Mobile Context still applies here but its all one website.

            I was speaking more in the beginning about website that are older and are not responsive. These types of websites will be much more difficult to convert to mobile which is why I was leaning towards the importance of selecting what to have and what not and how best to approach it. I have recently been converting some of my old website to mobile and I have had the easiest time and most success with making a separate trimmed down website that the full site redirects to. I would love to make these sites responsive but budget is the issue with those clients.

            So I’ll agree to disagree, I agree if the site is responsive and I don’t really agree 100% if the site is not. Fair lol.

        • 13

          *edit, was replying to you Travis but you posted 2 more responses while I typed this, which I think you make yourself clearer. :)

  3. 14

    While I admire the one site different device experience that I get on Smashing magazine’s site from a usability and technical standpoint I don’t think it works for every site out there. Your article pits these two options as fighters in a cage math where only one should be left standing and become the standard across the web. Having worked in a large company that is currently working through its ecommerce and social web mobile solution I can definitely see the benefits of both for different types of sites. Removing content for a mobile version is not always a bad thing and isn’t always done in excess. The point in removing content is to provide a better user experience for the device and most companies really seem to only strip out things that make sense. I also think you’ve given browser detection a bad worse wrap than it deserves. If you have good metrics on the major types of devices requesting your site you can make educated browser detection decisions about when to show mobile that allow the lions share of users to experience the correct view. In general I feel like your article argues that we should build to every possible user instead of playing to 90% of our users and giving them the best experience we can. I can see the benefits of both and it seems like these should be tools we use when making these decisions not standards for everyone. Overall I enjoyed it. Thanks

    • 15

      I kind of agree with you, but if you are cutting “excess” for the mobile site, is the content actually needed at all then. I know clients want to try to explain every single aspect of their company and products, but many are long winded instead of browsable by the human brain.
      If you are cutting excess maybe it is not needed in the first place and maybe then the two sites can be one site just using responsive layout or mobile redirect. If a phone can view 1028px wide then the phone maker has probably pushed too many pixels into a 4.5″ screen.

      Either way. If something needs cut, then maybe it should be cut from the main site as well as the mobile site.

      • 16

        “…if you are cutting “excess” for the mobile site, is the content actually needed at all then?”


        • 17

          …is stupid.
          It’s like saying “Do you really need all the stuff in your big house ? Look, some people have small flats, just a bed a table and two chairs.”

          Why isn’t the iPad just a big iPhone ? Why aren’t the app stores the same ?

          Oh by the way, you have to build two separate websites : one for desktop and one for mobile devices. Unless you love losing your time hiding content, maintening complex javascript, steal the advertisers, send several dozen or hundreds of useless kb to the user, etc.

          iPad example again : apps on the iPad are different from iPhone apps, and they are great. The iPad is a hit.
          Android tablets have “responsive” meh apps and don’t sell well, even if they are cheaper, more powerful, play flash, have usb/sd ports…
          This is the price of responsive design vs finely tailored software.

      • 18

        I never said they were cutting excess content. I said hiding content that isn’t mobile friendly isn’t always done in excess. In general you just can’t fit all of the functionality of a full-site webpage inside a smaller screen, no matter how you design it. It doesn’t mean that content isn’t desired, just lower in the list of priorities.

        It seems like much of this debate boils down to a purist vs practicality debate. Yes, there are costs to whichever approach responsive or not. That doesn’t mean that one approach can’t be done in an elegant way with understanding regarding the limitations of that approach. Not every website is created the same way. You can’t use the same approach in every real world case. Maybe one day far off in the future we can agree on some standard, but my guess is that by the time that is possible the game will have changed again.

        I stick to my argument that both ways can be done well and that both are tools for us to use in this amazing career.

    • 19

      I can’t agree more – it’s about how you do this ultimately and the intent and outcome from a user perspective.

      It’s perfectly possible to use a mixture of techniques and yes – most people should be worrying more about how many % of people can use the device that arrive at their site, rather than whether their UA string detection misses 0.2%.

  4. 20

    Thanks for this article, Bruce

  5. 21

    Great piece! Global usability is often not the priority it should be. A different angle on the subject that should be considered.

  6. 22

    Next time Jakob Nielsen says something, here’s what you do:

    1) Go to his website and look at it.
    2) Ask yourself, “Would I call this person a ‘usability expert’?”
    3) Say the word “no” out loud.
    4) Move along.

    • 23

      The next time “Matthew” says something, here’s what you do:

      1) Does he have anything constructive to add?
      2) Does he understand the difference between pretty and usable?
      3) Does he understand that a person’s website not neccessarily reflects the latest in web design? Similar to how only recently got an overhaul? How one can talk about football without actually being a pro player?
      4) Does he have anything better to offer than Nielssen’s DATA-driven usability research amongst thousands of users and businesses over 2 decades?
      5) Say the words “hell no” out loud.
      6) Move along.

      • 24

        I’m sorry, but nowadays, and probably always, “pretty” does play into usable. You can bother yourself with employing the base necessities of “usability” all day long, like Mr. Nielsen, and end up with a “usable” website that no one actually cares to use. This is, for the most part, a visual medium, and the visual nature of design, print or web, is an inherent part of it’s usability. If you’re creating a website for all, or mostly, disabled users, then by all means, Mr. Nielsen is probably a fantastic resource to base your decisions off of, but for the rest of the real world, employing his concepts in whole, or purely, may make your site “usable” but not a lot of people are going to bother using it.

        • 25

          I absolutely love web design, however you can have the most amazingly designed page on the internet but if it’s unusable and the content sucks, nobody will use your site. However, Google has proven that if your content is top priority and it’s easy to use, it can excel. Look at the most popular websites today… how many of those are what you’d call “pretty”. Not many, if any.

    • 26

      Matthew and his “thumbs up” supporters have an obvious flaw in their “what makes a website usable” knowledge. “Pretty design” can make a website more usable, but it’s not a requirement. There’s a little company called Google that would agree with this.

      • 27

        Google is pretty, unless you’re talking about the most basic of services. Even allows you to insert your own background image, and don’t forget the doodle. Add to that something like Analytics which looks good and was just redesigned by them. I doubt Google would agree that stark usability trumps style. If it did, 90% of the readers here would have careers. We’d all be using Lynx and liking it.

  7. 28

    Thank you for taking the time to consider the usability research and responding to my article.

    There only seems to be one factual error in your article; the rest is a matter of interpretation.

    You write that the reason full sites have low measured usability on mobile devices is that “many full websites are unusable on any device.” While I agree that many websites have lower usability than I would like that’s not the explanation for the research findings. Remember that the statistics show lower task completion rates for full sites on mobile phones than for those sites on desktop computers. So the full sites can actually be used. (Even if they could surely be better.)

    You are right that it’s a Western perspective to stop running usability studies with feature phones. However, the standard rule for all usability research (not just mobile) is to test the environments that paying customers use. We conduct the research to help our clients maximize their conversion rates. If we had a client in Africa, then for sure we would test with different set of devices than what we use to help American, European, and Australian clients maximize their online profits.

    Several thousand people have been to the training courses in mobile usability, and this audience peppers us with questions but they never ask about designing for feature phones (not even when we presented the seminars in China). In fact, in past years when we did cover feature phones in the courses, a lot of people wrote on the feedback forms that we should remove this material to make more time to discuss touchscreen phones. I do listen to audience feedback, so we did what our paying customers requested.

    Returning to the main question as to whether to let the user research determine design guidelines. I continue to believe that this is the best idea. I have been through many cases before, where entrenched billion-dollar interests protested against my usability findings. Just a shortlist: the entire telephony industry protesting that WAP is the Wrong Approach to Portability, the many advertising agencies that conned their clients into using splash screens or other glamour-design during the dot-com bubble, the Flash designers who didn’t like my “99% bad” conclusions, or the PDF lobby disagreeing that “PDF is bad for human consumption.”

    In all of these cases, most people eventually came around to accept the usability findings. In the long term, it’s more profitable to design for users than against them.

  8. 29

    Mike Petrovich at Pixel Chefs

    April 19, 2012 6:52 pm

    I agree with your conclusion, but not quite with the reasons.

    I wholeheartedly agree that a site’s URL should be device agnostic. With the ever-increasing variety of devices today that span the entire continuum from high-powered desktops to midrange tablets to feeble phones, it doesn’t make sense to segregate devices into discrete “desktop” and “mobile” camps.

    However, it’s all about CONTEXT: what you show to a user on a 27″ desktop can be very different from the needs of a mobile user using a 3.5″ touchscreen. The desktop user is typically sitting at home or work and spending relatively long stretches of time interacting with your site in more complex ways. The mobile user typically has additional bandwidth and time constraints but more importantly different objectives in their use.

    Take an airline website, for example. Booking usually occurs closer to the desktop end of the continuum, whereas users near the mobile end are typically more concerned with checking in and verifying the status of their flight. These are potentially inaccurate assumptions, and your analytics data may indicate a different trend. But the point is the same:

    People use different devices in different contexts, and thus their needs in each may be different. Analytics and behavioral tracking data can reveal patterns of use that will identify what content and functionality is important to users in each device context.

    • 30

      Amen. Mobile design needs to consider context first. The airline site is a great example. I’d add that desktop users are quite often multi-tasking, and mobile users are quite often “tapping and going.”

      Of course, good designers don’t assume any of this (as was implied earlier in the comments). They get real users to show them how they need to use the site they are designing.

      Here’s my question though: is there any reason why good, restrained mobile design (and content strategy) can’t be built with proper responsive techniques? From the tone of the articles coming out these days you’d think it’s one or the other.

      • 31

        Context *can* be very important, but how many of you are actually making airline websites? I think the airline site is an overused example and an edge case.

        Studies have shown (check Luke W’s site) that many times people are browsing from their couches. I know I am right now, on a 3.5″ screen. For me right now, the fact that I’m on an iPhone does not translate to me being a hurried businessperson rushing to their destination. It’s just the device I happen to be using.

        We are still figuring this stuff out, but I believe responsive techniques will only improve, and I’m amazed at what is possible even in these early days.

  9. 32

    Bruce: can you please provide concrete examples of sites that:

    * Are mobile optimized. That is; on a 3g connection they are fast to download, and do not waste my bandwidth cap.

    * Looks good on desktop. That is; they are not more than 50% “white space”, or use overly large buttons for no apparent reason than to fill space at the very least. The verge is a good example of a content rich site that looks good. no basic wordpress default look-a-likes.

    * Has all the content you expect on desktop. For example, (large) Thumbnail images, metadata (author time posted, etc), article excerpts, etc. without sacrificing SEO

    * Does not have anything unnecessary on mobile.

    * Functions well in other devices, like the google tv browser for instance. or opera on the wii even! after all, one web also means things other than shouting ‘mobile first’.

    * Supports feature phones. (with stock browsers, which may or may not be opera mini)

    The only site anyone has ever put forth when I ask for specific examples (i note you don’t show any in your article) is the boston globe page. But it’s really simple and plain ( intentionally, it looks like the physical copies of the globe ) so it’s not really a good example.

    Also, how does one target a phone vs a monitor vs a tv, when phone screen densities are increasing so rapidly. after all, you don’t want to display a set of touch optimized css to a netbook, would you? or to a tv.

    • 33

      “Has all the content you expect on desktop. For example, (large) Thumbnail images, metadata (author time posted, etc), article excerpts, etc.”

      ^^ THIS ^^

      Sometimes I really think people are arguing just for the sake of being contrary. OF COURSE we expect a richer experience on a desktop than on mobile. If you expect otherwise, you are in the minority. Some people may want the same on their mobile device as on the desktop, but VERY FEW people want less on the desktop version just to accommodate mobile functionality. The fact that sites may relegate the most useful information to secondary pages does not mean good desktop design is nonexistent.

      I’m working with a website right now that was designed for desktop (but works fine on smartphones) and gives all kinds of information in blocks and columns and fading graphics and embedded YouTube/Map/Calendar and whatnot. But a lot of our users just need access to literature, and they will often be accessing that from mobile devices. So I’m looking to create a version that is only a menu page with over-sized buttons to lead to the literature. Very easy to use on a mobile device, but it will look terrible on a desktop screen. Does anyone want a desktop screen with nothing but 5 big buttons on it? OF COURSE there is a difference.

      On the desktop version there is more information about the products. But for people only wanting the basic information and corresponding literature, this will only serve to clutter up the page. If a customer wants to review the technical guide before a job, is he really interested in complementary products? Unlikely. It doesn’t make the information less important, just less relevant. If he’s perusing the site in his off time, he may very well be interested. So THEN he can view the full site. But in the heat of the moment, if the page takes longer to load or is harder to navigate, is he going to be thankful I was thorough or ticked off because I’m wasting his time?

      So I won’t prevent mobile users from accessing the main site. But to force them to wade through an extra page of thumbnails and block layout seems very anti-mobile-friendly in my book. Whereas, I don’t think anyone with a desktop browser wants to view a page designed for an iPhone browser in portrait mode. Maybe 15 years ago, but not today.

  10. 34

    Pre Priyadarshane

    April 19, 2012 6:02 pm

    Well written argument, but I cordially disagree. There is no right answer to “if a separate mobile site should be created or if the design should be responsive.” The answer to this question is dependent upon the website user’s expectation.

    In most cases, responsive designs make up for a poor user experience since content is not optimized for mobile. Mobile users expect results faster, and want access to content quicker. Content that is written for a desktop user does not accommodate a mobile user at all times.

    For instances where users will take time to go through content and are looking for detailed information, responsive designs are better.

    Though it would be great for businesses and designers to work on one site for all, the unfortunate truth is consumers access content from multiple devices, and the use case generally differs from one device type to another. Content that is optimized for each use case and a solution that addresses your user needs is your best bet.

    As mentioned in the article, it’s always a best to ensure that mobile users do have the capability to switch to full site.

    • 35

      +1 agreed, the tiny mobile version should not load all the graphics and assets of the desktop version. It should load a fraction of the files and file size but make it easy to choose switching to desktop mode to load everything.

      Responsive design is really tough to do well and it especially frustrates me on sites like this. I’m using a smaller external monitor and the ENTIRE screen is taken up by the header and main menu because I’m a few pixels shy of the next media query width. I can only see half of the H1 without scrolling down. I’d rather see the ads in the right column and be able to scan half the article when the page loads or just jump right to the text and photos.

      • 36

        “Mobile users want to see our menu, hours, and delivery number. Desktop users definitely want this 1mb png of someone smiling at a salad.”!/wilto/statuses/63284673723375616

      • 37

        There is a take away here. The top of smashing at a particular width is just stupid, especially on the content pages, the categories could be after the article.

      • 38

        So I work for an IT company, and was assigned to read this article, and I just wanted to say I wholeheartedly agree! I’m not a techie, but I do have a tablet, and I often find myself switching to the regular webpage instead of viewing the mobile website. I am used to seeing the regular websites, and I can’t find the stuff I want on these new websites. It is very frustrating. Plus I don’t really feel they are that much easier to use, so why move everything around and confuse me?

        • 39

          If you cannot find what you want on a website, regardless of whether it is a desktop or mobile version, that is purely down to the way in which that particular site has been structured. I would say that it is far easier to ‘drill-down’ into the required content of mobile sites that I have seen (done).

        • 40

          I think you kinda missing the the point here, yes I too prefer to see a desktop site on a tablet because of the screen size! But sites for mobile users is a must,,, if only for load time! A link to the desktop for further info is a good idea! x

    • 41


      I think everyone involved in the ‘is a separate site bad/good’ argument is kinda missing the point.

      A bloated site like some I see with hundreds of Kb payload on the pages, will just suck, regardless of whether it is a separate site, a responsive design or some new hybrid yet to be invented. It doesn’t matter.

      If you look at a British Airways or other airline App – the best of them don’t remove the soul or content from the web desktop version – they provide a fast, easy way to do tasks in the likely context. I’m not browsing a responsive design and tilting the screen whilst I’m legging it for departures. I think the debate about the transmogrification or not of desktop content focuses on an issue that is NOT THERE for users.

      It’s about how well the site is put together, from a total service and user experience point of view. If you’ve done handset testing, performance testing, tuning, tweaking and design work for a worldwide mobile audience, you’ll know how hard it is to get this right, regardless of which particular approach you take. Hands on practitioners for building this stuff will show you great designs that express the service, content, experience in a way that works well on the device that turns up at your doorstep. It isn’t a factor of separate vs. content integrated sites at all. A lousy experience does not discriminate.

      There – I said it. It’s not about us arguing about it. It’s about them – yes, the people who get slow, cruddy, poorly tested, bloated or irrelevant mobile sites. It’s not enough to single out a particular method and say you like or dislike it so strongly, when there is a bigger issue at stake.

      I also have scant evidence that people care about this. They care about the experience, regardless of how you deliver it. They care that it works on their handsets. They care that it allows them to achieve their tasks or goals. They care whether the contact options suit their budget. They care what your page load time is like. They don’t care if it’s a separate mobile website, as long as it is built for their needs.

      I sometimes look on at this stuff and feel sadness that we devote so much time to debate and little to action. I met a huge group of small businesses in Northern Ireland (SMEs) and their main problem was not knowing how much mobile traffic they had and (b) Not knowing where to start with building something easy to start with and not expensive, for their customers. That to me seems to be a bigger problem than our feelings an opinions on separate mobile sites.

      User agent string detection is a lousy way to do this stuff Bruce – kinda clunky for the reasons you describe. There are plenty of plugins or indeed page level code, which will get you access to Deviceatlas, WURFL or indeed a combination of several techniques. There are PHP, .NET and other server side integrations that take the hassle away from device detection. Bango, our analytics provider, for example – does very detailed featurephone analysis for us worldwide because they use a number of detection and carrier level identification. That’s why they can tell us the phone model, and it’s local marketing brand name. My point here is there are ways to do this better than what you describe.

      Don’t get me wrong here. When I can haul the CMS into shape, I’ll deliver a great experience through a complete re-architecture of content that’s planned. That will give me the ability to do even more than we achieve now with our mobile website & app coverage. The problem for a lot of website owners is that sometimes their IT resource is either busy, slow to change, reluctant to invest or just expensive. The changes that are required to build or design this capability will take some time – in a tough market, you’ve got your work cut out already to price up CMS architecture work.

      So – to sum up. I think the debate has a point – a crux – which is not shared by customers. People care about the experience on their device, not a design methodology. It’s merely a debate about the colour of a bridge, not the underlying architectural merit.

      Secondly, we all need to something to help people design stuff, not patronise or browbeat them. I sometimes feel that an often inward looking debate fails to include the real people here. Those millions of users who get a duff experience.

      I’m a trained UX guy but still fall into the trap of letting ego and opinion bias my decision making. I use listening to customers to keep me grounded. In this debate, I think they’re simply missing.

      • 42

        So enjoyed your response. Especially this part.

        “I also have scant evidence that people care about this. They care about the experience, regardless of how you deliver it. They care that it works on their handsets. They care that it allows them to achieve their tasks or goals. They care whether the contact options suit their budget. They care what your page load time is like. They don’t care if it’s a separate mobile website, as long as it is built for their needs.”

        Thank you for your wisdom and insight regarding this matter.

    • 43

      +1 on Pre’s comment. In my humble opinion, it’s the actual structural markup of your page that will be the ultimate deciding factor on whether you should go responsive or separate.

      Case in point:

      You have a {admin system / stats system}, something with long forms (most of them split into multiple columns), image + file upload functionality, several 100% width flexible tables with several sortable (via js) columns of statistics. You have a dashboard with javascript charts and gauges. Think Google Analytics and subtract some of the complexity.

      Imagine trying to shoehorn this into a mobile version using UA detection / viewport sizes etc. Even if you go modernizr.js crazy, have separate assets (images, CSS, JS) for each device, you still have to deal with the fact that structural markup such as long tables of stats data cannot be viewed on a mobile device in a helpful manner.

      On the other hand, a separate uber-lean version of your HTML with tables abstracted to long lists (sortable / filterable) with it’s own JS / CSS and image assets would be quick to set up, code and manage.

      And of course, let us not forget the fact that many mobile users have data plans: is 6.43kb in size, one order of magnitude less than, which is 76.66kb in size.

    • 44

      I totally agree. Users don’t want to limit their access to just desktops and/or laptops. In todays world people are on the go more and more and they want to be connected at their finger tips.

  11. 45

    Whilst I agree with you Bruce, I would say that browser sniffing is perhaps easier than checking your analytics’ logs for new user agents:

  12. 46

    One of the biggest problems we are facing today is the pragmatic approach most people are taking when facing web design. Rather than figure out what the best practice should be, people are using temporary arguments as motivators to develop best practices.

    Of course one site is better than two separate sites. It’s the only way the industry as a whole can move forward. You debate for hours about speed and loading times, but those arguments are tied to current technologies. While definitely important, they should not be considered when developing your original best practices. They can only be used to deviate from those best practices.

    Why is this important? Because now is the time to develop and fine-tune patterns that will be used in the future. There really is no good reason to emit content for mobile users. Sure you may guess that when I need speed when browsing on my phone, but for all you know I’m sitting on a train and I have all the time in the world to find certain content or to complete a certain action. Stats may indicate this isn’t the case for the majority of users (yet), but what about two or three years from now.

    If we keep looking at today and tomorrow, our industry will remain fickle and juvenile. Best practices should be developed with correctness and future opportunities in mind, only then can you deviate from them because the current standards don’t allow it yet.

    When I find a site doesn’t have the content on mobile (which I know it is there and which I need right now), you just pissed me off royally. That’s what you get for second-guessing people’s “context”.

  13. 47

    To say “we shouldn’t make seperate mobile websites” is founded if you think websites themselves are being created correctly in the first place. This sadly isn’t true.

    HTML5 doesn’t help either, in that it is trying to do what XHTML also couldn’t do with the pros of XML … have one content and have multiple sources style it.

    The information highway is a phrase that isn’t used much any more, but I like to think that a one web approach is only going to work properly, if you can really think of web design as something outside of content. Web design can itself be content if you create web designs of course, but most of the internet (Facebook, Hotmail, Youtube, eBay, Google Docs) is about accessing content … how people get to that varies, through devices and platforms. This is where I think the problem lies … mixing web design (the means in which to access and navigate content) and actual content (that which people want to access and maintain in a central place).

    All platforms are merging and cloud is taking pace for a good reason … we should want and should have one version of content and allow that to be copied/manipulated/shared be others. The appearance and functionality of how we access that content is where there is and perhaps will always be room for differing layouts and designs, but the content itself always has and likely always will need to be presented differently … afterall, we recycle content all the time and people don’t have a problem with that. So why should content look the same on each device!?

    Web designers should either make multiple versions of content to put as much bread on their family’s table as possible, or wait for the day that web design has little to do with content we finally understand that web design itself has been getting in the way of one web.

    I agree with others sentiments that there is alot of interest in getting our work done right, so that people can benefit and that we can make a living at the same time. But as has already been said by others, technology has continued to demonstrate it’s ability to handle and cope with more and more content. If 3D mobile projectors appeared on the market in 2 years time, do you think 1080 video on 2D websites is still overkill for mobile devices!? Those 480px websites are going to adapt pretty badly then, and the whole while desktop resolution websites like Apples have already been accepted on mobile devices, so people have spoken I guess. The only question really, is which is going to make you more money in this industry and my feeling is chasing the multiple versions (that is at least how I approach the issue) even if I feel technology will prove it to be a temporary fix like WAP was.

  14. 48

    I completely agree that mobile sites are a waste of space. I have not visited a mobile website yet where I have not had to switch (or more annoyingly spoof my user agent) to gain access to some content.

    You might be able to argue in theory mobile sites have an accessibility advantage, but real world testing to my mind proves that they are always poorly implemented and maintained. Perhaps it is all down to poor resource management, but this appears unlikely especially as the massive companies cannot do a half decent job.

    I believe the current state of mobile sites is strong evidence for using your resources to make “desktop” sites more mobile friendly and bandwidth conscious than splitting the systems.

  15. 49

    Just a niggling little complaint: you don’t provide a link to the xkcd website, which is part of his license terms.

  16. 51

    Couldn’t. Agree. More.

    Especially with: “you never know better than your users what content they want.”

    Though, I would add “or how they want to view it.” What bothers me about much of the mobile web and responsive web discussion is the idea that we can automatically anticipate how people want to view a website, so can remove that control from them. No, no, and no. The most important part of any mobile website is that link over to the full website, just like the most important part of any “responsive” website is a link to suppress the responsive features.

    Users want and need the two “cons” — content and control. Remove content by offering only the content you arrogantly assume mobile users want, or remove control by arrogantly assuming you know how users want to view that content, and you are delivering frustration to your users.

    • 52

      Douglas Bonneville

      April 20, 2012 5:13 am

      Quote of the Day:

      “The most important part of any mobile website is that link over to the full website…”

      Never was a truer truism spoken :)

  17. 53

    Thank you for bringing up the fact that though RWD may be ideal for many (most?) situations, it is often not the pragmatic choice when you’re dealing with a website that can’t be scrapped and re-architected to be mobile-first RWD at this time.

    As a UX person, I mainly work on websites with thousands of pages, multiple audiences and tasks, and plenty of 3rd party and legacy systems. For one of my clients to “do mobile right” with mobile first and RWD, it’s a massive investment of money and people. From planning to implementation, it can easily take a year or longer to launch if they can even afford it this year.

    So if you can’t redo your web property entirely, what can you do for mobile? I find myself recommending structured content/COPE mobile versions or entirely separate mobile experiences because any thoughtful mobile solution is better than no mobile solution at all if we can’t afford or can’t re-IA, re-design and recode for RWD.

    Plus, it’s funny that no one is mentioning that Nielsen’s article is based off user research conducted somewhere between 2009-2011. How do you do research that includes a technique that doesn’t exist? Or did I miss something?

    And lastly, from these posts here and on .net, I’m hopeful we can take this discussion past coding technique and talk more about what the users of the end product need. Lots of comments and blog posts seem to come back to some tired debates…a few tropes I’ve pointed out here:

    • 54

      It’s actually not completely true that the usability studies were conducted during 2009-2011. We started doing mobile usability studies in 2000. In fact that first report is now available for free download: Even though it’s technically obsolete, there are many interesting observations about user behavior that still hold. That first study is when we concluded that killing time is a killer app for mobile.

      Plus, of course, we continue to run new studies – whether for clients or to update the seminars. I don’t always write about them if they’re confidential or if they simply confirm prior findings with new examples. The new video clips look good in the seminars, but I can’t show them on the website.

  18. 55

    May I post an example where a 2 template approach proves to be advantageous.

    A brochure type site where the full screen is leveraged to showcase the products. The layout is beautiful on desktops and tablets but not functional for a smart phone sized display. The solution was to create a CMS with one content repository and serve it in 2 separate templates. Both templates serve the same content but utilize a layout optimized for the intended audience.

    template 1 ( )
    for desktop and tablets utilizing “responsive” full-screen HD media.

    template 2 ( )
    for touchscreen/smartphone devices utilizing a less resource intensive template.

    You can effortlessly switch between the mobile and desktop experience of every page by replacing “www” with “m” and visa versa.

  19. 56

    Whatever avenue you decide to take, I agree that giving the user an easy wasy to switch to the full version is a must if you’re going to go with a mobile site.

  20. 57

    It really depends on the kind of website we’re designing. And to be honest I disagree with the author of this article, since I personally believe that in a usability point of view, we should always strike for what is better for the user.

    Making a large website responsive will create many usability issues. Making 2 distinct versions with the same “feeling” but with improved usability for each device will most likely win over the responsive option.

    I personally believe that responsive design is good, but mainly for small/medium websites. But take an example of a large marketplace, and you’ll need a mobile version most likely.

  21. 58

    Jose Manuel Estrada Albizu

    April 19, 2012 10:10 pm

    Great article! First at all, I don’t definitely consider myself a world class web developer, mainly because I live in a part of the world when the knowledge is a very hard to hunt prey, regarding the web. However, I found the time to learn from the W3C right immediately I bought my first Microsoft Frontpage Bible (back in 2001) because I refused to believe that web development was such an illogical and tedious work… And then I saw the light! Since then, and within my means, I began to develop web sites built with semantic, valid HTML and CSS.

    Having said that, and based on my own personal experience, I think and I even dare to affirm that separating web content from desktop media in order to make it more coherent on mobile devices is just like the bad and still living habit of having a print version. W3C has proven that there can be always a very intelligent and efficient methodoly to keep working smarter, not harder.

    If you take the time to plan and develop a decent standard-based web site, with accessibility and usability in mind, then it would be probably a great site to browse on any device: faster, valid, accessible, usable, productive and beautiful.

    I’m still far from perfection, but I am very proud of how we (my small web development company in Venezuela) made our company web site (spanish) decently navigable from both desktop and smartphones. Not ready yet for all mobile devices, not much time for a self massage :)

    I would like to invite you guys to visit our company web site from your smartphone or tablet and send or share right here your opinion:

  22. 59

    This article is hilarious. I completely disagree. Usability and UX are important!

  23. 60

    I think this does not make sense:

    “Most people attempt to do this with browser sniffing—checking the User Agent string that the browser sends to the server with every request…”

    How do you know these stats for sure? and if it was that true, then the user who manipulated their browser User Agent is telling strictly that I want to be a different browser and I know the consequences. so why bother and worry for them to detect their devices?

  24. 61

    I think a more moderate approach is needed when deciding if a separate mobile site is right for the particular site. For many sites with simple content (blogs, simpler online shops etc), a full responsive approach makes sense provided you try to optimize your bandwidth requirements accordingly.

    However, for more complicated sites that have complex processes and interactive elements, it makes a lot of sense to try to make a mobile site.

    I don’t follow the philosophy that you should block access to certain parts of your site from mobile users, but it makes sense to make the main tasks in your application easier at the expense of making less important information more difficult to get to, generally by hiding it behind a menu (or some method of progressive disclosure).

    In short, make mobile apps and sites both full-featured, but be sure to optimize their processes. Your methodology for optimizing is probably less important to the end user than it is to your development team.

  25. 62

    All the Nielsen bashers miss a point : Nielsen base his usability guideline on DATA, extensive DATA, not philosophical or theorical bullshit.

    Therefore, he’s right, you’re wrong.

  26. 63

    I think that Jakob’s article is problematic because it mixes a concept with its implementation.

    The idea of a different user interface for mobile and desktop is not a bad idea but the redirects and browser sniffing and seperate pages for mobile and desktop is problematic.

    In his response to comments ( he mentions that the same code could be used for both mobile and desktop designs and transformed with client-side scripting (like jQuery mobile is doing).

    I would think that satisfying both arguments at the same time would be possible and helping users in both spaces.

  27. 64

    “Why we shouldn’t make separate mobile websites” should be changed to “Why we shouldn’t always and only make separate sites.”

    I have to humbly disagree with the core point of this article. In fact, I still defend and prefer mobile sibling sites (MSS from hence forth). I think MSS, for the reasons you say no longer apply, still applies strongly. The mobile experience is just different, and it deserves its own special treatment, its own contextual UI considerations and information architecture. These are things that I don’t feel a rubber-responsive site could always fully satisfy. I think all of what is being taught now about responsive design should be applied; however, to the mobile sites we make.

    To be fair, there are just as many cons against a purely responsive site. Just a few include: too much reliance on media queries and scripting, two things that aren’t universally accessible, mobile-first mentality which may pamper mobile users and make the desktop experience too minimal/bland/limited, responsive sites tend to score horribly on mobile validators and analyzers, etc.

    They’re both viable solutions. And even though it doesn’t sway the opinion of any RWD elitists I know, we just can’t ignore that all the big names still use MSS. Making some sites responsive is just impractical. It may work on a cute blog that relies on simple colors and a few columns that can collapse, but with some very intricate designs, the queries that hide/show scripts would get to be a bit too ridiculous after a while. Whether to go with just RWD or a mobile sibling site should be conditional. Sometimes it’s one, sometimes it’s the other. No need to say one is always and unequivocally bad.

  28. 65

    If you try to debate someones oppinion you should interpretate them correctly. You start by quoting “Good mobile user experience requires a different design than…” – and then you say you disagree that mobile users need different content, and rattle a bit further about the content. But thats not the point you quoted. He says design not content. For the best experience on mobile it needs a different design but can have the same content!

    You can’t detect mobile browsers? Hell yeah you can and besides that there are many other ways

    Furthermore you cant just make a statement like this. It all depends on the project/site. Its too black and white.

    You need to rethink your mind about this

  29. 66

    Great article, well balanced, but I must disagree with all of the statements. It all depends on the context. You cannot strip ALL user experience and content on mobile vs desktop.

    The best example is travel:
    – people use travel websites to book and research – they will consume much more information while researching prior to booking and their cognitive process is quite different than the one when browsing on mobile
    – a research showed that 70% of mobile bookings were made for same-day check-in

    Do you think that the content and the context for these two cases are the same? Can you solve both with “responsive web design”?

    This is a marketers perspective and I would say: don’t try to solve the problem with looking at just one or two cases. In this case mobile website IS the answer.

  30. 67

    I was going to read this article but I realized half way through its been written one hundred times over. Smashing Magazine your content is getting old quick.

  31. 68

    There has been so much hype around responsive design being the solution to all of our problems that I think we have overlooked fundamental issues with this approach. Understandably, when advocates in the development community are warning the masses of the looming “zombie apocalypse of devices”, it then becomes a very attractive proposal; one implementation to work everywhere. Although immediately our concern is mobile, within a couple of years TVs may be more of a mainstream issue, then cars, fridges and who knows what else.

    But how can we develop our websites to work responsively for devices we don’t even know about yet (I’m not just talking about breakpoints)? For devices that we don’t even understand the context (yes, that word again) in which they’ll be used. The more I think about it, the more I think that responsive alone isn’t the ultimate solution everyone is gearing it up to be.

    I just cannot see visitors using a car implemented device that want a full blown website with all it’s company profile waffle. I would imagine again, they’ll probably have similar context to mobile visitors; local, task oriented usage.

    At this stage, I don’t think it’s appropriate to second guess website usability for every use case when we’re moving into the unknown. I’m very much of the opinion that there isn’t always a one size fits all solution, and that it really does depend on the project (and all of the variables that come with it). This may well mean a separate implementation.

  32. 69

    Isaac Weinhausen

    April 20, 2012 12:40 am

    Dear Design Community,

    Let’s be honest friends, this debate between designers that are “for” and “against” responsive design has become a holy war between dogmatic zealots, who have tragically martyred Jakob Nielsen during their march towards battle. Chill out and take a moment to think for yourself.

    Remember what you do: design. Design is not merely a summation of well thought rules and formulas taught by the higher echelon of the intellectual elite; rather, design is a discipline, practiced by you, the designer. It’s always actively thinking about the needs of people in restricted situations. In the words of Kim Goodwin, “Design is the craft of visualizing concrete solution that serve human needs and goals within certain constraints” (Designing for the Digital Age, pg 3).

    You decide. Design the solution, don’t copy. What are the needs of your users in their particular context on their specific device? How can those needs most be most effectively met within the given device capabilities, budget, timeline, and political climate?

    Arguing about blanket design solutions for problems you have minimal insight into is both easy and a waste of time. Instead, exercise your discipline, d-e-s-i-g-n. Be confident in your abilities and understanding of your given problem, do what’s right for your user and client.


    • 70

      Good discussion here, but I believe Isaac sums it up pretty well. There are so many situational factors in web design that you should never take a blanket approach. You should make the best business solution taking into account: purpose of the site, users, content, complexity, cost, etc.

      I say read all the pundits and studies to keep abreast. Then design.

  33. 71

    1) I don’t think I have ever had browser sniffing fail. And if it ever did, it shows the main page. People spoof browsers for a reason. People could also turn off all images if they wanted to. If you are modifying your headers, you deserve whatever it is that you get.

    2) We are usability experts. If something just plain doesn’t work on the small screen it needs to be removed. More, small screens have such limited space. It is clearly a different design and content challenge.

    You might as well say that a print ad and a billboard ad should always have the same content.

  34. 72

    The answer lies in compatibility.

    Both sites serve their purpose for different platform. A mobile site being a sub version of main website is originated to give better readability to accessibility to mobile users.

    As time passes, demand for mobile site gets deeper and we see a lot of interactive web application being embedded into the mobile site instead of main website today.

    However, being a “light” version means too much content is prohibited. Web masters should always provide a link back to main website for users who wanted more detailed information.

    * Please comment if you agree!

  35. 73

    Your article is very convincing at first glance, but ultimately rests on a weak, unexplored assumption. You say, “The reason many “full websites” are unusable on mobile phones is because many full websites are unusable on any device. … website owners have long proved incontinent in keeping desktop websites focussed, simply because they have so much room.” But more room leading to more clutter is hardly a truism. More room makes more clutter *possible* but not mandatory.

    In fact I can turn your argument around: if your website has ten things a user wants (like in the xkcd), which two do you choose at the top of your mobily sleek page, and which eight do you delegate to click or scroll?

    Personally I’d want a separate page on my desktop if only to get rid of the giant tap-friendly buttons that plague almost every website today.

  36. 74

    I’m a developer and I own a development set up with dual monitors, a galaxy tab 10.1 and a galaxy note – recently replacing my galaxy s2.
    Out there in the wild when I try and access the web it can be laughably slow.
    I’d like whatever I browse to be very very small so that it actually loads.
    Back home I connect to wi fi and open up web sites on my tab. Some of them fill a narrow band in the middle of my screen. Apparently it’s a mobile device so I’m only getting a cut down experience like it or not.
    I’d prefer to see a full site.

    Seems to me that there’s an obvious answer.
    A very lightweight home page where I select my preference, saved as a cookie. All other pages to also have some way of setting my preference should I navigate straight to them. Any redirecting being to that super lightweight preference selection screen.

    Unless I’m specifically looking at pictures, I think pictures and graphics generally on a web page are over-rated.
    I don’t really care if buttons have cool looking shading on them, rounded corners or whatever. Rectangular with text is fine.

    • 75

      Good points. It’s too bad that browsers don’t make device and connection type available to developers in a consistent fashion so a website can properly adapt. I like your idea of a user override cookie.

  37. 76

    I work with independents and small businesses. There is absolutely no way that the vast majority of people in small businesses have the time nor the budget to have separate Sites for mobile. For these businesses (which constitute a large proportion of Websites) responsive Sites are ideal in that they don’t have to run two Websites.
    Yes, responsive Sites may not always look perfect but they are generally very cost effective and take less effort to maintain. My feeling is that there are going to be major advances in responsive design (or similar concepts) over the next few years as demand for single Websites that look great on all devices will be massive.

  38. 77

    Thanks for all the comments so far.

    Many have said that there are circumstances in which a separate mobile site is justifiable. I agree; I concluded “There will always be edge cases when separate, mobile-specific websites will be a better user experience, but this shouldn’t be your default when approaching the mobile Web.”

    I appreciate the title of the article doesn’t allow any subtlety, but the title of the article isn’t mine (although I said OK to it once it was live). My title was “Why Jakob Nielsen is wrong about mobile” because he seems to suggest separate sites are always better. I say One Web is *usually* the best place to start,

    Going from top to bottom:

    @Craig Sullivan said:

    “User agent string detection is a lousy way to do this stuff Bruce – kinda clunky for the reasons you describe. There are plenty of plugins .. There are PHP, .NET and other server side integrations that take the hassle away from device detection.”

    Sure – but they’re all comparing the UA string with some database of features. You’re entirely dependant on that database being up-to-date and therefore recognising the UA string and its list of features being accurate. Compare this with client-side feature detection such as Modernizr.

    @Jakob said

    “You are right that it’s a Western perspective to stop running usability studies with feature phones. However, the standard rule for all usability research (not just mobile) is to test the environments that paying customers use.”

    Thanks for the clarification; your rules read like they’re golden rules for all, rather than specific research on specific companies who know exactly where their customers are. (I appreciate you don’t mean them like that, but that’s how people are taking them).

    Hutch asked for examples of good responsive design. I often cite, fixmystreet,com, starbucks, They’re not perfect (what is?) but they show considerable promise.

    Eduardo Santos said “But take an example of a large marketplace, and you’ll need a mobile version most likely.”

    I think that’s because the big sites were the first to see the value of mobile, and making a separate mobile site was the best or only way to do it – or was at least better-performing that just serving the desktop design and content. (That’s why Jakob’s research shows, the “best” sites when viewed on mobile are currently separate mobile sites).

    Many sites that are retrospectively mobilising themselves are using the “separate” site methodology because for many it’s the easier and cheaper way, as I say in the article. For new sites, I believe that you should begin assuming One Web and responsive web design, feature-detection and progressive enhancement. Again, I’m reminded of accessibility; designing with it in mind from the start is an order of magnitude cheaper and easier than retrofitting an existing site.

    • 78

      @Bruce – Hey, if that’s the only small thing to comment on my post, then great

      The UA string is critical for people who do network level redirection, which can be much faster than client side (and works with our Global content distribution network). WURFL and other device databases are updated very regularly – and yes – a small percentage of devices will miss detection initially. You traduce the work of the community if there is any implication this is somehow ‘second best’ – it’s a very good way to do global CDN and traffic shaping. It also saves having to load page code and then redirect people (which is very slow).

      In terms of your comment, you’re just conflating RWD and usability. It’s perfectly possible to have a highly usable, progressively enhanced, device compatible site, running off the same CMS, lightweight, fast and customer focused. I do dislike the mobile separate sites which are based on scrapers or feed but I know plenty that are brilliant and yet live on a separate site (asos, for example).

      Let’s take my mobile sites – the UK one was tested with over 120 handsets and that covered 97% of the visitors we saw in arrival stats. It’s one of the few UK sites to work properly on Blackberries and even lets you transact with us on a 10 year old flip phone. This is a perfect example of a custom site, which happens to live on another domain, that also possesses all the attributes that matter in mobile design – the users. It’s also got maximum device reach – to increase our audience and conversion.

      These mobile sites now generate 20-25% of our revenue in key markets and account for up to 35% of daily visitors. The site also takes revenue in excess of £5M per month. Am I missing anything?

      Choosing separate site does not guarantee success – nor does the flipside you detail. Bad experience simply does not result from the choices you outline – and Jakob and I are agreed on that one for sure.

  39. 79

    Good article, thanks.
    Also The Interactive – Storie di Interazione Quotidiana (the italian blog about interaction design) has covered this topic after the Nielsen article.

    The summary: it depends.

  40. 80

    To be brief, I agree that one should not provide separate mobile webites. I find those who do, usually, unusable. But for those who don’t, I expect at least some form of visitor accomodation. One very important one, which most sites have, is scalability: the ability to enlarge the font to a more comfortable reading size. The page upon which I am now typing does not have this simple trait.

  41. 81

    I wish I had time to read all the comments, I’m sure there are some great ones. I’ll have to follow up later.

    For now I’ll just say that I tend to agree with Bruce. Ultimately it’s about the experience. While devices do create different expectation both the Guest and the brand tend to gravitate to consistency, yes? Is it not possible to create a device independent experience? I believe that it is possible. Easy to do? Initially, probably not. Regardless, it doesn’t strike me as being rocket science.

    FWIW, I had a related discussion with a distinguished colleague a couple months ago. I mention that I was wanting to build a 480 wide site, period. No media queries, etc. One site, 480 wide, all devices. More or less an exercise and experiment to see what was or was not possible. The counter argument came back: “That would be stupid” (direct quote) and “If there’s screen space you should use it” (paraphrased).

    Really? We’re going to fill the screen just because we can, not because we should? Is that progress? Is that how an experience should be defined? If there’s content that doesn’t “belong” on a small screen then how does a larger screen suddenly give it value? Or is it just filling space? And perhaps distracting from the core experience?

    Is there no one else up to Bruce’s challenge (so to speak)?

  42. 82

    While I enjoyed the OP I disagree quite heartily. One of my favorite sites to read on break at work is Smart Planet. The issue I have with them is that they do not pick up that I am on my phone and instead deliver a horrible mobile experience by forcing me to view an otherwise ‘just fine’ desktop page. A large advertisement loads and on PC, I just close it out. The issue being that on mobile you have to wait for the video to load, (there goes a decent amount of data), then zoom in several times in order to confidently hit the close button instead of accidentally opening another browser window. Luckily the advert doesn’t load every time.
    I understand that it would not be so painful if the webdev made the site with both platforms in mind, but both platforms have different needs. I rarely, if ever, surf the web for the sake of surfing on my phone like I do on my pc. On my phone, I have a specific destination in mind and usually only care about one facet of the page. An article or some piece of information only. Everything else on the page is irrelevant to me on that platform. Having two separate platforms with an ability to switch between them at will would provide the best user experience in my opinion.

  43. 83

    There is absolutely no reason to create mobile websites. All modern phones have full-blown web browsers that can view almost any content that desktop browsers can. Concentrate on things that matter, like content and navigation and STOP with the responsive design cr@p already!

  44. 84

    I absolutely agree with you, Bruce. It’s a bit like the old adage, “design for the user, not the designer”. We want mobile websites, so we design them, and assume the user wants those, too.

    Responsive web design makes the most sense because now, we aren’t creating just mobile browsing experiences, but tablet experiences as well. If you go with a mobile site, and do your due-diligence with UA sniffing, how are you going to handle the tablets? They’re bigger than phones, but quite possibly on a cell network. Tablet users don’t appreciate phone-sized websites, I’ve learned.

    I think that there is one thing that has been overlooked though, and that’s responsive content. I certainly think that all content should be available all the time, but the priorities of mobile, tablet, and desktop users may still be different. For that, I don’t see harm in reordering navigation, or selecting certain content to be more visible – so long as the user can get to all the content he or she could through desktop.

    Taking the local restaurant as an example, a mobile user may want the address, a tablet user may want the menu, and the desktop user may want to make a reservation. It’s not about different content, it’s about relevant content. I’d propose using CSS for the responsive design, and then using the Geolocation API and *some* UA sniffing to prioritize what content is displayed.

  45. 85

    This discussion reminds me of two fat ladies waiting at the bus stop by the local New Look:

    “Ooo, you’d look horrible in that Gladis. It’s far too small” says Meredith.
    “But the colours are lovely and look at the styling” says Gladis.

    A UX/UI expert happens to be walking by. She nips in and tries the dress on.

    “Ooo, the cheap tart. You’d have thought she could afford Boden”.

    The point is that who can and should be able to afford either approach depends on every factor under the sun not least of which is the content, budget/ROI and audience – and you can’t always base marketing decisions on user-feedback, or we wouldn’t have iPhones, iPads or even landline telephones. The Countess of Grantham said it best in Downton Abbey when they first got their telephone:

    “Who on Earth are we going to call?”

    Either way, nice article Bruce. And just great to see the great old bore himself replying on here. I’m impressed Jakob.

    For my two cents, I love Drupal’s new Omega responsive theme system and adaptive image module. Works great for clients who want the best of both worlds but can only afford one. Drupal can easily serve two (or more) different front-ends too ensuring a long-term economic advantage to the site-owner – which is another point being somewhat overlooked here.

  46. 86

    Darrell Estabrook

    April 20, 2012 3:57 pm

    This article title assumes a solution without a specific problem.

    While it’s great to have a philosophy on the subject, there is no reason to fall squarely on one side or the other. Why? Because the nature of the business and its users should dictate the technology solution.

    The trouble is website owners want it all–one website which is easy to develop, outputs all the right content to the right devices, and will be easy to use regardless of device. Oh yes, for one low price. Does this mean we don’t try to provide the most efficient, effective solution? No we do try, but it does mean we need to educate website owners on what the trade offs are and be realistic with the effort involved.

    As was mentioned in the author’s comment, above, Starbucks being a good example of responsive design. I would disagree. While Starbucks content portion of the website is responsive and the menus and widgets appear in a reasonable configuration at different sizes, the “web app” portion of their site (i.e. My Account) borders on unusable not to mention visually disjointed because of responsiveness. This is because that portion of the site has moved from a navigation, “consuming” content portion of the site to a task-based portion of the site. There are simply different needs by both the business and the users in this area. To have this part of the site responsive is to sacrifice usability for lower cost of development. It’s a valid business decision, but what does it cost in customer perception? Responsive design is cool, but not a silver bullet–there’s a time and place for it.

    There are certainly technical hurdles, and this isn’t “easy.” Then again, if it were would you really enjoy coming to work each day? :)

  47. 87

    One-size-fits-all solutions are great in their conceptual simplicity, but the domain you set forth does not lend itself to a such a solution.

    “Mobiles” are smart phones and tablets, with screen resolutions typically ranging from 320×240 to 2048×1536 and screen diagonal lengths ranging from less than 3″ to greater than 10″. The issue of resolution differences are a well-understood problem, but screen size is an enormous factor that is often overlooked in this domain.

    For example, the iPad 1/2 screen diagonal length is 9.7″, while the iPhone 4/4s screen diagonal length is 3.5″. They both have similar resolutions, but how this resolution is displayed over a physical area is important. The physical height and width of pixels change per panel, but the physical size of your finger is constant no matter what panel you use. The accuracy of such input relies not only on the accuracy of the digitizer within the device but also on the perception of the person touching the screen.

  48. 88

    How you approach your mobile website really depends on your needs. There’s no such default thinking as “you should build responsive website” or “you should build a separate website for mobile”. It is so pointless to argue, every use case is different. If you want to optimize performance for each device, responsive is not for you; if you don’t have an unique content strategy for mobile, you just want to display the exact same content across all devices, then building a separate mobile website does not make sense. Luke W wrote a really good article on what solution to pick for building your mobile website, everyone should read it through:

  49. 89

    Some of the most popular apps for smart phones are those that bypass the mobile redirect feature and let users view the real site not the mobile one.

    Now why do you think they want to do that?

    Lends more evidence to your argument.

  50. 90

    #1 pet hate: NEVER redirect a mobile user to dump/home page that doesn’t have the same content as the “desktop” link. I’m not going to re-search the info _i just clicked on_…

    #2: as noted have a way to go from both views….
    2b-and _stick_ to it! Don’t ask every page!

    #3: make sure any menus, especially drop downs are usable on mobile.


↑ Back to top