# Web Interfaces, Continuations, and AJAX

This started as a comment to Simon Brocklehursts post on Web Interfaces. When I started on my 4th paragraph I decided that it was better off as a blog post than a long missive on Simon's blog.

So go read his post and then come back here, and pretend that I'm commenting there. Go ahead, I'll wait. :)

Hear hear! I've long explained to people that I use vi because it's easy to use, although not easy to learn. The pain I went through to learn vi has been repaid thousands of times over in how easy to use it is ONCE you've learned it. This statement inevitably causes confusion among those who don't know vi, and I find myself spending 10,000 words to explain this to them. Now I can just point them to Simon's post.

I find myself using AJAX at work to enable the kinds of rich GUI interfaces Simon writes about. The easily understood example is an imitation of OSX live searching. Present the user a table and a search field, and as the user types the table is filtered in real time. It's a simple thing, but my users love it.

A better example is the HR/Resume system I'm working on for work. To add or change an employee's entry and/or resume, you use the same page, which is a form page for entry. You can either use the drop-down to select an employee, or start typing a name into the name field. As soon as a unique match is found (based on their username) the form automatically fills in based on what's in the database. This is similar to the Access application I'll be replacing with this. Now, I'm not holding Access up as a paragon of good design, but at least for our company and clients the interface is known and is easier to use (as opposed to learn) than your average web application, despite how it makes programmers cringe.

I then use Javascript to keep track of which fields have changed, and submit only that information which has changed. This increases the responsiveness of the application, as the user doesn't have to submit large amounts of data via the ADSL connection they're likely using. I'd never use this in an application for the Internet, but when I can specify that only certain browsers are supported this sort of thing is possible.

So far I only have one user actually using the system (Our HR person) but she likes it so far, and is typical of an average user. She's the same user that had trouble figuring out our 3rd party timecard system, so I figure I've done something right.

AJAX as I'm using it doesn't break bookmarkability, and doesn't break the back button, it simply adds the rich GUI elements that make my webapps easier to use. IMHO, this is the future of webapps, somewhere between the extremely simple apps Tim advocates and the Rich AJAX apps others advocate.

I also have to point out a flaw in Tim Bray's parenthetical comment on Simon's post. Tim Says:

but Simon, a good browser should pre-fill forms for you and get it right almost all the time; Safari does

Tim is taking a narrow view here. Safari's autofill gets it right most of the time, but that's only a subset of when web apps are used. It ignores the common case of webapps used inside of companies. For example, you wouldn't want your web browser to autofill a bugzilla form. In fact, I can think of very few webapps outside the Internet where you actually want your browser to autofill.

posted at: 2006 May 21 01:37 UTC | category: tech | (story link)