Monday, May 9th, 2005

Ajax Summit: Eric Costello of Flickr Presentation, a.k.a. “Stewart is a fussie little guy”

Category: Ajax

Eric Costello is a UI guru at Flickr, who groks Flash as well as this Ajax stuff ;)

Flickr is getting rid of Flash and is actually moving towards Ajax.

He starts out by showing issues when you dynamically change the DOM, and having the browser moving things around, forcing the user to have to scroll around. Shouldn’t the browser be smart about dynamic changes?

He also talks about changing the DOM, changing the server, and the browser not being smart enough to know about this. If you FORWARD / BACK, it loads the version that it put in the cache when the page loaded. Surely it should cache the last version of the DOM?

Eric shows editing a note on top of a photo, which currently uses Flash. He wants to see a nice way to do this, with in place layers that you can edit inline. He is doing a great job at showing things that annoy him :)

“Ajax is too fast, and too easy, which breaks what they are used too on the web”

David HH of Rails/Signals37 fame jumps in and gives us his thoughts (e.g. fading techniques). A discussion got started which talked about how users have different expectations on the web, versus desktop applications, and an interesting group of theories came out.

Why Flash?

Flickr was built on the “Game Neverending” engine, which was Eric’s first time using Flash. Flickr was launched as real-time photo-sharing, which let you chat with people and drag and drop photos to each other, and grew from that.

Since the core tech was Flash, and there was a lot of libraries that they had, it was a natural fit. All of the cross browser problems were gone too.

Some of the problems, are that some pages are lagged, and you can’t right-click and ‘Save’ the image down.

Why move to Ajax from Flash?

The demo shows that the page loads quicker, and they have gone a great job with porting over the functionality that you may not even think you could do with this stuff.

Eric also showed really interested new functionality that lets you do a hell of a lot in the photo view, without having to go to other pages.

Getting around the browser cache problem

When change anything on a Flickr page with Ajax, it sets a cookie, and the cookie is set to a timestamp that is inserted into the JS when the page loads. Whenever the page is reloaded (e.g. from cache), and if the cookie value is the same, then a change has happened, and I callback to get the new information.

So in the new Flickr, you can BACK and FORWARD all day, and the original title doesn’t come back to haunt you. Nice hack Eric!

Waiting until onLoad()

Eric talks about how he has found putting code in onLoad() is too late. You can be waiting until images are loaded etc. So, he uses a pattern of putting <script> after elements that he needs to work with.

Posted by Dion Almaer at 1:56 pm

3.4 rating from 7 votes


Comments feed

Flickr getting rid of flash – excellent news.

Comment by IM — May 10, 2005

There has been a javascript version of the photo “notes”, ala flickr, developed in the not too distant past. As it is, the link escapes me at this early hour.

Flickr does lag, but I wasn’t aware if that was due to Flash. If it is, then I would imagine getting rid of it would be a good option. I thought they did champion Flash for the right click save image as protection. Flash offered a layer of security that the usual user wouldn’t know how to work around in order to get the image.

Just ran across this blog today and love it!

Comment by lincoln — May 10, 2005

The Lickr user script for Greasemonkey ( ) definitely shows that much of the Flash experience can be done in Javascript.

I’d expect the cookie hack to break when you use multiple tabs.

Comment by Julien Couvreur — May 10, 2005

I’m curious exactly what it is that “lags”… if it’s a single-photo SWF then you can’t take advantage of its built-in streaming, but it should still be just as fast to transfer, just as fast to initialize… what is it, specifically, that’s said to “lag” here…?

tx, jd/mm

Comment by John Dowdell — May 10, 2005

‘The demo shows that the page loads quicker’ – Can we see the demo?

Comment by felix — May 10, 2005


Easy, it’s that Flash doesn’t load in the background, something very noticeable in this tabbed-browser age. It’s common now in Safari or Firefox to open up a bunch of links as tabs and let them load while you read content or what have you in the current view. Problem is that Flash doesn’t start loading images until the Actionscript fires programmatically, which isn’t until you actual cycle through to that tab or window. So what you get when cruising Flickr, for example, is that you batch open a bunch of images (say you want to flip through someone’s recent photos to see if you like their style) but have to wait a few seconds (at least) on each tab to view the actual photo.

This is unnecessary, annoying and nonexistent with other non-Flash image loading techniques. I’m sure the finger could be pointed ultimately at the browser makers, but none of that would be productive for the developer in the trenches now. And don’t get me wrong, I’m a big fan of lightweight Actionscript-heavy Flash apps (I make them for a living) but there doesn’t seem to be currently any way within Flash around this drawback.

