Erik Runyon

In the early days of RWD, it became evident that we could not (and should not) tie our breakpoints to the widths of popular devices. I’d like to think this is a fairly popular view these days. This is partially due to the influx of internet capable devices all with differing screen sizes and resolutions. Though a majority of these are phones and tablets, this also includes gaming consoles. In September, Anna Debenham wrote an article on A List Apart titled “Testing Websites in Game Console Browsers” where she wrote about the emergence of browsers in popular gaming consoles and the variety of input types that comes with them.

I had the privilege of presenting at HighEdWeb again this year in Milwaukee, Wisconsin. One of the highlights was the keynote by Adam Savage of Myth Busters fame. Even though the keynote and following Q&A session was long by typical standards, everyone seemed disappointed when it came to an end. And quite an explosive end at that. Adam closed with a video montage of some of the best explosions from Myth Busters.

Two things up front. I love stats, and I love Gaug.es. I love Gaug.es so much, I have it open as a tab 100% of the time on both my development machine and my iPad. What I don’t love is using Gaug.es on my iPad. There are two small issues that bug me while on the iPad.

1. I can’t drill-down to the browser detail in the Technology section
2. The layout is fixed-width and doesn’t work well in portrait

Like I said, small issues. As we developers tend to do, I decided to write a little hack to fix these issues.

[4]: javascript: (function() { var g = document.createElement(‘script’); g.type = ‘text/javascript’; g.async = true; g.id = ‘gauges-script’; g.src = ‘http://weedygarden.net/demos/gauges-ipad/gauges.js’; document.getElementsByTagName(‘head’)[0].appendChild(g); })(); [5]: http://twitter.com/orderedlist

Flexible grids, flexible media and media queries. The three basic building-blocks of Responsive Web Design. And though most of the public debate lately has focused on the second, developers have quietly grumbled about the first. Not an outcry by any means, but minor complaints and frustrations. One of these complaints is centered around browsers and the differences in their rounding of our lovely six to twelve decimal widths. In some of my early responsive sites, I spent way too much time fighting these rounding errors, and some to no avail. Which leads me to a topic I’ve wanted to discuss for some time, but have been holding off until I was positive about my views. But today’s post by John Albin Wilkins has prompted me to get something down in writing.

On the new ND.edu we used a combination of server-side detection, media queries and javascript to determine content. We made the decision that not all content needed to be initially loaded for mobile devices, and instead made it available through top-level navigation. This allowed us to drastically reduce the amount of resources that are initially downloaded and the result is a very fast mobile experience. They say a picture is worth a thousand words, so I’ll leave you with an image of the site on a phone next to a 70″ display and some stats.

My 2010 article about hi-res background images gave a pretty simple example of how to replace a background image with a 2x version for the fancy hi-res devices that are hitting the markets. In this example, I’ll show you how to do the same, but with an image sprite. And to wrap things up, I’ll leave you with a limitation of the technique.

The latest version of ND.edu makes use of A LOT of external data sources. To make sure the site runs reliably, even in the case of an outage by one of the external feeds, I put together a fairly simple PHP class to handle the local caching of feeds.

It basically works like this:

1. Create the class with the local file-name (whatever you want) and the external source (and an optional expires)
2. The class will check if the local file exists and if it has expired
3. If it has expired, it will try and fetch the remote source
4. If the remote source is a-ok, it will pull a fresh copy and save it to a “cache” folder
5. If remote source is unavailable or too slow, the class will fall-back to the expired (cached) file

While building the most recent ND.edu, I ran into a little iOS 5.1 bug (at least I think it’s a bug). One of the features of the site is a menu with “position:fixed”. Another feature is we load a number of top-level pages on to the homepage for larger screens. So the functionality is such that, if someone is on the homepage, and they click one of the main navigation items, we scroll them to that section rather than loading that page. But we quickly ran into an issue on iOS devices.

Over the past couple of months, our group over at the @NDWebTeam has been redesigning the main ND.edu website. What we quickly realized is that ND.edu has a lot of lists. And since part of our design process was to have the site scale from mobile to wide-screen, we wanted to make use of css3 columns to shiny-up those lists. In the past, we would have floated the list items with set widths, but this is 2012 and we don’t want to do that anymore. Outlined below is the progression our designer Philip Zastrow and I went through to get these lists functioning how they should.

So first thing to do is set the column count and gap. This is where we ran into our first problem.

Back in November, Chas Grundy wrote about our emergency procedure for ND.edu. When we implemented this feature for ND.edu, we based the functionality on a single-source file. This gave the ability to update the message on both ND.edu and emergency.nd.edu quickly and easily. The added bonus to this approach is that we could then use that same file to build a script that could be used on any Notre Dame site to display the emergency message. But I’m getting ahead of myself.