Web Standards Sherpa : A Case Study

December 22, 2014

Earlier this year, I had the privilege to work on a very high profile site in the Web Standards community, Web Standards Sherpa. Our goal was to revamp the site with a mobile-first approach to the responsive layout. As I look back on the year, this project stands out as one of the projects I am most proud of.

Background

I started working with Web Standards Sherpa in January 2013 after I joined Easy Designs. We would take time out of client work to periodically invest into Sherpa to fix things, add new features, or just improve upon the current features of the site.

One thing that I noticed when first working with the site is that it did not appear to be responsive. If I viewed the site on a tablet or phone, I got a scaled view of the site. I had assumed that the site had launched prior to responsive layouts becoming a widely adopted practice. As Aaron Gustafson points out in his article about the revamp, the Sherpa team decided late in the project to make the site responsive and chose a desktop-first approach.

But as I was observing, the site was not working responsively in several of the devices I tested it in. As I dug under the hood, I discovered that the developer who had built the site was using some scripting tied to ExpressionEngine to serve different stylesheets based on media queries. We had upgraded the ExpressionEngine software in the Fall of 2013 and I believe the functionality to serve the different stylesheets was no longer working. Because the site was built with a desktop-first approach, the desktop stylesheet was the only one being applied.

Getting Started

At the beginning of this year, we had some breaks in between client work and decided that the time had come to work on the revamp. A majority of the work fell on my shoulders and it was a challenge that I was excited to get started on.

During my first year at Easy Designs, I had tackled several projects that required taking legacy fixed-width sites and making them into mobile-first responsive layouts. My experience with these project helped shape some best practices for approaching making fixed-width sites responsive

Looking for Clues

Because there had been some thought into the mobile and tablet views when the site was first launched, I decided to see what those layouts were. I enabled the stylesheets on my local development environment and studied the layouts. This research was helpful and gave me some tracks to run on. I also had some ideas on how to improve upon that work and carry more of the spirit of the desktop design through to the mobile and tablet views.

Fixed Width to Fluid

One of the tenets of a responsive layout is that it is fluid instead of fixed width. Like the retrofit projects I have done in the past, one of the first things I do is to move layout styles (such as widths and floats) into the media queries for the tablet or desktop views. Now my content is linear and it gives me a base to start working with a mobile-first approach.

I changed media queries to be em based instead of pixels. Lyza Gardner wrote about the advantages of this approach two years ago. As Aaron mentioned in his article, an em based media query approach provides the most appropriate reading experience based on the user’s font-size preference. If the user chooses to increase or zoom, the layout will respond to that zoom because the media queries are relative to the font-size.

Adding Breakpoints

As Aaron mentioned in his article, the current version of Sherpa went from three breakpoints to nine. I have several convention breakpoints that I use in just about every project. But I also don’t want to be limited by those breakpoints.

Mark Boulton, Jeremy Keith and others have advocated determining breakpoints by where the content “breaks” and needs attention. I used that as a guiding principle as I began to rebuild the Sherpa site. I added breakpoints as I needed to tweak the design to provide a solid reading experience across the board.

One of the specific ways that I did that has to do with the feature content area on the homepage.

Homepage Carousel

The site had originally been built so that only three features were written in the HTML. Then using JavaScript (jQuery), the carousel of features was built. As we revamped the site, we wanted conditionally load the features carousel at specific width. I will talk more about this later.

Initially, there are three features. The default layout was to stack these three vertically with the current issue on top. Taking a cue from the desktop design, I wanted to make the current issue more prominent than the other two features. I accomplished this by using bigger font sizes for the content and the link button.

I then began experimenting by resizing my browser window to determine a good width to make the layout more interesting. I determined that around 550 pixels was a good point to have more than a single-column layout. My main breakpoint was at 600 pixels. But I did not let that keep me from changing the layout where it seemed to work the best.

