Pattern Name

Cover Summary Pattern

Intent

To provide covering summary of task or goal related information, hiding away unnecessary detail which need not be accessed on most occasions.

Motivation

Often Functional or User Interface Requirements Analysis will turn up a frequently performed task which uses a subset of data. It makes sense to provide easy access to the data for this specific task with a minimum of effort. For other less frequently performed tasks the User may choose to drill down through additional navigations to find what they need.

In addition, a specific step in a collection of Use Cases may be recurring. This leads to a sub Use Case which the others re-use. They are said to << extend >> that sub Use Case. For example, Use Cases with names such as "Take an Order", "Call a Customer", "Change Customer Address" may all << extend >> a sub Use Case called "Find Customer". The "Select Customer" involves searching for a particular customer on the database, perhaps by name, date of birth, customer number or some other piece of information that the customer provides the User. [ Note: Constantine & Lockwood have also detailed "composition" where one Use Case re-uses another subcase. The difference between << extends >> or << composes >> is subtle and does not really affect the applicability of this pattern ]

When we see a pattern such as this emerging we want the User Interface to best facilitate it.

We have a commonly extended Use Case for a simple task "Select User", it is almost certainly a step within some of the most frequently performed tasks in the system. It would be nice therefore to provide an Interaction design which facilitates these most frequently performed tasks.

Selecting Frequently Used tasks

UI Strategy 2 gives us some clues to identifying the more important tasks across different users of a system. With some additional task analysis, it should be possible to determine how often these are performed. Sometimes a less frequently performed task is so important that you can ignore its infrequency of use and treat it as a frequently used one.

Constantine & Lockwood have suggested that the way forward after identifying such tasks is to write Scenarios for each task from the appropriate Users point of view. Take these Scenarios and abstract them to Use Cases and then to Essential Use Cases, on the way removing any specific interaction detail. Then analyse the collected Use Cases an extract out the subcases as extensions or compositions.

Data Required

UI Strategy 5.b suggests that we must take these tasks, particularly those minor ones identified as frequently re-used and analyse what data is required to complete the task.

For example, a minor task (frequently extended Use Case) "Select Customer" may require a search filter prompting for available input data such as Customer Name, Customer Number, Date of Birth, Date of Incorporation, Registration Number or some such. The real task is then selecting the specific customer from a list of search results. A search for a customer called "Smith" may produce many hits. How do you identify that specific Smith? This is the answer that Strategy 5(b) is requiring. For that frequently extended Use Case "Select Customer", what data is required to achieve a suitable selection? If we were building a banking application, perhaps, Date of Birth, Account Number and first line from their address.

Repeat Strategy 5(b) for the extending Use Cases, or the major frequently used tasks e.g. to facilitate sales prospecting "Contact Customer by telephone and update their details". For a recruitment agent, the goal may be to identify the latest availability date for a contractor. Hence, we have a Use Case "Get latest availability Date" which uses "Contact Customer by Phone" which in turn uses "Select Customer". This is beginning to look like a candidate for a Cover Summary Pattern. Why?

Lots of Additional Data, mostly never required

an Example scenario...

Consider the Essential Use Cases needed for this example ...

Select Contractor User Intention System Responsibility   Prompt Search Criteria Enter some search criteria     Perform search and display matching results Select a Contractor from the displayed results list   Use Case 1 Call Contractor Select Contractor     Display Phone Number Make phone call using number displayed   Use Case 2 Update Address for Contractor Select Contractor     Display Address Edit Address     Display New Address Use Case 3 Check Contractor Availability Call Contractor     Display Availability Date Edit Availability Date     Display new Availability Date Use Case 4 Update Contractor Skill Set Call Contractor     Display skill set Edit Skill Set     Display new skill set Use Case 5 The Use Case Map would look like this... Fig 1 Use Case Map

As you can see from the example, there is very little "Essential" data for most of what the User has to achieve. Sometime Larry will get lucky. He will be able to place a contractor in a job, then suddenly he needs a lot more information.

