Practical Ajax - Enhancing The User Experience
Ajax can be a double-edged sword of sorts. If properly done our users should really have little or no clue that any 'magic' has happened. If overdone (or implemented needlessly - a phenomenon I like to call 'Because I Can...' or 'BIC') our users can be overwhelmed, and/or confused. One of the end goals of implementing an Ajax solution is to give our users an enhanced experience with our application - or at the very least keep them from being annoyed by the experience.
Imagine an application that you might use to manage/catalog something. It's not uncommon to have items that are related to one another. A normalized database would handle these relationships through the use of keys (both primary and foreign). Whether they are auto-numbered integers or manually created UUID's makes no difference - they still will relate one record to another record (or multiple records) or vice versa.
Object Oriented practices handle these type of relationships via composition. A simple example of composition would be a Employee object which could consist of a FirstName, LastName and one or more EmailAddress(es). It could be said that an Employee 'has a' EmailAddress. As opposed to an Employee 'is a(n)' EmailAddress in which case we'd be talking about another Object Oriented practice called inheritance (an example of which could be an Employee inheriting or extending a 'User' class).
So what does Ajax have to do with objects and composition? Well think of that Employee I mentioned previously. How many times have you ran into one of the following scenarios:
- You fill in your first name, last name and save the data. You're taken to another form which allows you to enter an Email address. You save the email address. You return to that form and enter another email address. You return to the 'Employee Directory' and you see your info and both of your new email addresses.
- You fill in your first name, last name, and click a link which opens a popup for you to enter your email address. You enter the info and save in the popup browser window. The window closes itself when saved and automatically submits (or even worse, just refreshes) the parent window.
- Even more horrifying is the good ole 'fixed number of email address' trick where the developer obviously didn't even bother creating a seperate table. In this scenario you're presented with First Name, Last Name, Email Address 1 and Email Address 2. You're stuck in the box, and nevermind if you have more then 2. Just enter the 2 that you check most often cuz you aint gettin more then 2! ;)
How could this scenario have been made a more enjoyable (or at the very least, less annoying) experience? The initial form would still contain the first name and last name inputs, but with Ajax you could have been presented the user with a dynamic dataset of existing email addresses. Each existing address would present a link to edit it, and there would also be a link to add additional email addresses. This link would open an Ajax (CSS based) dialog window whose contents would be dynamic to the given email address (not a new browser window!). The dialog would let the user enter/edit the email address and would save the data via Ajax form submission. Upon close of the dialog box the email address dataset would (conditionally) refresh itself to reflect the latest data.
Using the above scenario our users would have little idea what was going on. They would, however, have an amazingly better experience the the first example above (where they would have far more clicks and form submissions) and a more enjoyable experience then the second example (where the auto window refresh/form submission would break the user experience (users refresh/submit - your code should not do this for them!).
The bottom line here is, Ajax makes improving the user experience in our application an easy thing to do for us. Take advantage of it! Learn one of the many Ajax frameworks out there - or use the built in Ajax functionality in ColdFusion 8 which would make the above example dead easy!
Great post. Very important, and often ignored, is using technologies for function, rather than solely design sake. This was always one of the early arguments against Flash. That it was for Splash pages and animations. Even after the functionality was added to create great, dynamic applications, a lot of people still used it for design over function.
I do a lot of posts on the new CF8 Ajax components, which are very useful in certain situations. But rarely, if ever, would I use them, or Ext, on the front end of a web site. At least not outside of a specific application (like a registration process). Your example is a perfect example of a 'when and why' scenario.