Yesterday Luke Wroblewski asked the interwebs about the average size of a RWD site. While I obviously can’t speak to the wider range of RWD sites, I do happen to maintain a list of HigherEd RWD sites. The numbers that I track are by no means the whole story when it comes to performance, but I find them interesting.
Carousels. That gem of a web feature that clients love, and many developers hate. One thing is certain, they are the darling of HigherEd. In fact, they’re loved so much, I’ve been assigned many times to retroactively add them to sites that have already been live for years. This led me ask how much are users really interacting with the carousels. To answer this question I added tracking to to the main feature on ND.edu as well as four other Notre Dame sites with carousels, three of which are static, and one that automatically slides the features. Here’s what I’m tracking:
- Number of times the feature is switched by users
- Total feature clicks
- Total clicks per position
I’m also tracking interactions such as how many times the feature is switched using arrows vs. the dots (pagination), but that’s not the focus of this article.
My holiday vacation project this year was to migrate this blog off Wordpress into a system that better fits my brain. After quite a bit of research I decided on Jekyll. I decided to move off Wordpress because I often found myself fighting with the admin and editor just to do simple things. I was fine working in the HTML view, but I prefer the simplicity of writing in Textile or Markdown.
So why Jekyll?
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.
- I can’t drill-down to the browser detail in the Technology section
- 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.
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.
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:
- Create the class with the local file-name (whatever you want) and the external source (and an optional expires)
- The class will check if the local file exists and if it has expired
- If it has expired, it will try and fetch the remote source
- If the remote source is a-ok, it will pull a fresh copy and save it to a “cache” folder
- If remote source is unavailable or too slow, the class will fall-back to the expired (cached) file