The hapless IT Bod will need to provide Larry with Bank Details, Company Name and Registration number, accountants details, perhaps lawyers details too. As time goes by IT Bod will be sending in timesheets which have to be logged and invoices. Payments will get made and Larry's back office staff have to deal with all that, but for Lyin Larry, his job is sales and he will almost never have to see those details.

Making Lyin Larry's job easier is a probable motivation for Cover Summary Pattern.

Applicability

Cover Summary is usually coupled with a basic browse pattern as shown in this example. It could be separated out on its own.

Use Cover Summary

• when a number of minor tasks identified in Strategy 5(b) are recurring as subtasks of important, frequently performed major tasks identified in Strategy 2
• when several Use Cases for frequently performed and important tasks are re-using, extending or composing the same collection of subcases
• when the Essential Use Case map shows a clear extends or uses relationship between the Essential Use Cases and a small set of subcases

Consequences

The main consequence of Cover Summary, is that it emphasises certain tasks over other ones. Its important, therefore, that the analysis, which led to the selection of the tasks to be emphasised, is accurate.

Other tasks will inevitably require additional interaction / navigation such as button presses, as they are being subjugated in favour of the tasks facilitated by the Cover Summary.

Further, it may be that the Cover Summary actually helps a specific type of User such as the recruitment agent whilst other Users such as back office staff find the Cover Summary is of no use to them and they must always navigate to the details view. In this instance the Cover Summary becomes an additional obstacle or hinderance.

Implementation

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

Basic Implementation

Fig 2 Generic Prototype Drawing

In Fig 1, we provide a basic outline of a Cover Summary. It divides into two areas: the Selection Table; and the Cover Summary panel.

Selection Table

The Selection Table is providing a means to browse. As explained before this is facilitating a very low level Use Case such as "Select Customer". In this example, 4 columns are shown on the table. The data displayed in the 4 columns is considered sufficient for a 95% (or greater) identification of the correct Customer i.e. the table facilitates the task of selecting a customer. However, it does not guarantee that the goal of selecting the correct customer is achieved. Goals and tasks are subtly different. In order to facilitate the goal of selecting the correct customer, the Cover Summary is required. This should give the User sufficient confidence that they have selected the correct customer e.g. the address and phone number are correct as well as the name, date of birth and reference number.

Cover Summary Panel

The Cover Summary Panel is providing enough data to facilitate one or more subcases, or frequently performed minor tasks such as "Check/Update Availability", "Update Address", "Update Skill Set".

Navigation Model

Shown in a UMLesque notation, the Navigation Model shows what is happening with this pattern. A Search Criteria leads to a Selection Table of results, with Cover Summary. The Cover Summary in turn composes a More Details button which will finally lead to a full details window.

Fig 3 Navigation Model

More Details Button

One of the keys to this pattern is the inclusion of the More Details Button. There will undoubtedly be requirements which are met through less common Use Cases. These Use Cases will require more information and a larger number of more complex steps. Perhaps performed by different Actors. These Use Cases may still compose or extend common Use Cases such as "Select Contractor". By including the More Details Button, the same mechanism can be used for the simpler and common tasks such as "Update Availability" and for more complex tasks such as "List Timesheets for a Contractor". The more complex one, is accessed by pressing the More Details button which would navigate the User to a general purpose, Contractor oriented screen.

The key to success of this pattern is that some tasks are being facilitated by a covering summary of information. In order to perform more complex tasks the user must open up the details by use of the More Details button. It could equally be called "Open File", or "Display Contractor File" in this example.

Specific Example: for a Recruitment Agency Application

Fig 4 Application Specific Prototype Drawing

Window Cohesion - Cover Summaries 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. Larry Constantine has published similar work in his new book Software for Use. 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.

Cover Summaries are tightly coupled to the problem domain and have poor prospects of re-use as the coupling becomes tighter. The coupling becomes tighter as we overload more and more frequently used tasks or Use Cases into the Cover Summary.

