Web and Enterprise Architecture Design Patterns for J2EE, Part 2
Navigation Patterns
Navigation refers to the way in which the user moves through the screens of a web application.
6. Tour Guide
Intent
To provide an explicitly recognizable navigation mechanism for novice users.
Problem and Solution
A Tour Guide is our name for any set of components whose existence is explicitly for the
purposes of helping a user navigate an application. Menus are the best example;
tree-structured outliners are another. Hyperlinks can be Tour Guides, too,
if they stand "outside" of the data (i.e., a hyperlink that says Click here).
The Tour Guide pattern is useful when navigation components must be explicitly identified
as such. It is recommended for applications with a large number of casual
users, who may not be familiar with the logic of the application.
Consequences
The positive consequence of the Tour Guide design pattern is that the application is
readily understandable, even to casual users.
The negative consequence of the pattern is its "kludginess." Any navigation scheme that
does not weave itself into the natural fabric of the application by linking
data items naturally to one another is, in a sense, redundant and ugly. The
justification for this criticism will become clear when we discuss the Iceberg
pattern.
7. Iceberg
Intent
To present application data in a naturally linked fashion for intuitive traversal.
Problem and Solution
Consider a hypothetical Internet home banking application.
The user logs in, and sees a list of their accounts with the latest available balances. Each of the account names is a hyperlink, and clicking on any one displays a screen with the
details of that account, including, say, the overdraft limits applicable.
The current and available balances are displayed in a totals row, but the
rows above it are shown collapsed into a "transactions" row in a way that
invites the user to click to expand it. When clicked, the screen refreshes
to display the last twenty transactions that resulted in the previously shown
current and available balances. This is the transaction history. Clicking
on any transaction record brings up more details about that transaction, and
so on.
Navigating backwards is just as natural. Every screen displays the customer's name and (if applicable) the account name. Clicking on the customer's name takes the user back to the
home page that lists all of the customer's accounts. Clicking on the account name takes the user
back to the account details page.
What is important to note is that there is no explicit navigation component in this application -- no
menus, no special links. Moving through the various screens of the application
is naturally tied to the data items displayed, because that is how a user
would logically traverse this data.
Our name for this pattern
is Iceberg, because each piece of data displayed as a link hints at the greater
detail that lies underneath.
Consequences
The major positive consequences of
the Iceberg design pattern are elegance and economy. An application designed
with this pattern shows a deep understanding of the way its users actually
work with data. It shows that rather than "cop out" with a cookie-cutter design
that classifies all its functions under menu items and displays a weak home
page, the designers have taken the pains to identify the central focus of
the user and display that data in their home page. The paths to all secondary
data items flow from the data items on this page.
The pattern's very sophistication
can lead to some negative consequences. Novice users may find themselves asking,
"Where's the menu? Why doesn't this screen tell me what I can do?" Clearly,
the Iceberg pattern is more suitable for tightly integrated applications
with trained users. The natural and intuitive flow provided by the pattern
will deliver productivity payoffs in such situations.
Most often, consciously
or otherwise, designers provide both Tour Guide and Iceberg elements for navigation.
This redundancy seems to be beneficial, as it supports novice users as well
as more sophisticated ones. Applications employing metaphors may also end
up using both Tour Guide and Iceberg elements.
8. Taskmaster
Intent
To coordinate and guide user actions so as to maximize system efficiency.
Problem and Solution
An unseen factor
in user interface design is management policy. Should the user be in control,
or should the system tell the user what to do? This dichotomy often appears
in systems with both clerical and executive users. Executive users like to
be in control. They like to be able to direct the system and break away at
will from set ways of looking at data. Interestingly, executive users also
provide the requirements specifications that say how clerical users must interact
with the system. The leeway given to clerical users is normally much lesser
than that enjoyed by executives.
In such cases, the system displays the data that the users are deemed to need at the time,
and nudges them in the direction of the actions they must perform. Little
user discretion is possible in such applications.
Consider a hypothetical system where clerical users have two main functions: data entry and reconciliation.
Reconciliation consists of matching different data records that were previously
entered. Both data entry and reconciliation need to proceed at a more or less
equal pace to achieve optimal transaction throughput, although reconciliation
requires a certain number of records to be entered first.
On first logging in, users are shown data entry screens, which keep redisplaying blank forms
as earlier data is saved. At a certain point, the system determines that a
sufficient backlog of data has built up to enable reconciliation to begin.
Some users may now find their screens refreshing to display reconciliation
functions. They therefore find themselves being nudged in that direction, with the
system maintaining the balance of the two functions to maximize throughput.
The users have little discretion in their navigation of screens.
This is an example of the Taskmaster pattern, and is applicable whenever user actions have to be
guided in a desired direction, rather like sheep being shepherded into paddocks
by sheepdogs. It is particularly relevant when the system as a whole is the only
entity that has the overall profile of the users and current data, and is the only
one capable of determining the most appropriate tasks to be performed next, i.e.,
for applications requiring load-balancing across users.
The lack of user choice need not be total, merely constrained.
For example, users could be shown a set of records and required to choose
any one from the displayed list.
Consequences
The main positive consequence of the Taskmaster pattern is increased efficiency -- factory-floor, assembly-line efficiency.
There are no real negative consequences to the pattern, if used judiciously. Clerical users with transaction targets are often grateful to be relieved of choice. As long as the decisions
are being made for them, their job is made easier.
Data Volume Control Patterns
Inadvertent queries that retrieve huge amounts of data are a potential problem, and not just because they may display pages a mile long. Runaway database queries can bog down
the server, choke the network, or both. Some mechanism needs to be put in
place to ensure that only sane amounts of data get sent back to the client
for display.
The following are some of the patterns that can be used to implement data volume control.
9. Sliding Window
Intent
To reduce the impact of large queries on the overall system.
Problem and Solution
Any user of a web-based email program understands this pattern. The user is shown a list
of, say, the 20 most recent messages in their inbox, with links provided to scroll
back to earlier messages. On following this link, a similar page with the
previous 20 messages is shown, and the user now has the option to scroll further
back or scroll forward to the original set.
This is a pattern that affects not only the user interface, but also the entire data retrieval logic.
The server is "throttled" to force the retrieval of only a subset of the total
number of data records to be displayed. The subsets are usually distinguished
by the identifiers of their first and last records, or some suitable surrogate,
and these identifiers are used to control which records to retrieve next.
Borrowing a term from networking theory, we call this the Sliding Window pattern.
Consequences
The positive consequence of the Sliding Window pattern is that the application gains a readily understood mechanism to control data retrieval.
The negative consequence of the pattern is its complexity, as compared to a straightforward retrieval of all records. It is therefore probably unnecessary when the likely number
of records to be retrieved is manageable.
10. Summary
Intent
To reduce the impact of large queries on the overall system while providing simpler information to guide user actions.
Problem and Solution
The previous pattern (Sliding Window) breaks up a record set into chunks at the same level
of detail. But it is possible to reduce data volume by summarization as well.
For example, consider a Taskmaster screen that displays new, modified, and deleted records
for action by a user. The user has to choose a record from one of these three
sets and proceed with an appropriate action. In making this decision, the
user should be guided by the number of records marked "urgent," as well as
by the total number of records in each set. Clearly, it is unnecessary to
display the complete listing of all three sets in such a case.
What the user
needs on this screen is a set of summary rows that look something like the
following:
New records: 1 urgent, 10 total
Modified records
: 0 urgent,