Flash vs. Ajax

I’ve been hearing a lot of Flash vs. Ajax arguments lately, and unfortunately, they almost always start off in the wrong way.

It’s very common to hear people argue about Flash websites or RIAs vs. Ajax websites or RIAs, but this is always the wrong way to approach building any website. Would you have an argument with an architect about whether to build a house out of wood vs concrete? Of course not, they would use each material to build the parts of the house that the respective material is best for. Sometimes you might want to build a shack or barn out of all wood, sometimes you might want to build an all brick house, but many times you’ll want to use the best material for each section of the house. Build the foundation out of concrete, the walls and roof out of wood.

Websites and web applications should be treated the same way. Break things down to a component level and go from there. Use the right tool for each component. If you can do it well with HTML/Javascript, go for it. If it would work out better with Flash, then why waste time recreating something with Javascript that you could build 3 times faster with Flash? There are plenty of great examples of this today around the internet:

One of my favorite examples is Google Finance. They use HTML and Javascript for the stuff that is best suited for that, and then when they need to show a nice graph, they drop in a great interactive Flash graph and talk to it using Javascript as needed. The Flash controls the Javascript, and the Javascript can control the Flash as needed.

Another example is Flickr. They started out using Flash to display all of the images, including the image notes and the other toolbar options along with each image. While this might have been a good choice as the site started out, it was soon replaced by a more efficient HTML version of the toolbar and notes system that works just as well as the Flash version. They did end up keeping one small bit of Flash so users can rotate images and see a preview before they save it.

So the next time you start planning a website and you start thinking: “Hmm, Flash or Ajax?” Instead of looking at it from a site-wide perspective, try thinking about your site as a series of components, and then choose Flash or HTML/Javascript for each individual component instead.

Internet Explorer Eolas changes and the Flash plugin

Microsoft recently announced (again) that they will be changing the way Internet Explorer handles plugins (more info here).

So how does all of this affect you being a web developer?

Basically, the functionality changes work like this:

When using an applet, object, or embed tag to insert a plugin into an HTML document, that plugin will not allow user interaction until the user clicks on it. Microsoft calls this process “Activating an ActiveX Control’s Interface.

In the case of the Flash plugin, it means that your Flash movies will not work until a user ‘activates’ it first by clicking on it. The details are still a bit fuzzy, and I can’t find a developer preview of IE 6 or IE 7 that include this new functionality to test this new functionality (If you find one, please let me know) (see below). This is a slight improvement over the previous ‘fix’ which was a small dialog prompt for each ActiveX control on a page. Now you just have to click on each control to activate it (if you want to interact with it).

Microsoft says “We believe over the next six months, most customers will be running copies of Internet Explorer with this behavior.” The changes will be rolled into IE 6 through security updates to Windows, and included in IE 7.

But that’s so stupid! How do I fix it?

Thankfully, Micosoft offers a fairly easy way around all this nonsense: Embed your Flash movies using Javascript. Head over to the FlashObject page* and start using it (you should be using it anyway, everyone else is!). You may also want to retrofit your old websites that don’t use Javascript since this change will affect every website. If you are using quicktime, you can always use my QTObject script which works the same way that FlashObject does, but for the Quicktime plugin.

UPDATE (1-22-2006): Apple has recently released a new script that is similar to my QTObject script to prepare people for the upcoming IE changes.

* UPDATE (2-21-2006): After testing with a patch (search the page for ‘English’ to find the download link) that Microsoft released recently released (and with some help from Dan Freeman) it turns out that you must have ‘Disable Script Debugging’ checked in the Advanced options of IE in order for the controls to be activated as they are embedded. If you have Script debugging on (it’s off by default) then you will still need to activate each ActiveX control on the page.

Also: Macromeida/Adobe has a new Active Content Developer Center.

UPDATE (3-1-2006): Microsoft has released the update. There’s more information and a nice list of possible issues you might have after installing the update on this Microsoft KB article page.

UPDATE (3-24-2006): Looks like Microsoft is set to roll out the Eolas changes to everyone around April 11th. Get ready.

UPDATE (3-29-2006) Microsoft announced their future plans for releasing the patch to customers today.

UPDATE (5-9-2006): Adobe posted what looks like a very rare edge case regarding an out of date jscript.dll causing users to always activate ActiveX controls, even if they are embedded using Javascript in the proper way.

Flash Player 8 is out of beta

Macromedia finished up Flash 8 this week and released it to their Devnet subscribers. With that happening, it was also time to push the player out of beta as well. As of today you can upgrade Flash Player 8 and not have any of those beta worries.

Check out my Express Install page to see what it’s like to upgrade without having to visit Macromedia’s site. One thing I thought was odd is that Macromedia’s own download page doesn’t give you the option of using Express Install, and instead they only give you a link to download the OS X installer. If you are using Internet Explorer, they have always sent you to d page with a Flash movie embedded so it would trigger the ActiveX install, instead of forcing people to download the executable installer for Windows. Seems like an odd move to me.

I also have some issues with the final wording on the Express Install mechanism. When you start the upgrade, the dialog warns you that “This content requires Flash Player 8” when in fact you may already be using Flash Player 8 and simply need to upgrade from 8.0.15 (a beta version) to 8.0.22 (the ‘final’ version). Can you imagine trying to explain to a client why their website tells them they need Flash Player 8 when they already have another version of it installed, and then not being able to change the text because Macromedia controlls it?

There may also be the few occasions when you would want to build a Flash 7 site, and use the Express Installer to upgrade users from version 6.0.65 to 7. The upgrade message would still inform them that they need ‘Flash Player 8’ when they really only need version 7. This situation is much less common I’m sure, but once Flash Player 9 is released, they will need to change the wording to something more generic anyway because people will still be using it to upgrade users from version 7 to version 8.

How accessible is your Flash embed?

There’s an interesting article over on the Macromedia Accessibility blog. They take a look at some popular Flash embed techniques and see how they perform in screen readers. The thing that caught my eye, though, was the performance of the Flash Satay embed method. It looks like if you are using Flash Satay, JAWS won’t read your Flash content.

Unfortunately, they didn’t test FlashObject, but they did test UFO – which works in a very similar way – so I think it’s pretty safe to say that they would behave the same way in a screen reader.