At best when a single task is being supported such as "Contact Customer by phone", we could argue that we have a Procedurally coupled Cover Summary. In general, the real benefit of a Cover Summary comes when we are supporting more than one task. When those tasks are for the same User e.g. Lyin Larry, then we might argue that we have Temporal Coupling (slightly more tightly coupled). Why? Well Lyin Larry can perform several tasks all at the same time. He can call the contractor, he can ask for the new availability date, he can collect the latest "buzzwords" for work and he can update contact details. When our Cover Summary is doing all of this, it has become truly useful but it has also become Temporally coupled and is less likely to be re-used in other applications.

We can make our Cover Summary even more useful when it starts to support tasks for several different Users, User Roles, Actors or Personas i.e. a collection of Use Cases with different Actors. As soon as we are doing this, there is no longer a temporal relationship between the data in our Cover Summary grouping, indeed their is little logical association except perhaps that the data may belong to a small defined collection of entities all related to the key which is selected when browsing the table. A Cover Summary which supports several tasks or Use Cases across several User Roles or Actors can be considered Coincidentally coupled. That is to say, very little chance of re-use in any shape or form. However, we can say that we have a designed a screen which is optimised for the problem domain and maximises Usability.

This pattern is a clear indication that the goals of Usability and good system design theory can often be opposed. In this case, a Coincidentally Cohesive design produces the best results.

Design Strategies - Selecting Data for a Cover Summary

Selecting the data for a Cover Summary is easy when you have done thorough analysis first. In practice this may not be the case. You may for example only have the notion that "Select (or browse) Customer" is commonly recurring in your design and you would like to speed common tasks or achieve common goals by providing a Cover Summary.

(i) Mandatory data

It's always a good strategy for Summaries of any kind to identify mandatory data which you must collect for business reasons or data integrity reasons. For example, if you are providing a "Select Customer" in the browsing table, then populate the Cover Summary with the Mandatory data needed for a Customer.

(ii) Most Frequently performed tasks

From User Interface Strategy 5(b), identify the minor tasks which are used frequently and then ask what data do we need to complete this task. If it can be readily accessed through a single selection or single key, such as a Customer, an Account, an Invoice, or a Product Number, then place the required data onto the Cover Summary and browse by the required key by displaying the appropriate list of Accounts, Invoices, Products or Customers on the table. For example, a task "Contact customer by telephone" would require the telephone number.

(iii) Most important tasks

From User Interface Strategy 2, identify the important tasks and pick one or several which you would like to emphasise. It may be that you cannot complete the whole task through a Cover Summary but you can significantly speed up part of the task.

Again look at whether all, or part of one, or some of the tasks can be completed by accessing data through a single selection of single key such as a Customer, an Account, an Invoice or a Product Number. A data or object model should help when doing this analysis. If the answer is Yes, then list the appropriate selection in the table e.g. Customers, Products, Invoices or Accounts as required. Then place as many related data items onto the Cover Summary as makes sense to facilitate the tasks chosen.

(iv) Several Essential Use Cases which re-use minor subcases

A more formal approach where you have first of all done a reasonable amount of requirements analysis using Essential Use Cases and have developed these into a sophisticated Use Case Model showing Inheritance, Composition and Affinity. Look for Use Cases initiated by several Actors which all eventually re-use or compose a single (or small set) of minor subcases. Look for subcases which are sufficiently granular as to be facilitated by access through a single selection or key. Again a data model or object model will help when making this decision.

Populate the table with items for selection e.g. Customers, Invoices, Accounts, Products and then place the data items required to facilitate the minor subcases. e.g. "Contact Customer by Telephone" would require the telephone number.

Known Uses

General

• Customer Relationship Management

Banking

• Loan Application History
• Loan Implementation
• Collateral Custody / Securities Deposit

Acknowledgments

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. The Use Case related material has been added to this paper after reading Software for Use, by Constantine and Lockwood.