October 16, 2010

Not a mobile web, merely a 320px-wide one

A school of influential web designers are pioneering ‘Responsive Web Design’ as a way to render content on different types of browser screens. They must fix the fledgling technique’s technical faults before it propagates into the wild. And it is certainly not yet worthy of its name: designers must think beyond the glass of a screen and build experiences that respond to the humans beyond it.

A little while ago, renowned web designer Ethan Marcotte wrote an article on the popular web design site A List Apart. This seminal article is titled ‘Responsive Web Design’, and has seemingly been very well read and much admired.

‘Seminal’ because it proposes that sites should challenge many of the established conventions that have been prevalent in contemporary web design: rather than exclusively using a fixed print-like grid, for example, sites should be more fluid and flexible with respect to screen size. (Of course this is how all web pages used to work in the mid-1990s, so the concept’s novelty is probably dependent upon the age of the beholder.)

In case it isn’t obvious, there has never been a single screen size upon which web sites should be expected to render: computer screens and browser viewports have always come in a range of sizes. But now, the obvious logic goes, the big screens are getting bigger, the small (ie. mobile) screens more popular, and a huge host of new browsing form factors – from tablets to car dashboards – are radically reshaping the web’s diverse physical canvas.

By building sites which can respond to these different screen sizes using open standards, the chances of it looking nice on all of, say, a regular laptop, a tablet, a games console, and a 27″ cinema screen are greatly increased.

The real novelty of Mr Marcotte’s argument is not that you should find and remove all the fixed {width:960px} rules from your stylesheets, but that you can use CSS Media Queries to selectively apply styling rules based on certain criteria. This allows you to have a page layout which changes as a function of browser screen size. (The properties available for evaluation in media queries are exclusively related to screen display dimensions and color capabilities.)

Take these two renderings of ‘The Baker Street Inquirer’, for example:

In the narrower example on the right, the title decoration changes, the menu items rise to the top of the page, the images appear in twos instead of threes, and so on.

This looks fantastic. Apart from being a lovely piece of graphic design, viewers also know that this page will look good in their desktop browser whichever size they have it set at, and they won’t have to risk lots of empty space on each side (on a too-large window), or lots of left-to-right scrolling (on a too-narrow window) – both concerns when a browser’s viewport doesn’t match a web designer’s assumption.

Six months on, the fruits of this article are starting to ripen. The good, the great, and the brilliant of the web design world obviously read it and took every word of it to heart. Two oft-discussed examples are Simon Collison’s and dConstruct 2010’s web sites: narrow your browser window on both to see the magic happen.

More recently, Jeremy Keith is notably flying the responsive flag, and has designed a number of sites (and redesigned his own) using a similar approach. Just last week, the mighty Happy Cog launched a very attractive new blog that narrows elegantly, and the talented Mike Kus (with Think Vitamin‘s redesign) has also joined the party.

So, the wheels of evolution turn. Designers are innovating, trying each other’s new techniques, and pushing this worthy idea onwards. They are influencing each other, and in the way these things cascade through imitation, influencing the approach that many thousands of developers who look up to them will take when next asked to design or redesign a site. At this rate, it will only be a few years before more web sites use media queries than don’t. It’s a smart solution, using well-known, standards-based technology, and users with different screens the world over will undoubtedly be happier.

Sadly, this technique is not the revelational panacea that some might present it as. While it copes well with the challenges presented by size-diverse browsers on a desktop, for example, it is flawed when presented as an single solution to the challenge of the mobile web. A more-or-less explicit tenet of the ‘Responsive Web Design’ school is that contemporary mobile browsers are served neatly by this technique, so it deserves to be put under this scrutiny.

Before we go any further, and for the avoidance of doubt, it is thrilling that the ‘mobile web’ has finally garnered some sort of interest amongst the web design community. For a decade, lonely pioneers have been hacking about with little more than monochromatic text on cramped and feeble browsers. Seeing a new wave of talented web artists thinking about the medium is very inspiring – spurred on by the rise and rise of brilliantly capable mobile browsers. Mobile, the historically gloomy little corner of the web, is ripe to welcome fresh and smart ideas – clever and efficient ways to deliver exciting content to mobile users.

Sadly ‘Responsive Web Design’ is not yet one of them.

To start off with, there are some technical and tactical issues. Experienced mobile web designer Bryan Rieger has most notably illustrated these concerns, and strategist Jason Grigsby has explored similar points. Their main concerns stem from the facts that:

  • Media queries only affect the styling once the markup and other resources have reached the browser. Whatever the device – whatever the network it’s connected to – the browser will download the entire markup of the page, and any (probably large) images in it. Yes, a ‘responsive stylesheet’ can resize media or hide it from the user, but designers should not presume that they’ve done anything to improve the performance or network utilisation by this sleight of hand. Cellular network usage is free in neither the financial nor performance sense. Ironically, Mr Keith’s article about the technique itself has a total size of about 1.6Mb – a payload that no mobile device this side of LTE will sniff at.
  • Media queries are not supported by most of the world’s web browsers. Certainly all WebKit-based browsers handle them well enough, and most other contemporary desktop browsers do too. But anything else will struggle: this includes legacy desktop browsers (which certainly don’t seem to concern the web’s great and good) and, more seriously, most mobile handsets in the market today.

Both issues are present in Mr Marcotte’s initial expression of ‘Responsive Web Design’. Perhaps understandably: while the exposition of technique focusses on the aesthetic of flexible design, there is little discussion of performance optimization. Further, many of these concerns pale if you’re a designer who lives in a world where everyone has an iPhone 4. Perhaps the article set out to merely present a prototype which the author knew would of course be iterated upon and refined.

Certainly some refinement could be applied to the mathematics, which apparently advocates daft rules like {margin-right: 3.317535545023696682%}!

