Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

RWD & Device Detection? Building A Better Responsive Website

Earlier this year, I was in the beginning stages of a redesign for our company’s website1. We had already been planning to use a straightforward responsive approach to Web design, which is our preferred solution for multi-device support. After hearing some frank discussions at An Event Apart conference in Boston about the limitations and challenges of responsive Web design, I realized that our solution needed a bit of adjustment.

Thankfully, the project before us was the ideal opportunity to experiment and push ourselves to improve our responsive workflow. In this article, I will detail the process we took, including some of the changes we made along the way, as we worked to build a better responsive website.

Variety of phones.2
The variety of devices being used to access our websites is more diverse than ever. (Image: Blake Patterson3)

Defining Our Goals Link

The first step in our project was to make a list of the benefits and drawbacks to the responsive approach we had been using. Our list looked like this:

Benefits Link

  1. A single website to build, maintain and promote.
  2. Support for a variety of screen sizes, not just the extreme cases of large desktop monitors and small handheld devices.
  3. Future-friendly, because the layout will reflow based on screen size and not just the size of today’s popular devices.

Drawbacks Link

  1. Content meant only for large-screen devices is often delivered to small screens and simply “turned off” with CSS media queries, creating unnecessary downloads.
  2. Because the markup is a one-size-fits-all solution, we are unable to change the source order of that markup (or eliminate unnecessary elements from the markup completely) based on the device or screen size.

What you will likely notice here is that the drawbacks we identified with a responsive approach are areas where a mobile-only solution excels. We wanted the best of both worlds for our new website — the advantages that a responsive approach and a mobile-specific solution have to offer.

Starting With Content Link

One of the common differences between a responsive design and a dedicated or mobile-only design is in the content or features that are delivered to the browser. A mobile-specific website often features only a subset of content found on the “normal” version of the website. This is one of the ongoing debates about the two approaches, and proponents of mobile-only websites often argue that mobile users want access only to content that is “important” to them.

The problem with this line of thinking is that what is “important” to a user — any user — changes according to their situation. Eliminating access to content based solely on the device someone is using is sure to alienate and frustrate anyone who doesn’t fit into the ideal scenario that you envisioned when you decided what to include in and what to eliminate from your mobile website.

Our belief has always been that all users should have access to all of the content that the website has to offer, but we wanted to make sure this was indeed the right answer for our website and our users. To help us determine the right approach, we turned to our analytics and found no discernible difference between the type of content requested by our mobile visitors and by our visitors on non-mobile devices. Content that was popular for desktop users was similarly popular for mobile visitors.

Additionally, we sat down and spoke with some of our current clients, who represent a large part of our website’s audience, and asked them some questions, including “What content are you coming to our website for when on a desktop computer?” and “How about on a tablet or a phone?” The interviews were obviously more in depth than this, but you can see what we were asking. Once again, we found that the content they were seeking was the same, regardless of the device they were using.

Data Dictates Direction Link

The findings from our research reinforced our belief that a responsive approach, which provides access to the same content across all devices, was the right choice for our website. This research also enabled us to determine what content on our website was not being accessed at all. When we discovered pages that were not being used by our audience, we cut them from our site map. Similarly, content that was most popular was treated appropriately in our content hierarchy and our layout plans for the redesign.

By starting the project by looking at our content and gathering data on what was important to our audience and what was not, we were able to move into the design phase with an informed plan for what content our website’s design needed to support.

Designing To The Extremes Link

I have heard the arguments for designing in the browser, and I appreciate many of the benefits this approach brings. That being said, having tried designing in the browser on a number of occasions, I have found that my own design workflow is simply better suited to starting in Photoshop. In no way do I think this is the right decision for everyone, but it is the right decision for me, and it is how I began this design.

For responsive designs, I use a method that I refer to as “designing to the extremes.” I start by designing the desktop version of the website. In this version, I work out the design’s typography, tone and overall visual direction — as well as the layout for the large screen view of the website. Once I am happy with this version of the design, I work on the small screen or “mobile” version of the website, using the same visual direction, but adjusting the layout as appropriate for the smaller screen.

At the end of this process, I have visual examples of the two layouts of the website that will vary the greatest — the biggest and the smallest screen versions of the design. These two examples will guide me as I begin the website’s front-end development.

Two versions of a website design.4
The “extreme” versions of the new website design

Mobile First Link

The “mobile-first5” approach to responsive design is not a new idea. This method, whereby you build the mobile experience and layout of a website first and then use media queries to adjust and add to that layout as the screen size grows, has been considered a best practice in responsive Web design for some time now. While not a new approach, it is still an important one, and coupled with our plan to “start with the content,” it helped us to address one of the shortcomings that we identified in our responsive projects — the problem of delivering unnecessary content.

