Page 1 of 1

AJAX: usability guidelines

Posted: Sat Dec 10, 2005 4:05 pm
by raghavan20
I have found the usability problems associated with AJAX here but do you know any good article/s that talk/s about AJAX best coding practices to make it highly usable.

Posted: Sat Dec 10, 2005 4:36 pm
by raghavan20
alright, this might be a better way to start. how do you guys tackle the back button problem with your ajax applications?

Posted: Sat Dec 10, 2005 8:22 pm
by Chris Corbyn
raghavan20 wrote:alright, this might be a better way to start. how do you guys tackle the back button problem with your ajax applications?
Specifically? -- If you track link clicks and user activity then it helps but I dont know you're individual situation :)

Posted: Sat Dec 10, 2005 8:45 pm
by Roja
raghavan20 wrote:alright, this might be a better way to start. how do you guys tackle the back button problem with your ajax applications?
Thats an easy one. I don't use ajax for anything that would interfere with it.

For example, building an online chat system ("Shoutbox") makes a ton of sense with ajax. You login, and once in, you are "in the application". From there, what does back mean? It means going back to where you logged in, which will work just fine.

Making a shopping cart makes sense to a degree, until you think about the back button. What if I move an item into my cart, and want to back up? In a pure ajax cart, you couldnt (without specifically coding a solution to that issue).

For me, I think of it in terms of "Does the user make a change that they may want to back up from". If so, thats probably a non-ideal place for ajax.

Posted: Sat Dec 10, 2005 9:27 pm
by josh
A lot of non-ajax shopping cart systems have a remove button, and the back button does not undo adding an item to the cart, the only way to remove an item is to hit the "remove button" right under the item itself in the cart. Maybe that is "bad practice", but just look at gmail, I archive an email and hit the back button and the application locks up, but most users would not think of hitting the back button, they would generally go into "all mail" find the email and move it back to the inbox, this is because they are used to traditional desktops applications, now this isn't a traditional desktop application, but AJAX simulates that. If your entire application mimics a desktop app then I think it's perfectly fine, and even intuitive to have the back button not undo changes. Now if you are mixing web features (lots of pages reloading), and your application is not entirely contained to one "screen" (gmail hardly ever refreshes my page, and when it does I don't even notice it), I think the back button should do something.

Although as developers we inevitably overlook some things, I find the best way to test the interface is to get a bunch of computer illiterate people to use it and watch what they do very carefully, if for some reason most people are wanting to hit that back button then your application is not entirely simulating a desktop application. If your guinee pigs are struggling finding a "delete" button or something like that, you need to redesign that particular part of the application.

Posted: Sun Dec 11, 2005 5:52 am
by raghavan20
alright...i am learning ways how to develop highly usable interfaces for AJAX applns. lets assume a situation, it's a directory service, you type in some keyword and you get some details on blur event. the user wants to go back and see the details for the keyword he/she entered earlier how do you make this happen. (Or the common place of problem might be any page in admin section where you employ ajax)

one of the ways, i think, should be saving the keywords typed by the user since his/her first try. But how do you detect that back button is pressed and then retreive appropriate keyword and related information.



2. my second question is, how do you let search engines index pages where AJAX is employed?

An excerpt from ASP.Net professional
asp.net professional website wrote:There are already thousands of web sites using AJAX or similar techniques. One problem all of them have is the point that web crawlers will only search for HREF, SRC or some other link tags. I never saw a web crawler that is searching for AJAX JavaScript proxies. I think web developers only see the benefit of AJAX for the speed/performance advantage of web sites. If you want to build web sites that will be reachable through search engines you have to write two sites, one with the usage of AJAX for the human visitor and one for web crawlers that will need the complete HTML/text of the page.

Posted: Sun Dec 11, 2005 6:14 am
by raghavan20
1. For the first problem, i am wondering is it possible to store to store all the values and a counter in the session object. And every time the page is loaded when back is hit, decrease the counter by one and retrieve appropriate array value and send again an XMLHTTP request to get the details of that keyword/value retrieved. Is this feasible?

Posted: Sun Dec 11, 2005 2:53 pm
by raghavan20
O'reilly's XML.com website has developed a really simply history framework(RSH) to deal with this problem and their examples solve the problem. the article is here

Posted: Sun Dec 11, 2005 3:58 pm
by josh
Solution:

Don't use AJAX to display your content, if you want to use AJAX for your navigation, at least have a link to your site map in the <noscript> tags. Like already mentioned the user should be able to copy the URL or bookmark and get back to their content. Places I've used AJAX (or similiar things) include:
login box's, menus (always providing an alternative menu for non-jscript users and SE spiders), forms for users to fill out (hey search engines don't care about forms, to my knowledge, so go wild here), password protected areas like admin panels (again search engines don't go here)

Just whatever you do do not load content into a div layer on the fly with AJAX (you're better off using frames then this!!)

This is a common problem with AJAX... a helpful link

Posted: Mon Feb 20, 2006 9:47 pm
by it

Posted: Tue Feb 21, 2006 3:03 am
by matthijs