Device-Independent Design StrategyLooking Beyond Common Media Query Breakpoints

Advertisement

With all the talk about responsive Web design, designers and coders are moving even further from the fixed pixel layouts of design’s print-based history. We’re finally thinking in terms of fluid layouts and expandable, interactive content. But when you get down to it, we’re still thinking of the fluidity in terms of desktop, tablet and mobile sizes.

Chances are that your responsive websites have media query breakpoints at precisely the tablet and mobile widths, essentially creating three different versions of a website with the same code.

While this is much more ideal than what we’ve all done until now, it’s not always the best way to approach things. Often, our content breakpoints (the viewport widths where content should be reformatted) are different from common device breakpoints (the viewport widths that reflect physical devices).

When we code for only a general desktop size, a general tablet size and a general mobile size, we are forgetting about the infinite other shapes and sizes that our devices are and will be in the future (especially as TV becomes a more popular medium for Web content). We’re not truly utilizing the full potential of responsive design. We’re not truly coding for any device.


Image Source: opensourceway1.

Our goal should be to always present content in order of importance, no matter what size a screen is. There’s nothing wrong with using media query breakpoints at tablet and mobile widths (in fact, that’s a great start), but don’t forget about all the other possible sizes that a screen can and will be, and don’t forget that no matter how a user accesses content, there will always be a need for content hierarchy.

We’ve all read about what kinds of goals users have on each different device, but the fact is that Internet users will access the Web on any number of devices for any number of reasons. We can’t claim to know what the most important content is to them at any given point in time or from any given place, but we can make an educated guess as to what the most important content overall is and make sure that it always shows up before less important content.

Design is based on creating hierarchy and controlling what a viewer sees and when, so designing a website based on content hierarchy makes a lot of sense. It’s essentially what we all do now when we initially design a desktop layout, only instead of worrying about how the design responds in relation to content, a lot of designers make sure that the design responds in relation to aesthetics, letting content arrange itself organically. This is an oversight.

With good design systems (as opposed to just good design), I propose we focus our responsive efforts on the content, and not on the design alone.

One note before we get started here: a content-first approach doesn’t necessarily mean that a designer or coder needs all the real content up front. That’s a huge help, but in real life, that’s just not always possible. We might not know the exact content we’re working with when we start a project, but we always know the nature of that content, and we can usually guess how it ranks amongst all the other content on a page.

The Top-Down Approach

By definition, a user enters a website “at the top” and then scrolls down. In the past, there’s been a whole lot of focus on keeping important content “above the fold” so that users don’t miss anything. Well, I have a news update. In 2012, people know how to scroll. I’m not saying to bury important content below the fold, but just know that almost all Internet users these days know that with a flick of the finger or a scrollball roll, they can adjust their view of the page. Furthermore, a lot of savvy users will quickly scan an entire page2 before reading any of the content.

This means that we can and should sacrifice the precious “above the fold” space in favor of readability and usability. The most important thing is not that the content is viewable without scrolling, it’s that it’s digestible, clear and easily scanned when it’s on the screen.

Take the website CSS-Tricks3 as an example. There are several major breakpoints where content shifts around so that readers get the most important content first, based on what fits on the screen. Each different layout re-prioritizes content based on the available screen real estate.

CSS-Tricks does a good job of rearranging content for different viewport sizes.4
CSS-Tricks does a good job of rearranging content for different viewport sizes. Large view.5

When, Where and Why

We can safely assume that a “top-down” content hierarchy is almost always applicable, and we can plan all of our content to go most to least important, top to bottom. In the case of the desktop screen, we may have three columns of information, each with its own top-to-bottom content hierarchy. Then when the viewport gets too small, we stack the columns themselves from most to least important, top to bottom.

We can achieve this through a commonly-used, collapsible column system where containers are treated as inline elements, left-floated elements or both. Then we adjust these column widths with media queries in the stylesheet.

We use something like this in my company’s platform:

<div class='one-third column'></div>
<div class='one-third column'></div>
<div class='one-third column'></div>

And our styles go something like this:

.column { float:left; display:inline; }
.one-third.column { 
   width: 33.333333333% /* 320px / 960px */; 
}

@media only screen and (max-width: 767px) {
   .one-third.column { 
      width: 100%; 
   }
}

