Carousels are bad for Accessibility

I’ve never been a fan of carousels. They’ve become a crutch for designers and clients who want to spice up a homepage presentation with something that moves. ShoulIUseACarousel was shared by a lot of folks I follow, NetMagazine did an interview with the accessibility expert who created the site.

JS: Carousels are seemingly an easy fix to two universal design problems: how do I fit so much content into so little space, and how do I decide what content is the most important? It’s easy to justify away the usability issues of a carousel when you consider the benefits of presenting multiple content pieces in such little real estate

From: Accessibility expert warns: stop using carousels | News | .net magazine

From an information architecture perspective, Travis Lafleur provides a better alternative. In spirit, it’s very similar to the approach we used on DCUnited.com back when I was there.

Consider this simple, straightforward alternative. First, determine essential content to be featured on the page. Keep in mind the desired outcomes of the project as a whole, the mindset and goals of your users, and what actions you want them to take on the particular page. Next, prioritize. This can be as simple as assigning numbers to each item. If users notice only one thing on the page, what should that be? If they notice two, what should the second be? – and so on. If you’re having trouble prioritizing – or have too many items to promote – consider breaking the content into logical groups and spreading it over multiple pages.

From: Biggs|Gilmore – A Critique of Carousels

It turns out they also don’t lead users to take meaningful actions.

I’m sure you’ve come across dozens, if not hundreds of image sliders or carousels (also called ‘rotating offers’). You might even like them. But the truth is that they’re conversion killers.

From: Don’t Use Automatic Image Sliders or Carousels, Ignore the Fad

Eric Runyon has the stats to back this up, click through to see how many people click beyond the first slide.

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.

From: Carousel Interaction Stats | WeedyGarden

Finally, Jack Shepard lists better alternatives to using a carousel slide.

Let me preface this by saying this discovery is not anything new, however unless you’re really geeking out you won’t be in the know on this stuff.

From: The cure for the common image slider carousel

Measuring Site Speed localy

This is a cool utility that uses YSlow! and PhantomJS to measure your site’s speed across many pages. Should be good for identifying slow individual pages as well as practices that impact multiple pages.

This is how it works: You feed it with a start URL and how deep you want it to crawl. The pages are fetched and all links within the same domain from that page are analyzed, and a couple of HTML pages are created with the result. Sounds simple?

From: Performance Calendar » Do you sitespeed?

Building CandiData

This past weekend, my colleague and friend Sandy Smith participated in Election Hackathon 2012 (read his take of the hackathon). We built our first public Musketeers.me product, Candidata.me. This was my first hackathon, and it was exciting and exhausting to bring something to life in little more than 24 hours. Our idea combined a number of APIs to produce a profile for every candidate running for President or Congress in the United States. The seed of the idea was good enough that we were chosen among 10 projects to present it to the group at large on Sunday afternoon.

Under the Hood and Hooking Up with APIs

We used our own PHP framework, Treb, as our foundation. It provides routing by convention, controllers, db acccess, caching, and a view layer. Along the way, we discovered a small bug in our db helper function that failed because of the nuances of autoloading.

I quickly wrote up a base class for making HTTP Get requests to REST APIs. The client uses PHPs native stream functions for making the HTTP requests, which I’ve found easier to work with than the cURL extension. The latter is a cubmersome wrapper to the cURL fucntionality.  

To be good API clients, we cached the request responses in Memcached between an hour to a month, depending on how often we anticipated the API response to change.

Sandy also took on the tedious – but not thankless – task of creating a list of all the candidates that we imported into a simpl Mysql table. For each candidate, we could then pull in information such as

  • Polling data from Huffington Post’s Pollster API, which we then plotted using jqplot. Polls weren’t available for every race, so we had to manually match available polls to candidates.
  • Basic Biographical information from govtrack.us
  • Campaign Finance and Fact Checked statements from Washington Post’s APIs.
  • Latest News courtesy of search queries to NPR’s Story Api.
  • A simple GeoIP lookup on the homepage to populate the Congressional candidates when a user loads the page

Bootstrap for UI goodness.

I used this opportunity to check out Twitter’s Bootstrap framework. It let us get a clean design from the start, and we were able to use its classes and responsive grid to make the site look really nice on tablets and smartphones too. I found it a lot more feature filled than Skeleton, which is just a responsive CSS framework and lacks the advanced UI elements like navigation, drop downs, modals found in Bootstrap.

Improvements that we could make

