Carousels continue to be a hot topic. The numbers I posted back in January resulted in quite a bit of discussion. Out of curiosity, I decided to revisit the data now that I have more data to pull from. The following numbers are from January 1 through June 30, 2013. We’ll be looking at the same five sites which include ND.edu and four un-named Notre Dame sites.
Back in January I posted numbers gathered from the HigherEd RWD Directory. The size of the list has more than doubled since then. The bad news? Almost every number has increased (that’s a bad thing). Additional stats since last report includes image count, size and percentage of page weight.
On a side note. Last June the directory had 16 entries. Over the course of the year we added 100 responsive/adaptive sites.
I had the opportunity to re-present my talk (Rebuilding a university homepage to be “responsive”. Twice. In less than a year.) from last fall’s HighEdWeb national conference at this year’s Michigan regional conference in Flint, MI. The majority of the presentation is the same, but it includes updated data from the RWD directory and some interesting stats from the BCS bowl game in January.
Let’s be honest. Google has made their feelings perfectly clear when it comes to feeds. Feedburner has been languishing for years. They were working on a half-baked new interface only for it to disappear. They deprecated its API. It’s obvious the service is no longer actively supported, and with the recent sun-setting of Google Reader, I have no faith it will stick around much longer. So rather than wait for that to happen, I decided to move on now.
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:
- 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.