By starting with content, we ensured that all of our website’s content was relevant and appropriate to all users, mobile or otherwise. This meant that we didn’t have to worry about delivering large amounts of content in the markup only to have to hide it visually with CSS. The mobile-first approach meant that images would be delivered only to devices they are intended for. For instance, our new design called for a background graphic of a watercolor texture.

The image, which is quite large, is intended to be a part of the design only on larger screens (660 pixels and up). Because our CSS starts with the mobile design first, this large graphic is never sent to small-screen devices because the media query that loads the image is activated only by larger screens. That media query, which applies the background to our html element, looks like this:

@media only screen and (min-width: 660px) {
   html {
   background: url(/images/bg-watercolor.jpg) no-repeat fixed center top;
   }
}

In addition to adding that background image, this media query that is triggered at 660 pixels also introduces a number of other layout changes to the website, transitioning from what we consider the small-screen layout to what will become the various larger-screen versions.

Building To The Design, Not To Devices Link

When we began using responsive design in our Web projects, we focused on known devices and screen sizes, and our media queries often reflected those known devices (iPhones, iPads in both portrait and landscape orientation, laptops, widescreen desktops, etc.). Over time, we found that this was not the best approach because it only addressed the devices and screen sizes that were popular today and not those that may come in future. One of the strengths of responsive Web design is its future-friendly aspect. So, to fully realize that strength, we moved away from building to devices, instead allowing the design to dictate our media query breakpoints.

The mobile-first method established the baseline for our website’s CSS. With that in place, we launched the website in a browser and scaled it to the smallest size of our layout (we set a minimum width of 320 pixels in the CSS). Slowly, we increased the size of our browser window to see how the layout responded. As the browser window widened, we noticed that the layout began to feel strained. It was at these points that we would need to establish a new media query to adjust the layout.

To help us with this approach, we created a graphic and set it as the background of our desktop. With vertical lines showing us a width of 320 pixels (our smallest size) and then a break at every hundred pixels starting with 400, we used this as a guide as we scaled the browser window to determine where the design started to break down, and then used those approximate pixel values in the resulting media queries that we added to the CSS.

responsive-guide-sm-5006
This desktop background can be used to help determine the breakpoints needed for a responsive design.

This approach of adding media queries based on the needs of the design, rather than on known device sizes, enables a website to better respond to a wider range of screen sizes. It does, however, end up filling the CSS file with more media queries than if you were using device-specific breakpoints. Still, while the number of media queries is higher, the queries themselves tend to be very small because you are making few changes with each one, rather than making the sweeping changes normally needed for device-specific media queries.

One area of our website where this increase in media queries is evident is the navigation.

Responsive Navigation Link

Handling navigation is one of the most challenging aspects of responsive design. For our website, we essentially have four main areas of navigation.

  1. Primary navigation;
  2. What we call the “help navigation,” which links to various portals and services that our clients use;
  3. Footer navigation;
  4. Section-specific navigation, which is presented on subpages of the website (for the larger-screen layouts) in the left-hand column.

Because our CSS is mobile-first, one of the first things we did was to establish the navigation for our small-screen layout. This meant turning off the display of all of the navigation sections except for the primary navigation.

#helpNav, .subNav, footer nav {
   display: none;
}

Now, I said earlier that our goal was not to deliver content to devices only then to “turn it off.” That was indeed the goal, but with our navigation, we had to accept that this was how we needed to do it. We weren’t able to find another, simple yet maintainable, solution. Luckily, the content we are delivering and not displaying turns out to be only a few lists, so the impact on downloading for visitors is minimal.

The help navigation is the one area of the website that has been considered to be not relevant to most users, because these links and portals are intended only for desktop users. Now that’s a big assumption and a bold statement. The rationale behind this was that the portals themselves, which are all third-party applications over which we have no control, are not optimized for very small-screen mobile devices, and the services they offer are geared to supporting corporate clients with large screens on desktops.

This situation informed our decision to remove that section from the small-screen version and in the months that the site has been live we received no comments or complaints from our user base regarding that decision. For the other two navigation areas, our subpage section navigation and our footer navigation, this content is presented as part of the primary navigation for small-screen devices. This is why we turn off these three areas by default.

Later, as the screen size increases and we get past the 660-pixel point where the larger-screen design begins to show, we will style these navigation areas as needed.

Here is the CSS for our help navigation:

#helpNav {
   display: block;
   position: absolute;
   top: 1px;
   right: 0px;
   width: 100%;
   text-align: right;
}

#helpNav ul {
   padding-left: 10px;
}

#helpNav li {
   display: inline;
   padding-right: 6px;
   padding-left: 6px;
   background-color: #2f6a98;
}

#helpNav a {
   font-size: 12px;
   padding: 0 6px;
   color: #FFF;
   border-radius: 20px;
}

#helpNav a:hover {
   background-color: #f66606;
}

And our subpage navigation areas:

.subNav {
   display: block;
   width: 25%;
   float: left;
}  

