Addressing Flash Websites in the iPad generation

Flash – it’s like a legacy application on the Web these days.

There are millions of Web users out there with iPads, iPhones, iPod Touches, et al, all of whom cannot access Flash websites (me included) when using these devices. Yet there are still web development companies producing exclusively Flash content for websites which stops this very large and growing user base from the services offered by the website (for example restaurants, clubs, car showrooms, etc, etc).

The issue isn’t going to go away – more mobile users are coming online every day with no mechanism to view Flash websites. While it is true that older websites are very unlikely to ever be updated (some companies just don’t like spending money on the Web, which is another debate for another day), websites built today need to offer alternative, accessible content – even if it is just a map and contact details (these are the most commonly looked for items by mobile users, after all). There are even laws about it!

To remedy this, I thought I would share some quick code I put in place for a client recently who had an exclusively 100% Flash website (which we didn’t build by the way) and needed a “quick fix” when their owner got an iPhone and suddenly couldn’t see his website Flash was important to this client, so the flow of the code detects if Flash is available and shows that content by default, otherwise it flips over to the static HTML for people without Flash – which includes the ubiquitous iPhone.

My solution was to take the published Abode Flash Detection Kit and modify it slightly to avoid breaking the existing Flash Application which was wrapped with SWFaddress (which provides deep linking capabilities for Flash & AJAX, so making each “page” in the Flash a separate URL and also better enabling SEO).

If you’re not familiar with Adobe’s Flash Detection Kit (or many similar alternatives), the code relies on JavaScript to detect if Flash is installed and then either displays the Flash content or alternative HTML content. The Adobe kit does this in-line by calling further JavaScript to either build the Flash object (a good mechanism which avoids other browser issues, notably for IE), or display the HTML content.

Here are the steps I took to wrap the existing Flash website with the detection system to prevent breaking the existing application:

1. Created a new home page containing some static content (in this case, a small HTML website was produced and the home page was an introduction with contact details). This was named “index.php” (LAMP server) and uploaded next to the original index.html homepage which wrapped the Flash.
2. Included the Adobe Flash Detection Kit and wrapped it with some logic (used by step 5 below):

   <?php
     $noflash = ( isset( $_GET['noflash'] ) ) ? $_GET['noflash'] : 0 ;
     if ( $noflash <> 1 )
     {
   ?>
   <script src="/flash-detect/AC_OETags.js" language="javascript"></script>
   <script src="/flash-detect/detection.js" language="javascript"></script>
   <?php
     }
   ?>
   

3. Modified the detection.js code to provide a simple switch for Flash. This meant that if Flash was detected it simply redirected the browser to the Flash application wrapped in the existing index.html file:

   // -----------------------------------
   // Globals
   // Major version of Flash required
   var requiredMajorVersion = 8;
   // Minor version of Flash required
   var requiredMinorVersion = 0;
   // Minor version of Flash required
   var requiredRevision = 0;
   //-----------------------------------
   
   // Version check based upon the values entered above in "Globals"
   var hasReqestedVersion = DetectFlashVer(requiredMajorVersion, requiredMinorVersion, requiredRevision);
   
   // Check to see if the version meets the requirements for playback
   if (hasReqestedVersion) {
       // if we've detected an acceptable version
       // embed the Flash Content SWF when all tests are passed
       location.href = 'index.html' ;
   }

4. Added a line to the .htaccess file which redefined the home page of the website to look for index.php first:

   DirectoryIndex index.php index.html index.htm default.htm index.php3 index.phtml mwindex.phtml

5. I also modified the index.html file to make the Flash an embedded object (making it a proper layer instead of floating to the top which happens with OBJECT tags; thank you PS3 website!), and added a layer allowing visitors to click through to the HTML if preferred (the noflash=1 flag ensures that when the index.php home page is called from the HTML that it doesn’t run the Flash detection and flip the visitor back to the Flash content!):

   <body>
     <div id="flash_content">
       <embed id="mainFlashObj" width="100%" height="100%" wmode="transparent" quality="high" bgcolor="#000000" name="mainFlashObj" src="website.swf" type="application/x-shockwave-flash"></embed>
     </div>
     <div id='footer'>
       <a href="/index.php?noflash=1">Non-Flash Version of the Website</a>
     </div>
   </body>

6. Added some CSS to position the ‘footer’ layer over the Flash (since the Flash was set to 100% of the viewport):

   #footer {
       text-align: center;
       top: 0px;
       z-index: 10;
       position: absolute;
       padding: 5px 0 0 0;
       overflow: hidden;
       width: 100%;
       height: 25px;
   }

One benefit of this approach is also to make the static HTML content immediately visible to search engines. By changing the default home page of the website via the .htaccess file, we point search engines to this new content. Also, since search engines fail the Flash detection test, they are not redirected to the Flash content and only get the static HTML. A link is provided within the HTML site to the Flash content so that the content is still accessible by visitors and search engines alike.

The end result is a seamless experience which, while prioritising Flash (at the client’s request), presents a complete website without the need to introduce a splash page asking the user to choose Flash or HTML, which is a lazy choice in my book and not a good user experience.

I hope you find this approach useful to wrapping Flash sites with alternative content.

Related Reading from this Blog

1. AJAX versus Flash
2. Flash Flaw could lead to Phishing Flood
3. Architecting Great Websites, Graphic Design
4. Architecting Great Websites, Introduction
5. The iPad, Office and the Cloud (A Plea)