Category: Web Development

Carousels Are Useless

Carousels are a lazy and ineffective way to surface content on the web. Stop using them.

— End of Post —

Earlier this year, Erik Runyon the director of web stuff at the prestigious University of Notre Dame, took a close look at how their users were interacting with carousel content.

He found that of the 1% of users even engaging with the carousel in the first place, 84% clicked on the first item in the carousel and PRACTICALLY NO ONE (~4% each equally) clicked on the remaining items.

To put it another way, you gaining practically nothing by putting content in a slider.

This data mirrors my recollection of the tracking we ran on hiphopdx.com when we were working on a redesign circa 2010.

This is not new information, yet carousels are more popular than ever.

If you absolutely must use a carousel, take a read through Brad Frosts post over here.

But seriously, find a better solution.

Update: Chris Noto asks a good question in the comments “why is hiphopdx.com still using a carousel.” While I can’t answer for certain, I tried.
TL;DR – the 0.04% of visitors who click through the last item in a carousel still generate real dollars in ad revenue.

Dot-Com Era Browser Tech

Thanks to my RetroPosts plugin, this weekend I was reminded of a blog post I wrote in 2008 – Web Dev Challenge: 1996 Compatibility. In the post I outlined rules for developing for browsers from 1996: CSS1, Javascript 1, 640×480 screen resolution, etc. I think I assumed this would be a relatively simple challenge, but I didn’t ever follow through with the plan.

In the post I mention developing for Netscape version 2 in the post. I don’t recall actually attempting to run the browser at the time of writing, so last night I decided to track down a copy of Netscape 2 and poke around the web. Unfortunately Netscape Navigator 4.01 was the earliest version of Netscape I get my hands on. To my surprise it actually installed and ran in Windows 7! Talk about backwards compatibility.

This sums up my experience using Netscape.
This sums up my experience using Netscape.

Every single website I tried gave me dozens of javascript errors on load. It’s easy to forget how ubiquitous Javascript usage is. Even sites that don’t have any dynamic features, are likely calling jQuery, Google analytics or an ad platform. As far as I could tell, Netscape 4 does support Javascript 1 (and Internet Explorer’s ECMA script), but it would seem that modern javascript has evolved so much that these standards are irrelevant. I doubt any developer has considered Javascript backwards compatibility in the past decade, I wonder if it would even be possible.

Once the Javascript errors were dismissed, the sites themselves rendered fairly similarly to what you’d expect from a browser with CSS turned off. Wikipedia states that Netscape 4 added support for “CSS1 elements, minimal dynamic font support and the proprietary object element.” I had forgotten just how limiting this was.

A small gallery of modern sites viewed in Netscape 4.

I also took a look at the web in Internet Explorer 3. With full(?) CSS1 support, ActiveX and Java applets (not to mention Comic Chat) at the time Internet Explorer 3 was poised to upset Netscape’s market dominance. In my testing, the web looks much the same as it did in Netscape 4 with the exception of the javascript errors (which I suspect Internet Explorer was simply hiding).
The Google homepage is virtually perfect.
Though the Google homepage is virtually perfect.

The first browsers with support for anything resembling modern front-end features were versions 6 of Netscape and Internet Explorer, released in 2001. That’s after the collapse of the dot-com bubble! Investors were spending billions of dollars on technology that couldn’t even render a png!

In conclusion, I think my original idea of developing a 1996 compatible site would be a lot more difficult than I had thought. But given that this era of browser technology represents such an important time in the Internet’s history, I think it would still be a worthwhile endeavour. Who’s up for it?

Please don’t customize social media icons

When I put on my front-end developer hat, I’m often the last line of defence between the client and an unfortunate typo, bad idea or missed opportunity. I’m the last pair of eyes to examine a design before it hits the development environment. Designers probably hate me for it, but if I see a design choice that doesn’t make sense to me, I’ll mention it.

One of the most common design choice that irks me is customized social media icons. Web designers seem to have an inescapable need to redesign Facebook, Twitter, Google+, LinkedIn, whatever.app’s icons to match the overall look and feel of the site. One one hand, I can almost understand the appeal, these logos can stick out like a sore thumb. On the other hand, that’s the entire point!

Brands like Twitter and Facebook spend massive amounts of time and money tweaking their identity. They spend even more money marketing their brand, getting it in everybody’s face. Facebook’s white ‘F’, Twitter’s blue bird are immediately recognizable. In my humble opinion, if you actually want website’s visitor to notice and use those sharing features I’m supposed to implement, it’s probably a good idea to follow the social network’s brand guidelines. If you want people to share your content or follow the @account, it’s not a great idea to have the social media icons BLEND IN WITH THE REST OF THE SITE!

I’d love to do an A/B test to examine this theory.