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’b) Work items are transferred from one user to another; there are many possible schemes for this including:
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.
i) simple ‘pass it on’c) New work can arrive at any time, not necessarily in priority order.
ii) an ‘offer - accept/reject’ protocol
iii) ‘get next’ from a central queue
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.
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)
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.
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.
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.
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
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
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)