Note: The “only” keyword after @media is optional and only there so that older browsers ignore the media query if they don’t support it.

We can get fancier by adding another class to the first column, which we’ll say has more important content, and then adding a separate “in-between” media query for cases where we want a layout that’s a bit more custom.

As an example, when the viewport is wider than a certain amount of pixels, say 900, we can safely assume that three columns will fit in that area. When our screen real estate is less than 900 pixels wide, three columns would create reading areas that are too small. So we add a media query to break this into a single column on top that has the more important content, with two columns side by side underneath. Then at 300 pixels wide, we go back to three stacked columns that are full width.

<div class='one-third column more-important'></div>
<div class='one-third column'></div>
<div class='one-third column'></div>
.column { float:left; display:inline; }
.one-third.column { 
   width: 33.333333333% /* 320px / 960px */;
}

@media only screen and (max-width: 500px) {
    .one-third.column { 
      width: 50%; 
    }
    .one-third.column.more-important { 
      width:100%; 
    }
}

@media only screen and (max-width: 300px) {
    .one-third.column { 
      width: 100%; 
    }
}

Most responsive Web designers today will stop at my original code example. Their website will respond with media queries, but in a very content-agnostic way. I say we take things a step further like my second code example, and we create better content presentation with more thought and more media queries. Everything should be based around presenting content in a controlled and successful way.

When deciding on columns and column size, keep in mind that columns that are too wide6 are just as hard to read as columns that are too narrow.

With a nested column system, we can nest columns within each other to create a huge variety of layouts for different screen sizes. And, again, we should think about it in terms of content size, not device size. As it currently stands, most coders will add breakpoints at around 1024 pixels for a tablet and maybe 480 pixels for mobile landscape. (Feeling saucy? Add in 768 pixels to cover tablet portrait.)

I propose we start with those, but we add media query breakpoints wherever it makes our content look best, based on how that content actually looks. In addition to device size, media queries should be based on content, column width and most importantly… real-life testing.

If we do this correctly, our layouts will look great on a mobile phone and great on a tablet, even if we don’t do media queries at their exact widths. Why? Because our layouts will look great everywhere. A common theme that I see in current responsive websites are those little “in-between” glitches where the screen is too large for one media query (say a tablet size), but too small for the next one (a desktop size). With this new way of thinking, we know to adjust the widths in our media queries or add an additional media query to fix the glitch, regardless of the actual pixel value and what device it corresponds to.

A Common Example

A common example of this type of nested layout is the classic “sidebar.” Sidebar content is typically less important than a larger main column, so if the screen is wide enough to show both columns side by side, show them. If not, then the sidebar can get pushed below the main content.

In the end, when and how that content shifts comes down to screen size and readability, not device and device goals.

A Common Mistake

A common mistake that stems from coding for the device is when a designer knows that content should stack for mobile, but they forget to really look at that content at a mobile size.

Microsoft utilizes a responsive layout for their Surface7 tablet’s website, and so the design stacks to fit small screens, but the content itself doesn’t get enough attention, and therefore the website design falls short on small screens. The rows of content, each with a block of text and an image, stack on top of each other, but instead of stacking in a uniform, content-centric way, every other pairing differs as to whether the image or text comes first, creating a somewhat messy look. This could be solved with an alternating float:left and float:right on the image containers, but instead Microsoft relied on the default column resizing to create a “mobile version.” A little extra thought about the specific content on this page at this screen width would have gone a long way.

Microsoft's Surface website falls short on small screens.8
Microsoft’s Surface website falls short on small screens. Large view.9

Furthermore, I believe that Microsoft might have missed an opportunity on large screens to fit a couple image/text pairs side by side. On my 27″ iMac, there is arguably too much room around each content pairing, and therefore not enough control in the design.

For Microsoft to improve this website, they’d only need to go a little bit further. The design probably looks best on a laptop screen, where the images and text sit next to each other, one image/text combination per row. But on a larger desktop monitor, the website expands to where it looks too open, and the spaces around content become large and uneven. Another media query can put two image/text combos on each row, evenly separating the screen real estate on screens with enough of it. The font-size and line-height could be increased to accomodate for the available space and make the relation between text and the illustration a bit clearer.

