Making mobile mistakes

I started in the web back in 1994. We made a lot of mistakes. Unfortunately I am beginning to see those mistakes repeated in 2011… in mobile development.

I am not sure I like the way some are talking about the mobile web. Its passing through the same awkward adolescence that the web went through.

Like the web itself a few years back, organisations are beginning to pay attention as they see users slowly adopt mobile. They know it will be important but it doesn’t have the levels of usage to justify heavy investment.

At the same time we are seeing web designers jumping on the mobile bandwagon in much the same way print designers did with the web.

This fatal combination is leading to bad advice and half assed solutions.

I see similarities between the emergence of mobile and the emergence of the web itself. These similarities exist in three areas:

1. We can do the web too

I remember how annoying it used to be in the late nineties and early naughties when print designers started offering web design. From their perspective the web was similar to print.

In fact many of their skills were transferable. However, there was also a lot of differences too. The web and print simply were not that much alike.

A print design website that offers web design too

I see the same thing happening with mobile. Many web designers are claiming they can do web too. They try to transfer their skills in web design and applying them to mobile. However this isn’t always the right approach.

I am not saying that web designers should not offer mobile (after all we do at Headscape). We just need to be careful we understand the mobile web before we start offering solutions that might ‘do the job’ now, but be wholly inadequate as we learn more about the medium.

I would argue it is not adequate to simply load a mobile stylesheet or have a responsive design. That brings me to the next similarity I see with days gone by.

2. We can just reuse…

Back in the early days of the web clients would talk about ‘putting their brochure online’. They wanted to replicate the print work they already had. They wanted the same words, same design, same everything.

What worries me is that I see clients and web designers having the same conversation today. The ‘one web’ brigade talk about delivering the same content to a mobile device and a desktop computer. Clients are asking for their ‘existing site‘ to work on mobile devices. Neither group seems to be considering whether users need the same content on both the web and mobile.

When it comes to the mobile web, context is king. What content we should be delivering is entirely reliant on the context the user is in. Take for example the Headscape website. Users are unlikely to want to view our portfolio on the small screen of a smartphone. However, they might want to get directions to our office or our phone number if they get lost.

Person accessing the web on a train using an iphone

A mobile device plays a different role to a desktop computer. We cannot simply ‘skin’ our existing website and expect that to be sufficient.

The last similarity I see between the emergence of the web and the emergence of mobile is ‘device specific development’.

3. This site/app only works in…

Those of us who have been working on the web for sometime joke about ‘the browser wars‘. This was a period of time when browser manufacturers would compete for market share by releasing their own proprietary tags that could be used by web designers. The casualties of this war were users who would often arrive at a website to be greeted by a message telling them that the site would only work in a particular browser (normally Internet Explorer).

Web designers were also a casualty of this war. They were sometimes expected to design their client’s website multiple times for different browsers. Finally the client suffered because they had to finance this reworking for different browsers.

I look at the mobile space at the moment and see much the same thing happening. Organisations are releasing iPhone and iPad apps, Android apps, and even Windows Mobile apps. Each device has its own unique functionality that the developer can call upon and so each provides a different experience.

Image of different mobile platforms

Once again everybody suffers. Users suffer when their particular platform does not have the cool apps found on another platform. Developers suffer because they have to recode for each platform and clients are left footing the bill.

One answer to this problem would be to build web based apps rather than native apps. In fact Bruce Lawson gave a great talk at SXSW explaining just how much is possible without the need for running a local app. This would open up the possibilities of building once for all mobile platforms and use progressive enhancement to provide the best experience possible to each device.

From the cloud to the device and back again

At the moment the big drawback of web based mobile apps is speed and connectivity. Web based mobile apps are slow compared to their native cousins. What is more in many situations there can be no connectivity at all. At the moment at least, native apps look like the better option and we will all have to deal with the potential downsides.

That said, I think mobile will reflect the evolution of the web. For a long time software ran on our local machines. However, more recently we have seen a move to the web. This has happened because of broadband. That ‘always on’ high speed connection has allowed an explosion of cloud based apps. While the mobile web moves native the desktop app is moving to the cloud. I suspect therefore that when mobile devices also offer ‘always on’ high speed connections we will see a move back to cloud based apps. They will be cheaper to develop and run across more devices without the need to recode.


