Thursday, March 17, 2005

Ajax

There has been a handfull of noise about Ajax (XMLHttpRequest+javascript, etc i.e. what gmail uses) on the web recently. I spent last night looking around at everything I could find. A few do's and don't about when it should be used:

It should not be used when the content is static and the content is of a small enough subset. For example on a cddb website you should be able to browse to genres, artists, etc and then make a bookmark. You could use Ajax, but it would not be bookmarkable and on will be not worth the trouble as cddb entries don't change that much.

You should use it when the user it editing content that isn't bookmarkable. For example in gmail when you are composing, reading, sorting e-mail it wouldn't be of value to bookmark any of those sense they are constantly changing.

It should be used for validation of user input.

Simple way to look at it:
readonly - Plain html
readwrite - Ajax might make sense.

Read Only Example:
If you (like many) are making a photo gallery web application, you could use ajax to load up images as they click next, but then users couldn't bookmark the image that they want to show someone else later. Instead you should have the next link actually go to a new page.

Read Write Example:
Checkbook managing. Adding new items to the checkbook aren't exactly something you want to bookmark, but you can bookmark the page that shows the overview of one bank account or another.

Some inevitable bad things that will come of this:
-Websites with tabs that aren't bookmarkable, but load them all at once
-Photo galleries that load images on the fly.
-Blog sites that load the stories rather then linking to them.

Some good simple things:
-Validation of fields done on the server side, thus letting you track what fields need improving and are wrong a lot.
-And website that lets you comment (blogs) don't need entire extra web pages to add comments, but could do it inline right on the page.
-Web galleries, when logged in as *admin* will let you comment, rotate image etc on the fly without reloading the page.
-Sites where the user "builds" something. Such as when a user searches through a very large quantity of _dynamic_ data. The search should be bookmarkable, but Ajax can show a highlight that 7 items with the following headers were found. A good example: real estate. You want to keep your search so you can keep coming back to it, but while building your query you want to be able to try out different combinations of the search and quickly know that just by selecting "pets" the number of available houses goes from 1000 to 12.

Some more complex things:
-I would definitely use a online checkbook that let me import my back downloaded files and automatically figured out what my budget is for me. Yes, ever bank has a online banking, but only for *them*. Think quickbooks light.
-Games! You can do simple turn based games and have "fluid" motion without the disconnect of reloading the entire page every time they make a turn (and no wait for the computer to make a turn before it replies too).
-Todo lists. Quickly add/remove items, accessible wherever you go.
-Addressbook. Really an LDAP server that had a nice frontend to add/remove fields letting you use that addressbook in your regular e-mail client and *share* your (or parts of) addresslist with others (such as in your family etc)
-Instant messaging (combined with addressbook !*please*!) Jabber, but better
-Graphing calculator with log
-Calender (combined with addressbook and todo list !*please*!)
-Password manager (pretty much the same code as on the todo list with a little more added on)

There are some key things that must be addressed for an Ajax application to be successfull. First, having it on the server must offer some advantage. For Apple users who already have a powerfull calculator they don't need an Ajax calculator other then the fact that it loads instantly, but for Windows users it is very handy as their calculator is, well, crappy. The addressbook with provided ldap makes good sense for just about anyone. At this stage you could almost take any good Palm utility and make an Ajax application out of it that will be used by a lot of people.

Following the Palm paradime Ajax would be a nice way to completely get rid of "saving". Saving came about because of flaws in computers as isn't a natural thing that you do. You don't manually save documents, it always does it for you in the background. Playing a game, it is saved on the server so the next time you come back it automatically starts at the same place. There should be no need for manually saving anymore!

Once someone comes out with a document editor you could take advantage of a number of things the formost of my list is revision control. Every time a user leaves the website the document would automatically be "committed" to subversion or whatever is used on the backend (users never knowing is key). Then users could go back in time to see different revisions of their document. And if you had an addressbook/im on this website you could share documents with other users very easily. Very quickly we start to get in the range of abilities that your modern word process can't really do. Yes you would have to add the ability to count the number of words and silly "basic" stuff like that, but the real value would be the ability to edit your documents whereever you are with full revision control and the ability for others to make changes to your document. Don't forget printing is as easy as clicking print in the web browser, no transfuring of files around on floppy. Unleash that upon the world and you will very quickly find people who used Microsoft Word for spell checking, todo list, and other basic things using this much more powerfull tool.

Taking it to the next step you could make a website editor so anyone could make and maintain a website and when they are logged there website will show up and they can just click and edit the pages.

If you only get one thing out of this: If your content is readonly to the user, don't use Ajax!

No comments:

Popular Posts