Pattern Name

Chessboard Layout Pattern

Intent

To provide a 2 dimensional, a-modal, visible navigation space ideal for novice or occasional users.

Motivation

A multi-screen GUI has become a favourite amongst designers aiming at a wider and less experienced user community. It is widely held that multiple overlapping windows can be confusing and visually cluttered for the novice user.

Another common motivation is that a predominantly data intensive business application must provide simple, fast and by implication "a-modal" navigation across large sections of the problem domain. This is a common requirement when user task analysis and interviews indicate that the user is often interrupted or must frequently switch between incomplete tasks. It is also common to prefer an a-modal design when it is impossible to predict in advance what the user will prefer to view and when. Particularly true of applications for the World Wide Web where the user community can be unknown or undefined and prior research into their needs and preferences has not been done.

It is proposed to provide a single (almost) full screen presentation of a single view, whilst allowing the user to quickly navigate to other related data through no more than two mouse clicks / navigation choices or selections.

Chessboard Layout provides a simple two dimensional navigation where the problem domain has been divided into approximately 64 (or less) views for visual presentation. That is to say that a two dimensional structure is being provided which provides for approximately 8 first choice i.e. 7 +/- 2, followed by approximately sub-divisions of those top level choices i.e. 7 +/- 2 second level choices.

Hence the name chessboard. The problem domain is divided into approximately 8 x 8 squares where each square on the board represents a screen to be displayed. This provides for simple, fast a-modal navigation around a large data set.

Applicability

Use Chessboard Layout

• when the audience can be / is novice or occasional users
• when there is a need to provide a-modal navigation from any part of a data set or application to any other part with a minimum of effort
• when the data, tasks or system goals can be broken down into a simple two dimensional hierarchy

Consequences

Maximum of 3 tiers. The main consequence of using Chessboard Layout pattern is that you are constricted by a 2 dimensional hierarchy for the application. This may prove troublesome, if the domain is large. A third dimension of navigation can be added by introduced a tabbed pane within a screen, this is presented in another pattern white paper. However, the designer is really restricted to 3 dimensions. This is not appropriate for every design problem.

However, a maximum of three layers of hierarchy does focus the designers mind on appropriate data and task groupings. Three levels of menus has been shown in studies to be an effective maximum. Two layers is even easier for the user.

Number of choices is limited by the display space available. A further consequence is that the number of choices at each level is restricted to approximately 8. Recent studies have shown that it is better to increase the number of choices at the first and second level rather than exceed 3 levels of menus. I would advocate that this is good advice. I would further suggest that the number of choices is restricted by the visual space available. In other words, approximately 8 choices can be made to fit on a typical 800 pixel wide display. Perhaps as many as 15 choices can fit into a 600 pixel deep display (or more if you only use text). Therefore, there is some flexibility. However, it is fair to say that a consequence of adopting a Chessboard Layout is that the number of navigational choices is limited by the visual area available as those choices must fit and look appropriate in the space provided.

In summary, Chessboard Layout puts the onus on the designer to devise an effective 2 (or 3) levels of hierarchy for the menu selections. The designer is forced to put in more effort in order to simplify the task for the user. Designers might like to try using User Interface Analysis strategies in order to develop ideas for the navigation choices within a Chessboard Layout.

Implementation

We take a look at how Chessboard Layout pattern can be implemented and how it can be developed with a third level of hierarchy.

Basic Implementation

Fig 1

In Fig 1, we show the top level choices as a bar down the left hand side. Personally, I prefer the choice of the top level menu options as a vertical bar, however they could equally be horizontal instead. Selecting an option from the top level has the effect in this example of producing a selection bar across the top of the viewing area. Almost certainly there would be a default selection such as 3.1 above. The User may select any of the available 2nd level options from the horizontal bar. The result is that the rest of the screen is filled with data and navigation options related to that choice. In Fig. 2 I show how a final Chessboard Layout might look for a banking application.

Fig 2.

Introducing a third tier

In Fig 3, I introduce a tab pane within the selected screen. This provides a convenient 3rd tier to the navigation hierarchy. I believe that 3 tiers is the realistic maximum if you selected to use a Chessboard Layout. The introduction of the tab pane is really an addition or supplement to the basic pattern. Subdividing a selection bar button with tabs could be described as a second pattern which is added to the first, Chessboard Layout. This composition of patterns and recognising which ones work together in a complimentary fashion is important.

Fig 3

Design Strategies - Populating the navigation options

So how do you select the navigation choices for the chessboard layout?

In my paper on User Interface Analysis, I highlighted a number of strategies for analysing the problem domain from a User Interface perspective. Many of these strategies were aimed at highlighting key navigation choices for the interface. So now let us consider some design strategies for Chessboard Layout.

(i) Role Players as a top level choice

From Analysis strategies 1 & 4 we can compile a list of the key role players for the system. Why not take those and make them the top level choice. For example, Salesman, Warehouse Clerk, Accountant, Sales Manager. You might then consider using the sub-category of verbs for the 2nd level navigation e.g.Warehouse Clerk would have Dispatch and Receive selections for the 2nd level.

There are some limitations with this approach. Its very oriented around jobs or roles and may lead to an overly simple interface and require 3rd and subsequent layers of navigation choices.

(ii) Choose actions as top level choices

From Analysis Strategy 2, select the actions or verbs as the top level choices. It is likely that the "most important" actions will turn out to be the business transactions involved e.g. "make sale" / "sell". You can use nouns they act upon as a 2nd level choice or merge a verb-noun combination into a top level choice and then sub-divide by stages of the transaction or parts of the noun involved. This leads into the 3rd strategy.

(iii)Choose Collections or Histories as a top level choice

From Analysis strategies 6 & 7 we identified collections in the domain. It is likely that many reports, views, interactions, updates and analysis will happen across collections of data. They make logical choices for top level selections. The collection is essentially a container of items and containers make good choices as it is easy to scope transactions around them.

Consider verbs which act on the selection as 2nd level choices, or periods of time e.g. this month, last month, last quarter ..., or different types of data within the collection. Any of these may make appropriate 2nd level choices.

(iv) Choose Business Decisions as a top level choice

From Analysis Strategies 9 & 10, we identified the important business decisions which get made using the proposed system and identified the roles which interact to make the decision as well as the things which are involved in making the decision. Try making Business Decisions the top level choice and sub-categorising by things involved. This is my favourite strategy for populating a Chessboard Layout. With the DDD Co. example, we would get

• Approve Credit (top level)
  • Business Background
  • Financial Statements
  • Credit Agency Report
  • Order Value
  • Business Plan

(v)Mix Design Strategies (i), (ii), (iii) and (iv) for best results

As you will see from Fig 2. In order to get a nice balanced result with approximately 8 top level choices with a reasonable number of 2nd level choices for each, it is often necessary, even best to mix strategies.

Known Uses

General

• Web sites e.g. www.studioarchetype.com
• Transaction Worker Applications
• Hot Java Views

Acknowledgments

I don't claim to have invented Chessboard Layout, though I have used it often. I would like to acknowledge that Jeff De Luca helped me to focus and develop the formal presentation of this pattern and realise the motivations and consequences. Since developing the User Interface Analysis Strategies, I have browsed many web sites which use chessboard layout and realised that the designer was applying much of what I was expressing formally.