ClearMenu is a project by the folks at Unit Interactive, including me, as a design experiment and commentary on the state of web design in the food industry. You can read more about the project and all the mini-sites at the ClearMenu site. This is a multi-part series on my contribution, “SportsBar”. The previous entry focused on the layout development. This third part focuses on the development of the page behaviors.

The Media Query Problem

We’re quickly approaching the point in our industry where designing websites responsively is no longer optional. With the unrelenting rise in internet use on mobile devices the pages we design and build for clients simply need to work well everywhere. Unfortunately, the technology for effecting responsiveness is fractured and we’re still arguing about best practices. So, for this project I spent a lot of time considering the “right” way to do responsive.

Using media queries to switch styles at certain break-points is the default option at this point and they have their advantages. The switch is slick and fast, but you pay a price for it. The first problem is that not all browsers support media queries. An argument that doesn’t really do it for me as I’m fine with leaving the old browsers in the dust. The real problem is that browsers don’t ignore styles they don’t currently need. They instead download everything (including unused background images) and store them in case they are needed.

For my project I decided to try out a technique for creating visually random background images dubbed the Cicada Principle. The diamond pattern with various sports balls is actually made up of three separate images of different sizes layered in such a way as to make the ball pattern hard to discern. (The different colors are generated using RGBa backgrounds on the various sections.).

This technique yields great results (and can be a mind bender to work out) but caused an issue for me. I didn’t want to serve all of these images to mobile devices. I could hide them using media queries but I couldn’t stop the images from being downloaded, eating up bandwidth, and slowing the page load. Media queries just weren’t going to work for me.

Adapt.js

I had another responsive need beyond loading the minimal necessary styles for mobile. My page needed to trigger some very significant Javascript changes at the exact same time that the styles were switched. Luckily for me Nathan Smith wrote the excellent Adapt.js - a small script that would allow me to switch styles and Javascript behaviors using the same logic.

Adapt.js works by using Javascript to read the horizontal width of the user’s screen and then loading only the specified CSS file for a given range of widths. Because it loads only the necessary styles, mobile devices never have to download superfluous resources. In addition, Adapt.js provides a callback option that fires when a switch is made and passes which switch occurred to your callback function. This is what allowed me to adjust my bindings in conjunction with style switches.

To further optimize this process I created a base stylesheet that is on every page regardless of window width. This sheet contains the very basic styles used in the lowest resolution layout. I set Adapt.js to only engage at a higher width, so at the very narrowest widths, no additional styles are added via Javascript.

Contextual Loading

Load time is a huge consideration for designing for mobile users and so is focus. It’s much easier to get lost on a full page of content when staring at a 3.5” screen and navigating with your thumb. To help with this, I set up the SportsBar menu sections to live on their own pages by default. If you pull up say, the “starters” section on an iPhone you will only see that section and can go to other sections (separate pages) using the menu navigation, now located at the bottom of the page. For larger screens, the sections are all loaded into a single large page using Javascript. Mobile users are served a contextual experience that loads faster and has a simpler navigation scheme.

Scrolling Images

Another feature that is loaded via Javascript, and only for larger resolutions, is the image swapping on scrolling. This behavior was a central mechanism to the entire design and caused me no shortage of headaches (more on that in part four). However, I think it is important to note that no images are loaded by default on the page in another nod toward mobile-first development.

The images are discovered by the script and then added to the page. Users on mobile devices don’t see the food images by default and are unencumbered by waiting for them to load. Instead, smaller resolutions can click on an item to get a simple light box presentation.

There are other things that could be mentioned, but I hope this rundown has communicated the amount of thought and development that went into realizing a relatively simple site. Developing responsively with complex page interactions is neither simple, nor easy. I’ll cover some caveats and concerns in the final entry into this series.

• Part one of this series, “Design”
• Part two of this series, “Layout Development”
• My Menu
• ClearMenu.com Home

ClearMenu is a project by the folks at Unit Interactive, including me, as a design experiment and commentary on the state of web design in the food industry. You can read more about the project and all the mini-sites at the ClearMenu site. This is a multi-part series on my contribution, “SportsBar”. The first part focused on the design. This second part focuses on the layout development.

Golden Grid System

I design and develop my sites on a strict grid - a column structure and a vertical rhythm. For years I had developed just a single static layout for my designs. Recently I had begun to develop several static layouts and to switch between them using media queries that detected window size. This worked as far as it went, but it didn’t go far enough.

As Ethan Marcotte argues in Responsive Web Design, for a design to be truly responsive it must be liquid. Only in this way can the layout adjust itself for any possible browser resolution. I was keen to try his methodology for this project but there was a major hurdle. For grid-based layouts to really work, the gutters and basic rhythm unit must match up perfectly. Otherwise you violate the principles of quiet structure.

Liquid layouts use percentage widths to stretch and contract the columns. The widths of the columns and gutters adjust to the window width but the rhythm stays static. This results in discrepancies between the two which breaks the harmony of the design. Not good.

Enter the Golden Grid System. Joni Korpi noticed a new toy included in all modern browsers: box-sizing. By setting box-sizing: border-box browsers can now calculate elements’ widths outside of their padding. This means we can have containers, with padding, that have percentage widths. That means we can have fluid layouts without compromising gutter size! (Here’s a more complete explanation.)

Another New Toy

There is one aspect of the Golden Grid System that I hated: using EMs to set the type, rhythm, and gutter sizes. I’ve been on a vendetta against EMs for years. I hate them. That they are a relative sizing unit is great. That they are relative to the parent element is a complete nightmare. So, it was with great delight that I learned of a new unit that is available in modern browsers: the REM.

REM, like EM, is a relative unit but unlike EM, REM is always relative to the HTML element. If the font size set on your HTML is 10px and the font size on your element is 2.4rem your resulting font size will be 24px. Every. Time. No fussy math or 10-decimal numbers. You can easily zoom your entire grid by adjusting the font size of the HTML element and you can do that with pixels. (Again, here is a better explanation of REMs.)

Thus armed I went about crafting my first truly responsive design - using percentages for column widths and REMs for font sizing and gutter widths. If you are interested in seeing how the design lines up on the grid, you can add ?grid=true to the end of the URL of my menu to reveal the Golden Gridlet (three lines, upper right). Clicking on this will show you the grid.

Shifty Navigation

I was almost there. The final piece to my layout puzzle was the navigation. As I mentioned in part one, the navigation shifts between the top of the page for larger resolutions and the bottom of the page for smaller, presumably mobile resolutions. I was lucky enough to have caught a post by Jeremy Keith on achieving this very thing using pure CSS. In short, by setting the body to display: table and the navigation element to display: table-caption you can move the navigation to the top or bottom of your page at will and compromise nothing in the process. Using this technique I was able to realize dramatically different designs for my navigation without resorting to Javascript.

There you have it - the building blocks for the responsive, liquid layout of my menu. In part three I’ll take a look at page behaviors and stylesheet switching.

• Part one of this series, “Design”
• Part three of this series, “Page Behaviors”
• My Menu
• ClearMenu.com Home