CMS editable Flash

With all the fuss over AJAX and Flash accessibility you get, I thought it might be worth outlining the process we use and highlight one of the advantages you get with it. (Hint, it’s in the title.) It also means that the use of Flash has no impact on your Search Engine Optimisation.

Oh, and although I’m writing this article, much of the implementation (and Flash expertise) is from my colleague and co-author Tom Hooper. Any Flash questions will be directed his way!

Intro

Recently we re-launched our CMS’s site, defacto-cms.com, and with it a flashy (in both senses) case study selector. If this were a clients site it probably wouldn’t be worth the time for this purpose, but now the framework is in place it will be easy to replicate.

The ‘carousel’ navigation widget is only used in the case-studies section at the moment, and it is essentially local navigation for that section. You select a case study, it spins into the center, and if you select it the content below is replaced by that case study’s information. The visual effect is not 100 miles away from the iTunes ‘coverflow’ effect, although there are some subtle differences. It uses the Papervision3D open source ActionScript 3 engine for the 3D effect, plus a fair bit of scripting!

NB: Don’t use this in Safari yet! There’s a crash-bug we’ve discovered in Safari affecting the AJAX. You can load and play, but don’t select a case study with the Flash.

It is worth noting that we needed to use quite a recent version of Flash to get that effect (V9.0.28+).

What’s different?

I don’t think there is much new in terms of techniques, although I haven’t seen people use the content of a page as source for the Flash in this way before. It has also had quite a lot of attention in terms of bullet proofing and making accessible.

The foundation

The foundation is straight XHTML 1.0, and on a basic browser you get a list of links with images.

The HTML needed to run it is a container div, its content (used in the Flash), and an object which is used to configure the Flash element on the page. This is a very generic method that we will be using for any Flash content, but as an example, for carousel that skeleton is:

<div class="flash-object" id="landing-proposition-inner">
<h2>Websites powered by Defacto include...</h2>
<ul>
 <li><a href="page1.html">
<img alt="Organisation website screenshot" src="shot1.gif" />Organisation Name</a>
</li>
<!-- more items -->
</ul>
<object>
	<param value="/defacto/live/swf/carousel.swf" name="swfLocation" />
	<param value="200" name="height" />
	<param value="#0E3E80" name="bgColour" />
	<param value="url" name="sendMode" />
	<param value="9" name="reqMajorVer" />
	<param value="0" name="reqMinorVer" />
	<param value="28" name="reqRevision" />
</object>
</div>

What the scripts do

A JavaScript script is used to embed the actual Flash into the page, in broad strokes, the page loads and the script then:

1. Runs, if you have a fairly recent browser (we used jQuery, so it matches Yahoo!’s graded browser support table fairly closely).
2. Checks the version of Flash that you have, and either:
   • Replaces the content of the container div with the Flash, or
   • Adds a small “Would you like to upgrade your Flash” link.
3. If the Flash is added, the current URL and container ID is passed to the Flash.

The Flash then loads, then displays the carousel using the images and links from the URL and ID it was sent. When a case study is selected, the Flash calls a JavaScript function to replace the content of the page (using AJAX).

Reasoning

If I were you, there would be several questions going through my mind:

Question: Why use AJAX?
It prevents you having to re-load the Flash each time you view a case study. Even cached, it’s doesn’t load instantly, and this way you don’t have to sit through the initial animation again and again

Question: Flash has to load the page itself to get the content, why not pass the content from the JavaScript to Flash?
We tried that, but it seemed very CPU intensive, and given that the nature of the widget is already CPU intensive, we steered away from that. Although it may mean loading the thumbnails twice, they should be cached for the second load. In our initial testing, the caching/loading differed between browsers:

• Firefox loaded the page fully before the Flash, which is strange, so Flash gets the cached images.
• IE seems to load the Flash and page simultaneously, so the first request for the images is usually from Flash.

Technically as the images are removed from the page when the DOM is ready, they shouldn’t all load, but I can’t confirm this yet.

Question: Why not do the Flash version detection in the Flash?
In the case of Flash not being installed, you either get a warning from the browser, or a broken plugin display. There is also a problem with signposting users what to do next, as you end up with dodgy inaccessible buttons or messages in Flash. Since the AJAX interaction requires JavaScript anyway, we decided to use JavaScript detection to deliver a much smoother user experience.

