W3C home > Mailing lists > Public > public-uwa@w3.org > October 2007

Ajax and layouts

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Thu, 11 Oct 2007 15:00:46 +0100
Message-ID: <D5306DC72D165F488F56A9E43F2045D3014D9197@FTO.mobileaware.com>
To: <public-uwa@w3.org>

Recently I have been looking at the use of Ajax in the creation and
control of presentation layouts, as input to the UWA's charter item on
Layouts. Here is a short summary of my findings:


The script resources that accompany Ajax-pattern pages often provide
layout solutions in the following categories:
- Generation of structured presentation
- Visibility (show/hide, expand/contract)
- Resizing of regions
- Access (e.g. enabling/disabling visibility controls)


Complex effects can be achieved through simple combinations of the

For example, the tabbed layout is achieved through an event handler that
controls the visibility and style of the tabs, and the visibility of the
content within the tabs. In this case, the handler sets the current tab
to a default style and applies a highlighted style to the newly selected
tab. Then the visibility of the current tab content is set to hidden,
while the corresponding selected content is set to visible.


Using events to selectively present subsets of the page content enables
a much more dynamic and interactive feel because there are little or no
round-trips to the server. But the page weight grows to accommodate the
material that is initially hidden.

The Ajax approach can reduce the page weight by keeping (some of) the
hidden material on the server, and retrieving it only when it needs to
be displayed. This means that there is a round-trip call to the server,
but the returned payload will be significantly smaller as it only
represents the newly-visible content.

Thus there is a balance between page weight and responsiveness. In some
cases it may be possible to adjust this balance. For example, a page
with several tabs could include the first few tabs of content in the
initial page, and leave the remaining tabs of content for retrieval via
the XmlHttpRequest mechanism.

Furthermore, the asynchronous approach can overcome the perceived
latency issues by pre-emptively retrieving content. For a tabbed
interface, this means that the next tab can be anticipated and retrieved
while the user is reading the current tab. The penalty for this approach
is the possibility of retrieving unnecessary content, which could be an
issue where networking resources are scarce or expensive.


Ajax lends itself well to the creation of tabular layouts. In this
technique, the Ajax application on the client retrieves the raw data
from the server. This data is compact and devoid of table markup
overheads. Once retrieved, the application script generates the
necessary table markup, looping over all the data retrieved from the
server. This is both efficient and flexible. It is particularly flexible
where the display window varies in size, allowing the script to
determine for itself how many rows or columns to display.


In addition to the tabbed interface mentioned above, Ajax applications
can present regions on the page as if they were independent windows.
This is popular for portal UIs. The effect is often achieved via nested
tables and appropriate styling, coupled with visibility controls and
resizing. For example, small icons can be placed to one side of the
first row to represent minimise, maximise and close operations. In the
case of min/max operations, several Ajax applications use a timer to
generate an animated close/open behaviour. This merely involves a rapid
sequence of region resizing, and possibly some style changes. It is not
necessary for the browser to have any particular support for animation,
though experience shows that the overhead of animating via scripts can
lead to poor performance on the browser. This is especially true of less
powerful devices. Care must also be taken to avoid constant page re-flow
during animation, as this will significantly affect performance.


It is a common UI pattern to use alternative backgrounds for lists, to
act as delimiters and also to aid the viewer who has to keep track of
what's being read. These backgrounds can change colour to indicate many
things, such as priority, age, relevance etc. The colours, borders or
other style items can also change to indicate other things, such as the
fact that the user has selected or otherwise consumed the content.
Instead of making a round-trip to the server to modify the style of the
content fragment whose state has changed, a script can dynamically make
the modification in-situ.


Layouts often include a number of visual controls, including buttons,
labels, grids, panel splitters, text input cells, list boxes etc. Many
of these are supported already in the forms markup, but more complex
visual controls can be created through combination of existing display
controls and carefully controlled layout. For example, an Ajax
application can retrieve labels for form elements and display them in an
aligned layout (typically vertical). Furthermore, the style of the
labels can be dynamic, to reflect the data entered so far by the user.
For example, required fields can be highlighted until the necessary data
is in place.


The toolbar is a popular interface artefact for mainstream native
applications and is now becoming popular in Web applications. The most
complex of these can be found in Rich Text edit boxes embedded in the
browser. A script processes keyboard and toolbar entry in real time,
reflecting the result in a WYSIWYG display region. Less complex toolbars
can be found as floating elements, typically at the top of the display
where they appear adjacent to the existing browser toolbars.


Building upon the tabbed layout, and Ajax application can create a form
wizard that gathers data in stages. Between each tab of the wizard, data
can be checked and updated and reflected in the wizard. The entire
layout of subsequent tabs can be determined on the basis of data
previously entered.


Small, focussed applications can be embedded in portals/regions of the
main display. These widgets then use Ajax to operate independently of
the main page content. The technique is often used for embedded
advertising or localised information services.


To make efficient use of limited space, the layout can adjust after a
period of inactivity. For example, a complex navigation region can
collapse after a few seconds to allow more space for presenting the main
content. When the user wants to navigate, moving the cursor to the
anchor of the collapsed region will restore it. This behaviour is
different to most other approaches that cause layout changes immediately
upon some user-generated event.


One common requirement of layout managers is the ability to nest one
layout within another. This is not always considered in Ajax
applications, where it is often assumed that the whole display area is
assigned to the application, when in fact it may only occupy a portion
of the main window. The prevalence of Ajax mashups is raising awareness
of variable contexts and this should be less of a problem in the future.

- - - 

This is not an exhaustive analysis, but it suffices to establish the
role that scripting and Ajax already play in the creation and management
of Web layouts. I look forward to discussions. Meanwhile I expect this
material to move to the UWA wiki.

Received on Thursday, 11 October 2007 14:01:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:23 UTC