Category Archives: ajax

Flash on the Beach, Miami (CANCELED)

Posted on by

UPDATE: The Miami conference has been canceled due to lack of attendees. This is very sad news, but in an economy like this it’s not really surprising. Guess we’ll just have to wait for September for our dose of Flash on the Beach.

If you are still looking for a Flash/Design conference to attend this summer, I highly recommend Flashbelt.

The best European Flash conference is heading to the states this spring. Flash on the Beach has been happening in Brighton, UK for the last few years and is such a good time, I think everyone should go.

I’ll be heading down to Miami this year to talk about YouTube type things, so if you are curious about using YouTube for a project, or just interested in hearing some stories about a very high performance Flash application, you should come to my session :).

Flash on the Beach Miami

In case you are interested, there’s tons of pictures and writing about past FotB events all over the place. So check it out, and hopefully I’ll see you there.

SWFObject now available on Google AJAX Libraries API

Posted on by

I’m happy to announce that SWFObject (version 2 of course) is available from the Google AJAX Libraries API.

What does this mean to you, the average user of SWFObject? It means you no longer need to place a copy of the SWFObject script on your own web server, and can instead link to the copy hosted on Google’s servers.

If you are unfamiliar with the AJAX Library API, you can find more information on the Google code site, or continue reading below for some simple examples to get you up and running quickly. SWFObject may not be in the docs on the AJAX Libraries API site yet because it was just added recently, but the team is working on the updated docs now, so check back later if you don’t see the SWFObject specific information.

Now for the business: I imagine that most SWFObject users most likely only use SWFObject and none of the other libraries hosted on the AJAX Libraries site. So here’s a direct link to SWFObject v2.1 that you can simply place on your site, and that’s it:

http://ajax.googleapis.com/ajax/libs/swfobject/2.1/swfobject.js

Yep, that’s it. Just replace the path to your local copy of swfobject.js with this one and you are done.

Another option is to use the google.load call which is documented here.

Speaking at the Ajax Experience

Posted on by

I just found out the other day that the Ajax Experience has invited me to come talk about Flash to a bunch of Ajax nerds this July. This should be a really fun one (no, really!). My talk will be on how to use Flash *with* that fancy Ajax app you are building, so enhance it and give it that little extra kick. Think of it as an introduction to using Flash happily with Ajax techniques.

It’s got a fantastic lineup if you are into the whole Ajax thing, so I definitely suggest checking it out.

Check out my session outline for more info.

Also: Flashbelt is only 2 weeks away! It’s JUNE already. Time to hit the upper midwest and talk Flash with all the cool Flash nerds again. If you haven’t looked at Flashbelt and are itching for a conference, this will be a nice one to check out.

UPDATE: Apparently, there’s only 50 tickets left for Flashbelt, so get your tickets now if you are planning on going!

Flash vs. Ajax

Posted on by

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.