ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Web and Enterprise Architecture Design Patterns for J2EE, Part 2
Pages: 1, 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, 20 total
Deleted records: 0 urgent, 5 total

The user has sufficient information from the summary to make a decision. He or she will probably deal with the urgent new record first, and then tackle the modified records, because they are the biggest set.

Note the hyperlinks on the summary rows. The display uses the Iceberg pattern to lead the user to greater detail.

If the number of records in a given set is extremely large, it may be necessary to employ the Sliding Window pattern to display it when the user uncovers the Iceberg.

Consequences

The positive consequence of the Summary pattern is a well-understood, simplified interface. It is similar to the Need to Know pattern, except that its purpose is not security but data volume control. Summary information also has advantages in terms of human comprehension, quite apart from data volume control, so the use of this pattern should take into account all of those factors.

There are no real negative consequences to the pattern. There is some processing involved in calculating summary information. If this effort outweighs the savings gained by not displaying the detailed data directly, then it is probably unnecessary.

11. Search Refinement

Intent

To avoid the need for unnecessary data retrieval.

Problem and Solution

For certain kinds of user queries, where the required final response is known to be a limited set of data records, it may be worthwhile to force the user to refine their query, rather than waste effort in displaying large numbers of unnecessary data records. A simple message such as "Your query retrieved an abnormally large number of records. Please refine your query and try again" may be sufficient.

Though the Search Refinement pattern is relatively trivial, an explicit identification of this "user tuning" strategy may be in order because it is a somewhat unconventional solution.

Consequences

The main positive consequences of the Search Refinement pattern are the simplicity and elegance of the solution at the user-interface level.

The main negative consequence is the added complexity required to judge whether a query is likely to retrieve a large number of rows. In SQL terms, a select count() may need to be performed before every select in order to implement this pattern.

Conclusion

We have presented here a number of techniques that we have found ourselves using more than once in our profession as J2EE architects and developers.

Many of these are simple and obvious, but we hope that the set has value for developers in our field. We know from experience that they work well in the appropriate contexts.

We definitely see scope for more Web and Enterprise Architecture Design Patterns, as well as more categories (such as Page Layout patterns, for example). We would love to hear from other practitioners about patterns that worked for them.

We also hope that with the popularization of the patterns we have described here, web and enterprise architects will be able to discuss designs much more succinctly:

"... I suggest we make the Operations Clerk's home page a Taskmaster, with each displayed task being an Iceberg. The Operations Supervisor will get essentially the same page, with more options provided using Need to Know. I don't think there's any need for a Tour Guide, because it's a tight application with only trained internal users ..."

If our paper helps designers communicate sophisticated concepts with a compact vocabulary, reuse tried-and-tested techniques, and get to spend less time at work and more with their families, then the warm glow of satisfied pleasure will be all ours.

Ganesh Prasad is an architect with Westpac Banking Corporation, Australia's third-largest bank.

Rajat Taneja is a contractor with Sun Microsystems, Australia.

Vikrant Todankar is a senior consultant with EDS Australia, on assignment to the Commonwealth Bank of Australia, Australia's second-largest bank.


Return to ONJava.com.