.subNav h4 {
   padding-bottom: 8px
}

.subNav ul {
   list-style: disc;
   color: #c65204;
   padding: 0 0 20px 20px;
}

.subNav li {
   padding-bottom: 14px;
}

.subNav a {
   color: #186483;
   font-size: 21px;
   font-family: 'RokkittRegular', Times, "Times New Roman", serif;
   line-height: 1;
}

Finally, our footer navigation:

footer nav {
   display: block;
   margin-top: 40px;
}

footer nav ul {
   list-style: none;
}

footer nav li {
   padding-bottom: 24px;
   width: 19%;
   padding: 0 5% 20px 0;
   float: left;
}

.innerNav li {
   width: 100%;
   float: none;
   padding-bottom: 4px;
}

footer nav a {
   color: #575454;
   font-size: 12px;
}

.innerNav a {
   font-weight: normal;
}

Pixels Vs. Ems Link

You will notice that we have used pixel values in our media queries. Using pixel-based media queries is how we, like many front-end developers, began implementing responsive design, and we have maintained the practice as part of our responsive workflow. In the spirit of “building a better responsive website,” though, I’ll point out an article on proportional media queries using ems7 that was brought to our attention during the editing of this piece. Essentially, to improve the appearance of the site when zoomed in, it’s highly recommended to convert px-media queries into em-media queries by dividing all pixel values by the body font-size.

This wonderful article has caused us to rethink our pixel-based approach to media queries, and it is another example of how we continue to refine our responsive approach. While we did not use ems in our media queries in this particular project, we are experimenting with them now, and the approach is worth mentioning here.

Primary Navigation Link

Our primary navigation is presented on wide screens as a horizontal row across the top of the layout. On small screens, this primary navigation structure changes so that there is a large “Menu” button at the top of each page that links to the navigation at the bottom of the page. To accomplish this, we added a link with an ID of menuLink and a class of tabButton in the header, which is near the start of the markup. We then placed a division with an ID of mainNav at the very end of the markup. Inside that division is our main navigation, which is simply an unordered list with a number of other unordered lists inside it for the subpage section menus. We also have another anchor with an ID of toTop, which acts as a link back to the top of the page.

Menu button as presented on a website's mobile layout8
The small-screen layout presents a “Menu” button at the very top of the layout.

Continuing our mobile-first approach, we styled the menu link at the top of the small-screen layout to look like a button.

#menuLink a {
   float: right;
   margin: -56px 8px 0 0;
}

.tabButton a {
   color: #FFF;
   font-family: 'RokkittRegular', Times, "Times New Roman", serif;
   font-size: 20px;
   background-color: #45829b;
   padding: 10px 12px;
   border-radius: 10px;
}

.tabButton a:hover {
   background-color: #f66606;
}

Our main navigation menu is set to its small-screen display:

#mainNav {
   margin-top: 30px;
   width: 100%;
}

#mainNav #toTop a {
   float: right;
   margin: 0 8px 0 0;
   font-size: 20px;
}  

#mainNav nav {
   padding-top: 80px;
}

#mainNav ul {
   list-style: none;
}

#mainNav li {
   background: #45829b;
   border-bottom: 1px solid #abc7d2;
   padding: 4px 10px 4px 15px;
}

#mainNav li:hover {
   background-color: #f66606;
}

#mainNav a {
   font-size: 24px;
   color: #FFF;
   font-family: 'RokkittRegular', Times, "Times New Roman", serif;
}

The small-screen version of the website's main navigation9
Our website’s primary navigation as presented for small-screen layouts

Our submenus, which are set not to display initially, we can now display as the page requires. Each of these submenus has a unique ID, such as servicesTab, and each section of the website has a class applied to the body tag. The class for the “Company” section is companyPage. We use this class to set styles for that entire section of the website. We use the class of the submenu sections to turn on the submenus as needed when a section is active.

.companyPage #companyTab ul,
.newsPage #newsTab ul,
.contactPage #contactTab ul,
.servicesPage #servicesTab ul {
   display: block;
}

Subpage navigation for our small-screen layout10
The subpage navigation displayed for the small-screen layout

Getting Larger Link

As the larger-screen layouts kick in — once again with the media query for 660 pixels and above — we dramatically change the primary navigation’s layout. First, we turn off the display of the menuLink and toTop buttons because they are no longer needed:

#menuLink a, #toTop a {
   display: none;
}

Next, we style the mainNav horizontally across the top of the page to achieve the larger-screen design:

#mainNav {
   position: absolute;
   top: 92px;
   margin: 18px 2% 0 2%;
   width: 96%;
   text-align: center;
}

#mainNav nav {
   padding: 5px 0;
   border-top: 1px solid #bacfd7;
   border-bottom: 1px solid #bacfd7;
}

#mainNav li {
   background: none;
   display: inline;
   border-bottom: 0;
   border-right: 1px solid #bebebe;
   padding: 0 6px 0 8px;
   margin: 4px 0;
}