But thankfully none of these concepts are necessarily deal-breakers: tinySrc (created by this author) allows you to have already dynamically-resized images arriving at the browser in response to a static piece of markup. Mr Reiger illustrates that by rethinking the assumptions about which browser is the default (i.e. a basic mobile one) and which receives the conditional styling (i.e. the clever, or desktop ones), one can mitigate a lot of the problems caused by serving up too many irrelevant resources. That’s probably not entirely what Luke Wroblewski was getting at when he said ‘Mobile First‘, but it’s good enough to work.

Hopefully, Messrs Marcotte, Keith, Kus, Zeldman et al will take these considerations on board and refine their logic accordingly. Theirs is the work that will be widely aspired to and derived from, and this is some basic hygiene that should be encouraged as soon as possible. The practices are not yet best practices – and we should hope that this technique doesn’t become a precedent for playing fast and loose with mobile payloads.

Technical issues aside, the primary concern with using ‘Responsive Web Design’ for mobile web sites remains, and it is far more fundamental.

Firstly let’s look at the name – or at least the origin from which is was purloined. ‘Responsive Architecture’, a term coined by Nicholas Negroponte, is a school of thought that says that buildings and structures should be able to react to changes in their environment, altering their shape or surfaces accordingly. Indeed this is what ‘Responsive Web Design’ does too: change the browser size, and the site within it will respond.

But Mr Marcotte posits that it is also about ‘how physical spaces can respond to the presence of people passing through them’ – in other words, that buildings should react to the way in which humans behave, and implicitly, to what it is that they need or want. This is where the ‘Responsive Web Design’ aspiration falls flat. Nothing about the technique is explicitly related to the human actually using the site, nor his or her context.

The problem of course, stems from the reliance on media queries as the key input to the layout’s alterations. Complex criteria can be built to segment styling based on width, height, orientation or color depth – but nothing else. The design is responding to the glass on the front of the gadget that the user has in their hand – not to the flesh and bone beyond it, where they are, what they are doing, and what state of mind they are in.

In the world of mobile, this matters. The fact that the user has a small screen in their hand is one thing – the fact that it is in their hand at all is another. The fact that the user may be walking, driving, or lounging is yet another. In fact, it’s quite likely that they really deserve different content and services altogether – or, at least, a differently prioritized version of the default desktop experience.

Is this too abstract? Too theoretical? Absolutely not. As a commonplace example, consider the FourSquare mobile web site and its sister web site. The former, of course, is designed as a slick and efficient way to check your location in to the service – and not much else. The latter provides a chance to review previous activity in the comfort of a desktop environment.

Is this responsive? Of course it is – at least in terms of responding to what humans in different environments want to do. The user, by specifying which site they want to receive, gets a design and an interface that is wholly appropriate to their context, not just their screen width. (Sadly, visitors with mobile handsets do not get automatically forwarded to the mobile version of the site, which would have made the service even more ‘responsive’.)

Consider, on the other hand, the St Paul’s School website. It looks lovely and exhibits all the hallmarks of the ‘Responsive Web Design’ school. Resizing the browser window demonstrates the page’s fluid grid, and on a narrow, mobile screen the layout becomes vertical and flows respectably down the page.

But let us just think about the use cases for this web site. Clearly the desktop site is designed to target prospective parents – St Paul’s is a top-notch fee-paying school in London – and the design, menu structure and layout reflect that. The ‘about’ page is first and foremost in the menu, followed by a sequence of pages designed to give the reader an insight into the workings and philosophy of the school. One can imagine well-heeled parents poring over the site for hours, deciding if it is the place for their child to attend and getting a feeling for the institution.

But a mobile user? Let us think about what a mobile user might want from their interaction with the school’s online presence. Are prospective parents so busy that they research making one of the biggest investments in their lives by spending a few moments on a mobile browser? Well, possibly; but it is hard to imagine that reading the school’s lengthy prospectus should top of the list of important mobile use-cases.

If one is accessing this site on a mobile device, there are other far more likely reasons. Imagine an existing parent or student keeping abreast of the (well-populated) school news, or upcoming calendar of events. This is something they might easily snatch a few moments doing in the car on the school commute, say. Or perhaps the user is a prospective parent or visitor who wants to check on the address and location of the school en route, or wants to put a call through to the school office.

Has the design responded to these, now very different, requirements? No. In the mobile display of the site, the news and contact pages are still at the bottom of the menu, below the admissions information and exhaustive list of school sports. The contact page (once you have reached it) does contain telephone numbers, but they have been turned into callable links by the browser’s automatic number detection, not the designer’s hand, so rather curiously you can also click to call the school’s fax number.

And the location page, to get a map and directions to the school? Most of the screen is taken up with an aerial portrait of the school – of arguably marginal help for navigation – and the map itself is only available within a 1.5Mb, three-part PDF document. You couldn’t make this up.

Surely a mobile user deserves and expects a map image embedded in the page, or even a link to Google Maps (which, incidentally, certain mobile browsers will parse to invoke the native map client). Apparently a few of these clever new gadgets have GPS in them.

Responsive to the user’s needs? Barely.

Anyway, the purpose of this article is not a hatchet attack on one particular site. It’s merely being used as an example of how using what is currently called ‘Responsive Web Design’ is often nothing of the sort – or, at best, a single cosmetic tool that needs to be used in conjunction with other, mobile-centric ideas and sympathies.

One gets the sense that those promoting and using ‘Responsive Web Design’ in its current form secretly hope that this is all they will have to do to be able to call their sites ‘mobile-ready’ (although whether that is what they commit to their clients, of course, one cannot say). We should sincerely hope this is not the case. These are smart and insightful individuals: surely they understand that juggling a few pixels around does not amount to designing for different types of user.

