Ajax and the Ken Burns Effect 239
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.'"
Buzzword compliance? Check (Score:3, Insightful)
Yet another thing XML complicates... (Score:4, Insightful)
Risk the Client PC's Limitations ? Not yet ... (Score:4, Insightful)
There are a lot of "Web 2.0" buzzwords... (Score:3, Insightful)
Re:Risk the Client PC's Limitations ? Not yet ... (Score:2, Insightful)
Processing everything server side [...] dont you think ?
No :p
Available processing power of the client is the same when several clients access the web page.
Available processing power of the server degrades with the number of clients...
You must know you're target audience, and send most of the job you can to them (never trusting them), or by your logic, why send HTML, you better render it and send it as an image so that the client don't spend time prossecing all those HTML tags :p
Re:Yet another thing XML complicates... (Score:3, Insightful)
Re:This is detailed Ajax, Ken Burns style... (Score:3, Insightful)
Dealing with a lack of material to work with... (Score:2, Insightful)
what is wrong with this picture? (Score:4, Insightful)
it's tough to show you what this looks like in a browser, when i'm plainly viewing it... WITH A BROWSER?
wtf?
Re:Yet another thing XML complicates... (Score:3, Insightful)
AJAX does not require XML (Score:2, Insightful)
In practice, AJAX means Asynchronous JavaScript And XMLHttpRequest. Nothing in the XMLHttpRequest [wikipedia.org] object's interface requires that the retrieved data be XML; it could be in other notations such as CSV or JSON.
You hoo... Ed Tufte? (Score:4, Insightful)
This is a silly demonstration of technology for technology's sake.
Re:Yet another thing XML complicates... (Score:1, Insightful)
Because of presentation and content separation.
Re:WHERE'S THE DEMO??? (Score:2, Insightful)
I wonder how many of these poor implementation things are due to limitations of AJAX, versus just plain poor implementation.
Re:This is detailed Ajax, Ken Burns style... (Score:5, Insightful)
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.
Re:This is very true (Score:5, Insightful)
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.
Re:A policy of noscript (Score:3, Insightful)