PART II
Chapter 8: User Interface Design for Ajax 337
users are not aware of changes. Put simply, if incremental changes to pages are performed too
subtly, users may not notice that the content is changed. The rise of spotlighting techniques
such as the simple yellow fade and other transition schemes, are again not Ajax in the sense of
being involved in backchannel communication, but are needed interface changes without the
predictable full screen repaint between pages or application states that users are used to.
Moving from the traditional click, post, and wait Web pattern to a potentially much
richer Ajax style does require that users break old habits and learn new conventions—or at
least apply old conventions in a new environment. While Ajax applications may appear to
act more like desktop applications, users have been trained to use Web applications in
different ways. Double-clicking and right-clicking, while common in desktop interfaces,
might not be assumed available in a Web application. The same unfamiliarity could be said
for direct manipulation such as dragging. Keyboard usage outside URL entry and form-fill
out will also likely be unusual to most traditional Website users. At least for now, as the
Web transitions to new interface patterns, Ajax designers and developers will have to
encourage users to explore and learn new conventions using interaction indicators like
varied cursors and tooltips, and may even need to provide tutorials upon first use.
Some might argue that changing interface conventions in light of Ajax is a bad idea and
even suggest avoiding desktop software idioms in favor of a simpler Web interface palette
of single-clicking with colored, underlined links and basic form controls. However, to fully
deliver upon the richness and speed promise of Ajax without infuriating users, interface
changes are required. Conversely, aiming to emulate a Windows-GUI interface in a Web
browser is clearly not the solution. The Web is different, and it has its own conventions that
should be respected. Interface conventions will continue to emerge as Ajax is used more and
more, and likely numerous spectacular failures will occur when attempts are made to
innovate. The potential for failure should not be an excuse to avoid change, as the
challenges of Ajax do not outweigh its potential benefits. The ability to rapidly browse large
data sets, avoid frustrating round trips to the server, and simply get common tasks done
more quickly is well worth any extra effort required.Communicating Network Activity
We begin our more detailed discussion of interface changes required for Ajax by focusing on
the implications of the changed network communication pattern. We hope that after the
lessons of previous chapters, particularly Chapter 6, it will be clear that in a networked
environment, things really do fail from time to time. Web users may not like such failures,
but they accept it and mitigate it all the time. Hitting the back and reload buttons are such
frequent activities for users that they are not often conscious of just how often they perform
such tasks. To avoid user frustration with intermittent network and server problems, both
browser vendors and Web developers alike have taken great pain to inform users to what is
going on. In the past, much of this dialogue in regards to communications status was the
responsibility of the browser, but with the rise of Ajax, this duty is moving to the developer
more than ever before.Traditional Web Pattern Activity Indicators
Web browsers do a good job of letting users know that network activity is taking place and
the general progress of such activity. For example, as shown in Figure 8-1, a browser may