Then, to regain consistency on small screens, the code needs a little adjusting for correct content hierarchy. Each image should be arranged in the layout before its corresponding block of text. It makes sense to code all of the image/text pairs the same way, because they’re most likely to have the same importance in relation to each other. Once they’re coded with the image first, they’ll stack perfectly on a small, mobile screen. For visual interest (repetition with variation) on larger screens, every other image can get a float:right instead of a float:left, and we’ll see the layout we see now with the image/text pairs side by side.

Won’t “Arbitrary Breakpoints” Take Longer to Code?

If you code for content from the beginning and add breakpoint when content dictates it, most screen sizes will just need a little tweaking in the stylesheet to help everything shift around.

In addition, once you have an initial responsive column system, entering the values for column-based percentages is as easy as copying and pasting. I’d argue that the amount of time to add a “special case” media query is the same amount of time that it takes to find a solution that lets content work without an additional media query.

Doesn’t the Importance of Content Change from Device to Device?

No. According to recent studies, 17% of all adult cell phone owners in the US access the Internet mostly on their cell phones10. This is due to the economics of buying phones and computers. If someone can’t afford both, the phone makes more sense because it makes calls and browses the Web.

In addition to that, because of the recent increase in mobile-friendly websites, people are more likely to access information right from their phone, wherever they are, even sitting at their desk in front of their desktop! This is especially true if the phone is the most handy device at the time.

This is why we can’t assume use cases or goals based on device anymore. So we need to code so that our content makes sense on a 300 pixel screen, not a mobile phone screen. We also need to make sure that if we only have 300 pixels to work with, the most important content appears first, the second-most important is next and so on.

Only by thinking this way can we truly utilize responsive design to accommodate future devices. And only through this mindset are we truly taking advantage of responsive design.

Have a look at architectural firm Andersson-Wise11‘s impressive and intelligent responsive website. The content shifts and reforms not only based on width, as most websites do, but also on height. The golden ratio is everywhere in this design, and if you play with your browser size, it’s clear that their goal was to present content as efficiently and clearly as possible, reacting to browser shape and size in a systematic and programmatic way.

Andersson-Wise always puts content first.12
Andersson-Wise always puts content first. Large view.13

In my opinion, the main quality that makes Andersson-Wise’s website better compared to the Microsoft Surface website is that there is no screen size or shape where Andersson-Wise’s website looks “undesigned” or out of control. The Surface website, in contrast, seems at times like the content is untamed and not specifically planned. If you imagine it as a static layout, it really only looks well-designed between 1,000 and 1,200 pixels, which is probably the size they started designing with. Other sizes “work,” but they don’t shine, like Andersson-Wise.

One more thing. The user probably doesn’t know anything about code or responsive Web design, and so they won’t be impressed that your website resizes. They do notice if your website doesn’t look good, though, and they know if content is hard to find or hard to read.

Keep in mind that we’re not creating desktop, tablet and mobile websites. We’re creating one responsive website. Look at and think about content at every size you can. Forget about the device, and fix little quirks with custom media queries. Invest in the future of your website and in the future of the Web in general.

Image source14 of picture on front page.

(cp)

Footnotes

  1. 1 http://www.flickr.com/photos/opensourceway/5537457201/in/set-72157628499533033
  2. 2 http://www.useit.com/alertbox/9710a.html
  3. 3 'http://css-tricks.com'
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2012/08/css-tricksScreenshots.jpg
  5. 5 http://www.smashingmagazine.com/wp-content/uploads/2012/08/css-tricksScreenshots.jpg
  6. 6 http://www.webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/
  7. 7 'http://www.microsoft.com/surface/en/us/about.aspx'
  8. 8 http://www.smashingmagazine.com/wp-content/uploads/2012/08/microsoftSurfaceScreenshots.jpg
  9. 9 http://www.smashingmagazine.com/wp-content/uploads/2012/08/microsoftSurfaceScreenshots.jpg
  10. 10 http://pewinternet.org/Reports/2012/Cell-Internet-Use-2012.aspx
  11. 11 'http://anderssonwise.com'
  12. 12 http://www.smashingmagazine.com/wp-content/uploads/2012/08/anderssonWiseScreenshots.jpg
  13. 13 http://www.smashingmagazine.com/wp-content/uploads/2012/08/anderssonWiseScreenshots.jpg
  14. 14 http://www.flickr.com/photos/r2i-social-networking/6925301398/sizes/m/in/photostream/