To keep the prominence of the current issue, I had it span two columns and conditionally loaded the teaser image. The other two features use a display:table-cell to create two columns of equal height.

I had considered having the features go three across at a certain breakpoint. But after some experimentation, it never looked quite right so I carried over the two column layout until the desktop view which becomes a carousel of content around 1024 pixels.

Conditional Loading

One technique that I picked up while working with Aaron at Easy Designs was conditional loading of content. The idea behind this is that we only serve the user content at the appropriate condition. I have seen many places where content is hidden with display:none until a certain breakpoint.

The disadvantage to this approach is that the content is still part of the DOM and loaded into the page. By conditional loading resources only when they are needed, we can avoid hiding page elements and decrease page weight which leads to better performance especially on smaller devices with limited bandwidth and data charges.

I used conditional loading several places on Sherpa to improve the performance of the site. The comments section is only included when the user taps on a link. The homepage carousel was refactored to swap out the three features for a full-listing of articles and then back to three features when the page width is under 1024 pixels.

I used two techniques to conditionally load content. First, I used a script Aaron had written that gets JavaScript and CSS to work together using the same breakpoints that are defined in CSS.

Secondly, I used a modified version of a dependent anchor include script that Aaron have developed using work from Scott Jehl and Emil Bjorkund. This script allows you to use data attributes in your HTML to define at what breakpoint you want conditionally load content. You use another data attribute to define the content to include.

<a id="comment-loader" data-include-on-tap="" data-replace="/comments/reflecting-on-the-revamped-sherpa/" data-include-size="5" href="/reviews/reflecting-on-the-revamped-sherpa/comments/#comments">View comments on this entry and add your own</a>

Optimizing the Reading Experience

Several decision I made were targeted at optimizing the reading experience. The reason people come to the site is to read the articles and learn from our Web Standards experts.

One of the decisions I made to keep the focus on the content was to increase the body text size for both mobile and tablet. Because I was working with ems, it is very easy to change the default base font for smaller screens and tablets.

Secondly, I decided to stick with a one column layout for tablets. I had experimented with implementing the same two column layout for reviews and Ask the Sherpa articles for tablets. But with increasing the font sizes, it was a better reading experience to stay with one column and allow the user to just focus on the task of reading.

There were places with secondary content that I used the same pattern from the homepage feature to have one column span over two columns underneath it.

And just as I had done with the homepage features, I let the content dictate when to implement the change to two columns for this secondary content.

Optimizing the Homepage Carousel

One final way that we optimized the site was to change the way that the feature carousel worked. Originally, the carousel would be built by JavaScript once the browser was at a specific width. But what happens if you resize the browser or change device orientation?

We refactored the script to clone the code of the features which is written in the HTML (3 list items). The expanded carousel was already being built by JavaScript. We created variables to store the code for the default feature and the expanded feature so that the correct one could be implemented when the browser resized or the device orientation changed.

We could have just hid the extra items in the expanded carousel when the browser was resized smaller but we felt it was a better approach to just go ahead and switch them out. It is a little detail that most readers will not recognize but we felt it was the right way to do it.

Epilogue

I was very pleased with how this project turned out. I believed that it was very important for this site that champions Web Standards to showcase one of the best practices for building sites for our multi-device world. And as a user of the site, I am glad that I have an optimal experience when I read articles on my Nexus 7.

As a developer, this project gave me an opportunity to implement best practices, experiment with new approaches, and continue to learn more about how to best build mobile-first responsive websites.

Here are a couple of things I did not cover but you might want to investigate as you develop mobile-first responsive sites.

• I made links touch friendly
• I used Jake Archibald’s technique of sass-ie
• I used Grunt

I want to thank Aaron Gustafson for writing his article, Reflecting on The Revamped Sherpa. I had wanted to write this case study for some time and his article helped give me a nudge to document my thoughts. I think it is important to share what we learn and be able to see into each others’ processes. I know that I have learned so much for others who have drawn back the curtain.