Progressive layering / enhancement

The easiest way to describe the layering is to describe the progressive enhancement, i.e. what you get with what capabilities the browser has:

Basic browser (no CSS or JavaScript)

An HTML list (ul) of standard links that work and image thumbnails.

Standard browser without JavaScript support

An HTML list of links that work. (Images are hidden with CSS, as they are too big when you have the layout in place.)

Standard browser with JavaScript, but without the required version of Flash

An HTML list of links, and a little link at the bottom of the area suggesting you update Flash.

Standard browser with JavaScript and required Flash version

The Flash carousel version, using AJAX to load the content.

In the first version the “has JavaScript but not Flash” condition used AJAX to load the content, which seemed like a more even step. However, the accessibility and browser support issues mean that the weak point is really scripting (AJAX), not Flash.

Benefits

There are several advantages to this whole method that appealed to us:

• The method scales up. The first time we tested this was for a micro-site that replaced the whole site with Flash.
• Search Engine Optimisation (SEO). Since your content is well structured XHTML, Google doesn’t even know you’re using Flash.
• The presentation in Flash can be very different from HTML, even with the same source content. (Caveat: the more Flash elements you layer on top of the source content, the less flexible the content becomes.)
• Flash can call JavaScript functions to interact with other parts of the page, so you can still use (X)HTML when it is best suited to the content.
• You can have multiple Flash instances on the same page, each with it’s own variables.
• It is easy to turn on/off, bulletproofing the accessibility.
• No duplication of content, you don’t have to update two things.
• You can edit the content within any XHTML capable CMS.

I’ll repeat that for those at the back: You can edit the content in a CMS, not one coded specifically for editing Flash or custom XML files.

Obviously, you can’t add or change functionality, but in this case you can add case studies (links and their thumbnails), and in other cases you could change the content of pages (i.e. text and images).

Accessibility issues

We are tripping several alarm bells in terms of accessibility by using Flash and AJAX, but actually it wasn’t that hard.

The pages work fine without JavaScipt. The AJAX loads on a keypress of enter, so screen readers will generally update the virtual buffer. There could be a problem if the content takes a little while to load, but adding Juicy studio’s update buffer function should resolve that.

For the the Flash you just have to put in the work (and knowledge and testing) to ensure that it works with both visual keyboard access and with screen readers. You also have to work out what should be shown to screen readers in what order for it to make sense. We did find a bizarre bug in JAWs (8.0 original version) where the whole pages content was repeated when it entered the Flash, but applying the later patches to JAWs fixed that.

User control

One of the basic assumptions we accepted is that people may not be able to, or want to, use this feature. Therefore we added a “Disable scripts” option at the top. This essentially turns off the advanced scripted features such as the flash, but leaves the cosmetic ones in place (e.g. adding rounded corners).

This is very useful for older screen readers, which may understand just enough JavaScript to get into trouble. At the moment, it’s also useful for Safari, as we’ve encountered quite a severe bug when it encounters the AJAX function.

Usability additions

Usurping the innate page model of the web comes at a cost, some of which we’ve worked around. If you just use the Flash, it’s fine, but if you switch between navigation methods it’s a little clunky as the Flash is not reloaded.

The aspects we did work around were primarily changing the page title when you load a new case study, and providing a mechanism to get back to the index page (in the breadcrumbs).

We also made the visual aspect somewhat more HTML-like, so that a case study has underlined text “View case study”, then when you select it that disappears. Adding this made the keyboard/screen reader aspects easier to deal with as well.

Improvements still to make

There are a few things we would still like to adjust, the first of which has to be the Safari bug we’ve tripped. It actually crashes Safari! Unless we can track it down, we might have to add an “if browser is Safari then don’t run” type rule. JavaScript debugging in Safari isn’t that easy, and yes messieurs Christian & PPK, you can say “I told you so”. However, it would have taken an awful lot longer than we had (1.5 days on JS) to complete it without a library.

Although we’ve restored the titles to individual (AJAX) pages, we haven’t re-enabled bookmarking of individual pages. Although search engines will have no trouble finding the pages, people will have difficulty bookmarking individual case studies.

I’m also not convinced that the double click aspect (i.e. one to move the case study to the center, a second to select it) is the way to go. Some people expect the first click to select a new page, some don’t.

Which did you expect?