Erik Runyon

Sometimes (read a lot of times) we have to put carousels on our sites. And even though we’ve shown numbers that they’re not effective, we end up adding them anyway. So in an ongoing effort to find ways to reduce the impact on performance, we look for simple to implement ways to cut down on the number of images loaded.

In a previous post I wrote about moving from Wordpress to Jekyll where I was ultimately hosting this site in GitHub Pages. While that setup was great, and an easy way to get started, I wanted to have a little more freedom to play with plugins and additional/custom functionality. To that end I migrated the system into Octopress and reverted to hosting with the same server from which I was running the previous Wordpress install. I had waited to cancel the hosting service just in case I decided to do this.

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:

1. Number of times the feature is switched by users
2. Total feature clicks
3. 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?

1. I can write my posts in Markdown.
2. It uses Liquid for its templating. I’ve been using Liquid for a long time, so I’m very comfortable with it.
3. Jekyll sites can be hosted for free on GitHub Pages.

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.

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.