Comment by Al Abut — May 11, 2005

“it’s that Flash doesn’t load in the background, something very noticeable in this tabbed-browser age”

Are you saying that some of the current tabbed browsers defer loading plugin content until that tab receives focus? (I’ve seen some that have deferred, and some that have loaded all background-tab content simultaneously, but I haven’t catalogued browser behaviors here.)

But either way, that seems a different issue than “lags” as originally presented? (And it seems something which may addressed in implementation, rather than in capability… different previewing options, eg.)

Is that what the original speaker was talking about with “lags”, or something else…?

tx, jd/mm

Comment by John Dowdell — May 11, 2005

Hi. I wrote Lickr, so I’ve studied Flickr quite a bit.

Al Abut wrote: “Easy, it’s that Flash doesn’t load in the background, something very noticeable in this tabbed-browser age.”

I’ve never heard of this before. It certainly is not happening in my browser (Firefox 1.0.3).

Flickr’s Flash use slows down the page because things take a rather circuitous route:

– you request a page.
– PHP templates write custom javascript for the page.
– the javascript executes in your browser and generates HTML for the embedded Flash
– the Flash URL has different query parameters every time, so your browser cannot cache it
– the Flash is just very small stub which then proceeds to REALLY download the photo you wanted, with a slightly different interface depending on those parameters.

On the contrary, the delay is more noticeable when you’re browsing in a single window. In a tab, that small delay is irrelevant.

Comment by Neil K — May 11, 2005

By the way, that wasn’t a slam at Flickr. Their Flash solution gave them a cross-platform, quite fancy Flash interface, at a low cost to developers and little inconvenience for most users. It still wins raves for usability. DHTML is a harder path to follow, but it’s got other advantages, particularly in scalability.

Eric Costello actually emailed me a while ago to let me know this was coming. It was a very nice gesture, especially to an outsider who’s technically “hacking” their pages. Other companies wouldn’t even dream of doing that.

Comment by Neil K — May 11, 2005

If “Flash doesn’t load in the background,” then I take it you are a Safari user. Talk to Apple about. It’s the same for other data handled by plugins, including movies and music.

Comment by Grant Barrett — May 11, 2005

>Flickr is getting rid of Flash and is actually moving towards Ajax.Just to be clear, we are not actually getting rid of Flash, not at all! And we have been using Ajax on the site since before it was called “Ajax”. But on Flickr photo pages we will no longer be displaying photos in a Flash wrapper. There are still many Flash mini-apps on the site that we have no intention of getting rid of. In fact, on photo pages, we will still be using a Flash movie to preview rotation of a photo.

And a minor correction: the bit of Flash that does not get cached on the current photo pages is actually a tiny little SWF (455 bytes) that loads a much larger (cached) movie that contains all the code, and the (cached) jpg itself. The delays when loading photos pages with Flash have more to do with the overheard of the browser running a plugin, and the fact that the swf actually makes API calls to grab note data every time you load the pages. Both of these delays will be go away with the new version.

And Lickr rocks :)

Comment by Eric Costelllo — May 11, 2005

Crap, there should have been a break after “>Flickr is getting rid of Flash and is actually moving towards Ajax” in the above post.

Comment by Eric Costelllo — May 11, 2005

“Are you saying that some of the current tabbed browsers defer loading plugin content until that tab receives focus?”

Yup and after further testing, it’s definitely only Safari that does this. Maybe Firefox used to and Flickr fixed it? Probably my own fault memory.

Regardless, I’m glad it’ll go away for the Flickr folks after some Ajaxification and glad to see they understand how lightweight Flash can be in building smart interfaces (it blows my mind that we’re still stuck with urban legends about how Flash is always bloated), but unfortunately this won’t solve this aspect of Flash while surfing other sites or building my own projects. And switching to Firefox isn’t a good answer, not for me and my moderately-powered iBook – it’s just too slow.

Comment by Al Abut — May 11, 2005

Another point. Flickr was essentially broken on Linux. It was impossible to use it on FireFox/Mozilla because the CPU time was horrible. It would take minutes to load pages!

Personally its not as much of an issue because I’m not on a mac.. but I’m sure you have plenty of other Linux people out there who can’t use Flickr…..

Comment by Kevin Burton — May 11, 2005

Leave a comment

You must be logged in to post a comment.