State of the web: of apps, devices, and breakpoints

IN The ‘trouble’ with Android, Stephanie Rieger points out the ludicrous number of Android screen sizes on a typical UK client’s website and comes to this conclusion:

If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

I urge you to read the entire article—it’s brief yet filled with rich chocolatey goodness.

Responding to it, Marc Drummond concludes that responsive web design default breakpoints are dead and urges designers to “use awkwardness as your guideline, not ephemeral default device widths” and return to fluid design. (I believe he may actually be thinking of liquid layout—the kind we practiced back in the early mid-1990s when cross-platform and multi-manufacturer desktop screen sizes and pixel-per-inch ratios—not to mention strong user font, size, and color preference options—made fixed-width layout design challenging if not impossible. As I understand fluid design, it is merely another word for responsive design, in that it relies on CSS3 media queries set to breakpoints.)

We’ve lost our compass

Rieger and Drummond are hardly alone in feeling that “our existing standards, workflows, and infrastructure” cannot support “today’s incredibly exciting yet overwhelming world of connected digital devices” (futurefriend.ly) and that something new must be done to move the web forward. And of course ppk has been warning us about the multiplicity of platforms and viewports on mobile since 2009.

Agreed: that is an exciting and challenging time; that fixed width layouts do not address, and adaptive layouts (multiple fixed-width layouts set to common breakpoints) do not go far enough in addressing, the challenges posed by our current plethora of mobile screen sizes, zoom settings, embedded views (i.e. “browser” windows inside app windows, often with additional chrome) and what Rieger calls “the unintended consequences” that occur as these various settings clash in ways their creators could not have anticipated.

As consumers, we’ve all had the experience of seeing the wrong layout at the wrong time. (Think of a site with both mobile and desktop versions—whether these versions are triggered by CSS3 media queries or JavaScript and back-end magic is beside the point because technology is beside the point—good user experience is all this is supposed to be about. On a Twitter app on a mobile device, the user follows a link; the link opens in the browser built into the Twitter app. Which version of the site does the user see? The mobile one or the desktop? Often it is the desktop, and that can be a problem if the app’s version of the browser does not permit zoom. Even if it is a mobile version, it may be the wrong mobile version, or it may not fit comfortably inside the app’s browser window.) Considering our own experiences and reviewing Rieger’s chart, it is easy to share Drummond’s conclusion that breakpoints are dead and that all sites should be designed as minimally as possible.

If breakpoints are dead, responsive design is dead

Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints both in creative workflow and as a key to establishing user-need-and-context-based master layouts, i.e. a minimal layout for the user with a tiny screen and not much bandwidth, a more fleshed-out one for the netbook user, and so on.

But responsive design is not dead; it has only begun. It is not a panacea but was never intended to be. It is simply the beginnings of an approach.

I respect those colleagues who say breakpoints are dead, understand how they reached this conclusion, and am eager to see where it takes them in the coming months as they experiment with new methods, perhaps developing wonderful and unforeseen best practices. I hope design will be a brilliant part of these new methods, not something that gets abandoned to create a bland but workable lightweight experience for all.

But I also believe it is possible to draw a different conclusion from the same data. It is even possible, I believe, to say the present data doesn’t matter—at least not in the long run.

Tale of the chart

There was a time in the late 1990s when industrious web designers showed how atrocious CSS support was in browsers. Eric Meyer’s Master Compatability Chart for Web Review, formerly at http://www.webreview.com/pub/wr/style/mastergrid.html, was one of the best, but is no longer available for your historical viewing pleasure—not even at the mighty Wayback Machine. That’s too bad, as it would have perfectly illustrated my point. The chart used a variety of colors to show how each detail of the entire CSS specification was or was not supported (and if supported, whether it was supported correctly and completely, partially and correctly, partially and somewhat incorrectly, or completely incorrectly) in every browser which was available at the time, including, if memory serves, close to a dozen versions of Netscape, Explorer, and Opera.

Looking at that chart induced nausea and vertigo. It was easy to draw the conclusion that CSS wasn’t ready for primetime. (That was the correct conclusion at the time.) It was also easy to look at the table and decide that table layouts and font tags were the way to go.

That’s what most designers who even bothered looking at Eric’s chart decided, but a few (Eric and me included) drew a completely other inference. Instead of trying to memorize all the things that could go wrong in each browser, we created general rules for what worked across all browsers (e.g. font-size in px, floats for layout) and advocated design based on the things that work. This, I believe, is exactly what the futurefriend.ly and Move the Web Forward folks are doing now: trying to figure out commonalities instead of bogging down in details. (This is why some in our community have labeled futurefriend.ly and Move the Web Forward “WaSP II.”)

The other inference Eric, I, and others in the 1990s drew from Eric’s chart was that browser makers must be petitioned to support CSS accurately and correctly. We and many of you reading this engaged in said petitioning, and thanks largely to help from with the browser engineering community (from people like Tantek Çelik and Chris Wilson and organizations like Mozilla) it came to pass.

Of mice and markets

We cannot, of course, petition all the makers of, say, Android devices to agree to a set of standard breakpoints, because there are over 500 different Android devices out there, many of which will fail in the coming months—or if not outright fail, simply be replaced in the course of planned obsolescence AKA upgrading that drives the hardware segment. And each new product will in turn introduce new incompatibilities (AKA “features”).

In the short run it’s going to be hell, just as the browser wars and their lack of support for common standards were hell. But it is the short run.

500 standards is no standard. Give a consumer 500 choices and the price-driven consumer picks what comes with her plan, while the selective consumer begins gravitating toward a handful of emerging market leaders. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.

Until that time, designers certain can abandon breakpoints if they can find a way to do good design under purely fluid conditions—design that pleases the user, satisfies the client, and moves the industry forward aesthetically. But designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports. This I believe.

When I see fragmentation, I remind myself that it is unsustainable by its very nature, and that standards always emerge, whether through community action, market struggle, or some combination of the two. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years. We are on the edge of something very new. Some of us will get there via all new thinking, and others through a combination of new and classic approaches. Happy New Year, web designers!