Mr Keith in particular appears to understand the dilemma. He points out that ‘I don’t refer to this as mobile optimisation’ and that media queries are not the ‘silver bullet for the mobile context’. Nevertheless, the screenshots of his portfolio sites are 480px in width (conveniently the landscape size of an iPhone), and he is somewhat disparaging about the idea of ‘the rabbit hole’ of creating a different site for mobile devices.

(Of course that isn’t technically required. A small snippet of server logic would have have been all that was required by St Paul’s to move news and contact to the top of a mobile menu, and to replace the PDF link with a Google Maps resource, for example.)

But this may give us a clue why so many others seem desperate to will the current implementation of ‘Responsive Web Design’ into being as the sole way to develop services for mobile users: it’s all client-side, and requires nothing more complex than a few extra tricks in existing CSS files. It may be that many web designers are daunted by the thought that they may be required to think about mobile device detection and conditional logic on the server-side, and are clinging to the hope that they can claim to support mobile users without having to do any, well, programming.

Sadly for those involved, this probably can’t be avoided. It’s not that media queries aren’t an excellent way to resize layouts (of course they are), nor that they don’t act as a reasonable proxy for identifying a mobile devices (which is also more or less true for now) and in turn mobile humans.

It’s a more fundamental issue – which is that any site should be ruthlessly scrutinized for ways in which it can behave in better ways for all of its constituencies of users, and that the differences between those ways are often going to be more significant than can be papered over with some stretchy images and fluid grids on a conveniently powerful mobile browser.

The real fear is that this subtlety is lost on those disciples who want to rattle off a site design that works on mobile devices as well as desktop browsers. The result of their efforts might look lovely on the client’s iPhone, but the speed at which that magic trick was performed will certainly have come at the expense of someone actually sitting down and thinking about what that mobile variant of the experience should actually offer.

The result? We won’t have a mobile web, but merely a 320px-wide one. A web for which the humans using it matter less than the width of the glass it is displayed on.

As a postscript, an analogy: we are in an age which, in many ways, resembles that of the birth of broadcast television. The mobile web is a new medium that, yes, is able to deliver services similar to its precursor, but which can also be developed and enhanced in ways that have yet to be dreamt of. Reflowing today’s web sites for mobile devices is a philosophy akin to that of the first broadcast television programs: “let’s stick with what worked before, and just put well-dressed radio presenters onto the screen”.

Did that work? Sure it did – as a start. But was it these dull talking heads that made television the greatest medium of the 20th century? Hardly. It was when program makers started to explore the visual capabilities of the their new canvas – and the increasingly demanding expectations of the viewers who expected to see something more interesting on the wooden box they had just spent a lot of money on – that innovation occurred.

Today’s ‘Responsive Web Design’ is a lukewarm response to a similar seismic shift – that of the sedentary web into expectant mobile hands.

Our approaches need to be bolder, more structural, more experimental, and, frankly, more considerate of the diverse audiences we should all be trying to cater for.

