Slashdot Mirror
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.'"
The use of AJAX technique in that example is spurious, at best. It's almost sad, really, since that's probably the only reason this article was accepted.
Slashdot - where whining about luck is the new way to make the world you want.
Yes, AJAX is great. Of course, the XML bit of it gets in the way, it's simpler to just grab the appropriate HTML or Javascript code directly from the server. Why write something that outputs in XML, then write client-side Javascript to re-interpret it and run javascript code or create HTML? XML is just a complication for most tasks.
Speak before you think
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 ?
Read radical news here
...Web 2.0 is a buzzword itself. I've seen an article that showed that many of the "Web 2.0" technologies are largely older technologies that have been renamed and rehyped, this time around, they took hold.
Isn't most of what's on TV just padded-out content anyway?
Actually, Ken Burns has a wealth of material to work with, but none of it moves. He scowers the public records, historical accounts, and personal diaries to find these very insightful, personal accounts that really bring to life a time before universal capture of moving images. He scans and pans over static images to create a backdrop for what is essentially a book on tape. He does an excellent job considering the lack of movies and video, but not for lack of material.
it's tough to show you what this looks like in a browser, when i'm plainly viewing it... WITH A BROWSER?
wtf?
This comment is fully compliant with RFC 527.
In practice, AJAX means Asynchronous JavaScript And XMLHttpRequest. Nothing in the XMLHttpRequest object's interface requires that the retrieved data be XML; it could be in other notations such as CSV or JSON.
This is the animated equivalent of chartjunk. It does not improve a bar chart to make the bars look like Cuisinaire rods instead of rectangles. It does not improve a slide show to move and zoom the pictures in random directions.
This is a silly demonstration of technology for technology's sake.
"How to Do Nothing," kids activities, back in print!
Good god... no wonder he didn't put the live demo up. It looks terrible! The pictures are all over the place. Doggy's head got chopped off by the side of my browser window. The fade-out didn't even work on Opera, so I had to run it on IE to see if it looked any better. One rule of the "Burns Effect" should be "never show them where the picture ends" -- but on this demo you are constantly looking at the corners of picture with two thirds of the screen being black because it's off the edge of the picture. And the zooming looks like crap because of the poor interpolation method. And the animation is not smooth at all. So, nice try, but this is a pretty poor implementation.
I wonder how many of these poor implementation things are due to limitations of AJAX, versus just plain poor implementation.
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.
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.
You're still not understanding what AJAX is. 99% of the processing load is still done by the server. All AJAX does is manipulate/update the user interface asynchronously instead of having to refresh each page. AJAX does not shift the server load to the client. I'd advise you to read the wikipedia entry on AJAX or TFA to get a better understanding of what AJAX is. These are user-interface enhancements, not a load-balancing/distributing strategy.