We’ve already talked about a number of features we could add or rework to make the site better. Of course, given the shelf life this app will have after November 6th, we may not get to some of these.

  • Re-work the state navigation on the homepage so that it plays nice with the browser’s history. We did a simple ajax query on load, but a better way to do it would be to change the hash to contain the state “http://candidata.us/#VA”, and then pull in the list of candidates. This would also only initiate the geoip lookup if the hash is missing.
  • Add a simple way to navigate to opponents from a candidate’s page.
  • Allow users to navigate to other state races from a candidate’s page.
  • Get more candidate information, ideally something that can provide us Photos of each candidate. Other apps at the hackathon had this, but we didn’t find the API in time. Sunlight provides photos for Members of Congress.
  • Pull in statements made by a candidate via WaPo’s Issue API, maybe running it through the Trove API to pull out categories, people, and places mentioned in the statement.
  • Use the Trove API to organize or at least tag latest news stories and fact checks by Category.

Overall, I’m very happy with what we were able to build in 24 hours. The hackathon also exposed me to some cool ideas and approaches, particularly the visualizations done by some teams. I wish I’d had spent a little more time meeting other people, but my energy was really focused on coding most of the time.

Please check out CandiData.me and let me know what you think either via email or in the comments below.

Web design fail: Northlanders

Its amazing to still come across web design failures like this one. The image above is a screen cap from the Northlanders, a site about a series of graphic novels about Vikings. The main purpose of this site is to sell the books, either physical or digital copies.

The designer, who is undoubtedly from a print background, realized this and used the large white circles and large text to draw the visitors eye to those element. But they failed massively by only making the small text below the “Buy…” headers the clickable links, as I highlighted above. Anyone who actually wants to purchase the books has to be lucky enough to mouse over just the right area to find the link.

This is a multi-level fail. We’ll ignore the fact that the underlying markup is table-soup from 1999. At least the large text should be a link, most users will hover over that first, not the smaller text below. What’s worse, the links aren’t simple link elements, it uses an image map to define the clickable regions, since all 3 circles are part of a single image. And, if you decide go and use an imagemap, why do you not make the whole circle clickable using the circle shape allowed in imagemaps?

You might think that such design decisions don’t matter, but this design makes it harder for users to buy what you are selling. Its costing you sales, and it doesn’t need to.

Responsive Design

I’ve updated my theme here to make the layout more responsive depending on the device you view it in.  For both smart phones and iPads/tables, the layout linearizes. That is a fancy way of saying the right sidebar should scoot below the main content area, and everything will become 100% wide to fill the screen. 

I did this using CSS3 media queries, this technique only works in newer browsers, including Chrome, Firefox. and Mobile Safari.

First, the viewport tag will help different devices render the page correctly. After reading, Choosing a viewport for iPad sites, and A tale of two viewports — part two, I added this to my page template

{syntaxhighlighter HTML}

I then added three blocks of media queries to adapt the layout depending on the device, the first block linearizes the page content if the device screen is less than 1024px wide. The second and third blocks fix some font sizes so that text renders legible on different devices.

{syntaxhighlighter CSS}
/* LINEARIZE CONTENT */
@media only screen
and (max-device-width: 1024px) {
#wrapper {
width:auto;
padding:10px 10px 0;
}
#container,
#page {
width:auto;
margin:0;
padding:0;
}
#rgCenter,
#rgRight {
float:none;
clear:both;
}
#rgRight {
background-color: #e3e3e3;
padding:20px;
margin:0 -20px -20px;
}
div.span-10,
div.span-6 {
float: none;
width: auto;
margin-right:0px;
}
}
/* ipad / tablets */
@media only screen
and (min-device-width: 768px)
and (max-device-width: 1024px) {
body {
font-size:1.3em;
}
#wrapper {
width:1024px;
padding:20px 20px 0;
}
.dsq-comment-text {
font-size:1.8em;
line-height:1.5;
}
}
/* ipod/iphone3 */
/* Smartphones (portrait and landscape) ———– */
@media only screen
and (max-device-width : 480px) {
/* Styles */
body {
font-size:1.3em;
}
#wrapper {
padding:10px 10px 0;
}
#logo-floater h1 {
font-size:1.5em;
}
#page h1 {
font-size:1.3em;
}
#page h2 {
font-size:1.2em;
}
#page h3 {
font-size:1.1em;
}
}

Lightweight UI Plugins for jQuery

