Addressing Ajax Design Issues

Ajax is a new ball of wax when it comes to Web applications, and as such, new rules about how the interface should and shouldn't work are emerging. Those rules have not been formalized yet, but the Ajax community is discussing them. Before launching into creating your own Ajax applications, consider the following design issues.

Breaking the Back button and Bookmarks

When you have control over what's going on in a Web page and you're using JavaScript to make things turn on and off in a page — or even to alter the page's entire appearance — the browser's Back button won't work anymore. The Back button works from the browser's history object, which stores the successive pages that have been loaded into the browser. But if you aren't loading new pages — which is what Ajax is all about — the history object doesn't know about them.

This is one to keep in mind as you design your Ajax applications. If necessary, provide your own local Back button using JavaScript. If you want to let the user move backwards to previous window states, you have to keep track of what's been going on and let the user navigate as they want to.

Leaving the user in control

Ajax applications can seem to take on a life of their own because they operate behind the scenes. And they can communicate with the server even when the user doesn't want them to — as when the user makes a typing error. You can imagine how you'd feel if you'd just entered a typo and it was immediately stored in a database by an application that didn't ask you if you wanted to store anything.

So, to give your applications a good feel, here are a few tips for putting users in control:

• Don't whisk data away for storage until the user really wants to store it.

• Remember that, ideally, your application is supposed to respond to events caused only by the user. Users can find too much server-side validation disconcerting because it creates the impression that you're correcting them at every keystroke. Don't forget that one of the design principles of graphical user interfaces (GUIs) is that the user should be in control, that they should direct the action.

• And don't forget to offer the user a way of undoing errors.

Remembering all the different browsers

As with any Web application, it's worthwhile to keep in mind that there are many different browsers around, and your Ajax application should be tested in the ones you want to support.

As of this writing, Internet Explorer and Firefox make up about 96 percent of browser use, and the rest (Opera, Safari, and so on) are each in the 1 percent or less category.

And don't forget that not all browser will support JavaScript, or will have JavaScript turned on — and for those users, you should have a backup plan.

Avoiding a sluggish browser

Ajax applications can be large, and when they start using up resources like memory and CPU speed, you've got to be careful. A large application can use up a huge amount of memory, especially if you're not careful about getting rid of large objects that have been created.

Sometimes, developers use Ajax just because it's a new thing. Be careful about that tendency, too. Ajax solves many problems, but if you don't have to use it, there's no reason to. And also, don't forget that your Ajax applications might not work in all browsers — such as those where JavaScript has been turned off. You should provide some kind of backup plan in that case.

Handling sensitive data

With Ajax, it's easy to send data without the user knowing what's going on. In fact, that's part of the whole client/server connection thing that makes Ajax so popular. But it's also true that the user may not want to send the data you're sending.

It's best to be careful about sensitive data. The Internet is not necessarily a secure place for sensitive data, after all, and if you start sending social security numbers or credit card numbers without the user's permission, you could wind up in trouble. So give the users the benefit of the doubt — ask before you send sensitive data.

Creating a backup plan

Ajax relies on being connected to a server but don't forget that not everyone is online all the time. And your own server may go down, so your users may be working from cached pages. If you can't connect to a page online, you should have some kind of backup. And that goes for users who have browsers that don't support JavaScript, too.

Showing up in search engines

Google searches billions of Web pages for the text that its users search for — but if the text you display is loaded into a page based on user actions, not on browser refreshes, Google isn't able to see that text. So bear in mind that if you want to make your page searchable on search engines like Google, you've got to give your page the search terms they need. (You can store your keywords in a <meta> tag in the browser's <head> section, for example, which is where search engines expect to find them. See this site for more information on that.)

dummies

Source:http://www.dummies.com/how-to/content/addressing-ajax-design-issues.html