Pattern from Peter Windsor

Pattern: Work Queue

aka Ticket List, Strip Bay


The users’ tasks are to process ‘items of work’ each of which is represented by an object in the system.  Characteristically:

a) Each work item is ‘owned’ by one user, but others may ‘have an interest’ in it.

b) Each user may have a specific ‘function’ or ‘area of responsibility’; for example:

i) one user is the ‘allocator’, other users are ‘processors’
ii) the work is to manage ‘traffic’, each user ‘controls’ a geographic area and the work items are permissions to pass through the area.
iii) each user has a different speciality; for example the work is publishing, the specialities include author, editor, proof reader, typesetter, printer.
b) Work items are transferred from one user to another; there are many possible schemes for this including:
i) simple ‘pass it on’
ii) an ‘offer - accept/reject’ protocol
iii) ‘get next’ from a central queue
c) New work can arrive at any time, not necessarily in priority order.

d) A user may have to perform several actions for each item but cannot always do all the work for one item before proceeding to the next.

e) There is substantial data associated with each item, some of it ‘global’, some of it unique to an individual user’s responsibilities.

f) The data and state of an item can change asynchronously.


Examples of this pattern include:

a) Displays of service calls in a help desk system

b) Displays of pending calls in a call centre

c) ‘Strip bays’ in air traffic control

d) Document lists in an intelligence gathering system

e) Orders in a kitchen (classically implemented with raffle tickets)


The solution to this problem is to represent each work item as a ‘ticket’ or ‘strip’ and to organise them into ‘bays’.  The following sections explore the major design choices within this solution.

How Many Bays?

The set of bays needs to match the work flow.  The main schemes are:

a) A shared central bay for ‘un-allocated’ items, each user has their own bay for their current work.

b) An allocator has a bay of ‘un-allocated’ items, each user has a ‘pending’ bay of newly allocated items plus an ‘active’ bay of work in progress

c) Each user has an ‘offered’ bay for incoming work, an ‘accepted’ bay for current work and a ‘finished’ bay for recently completed work.

How to Order Items Within a Bay

The ordering of items within a bay also needs to match the processing.  The main schemes are:

a) If there is a simple priority order, sort by priority

b) If the items have ‘states’ which affect which tasks can be performed, group items by state

c) If there is a ‘problem solving’ aspect to the processing, group items to show patterns pertinent to the problem (eg group traffic following the same route).  For some problem solving cases (eg in air traffic control), it is necessary for a single item to be represented by multiple strips.

Generally, there is no ‘best’ order and so the preferred design allows the user to choose between sort orders.

If an item’s data can change such that its position in the bay should move, consider whether the sort order should be updated automatically or whether it should wait until requested by the user (with some notification that the change has occurred).  If the users are routinely interacting with bay, the latter is preferred to avoid strips moving just as a user tries to interact with them.  A sophisticated solution to this problem is to identify those user inputs that cause the strips to move and cause re-sorting to occur as part of that processing.

Incoming and Outgoing Work

If the users are routinely interacting with a bay, it is important that the system does not move the strips autonomously (or at least to minimise when that happens). Otherwise the system will be liable to errors due to the strips moving just as a user tries to interact with them.

For incoming work, ie when strips need to be added to the bays, possible approaches are:

a) Always add new strips to the ‘end’ of the list; they can be moved to their ‘correct’ position at the next re-sort.

b) Have a separate ‘pending’ section at the end of the bay for new strips; new strips are then moved into the body of the bay by the user

c) Have a separate bay for new strips that the user does not normally interact with (eg an ‘offered’ bay); strips are then moved to the ‘working bay’ by the user.

For outgoing work, ie when strips need to be removed from the bays, possible approaches are:

a) If the user can simply pass an item on to the next person, remove the strips immediately

b) If items become ‘completed’ asynchronously (eg when another user accepts an offer), and the current user still needs to interact with them, mark the strips as ‘completed’ and then have them removed either explicitly by the user or as part of the next re-sort.

c) If items become completed asynchronously and the current user does not need to interact with them further, move them to an ‘outgoing’ bay when the user passes them on and automatically delete them on completion.
Information Management

The selection and arrangement of data on the strips is not considered in detail here.  However, note that as well as the data that is directly pertinent to the task it is often important to include identification / contextual data that helps the user discriminate between items and recognise patterns across them.

Typically there will be too much data for permanent display.  There are two information management techniques we use with this pattern:

a) Provide two or more strip formats between which the user can select.  Eg ‘full’ (multi-line) and ‘collapsed’ (single line) formats.  A variation on this has the system select which form based on the state of the items (this too can be a user option alongside options that use one format for all strips in a bay)

b) ‘pop-up’ to request full information for a single object

Changing Data

When the data associated with a work item changes, how the new data should be presented depends on its relevance to the user’s tasks:

a) Non-critical data can sometimes be updated directly without additional feedback (as the user may be relying on contextual data to re-inforce identification, this is not recommended in general)

b) Changes that the user should notice, but which do not demand immediate attention, can be applied directly but displayed with a low priority highlight, eg make text ‘throb’ between black and grey.

c) If the user needs to continue with the old data or otherwise explicitly see the change, mark the strip as having pending changes, but do not update the display until the user requests it.

d) If the changes should get the user’s attention, make the changes immediately use a strong highlight, eg colouring the background to the affected area.


This is expensive to implement.

The detail of the solution can be highly sensitive to the work flow.  Thus it is important to evaluate the proposed design thoroughly (preferably through a working prototype).  Further, it is likely to change during the lifetime of the system, so it is desirable that the implementation is flexible (although that can conflict with achieving satisfactory performance).
Interaction with the work items is not addressed here.  Key questions are:

a) what actions through direct manipulation, which through more indirect methods

b) what ‘focus’ / selection to support (eg single vs multiple selection)

c) trade off between context sensitivity and consistency (eg if a pop-up menu is provided, is it context sensitive or is there a standard menu with enabling / disabling)

Related Patterns

Ticket List is a form of High-Density Information Display.  It has some common elements with Series of Small Multiples.  It uses Optional Detail on Demand.


An example pattern prepared for the Usability Pattern Language Workshop at Interact '99