Design Principles
Navigation
Another feature of the browsers that most people have become used to is the ability to return to a previously
viewed page. This is no problem in a traditional web site, especially if the site in question is merely a brochure for an organization and there is no information that needs to be retained and transferred
between pages.
Now what should happen when the user clicks Back in an AJAX website?
If you choose to use Ajax techniques, then don’t switch unnecessarily between updating parts of a page with new content this will lead to inconsistencies in how the browser’s navigation buttons behave and the user will become wary.
An example would be a menu page that uses standard links to lead to sub-pages, each of which use Ajax to
implement their own functionality. Within these sub-pages, after partial updates have been used, the only reason to leave the page would be to return to the menu so keep a link to the menu from the current page so the user won't have to press back.
Minimizing Traffic
if you want your application to have maximum reach you need to minimize network traffic.
For applications using Ajax and other Web 2.0 techniques this can be achieved in a number of ways:
- Making requests and responses as terse as possible
- Combining multiple requests into one
- Processing on the server when possible
- Not overusing Ajax and related technique
Keeping Communication Concise
Making requests and responses as terse as possible obviously cuts down on network traffic and there
are a few ways to do this.
XML is not known for its conciseness and can lead to bloated messages.
Three things that influence the size of your messages are choice of names, whether to use elements or
attributes, and indentation
The following code shows a real-life example for XML message meant to represent a user’s shopping basket.
<shoppingBasket>
<userId>1234567890</userId>
<items>
<item>
<sku>abc123</sku>
<quantity>1</quantity>
</item>
<item>
<sku>def456</sku>
<quantity>2</quantity>
</item>
<item>
<sku>ghi789</sku>
<quantity>3</quantity>
</item>
</items>
</shoppingBasket>
The big advantage of this format is that it’s easy for a developer to see what everything means
The downside is the size of the message
so it can be more economical to shorten the names of the elements to something like the following.
<b>
<u>1234567890</u>
<i>
<s>abc123</s>
<q>1</q>
</i>
<i>
<s>def456</s>
<q>2</q>
</i>
<i>
<s>ghi789</s>
<q>3</q>
</i>
</b>
Further savings can be made by using an attribute-centric format such as the following one:
<b u=”1234567890”>
<i s=”abc123” q=”1”/>
<i s=”def456” q=”2”/>
<i s=”ghi789” q=”3”/>
</b>
Many XML developers would argue that reducing the size of documents by using very short names is
poor practice and if size is such a worry then other technologies should be used, either a non-XML format
or some sort of compression
Combining Multiple Requests
Combining multiple requests can also cut down on network traffic. There is an overhead on each request to the server, including details such as content type, the length of the message, and the eventual destination.
By stuffing multiple requests into one request, these header details are only sent once.
A simple example would be a spell-checking service. As a user types into an HTML text area each word could be sent back to the server and checked for the correct spelling, much the same as most modern word processors carry out this task. An alternative would be to wait until the user leaves the text area or, as a
compromise, one sentence at a time could be checked. This sacrifices some user functionality but greatly
reduces the data passed over the network.
Processing on the Server When Possible
Processing on the server is a traditional technique, originally used because clients didn’t have sufficient
processing power, RAM, or large enough local storage. Nowadays a traditional computing device such
as a desktop will have all these essentials, but network issues can still remain.
One common task is that of transforming XML through the use of an XSL transformation. On modern
traditional browsers this can be accomplished client side, but this would involve both the source XML
and the transformation being sent across the network. Transformation server side can eliminate much of
the traffic as well as allowing for clients that don’t have the requisite functionality. The downside of this
is that usability will almost always decrease in the sense that if the user wants a different view of the data, perhaps sorted in a different order, a second trip to the server is needed.
If all the data and the XSLT had been sent to the client originally then subsequent manipulation would have been much quicker. This is the sort of decision that needs to be taken when designing an application; if the user is going to want to see different views of the information it may be better to provide the raw data and the
means to manipulate it despite the fact that the initial download will probably take longer.
A further consideration is that XSLT processing server side is not necessarily going to save bandwidth,
as there is not a direct correlation between the size of the output document and that of the XML input
and its transformation.
Limiting Use of Callbacks
Avoiding excessive use of callbacks is also recommended.
The following list highlights reasons why this is a bad idea:
- Excessive network traffic : not all clients have the luxury of a permanent high-bandwidth connection.
- Too much feedback and information slows down the user
- Removing the ability to correct error
- Spying on the user
Prepared by Mai Fouad and Mahmoud Ali