79 thoughts on “State of the web: of apps, devices, and breakpoints

  1. Lovely write-up, Jeffrey. I’d add one thing:

    Of course, if breakpoints are dead, responsive design is dead, because responsive design relies on breakpoints…

    There’s nothing that says our breakpoints, whether in our designs or in our CSS, need to be pixel-based. Marc and Stephanie’s essays reinforced something I’ve been thinking for some time: that while px-based breakpoints quickly obsolete themselves, they’re not our only option. As I mentioned on Twitter, em-based breakpoints have the benefit of being tied to our content, and might present a more future-proof alternative. The folks at Front have been experimenting with this, and Paul Robert Lloyd’s design is a beautifully responsive design that just happens to be em-driven.

    As you said, this is a terrifying and exciting time. Can’t wait to see what happens next.

  2. Hi Jeffrey!

    I guess I wasn’t clear enough in my post. I love responsive web design! I simply think that using breakpoints based on device sizes (320px, 480px, etc.) isn’t the best way to go anymore, because there are so many devices that don’t have those device sizes, or because content might not appear within a browser width that matches that default device size. Instead, I still think that breakpoints should be set, but they should be based on the natural breakpoints found within the content, a content out approach. Maybe things look awkward at 350px or 570px or whatever. And the same principle applies if somebody sets breakpoints based on ems, rather than px. I’m just saying to find those points where things start to look wonky, and use that as the basis for a media query. I’m pretty sure Ethan Marcotte has advocated this approach as well.

    Also, I did mean fluid design, as in the fluid grids and fluid images, which Ethan discusses extensively.

    I’ll put this clarification on my post as well. Thanks!

  3. Marc, I thought your point is quite clear. I use breakpoints based on my design rather than device sizes. That way I don’t have to worry about my site looking awkward on different devices.

    Happy New Year, Mr. Zeldman!

  4. In the book and elsewhere, Ethan (and many others) have been clear that responsive web design is a method to make a site work on any number of known or unknown devices; the core principles of a fluid grid and flexible images mean that no matter what screen size you throw at a site, it will work. This is the beauty of responsive web design, and why it only gets more and more important as the number of devices increases.

    So, if breakpoints are dead, responsive web design is king.

  5. Another thought: it’s not as if you can’t keep using common device sizes as breakpoints. If you are using a fluid grid and fluid images, there is a decent chance that a layout with a slightly different width will still look ok. I think what is important is to acknowledge that those breakpoints are not the only widths your design will encounter on its great adventure through the world wide web. It may be that when your design encounters a browser width slightly larger or slightly smaller than the one you envisioned based on common device sizes, your design may have a sad, and not look quite right. In that case, you might be better off finding a more natural breakpoint that may not exactly coincide with common device sizes, but could of course be fairly similar.

  6. Mandy:

    I just meant that setting breakpoints based solely on a few common device sizes may not always fully capture the wide range of actual browser widths that are out there (although using fluid layouts, as Ethan advocates, definitely will help layouts still work in most device and browser width). I still very much advocate setting breakpoints using media queries within a responsive web design framework.

    Using the word “dead” was probably not the best choice I could have made in order to convey this sentiment.

  7. Why not just use both? Control which layout a user will see based roughly on their breakpoint, but also have the flexibility of a fluid layout. That way the user always sees the layout they should see.

  8. I think there needs to be a distinction made between Responsive Design and Media Queries. In the same way that just using CSS doesn’t automatically make your site more accessible than using tables (your content could be a bunch of divs, for instance), just using Media Queries doesn’t automatically make your site truly responsive. The technique is the methodology, not the technology.

  9. I don’t think breakpoints are dead; in fact I believe they remain an essential aspect of the responsive design workflow.

    The Problem only arrives once these values are based on arbitrary screen dimensions or device features. I advocate using breakpoints that take their lead from the content (again, content first). For example, a design doesn’t adapt because the viewport has narrowed, but because a certain line length becomes excessive, or a long heading takes up too much space. This approach, in addition to testing on as many different devices you can muster (with tweaking applied as you find necessary) is where I’m headed.

    As always, it’s a balance between ideology and pragmatism. Happy New Year Jeffrey!

    (Sidenote: Once again thanking Ethan for advocating my site as an example of em-based responsiveness. Cheque is in the post!)

  10. What I don’t get is: why, instead of embracing the fact that devices will come in various shapes and sizes, are we actively hostile to this and call it “fragmentation” with such negative connotations? Why are you hoping for a standardisation on screen resolutions, with the prediction that the more exotic devices will likely fail? And why don’t we, instead, revel in the fact that we’ve wisely moved away from pixel-perfect designs that absolutely require a particular resolution/screen size/browser/input modality, take our learning from the past (fluid, elastic, responsive, adaptive and whatever else you want to label them) into this new and exciting world of multi-screen goodness?

    The idea of breakpoints, as any other technique, can be abused. If it’s simply seen as a “I’ll use the measures of my favourite iDevices as an absolute breakpoint”, then yes, having different devices and screen sizes (outside of the i-based monoculture) can obviously throw a spanner in the works. However, I thought that RWW would be particularly suited to dealing with the “fragmented” reality of devices out there? Treating breakpoints as a generic “if the screen is smaller/thinner/taller than this, it makes more sense to arrange content in this particular way” would still work fine, no?

    (On a related note of abusing technologies, don’t get me started on “mobile” sites that set an apparently very flexible and adaptive width=device-width, but then still assume in the rest of their CSS that this actually equates to 320px, just because that happens to be the case on a particular device they tested…see for instance mobile flickr. Yes, for THOSE sites/designers, this “fragmentation” is bad, but only because they completely missed the point)

  11. I guess it makes mores sense than ever that content sets the breakpoints, the other day, in a meeting the projector forced the screen on a mac using Safari to 800×600 px, wreaking havoc on a design made for iPad and Android breakpoints and the such.
    But the same layout, below 760 width was made for content breakpoints with fluid layout and it is beautifull.
    They had a working IE6 there too.

  12. Hi, Marc!

    I love responsive web design! I simply think that using breakpoints based on device sizes (320px, 480px, etc.) isn’t the best way to go anymore, because there are so many devices that don’t have those device sizes, or because content might not appear within a browser width that matches that default device size. Instead, I still think that breakpoints should be set, but they should be based on the natural breakpoints found within the content, a content out approach.

    I love “content-out” as a strategy and didn’t initially get this from your brief post. I can see how setting a series of breakpoints based on ems (based in turn on font size) could create lovely context-based layouts that move fluidly from one state to another. They won’t match with device sizes but they won’t be trying to. There is a lot to think about and play with there.

    Ethan’s comment, and his link to Paul Robert Lloyd’s site show that this can work in a website that is “designerly,” although I haven’t tested in a PPK’s worth of mobile devices to see how that design holds up in the various contexts mentioned in Stephanie’s article and mine.

    I think we all agree that there’s no need to despair over or even worry about the insane plethora of device breakpoints out there (even if we reached the same conclusion from different angles). I’m glad we also agree that responsive design is an approach that works because it is agile—and that how we approach responsive design is still emerging (still fluid, if you will). :)

  13. Patrick:

    Why are you hoping for a standardisation on screen resolutions, with the prediction that the more exotic devices will likely fail?

    This will happen whether I hope for it or not ;) and when it does happen it will be easier for more kinds of design to work well for more users.

    But I see your point, just as I saw Marc’s point even when I thought his point was simpler (i.e. before he clarified his point with comments here).

    One issue for me is that some designs resist fluidity, want to be fixed (or want to be a series of fixed widths). I don’t think this is “bad” and I don’t think this fact will go away.

    Also, if you remember the 1990s as well as I do, you’ll remember that liquid design was often a precursor to no design or bad design. As a designer I often struggled at the time to reconcile what I knew about usability and about the unpredictability of platforms and devices with what I knew about design and the best way to present certain kinds of content. Some of liquid design’s staunchest advocates at the time were also terrible designers or non-designers who believed design was unnecessary, impossible, or beside the point on the web.

    Today’s advocates of responsive design are designers first, and that makes a huge difference, but not everyone who follows leaders understands them, you dig?

  14. Mandy:

    So, if breakpoints are dead, responsive web design is king.

    No, if breakpoints are dead, responsive design is dead. What Ethan and Marc are now talking about is substituting a different kind of breakpoint for the px-based breakpoints we started with. That makes a lot of sense and is almost certainly the best way to go forward with responsive design—although designing for common px-based breakpoints also works; may work better for some designs and some designers; and is not really a problem in my view, for the reasons I outlined here.

    For the reasons I explained, I don’t worry too much about these little inconsistencies and I don’t believe breakpoints or even adaptive design are dead.

  15. “This will happen whether I hope for it or not ;) and when it does happen it will be easier for more kinds of design to work well for more users.”

    Hard to believe this coming from one of the first to shout that web design is not print design, and the curator of ALA with seminal articles like the Dao of Web Design. So, you’re all in favour of elasticity, adaptation, etc…as long as it’s “not too much” and falls within a tightly defined and standardised set of sizes?

    Even looking at the desktop space, yes…monitor sizes usually follow some standard, but whether or not users have their browser maximised or not is still uncertain. We don’t complain there about “fragmentation” and ask for browsers to force maximized views…so what makes mobiles so different? Is it just because you want that pixel-perfect, app-like experience?

    “Also, if you remember the 1990s as well as I do, you’ll remember that liquid design was often a precursor to no design or bad design.”

    Every design trend/technique can lead to abuses, especially because people get religious about it rather than seeing it as what it is: a tool. Witness today already the uninformed calls of “RWW leads to boring design” and similar nonsense.

    I’d poo poo designers/developers calling for “no design” the same way that I’d seriously question people calling for a standardisation on screen sizes, to be honest. Embrace the fluidity, don’t fight it…

  16. “designers who persist in responsive or even adaptive design based on iPhone, iPad, and leading Android breakpoints will help accelerate the settling out of the market and its resolution toward a semi-standard set of viewports”

    Almost sounds like you’re calling for a boycott of anything that doesn’t match your view of what should be a standard (but at least it’s nice to see that it aknowledges that the mobile world isn’t just about iPhones and iPads). Frankly, this makes me doubt your commitment to Sparkle Motion… ;)

  17. Even looking at the desktop space, yes…monitor sizes usually follow some standard, but whether or not users have their browser maximised or not is still uncertain. We don’t complain there about “fragmentation” and ask for browsers to force maximized views…

    I agree. A website “optimized” for a certain resolution typically works fine whether the browser and OS have tons of chrome or very little, whether the browser window is maximized or not, and so on. We have made it work through things like centering against a mildly textured (or flat color) background, which enables the pixel-focused design to look good under varying conditions.

    And the same can be true of a responsive design with px-based breakpoints, even if those breakpoints don’t align exactly with the screen dimensions of the device in question, EXACTLY as on the desktop—only within tighter constraints, because the desktop has a lot more flab to play with; the screen on a mobile device is much smaller and therefore there is less “give” if you take a px-focused approach.

    so what makes mobiles so different?

    The screen on a mobile device is much smaller and therefore there is less “give” if you take a px-focused approach. That is the difference. There is less wiggle room.

    But there is still some wiggle room and that’s one reason I think all these size issues are less of a big deal than some practitioners imply.

    Is it just because you want that pixel-perfect, app-like experience?

    It’s not about what I want, actually, although as a user I do want apps to be px-perfect and made for my device.

    I did publish Dao of Web Design and was one of the first (although definitely not one of the only) designers saying the web is not print. I’m not opposed to responsive design: I convinced Ethan to write about it for A List Apart, urged him to write a book about it, published that book, and have been putting him onstage for the past three years to lecture about it.

    Pixel-perfect desktop web design was always a consensual hallucination (because of variances between operating system fonts, because some users turned off style sheets or JavaScript, because some users set their default font to be huge, etc. etc.) and yet often in our careers we have striven for it, sometimes with great success that moves the medium forward. Few would deny that nytimes.com is a great web design even though it falls apart if the user sets a giant default font size and tells her browser to override the stylesheet where font size is concerned. Design on the web has always, always been a negotiation full of unknowns and land mines. In spite of all that, we have often been asked to design sites from a fixed-width, px-focused perspective, and we have sometimes been quite proud of the results.

    It’s possible to support responsive design as a brilliant approach to a set of problems and to think of it as the way forward without treating it as religious dogma, and without deriding other points of view.

  18. “the desktop has a lot more flab to play with; the screen on a mobile device is much smaller and therefore there is less “give” if you take a px-focused approach.”

    Mobile devices/tablets have one advantage here, in my opinion: the zooming behaviour – at its simplest, with a dynamically redone viewport meta, but ideally (and yes, full disclosure, in my day job I work for Opera, and Opera are the ones that proposed this, etc) CSS Device Adaptation http://www.w3.org/TR/css-device-adapt/ which allows for surgically targetted viewport tweaks (rather than whitespace flabs) to pre-zoom to just the right width. Of course, this can still lead to issues with some image crispness, but that’s the next frontier of adaptive/responsive design, it seems, with the various image-serving techniques.

    “But there is still some wiggle room and that’s one reason I think all these size issues are less of a big deal than some practitioners imply.”

    Well, exactly. So the “fragmentation” isn’t such a huge problem, but a reality that we as designers just need to be aware of. It doesn’t mean throwing out all design, just like it doesn’t mean we should ignore the screen sizes we don’t like.

    “Design on the web has always, always been a negotiation full of unknowns and land mines”

    But you seem to be calling for some of those land mines to be cleared by getting everybody to only walk along a certain path (of screen sizes that you consider “standard”).

    “It’s possible to support responsive design as a brilliant approach to a set of problems and to think of it as the way forward without treating it as religious dogma, and without deriding other points of view.”

    I hope you don’t feel I’m deriding your point of view here, as it’s not derision on my part, just astonishment as the view espoused here seems orthogonal to your usual stance. Oh, ok, maybe pointing out that you’re at least aknowledging *leading* Android devices was a bit of a dig, admittedly…

  19. Few would deny that nytimes.com is a great web design even though it falls apart if the user sets a giant default font size and tells her browser to override the stylesheet where font size is concerned.
    “Great design”… if it makes a site unusable… == art, at least for those users. Something to hang on a wall and admire and say how pretty it is.

    Design on the web has always, always been a negotiation full of unknowns and land mines. In spite of all that, we have often been asked to design sites from a fixed-width, px-focused perspective, and we have sometimes been quite proud of the results.

    We’ve made art. We were not proud of it.
    It pleased the client. We got paid. We moved on.
    And at night we hear the sound of a thousand elderly fists banging their tables with frustration as they attempt to use the art.

    Maybe the environment *won’t* stabilise. Maybe our techniques will change instead.

    Frankly, these thousand-faces-of-Android can only help stop the “iPhone stylesheet” flu that’s been going around… which I’m sure is partially driven by developers asked to build “a mobile app” of a web site, and since they decide they must go native, and because they don’t want to write the Java version *and* the Objective C version *and* the HTML5/newt version… they just write for the iPhone and call it a day.

  20. It’s an interesting and challenging time. This isn’t just about web browsers failing to comply to some external standard. It’s a more dramatic shift:

    – Browsers are not living in 3 or 4 OS’s anymore. They are living in countless rebuilds and tweaked versions of various OS’s. Webkit is the starting point and then things go in many directions.

    – Apps are eating into browser time. It isn’t just about various browsers on various devices. Content is being stripped down to pure data and re-introduced inside of other experiences that aren’t even browsers. Think: Flipboard or Pulse.

    – The browser these days is living inside of apps. Most twitter clients have their own instance of webkit on most platforms. What do we do there?

    – It used to be your laptop and your phone. Now there are 7″ & 10″ tablets. 2-4″ screens on phones.

    In short: it’s getting more challenging. Control is shifting away from the “publisher” and being redistributed to the app maker and the end-user. Art direction is under threat and as the creator of Readability, it frankly scares me to end up in a world where content is just “data.”

    I hope we arrive at a place where designers can impose their will in some manner that even survives in the Flipboards of the world. How do we draft up something that allows for design to thrive as it gets attacked at all sides? What does that “standard” look like? It is no longer about the web. It’s a bigger challenge today.

  21. Patrick:
    “Why are you hoping for a standardisation on screen resolutions, with the prediction that the more exotic devices will likely fail?”

    Jeffrey:
    “This will happen whether I hope for it or not ;) and when it does happen it will be easier for more kinds of design to work well for more users.”

    I agree that this standardization on device resolutions will happen whether we like it or not, but I think it’ll be for a different reason: Apps. If we’re honest with ourselves, we as web developers have it a lot easier than a lot of application developers out there: there’s a lot of flexibility in web apps that is hard to replicate in non-html applications. If anything, I think that’s why device resolutions will begin to standardize.

    That said, we shouldn’t wait for standardization here – we should defer to reality and play with what we’re given. Responsive design, done well with fluid layouts, wins.

  22. You know how when you go to Lowes to buy a new faucet or doorknob or window for your house, they have it? Maybe you have to take a few measurements to see if your window is 24 or 36 inches wide, but you can reasonably expect Lowes to carry windows in widths of 24 and 36 inches. That’s because most modern construction components have standardized measurements. This lets manufactures move more products to builders, who can expect that as long as they build within a certain set of measurements, there will be a component to slot in when the time comes. No custom carpentry, no waiting for weeks for 29.5 inch windows to come in.

    If you own a house built before this glorious time in manufacturing, you probably have a lot of money or don’t do a lot of repairs or upgrades. These houses require custom everything, because they were built at a time when builders defined their own set of standards on site (get it? “On site”?).

    Right now, with mobile device screens and to a lesser extent with large desktop screens, manufacturers are each setting their own standards. We, the carpenters, have to custom-make everything if we want a “just so” fit, which, like that Victorian Painted Lady, costs the owners a bundle.

    There are only 3 ways this can go down:
    1) We wait for the manufacturers to stop trying every screen size under the sun. Maybe one day they will! Maybe…
    2) We define the standards for them by designing to an agreed on set of dimensions. There are some pros and cons to this if you think about designing for anything that isn’t just glorified text on a screen.
    3. We stick with Responsive (the fluid kind, not the breakpoint kind) Design.

    Unless the tide turns against Responsive Design, I’m placing my money on #3.

  23. I agree that this standardization on device resolutions will happen whether we like it or not, but I think it’ll be for a different reason: Apps.

    Chris: Agreed, the platforms with the most apps will dominate (because of network effects), and those who design major apps will demand that devices support the same specs—and they’ll have the leverage to make it happen.

  24. Control is shifting away from the “publisher” and being redistributed to the app maker and the end-user. Art direction is under threat and as the creator of Readability, it frankly scares me to end up in a world where content is just “data.” I hope we arrive at a place where designers can impose their will in some manner that even survives in the Flipboards of the world.

    Rich: Me, too.

  25. it’s getting more challenging. Control is shifting away from the “publisher” and being redistributed to the app maker and the end-user
    […]
    I hope we arrive at a place where designers can impose their will in some manner

    i’m seriously surprised to see the return of this mentality. if anything, i’d say the learnings from almost 12 years ago are even more relevant today then…

    The Sage

    “… accepts the ebb and flow of things,
    Nurtures them, but does not own them,”

    http://www.alistapart.com/articles/dao/

  26. Patrick: Respectfully, and with love, I think you might be misinterpreting what is meant by “a place where designers can impose their will in some manner.” If you oppose the idea of designers even influencing the visual experience, then what is a designer’s job? :)

  27. “influencing” vs “imposing” … seemed to me there was a difference in forcefulness there. I’d associate “imposing” more with things like preventing zooming, or resizing text, or reflowing to make something more readable. :)

  28. I think there is a perfectly conceived unit for the web: percent.

    Mix percent and breakpoints-based media queries, you have more than enough as a designer to propose an experience optimised for any given electronic medium.

    In the end, what we look for is proportions, controlling hierarchy and focal points.

  29. So, is it safe to say that ANY responsive or even adaptive designed website is better than a site not having these at all?

  30. I hope we arrive at a place where designers can impose their will in some manner that even survives in the Flipboards of the world. How do we draft up something that allows for design to thrive as it gets attacked at all sides? What does that “standard” look like? It is no longer about the web. It’s a bigger challenge today.

    Respectfully, and with love, I think you might be misinterpreting what is meant by “a place where designers can impose their will in some manner.” If you oppose the idea of designers even influencing the visual experience, then what is a designer’s job? :)

    Hoo boy, that’s a can of worms but I’m drinking so, as a designer, I’ll tackle it.

    A designer’s job is not to deliver visuals.

    While the realization has taken (and is still taking) time to clarify throughout the profession, a designer’s job is to deliver desired content in a welcome and, ideally, delightful visual interface. When adapting a design to smaller screens, a designer may choose to strip out or modify visual elements, but what is never sacrificed is the desired content. Flipboard doesn’t remix a site’s visuals, it remixes what’s important—desired content. The above quoted statements—though I know this is not the intention—could be interpreted as valuing the corner radius of a rounded rectangle over the content it contains.

    “Imposing their will [on the Flipboards of the world]” paints designers as not only ambivalent to their job of delivering content, it implies a resistance to the emergence of many potentially delightful ways content can be delivered. Instead of drawing battle lines, I would hope the existence of Flipboard-type apps further underscores how important it is for designers to hone an intimacy with content that allows them the ability to separate the critical from the redundant, the desired from the extraneous. This skill is what will ultimately serve any design in any screen size or context best, even (and especially) if that context strips out all of the original visual elements.

    That the Flipboards of the world exist prove design is something users desire—which is the complete opposite of an attack on design. Designers can certainly use this as impetus to create even better interfaces that woo users away from Flipboard as long as we don’t lose focus or become curmudgeons. We begin to endanger the design profession when we disallow our world to grow.

  31. I’m confused. Admittedly this doesn’t take much (especially when my son wakes me at 5am, like today). But I digress.
    I don’t think breakpoints are dead, I think people’s thoughts that you would only need to use MQs for 320, 480, 600, 780, 960, 1100 (for example) are wrong. Since the Boston Globe site was released I’ve used these breakpoints as a starting base to add to. I’ve done this because when ‘digging into’ the code I noticed breakpoints that would only change one piece of CSS, one font size or margin setting.
    The only way to go about noticing that you’d need to change a bit of css at a certain viewport (not screen size) is to test it. I’ve only worked on (really really really) small sites but I’m constantly resizing my browser to have a look to see what my fluid grids throw at me. This would then possibly lead to throwing in a min & max MQ to ‘fix’ anything that looks rubbish.
    Noting Jeffrey’s comment quoting Dan’s tweet. I’m also thinking we should remember that http://dowebsitesneedtolookexactlythesameineverybrowser.com/ should apply here.
    We’re not building the fixed pages of yore, we’re doing the best we can for our clients to provide a product that should work in as many browsers as their budget allows.
    I also note that Stephanie’s post discusses the screen sizes of all of these Android devices. Wouldn’t there be the possibility that their viewports are less fragmented? We all know there’s a difference, don’t we.
    RWD is still growing, it’s still early, we’re still learning stuff. It’s a wonderful time to be in this industry. We should embrace the chaos of screen sizes (well, viewports) and continue our work accordingly.

  32. I really love the idea of basing the breakpoints around the content, rather than being bound to device screen widths – and relying on a fluid design to fill in the gaps in an elegant fashion.

    I think sizing widths in Ems is probably valuable as well, but possibly a different discussion to be had.

    I’ve thrown a few quick thoughts on this together over at my blog.

  33. The problem with web design at the moment is as highlighted, there’s simply too much to take into account and too few tools built for the job. We’re getting there and making the right steps with RWD and OneWeb approaches for sure but I posted this recently as my *take* on describing what I do for a living. It resonates with this a bit.

    Web design is
    … A series of best guesses on how to apply a set of rules and techniques that change faster than the terminology used to describe them with the aim of making something accessible to more than 7 billion* internet enabled devices (of varying screen size, power and performance) that we currently know about and an unimaginable variety that we don’t. Web design is …

  34. This is one of the best articles I’ve read that nails the exact problem I’m going through on my own blog. I’ve been a web developer for almost 15 years and have gone through all the old years of cross browser development. It’s still an issue but nothing like what I encountered before. Now, getting into mobile development and, in particular, Android, I’ve found myself doing the waiting game as I’ve found the mobile version of the site to be lacking and crippled when viewed on Android devices or even tablets. My thought now is either to bite the bullet and build for those devices natively, use a third party tool like Carbyn or just hope I cover most of the devices.

  35. I think there’s an important factor missing from this discussion, which Mark Boulton and a few others talked about recently: web advertising, and particularly standard-size ad units.

    Advertising may not be a technique (as Matt Wilcox suggested), but advertising isn’t always bad/ugly (and often necessary) and it certainly could be called a technique to design for it responsively. It gets dodgy to use all ems and non-“standard” breakpoints if you need to have leaderboards, medium rectangles, and so forth at specific pixel dimensions.

    Ironically, I know of two leading web-zines on web design/UX that just relaunched within the last month or so and neither are responsive according to my smartphone, and both rely on a lot of advertising.

    Nathan Ford talks about responsive ranges for advertising, which seems like a decent place to start. We’re trying something like that for the relaunch of TXP (targeted for February).

  36. I personally use a mix of fluid design (sizes in%, fonts em) and 3 or 4 critical breakpoints to recalibrate the fluids.
    The only fixed blocks are located in the upper left corner of the site on which the whole design is based.

  37. I don’t think breakpoints are dead; in fact I believe they remain an essential aspect of the responsive design workflow.

    The Problem only arrives once these values are based on arbitrary screen dimensions or device features. I advocate using breakpoints that take their lead from the content (again, content first).

    This, to me, is the king comment and Paul has taken the words right out of my mouth.

    It drives me a little crazy when people talk about breakpoints that match the resolution of some device. As I read more and thought more about the idea of responsive web design it didn’t take long to click that this was a way to control your content, not your devices.

    If we start at the lowest denominator (mobile first) and enhance our site appropriately as space allows then the devices will take care of themselves. These enhancements – or layout changes – vary depending on what the content is, not what the device is. Be it at 300 pixels, 800 pixels, or 5000 pixels. I can not go into a design project knowing what my breakpoints will be ahead of time. That’s why they are called breakpoints, not devicepoints. My layout changes when it becomes broken, not just when it gets viewed on an iPad.

  38. I find a large amount of web designers & developers have lost the point of responsive design and are as you say Jeffery caught up with basing breakpoints on device dimensions.

    Its obvious we need to make sure sites are optimised for the specific devices the client has specified in their brief, however they should just work. Why? Because the breakpoints should naturally be when the design reaches its limit. For example the menu gets too cramped, an image gets too small, or content gets too narrow. These are natural breakpoints which should be the focus of all our attention.

    Bottom line is when the design breaks, BAM, there is the breakpoint. Dan is correct in his statement with percentage based layouts natural scaling can occur between these natural breakpoints.

  39. “I love “content-out” as a strategy…setting a series of breakpoints based on ems (based in turn on font size) could create lovely context-based layouts that move fluidly from one state to another. They won’t match with device sizes but they won’t be trying to. There is a lot to think about and play with there. – Zeldman”

    There IS a lot to think about and designing content-out is quite liberating, but it’s also important to remember why we’re doing this.

    Designing content-out works quite well. We’ve used this approach for a while now and have found that if there are wonky/awkward spots when you test by resizing the screen on the desktop, they will in most cases end up just as wonky on devices. An approach that is working quite well for us at the moment is to design using major and minor breakpoints. (More of this in our Pragmatic Responsive Design presentation ).

    The major breakpoints create the broad stroke changes that are required when moving from the small(er) screen (‘mobile’), to a much wider one (often a tablet-like device), to an even wider one (often a desktop but increasingly there can be higher breakpoints for TVs etc). These major breakpoints are set using media queries in the document head. The minor breakpoints live within those 2-4 style sheets and provide (mostly) the tweaks needed to remove awkwardness. This in effect creates media queries within media queries and provides huge flexibility while keeping it clear why each breakpoint has been set.

    As noted earlier by others in the comments, these ‘tweaks’ most often include adjustments in font-size, line length, line height, gutters, padding and other elements that make the layout feel more balanced and improve legibility. Other useful tweaks are adjustments of the overall font size to ensure button/menu touch targets and form elements are large enough to manipulate on touch screens. If you’re going as high as TVs, text often needs to be enlarged quite a bit at that size so changes don’t always follow a predictable upwards or downwards path.

    Then you move on to final pragmatic tweaks to ensure nothing is wonky on key devices. (Some people would say you should do this first but I think this just encourages teams to think of it as a ‘device-x site’.) Most sites fall into an 80/20 pattern where you can easily identify the top devices (often a cluster of 10-15 devices which almost always include the iPhone and iPad.) Be mindful however of the remaining 20% which can include 20-30 (+) devices and may easily amount to tens of thousands of users a month.

    So while content should always guide the design (which also helps prioritize useful stuff like document flow, markup structure, and information design), the whole process works best as a balancing act between the opportunities and constraints provided by the medium.

    When all is said and done, the reason we’re even doing this is because of device diversity, which will likely not go away. We are well on the way to standardizing around WebKit but even if screen sizes also standardize (…big if), a device will always remain way more than just a screen size combined with a rendering layer. The problem with the (exclusive use of a) content-out approach is that it may be seen as an excuse for many not to think about the devices at all. As it stands, very few people currently test on actual devices (on actual 2G, 3G, etc networks). There are many reasons for this (cost being only one of them) but as an industry, we’re going to have to move past this somehow.

    Testing on devices reveals all sorts of stuff that simply adjusting content never will, and that you won’t see by simply testing by resizing a desktop browser.

    1. Without device tests you know nothing of the performance. Most modern CSS effects and techniques still work quite poorly on devices. Web fonts, CSS drop shadows, CSS gradients, CSS animations regularly grind sites to a halt (quite literally…that’s if they don’t crash the browser altogether). Testing on devices provides a reality check of just how far you can push the design and what range of devices it will work on. Sure some of these issues will improve due to better hardware but PCs are pretty advanced and we’re still building poorly performing desktop sites…i’d love to see those go away as well).

    2. Device capabilities (e.g. actual capabilities vs the boolean ‘pass’ the browser returns in a JavaScript test) can also only be tested on an actual device. Whether you choose breakpoints based on ‘popular’ screen sizes or not, you will probably end up compelled to use a 320px breakpoint simply because of the iPhone. At this size also sit older (often landscape orientation) BlackBerry devices, many Nokia feature phones and many brand new small, cheap Androids. This throws all sorts of varying capabilities into the mix at what appears to be a very safe, common breakpoint. Eventually some of these devices will go away but if you believe screen sizes will standardize, then it follows that within those common screen sizes there will always be some bleeding edge AND some older or ‘good-enough’ devices.

    3. Then comes form factor. It often feels as if new devices only support touch, but at least 30% of smartphones (and closer to 90% of feature phones) still have a keyboard (while others are both touch and type). There is no sign of this changing soon as a touchscreen greatly impacts a device’s bill of materials and a segment of users still prefer physical keys. The presence of any indirect manipulation control (be it keyboard, trackball, arrow keys etc) impacts how interactive elements behave and should be designed.

    4. Pixel density now ranges from about 150 to about 300 ppi. That’s a massive crazy difference. Testing on a desktop reveals nothing of this. Many OEMs have reset the browser viewport to preserve legibility but you still end up with all sorts of differences that should be considered in the design process.

    5. And finally comes the impact of the network. Latency is obviously a problem, often due to poor connectivity – but factors such as large numbers of concurrent requests from 3rd party services (Facebook widgets, hosted fonts etc) will also impact performance. Of course content itself may also be modified on many networks by server-side ‘tweaks’ and adaptations due to proxies, transcoders and related ‘optimisers’ which are all beyond your control.

    Just to be clear, content-out design makes a lot of sense, but we’re going to need a mixture of content, device, and capability-based breakpoints going forward. The only way to develop a good understanding of these factors is to truly begin experimenting with devices, just as we experiment with design. These devices (and ones we haven’t thought of yet) are the new ingredients of the web just as much as HTML5 or jQuery.

  40. Concrete and well-commented/documented EXAMPLES of how people have dealt with the various screen size issues discussed herein would go a long way toward helping us all work our way through this dilemma(s).

  41. Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge.”

    I don’t foresee this moment coming at all – it just doesn’t tend to happen in the open-source community, which prior to Android had never hit a point where one could say that open-sourced software was in the hands of the majority. Android could very well be leading something that results in common breakpoints never existing.

    Take a look at Linux-based operating systems – sure, you have the few leaders like Ubuntu and Fedora but there’s a whole ecosystem that’s been perpetuating itself for over a decade and there’s barely even any money behind it (unlike Android). Developing sites compatibile for the gamut of Linux users is still often a shot in the dark; we just tend to luck out due to the fact that it’s not a widely adopted platform.

    Now we have Android – a widely accepted platform that anyone can use for free, which has an established ecosystem of developers, home-brew communities, and hardware manufacturers. Anyone can hop on the Android bus and nearly everyone has in terms of building hardware. We’re seeing not only Android-based phones and tablets, but Android-based printers, refrigerators, car stereos, microwaves, watches… and this seems to be just the tip of the iceberg.

    Even if the secondary hardware market for Android never takes off with the consumers I think we’re still going to lose breakpoints in the tablet and phone space. When you have something as free and nebulous as Android there’s really no room for things to get comfy as they do with Apple, who’s dictating everything that happens in the iOS ecosystem – they have to set standards or they’re just throwing money into an internal logistics hole.

    Hardware manufacturers are constantly experimenting with Android form factors, not because they necessarily think they’re better – but because they’re trying to stand out in an otherwise homogenous market. It’s exactly why Amazon didn’t come at Apple with a 10″ tablet form-factor – their approach isn’t better, it’s just different and it’s working for them. Hardware vendors don’t have to worry about wasting money building new software foundations every time they want to make a double-screened, square, or triangle device.

    I don’t think anyone has really even begun to consider the implications of flexible displays, which are really just now starting to become serious possibilites in the hardware market – and really we’re already watching the smartwatch market take its first steps.

    While I wish it weren’t true, I think breakpoints are indeed dead. Things are too cheap, fast, and short-lived in the market for any sort of comeback.

  42. You know, breakpoints coming back is just as likely as blogs supporting a common commenting markup scheme; which I apparently neglected to follow as I italicized my entire comment.

  43. After reading this post at 5am (GMT) and commenting I thought I’d throw a quick little ‘boilerplate’ of Media Queries for ems based widths rather than px based. It can be found here –

    http://app.kodery.com/s/1075

    I think boilerplates and frameworks in general are fantastic but they will never be a ‘finished’ tool to use. They will always need refining for your specific site.
    Therefore this little boilerplate is based on my ‘starting point’ and possibly not yours, or yours, or yours at the back. You may need something completely different :o)

  44. Just to be clear, content-out design makes a lot of sense, but we’re going to need a mixture of content, device, and capability-based breakpoints going forward.

    Stephanie: Thank you for your wonderful, clear comments here, and for everything you do for this community.

  45. Breakpoints should be based on the DESIGN not the DEVICE. It has always baffled me that people used device widths as breakpoints when the design tends to break at sizes other than the target device width. For example, the design delivered to a screen width of 320px probably breaks at 400px, not 320px. Media queries should be testing the needs of the design at different widths, not the needs of a device width on the design.

  46. Im a huge advocate for RWD, but it is worth recognising, as Ethan and Jeffrey have always specified, this is just the beginning and isn’t a fix-all method. What’s great about RWD is the scope and depth to which it could -potentially – be pursued. A great example would be the endeavours of the Developers at the BBC – http://blog.responsivenews.co.uk/ who are looking to build a site that is responsive based on more than just screen size.

    I’m new to the world of web, i’m studying for a degree in Interactive Media, i’m in my final year, I want to be a Front-end designer when I graduate in April. So granted my “experience” would be limited in terms of history, but as someone that is currently in training, I feel there simply couldn’t be a better time to be in this industry – HTML5, CSS3, RWD and Mobile are such exciting and unpredictable developments.

    However, my perception of the idea that “breakpoints are dead” based on screen sizes is that there is a contemporary context we can compare against, which is our desktop browser. My understanding is that the common fixed width of a website was based on the browsers of the time – 780px wide website for a 800×600 screen, 960px for a 1024×786 screen – and 960 still seems to pretty much be the norm despite the fact screen sizes have massively surpassed 1024×786.

    However we are talking about mobile sites with dimensions or 320×480 as if there is no leeway in it. We know browser sizes are massively varied but if we know there are no mobile browsers that are above 360px (for example) and no narrower that 280px when in portrait orientation, why dont we build our sites with that tolerance in mind?

    We’d build desktop sites with exactly that leeway in mind – we didnt build sites with a wrapper of 1024, we built them with a wrapper of 960 .

    Building with percentages and em’s allows us to “accept the ebb and flow” and build with leeway in mind, so why dont we set the “breakpoint” at what would be accepted as just above the largest average screen size, build responsively and it will suit all within that tolerance. If the design is going awry, as we’ve established, we add another breakpoint.

    Basically, when we argue about the issue of the dimensions of a mobile devices not all being 320 x 480 and arguing about breakpoint locations, we are returning to the same mentality of pinning the site down to a px width, just like we used to with the 780’s and 960’s – and it is exactly that which we are trying to move away from, right?

  47. This is a very different time to that of the browser wars, and we need to be careful that we don’t apply lessons learned then to the situation we are now in.

    The number of and variety of devices and viewports which need to be supported can seem overwhelming, as can the job of making websites work on them. I think we need to take a step back, though, and focus more on the user experience. What kind of experience do we want to deliver to people in specific environments. I have conducted thousands of usability tests, and no-one has every said to me “the trouble with this website is that it’s not been optimised for this viewport.” I do, however, often come across people who get pissed off when they can’t get the full ‘desktop’ site on their smartphone. Unfortunately, many ‘mobile-optimised’ sites apply web app user experience patterns which often do not work on content driven websites.

    The whole situation is dire for users.

    If we focus on the user experience, then the situation becomes much simpler. There’s a great document on mobile web best practices:

    http://www.w3.org/TR/mobile-bp/

    So, as well as thinking about breakpoints, I urge developers to also consider how we create a consistent user experience. For example, how do we create a consistent navigation for mobile devices in portrait mode? We can’t use mobile app patterns, because they don’t work on mobile websites. And some solutions may work technically, like converting the nav into a form select, but I’m not convinced they are the optimum user experience.

  48. Scott Kellum:

    Breakpoints should be based on the DESIGN not the DEVICE. It has always baffled me that people used device widths as breakpoints when the design tends to break at sizes other than the target device width. For example, the design delivered to a screen width of 320px probably breaks at 400px, not 320px. Media queries should be testing the needs of the design at different widths, not the needs of a device width on the design.

    Thank you.

  49. This is a frustrating time to be a web designer, but it’s also the most exciting time in ten years.

    Amen.

    One thought to throw out there: I’m looking forward to the day when we can look at resolution AND size for a given viewport. 960 pixels on a 3.5″ iPhone screen is vastly different from 960 pixels on a desktop.

    In the meantime, this is an exciting and challenging time for screen-based design. There’s no reason to be bored.

  50. Jeffrey, I think there is one point in your post (already commented by others) which I think it would be worth clarifiying.

    Eventually this nutty market will stabilize around a few winning Android platforms (e.g. Kindle Fire) and common breakpoints will emerge. What The Web Standards Project achieved with browser makers, the market will achieve with phones.

    As you already know, Android is by its nature an O/S built to run in many (and very different) devices. This actually has being the main drive behind its success the last two years.

    In your comment, you are assuming that with time the majority of these other – different – devices won’t manage to get a significant market percentage and thus the available Android devices will limit to a small number. Personally, I don’t think that this will happen – and if it did – it would mean the end of the Android (which is a veery bad scenario). Android’s successful model is the same as Nokia’s five or ten years ago: Give the people a variety of phones, from very cheap ones, to very expensive ones so they always have a choice. The variety of Android devices promotes healthy competition: so you have a very expensive Galaxy SII, a cheaper Galaxy mini, and a buttload of other devices which seem very tempting compared to just one, 500€ iPhone. I think it’s for everyone’s interest if your wish/prediction didn’t come true!

    Anyway, the confusing point is here: How does pushing browser vendors to adopt standards compares to this situation? Back then, the goal wasn’t to stop Microsoft from making browsers, but to update its product, right? How can we on one side be advocating that RWD is the FUTURE because it handles the increasing number of devices, that “Responsive Web Design is web design, done right” etc and on the other wishing that these devices be limited “around a few winning platforms”? It just doesn’t make sense – or I’m missing something. To hell with it, if we end up having one or two leading smartphones, then why not go back to having separate desktop/mobile phone websites just as we did couple of years ago. I hope I am making myself clear…

    What I think is safe to say, and I’m pretty sure you’ll agree, is that CSS Media Queries opened up new horizons, RWD put them in the spotlight, and today we realize the technical limitations around these proposed methods. We might also have being a bit over-enthusiastic about it. It seemed too easy to be true!

    What we’re facing is definitely not the fault of smartphone manufacturers but our lack of a technology able to do proper device and context detection. You can say I watch too many movies, but I’m imagining of a technology able to detect not only the screen/ viewport exact size, but also the amount of information detail a user wants at a particular moment and serves him the corresponding content – by combining his location, heart-rate, palm humidity, pupil dilation or whatnot…

  51. So, is it safe to say that ANY responsive or even adaptive designed website is better than a site not having these at all?

    Yes, Brian, I think any responsive or adaptive design is better than nothing at all. Just as publishing to the web in any form is better than not being on the web at all.

    This is a fabulous discussion with a goldmine of lessons, and one can’t deny Stephanie’s observation that a variety of content, device, and capability-based breakpoints are necessary to reach the most people on most devices with the most control. But just remember, that isn’t web design in its purest form. Seeking the most viewers with the most predictability is the same as being in the print world. It’s what we as web designers typically rail against. If you want predictable results in all conditions, take up stone carving, not web design. =)

    Web design in its purest form is, as Luke Dorny suggests above, flowing text. And I believe he was being sarcastic when he said he would just go back to it, but it’s not just sarcasm: it’s truth. Progressive design, that old chestnut, tells us to start with the basics and layer on what we can, when we can, and never say it’s done. It’s always a work in progress. Progressive.

    So in mobile web design, if talk of breakpoints, screen sizes, operating systems, and device manufacturers makes your head hurt, welcome to the best and worst of times. The beauty is, you can help make someone’s content be seen anywhere and everywhere by using RWD and paying attention to mobile context.

    But start with baby steps and don’t let the leading edge scare you away from doing nothing at all. And most importantly, don’t give in too much to the desire to control in all situations. “Breakpoints” is merely a codeword for “multiple designs”. How many designs do you want to make for one site? If you want to design a dozen, go for it — it will certainly be viewable by more people. But is that really web design?

    Yes, yes it is. If this discussion teaches us anything, it’s a paradox where we fight between design control and content openness. It’s the Great Paradox that will never go away, and no matter which side you take, you’re always right. And also a little bit wrong.

  52. Excellent. Good to see a Smart Crowd here. But maybe i get a different crowd… my stats show more iPhones… but that may be the MKTG cycles of what i do.

    Its the dual orientation that kills me since i prefer a swipe navigation mode, and segmented content into swipe-page collections. I wonder how many of us focus on Swipe vs scroll? For me it started with HBO and CBS promo ( yes Jeff , its years later and I remain mired in Hollyweird workload )

    I ended up for the sake of sanity just making screens that tell you to rotate landscape or somaething, and then do e.preventDefault(); to keep pinch zoom at bay. Keeping honest – here is some of that
    http://cdn.ctnhd.com/hbo and http://www.tgw.tv – detect and go iPhone / iPad .

    I would love some crowd such as this one to craft a framework guide for those of us that live in the space to keep hand coded crafting a first choice.
    Happy New Year Old man…

  53. I don’t think responsive web design is always the answer. I do think it should be mandatory for a basic website. But I feel the actual design is being threatened.

    I understand if the budget is not there for a separate mobile site or native app. But the mobile experience shouldn’t be the same as the desktop experience. Not for every project at least.

    For larger projects, we should not need to compromise the desktop design and experience, just to make it responsive for mobile. If the time and budget is there, separate mobile sites should be created. And we can do so much more with the design and experience for those mobile sites.

  54. HTML and CSS is a failure of our cooperation as developers arrive at a solution (or rather choose the correct path) a decade ago.

    Until complete separation of content and design occur, we deserve the crumby user experience. It is within reach if we can remove the control of the platforms but apparently JavaScript will be the engine since the browser must be the vehicle. In the end, we will be force fed a dozen models to cruise around the info highway and hopefully not have toll roads everywhere by the time we get there.

    So much for flying cars…

  55. Breakpoints are flawed by nature, certainly in there current state where they are one-dimensional (screen/browser size) and forced up on the user (no way to overrule them).

    Breakpoint do (kinda) work in a mobile context where everything is small and full-screen, but responsive on desktop (or any other windowed-capable OS) is simply crap.

    Responsive has been an interesting challenge up to now, but it’s still very much a designer-thing and not so much a user-thing.

  56. Thanks for yet another insightful article. I’m intrigued by what Ethan pointed out on Paul Robert Lloyd’s website in that he uses em-based breakpoints. Definitely something to consider in future for me.

  57. Well, first off I have to say that the article, many of those referenced and all the comments have been a fantastic read. Thanks everyone who have written so far for providing a wealth of great insights.

    I have to admit though to being a bit flummoxed by the notion in the first place that breakpoints have to translate to specific screen sizes in order to work. I think Ethan and others from the very beginning used them to (as one commenter put it) ensure that the content breaks in a logical way when it no longer makes sense in that given layout structure (i.e. it’s wide enough to support two columns or conversely too cramped to support a 3rd, etc). I’ve always taken it to mean a range so that ‘anything up to 500 pixels wide’ would get one layout, and then check again once things like line lengths get too long, etc. to see if another layout change makes sense.

    So to me it doesn’t much matter how many devices there are out there – and I’m sure many will go away and more will come to replace them. Ethan’s approach still seems completely valid and it’s one I’m happy to have adopted on every project I’ve worked on in the past 6 months. It’s true -it’s only a beginning, but it’s the most rational and adaptable approach I’ve encountered in all my now 18(?!) years of work on the web.

    Cheers, and happy new year to all-

    Jason

  58. Would you believe as I took a break from designing a flexible interactive design pattern I found this article running in my feeds. Like many have already written, I have drawn some of the same conclusions whilst designing for so many devices and configurations. The confluence of these design problems really brings this old quote to mind:

    “The typographic grid is a proportional regulator for type– matter, tables, pictures and so on. It is a priority programme for a content as yet unknown. The difficulty lies in finding the balance between maximum formality and maximum freedom, or in other words, the greatest number of constant factors combined with the greatest possible variability.” – Karl Gerstener, 1961

    Currently I am working on an idea that takes learnings from using grids over the years, modern responsive design methodologies and some old architectural and typographical design patterns. Like all here I really look forward to sharing our thoughts as we tackle another challenge together. Onward forward:D

  59. With regards to breakpoints & media queries, if a user has a device that’s “close to” a breakpoint, but never triggers it because it’s (X) pixels off up or down from a common standard, could a solution be to incorporate another layer of variability? Say, a function that allows us to set “floor” + “ceiling” parameters, where we determine how close it needs to be, one way or the other, of a breakpoint, and then trigger that breakpoint for a better user experience on that device?

    Since there are a bunch of devices with “close, but no cigar” resolutions out there that will inevitably keep coming because of the nature of the industry to “one-up” the current leader, then “close” could be the exact target, not an exact pixel width, or height for that matter.

    Just seems like things get so granular sometimes. Milton Glaser said, “Simple isn’t better. Just enough is better.”

    Just enough can be a swing number. Subjective.

    Maybe we need to be more subjective and less exact in our measurements when deciding to trigger the best CSS for that device.

    If it’s close to an iPhone or specific Android device, we (the community) decide how many pixels, up or down, is good enough to warrant triggering the nearest breakpoint for a better experience.

    Food for thought.

  60. I was also wondering why the heck device makers don’t actively promote support for web standards as a key feature/differentiator/USP to consumers. Or, why web standards still feels exclusive to the geek-dome community. It’s open, but still feels closed because of “where” it’s communicated and lives.

    Think about it. I’m a consumer. I don’t care about “how” it works, but I do care about “that” it works.

    If web standards becomes branded (S), say, like the super sexy HTML5 (5), and it’s marketed on devices in myriad ways, people will invariably recognize that it’s a good thing, often without knowing what the heck it even is. It will gain merit, trust, and help consumers, as well as we creators of the stuff.

    “That” it works, and that “that” has an identifiable mark, is useful to consumers buying choices.

    The main takeaway from seeing this web standards (S) logomark would be that, as a consumer, I can see that this device is designed to make the most websites look and work the best. I don’t care how at all. I’m already sold.

    Consumers see “close, but no cigar” sites all the time on devices. A broken div here, a jostled header there, tiny fonts, and so on.

    “This device supports ‘Web Standards’! Whatever that is. See the cool logo?! It makes websites look great… or something. This device next door doesn’t have the (S) logo. Screw that. I I’ll buy the one with the (S).”

    Something like that.

  61. Pingback: Room 329

Comments are closed.