#mainNav a {
   font-size: 16px;
   color: #45829b;
}

#mainNav a:hover {
   color: #f66606;
}

These styles set the look of our primary navigation. But to build to the design, instead of to the device, we will need to make small adjustments as the screen size grows. Our primary navigation’s font has eight different sizes in total for the larger-screen layouts, changing as the screen grows and as we have more room to work with. Figuring out how best to display this navigation so that it is both easy to use and visually attractive was one of the challenges we faced while working with this responsive design.

Initially, our font size is set to 16 pixels. Once we hit 767 pixels in width, we bump that to 18 pixels.

@media only screen and (min-width : 767px) {
   #mainNav a {
      font-size: 18px;
   }
}

We continue this pattern a number of times, increasing the font size finally to 27 pixels as the website reaches its largest size. In this way, the website’s navigation truly responds best to the design and to the screen being used to view that design.

Getting Help From The CMS Link

Our preferred CMS is ExpressionEngine11, and the specifics of this next portion of the article refer to that platform, but the general idea of what we accomplished with ExpressionEngine could undoubtedly be applied to other popular CMS platforms as well.

One of the biggest drawbacks to the responsive approach is that you cannot deliver different markup or a different source order to different devices. This drawback is what we wanted to overcome with our CMS. During our experimentation and research, we stumbled upon an article titled “Going Truly Adaptive With ExpressionEngine12.” Using the approach detailed in this article, we were able to use a device-detection script to set a variable in the system of either mobile or full. We could then conditionally load markup into our website based on which of these variables was met.

By going further and using the device detection, we were able to make other very small changes to further improve the mobile experience. To us, this was kind of like progressive enhancement, where we created a quality solution and then tried to take it further to deliver a slightly more optimized experience. Make sure to read Chris Coyier’s similar view on combining RWD and mobile templates13 in which he argues about mixing and matching a variety of techniques for your mobile strategy.

Starting Small Link

You could certainly use these variables to deliver completely different markup and source orders to different devices, but our initial approach was a little less extreme. Because we had already decided that all versions of our website would have access to all content, we initially used this variable method to make slight adjustments to how much of that content would be delivered. For instance, on our website’s home page, we show teasers for a variety of content found within the website. For the “Culture” and “Project Spotlight” sections, an image accompanies each post.

The images are a nice-to-have addition but certainly not critical, so we do not deliver these images to mobile users at all.  Now, I do not mean that we use CSS to turn off their display, which would cause the data to get delivered to the browser anyway; instead, we use the variables we have established to omit the images from the markup unless they need to be shown.

Two sections of our website's home page14
The teaser images are nice to have, but not critical to the content or layout.

The syntax is quite easy. Once you have established your variables — which the aforementioned article15 explains how to do easily by adding a little script to the system’s config.php file — you can use those variables like an if statement.

{if global:site_version=='full'}<img src="{teaser-image}" alt="{title}" />{/if}{if global:site_version=='mobile'} {title}{/if}

This is ExpressionEngine syntax, but you should be able to read this and easily see what is happening. If the full variable is met, then we deliver the teaser-image from that article’s entry in the database. If the mobile variable is met instead, then we deliver the title of the article.

We use this same approach for the home page’s “News” and “Blog” sections, delivering three short teasers if the full variable is met and only one if the mobile one is. That syntax looks like this:

{exp:channel:entries channel="news" {if global:site_version=='full'}limit="3"{/if}{if global:site_version=='mobile'}limit="1"{/if}}

Here you see that we are accessing the ExpressionEngine channel named news. We use our variable to determine how many recent entries will be displayed from that channel, using the limit parameter.

Taking It A Step Further Link

In the website’s “Culture” section16, we publish articles that are often accompanied by a number of images. Unlike the teaser images on the website’s home page, the images in the articles themselves are critical to that content, because they help to carry or reinforce the article’s point. Now, while the images are important, they are also quite large — each one is 650 pixels wide, and most articles include at least three images and as many as ten. Because mobile devices will show the images at about half their original size, the downloads for the full-sized images would be quite substantial. To address this, we once again turned to our device detection and variables.

For each article, we produce two sets of images: one full sized at 650 pixels wide and a second set at almost half that size. We then use the variables in our article (but first we need to allow ExpressionEngine code in our page’s template), and we include the markup for both sets of images — but only one set is ever delivered to the browser. Mobile devices get the smaller images, while everything else gets the normal set.

We take a similar approach with the home page’s large billboard area. These rotating banner messages and images are used to promote important items, such as upcoming events, new services and announcements, in a bigger way than we do in the other areas of the home page. The billboard is another nice-to-have element that is intended for large displays only. Once again, we use the variables to deliver the main billboard division, as well as the JavaScript that runs it, to appropriate devices — effectively enabling us to send different markup to different devices and eliminating yet another of the drawbacks that we identified at the start of this project.

