Ajax and the Ken Burns Effect

An anonymous reader writes "IBM DeveloperWorks has an interesting project posted that shows how to design a client-side slide show using the 'Ken Burns Effect.' From the article: 'If the Web 2.0 revolution has one buzzword, it's Asynchronous JavaScript and XML (Ajax). [...] Here, you discover how to build XML data sources for Ajax, request XML data from the client, and then dynamically create and animate HTML elements with that XML.'"

Comments

This is detailed Ajax, Ken Burns style...

[crazyjeremy]

Ken Burns effect from wikipedia:

"In his documentaries, Burns often gives life to still photographs by slowly zooming-in on subjects of interest and panning from one subject to another. For example, in a photograph of a baseball team, he might slowly pan across the faces of the players and come to a rest on the player the narrator is discussing. ... This technique came to be known as the Ken Burns Effect, even though he did not originate the technique, and has become a staple of documentaries, slide shows, presentations, and even screen savers."

Ken Burns effect in Ajax: Use good ole DHTML and XML to whip stuff around on your screen. Or as the link says "I animate the images with random slow moves, zooms, and fades to give a pleasing version of the Ken Burns Effect without having to download Macromedia® Flash or any other heavyweight animation tools."

Re:This is detailed Ajax, Ken Burns style...

[lysergic.acid]

The point of the article isn't to entertain you with a slideshow. It's an intro guide/tutorial to AJAX for developers interested in the technique. Personally, I found the article to be very informative, and a good exercise for learning the basics of AJAX. Now I can go on and implement AJAX in the interface of my real web applications, which are much more complex and have a purpose other than to simply demonstrate how AJAX works.

It's kinda like when you first start programming you might begin with a simple "hello world" program. That doesn't mean C/Perl/whatever language you're learning is useless just because the hello world application was designed as a simple programming exercise.

So you can stop complaining everytime AJAX is mentioned. If you're not a web developer, then it might not interest you, but that doesn't make it pointless; you just don't have any use for it. Instead of looking for stupid things to complain about, just skip the article and go read your books or something.

Ajax and the Mr. Burns effect....

[Anonymous Coward]

It's Exxxcellent.

Risk the Client PC's Limitations ? Not yet ...

[unity100]

I still definitely refrain from Ajax like hell. The concept of delivering the load to client's computer whereas being subject to limitations of the visitor pc, and the risk of not being able to deliver the content as wanted or even at all, is one too big to take. Processing everything server side, and printing out just plain old HTML formatted result to a client pc, thus bypassing all overzealous anti-virus, privacy, anti-spyware and security software and any limitation the client pc has, is the surest thing to do, dont you think ?

The Headline Says "Ken Burns Effect"

[klenwell]

Where are the sepia tones, jazz soundtrack, and pedantic voiceover?

Tom

Ken Burns effect?

[Anonymous Coward]

Ken Burns effect? What, it takes 10 hours to get through the thing?

Re:First Post

[alanwj]

First post :)

This is poor advice. First you GET. Did you even look at the article?

Alan

Coolest Ajax UI Ever

[Anonymous Coward]

Client-side slide shows are nothing. This is the coolest Ajax UI ever. This simple yet Ajax intuitive UI:

• was built with off-the-shelf, re-usable components
• was assembled in minutes and required no debugging
• has a scalable architecture
• uses well-defined interfaces to separate objects
• is inherently cross-browser compatible
• runs on Windows, Linux, and OS X

This is very true

[SmallFurryCreature]

IF you are going to take the view that you are not going to rely on the client having certain capabilities when are you going to stop?

Render the page server side as an image? So you presume the client has image capability?

I think that for to long we have tried to include everyone. Bending over backwards to support crap browsers with broken functions just to make sure nobody was left behind. Well fuck it. At a given point you must just be able to say, "upgrade or our site won't run".

If you don't the price is going to be that other people can move ahead and use new technologies while you are stuck with an ever dwindling but always present group of people who still use the same software from a decade ago.

Ask yourselve if this is normal in the real world.

Old cars can't run on modern petrol. Yet how many gas stations keep an old pump around for cars from before WW2? Try to get some polaroid film from your average camera store. A lp player from a highstreet electronics store.

Get the picture? So why on earth are we still worried about people using browsers 2 generations out of date.

Re:This is very true

[honkycat]

I would say that you should generally stop when you've given up enough that your web site is no longer capable of serving its purpose. If you are building a site to share photographs, then there's no real need to handle the case where the user can't render an image because your site will be worthless anyway. If, however, you're a news site with photos alongside articles, then you really ought to take the time to support text-only users.

Also, you need to separate "backward-compatibility" from "downward-compatibility." The latter is, IMO, the more important of the two. The difference I am getting at is that backward-compatibility concerns a protocol change that breaks or is not supported by older browsers, whereas downward-compatibility concerns an interface capability requirement that can't be worked around by a software upgrade.

There are users who can't use nifty features for a lot of reasons. Blind users have a hard time with web pages that don't render well in text mode for a screen reader or Braille "display." Users on a handheld device have limited screen area and processing power. I myself often use a text mode browser on a brand new PC before I get X up and running. If your web site can be useful to these people, then it's worth being downward compatible.

Backward compatibility is, IMO, a bit less of a must-have, but I still would advocate maintaining it unless it's a serious hardship. Not many web sites need or are even improved by these new technologies. There are exceptions, but I find that advanced HTML rendering techniques often make sites *less* usable to me. Arguing "upgrade or die" to support something that's "cool" rather than something that's "useful" seems like a poor policy.

Your examples of gasoline and Polaroid film fall into this backward-compatibility category. Gasoline is not a great example for this discussion because there is good reason to actively discourage people from using the older more dangerous formulations. Still, pragmatically, at some point there just isn't enough demand for something to warrant continuing to provide it. I think it's worth trying to keep things compatible if you can.

And I don't know that I've seen many cases of people "bending over backwards" for compatibility. Most places, IMO, don't do nearly enough of it.

Google agrees with you , this is why Gmail....

[Shohat]

This is why Gmail has an alternative to the Ajax interface , and you can switck to HTML mode , and it just removes the AJAX dependant features :
* Filter creation
* Settings (Including Forwarding and POP)
* Spell checker
* Keyboard shortcuts
* Address auto-complete
(from http://mail.google.com/support/bin/answer.py?answe r=15049)
Google really sets a fine example here by letting users choose what kind of interface they prefer , even though they could easily just ignore these users, as I personaly dont know anyone that uses this feature . Making a dual interface for AJAX applications on all these fluffy Web2.0 sites is a good idea , specially for mobile/light clients like that 100$ laptop

Re:WHERE'S THE DEMO???

[Toveling]

On my home server (may be a tad slow), http://toveling.dyndns.org/kenburns/