carousel pt2
In last week's article on carousels I coined a basic definition and illustrated how this definition can influence the html that comes forth from it. I purposely left out one layer of complexity though, as I believe it deserves a separate entry. So this week let's talk graceful degradation for complex functional components. As it turns out the carousel serves as a perfect example for taking a closer look at the boundaries between html and javascript.
I guess most of you will be familiar with the concept of graceful degradation, for those of you who still feel a small shiver running down your spine here's a very concise recap. The goal of graceful degradation is to provide visitors with older software (browsers) or with specific functionalities disabled (like scripting) with the same information regular visitors get. Maybe not as easy to access or as simple in use, but the information should be there and accessible to all.
A carousel shows by default only one (or a limited selection) of its items, so that becomes a problem when javascript (assuming we're not talking Flash carousels here) is disabled. The question is, how should we best provide all the information in the carousel to users who don't have the needed scripting power. There are quite a few option here, so let's run through them trying to find the best one.
back-end solution
If you want to make it easy on yourself you can dump all the hard work on the back-end developers. This solution requires you to do very little as the design of the carousel will remain exactly the same. The only thing that needs to be done is to provide urls to the current page with different query parameter values. Those parameters will determine which item should be shown. Advancing to the next item involves a page refresh but at least this way all the information is still available (for those who care). Do mind that things become a bit more complex when more than one carousel (or similar component) resides on a single page.
The urls will be replaced by onclick events in the javascript version so regular visitors won't notice anything. Another small pro is that you can actually link to a specific item in a carousel now. Still, this method is just not as fancy as it could be, so let's leave this option behind and keep it for those moments when time is of the essence.
front-end solutions
If you want a front-end solution know that there will be some additional design work. Instead of showing only one item you'll need to show multiple items, which is usually not possible in a regular carousel design. This doesn't mean the extra design should be anything fancy (remember you're just catering for a very small percentage of your visitors) but it should still be clean and usable.
The main html-related question here is what to do with the navigation part of the carousel. Since all the items are on one single page the navigation becomes somewhat obsolete, though there are situations where it can be made useful again.
option 1: no navigation
Depending on how much 'extra' content will be shown, you could remove the navigation altogether. It's best to do this back-end wise and to keep the html out the page source. As the navigation is not needed, it simply shouldn't be there. Alternatively (if you're fed up with bugging the back-end guys with your tricky demands), you could hide the navigation using some css trickery.
This is a pretty valid option as long as the carousel data doesn't push all the other content several pages down. If that's the case, the navigation items will become useful again.
option 2: keep the navigation present in the html
If the carousel content becomes too prominent it's good to keep the navigation links present and to make them function like anchor links. The next/prev links can still be removed, but the direct links are handy aids for jumping to the wanted item immediately. It's even possible to add a little skip link that jumps across the whole carousel section, but that's probably taking it a bit too far.
This solution doesn't require too much work except for providing a non-javascript design and writing the css for both versions. The anchor links aren't really our responsibility and should be handled on back-end level. Just make sure each focus block has an unique identifier so they can be targeted by the anchor links.
option 3: keep the navigation present with javascript
One last option is to build the navigation links using javascript. As this section is only really mandatory when javascript is enabled it's fair to let javascript handle this part of the carousel. This is where the boundary between javascript and html becomes a little flaky though, as it's not all that obvious how the html code should be built. Below are several options:
- Place a rough outline of the html code in the html source.
- Place a rough outline of the html code in the javascript.
- Build the code from scratch in javascript.
Whatever method you pick, the actual code to build the navigation section is a little tricky. First of all you probably need a special link label for the carousel navigation. This is not necessarily the same as the title of the content item, so it's best to include this label in each carousel item and hide it from view (using the html5 data- property would be a nice option here). On top of that, the items inside a carousel are prone to change so it's best to build the list items dynamically.
That's what the rough outline is for. You don't need to include the full html code (all links with labels), just one link which can be cloned as many times as there are carousel items. Extra classes like first/last/active could be added by javascript when building the navigation links. Mind that all of this takes some time, so depending on when the javascript is executed it might take a little while for the navigation to appear.
This final option might be a little over the top, even introducing some ambiguities on where to find and adapt html code, but from a theoretical point of view it's probably the cleanest option available.
conclusion
It could be that I've missed one or more possibilities here, if you have any suggestions do leave a comment in the comment section. I'm still not entirely sure what option I prefer myself. I like the theoretical slickness of option 3, but the implementation itself is somewhat fuzzy and dirty. Hiding away html code in the javascript will almost definitely result in problems later on and might even show some performance issues. From that point of view, option 2 is probably the most stable way to go. The navigation is in the html, if not needed you can still hide it with css (even from screen readers) and everyone will know where to look when the code needs to be adapted.
Like always, I hope these articles say just as much about methodology as they say about the actual techniques. I hope this article illustrates the varied range of graceful degradation techniques and how to approach them. There is still a huge need for defined best practices in our line of work, sadly these topics remain less sexy than the newest css3 fad (which probably only works on Chrome anyway).