↑ Back to topShare on Twitter

Drew Thomas is the Chief Creative Officer and an owner of Brolik. Brolik is a digital agency based out of Philadelphia, PA with global clients like Everlast and Comcast.

Advertising
  1. 1

    Hah, go figure. Microsoft’s Surface site doesn’t respond properly. ;)

    6
  2. 5

    I was thinking the other day about a possible mobile-first semi-responsive non-fluid solution. This is where you design a fixed width 640px wide ‘mobile’ version of the site and then a 1024px ‘desktop’ version.

    You set the viewport to / meta name=”viewport” content=”width=640″ /. The website then snaps to 100% of that device’s width and loads up a mobile default.css

    Then on any device wider than 767px (the one and only breakpoint) we use javascript to set the viewport width back to normal, and media queries to serve up an additional desktop.css with the Desktop version of the site.

    In theory this should work but I’ve seen no sign of this non-fluid approach across the web. Which makes me think it’s impossible, or I’ve just invented it. Copyright 2012 John King :)

    3
    • 6

      The problem I see with your solution is that you are missing small tablets. which may fall down with your design.

      The second issue is an issue that foundation 4.0 is hoping to address is that when you design for pixels you have high retina and other ~200dpi screens as well as ~72dpi screens.

      Twitter’s bootstrap and Zurb’s foundation give a good idea of the scope of the problem.

      One other thing that we are just starting to do is get a base set of aural media style sheets.

      0
  3. 7

    This article gets even better when you take the grid out of your markup entirely. Instead of using multiple class names, use one class name and then within breakpoints change their presentation. I like that execution and wish that more framework or grid systems (if thats what you are in to) started to use it.

    0
  4. 8

    Great article. It goes to show that designing a website responsively is NOT as easy as one would might think – it requires tons of time!

    0
  5. 9

    I found this jQuery plugin that may help certain layouts on small screens = http://srobbin.github.com/jquery-pageslide/. Putting sidebars at the bottom is not always a good solution. For example on a blog when the sidebar acts like a navigation tool it seems like this jQuery plugin will be ideal keeping all the blog links like Categories, Recent posts, Archieve etc. front and “center”.

    1
    • 10

      This [jquery-pageslide] looks interesting. Must test this out for sure. What I like most is it’s manipulation of lateral screen space. I can’t believe I haven’t thought of something like this in all this time. Props for the share.

      0
  6. 11

    Great article, thanks very much! Just a question though, and apologies if this has been asked before; is there a good method (probably JavaScript) to loading different sized images depending on browser width?

    I only ask because on the “Andersson-Wise” website you provided as an example, the same large images seem to be used no matter what width I have my browser set at, meaning that I’d probably be loading an extra 250kb or so per image on a mobile device when it would be unnecessary. Is there a way around this?

    I could do this using various JavaScript “if” statements – just wondered if there is a ‘cleaner’ and more user-friendly (especially from an administration point of view) to do this.

    Many Thanks
    James

    3
    • 12

      You could use a technique where you add data attributes to an img element, say data-medimg and data-lrgimg, and based on the browser width swap out the original src of the img element using JS. The original src being the smallest size image.

      How would you know the width of the viewport, one way is to inject content in a media query with CSS and hide it, and use the word you inject at different break points as a JS hook. Jeremey Keith has a way of doing this on github part of another project, dont have any of the details on hand…

      0
    • 13

      Great question. Images are still a big issue with responsive design, and although there are some good solutions for the future of responsive images, there’s not all that much out there right now.

      I just so happened to have “released” my own responsive image jQuery plugin yesterday, called Responsive Img. responsiveimg.com It’s completely untested, except on my own website, but it should do just what you’re looking for.

      There are probably others out there, too, but I haven’t found one yet. I’ve tried many different workarounds, but ultimately ended up writing this plugin to try to solve the problem myself.

      Thanks for reading.

      3
      • 14

        Personally, I’m using javascript to set a viewport width cookie.

        On the server-side, if the cookie is set, it is read and used to load the correct image size, based on that viewport width. This is not perfect because it does not take network speed into account, but it’s a good start, better than nothing.

        If the cookie is not set (which is true on only the first visit or if cookies are disabled), server-side I will load the default image size, which in my case is the mobile (smallest) one. If it turns out that this file is too small for the user’s viewport, javascript will progressively load a better image, but as said, only in rare cases where the cookie was not set.

        It works nicely. I keep clean normal img elements in HTML, there are almost no double loads, and all logic is contained server-side without strange web server plugins. The only problem I can see is clients that have javascript disabled entirely, those will always get the default image size, which is not always the perfect one.

        0
      • 15

        Why don’t anyone use base path meta tag for responsive images?

        First use absolute paths for any static content – css, js, video, links etc, so base path has no effect on them.

        Then with simple inline JS in update [base] tag to something like this for small screens [base href=http://site.com/media/mobile/] or [base href=http://site.com/media/hd/] for us with 24 inch displays.

        0
        • 16

          We could even use for images is css files too!

          Just use relative paths for css files too and make sure they are in each size folder.
          CSS rule background: url(‘images/fancy_background.png’); located in /media/hd/style.css would load /media/hd/images/fancy_background.png

          While mobile users with base path = /media/mobile/ would get /media/mobile/style.css and corresponding /media/mobile/images/fancy_background.png.

          With tools like LESS CSS its too easy to have css file compiled for each size folder. With some simple tweeks we could even reduce CSS file size by not serving useless styles. HD user does not need mobile css rules and vice versa.

          0
          • 17

            Interesting concept.

            One minor detail, the HD images and the mobile images are often one and the same as 200dpi devices are more commonly a iPhone 4S,iPhone 5, or Galaxy III, with mac book pro retina and iPad3 being far less common on my sites.

            Another complication is that I use SASS instead of less and I tend to inline a lot of small images, so that will take some thought as well.

            But overall I like the concept. (now, can I figure out a way to make it work.)

            0
    • 18

      try scott jehl’s picturefill that mimics the proposed responsive picture element. https://github.com/scottjehl/picturefill

      1
    • 19

      James, the best method I know of is to use the max-width css declaration. This works incredibly well on all modern browsers, including mobile. I don’t support IE6 so it isn’t an issue in most of my work.

      I create images larger than normal (though still small in size) so they can easily re-size and expand when needed.

      Go here on different devices to see in action – jackmcdaniel.net

      1
    • 20

      I would recommend taking a look at Adaptive Images: http://adaptive-images.com

      “Adaptive Images detects your visitor’s screen size and automatically creates, caches, and delivers device appropriate re-scaled versions of your web page’s embeded HTML images. No mark-up changes needed. It is intended for use with Responsive Designs and to be combined with Fluid Image techniques.”

      2
  7. 21

    I feel like you are nitpicking a bit with the Microsoft Surface website example. In my opinion, it’d be extremely difficult to ensure a responsive website looks good without working from some type of break point. I’m just not sure it should arbitrary. I think even clients would rather see something tailored to an iPad or Surface tablet than say…here ya go I made this from some arbitrary size that I thought was cool.

    And AnderssonWise is a decent example but they use breakpoints as well. I’m not a huge fan of the completely liquid nature of the type either. Just go the press page and shrink the width to around 723px….the text becomes unreadable, not a great line length for reading. Imagine if it were a few paragraphs.

    A good example would be http://trentwalton.com/2012/06/19/fluid-type/ even though the type is liquid, the size changes with the screen width…

    4
    • 22

      Good point about the type. Part of what I’m advocating here is to make adjustments based on how content is presented, so in AnderssonWise’s case, if the type doesn’t read well at 723px, they should add a breakpoint somewhere around that size and make some adjustments.

      And to be clear, when I mention arbitrary breakpoints, I don’t mean just choosing random breakpoints. I’m thinking more about breakpoints that are dictated by content and that may not be specific device sizes.

      So, Microsoft could still make really nice versions for desktop, tablet and mobile sizes, but they should also add more breakpoints at “in-between” sizes to keep control of their design and content.

      1
  8. 23

    Great article. Based on some testing, I’ve come to like the following content-first approach (which happens to align pretty nicely with some commonly occuring device breakpoints, which still matter imho)

    Imagine a ‘newspaper layout’ (the hardest to make responsive imo) existing of max 3 columns with different blocks of content, with a couple of block-types posssibly spanning 2 or even 3 (hero) columns.

    requirements:
    – device-width: 300px up to 1200px

    solution:
    – 1 to 3 columns
    – ranging from 300px to 400px per column

    min: 1 col * 300px = 300px;
    max: 3 col * 400px = 1200px

    This means:
    – design each type of block in isolation (as in: independent of any other blocks) to be renderable fluidly between [300px, 400px]
    – some type of blocks need 2 (or 3) columns (say a big picture with text to the left), but these blocks handle smaller dimensions, allowing only 1 column by:
    a) – being designed to gracefully degrade to 1 column (say, by doing a clear:left on the text, hence, showing the text beneath the picture) or:
    b) – hide them altogether for 1 column (and possibly showing an alternative, previously hidden, block)
    – having some logic to determine the (re)ordening of blocks going from 3 to 2 columns and from 2 to 1 column. Mostly css should take care of it, but if this isn’t enough to keep important info floating above some reordening with javascript could be needed.

    In my experience this is a pretty powerful yet reasonably simple (because blocks can be designed/tested in isolation) solution to do newspaper-style layouts in a responsive way.

    some (as in: not all) common device resolutions: (NOTE: not taking column-gaps into account. This skews the below a bit, but not that much)

    320px (smartphone portrait) -> 1 column * 300 px + 20px padding
    480px (smartphone landscape) -> 1 col * 400px + 80 px padding (biggest problem)
    640px (small tablet) -> 2 col * 310 + 20px padding
    anything in between -> 2 columns fluid
    860px (tablet) -> 2 * 400px + 60px padding
    900 – 1200 -> 3* columns (variable size)

    Hope someone finds this useful,

    Best,
    Geert-Jan

    2
    • 24

      I love news paper-like layouts. However, one problem I’ve found with them is that if you want to have a true news paper layout, this would require overflow text spilling into the next column. While this is easy enough to do with print, varying screen sizes make it hard to do for the web. If you didn’t code it right the user has to scroll up and down to read it, especially if they happen to have a narrower screen. When the user gets to the bottom of the first column, they would have to scroll all the way up to the top again to see the rest.

      I’m interested in finding new ways to solve this problem since multicolumn layouts look great and are reader-friendly (and time-tested too– news papers have been around for a long time and similar layouts were used in monastic Bibles).

      0
  9. 26

    Absolutely Anonymous

    October 24, 2012 7:24 pm

    Quite ballsy of you to critique Microsoft’s new website design, considering the team and effort put behind it. Imo, I don’t find the text up/down switch to be unpleasant, and probably neither do they – for some reason, I have a strong feeling they didn’t leave it to chance. Anyway, if the team does happen to read this article, they’ll at least leave with that super awesome floating trick of yours..

    4
  10. 27

    Common breakpoints and screensizes just don’t seem important anymore Every variety of screen size, resolution, and aspect ratio will exist out there in the wild, so why bother planning around just a few? I’ve been setting my media queries to kick in when the design breaks somehow, not when the screen hits 1024px wide. I’m free of 320, 480, 720, 800, 1024, 1280, 1400, 1600, 1920, and whatever retina is (in fact, I don’t care what it is). It feels good.

    Not sure I really get the focus on content-first design… I mean, I agree with content-first, but I look at my HTML, and it can’t be much leaner, or more relevantly ordered. There just isn’t much work to do here. In this sense, content feels relatively stable, whereas design is all over the place. Assuming most of us are already working with reasonably solid, best-practices content, doesn’t the focus of responsive design, quickly resort to… design?

    0
    • 28

      Yeah.

      I think we’re getting at the same thing. Once the content is stable, start adjusting the design (with breakpoints wherever the design “breaks”), and focus on presenting the content with good hierarchy.

      I guess it really is more of a design thing than an HTML thing. As long as the content is organized nicely in the code first.

      0
  11. 29

    Martin Sundstrøm

    October 24, 2012 11:04 pm

    I applaud this article! Just 2 days ago I wrote a set of methods and definitions for our company’s digital design department, to ensure that we all have the same approach to a successful responsive design strategy, and pretty much all of the above article confirms my thoughts. My own definition is heavily influenced by articles from Smashing Magazine over that past 2 years, so that’s no surprise. It just seems that this sums it all up very well :)

    One thing I did add:

    “Design for touch-screens first – To ensure the best usability, interphases should be designed and developed to work on touch screens first. This means making interactive elements like links and buttons large enough to hit with your fingertips. With luck, this will look and work fine on desktop versions too, eliminating the need to make more design versions than absolutely necessary. Responsive design is complicated enough to code and conceive without adding more interphase variations than needed.

    Designing “touch-first” also removes a web designer’s tendency to rely on weak usability indicators like hover/mouse-over effects, or the change from pointer to finger – these indicators do not exist on touch-screens. Links and buttons will gain increased usability when they have to convey their functionality with visual information alone.

    When a site’s design works and communicates correctly on a phone or tablet, it will do the same on a desktop or laptop. It may be possible or even necessary to exploit certain device-specific capabilities, but this comes at a later stage and is secondary in importance to basic usability. ”

    This idea is borrowed from another Smashing Magazine article regarding fingertip sizes. Who says a big touch-friendly button is less usable on a desktop?

    2
  12. 30

    Really great article! I had the same thought earlier and its good to see that there are people out there who will support more devices than iMac, iPhone and iPad :)

    0
  13. 31

    I really like this blog!

    -4
  14. 32

    Wow!!! What an article!!! Even if I have done most of the things which you have suggested—I have done those everything without any regular knowledge, having just listened to my own instincts. The web is lacking this kind of learning sources which are well explained and written in a methodical way. This obviously is one of the best articles that I have ever read regarding Responsive Design. Thank you very much for being generous enough to share your knowledge on this web, making it a beautiful and a worthy place to be visited by anyone!!!
    :-)

    0
  15. 33

    Bit confused by the screenshot of CSS-Tricks. It isn’t even the most recent design. Chris changed it months ago.

    0
  16. 34

    And view the authors own site at 800px window size. http://i.imgur.com/X7ypz.jpg

    Woopsie.

    I’m not being critical of the author but it highlights one of the big issues I have with the “totally responsive” approach. Most designs done this way, even by very skilled coders and designers, usually have their quirks or break entirely at some views. In the example above specifically at 800px. How many people will view it at precisely that size? Probably very few but the condition exists. This is because it’s exceedingly tricky, with current HTML and CSS to write code once and have it work perfectly on potentially thousands of different devices/screens/resolutions. It’s even more difficult to test because most people don’t have dozens of test machines and a stack of laptops/tablets and mobiles on their desk to load up the site in.

    1
    • 35

      Just to clear that up a little bit, here’s what brolik.com looks like on my computer at 800 pixels. http://i.imgur.com/fKaJ8.jpg

      Also, that site is pretty old at this point, so I’m not sure I’d stand behind it 100% as a shining example of responsive.

      Your point is well taken, though. Responsive is hard.

      0
      • 36

        The Microsoft’s surface tab web site also have some changes on it now (On mobile screen width, now they have coupled the image and text block, so that the image always appear on top of the relevant text block ). I assume that they hadn’t made those by the time you wrote this article. For me frankly; it doesn’t matter how any of your own sites look alike and it doesn’t matter those example sites (Surface,CS-Tricks) look for the time being. Because you, here have suggested a lot of better practices and explained about the mistakes that someone else would make on the future. That’s why I rated this article to be such a worthy one!

        —”Nothing on earth exists at a level of perfections, and the mistakes are made today to make us and the others learn something new and avoid the same mistake to be made again: for a better tomorrow”

        0
  17. 37

    “Not sure I really get the focus on content-first design… I mean, I agree with content-first, but I look at my HTML, and it can’t be much leaner, or more relevantly ordered..”

    But that they say, is where the problem is – for different devices, some content is not (or should not) be as relevant as it was before and should probably be dropped in the leaner mobile viewport.

    i.e. Table of contents, expanded menu description, some advertising space, maybe some whole swatches of functionality?

    We may decide to remove any reference to uploading content or maybe even user registration, depending on the nature of your work flow.

    Also, we target our content based on the locale of the user, their user preferences AND the hardware they currently use -responsive sizing within the context of a session is not really a big deal – it’s not as if the user deliberately and actively resizes their browser to troublesome dimensions each time they visit, rather they enter the site with a predetermined layout which we (hopefully) are ready for.

    To that end, my site is (and it seems, has to be) DATABASE DRIVEN.
    Each block of content, image and text, is given a weight and relevance depending on the detected device and is served up accordingly.

    0
  18. 38

    The question we always circle back to for the “leaving content out” argument is – if the content is deemed unimportant on mobile devices (where 33% of our studio’s clients are viewing), why is it important enough to be on the desktop version? 9 times out of 10…it isn’t. Mobile first!

    Back to the main topic, great article! I completely agree, “breaking points” are constantly evolving. It’s time to bite the bullet and design something that looks great every time.

    Thanks!

    Steph
    studiofj.com

    0
    • 39

      The content is not left out because it is not relevant, it is left out because within the context implied by the device it either is not needed or based on priority should not be shown.

      For example, on a content sharing and uploading site, users may watch, upload and maybe even edit photos and videos online.

      If the user device makes it impossible, difficult and extremely unlikely that the user would be using it to edit /create content, why have the user even SEE those menu options and descriptions?

      0
  19. 40

    In the words of Mat “Wilto” Marquis, “Get your own damn breakpoints!”

    I am currently helping to revamp an existing site at work to be responsive and instead of terming our breakpoints based on devices (mobile, tablet, desktop), we’ve decided on 4 terms: X-Large, Large, Medium, and Small. With the way we’ve architected our styles, we only need to change a variable to change any breakpoint width. This is great because we can focus on the styles and leave the breakpoint adjusting until later. The breakpoints are not the typical 768, 320, 480, etc. widths, we chose them based on where it made sense (roughly) and it’s turned out well so far.

    For images, we use sprites with 1X and 2X sizes as background images with HDPI support. For photos, we use the picturefill polyfill. For as much as possible we use CSS effects so we don’t need to maintain huge sprites.

    2
  20. 41

    Nitin Nanivadekar

    October 26, 2012 12:39 am

    CSS-TRICKS bombs on Android Gingerbread. Takes the whole browser with it.

    1
  21. 42

    By the way, the Surface site isn’t truly responsive. They identify screen width and serve css based upon that when the page loads. Turn your device from portrait to landscape, as I am doing on my Nook, and the site doesn’t adapt.

    1
  22. 43

    As screen resolutions increase on small devices I believe media queries will need to evolve to take account of physical screen size rather than screen resolution. Already the iphone5 matches the screen resolution of larger tablets but its more comfortable for users to see a single column mobile version.

    1
    • 44

      agreed. right now we can detect an iPhone 5 based on viewport size (568×320), user agent (iPhone). For iPhone 4, change the viewport and detect for pixel-ratio of 2; for iPhone 1 through 3GS, ignore the pixel-ratio. iPad Mini is the issue, because even with the information it currently offers to JS/CSS/PHP/etc, it still matches an iPad 1 and 2.

      Web browsers/Devices need to report their true pixel density if possible (those sub-pixel displays are the odd ones) in DPI or PPI, as well as their physical screen size in inches, cm, mm, whatever, with height, width and possibly diagonal. Aspect Ratio would be nice too.

      0
  23. 45

    “we need to code so that our content makes sense on a 300 pixel screen, not a mobile phone screen.”

    Rubbish – as screen resolutions increase it will be the physical size of the device’s screen which dictates what is comfortable to display to the user.

    A 3″ screen lends itself to a 1 col mobile version regards of it’s actual resolution. Conversely a 7″ screen lends it self to a 2 col layout even if it has a hd screen.

    1
  24. 46

    I just read this article now, and I couldn’t agree more.
    Everyone thinks about iPad and iPhone an forgets that responsive is about those and everything else.

    Is really important to raise awareness for this kind of mistake.

    0
  25. 47

    I do like the ideas in this article and I would use this approach myself but I do have one question. How do you deal with small devices with high resolutions since the resolution is no longer what defines if a screen is big or small. There are 5″ phones that has 1080p resolutions and others have 1024.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top