Through a mobile-first approach and with our CMS’ help, we are able to deliver our home page to desktop users at 738.3 KB and dramatically reduce that to only 174.4 KB for mobile users.

Fallback Plans Link

One of the questions that has always bothered me about a mobile-only approach and device detection is, What happens if that detection fails? Is the “normal” version of the website delivered to the mobile device, thereby rendering your carefully designed mobile experience null and void? This possibility is one of the main reasons why I have avoided a mobile-only solution that uses device detection in the past.

For our new responsive workflow, we are using device detection, but our process has equipped us with excellent fallbacks in case that detection fails for some reason. Because we are using a responsive approach, even if the full version get delivered to a mobile browser, the layout will be suited to that device because our CSS will adjust the website’s layout accordingly.

Additionally, because we went with a mobile-first build, items not intended for small screens, such as the giant background graphic mentioned above, do not get delivered either. The only thing that will fail is what we have done with our device detection-generated variables. If the worst-case scenario happens and our detection fails, then the mobile version would simply get a few extra images or a little markup or JavaScript that it does not need. The experience would still be suited to mobile. Not bad at all for a “worst-case scenario.”

Progress, Not Perfection Link

A few years ago, a client said something to me that has stuck with me to this day. Talking about his website, he said:

“Don’t worry about making my website perfect. Just work on making it better. If we’re constantly making it better, we’re going in the right direction.”

This idea has guided me over the years and reminded me never to dismiss a better solution simply because it is not perfect.

I know this is not a perfect solution, and I am OK with that because it is an improvement to our previous responsive workflow. It has helped us overcome some obstacles that we identified, and we can now bring those improvements to other projects we are working on. Yes, there are still many issues that we have yet to effectively address, such as the delivery of higher-quality images to HD displays as well as the use of em-based media queries referred to earlier in this piece, but we are moving in the right direction for this project and for others.

Who knows? Maybe someday someone will build a “perfect website.” In the meantime, we will focus on progress, not perfection, as we continue to make small improvements along the way, working to build a better responsive website.

What Do You Think? Link

How do you build responsive websites? Do you use feature detection or device detection? When would you recommend using one or another? We are looking forward to your comments!


(al)

Footnotes Link

  1. 1 http://www.envisionsuccess.net/
  2. 2 https://www.smashingmagazine.com/wp-content/uploads/2012/11/phones.jpg
  3. 3 http://www.flickr.com/photos/35448539@N00/4773693893/
  4. 4 https://www.smashingmagazine.com/wp-content/uploads/2012/11/envision-extremes.jpg
  5. 5 http://www.lukew.com/resources/mobile_first.asp
  6. 6 http://www.envisionsuccess.net/images/responsive-guide.jpg
  7. 7 http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2012/11/menu-mobile.jpg
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2012/11/nav-mobile.jpg
  10. 10 https://www.smashingmagazine.com/wp-content/uploads/2012/11/mobile-subnav.jpg
  11. 11 http://expressionengine.com/
  12. 12 http://www.designkarma.co.uk/blog/comments/going-truly-adaptive-with-expressionengine
  13. 13 http://css-tricks.com/mixing-responsive-design-and-mobile-templates/
  14. 14 https://www.smashingmagazine.com/wp-content/uploads/2012/11/envision-sections.jpg
  15. 15 http://www.designkarma.co.uk/blog/comments/going-truly-adaptive-with-expressionengine
  16. 16 http://www.envisionsuccess.net/our-culture
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

