RWD & Device Detection?Building A Better Responsive Website

Advertisement

Earlier this year, I was in the beginning stages of a redesign for our company’s website. 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.
The variety of devices being used to access our websites is more diverse than ever. (Image: Blake Patterson)

Defining Our Goals

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

  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

  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

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

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

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.
The “extreme” versions of the new website design

Mobile First

The “mobile-first” 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

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-500
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

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

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 ems 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

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 layout
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 navigation
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 layout
The subpage navigation displayed for the small-screen layout

Getting Larger

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

Our preferred CMS is ExpressionEngine, 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 ExpressionEngine.” 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 templates in which he argues about mixing and matching a variety of techniques for your mobile strategy.

Starting Small

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 page
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 article 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

In the website’s “Culture” section, 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

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

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?

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)

↑ Back to top

Jeremy 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 Web Development for the Providence, Rhode Island based Envision Technology Advisors and teaches website design 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

    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.

    5
    • 2

      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
    • 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.

      2
      • 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

      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

    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

      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

        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

      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

      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

    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
    • 22

      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
  9. 23

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

    0
  10. 24

    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
  11. 26

    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 ;-)

    3
  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

    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

      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

    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

      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

    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

      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
  21. 45

    Thorvald Neumann

    March 7, 2013 4:06 am

    Thank you for the very informative article, Jeremy.

    It certainly gives a lot of food for thought concerning a current project I am involved in.

    0
  22. 46

    The most informative and helpful article on responsive design I have read so far.

    0
  23. 47

    Hey Jeremy, great article! I appreciated your humble approach and I was challenged by some of your choices in the RWD process.

    0
  24. 48

    web development

    March 7, 2013 12:03 pm

    The most knowledgeable post on responsive design. Responsive design approaches easy reading and navigation with a minimum of re-sizing, panning, and scrolling.

    0
  25. 49

    Jeremy,

    I thought the menu button pointing to the actual navigation at the bottom of the page was brilliant! I’ve read extensively about RWD over the last two-years, and content is more important on handheld devices then navigation. Therefore, retaining the prime real estate at the top for content by placing the navigation at the bottom adhere’s to this suggested best practice.

    Great article!

    Thanks,
    Mario

    1
  26. 50

    Great article with a lot of helpful tips. Cheers!

    0
  27. 51

    If I understand correctly you used a mix of client side and server side feature detection ? What server side feature detection database did you use ?

    Also, to the folks starting with Zurb Foundation 4 has anyone used it sucessfully with server side feature detection – would love to hear comments on how it worked out – especially in an asp.net environment ?

    0
  28. 54

    Anil Kumar Panigrahi

    March 11, 2013 3:21 am

    I too created responsive mobile compatibility web application using php application … we can view the application by http://www.anil2u.info/2012/10/mobile-web-app-using-with-your-rss-feed-and-php/

    0
  29. 55

    Andrew M. Andrews III

    March 11, 2013 7:16 am

    As an alternative to server-side device detection, you can use client-side screen-width detection to set a cookie value, which the server can then use to decide whether to send back the HTML based on whether the client will display it:

    document.cookie = ‘width=’+ window.innerWidth +
    ‘;path=/;expires=’ + (new Date(2020,11,31,23,59,59,999)).toGMTString();

    This can be even further extended to allow the user to force a wide or narrow layout by clicking a link or button; for example, some users might prefer the “desktop” appearance on their smaller device, zooming in and out as necessary.

    0
  30. 56

    Love this article and how it walks through a realistic workflow when it comes to approaching Responsive Design. The mobile first strategy is the hardest one to implement by most because of the idea that “cut” the fat is really what we need to do as designers and serve up smaller images and remove unnecessary scripting that can bog or bloat a site down. Nice piece.

    0
  31. 57

    Thanks. I like your article. I’m not a fan of mobile-first approach. But more like PC/Mac user and Mobile user market which has separate css, images and html. Why i do that because on mobile, the focus is how to deliver our content as fast as possible with reasonable compression (image size in kb, css etc). For PC, as many web browser & screen resolution. So, no more unused div on mobile version and no more css for mobile on PC/Mac. Sorry for my bad english.

    0
  32. 58

    Antonio Vasilev

    March 14, 2013 2:00 am

    Great article and a great website @ Jeremy Girard!

    One thing that came to mind when i read about the problem you were having with presenting users on mobile with more content than they need is lazy loading(or something similar)

    Perhaps it would have made sense from a UX as well as a performance perspective to include a tap functionality which reveals and downloads content when the users chooses – or perhaps when they scroll down to a particular section of the site.

    If done correctly, that would mean that the user is not downloading any unnecessary markup and that they choose to view the content, resulting in a more compact, user friendly layout as well as a faster performing one.

    0
    • 59

      Lazy loading and ideas like those you have presented here are actually things we are looking into now as we continue to try to refine and improve our process.

      1
  33. 60

    Thought you should know your responsive site is broken. Sitting here in Chrome on Mac, I scaled down and then back up. The first pass the text was too large to fit on the page, as if I had zoomed in. The next time I got the crashed folder icon.

    0
    • 61

      Thanks for the heads up – we’ll test that platform/browser again to see what may be happening there.

      0
  34. 62

    I just saw the result… A mobile version for Nexus 7 is not necessary and even on smaller devices is it often a pain to seek this one feature, you know from your pc which you need now. Don’t violate the user (always keep an option for full site) and don’t think mobile needs mobile: with a device like Nexus 7 is a mobile version often more an Usability Bug.

    0
  35. 63

    Hi Jeremy, I am constantly disappointed with these types of articles that provide no user-testing in the development process. I find this irresponsible of your magazine to publish articles such as this, teaching other developers to ignore the user in the development process. Can you really call yourself a website developer if you only develop websites for project stakeholders and not the end-user? Regards, Reece.

    PS. I get it if you dont publish this comment on your website. Think about it though.

    0
    • 64

      Thanks for your comment. User testing was actually done during this project – it just wasn’t something I covered specifically in this particular article.

      0
  36. 65

    Mobile First for design? Makes sense. Mobile First for development? Still not seeing the benefit whatsoever. It’s either a subtractive or additive process for me. Same quality CSS, same load times, hardly ANY difference. Are you sure this isn’t just a preference?

    Also I am not seeing the behaviors you speak of at all, so something must have changed in the past month because I am simply failing to see why mobile first development has ANY affect on the quality of your end product. It just sounds like you are stating that a preference is the “RIGHT WAY” — I dealt with a client today that had an in-house developer that was emphatic about us developing mobile first. We said there are a couple of different ways to skin a cat and mobile first didn’t lend any palpable results in our testing that would cause better load times and such. When the user base is 50% mobile and 50% desktop (in the case of the client in question), why are we so emphatic about the mobile experience when half of folks are still on desktop technology? I just feel as though we are forgetting about the actual user here.

    Thanks for listening,
    Mary

    0
    • 66

      From a development standpoint, we found that a mobile-first approach to the CSS and adding styles on, such as background images, for larger screen devices ensured that we weren’t delivering those images or styles to devices that wouldn’t actually display them visually. Coupled with the CMS variables I mentioned in this piece, we were indeed able to deliver a better load time and significantly smaller file size to small screen devices. This is why we have found an “additive” approach to work better for our projects than the “subtractive” approach.

      0
      • 67

        I think it’s very important to drive towards a 1 design/ 1 code fits all. I mentioned in a reply earlier, but Christian Heilmann’s solution with match media (client side solution) seems pretty on point!

        Tutorial: http://christianheilmann.com/2012/12/19/conditional-loading-of-resources-with-mediaqueries/

        Demo: http://vanillawebdiet.com/demos/conditional-mediaqueries-loading/

        Though it’s not a “perfect” solution, I believe its heading in the right direction. In this demo he conditionally loads each media query stylesheet depending on screen resolution and provides fallback for if the script doesn’t load. If you click the demo on a computer screen you will see the image of a cat with a green background, but if you re-size the browser to a “mobile” resolution and refresh the page you will see the cat image is gone and the background is now aqua. Now if you take a look at the get methods in you’re network tab (I use Chrome), you’ll see that in mobile resolution its not loading the images or the stylesheet at all! That means fewer calls to the server and no unnecessary code loading. Something that would have to be improved on with this is on browser re-size because it doesn’t automatically call for the correct stylesheet (the screen has to be refreshed ~ the not perfect part) but again, but with some fine tuning I think this would be a solid fit for RWD.

        Do you have any thoughts on this Jeremy? I’m interested in your opinion.

        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