Comments (223)

  1. October 16, 2010
    John Boxall said...

    I have seen the future, and it is body classes.

  2. October 16, 2010
    James said...

    You mean like aerobics lessons? 😉

  3. October 16, 2010
    Ian Homer said...

    Great post – mobile is more than the capabilities of the device. We have to listen to the user and allow them to adjust and specify the context.

  4. October 16, 2010
    James said...

    Thanks Ian. I was particularly intrigued today by the TED iPad app (http://blog.ted.com/2010/10/14/introducing-the-ted-ipad-app/) which has a “How much time do you have?” icon.

    This is brilliant… a service that adapts to the state of mind, and context, of the human – as well as the glass of the tablet.

    (I should have mentioned it in the post, but it was long enough already!)

  5. October 16, 2010
    Andrew Hedges said...

    Great post, James. I’ve been following this topic on blog’s such as Jeremy Keith’s and the Mobile Web discussion group of which we are both part and I’ve had the same discomfort with the emerging hype rattling around the back of my head. You have done us all a service by articulating the concerns involved so clearly.

    I have direct experience with this as well. I work for Digg.com. We recently launched a new version of our website in August. We had a decent mobile web implementation before, but needed one based on our new backend platform for when we cutover from the old version. Short on engineering resources, we went with a server-side browser detect that does nothing more than *add code* (additional CSS) to restyle the regular website to better fit small screens.

    It is the worst possible mobile implementation.

    I’m currently working on a revamp of our m.digg.com offering so that it is optimized for mobile consumption. My point is, sometimes you have to do something janky just to have a presence in the market, but for the love of all things great and wonderful, don’t settle for it for a second longer than you have to.

  6. October 16, 2010
    Cennydd Bowles said...

    Hi James,

    First, this is in many ways a fine article, and I’m very pleased you wrote it. You are of course right. What is currently labelled responsive design is almost entirely a visual concern. Meanwhile, the mobile user experience has the potential to be so different from the desktop experience that simply shuffling the deckchairs can be a wildly pointless exercise.

    I work for Clearleft and was both project and UX lead for the St Paul’s website. For many months now we’ve been engaged in some deep discussions about responsive design, mobile devices, and the implications for the web design process, and I’d like to explain a little about the project so that you can understand the design decisions we made.

    Your criticism of the St Paul’s site is understandable and accurate. Hell, as a UX designer I’m particularly painfully aware of these issues. However, at the project’s inception—incidentally, long before any of these technologies had emerged into the mainstream—our brief was explicitly based around creating a desktop site. Mobile use was agreed to be an unlikely use case, and thus kept out of scope. After a well-received launch, a small additional budget was made available to improve the mobile experience, given the growth in these platforms. Given the budget and timescale involved, a dedicated mobile site was impossible. We instead chose to make minor changes via media queries to improve the UX on alternative devices. Anything else simply wouldn’t have got off the ground.

    And this is the point of responsive design. It is better than nothing. A small step toward making a more humane experience across various screen widths and hence devices, in situations where dedicated mobile/small-screen experiences aren’t possible or necessary.

    I’m concerned that in your haste to make an otherwise extremely valid point you’ve created a straw man. I couldn’t agree more that throwing media queries at a desktop site doesn’t make a mobile site. However, I don’t believe that any of the pioneers of this technique make this claim, and I’m sure I can speak for all at Clearleft in saying that anyone who presents responsive design as a “revelational panacea” is an idiot.

    But you’re right. And we know. And believe me, much of the web design community is trying. Hopefully UX designers will begin to reframe their attitudes to consider a greater diversity of devices and contexts than a 960px browser: indeed, I’m working on an extensive article on precisely this topic. Hopefully we can push beyond these crude techniques and help clients to understand why funding work on mobile-specific experiences is often the best route. But when this is not possible, I believe even small victories are worth celebrating, and for these cases, responsive design can be an appropriate technique.

  7. October 16, 2010
    James said...


    Thanks for your extensive reply – of course my toes curl when I know the protagonists themselves might read my commentary 😉 – an acute risk when I’ve picked one particular example.

    Of course, you’re right… it is better than nothing, and for those designers who strongly appreciate that this is a mere base camp, I wish all the best speed and luck at shaping the medium on the trek ahead.

    Sadly, my post was provoked by the fear that although designers like yourselves might be at the vanguard, we are at a point where the philosophical flaws are about to propagate as virulently as the cosmetic ambition. No doubt there are thousands of web designers for whom ‘if it’s good enough for Zeldman, it’s good enough for me’.

    In my humble way, I wanted to make sure that this bigger, more ambitious picture had a voice, so that the naive didn’t come away with the thought that a little tricky CSS was all they had to do to thrill billions of new users.

    And in the meantime, what do you think about replacing that monstrous PDF with a link that launches Google Maps? 🙂

  8. October 16, 2010
    James said...

    Thanks Andrew – awesome reply. I’m always fascinated by the way in which large online brands approach their mobile strategies.

    (On one hand you have the most to gain; on the other the most to lose.)

    Will you ever be writing about the approaches you have taken? In the past and for the future?

    Glad you enjoyed the article.

  9. October 16, 2010
    Scott Jenson said...

    At Google, we face this ‘just make it fit’ issue in many ways. There really are web purists that just want to treat mobile as a stress test for their markup: it’s it’s good HTML, it’ll work.

    Fortunately, most people w/in google understand this. There are limits, however, to how ‘mobile specific’ you can go. Google.com is so iconic, it’s functionality so freakishly clear that to deviate too far starts to confusers users brand concept of the product. We’ve worked hard to add mobile specific functionality without pulling the rug out from under users.

    Excellent post! Thank you.

  10. October 16, 2010
    James said...

    Hey Scott – thanks for dropping by!

    As it happens, I often use the example of Gmail as a beacon for how it *should* be done. You somehow know it’s the same service when you use it on mobile – it has the same colors, iconography, terminology etc – but in fact the two apps are entirely different.

    There are whole swathes of the desktop experience that haven’t been replicated: the settings, the label management etc etc – and the navigation is far more modal. Yet what is left in the mobile version of the app feels like just enough to give you everything you need to use the service in a constrained, yet focussed, context. It’s elegant.

    (Needless to say, the implementation of the differences between the two apps must surely be well beyond the abilities of media queries alone!)

  11. October 16, 2010
    Cennydd Bowles said...

    James – hey, no problems. You’re absolutely right to keep us honest, and I’m sure you understand why I wanted to defend our honour slightly 🙂

    I understand your fear that people may adopt responsive design as a cargo cult, focusing on the surface but not the need and meaning. I guarantee that will happen; it always does. Hopefully between us we can guide people to consider more sophisticated approaches where appropriate.

    “What do you think about replacing that monstrous PDF with a link that launches Google Maps?”

    I think I’ll show this discussion to my (truly fantastic) client and see if we can sort something out.


  12. October 16, 2010
    Jeremy Keith said...

    James, you say that responsive design “is flawed when presented as an single solution to the challenge of the mobile web.”

    Indeed. That is exactly why neither I nor Ethan have ever presented it as such. I grow tired of having to repeat that. I hope that you will listen at some point. As I said (and emphasised) on my blog:

    “The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.”

    That was at http://adactio.com/journal/1696/ Please read it before assuming that I’m advocating media queries as a solution for the mobile context: I’m doing no such thing.

    When you say “A more-or-less explicit tenet of the ‘Responsive Web Design’ school is that contemporary mobile browsers are served neatly by this technique” …a citation would be nice.

    Honestly, I don’t know how much longer I can continue to repeat myself. I never said that responsive web design was a solution for the mobile context. As Cennydd has made clear, your comparison of a dedicated mobile site like Foursquare to the media queries of the St. Paul’s site is comparing apples and oranges. If we had the time and budget, we would love to create a dedicated mobile site. But for a couple of hour’s work, the media queries are better than nothing, right? Nobody is claiming that it’s a mobile solution.

    I appreciate that you were only using the St. Paul’s site as an example, but I’d appreciate it more if you actually used a site that claimed media queries alone were a suitable mobile strategy.

    On an unrelated note, aren’t you conflating small screen size with small bandwidth? It’s true in many cases but not in all. For example, the iPod Touch is (very popular) small screen device that uses WiFi (not mobile networks).

    Conversely, the things that you say are problematic in the mobile context (e.g. large file size to download) are equally problematic in other environments. Large screen size does not equate to large bandwidth. So I didn’t think the solution is to optimise performance for small-screen devices: the solution is to optimise performance for all devices.

  13. October 16, 2010
    James said...

    Jeremy, thank you for the comment.

    I know you know this! But I *believe* (although of course it’s hard to prove), that this subtlety has been lost on many of those that are building the next wave of ‘responsive’ sites.

    Indeed you yourself have been best at making the point, and have even avoided using the word ‘mobile’ or using pixel bounds at all. (The post you’ve asked me to read I had already quoted in my article).

    Nevertheless, elsewhere, one has to wonder why 320px- and 480px-wide desktop windows would be mysteriously so interesting! Of course they are not – these dimensions are only significant for mobile browsers. (iPod Touch? OK, but I think I’m sure that’s not most designers’ primary target).

    From the Think Vitamin launch:

    With the amount of people in the web industry consuming content on mobile devices like the iPhone and iPad we thought Think Vitamin was the perfect place to try out our first “responsive design”.

    The word ‘first’ I like, because it implies it will be iterated on. But otherwise the message is: “if we use ‘responsive design’, we’ll be mobile”.

    A tenet of the ‘Responsive Web Design’ school is that contemporary mobile browsers are served neatly by this technique

    If they are not, why is it being used at all? My main point is that the *browsers* are indeed ‘served neatly’ by this technique. But the *users* may well not be.

    [Presented as a] single solution to the challenge of the mobile web

    I’m afraid I believe that. Or at least, that’s how it’s being reading it. From the original article:

    We can quarantine the mobile experience on separate subdomains, spaces distinct and separate from “the non-iPhone website.” But what’s next? An iPad website? An N90 website? Can we really continue to commit to supporting each new user agent with its own bespoke experience? At some point, this starts to feel like a zero sum game. But how can we—and our designs—adapt?

    The answer, we are led to believe, is the technique subsequently described.

    I admit that the closing lines concede that:

    if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach

    – but this hardly reads as advocacy.

    (And why ‘more limited’? Just ‘more suited to mobile users’, perhaps! That would truly be ‘responsive’.)

    I guess I have to use *something* to illustrate my points and I’m sorry if I come across as singling out particular individuals, articles, and sites. This is part and parcel of debating such nascent innovations.

  14. October 17, 2010
    Andrew Hedges said...

    A couple of months back I wrote up what was, at the time, my analysis of the current ‘best practice’ for mobile web apps as well as some of our thinking in terms of technical strategy for m.digg.com:


    I couch it that way because we’ve now settled on taking more of a progressive enhancement approach, starting with a simple site that will work across as many mobile-ish devices as possible, and adding a ‘fancier’ experience for devices that can handle it.

    Thanks again for the provocative article. This is just the kind of healthy debate the industry needs to coalesce around a coherent philosophy for the mobile web!

  15. October 17, 2010
    Jamie Newman said...

    I agree wholeheartedly with the points raised in this article when considering mobile as a whole (small screens, bandwidth, cross-browser issues), but as Jeremy and Ethan have said, media queries have a place in a web designers/developers toolkit and are better than having no small screen optimisations at all. Plus, they are very simple to implement if you’ve built your site layout fluidly.

    I think your criticism of Jeremy is particularly harsh, especially when he has been very careful to distinguish between sites that use media queries and mobile-optimised sites when discussing the topic, while being a proponent of media queries and the wonderful opportunities they provide. The St Paul’s school site is a particularly excellent example of what can be achieved with little/no effort and does not deserve to be singled out to prove your point, when others make no attempt at all.

    In summary, this is an excellent article with well-argued, valid points, but for some reason you go out of your way to criticise the very people who advocate what you are arguing for, which leaves a bitter taste. Disappointing.

  16. October 17, 2010
    James said...

    Hi Jamie,

    Thank you for your feedback – I really tried to stay aloof (and maybe didn’t pull it off). And the St Paul’s site is lovely. Just not, I felt, worthy of being called ‘responsive’.

    I want to see this topic debated while it’s still young. So of course there aren’t *that* many sites doing media-query fluidity at all – not many examples to choose from!

    (Yes, there are hundreds of millions of sites that do nothing for mobile users at all, but I wanted to drive a discussion around trying to improve the ways in which people *are* doing it).

    Anyway, that aside, I hope you enjoyed the debate.

  17. October 17, 2010
    Terence Eden said...

    One thing which is rarely mentioned is the (over?) reliance on the latest and greatest browsers. We know that many users – especially corporate ones – are unlikely to upgrade their browser. Media Queries need to be used alongside more traditional methods such as UA sniffing.

    In mobile, the problem is even worse than on the desktop. There is literally no way to upgrade the browser on most phones in the market place. Considering the slow adoption of smartphones – and the laggardly pace at which manufacturers update their existing portfolios – I’d say there are still several years to go before we can start using Media Queries for the majority of mobile users.

    Doesn’t mean we can’t have fun now though 🙂

    Excellent article – very thought provoking.

  18. October 17, 2010
    James said...

    Thanks Terence, glad to have you along 🙂

  19. October 17, 2010
    Jeremy Keith said...

    James, if the Think Vitamin redesign is a good example of a site using media queries and claiming that it is a valid mobile strategy, then why didn’t you use that example rather than the St. Paul’s site? Especially when, as others have pointed out here in the comments, I have gone out of my way to state that the media queries for St. Paul’s do not constitute a solution for the mobile context.

    Rather than putting words in my mouth and pretending that the small-screen layout of the St. Paul’s website was intended as a mobile strategy, you might want to update what you’ve written to include a genuine example of a counterpoint to your argument.

    You said “I guess I have to use *something* to illustrate my points” but the onus is also on you to choose a representative example.

  20. October 17, 2010
    Steve Souders said...

    Fantastic article. Great examples. Cennydd’s comment about the budget for St. Paul’s is a great reminder that tradeoffs are always happening. Nevertheless, the examples used illustrate the points clearly. As an advocate for faster websites I appreciate your echoing of Jason Grigsby’s points about needing something more than media queries in order to avoid unnecessary downloads. And the follow-up comments from Jeremy and others further hammer home the key takeaway: media queries are a great start but there’s much more that needs do be done to create an engaging mobile experience.

  21. October 17, 2010
    Stephen Oman said...

    James, this is an interesting article, but I think that the focus on layout design in the mobile web is actually obscuring the need for a rethink of web application design itself.

    Traditionally, as application designers, we would identify a problem and try to provide a software solution to it as a collection of functions. Interface designers then take that collection and try to layer on a UI, taking into consideration whatever constraints exist. Implicit in this is that there is a single collection of functions.

    However, the underlying problem is that there is no longer a single collection of functions. Instead there are multiple collections of functions, where each collection depends on several constraints. A mobile browser is one such constraint, on the assumption that the screen is smaller than a desktop and therefore less capable. Bandwidth is another and so on for all the myriad of different devices that you can think of.

    The question then becomes, how do you select which collection of functions are applicable during a given user session?

    In order to solve this problem, application designers need to start thinking in terms of contexts. Context-aware applications should then inform the right user experience.

    The hard part of course is identifying a context. What is a “Mobile” context? For example, I’m using my iPad in a coffee shop WiFi connection in Dawson Street. I’m definitely mobile, but should my user experience be? What if I switched to using my Android device? Same location, same connection but a different device. Then I walk a little down the street. Same location (-ish), same device, but now a different connection (3G hopefully, but maybe 2.5G).

    Applications now need to respond to a dynamic environment of changing contexts in order to give the user the best experience at a point in time. Focusing on screen size is the wrong approach.

  22. October 17, 2010
    James said...

    Hi Jeremy,

    Without a clear example, I ran the risk of the article as a whole being too abstract. I simply chose a site that uses ‘responsive web design’ but seemed not to be responsive to its users.

    It is to be read neither as criticism of a single web site nor the team behind it. It’s just used to personify the technique. BUT of course I fully understand your reaction.

    I’m not a web design insider (and probably never will be, at this rate!), so I can’t keep track of what claims have or haven’t been made about individual web designs. Nevertheless, nor can their users.

    I am more concerned about putting the technique in the spotlight and judging the results at face value. There aren’t that many web sites parading it yet, so I don’t have many to choose from. That’s also why I think this debate is important now.

    Mobile bloopers elsewhere? Of course! I could write a whole second article. Do you think it will help move the generic discussion on by writing additional specific critique?

  23. October 17, 2010
    James said...

    Hi Steve – fantastic to have you pop by.

    Indeed the comments are rapidly becoming more revealing than the original article 😉

    There will soon be a time when mobile users are be considered first, and their sedentary brethren as an afterthought. One day, I think the desktop browser will be the trade-off!

  24. October 17, 2010
    James said...

    Hey Stephen, thanks for the comment.

    I think we are in complete agreement! You’ve put the point more concisely than I did 😉

    The hard part of course is identifying a context

    Tell me about it! There’s an opportunity in there for someone to figure that part out, for sure.

  25. October 18, 2010
    Keir Whitaker said...

    Hey James,

    Firstly a great article which has clearly been enhanced by a lively comment thread.

    As one part of the team involved in the redesign of the Think Vitamin web site I can understand why when you quote this:

    “With the amount of people in the web industry consuming content on mobile devices like the iPhone and iPad we thought Think Vitamin was the perfect place to try out our first responsive design”

    you would assume we are stating that we have a “mobile strategy”.

    I can assure you we are not saying this at all. In fact if you have the opportunity do listen to the last couple of episodes of our podcast Think Vitamin Radio where we discuss the issue of “responsive design”. From memory I think we have all agreed that it’s not a “catch all” solution to delivering a “mobile” site, to consider it as such would be naive in my opinion.

    In regard to the quote we are perhaps in a unique position in that our site is directly targeted at people using so called “modern browsers” as well as devices like the iPhone, iPod Touch and iPad. It was therefore an obvious choice to “experiment” with the ideas expressed in Ethan’s article, the ideas that have now become known as “responsive web design”.

    As Jermey Keith expresses in this thread “…for a couple of hour’s work, the media queries are better than nothing, right?” I couldn’t agree more, by using media queries on our redesign we tailored the experience to certain devices, devices that we know are used a lot to view our site. We were well aware that we weren’t actually creating a “mobile” site. The alternative was to serve the same site to all devices, the same site with the same payload.

    In the course of my day job I have read a lot on this subject and can certainly say that the recent posts on Jeremy’s site are some of the best discussions on this topic and well worth a few minutes of any designers time.

    Finally, we certainly haven’t ruled out the option of creating a “mobile” site but like many others trying out the idea figured that it was worth a go and the response, if you will, has been positive.

  26. October 18, 2010
    Jeremy Keith said...

    James you say that you read my blog posts but now you’re saying “I can’t keep track of what claims have or haven’t been made about individual web designs.”

    Might I suggest that you didn’t read very closely if you thought for a moment that I suggested that the media queries used on the St. Paul’s website were intended as a mobile strategy.

    The alternative explanation is that you did read what I wrote but that you don’t believe me.

  27. October 18, 2010
    Andrew Hedges said...

    I have a lot of respect for Jeremy Keith most of the time, but his reactions on this thread and on Twitter just come off as unnecessarily defensive. The spirit of the article, as I read it, was that responsive design is good to a point, but that we shouldn’t consider it a replacement for targeted mobile sites. I don’t see where James called him a ‘liar’ like Jeremy claims on Twitter, and I’m fairly certain he would never do so intentionally. Sorry, Jeremy, but you just sound like you’re tossing your toys out of the cot at this point.

  28. October 18, 2010
    Max Flanigan said...

    Great post James.

    Your points extends well beyond the style of presentation. Let’s hope ego doesn’t hinder debate.

  29. October 18, 2010

    […] recent article by James Pearce started a great conversation in the mobile web technology circles. Are media queries, a CSS […]

  30. October 18, 2010
    James said...

    Hi Keir,

    Many thanks for your lengthy response. I’m sorry I hadn’t followed your podcasts.

    I hear ‘better than nothing at all’ fairly often, and it’s a hard one to argue against, especially if a couple of hours is all that’s been left over for mobile design.

    But the phrase implies that applying ‘responsive web design’ is a Step One. I’m nervous about this (and not only because many pressured projects never make Step Twos!)

    The reason being that ultimately it is a cosmetic technique, sensibly applied once the main functionality and templates are refined.

    Rather, my rallying cry is to carefully consider the underlying use-cases for mobile users as early as possible. From that may derive changes to fairly fundamental things like site architecture, navigation, functionality etc. Because of the possible impact (to the entire platform!) of making mobile users a primary target, fluid grid layout should be Step Last.

    Now, having considered the mobile user and conveniently concluded that they are indeed perfectly served by exactly the same markup as a desktop user, ‘responsive web design’ may be all that is required. For a linear blog-like site like Think Vitamin, that may be a valid conclusion (give or take a few spare megabytes of hidden images – you might want to check out my WordPress Mobile Pack 😉 )

    But there will be lots of sites and applications where not having assessed the needs of mobile users will have resulted in the loss of a great opportunity to thrill them. (Importantly noting that sometimes mobile users deserve additional features, not always fewer).

    I accept that ‘responsive web design’ is beautiful icing on a cake. But I think it is best to bake the cake first. Making a cake-shaped block of icing – hollowing it out and trying to bake a sponge back into it – seems like a, er, recipe for disaster.

    Let’s figure out how to move this discussion on to what those more fundamental mobile-focussed techniques and methodologies might be. Think Vitamin might be just the place.

    I am sure we can do better than ‘better than nothing at all’!

  31. October 19, 2010

    Great post James. I couldn’t agree more that taking into account the mobile context and minimizing payload size are essential to designing for mobile. I did noticed that unlike the other examples you gave, most of Adactio’s pages are very reasonably sized. only 23 KB uncompressed html, css, images and JavaScript for the front page and 69 KB for one of the longer blog posts.

  32. October 19, 2010
    James said...

    Hey Dennis; lovely to have you come by!

    Yes, I probably should stress that the payload size is often just a niggle too – of course dealing with the mobile human is more than the screen, but also more than the network constraint too (except in excessive cases).

  33. October 19, 2010

    […] was cited recently in James Pearce's post "Not a mobile web, merely a 320px-wide one" as an example of the new school of "Responsive Web Design" which advocates using a fluid design […]

  34. October 19, 2010
    Max Flanigan said...

    [Previous comment posted in error. Oops!]

    Pure ‘responsiveness’ goes beyond client side tweaking.

    When supported by the browser, CSS media queries can tailor to the form factor.

    Use of media queries for mobile adaption will visually enhance a design, however it’s not a default UX win since the network experience can induce potential load/cost frustrations when non-optimised.

    CSS media is not the definitive mobile strategy for web designers. Neither is it claimed to be.

    The real assertion made here thought is that ‘media ≠ context’
    I agree entirely.

    Delighting the mobile user is not just about universal access. It’s about relevance. Rendering the same web information to a different pixel width is not best usage of the medium.

    This message of ‘context’ goes beyond iPhone Vs Desktop. It also goes beyond mobile penetration rates and the long tail of mobile devices.

    Consider a world of browsers in every embedded interface. Imagine a browser inside your desktop, mobile, tablet, TV, car, fridge, vending machine, table surface, whatever. Maybe it outputs to a screen, a touchscreen, a projector, your eye wear, anything.

    A clever set of media queries might gracefully render the most beautiful experience to every possible combo. But a clever context will tailor the content to a user’s environmental need. This is not just presentation mechanics.

    Future design will deliver ‘responsive’ context. The potential user value is too high for it not to.

    What’s not clear today is how to do this profitably.

    In practical terms, responding to the mobile context implies detection of user agents to serve different files based on distinct grouping logic. Doing so carries cost, complexity and maintenance burdens.

    Therefore contextual relevance is easily traded off against budget. That is unless the design explicitly calls for features that are distinctive to mobile – such as location awareness, user profiles or instant access.

    So whilst CSS media queries may not represent a single revelational panacea for mobile, they do represent a step in the right direction.

    One that if taken more often can be iterated further. One that also lies within the skillset of modern web designers. Client side mobile device rendering may not be final state but it is possible and it is progress.

    A next phase might see mobile designs truly respond to user ‘context’ but first the encapsulated tools and standards must be available to facilitate simply.

  35. October 19, 2010

    Very good piece James…

    Thanks for sharing your thoughts/experience.

    Agreed… If I take a little spin on this topic, a responsive (Web) (mobile) app design is one that consists of multiple parts:

    1) the front-end/screenview organization/design being just one,
    2) the info models another, and,
    3) how optimal to the channel/device yet another.

    All three together making the optimal (mobile) application design (regardless of native or web).

    In support of this is the actual intelligence (and SW development) some on the client but most “hidden” on the server, on the web, on the cloud; think of this as an Iceberg where most of the processing power is “hidden, unseen” — on the server/cloud itself. This part of the mobile app Iceberg is perhaps what most of the most recent generation of mobile designers and developers are hoping to be able to ignore; a good example is device-detection and proper real-time adaptation (or responsiveness).

    Number one and number two above are tightly related, with number one about *how* to best render/organize the information on the screen, number two about *what information and when* to bring to the customer, based on use-cases including the mobile context. Number two requires sitting down and understanding the application’s vision, what the customer wants and what the user of the application needs (all via use-cases); perhaps some of the adaptive behavior is driven by “fixed” use-cases while other is based on intelligence where information is self-organized based on usage patterns of the user vs. others, over time. And then number three, yes, no doubt, *optimization* is of extreme importance; this is something that is bein overlooked; read next.

    On number 3 (optimization) if you remember, you and I discussing some time ago mobile optimization vs. “one web” where I argued mobile browsers can display “desktop versions” on the web site with no problem. Yes they can, but guess what, you were/are right. The user experience is not optimal and it is tiring having to zoom in and navigate throught the page to find/read. Not to mention, ignoring content optimization has a big impact on the network (usage) itself; the days of unlimited data-plans are ending, meaning for a while, it seemed that it was going to be “OK” to let content remain as is, but, no, content and applications needs to be optimized for the channel; because network usage do cost in one way or another.

    So in summary, proper “responsive” (web) mobile app design: screenview design + info models + app & content optimization

    There is something I have been preaching for a while, and that I believe is at the center of the discussion of this thread, and I call it People-Centric Mobile Computing; you can read about it on my blog.


  36. October 20, 2010
    John said...

    Finally, an article like this! I don’t understand why they’re promoting “Responsive Web Design” when large images are being downloaded onto the mobile browser.

    “Large screen size does not equate to large bandwidth.” – Jeremy Keith

    Yes, it doesn’t. But when people are on their mobile phones browsing the web, they are likely to be on the go. So they are in a hurry and would like everything to load fast. Loading unnecessary large images defeat the purpose of having a mobile site built with the RWD technique.

    “The choice is not between using media queries and creating a dedicated mobile site; the choice is between using media queries and doing nothing at all.”

    If you load a regular site and a RWD site on a mobile phone, they are likely to have the same file size, so what’s the point? Just because it looks nice and fits perfectly on the mobile phone doesn’t mean it’s right.

  37. October 28, 2010

    […] links to note on fluid design and the one I’ve got the most Rethinking the Mobile Web. An here a complementary and interesting […]

  38. October 29, 2010
    Neal G said...

    I actually did some research on browsers downloading images with media queries being used. I think this would clear up some of your concerns about the issue – http://www.nealgrosskopf.com/tech/thread.php?pid=73

  39. October 29, 2010
    Raf said...

    Interestingly—and very on topic—your overthinking of the mobile experience made my experience of reading your article much more complicated than it should have been.

    I found the article via Twitter on my iPhone, opened the mobile version (when asked which one I prefered) and ‘Instapapered’ it for future reading on the iPhone or Kindle. This is how I usually read articles on the phone.

    To my surprise when reading it offline, the mobile version was originally paginated and the article my Instapaper had saved for offline viewing was actually only 1/5 of the article.

    Had I instapapered the “desktop” version, I would have gotten the whole article.

    This goes to show how many variables come to play when trying to provide the best mobile experience and that sometimes the best solution is the simplest one.

    There’s more to article pagination. Mobile means we are not always-on. Imagine I am on a train, reading the first page of your paginated-for-mobile article. The train goes into a reception-less zone just when I am about to click to page two—another case of paginating of the article for mobile being a bad idea.

    Another thing, I tried using Kindle web browser (it is an implementation of Webkit) to read your blog. The comments’ section contrast is so low, it is not really legible. When I switched to the mobile version (I had to put ‘m’ subdomain before the url, not every user knows to do that), comments would not load at all, no matter how hard I clicked.

    Just thought I’d report the above, hope that helps!

  40. October 29, 2010

    […] interessant artikel over responsive web design en waarom het niet zo’n goed idee is als het lijkt – en mijn […]

  41. October 29, 2010
    James said...

    Hi Raf… that’s all good feedback.

    Certainly there are many cooks involved, and spoilt broth may well be the result… (Just be thankful I defend against carrier transcoding!)

    As for pagination, I agree that I think i can start to turn that down for better scrolling devices – although of course pagination is rife on the desktop web too, so Instapaper should probably think about that anyway.

    We need to transcend concerns about formatting and syntax… I think you’ve illustrated that the user’s context, as well as possibly requiring different content and service, also demands a sympathy to the many online/offline scenarios that now arise.

    I’m currently exploring how to revisit CMS thinking in more mobile app-like ways, which may very well mitigate some of these issues. I’ll report back 😉

  42. December 10, 2010

    […] has been some critique too but I agree with the valid points Jeremy Keith makes in the comments and in his post linked to […]

  43. February 14, 2011

    […] Not a mobile web, merely a 320px-wide one « James Pearce […]

  44. April 18, 2011

    […] Not a mobile web, merely a 320px-wide one ← Debuggen, hoe doe je dat? […]

  45. May 14, 2011

    […] opposite from that on a desktop, afterwards regulating Separate Sites is simply expected to be a most unsentimental choice. This is since we have a choice of promulgation totally apart HTML, JavaScript, and CSS to phones […]

  46. June 14, 2011

    I have learn several good stuff here. Definitely price bookmarking for revisiting. I wonder how a lot attempt you place to make one of these magnificent informative web site.

  47. June 21, 2011

    Great tips. I’ve found some real differences between some VPS hosts, mainly in their firewalls and options (UK2 being very forgetable). I was recently with Amazon EC2 which was great for a while but then its connection fell over – it locked up 4 times in 4 weeks and four times had to have a config tweak to correct the storage. The hardware had some issues. I tried Dediserve (http://www.dediserve.com/) and since joining they’ve been fine!

  48. June 22, 2011
    Robyn Ronhaar said...

    Excellent article. I wanted to write down a opinion yet located I needed an excessive amount of to say. My goal is to write a triond article in answer to your question.

  49. June 23, 2011

    We are a group of volunteers and starting a new scheme in our community. Your website offered us with valuable info to work on. You have done a formidable job and our entire community will be thankful to you.

  50. June 27, 2011
    Craig McPheat said...

    Going through the media query experience at the moment, good read thanks for adding to the opinions.

Leave a Reply