Each part of an AJAX interaction needs to be defined. Also, think about non-JavaScript versions of widgets. With AJAX interfaces, we move into a world of applications that have states and views and out of a world in which our document or page model was based on ideas carried over from print. This for me is a good thing. The Web is a rich medium, not a sequence of linked designs. As mentioned, we use AJAX to disrupt the normal browsing behaviour of our users.
This can be a good thing: no one claims that browsers do everything right, but understanding just how many things we should take care of when taking over the browser is important. To make this work, you need to update the URI of the current page with a fragment and reload a hidden frame in the page.
There are all kinds of annoying differences between browsers, too, and you can use something like the history plug-in for jQuery to get this to work. Probably the first thing to fix is to tell the user that something is loading when they click a link or push a button. If the page shows no apparent change, the user will think something is wrong and keep clicking. This is an unfortunate human reflex, because the more you tell a computer to do something, the slower and more confused it gets. A simple way to provide the user with feedback is to show a loading message.
To do this in jQuery, we need to get away from the load method and instead use ajax , which gives us information about what happens to the request, such as:.
Putting them together, we can add a loading message to the target element when the AJAX request starts, which is replaced when the data has successfully loaded:. As you may have guessed, the next logical step is to handle error cases. The following script takes care of all this, and you can see it in action on the error handling demo page. One last touch is to make it very obvious that something on the page has changed. The standard way of doing this is called the yellow fade and was introduced in by 37signals in its Basecamp application.
With this technique, you change the background colour of the element to yellow and then fade it smoothly back to white. Using it, we can highlight the AJAX returns, making it very obvious that something has changed:. This is about all we need to do to make AJAX more usable. But to make it accessible to everyone out there, we have to do a bit more.
Accessibility does not mean much more than hard-core usability. Or think someone who has trouble noticing changes from one page to the next and all of a sudden has to deal with small changes on individual pages—changes they are not notified about. Imagine a keyboard user tabbing through a document to activate a link and out of the blue being confronted by 10 more links.
There are a lot more cases such as these, and your interface should be able to handle them at least at a very basic level. If you research the topic of AJAX and accessibility, you will come across a lot of tutorials that deal with the problem of screen readers. The real problem with screen readers, and any assistive technology, is that they add yet another level of complexity to our Web interaction. We have HTML interfaces such as links and forms that need to work with all kinds of input devices: keyboard, mouse, voice recognition software, to name a few.
Then the browser needs to somehow tell the assistive software whether a screen reader or software that zooms the screen or a voice recognition tool that something has changed, and that other tool has to translate it into an understandable format. All of this can, and frequently does, fail. Again, this topic is too big to cover here, but some good articles are out there in case you are interested.
One very important requirement of accessibility and AJAX is providing keyboard access, and doing this in a very basic way is not hard. The element that triggers the AJAX call has to be something that users can access with the keyboard i. You can test this yourself: simply use the Tab key to jump from one keyboard-accessible element to the next in your document.
Can you access all of the functionality, and is it obvious where you are at any given moment? This is where you as a designer can do a lot to make your AJAX interface more accessible. Patrick Lauke has written a wonderful article on keyboard-access styling to get you on your way. The second, very important, part is to notify users in the element that they activated that something is happening. One example of this is the contact form on Get Satisfaction:. Large view. When we can see the screen in full, everything is pretty obvious.
Or someone who gets easily confused and uses a tool to focus on the part of the screen they are interacting with and blur out the rest. When you are only updating part of a page or perhaps performing an action that doesn't update the page at all AJAX can be a very good tool.
It's much more lightweight than an entire page refresh for something like this. Conversely, if your entire page reloads or you change to a different view, you really should just link or post to the new page rather than download it via AJAX and replace the entire contents.
One downside to using AJAX is that it requires javascript to be working OR you to construct your view in such a way that the UI still works without it. The most common use is to update part of the view. Note that this does not include refreshing the whole view since you could just navigate to a new page.
Another common use is to submit forms. In all cases, but especially for forms, it is important to have good ways of handling browsers that do not have javascript or where it is disabled. I think the advantage of using ajax technologies isn't only for creating better user-experiences, the ability to make server calls for only specific data is a huge performance benefit.
Imagine having a huge bandwidth eater site like stackoverflow , most of the navigation done by users is done through page reloads, and data that is continuously sent over HTTP. Of course caching and other techniques help this bandwidth over-head problem, but personally I think that sending huge chunks of HTML everytime is really a waste.
Cons are SEO which doesn't work with highly based ajax sites and people that have JavaScript disabled. When your application or your users demand a richer user experience than a traditional webpage is able to provide. Responsiveness - you can update only parts of a web page at a time if need be saving the time to re-load a page.
It also makes it easier to page data that is presented in a table for instance. User Experience - This goes along with responsiveness. With AJAX you can add animations, cooler popups and special effects to give your web pages a newer, cleaner and cooler look and feel.
If no one thinks this is important then look to the iPhone. User Experience draws people into an application and make them want to use it, one of the key steps in ensuring an application's success. For a good case study, look at this site. AJAX effects like animating your new Answer when posted, popups to tell you you can't do certain things and hints that new answers have been posted since you started your own answer are all part of drawing people into this site and making it successful.
Javascript should always just be an addition to the functionality of your website. You should be able to use and navigate the site without any Javascript involved. You can use Javascript as an addition to existing functionality, for example to avoid full-page reloads. This is an important factor for accessibility. Javascript should never be used as the only possibility to reach or complete a request on your site.
Ajax is primarily used when you want to reload part of a page without reposting all the information to the server. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow.
Learn more. When is it appropriate to use AJAX? Ask Question. Asked 12 years, 9 months ago. Once done, the server will send a response back to the client and the client will process it as necessary. JavaScript is the client-side programming language and XML is a markup language to define data.
JSON is another markup language to define data. This free, open-source software is a wrapper around JavaScript. The Ajax Control Toolkit is a suite of controls created by Microsoft that is integrated into Visual Studio and can be dragged and dropped onto web forms just like html and server controls. These controls are intended to be used for Ajax callbacks. However, they can also be used as normal client and or server controls. For example, Asp. Net does not come with the Tabs controls.
However, the Ajax Control Toolkit does. The Tab control can postback to the server just like server controls. Ajax should be used anywhere in a web application where small amounts of information could be saved or retrieved from the server without posting back the entire pages.
0コメント