Join Morten Rand-Hendriksen for an in-depth discussion in this video Responsive web design as a process, part of Mapping the Modern Web Design Process.
- Responsive web design has become the standard for most modern websites. And during the four years since Ethan Marcotte's Seminal article, the tools and techniques that made this type of design possible have improved immensely. Now that the concept of designs, that's re-size, flex, and rearrange depending on the view port has become common knowledge, we can look beyond the idea itself to how best to implement it. Here, as with many other subjects in web design, there are differing opinions and different strategies, so what I'm presenting to you is not the only way of doing things but rather an amalgam of tips, observations, and real life experience and know-how I've accumulated over the years.
To me, responsive web design is a process much like web design as a whole and that process has some fundamental constants which I'll share with you now. The first constant is mobile first. I've talked about this previously and now we can dive into a bit more detail. When I say mobile first, I'm talking both about visual design and about code. In visual design, it means you start with the smallest common denominator, the vertical iPhone with a width of 320 pixels and design everything to fit comfortably within that framework.
Once every piece is in place and everything looks natural, we can start scaling up to wider screens. Here, the goal is to take advantage of the available space while preserving the feeling that whatever you're seeing is always where it's meant to be. We also need to take into account the viewer. How far away is she from the screen? What is her most likely input device? And so on. On smaller screens, she's likely closer allowing for smaller fonts.
But, she'll be using her fingers for navigation which requires bigger buttons and links. On larger screens, she's likely further away warranting bigger fonts and she'll be using a mouse so smaller buttons can be used. The same goes for code. Start by writing code for the smallest possible screen and use media queries to add extra styling for wider screens. This is a point where the community is in disagreement. Some will argue that providing styles for smaller screens first and then scaling up using media queries will provide a sub-optimal experience on larger screens.
I disagree and largely because of the next constant. Media queries belong close to the original element. Media queries augment CSS rules when certain conditions are met. Most commonly screen width. Traditionally, media queries were added at the bottom of the style sheet or even in a separate style sheet. This would invariably result in a snapping action on slow connections. If the site was styled mobile first, larger screens would see mobile styles and then have the view snap into the wider layout once the last styles were loaded.
Same thing with desktop first on mobile. The wide layout would load first and then the site would snap to the mobile view. By adding the media queries close to the original rules, this snapping problem is more or less remedied because every element is styled individually. As a side effect, this method also makes the code easier to maintain. Since rules and media queries are place together in the style sheet, even a novice designer can see what is going on and make changes as necessary.
But the most important benefit of writing your CSS mobile first, is that it produces less code. When you start with the mobile screen, you write the baseline styles that are going to be applied on all screen widths. Your media queries will only contain augmentations for those wider screens. If you go the other way, the media queries for smaller screens will usually contain a large number of overriding declarations which produce more code cruft. For code simplicity, mobile first makes better logical sense.
The third and final constant is there are no predefined breakpoints. Even today, many designers still design and code their sites to hit specific breakpoints like the width of an iPad in horizontal or vertical mode. This is not a good practice for one simple reason. You don't know anything about the device used to access your content. It could be an iPad, but it could just as easily be some random screen with a browser set at a random width.
Or, it could be a new tablet or device not yet on the market. Case in point, the iPhone 6 and 6 plus were recently released introducing two new default screen sizes to the iOS browser. Rather than setting media query breakpoints based on the screens they will be presented on, set the breakpoints to display the content in the best possible way. That will likely mean your breakpoints will change depending on the element in question. But that also means your site will work better across all screens.
I find the best way to achieve this is to work on components one at a time and find natural breakpoints for each. And I'll talk more about that in the next couple of movies.
- Understanding what your users care about
- Creating user personas
- Creating content priority hierarchies
- Testing wireframes and interaction patterns
- Establishing a three-track build process
- Incorporating accessibility principles
- Using content blocks
- Testing and revising your web design
- Optimizing for social media and SEO
- Launching your web design
- Getting feedback from users