AJAX In Action [18]
A web browser provides two input mechanisms out of the box: hyperlinks and HTML forms.
Hyperlinks can be constructed on the server and preloaded with Common Gateway Interface (CGI) parameters pointed at dynamic server pages or servlets. They can be dressed up with images and Cascading Style Sheets (CSS) to provide rudimentary feedback when the mouse hovers over them. Given a good web designer, hyperlinks can be made to look like quite fancy UI components. Form controls offer a basic subset of the standard desktop UI components: input textboxes, checkboxes and radio buttons, and drop-down lists. Several likely candidates are missing, though. There are no out-of-the-box tree controls, editable grids, or combo-boxes provided. Forms, like hyperlinks, point at serverside URLs. Alternatively, hyperlinks and form controls can be pointed at JavaScript functions. It’s a common technique in web pages to provide rudimentary form validation in JavaScript, checking for empty fields, out-of-range numbers, and so on, before submitting data to the server. These JavaScript functions persist only as long as the page itself and are replaced when the page submits.
While the page is submitting, the user is effectively in limbo. The old page may still be visible for a while, and the browser may even allow the user to click on any visible links, but doing so will produce unpredictable results and may wreak havoc with the server-side session. The user is generally expected to wait until the page is refreshed, often with a set of choices similar to those that were snatched away from them seconds earlier. After all, adding a pair of trousers to the shopping basket is unlikely to modify the top-level categories from “menswear,”
“women’s wear,” “children’s,” and “accessories.”
Licensed to jonathan zheng 22 CHAPTER 1 A new design for the Web Let’s take the shopping cart example again. Because our Ajax shopping cart sends data asynchronously, users can drop things into it as fast as they can click. If the cart’s client-side code is robust, it will handle this load easily, and the users can get on with what they’re doing. There is no cart to drop things into, of course, just an object in session on the server. Users don’t want to know about session objects while shopping, and the cart metaphor provides a more comfortable real-world description of what’s taking place. Switching contexts between the metaphor and direct access to the computer is distracting to users. Waiting for a page to refresh will jerk them back to the reality of sitting at a computer for a short time (figure 1.14), and our Ajax implementation avoids doing this. Shopping is a transient activity, but if we consider a different business domain, for example, a high-pressure help desk scenario or a complex engineering task, then the cost of disrupting the workflow every few seconds with a page refresh is prohibitive. The second advantage of Ajax is that we can hook events to a wider range of user actions. More sophisticated UI concepts such as drag-and-drop become feasible, bringing the UI experience fully up to par with the desktop application widget sets. From a usability perspective, this freedom is important not so much because it allows us to exercise our imagination, but because it allows us to blend the user interaction and server-side requests more fully. Case Case Account Account Concepts, Customer Customer metaphors, Contract business domain Contract Boundary (painful to cross) Filesystem Filesystem Web service Web service File Data model, File bits and bytes, machinery Database Database Figure 1.14 Interrupting the user’s workflow to process events. The user deals with two types of object: those relating to their business, and those relating to the computer system. Where the user is forced to switch between the two frequently, disorientation and lack of productivity may occur. Licensed to jonathan zheng The four defining principles of Ajax 23 To contact the server in a classic web application, we need