Pattern Name

Summary Tab Pattern

Intent

To facilitate goal oriented access to a collection of otherwise functional data

Motivation

When a Tab Pane or Notebook control is used to present data about an entity, the tabs are often (arguably always should) be functionally organised. For example data about a Person may be divided into tabs for Address, Employment, Family, Education, Points of Contact, Personal Biographic Details (such as Date of Birth).

For many data reading tasks, this functional organisation is not conducive to speedy completion of a task or achievement of a goal because the user needs to see data from several tabs all at the same time. The same can also be true of data capture under certain circumstances. Let's take a look at data reading and data capture separately.

Data Reading

When a User only has a requirement to read data, rather than capture it, we must examine the purpose for reading. The data is being read in order to facilitate the achievement of a goal or the completion of a task. The purely functional data, across several tabs could be used for this purpose. However, this is problematic. It assumes that the user knows what to look for and it forces the user to browse across tabs in order to proceed. This involves the user in some short term memory application as all of the required data is not on screen together.

The simple solution to this is to present that data together on the Summary Tab. However, it is important to have a deeper understanding of the motivation for the summary grouping.

Have you grouped several items because several small grained tasks must be performed sequentially? If so, do they really need to be on one tab or could the user flip tabs as they complete each fine grained task?

Have you grouped the data items because they are all needed in order to complete a single procedure? A better choice for a Summary Tab.

Have you grouped the data items because they are needed for several tasks or procedures which need to be performed at the same point in time? Another strong motivation for Summary Tab.

Have you grouped the data items because they are needed by the same Role Player, or User across the lifespan of the application? Implying that the grouping helps the User find what they might need but does not aid in performing any specific tasks or achieving any specific goals.

Understanding precisely which motivation was used for grouping data on a Summary Tab is important. It gives an indication how tightly coupled the design is to the specific domain problem. Indicating whether there is any chance for re-use of the tab.

Applicability

The Tab Pane may be used within a Chessboard Layout as a third tier of menu selection, or within a dialogue as a single tier of organisational structure. Regardless of how the Tab pane is deployed, it ought to be possible to determine the User Goal or Task to be completed when the Tab Pane is encountered.

Use Summary Tab

• when a specific user goal can be anticipated due to the context of the screen in use at a given time or system state
• when data reading is done more often than data entry
• when different users read the data from those who enter the data
• when there is a sub-set of data which is mandatory and you wish to speed data entry

Consequences

The main consequence of Summary Tab, is that an extra tab needs to be developed, involving more work and more testing. The nature of summary tab means that data is being duplicated or de-normalised (if you speak Database design). This has the impact that you introduce a requirement to "notify" between tabs, introducing a UI plumbing code requirement for publisher-subscriber type code patterns.

A second consequence is that the UI Design is being specialised for a task or user. This may mean discriminating against other users. The designer must be confident that the gain from use of the Summary Tab is far greater than any potential loss or discrimination against other users or tasks.

Implementation

We take a look at how Summary Tab Pattern is implemented.

Basic Implementation

Fig 1

In Fig 1, the 2nd and subsequent Tabs are functionally organised. The leading Tab is providing the Goal or Task related Summary. It only provides the data relevant to the completion of the goal or task.

Window Cohesion - Summary Tabs are more tightly coupled

In his book on GUI Design David Ruble introduced a notion of Window Cohesion based on the original work by Constantine and Yourdon on Code Cohesion. Window Cohesion helps us to understand the coupling of any Window or View to the system we are building. It is a measure of the reusability of a given view. Functional Views are loosely coupled. They have the most opportunity for re-use. This would be true of the simple example here. The Address Tab is functional and could be re-used within the same application or across many others. This would be true of any of the functional Tabs for Personal Details. Points of Contact, Employment, Family, Biographic Details (such as Date of Birth) all represent individual views which are loosely coupled and easily re-used across applications.

Design Strategies - Selecting Summary Tabs

So how do you select candidates for Summary Tabs and what data, information or controls should go on a Summary Tab?

(i) Mandatory data

Instead of forcing users to browse across several tabs in order to enter mandatory data fields, duplicate them onto the summary tab at the front, allowing minimal data entry using only one tab an maximising operator speed. This usage would be considered Logically Cohesive and very tightly coupled to the application problem domain

(ii) Business Decisions

In a collaborative working application, more senior users often require a subset or summary of data in order to make a business decision. This is a case where the data reading task differs from the data entry task. Use User Interface Strategy 9 to identify suitable business decisions. Use UI Strategy 10, to identify collections and constituent parts, or sub-decisions.

Consider taking the data necessary for the decision making and placing it together on the front tab. Or across several constituent parts or sub-decisions, consider providing a summary tab at the front of each collection or constituent part data. For example in a banking application, separate out the loan product information from the securities information and provide summary tabs for both.

This allows the senior user to browse data and perform a task such as making a decision without having to browse through the hidden tabs.

(iii) Procedure Summaries

Consider providing a summary tab which indicates the status of a procedure. For example, several tabs of data may be used throughout the performing of a business procedure, perhaps collaboratively between users. It may be necessary to see at a glance what stage or status the procedure has reached. Consider taking the vital data for a procedure and display it together on a single summary tab. You can identify such procedures from UI Strategy 11. Such a Summary Tab would be considered as Procedurally coupled.

This technique is particularly useful for a-synchronous tasks within a procedure. Each task can be given a tab and those can be completed in any order and perhaps by several users over time. The summary tab will tell users at a glance what has been completed and what has still to be done.

Known Uses

General

• Customer Summary

Banking

• Loan Application Summary

Acknowledgments

I don't claim to have invented Summary Tab Pattern, 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.