One of my newest and persistent obsessions is constantly looking for ways to make dcunited.com load faster.  It’s a challenge because we want to have a content-rich site, with lots of photos, videos, and interactive elements.  There are a lot of techniques you can try, from optimizing images, using subdomains to trick browsers into downloading in parallel, combining images into sprites, and so on.  Of course, none of these techniques can help you if you choose or are forced to use something that has a big payload.

In this case, I was looking at the javascript libraries we use to do tabs, table sorting, and fancy tooltips.  jQuery itself is 31kb minified, which is a little chunky but not a horrible tradeoff.  Most plugins are svelt, except qTip which weighs in at comparatively hefty YUI-compressed 38kb.  For 38kb you get a ton of features with the plugin, but if you aren’t using most of them, its just bloat.

I need a compact UI library for websites

I started looking for a replacement plugin, and quickly found jQuery TOOLS, which states :

Websites are not desktop applications. They are different. What you really need is high usability, striking visual effects and all those “web 2.0” goodies that you have seen on your favourite websites.

Replacing qTip with the jQuery TOOLS tooltip plugin didn’t take a lot of time, by mid-morning I was already testing it across our supported browsers to roll it out to the live site. You can still get pretty fancy with this plugin.  However, you can customize your download to only include the tooltip plugin, which clocks in at just over 3kb minified javascript.  

This is a big difference, although 35kB may not sound like much, that’s 35kb less data that visitors have to download. More importantly, that is less javascript code that a browser has to parse when rendering a page. Javascript parsing can block other downloads and slow page loading.

CSS3 and HTML5 show a lot of promise

Wondering what's new in CSS3 and HTML5 that is bound to make your life easier, and maybe make you really ditch support for IE6 and maybe IE7?  Read this article from Smashing Magazine for an excellent overview.  It's hard to keep up with the changes that are becoming available in modern browsers and this article summarizes them all and provides links to learn more about each one.

Instead, we’re focusing on the specific techniques that you need to know to create modern CSS-based web pages of any style. For each technique or tool, we’ll indicate which of the five characteristics it helps meet. To keep this shorter than an encyclopedia, we’ll also just cover the basics of each technique, then point you to some useful, hand-picked resources to learn the full details.

Modern CSS Layouts, Part 2: The Essential Techniques – Smashing Magazine

Drupal – Designers vs Developers, can’t we get along?

There’s a lot of good insight in this blog post from the creator of the Views module for Drupal. I’m a big fan of the module, and when I’ve had to dive into the code behind it, I’ve come away pretty impressed. That’s pretty rare for a Drupal module, IMNSHO. Also, if you don’t understand or like the CSS classes and id’s that the Views module uses in its markup, I’m afraid you don’t have a good grasp on the “Cascading” part of CSS or how to use selectors effectively, if at all.

Before reading this, I’d never thought to frame how designers vs developers work in terms of the re-usability, perceived or real. Of course, that clarifies a lot for me, like why Designers love to design in Drupal, the latest site is a standalone piece of art, of course! Or, changing interactions from one site to the next, because each site is a “blank” slate, only to be mystified why it takes so long to implement this version of, say, a Document Library, when you’ve done dozens sort-of-like-it before. An Observation About Designers Versus Developers | Angry Donuts

The converse, however, is not true. If a designer desires a particular piece of functionality, the services of a developer are required. Now, in the Drupal world, we have created a pretty good illusion that you may not need the developer. Drupal, particularly with Views and CCK, allows you to utilize surprisingly complex bits of functionality without needing a developer. But this is only an illusion that you don’t need a developer. The truth is, that you only don’t need a developer as long sa the functionality that these packages provides you happens to be the functionality that your end goal requires. When these things are in sync, this is great. And Views and CCK can do a lot out of the box, so it’s pretty easy to get to 90%, but sometimes that last 10% can be daunting.

Now you have a website to run!

Going from a consultant on the outside to a developer on the inside, I can’t agree more that there’s a lot more work to do once you launch a site.  Since we relaunched our website at work in March, there have been a number of things we’ve had to change based because of how users actually use the site despite the assumptions we made during development. 
CMS Post-Launch Lessons for Improving Your Website – The CMS Myth

But avoid going on autopilot. While it’s great to catch your breath, don’t overlook the fact you now have a real, live website to monitor and measure activity and results. Many website projects are an exercise in educated guesses, leavened with research, interviews, insight and best practices. When your CMS-driven site goes live, assumptions and decisions go under the microscope.