Jeremy Girard was born with six toes on each foot. The extra toes were removed before he was a year old, robbing him of any super-powers and ending his crime-fighting career before it even began. Unable to battle the forces of evil, he instead works as the Director of Marketing and Head of Web Design/Development for the Providence, Rhode Island based Envision Technology Advisors. He also teaches website design and front-end development at the University of Rhode Island. His portfolio and blog, at Pumpkin-King.com, is where he writes about all things Web design.

  1. 1

    Amir Mehmood

    March 5, 2013 8:10 am

    I was really fed up with the source-order when I started my first responsive design. Device detection techniques are great but as they involve server-side coding skills which most web designers don’t like to dive in. Thanks so much for the great stuff.

    3
    • 2

      Jeremy Girard

      March 5, 2013 8:48 am

      Your comment about device detection being hard for designers is actually why we loved this particular solution so much. It was drop dead simple to implement and the flexibility it gave us to deliver different source order, or even different CSS (since all our CSS is inside of the ExpressionEngine CMS as well, we can use these variable to deliver different styles to different devices if we so choose), was something that allowed us work with device detection in a way that fit in with our team’s existing strengths.

      5
    • 3

      If you use a framework like Zurb Foundation 4, you can specify source ordering. You can rearange things based on small/medium/large screensizes (the breakpoints of which you decide).

      7
      • 4

        That framework Zurb F 4 even the 3rd version is super hot like super HOT!

        2
    • 5

      That’s also one of my bugbears. The system we use is quite limited in what is possible so we’re unable to use any server-side technology, nor do we have the experience or budget to produce a script or plugin to add the functionality. This is the both the curse and beauty of web design though, in us modifying our solutions based on the variables and situations around us.

      0
    • 6

      I have always and still do disagree with the “Mobile First” Ideal for designing most websites and your writing would say that you agree with me. Although you have a section devoted to “Mobile First” in the paragraph before it you contradict that ideal by saying ” I start by designing the desktop version of the website. In this version…”.

      Which is it? I personally prefer to start with the largest size you plan to build to. That way you can layout which images go where and how many columns you can have for content and navigation ahead of time. Then for designing the mobile experience (or the smaller screen experience). I just take the original design and shrink down the margins. This gives you a quick idea of what content will work on a mobile device and what won’t so from there you can begin pruning and restyling pieces to make them work as you progressively get smaller and smaller.

      This would be the “Mobile Last” strategy I guess but it makes much more sense to me. Especially since there are many new mobile devices with higher than or equal to resolutions on much bigger devices.

      If you were to truly thing mobile first you would start out with the bare minimum of the site that you feel you need to show and work your way up from there. If you expect the vast majority of your users to be on mobile devices fine but I would say most of the time that isn’t the case, and even when it is the case designing by adding content as you slowly scale up seems very hard to do since it is really hard to imagine scaling up a minimalist design instead of the much easier and IMHO more realistic path of scaling down your design.

      4
      • 7

        “expecting the vast majority of your users to be on mobile devices” is fast becoming the norm. It’s pretty shortsighted to ignore that trend. Do you really expect most people to still be accessing your content from their personal computers in even 3 years? People will use big screens at work and mobile everywhere else.

        2
  2. 8

    Server side detection is useful for being able to conditionally display different inputs.

    By using server side, I can avoid having clumsy jQuery UI datepickers popping up for mobile users, and just use date time instead, which is much more elegant on both Android/Chrome and iOS. And of course for desktop browsers, which mostly don’t support date time, I show a normal jQuery UI enhanced input instead.

    2
    • 9

      That is slick. Why I didn’t think of that? Thanks for the tip. Nice article by the way. I like simple but effective solutions like how the menu is handled. Kudos.

      1
    • 10

      Doesn’t Modernizr work with it either? I mean something like: if ‘date’ supported then show native datepicker else show jqueryui. ?

      2
    • 11

      Geoff Jackson

      January 2, 2014 1:40 am

      What do you use for conditionally serving elements in a website from the server-side Michael?

      I’m currently trying to identify the best way to do this for a responsive site built on Magento. I’ve been looking at Mobify.js for client-side adaptation but ideally I’d like to handle this on the server if possible but not really sure what options are out there for this.

      Thanks.

      0
  3. 12

    Great post, and useful tips, thank you!

    1
  4. 13

    Serbin Dmitry

    March 5, 2013 12:52 pm

    I’m on my way to build my personal website-portfolio, and I have next thoughts:
    1. One site fits all screens.
    2. Text and backgrounds can be adjusted by media-queries.
    3. Images, including galleries and slide-shows, can have 3 versions of images, namely “mobile”, “tablet”, “desktop”, and will be replaced by jQuery. To avoid loading images 2 times (1st on load, 2nd on screen detection), 1st time images will not be loaded. So basicly path to images will be like “images/[size]/image.jpg”, and [size] will be replaced after screen detection.

    Any thoughts on this?

    2
    • 14

      Jeremy Girard

      March 6, 2013 4:00 am

      Your method differs from what we did, but it sounds like you are trying to accomplish the same thing we were – deliver images appropriate to various screen sizes instead of giant images that will often be resized down.

      I think you may find, however, that you will only need 2 sets of images – large and small (or desktop and handheld, if you prefer). We found that the images appropriate for tablets were so close to those we needed for larger screens that there was very little to be gained by adding that 3rd set of images. Your project may differ, of course, depending on how the images are being used.

      My only other suggestion would be to plan for what happens if the jQuery fails. On our site, if device detection fails, the larger images get loaded. Not optimal, but certainly not disastrous either. Just make sure that you have a solid fall-back for the image loading solution you come up with!

      2
      • 15

        Serbin Dmitry

        March 6, 2013 7:10 am

        Thank you for your advices, Jeremy.

        For fail method i can use loading small images, which will increase traffic for desktop and tablets, but will save for handheld.

        Anyway, testing will help to clarify this.

        1
  5. 16

    Francesco Bertelli

    March 5, 2013 12:55 pm

    Just a note…I think there is a little wrong premise “A single website to build.”
    This is a wrong premise that many clients assume.
    But from a UX standpoint i feel you have to design for 3 or more different scenarios and translate all the interactive elements for both touchscreen or pointer devices (or remote / D-Pad). At the end of the day this works well for blogs or simple websites, but for the rest is not as easy as the client expect. OF course, it’s not going to be “cost x N screen sizes”, but at least 4 times…and not 1.5 as many clients assume. Juts an heads up.

    0
    • 17

      Jeremy Girard

      March 6, 2013 4:06 am

      I agree that you have to “design” the different scenarios for different major breakpoints in the layout, but all of those “designs” can be executed from the one responsive website. This is what I mean by “a single website to build.” This works for much more than just a “blog or simple websites” and we’ve used this approach for large, product driven websites, company intranets, and many others than fall well outside of the basic blog or brochure site format. Take a look at the amazingly complex and varied kinds of websites embracing responsive design today and I think you’ll see that the argument that it “only works for blogs” begins to hold very little weight anymore.

      0
  6. 18

    Kind of a shameless plug but our team at Linchpin has created a pretty useful responsive page/theme tester plugin for WordPress today. You can download/view more at http://wordpress.org/extend/plugins/responsive-page-tester/

    2
  7. 19

    It would be great if we had HTML Queries (not only Media ones) to determine what to load and what to remove from the markup.
    Of course, this could be done by ajax-ing the whole page and loading part by part, but that would be as uncomfortable to design as possible.

    1
    • 20

      Jeremy Girard

      March 6, 2013 4:09 am

      This concept of “HTML queries” is exactly what we were able to do with the variable we set on our CMS. For instance, if you visit on a handheld device and the “mobile” variable is triggered, the markup for the large “billboard” on the homepage never even gets loaded, nor does the javascript that powers that display.

      I’d love for this to be native to HTML with, as you said – HTML queries, but for now, our approach is very simple and effective and it is working great for us.

      0
  8. 21

    Peter Müller

    March 5, 2013 11:49 pm

    Good to see that “a better responsive website” involves server-side components as most examples of responsive design seem to be based on a “one size fits all” html. In many cases this server-side exchange of html modules is just the little twist needed to make it better. That’s only one reason why “my preferred CMS” is Contao 3. Special page layouts for “mobile” are in the core ;-)

    5
  9. 22

    Thanks for the great case study Jeremy.

    The down-sides I see with server-side detection are:
    – it isn’t as comprehensive as in-browser detection
    – it doesn’t provide feature detection
    – it doesn’t allow server-side caching of the output
    – it makes the server-code more complex (in your case only a little)

    Am I misguided on any of those points?
    I guess I feel PE / RWD should just deliver the same, minimally augmented content for each page (think API-first) and allow AJAX to take care of the rest (think responsive-content, site-mashups, inside-out framesets, alternate-stylesheets).

    Regards.

    0
    • 23

      Jeremy Girard

      March 6, 2013 4:14 am

      I agree with your points, but in our case, this device detection solution was really used as the last layer we added onto a site that was already very mobile-friendly. We treated it like progressive enhancement – if the detection fails, the site that loads will still perform quiet admirably. If the detection works, it will be that much better!

      In our case, this solution was much easier for us to use than feature detection or any kind of AJAX solution – neither of which are really our team’s strengths.

      As I’ve tried to point out in this article a number of times – this approach was what was right for us in this particular case. I absolutely agree that there would be other instances where feature detection would give us what we needed. Like so much in this industry, it is about quality solutions and knowing when each of those solutions is the right fit for the job.

      1
  10. 24

    Nice article. Very helpful & practical. Makes a complicated topic seem easy. I will try it with my next new website.

    0
  11. 25

    Please do a feature on Zurb Foundation 4, it does everything and more of which you described in this article! I’m a huge fan of it after learning SCSS and creating a base Magento theme for it (which I can now create new themes from)

    I’ve made a Github repository called Magento Zurb Foundation, it doesn’t yet have all of my changes yet, as i have to finish my theme first, but eventually it will be feature complete.

    -1
  12. 27

    With regards to determining the breakpoint sizes, I’ve written Viewport Genie, which is available as bookmarklet or small JavaScript include, and adds the viewport size in both px and em as an element at the top of the document.

    You can find out more about it and its companion plugin, mqGenie here: http://mattstow.com/your-media-queries-are-wrong-fix-them-with-viewport-genie-and-mqgenie.html

    HTH

    2
  13. 28

    Josh Buckle

    March 6, 2013 3:34 am

    Hey has any got any suggestions, for a cms that’ll integrate easily with a responsive website. I’ve never been a fan of wordpress so just looking for alternatives! Thanks :)

    0
    • 29

      Jeremy Girard

      March 6, 2013 5:12 am

      The CMS we used for this project, and for all our projects, is ExpressionEngine. Having worked with WordPress, Drupal, Joomla, and a handful of smaller CMS solutions as well, I have found that they all have their strengths and weaknesses – but ExpressionEngine is the one I have settled on.

      0
      • 30

        +1 on Jeremy regarding ExpressionEngine. At COPIOUS, we’ve found that it’s the best overall combination of out-of-the-box support, ease of use for our clients, and flexibility for the kinds of responsive websites we build for our clients.

        If anyone is interested in a few examples, we’ve got some on our site: copio.us/

        0
    • 31

      In recent months both Statamic and now CraftCMS are rising stars, build by EE devs. Expression Engine is powerful but a bit crusty now.

      0
    • 32

      You could use Drupal and a responsive theme such as Zen (my personal favourite). LightCMS has responsive, customisable themes out of the box, and we use Mezzanine CMS with Django using Foundation 4 (which is awesome, but you need to know Python…)

      0
  14. 33

    Sami Keijonen

    March 6, 2013 4:43 am

    At some point browsers still loaded background images even if using this.

    
    @media only screen and (min-width: 660px) {
       html {
       background: url(/images/bg-watercolor.jpg) no-repeat fixed center top;
       }
    }
    

    Have this changed recently? Answer to my question must be yes and that is great news. Can somebody point a good article about it?

    0
  15. 36

    Rogier van der Heijden

    March 6, 2013 5:10 am

    First of all, thanks for the good read! Very interesting to read about the solutions you used for different design and content problems. I just find one part of your solution a bit contradictory. If I understood it correctly you use device detection in order to load specific parts of the HTML. While earlier in the case you described using screenwidth would prepare the website for possible different screens and thus make it more flexible and futureready. I wonder why not keep triggering on the width in stead of the device being used?

    Another heads up you guys might have overlooked. The buttons in the mainnavigation for small screens have a roll-over effect, but aren’t completely clickable. This might be confusing on small touchscreens, when clicking next to a word you get the “clicked” feedback, while no page will load.

    0
    • 37

      Jeremy Girard

      March 6, 2013 7:14 am

      Thanks for the comments. We do use screenwidth to ensure the site is future-friendly. That is the foundation of how the site was built and if we had stopped there, we would’ve been in pretty good shape. The device detection, and conditionally loading pieces of HTML based on the variables that detection sets, just takes it a step further to try to add one more layer of small screen optimization. Like with other forms of progressive enhancement, our goal was to provide a good solution for all users and an even better solution whenever possible.

      In terms of the buttons – I think I know what you mean. It seems as if the target area is ONLY the text, not the full width of the visual button. Is that what you mean? If so, that is a great point and we are looking into now (either way, that is something that should be addressed). If you were referring to something else, please let me know so we can look into that too!

      Thanks again – comments and suggestions are greatly appreciated.

      0
  16. 38

    Simon W. Jackson

    March 6, 2013 5:25 am

    Love that quote!

    “Don’t worry about making my website perfect. Just work on making it better. If we’re constantly making it better, we’re going in the right direction.”

    2
  17. 40

    We did something similar on a mid-sized client website, we made a fully responsive site and then used server side detection to make minor tweaks.

    A good example was using a custom jquery selector type thing to enable a custom styled dropdown type device for use on all devices except IOS. On IOS we sent standard select/option HTML so that the native barrel selector was displayed.

    Large site, large amount of responsiveness, tiny amount of device specific code.

    0
  18. 41

    Mark Aarhus

    March 6, 2013 9:53 am

    For a site for my company I used categorizr to determind which device accessed the site. Based on this I could cut away unessecary css + javascript for mobile. This also allowed me to use sencha.io to serve images for mobile instead of the big pictures for mobile. I could also serve videos encoded for mobile instead of desktop version.

    Using this approach I could get the 800kb for desktop down to approx 300kb for mobile. I could have cut down to much more if facebook js was also cut away for mobile.

    All in all a win win :)

    0
  19. 42

    Rogier van der Heijden

    March 6, 2013 1:52 pm

    Thanks for your answer Jeremy! That button thingy you described was what I meant! I am looking forward to read about your future cases!

    0
  20. 43

    Nice read and love how dynamic your page is! I’m curious about your opinion on sticking with pixel values versus em’s — and if there was any discussion as to if there was a better choice for scaling and resizing. I’m still on the fence and have always used px, but see many people prefer the relative-ness of em’s in terms of percentage relationships. Apparently the CSS can do the math, if instructed.

    0
    • 44

      Jeremy Girard

      March 7, 2013 4:39 am

      It is interesting that you bring that point up. As the articles states in the “Pixels Vs. Ems” section, we have always used px values in our responsive designs for the media queries. It’s how we began in responsive layouts and, until recently, we had no reason to revisit that decision.

      During the editing of this piece, another article was brought to my attention – http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

      Give that article a look. It does a great job of explaining the benefits of EM-based media queries as opposed to PX-based ones. We have begun experimenting with this is some recent projects and are really pleased with the results so far.

      0

↑ Back to top