Of course these are all guesses. However, as I look at the development of the mobile space I am quietly confident that the future is rosy. I think we will learn from the mistakes made on the web itself and come out of the other end able to produce cheap, effective and usable mobile sites that are a lot more than a reformatted version of the website.


Those that argue mobile is an extension of traditional websites are in my opinion wrong. However, I equally believe that those who say the future is ultimately native are also wrong. I believe that the future lies with custom designed mobile websites that are cloud based. However, I think we will need to pass through the native app stage until the mobile networks can provide better quality universal connectivity.

But hey what do I know. That is just my opinion. Let me know what you think in the comments.


I have had some great feedback from some very smart people (see the comments below) and that has helped me clarify my thinking. I posted a short audio post where I explain that I believe wholeheartedly in the idea of providing all users with the same content but that I think the emphasis of that context needs to change based on the possible context the user is in. Admittedly we cannot know for definite what the context is based on the device but we can take an educated guess and provide those users with an optimised solution while not removing content from others that don’t meet with that assumption.


If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.

Book a consultancy clinic or contact Rob about a more in-depth review.

  • Now, over to Mr Jeremy Keith..

  • I must admit I’m a little surprised to see this post on this site. Admittedly, I tend to align with the “one-web” camp on this debate. Not just because I’ve been doing a lot of “responsive” work lately and seen very real benefits, but also because almost every day I find myself searching for the “View desktop website” link just to find the content that I really want because some website decided I’m probably looking for directions, or a log-in screen.

    How can we make such specific assumptions about what a person wants to see based on the browser or device they’re using? Personally, if I visit Headscape, I’m almost definitely looking for your portfolio (I’m a designer), and I’m just as likely to be browsing on my iPhone as I am on my laptop. In fact, I’m probably laying in bed reading my news feeds on my iPhone, in the US, where directions or phone listings for your offices are my last priority.

    Point #3 seems to work against your argument that separate sites is the answer to achieving proper contextual experiences. Isn’t building a separate site for different browsers (regardless of the device on which they’re installed) exactly the mistake we’re hoping to avoid repeating?

    Mobile is of course a very new area of focus, but it’s hard to deny that users are becoming annoyed with mobile lockout. I think most often, it’s not that users don’t want the content on the desktop site, they just don’t want that content formatted in a way that’s annoying to use. Through CSS and JavaScript, we have the tools to make our presentation and behavior highly contextual. Content is still king. Maybe context can be queen…?

    • I certainly share your frustration with some of the implementations of mobile sites found currently. However, that does not mean we should just throw everything at our mobile sites without making any distinction between the devices. We make decisions all of the time about what to be put online and what to leave off. We need to make those same decisions for the mobile web. Just because some make the wrong decisions does not mean we should not make judgements at all.

      Even if we do conclude that the website and the mobile site should have the same content that does not mean the sites should have the same emphasis. Some content is going to be more important on the mobile site than the website. The IA will be different, hell even the way the copy is written should often be different. Just throwing a different stylesheet at the problem is not the solution.

      Don’t get me wrong, I think responsive design has its place especially at the moment when clients cannot justify the expenditure of a mobile website. However, I dont see this as the best solution.

      As for your feeling that my third point goes against my argument I would suggest that things are not black and white. Yes it is much neater to suggest we should avoid building separate sites for different devices. However, I believe that unlike the browser wars these separate sites have different context, different business objectives and in some cases even different audiences. Those differences mean you cannot treat them simply as the same site delivered to different devices.

  • I’m with Scott. Content will win out simply because it already has context within the design (assuming the site is well-designed).

    The key is to have appropriate content in the first place. If I go to Headscape’s website and I’m looking for directions, I’ll just scroll down to your footer, where I would expect a link to your contact or directions page, no matter what device I’m on.

    Not to mention “one web” sites with mobile stylesheets built in are significantly cheaper and easier to maintain than having to build a separate native app.

    It’s not problem-free (large images and multimedia are a burden on mobile networks), but it’s the path of least resistance.

    • I 100% agree with the cheaper thing and as I said in the post I think it is often the best solution right now. However, I am not sure that will be enough long term.

  • I feel like most arguments against responsive design are based on the vague sense that we’ll eventually figure out what every user wants: tablet browsers will want a menu; phone browsers will want a phone number. And while we could likely refine that approach to cover the lion’s share of users, a truly iterative (albiet impossible) approach—wherein each of the site’s users sends us thoughtful feedback on the experience—would have us eventually adding almost every aspect of the “desktop site” back to the mobile site.

    As a quick example: when I first read this from my iPhone, I was unable to view the comments. Maybe they didn’t exist? They probably did, though, so I went looking for them.

    After clicking through to the full site, I was able to read and post comments, but not in a particularly mobile-friendly way. As a savvy user, I sought the comments out. I’m then left wondering why it was made so much more difficult for me—why weren’t the comments on the mobile site? It wouldn’t be that hard, or add much weight to the page. They could even be collapsed somehow, to prevent visual clutter. As a non-savvy user, I’ve immediately lost interest and gone to look up a hilarious picture of a cat.

    This isn’t my roundabout way of saying “add comments to the mobile site,” it’s my roundabout way of saying this: from a design, development, and—to some extent—a content-centric standpoint, I can absolutely understand the assumption that comments are a non-essential part of the post. But it’s exactly that: an assumption.

    • I agree Mat. However that should not be an excuse to dump everything on the site as this is also an assumption users want everything and can navigate through it all. Instead we should talk to users and watch their behaviour to find out what they really need.

      As for the lack of comments, that is just laziness on my part. Nothing to do with an assumption of any kind :)

  • ben

    For nearly ten years, I’ve followed what I call the Interrogative Method of gathering requirements:

    Who? What? Where? Why? When? How?

    There is nothing wrong with that work order requesting a mobile port (be it in the form of a restructured site or a new batch of stylesheets)…

    …If the site was designed properly in the first place.

    We’re not stuck in 1998 with respect to mobile design and implemtnation… I too often find myself stuck in 1998 with respect to the entire gig, because we still haven’t sold the critical skill of being able to appreciate how a given batch of content can be displayed within a given medium or canvas.

    “Responsive Design” and demos thereof might help someday, if decisionmakers ever learn to grasp what they’re looking at when we show it to them.

    Until then… as always… the first task is to convince the stakeholders to stand back and let us do our jobs. The battle cries of the crusade against Bad Design Paradigms are only so much cacophony in the meantime.

    • Greg Givan

      Your last paragraph is…perfect.

  • I am hoping to see a shift within the web design community towards the view that ‘content and context are king’. Rather than designing something scrumptious in Photoshop for client sign off we should be looking at the content first and foremost. Then with what content we have we should be working out what device needs it which would be dependant on (the likelihood) of what the context is.

    Irregardless of the technology used.

    I feel that a great example is the pizza express website. On a mobile device (let’s say the iPhone) it allows you to find a close by restaurant and then provide you with the contact number as well as a menu. If I was visiting pizza express’s website on my iPhone that’s all I’ll need. It’s the correct content in the context it is being viewed in.

    I’ve rambled about this some more here –

  • I would tend to agree with Matt and Scott. We’ve been doing some informal research of people’s impressions of ‘mobile web sites’. The most common comment seems to be that people want all the content and all the functionality (but with a more appropriate layout of course). Of course there are reasons why all the content and functionality may not be a good idea but the crux of the issue is that there is no “mobile context”. There used to be (and you will find the few books on mobile design agree on what that entailed) but it’s rapidly being turned on its head.

    The challenge is to sort out what this means from a design/content/functionality/implementation point of view (I will be talking about this at the Breaking Development mobile web conference ( in Dallas next month…remains to be seen what I will actually conclude… if anything :-P

    As for responsive design, it’s just one part of the solution. Even if you serve slightly different content/markup, you will still need responsiveness at the core of your design to account for the diversity in screen sizes (not to mention orientation changes).

    A bit more of our thoughts on the changing mobile context can be found here…if anyone is interested

  • Asher Webb

    Thanks for the insight here. I think even beyond stakeholders and clients there is an important battle going on as to how developers deploy mobile sites/apps. The idea of standards — which harken back to the browser wars — is very important. If we can deploy mobile web apps that are as responsive as native web apps than we can develop 1 time for a variety of devices. However, as Google has recently noted, end users prefer native apps. “Swimming in a stream of millions of apps” is a fad that will surely die. If not we will be left with a proprietary mobile universe owned and dominated by iOS, Android and perhaps WinPhone 7. When we look at all the ways the web has impacted the world because of the freedom that comes along with open source I think it is important we don’t enslave ourselves designing for closed systems — and in the process give 1/3 of our livelihood to multi-billion dollar conglomerates because they “supply us with the marketing chanel.” I don’t buy into this. As developers I feel it is our responsibility to our profession to promote web-based mobile apps.

  • @Stu Robson I’d like to be able to be able to “find a close by restaurant and then provide you with the contact number as well as a menu” from the desktop version of the site rather than be bombarded with all that other crap they have on there. As it’s been said many times before, starting with the mobile design forces clarity.

  • Very well written article Paul! My assumption is that Paul is referring to enterprise / medium sized industries with this post. (where budget isn’t much of a factor) However as mentioned small business would tend to benefit from responsive design due to budget limitations.

  • I’m still waiting for the silver bullet with regards “the mobile web”. Each of the main methods for me seem to have at least one major drawback; be it compatibility of media queries, duplicate data/apps, browser sniffing or making user assumptions.

    As Cameron Moll wrote in his book “Mobile Web Design” back in 2007 – perhaps it’s best to do nothing and let the browser/mobile developers figure things out?

    I agree with Paul though. Context should be a definite consideration.

  • heffe

    Great article. I think that while web based mobile sites tend to be slower and more simple than native apps they usually get the job done.

    As a mobile web user I usually want short bits of information and easy navigation. I think that ESPN has a great mobile site for the amount of content they have.

    Often times, I’ll download an app, and the features of the app aren’t anything more then what can be accomplished on a mobile web site, so I think one should ask the question, “do I really need an app for this?”

    However, what we mean by “mobile” certainly has an impact. As the iPad user, can handle more of a traditional web presentation, but us droid and iPhone users need a different format.

  • One of the biggest mistakes I see being made (and this article somewhat re-enforces this mindset) is optimising only for mobile devices/users.

    As others have pointed out in the comments here, why should only the mobile users get the optimised streamlined version of the site without the additional cruft? Why penalise desktop/laptop users? It’s true that most mobile users want to get straight to the relevant information but that’s true of desktop users too!

    As Guy said: “I’d like to be able to be able to “find a close by restaurant and then provide you with the contact number as well as a menu” from the desktop version of the site rather than be bombarded with all that other crap they have on there.”

    There’s also this assumption that mobile users have just one context (“I’m in a hurry! I need to find a time or a location!”) while desktop users have another (“I’ve got all the time in the world; I don’t mind wading through a bunch of irrelevant crap”) whereas, as Stephanie rightly pointed out—and I believe Luke Wroblewski is also doing user research in this area—this simply isn’t true.

    People will use their Android phones or iPod Touches over WiFi while they are lounging on the sofa and people will use their laptops over 3G while travelling on a train.

    Now tell me: which is the mobile context?

    • Hey Jeremy, great to see your comment. I think we are going to have to agree to disagree on this one. My point is that mobile and desktop are difference for a lot of different reasons and that you cannot treat them as the same thing. I feel that equally about screen readers, TVs, or any other device that accesses the web. To throw a one size fits all solution at them in terms of content (or more particularly hierarchy and organisation of information) is in my opinion naive. That said Jeremy (and I mean this with all sincerity) you are a smarter guy than me. It may well be that I am just not getting this. You just havent convinced me yet.

  • Paul, I think it’s interesting that you say “I feel that equally about screen readers” — that gets to the heart of the fallacy I see in serving up a completely different experience to a person just because of the device they are using. In the bad ol’ days, it was common practice to create a “separate but equal” text-only site for screenreader users. It ghetto-ised those users and it was, frankly, a cop out. These days, it’s understood that screenreader users should get the same content as everyone else, but that the site should be built the right way to begin with. (interestingly, some sites noticed that “regular” non-screenreader users were choosing to go to the “accessible” version because it was faster and simpler—there’s a lesson to be learned there for those who still think of desktop and mobile sites as different things)

    I think the reason why you might not be “getting it” is that you think I’m talking about retro-fitting an existing desktop site to make it fit better on a smaller screen. I’m not. I’m saying that the problem is not with “mobile” websites, the problem is with “desktop” websites. We shouldn’t be creating device-specific websites at all, whether the device in question is a mobile phone or a desktop computer. The truth is that we are all creating device-specific websites …namely desktop-specific sites. The solution is not to create separate websites for phones/tablets/fridgets, etc.; the solution is to build a site that works well for any device …and that includes desktop/laptop users who are currently being served up bloated sprawling crap.

    Just as retrofitting for accessibility will never work as well as designing and developing for accessibility in the first place, retrofitting for mobile or any other device will never work as well as designing and developing for everyone in the first place.

    Some characterise this as “one web” but a more accurate term is “universal design” (see the book on this subject by Matt May and Wendy Chisolm).

  • Emily

    Just noticed what I think is a small typo:

    “I see the same thing happening with mobile. Many web designers are claiming they can do web too”

    Shouldn’t that say ‘claiming they can do mobile too’?


  • I tend to agree with other commenters. More and more, I find myself visiting websites using an iPod Touch. Mostly because I hate waiting for my PC to boot up or my wife is already using the computer.

    It’s very rare that I’m in a hurry, in fact I’m usually relaxing on the couch, lying in bed, or … yes, on the can. There have been a number of times where I’ve been served a mobile website with reduced functionality. After being slightly annoyed, I look for the “View full website” link or leave if the information isn’t important enough.

    One of my favorite comments is why does the mobile version get the streamlined content? Does that extra stuff need to be there when using view with a desktop/laptop/netbook/whatever computer, especially if it gets in the way of finding what I want? For example, my local movie theatre’s website works great on an iPod. It’s all about finding a specific theatre and getting the showtimes. But if I visit the same website on a desktop computer, I need to wade through popups, Flash ads, theatre descriptions, etc. before getting the showtimes.

    Now I understand the argument for reducing the amount of content being sent out to a mobile device. But I personally don’t care since I’m using WiFi and not paying for a data plan.

  • Anthony

    I understand and agree that responsive web design is the future for mobile and web, however I just seem to think that is ignoring the present.

    Many phones do not support media queries, lots of phones have limited javascript capabilities and there is a greater gulf in the capabilities of browsers on mobiles. Modern mobile browsers love javascript and html5, older browsers are plain old xhtml or xhtml-mp.

    if we follow the argument that we should start with mobile sites then build up we are really not ensuring the best browsing experience for our visitors.

    So I still think that at this time, if you want to support all users then you need to think about serving different content to different devices. Don’t give my old series 40 nokia loads of javascript to choke on, don’t confuse it with html5 (it prefers xhtml-mp) and don’t have a convoluted flow of css files confusing it because it won’t recognise media queries. Neither will my mothers blackberry.

    Also, how would this work with high content sites? Examples being BBC, SKY, or maybe a local council site?

    • Anthony: the approach we’ve been using lately (sorry – no links to share yet) is to serve a fluid width mobile-friendly layout first without any media queries, and use min/max queries to scale the fluid layouts all the way up to desktop resolutions (in both presentation and behavior).

      Non-media-query-supporting desktop browsers like IE can be patched with some very lightweight JavaScript (see Respond.js: Images can be served responsively/responsively to eliminate overhead ( ). From there, all your heavier JavaScript can be loaded dynamically based on some feature detects.

      In the end, a complex site is reduced to its markup weight plus some mobile-optimized assets – which, if built responsibly, can compete with the performance of the average mobile-specici, content-oriented website.

    • Anthony

      @scott, Can I ask what browsers and OS you supported? How was your testing done?

      Been a lot of interesting talk about this over the last few days. Seems like there is a bit more discussion and acceptance (or “caveats”) from some top names in the industry that responsive web design is not the golden ticket, just another tool in the arsenal.

  • Useful information today from Jakob Neilson on this topic

  • Anonymous

    What amazes me is that a lot of websites of big companies don’t have a mobile website.
    I mean if Frank the plumber has it, why for a multibillion dollar company is that hard to do a mobile version of the website?

    Amy @ Cowboy Millionaire Review

  • bgrggfe

    Imean Shaheed was working last Sunday when federal agents rushed into the Patapsco Flea Market, announced over the loudspeaker that the bazaar was closed for business and shut down vendors selling  Cheap Louis Vuitton Handbags and Tiffany & Co. jewelry.”It was like the movies,” the 20-year-old Shaheed said Saturday after the Cherry Hill flea market re-opened. Some booths were empty, but the parking lot was full and customers flocked to vendors such as Shaheed who were open for business via Louis Vuitton Outlet Store.