New Blog Design –> Responsive Design & Web Analytics Musings

If you’re reading this post on the site itself (as opposed to via RSS or email), and if you’ve been to the site much in the past, then you’ll notice the design of the site has been completely overhauled. This was one of my goals for my weeklong holiday break…and it’s a goal I entirely missed! Luckily, though, I wound up with a kid-free/spouse-free weekend a week-and-a-half ago, so I got to tackle the project.

So, Why a New Design?

I updated the design for two reasons:

• The old design was starting to wear on me. There were a number of little alignment/layout/wrapping issues that I had never quite managed to fix, even as I tinkered with the blog functionality (for instance, my social icons never quite lined up well). I also figured out last fall that the nested table structure pretty much precluded me from getting the mix I wanted of fixed and liquid elements. In short, a redesign just seemed in order.
• Responsive web design is here. This was more of the direct-tie-to-my-day-job reason for the overhaul. Various sharp people at Resource Interactive have started pushing responsive web design as something that should be actively considered for our clients. As I dug into the topic, I realized that: 1) this blog is a good candidate for a responsive design, and 2) there are some analytics implications to a responsive design, and I needed somewhere to experiment with them.

So, this site is now using a fully responsive WordPress theme.

What Is Responsive Design, Exactly?

As I understand it, responsive design is an “Aha!” that grew out of the increasing need for web sites to function across a wide range of screen sizes and experiences and platforms: laptop monitors, desktop monitors, tablets (iOS and Android), and smartphones (also iOS and Android). The idea is that, rather than having a “desktop site” and a “mobile-optimized site,” you can have “a site” that works effectively on a wide range of devices.

There are two keys to this:

• The site needs to be viewable in different devices — 3 columns that display on a desktop monitor may need to become a single set of stacked content on a smartphone. Or, a list of links in the sidebar on the desktop may need to become a dropdown box at the top of the page on an iPhone.
• The site needs to support the most likely use cases in different devices — this is a stickier wicket, because it forces some strategic thought (and possibly research and testing) to think through what a visitor to your site who is using an iPhone (for instance) is likely looking to do and how that differs from a visitor to your site who is using a desktop.

Both of these are questions that have always been asked when it comes to developing a “mobile-optimized version of the site,” but they’re a bit more nuanced given that responsive design isn’t a “separate site.”

Wow, Tim, I’m Impressed with Your Coding Skills!

Don’t be impressed with my coding skills.

I did a little research and then shelled out $35 to buy the Rising theme. That doesn’t mean there wasn’t a fair amount of tinkering (and more tinkering yet to be done — I certainly have not fallen prey to a need to have the perfect site designed before pushing it live!), but the end result is an improved site. And, more importantly, having a site that actually works well across devices (Try it! Just resize your browser window and watch the sidebar at the right. Or, fire up the site on your smartphone and compare it to your desktop.)

Now, of the “two keys” above, I really focused on the first one. This is a blog, after all. Regardless of what device you’re on, presumably, you’re here to consume blog post content.

I’m still working with the palette (too little contrast between the hyperlink color and the plain text color), the font selection (I’m not in love with it), and the header logo (pulling what strings I can to get a professional to contribute on that front), but I’m reasonably content with the change. Let me know if you have any tips for improving the design (I’m not proud!).

Where Does Analytics Come into All of This?

While I have access to tons of different web analytics accounts across a range of platforms through our various clients, I don’t actually have a great sandbox for trying things out (you would think our company’s site would be a good testbed, but the reality is that there are so many competing agendas for competing resources there that it’s seldom worth the effort). Luckily, this site has built up enough content and enough of a presence to get a few hundred visits a day, which is enough to actually do some tinkering and get some real data as a result.

Here’s my list of what I’ll be toying with over the coming weeks:

• Responsive design analytics — we’ve had “screen resolution” and “device” reporting for years, but responsive design introduces a whole new twist, because it’s truly experience-centric. I’ve done a little digging online and haven’t found much in the way of thinking on this. While I don’t think it’s possible to directly pull CSS media query data into the web analytics platform, it should be possible to use Javascript to detect which responsive layout is being used for any given visitor and then pass that information to the web analytics platform (as a custom variable or a non-interaction event in Google Analytics). And, it should be possible to record when an onresize event occurs. In both cases, using this data to segment traffic to determine if a particular layout is performing poorly or well, as well as how visitors move through the site in these different experiences, seems like a promising thought.
• Facebook Insights for Websites — I’ve had this running for a while, but, as part of another experiment, I switched over from using my Facebook user ID in the meta data to authenticate my ownership of the site to using a Facebook app ID. That’s a better way to go when it comes to “real” sites, and I’m now actually doing some tinkering on some client sites to fully validate what happens, so look for some thoughts on that front in the future.
• Detecting the Facebook login status of visitors to the site — this is some experimentation that is actively in work. It’s the implementation of some code that Dennis Paagman came up with to use Facebook Connect and Google Analytics non-interaction events to detect (and then — my thinking — segment) visitors based on whether they’re logged into Facebook or not at the time of their visit to the site. This seems like it has intriguing possibilities when it comes to determining what types of social  interactions should be offered and how prominently. I’ve hit a minor snag on that front and am hoping Dennis will be able to help get to the bottom of it (see the comments on his blog post). But, if I get it figured out, I’ll share in a post down the road.
• Site performance — anecdotally, it seems like this site is now loading more slowly than it did with the old design. The Google Analytics Site Speed report seems to indicate that is the case, but I don’t feel like I have enough data to be conclusive there just yet. I have signed up for a site24x7.com account, which is a platform we use with some of our clients for a couple of reasons: 1) to see what it reports relative to Google Analytics (it’s a fundamentally different data capture method, so I’m not going to be surprised if the results are wildly divergent), and 2) to get more reliable data if I start playing with changes to reduce the site load time. In hindsight, I wish I’d signed up a month or so ago so I had good pre- and post- data. If I had a nickel for every time I wanted to have had that, I’d be a wealthy man!

In a nutshell (a gargantuan, artificial nutshell, I’ll grant you), I’ve got a backlog of topics, some of which will require some additional experimentation. This blog post, I realize, is almost more of a “to do” list for me than it is a “how to” list for you! Oh, well. They can’t all be winners!