The rise of the carousel August 10th, 2012

Over the last 6 months I’ve managed the collaboration between Digirati (my employer) and a number of design agencies were we’ve jointly engaged to deliver CMS integration projects.

All these sites have one thing in common – they include a carousel on the home page. Not a bad thing however I fear that the carousel is becoming ubiquitous, used to appease the cross department demands placed on home page real estate. Once departments are given a place on the carousel each feels happy that their needs are represented front and centre.

With insight and real case examples the successfulness of the carousel may well prove inadequate to deliver on its promise.

Whilst running user testing at all stages of design and worryingly so on live sites it’s become ever so apparent that the majority of users for the following reasons miss or don’t act upon the messages included as carousels.

1. Carousels often look like adverts. They are similar in size to MPU adverts and when coupled with the fact that carousels often ‘auto play’ they become animated mimicking an advert. These cases result in situations were banner blindness means that the moderately experienced web user tunes out from such content because of the similarity to adverts.
2. In some cases the carousel navigation offered is so subtle that if content is seen, users wait until it returns before they follow links of interest. Navigation needs to be clear and efficient to ensure it’s used.
3. It’s understood that online reading is replaced by scanning for trigger words. Users with specific tasks scan for these triggers or phrases that they expect to find. When content is predominantly pictorial or promotional in style it runs the risk of being missed, again the result of banner blindness as noted previously.

So where did the carousel originate?

The first ‘main stream’ use of the carousel is that seen as part of the iTunes user interface. Here Apple took the analogy of the carousel from the jukebox that many music fans are familiar with. Fittingly this is a great digitization of a very tactile interaction that many will have encountered before and so matching the mental model of navigating a vast music collection.

When this interaction is taken out of this space its familiarity is lost. Experienced (apple) users are familiar with information being made available in this way. Those less exposed to apple products, often, during user testing session’s falter in successfully finding or navigating content presented as part of a carousel.

Why then are carousels so prominent?

This question I feel can be answered in two parts. Carousels have become popular because they are included as part of and simple to deliver because they are;

1. Included as a default asset in almost all wireframing tools and so the designer creating wireframes falls into their comfort zone of including such functionality as its there in the asset pallet by default.
2. In the same way carousel functionality is included as a simple include in almost all javaScript libraries or for the more able javaScript developer a nice component with a level of complexity that would interest them in coding a bespoke solution themselves.

Point 1 is why I shy away from using wireframing tools with predefined assets as I myself often fall pray of including what comes as standard rather than identifying and developing a more suited solution. I prefer to wireframe with a pen and paper, for me it’s faster, more disposable and allows for each problem to be solved in ways most appropriate rather than by the most fitting template available in my tool of choice that day.

Point 2 is no bad thing – the availability of cross platform cross browser tested javaScript is a godsend for front-end development and I would expect it difficult to find a javaScript developer that did not prefer to use their library of choice on projects. The extremely competent javaScript developers that I have had the pleasure of working with all use these libraries for the heavy lifting and follow the Douglas Crockfrod school of thought that libraries are great for prototyping but when it comes to delivering performant production code you’ll need to be writing functions that do only what you need without the redundant overhead of the rest of the plugin, extension or function.

This is my point that many carousel functions do what’s needed well in delivering the functionality to alternate content within the defined component. Where most fail is in their level of affordance – the means offered to the user to successfully navigate the carousel are regularly quite subtle with little suggestion as to what they allow or on what they will have effect upon.

What the solution?

With all this said in some situations carousels solve very real needs and are fitting with the prior experiences and expectations of site users. What follows is my metal check list used when I come across carousels that aims to question and identify the reasoning for the inclusion of the component to ensure that its both useful, usable and successful.

When reviewing live sites. 1. Is it (the carousel) easy to navigate? 2. How similar are the dimensions and transitions to adverts? 3. Is the message and call to action clear and simple to comprehend?

In addition when reviewing wireframes including carousels 1. Are all transitions and states documented? 2. Are all CMS requirements captured? 3. What questions have not been resolved by placing all the content in one carousel?

These questions aim to ensure that when carousels are included that their content is well considered; its delivery is in context meeting with the expectations and prior experience of users and importantly all business requirements are successfully answered and meet.