Visual Support for Work-list Assignment
Typically, PAISs use a so-called pull mechanism: work is offered to all resources that qualify and the first resource to select the work item will be the only one executing it. To allow users to pull the right work items in the right order, basic information is provided, e.g., task name, due date, etc.
However, given the fact that the work list is the main interface of the PAIS with its users it seems important to provide support that goes beyond a sorted list of items. If work items are selected by less qualified users than necessary or if users select items in a non-optimal order, then the performance of the overall process is hampered. Assume the situation where multiple resources have overlapping roles and authorisations and that there are times where work is piling up (i.e., any normal business).
In such a situation the questions listed below are relevant:
- "What is the most urgent work item I can perform?"
- "What work item is, geographically speaking, closest to me?"
- "Is there another resource that can perform this work item that is closer to it than me?"
- "Is it critical that I handle this work item or are there others that can also do this?"
- "How are the work items divided over the different departments?"
Generally, products sort the work items in a work list using a certain priority scheme specified at design time and not updated at run time. To support the user in a better way and assist her in answering the above questions, we use maps. A map can be a geographical map (e.g., the map of a university’s campus). But other maps can be used, e.g., process schema’s, organisational diagrams, Gantt charts, etc. Work items can be visualised by dots on the map. By not fixing the type of map, but allowing this choice to be configurable, different types of relationships can be shown thus providing a deeper insight into the context of the work to be performed. Work items are shown on maps. Moreover, for some maps also resources can be shown, e.g., the geographical position of a user.
Besides the "map metaphor" we also use the "distance metaphor". Seen from the viewpoint of the user, some work items are close while others are far away. This distance may be geographic, e.g., a field service engineer may be far away from a malfunctioning printer at the other side of the campus. However, many other distance metrics are possible. For example, one can support metrics capturing familiarity with certain types of work, levels of urgency, and organisational distance. The choice of metric is orthogonal to the choice of map thus providing a high degree of flexibility in context visualisation.
Resources could for example opt to see a geographical map where work items, whose position is calculated based on a function supplied at design time, display their level of urgency.
The proposed visualisation framework is based on a two-layer approach:
- The visualisation of work items based on a distance notion.
A work item is represented as a dot positioned along certain coordinates on a background map. A map is meant to capture a particular perspective of the context of the process. Since a work item can be associated with several perspectives, it can be visualised in several maps at different positions. Maps can be designed at design time as needed.
When the use of a certain map is envisaged, the relationship between work items and their position on the map should be specified through a function determined at design time. Several active "views" can be supported whereby users can switch from one view to another. Resources can (optionally) see their own position on the map and work items are coloured according to the value of the applicable distance metric. Additionally, it may be helpful to show executing work items as well as the position of other resources. Naturally, these visualisations are governed by the authorisations that are in place inside the YAWL system. During run-time the YAWL engine keeps updated about the life cycle states of work items.
Distances can be mapped to colours for work items through a function colour which associates every metric value with a different colour in the set C. In our implementation colours range from white to red, with intermediate shades of yellow and orange. When a resource sees a red work item this could for example indicate that the item is very urgent, that it is one of those most familiar to this resource, or that it is the closest work item in terms of its geographical position. While the colour of a work item can depend on the resource viewing it, it can also depend on which state of the lifecycle it is in. Special colours are used to represent the various states of the work item lifecycle. The various rows correspond to the various states and their visualisation. Resources can filter work items depending on the state of items. This is achieved through the provision of a checkbox for each of the work item states. Several checkboxes can be ticked. There is an additional checkbox which allows resources to see work items that they cannot execute, but they are authorised to see. Resources may be offered work items whose positions are the same or very close. In such cases their visualisations may overlap and they are grouped into a so-called "joint dot".
An Example: Emergency Management
In order to clarify our framework, we are going to illustrate a number of features of the visualisation framework by considering a potential scenario from emergency management. This scenario stems from a user requirement analysis conducted in the context of a European-funded project, namely WORKPAD.
Teams are sent to an area to make an assessment of the aftermath of an earthquake. Team members are equipped with a laptop and their work is coordinated through the use of a PAIS. The affected area is broken down in patches. For each of them a workflow has to be carried on in order to assess buildings, which could collapse, in such an area.
This workflow comprises process Disaster Management as main. The first task Assess the affected area represents a quick on-the-spot inspection to determine damage to buildings, monuments and objects. For each object identified as worthy of further examination an instance of the sub-process Assess every sensible object is started as part of which a questionnaire is filled in and photos are taken. After these assessments have finished, the task Send data to the headquarters can start, which involves the collection of all questionnaires and photos and their subsequent dispatch to headquarters. This information is used to determine whether these objects are in imminent danger of collapsing and if so, whether this can be prevented and how that can be achieved. Depending on this outcome a decision is made to destroy the object or to try and restore it. For the purposes of illustrating our framework we assume that an earthquake has occurred in the city of Brisbane.
The figures below show different maps where dots refer to work items or resources. Dots for work items are coloured with respect to the distance metric which users are currently chosen.
Figure 1 shows the main process of the Disaster Management workflow, including eight work items. Dots for work items which are instances of the tasks Assess the affected area and Send data to the headquarter are placed on top of these tasks in this figure.
No resources are shown in these diagrams since positioning work items in a "Process" Map is believed not to make sense. Note that on the left-hand side is shown a list of work items that have no position the map. Specifically, they refer to work items whose corresponding tasks are not part of workflow Disaster Management. Figure 1 uses the familiarity metric to highlight cases closer to the user in terms of earlier experiences.
As another illustration consider Figure 2 where work items are positioned according to their deadlines. This can be an important view in the context of disaster management where saving minutes may save lives. In the map shown, the x-axis represents the time remaining before a work item expires, while the y-axis represents the case number of the case the work item belongs to. Here we have also clicked on a specific dot to obtain other information of the corresponding work item. A dot that is selected as focus obtains a blue colour and further information about the corresponding work item is shown at the bottom of the screen.
Figure 3 shows some screenshots of a geographical map of the city of Brisbane. On these maps, work items are placed at the location where they should be executed. If their locations are so close that their corresponding dots overlap, a larger dot (i.e., a joint-dot) is used to represent the work items involved and the number inside corresponds to the number of these items. The green triangle is a representation of the resource whose work list is visualised here. Work items for tasks Assess the affected area and Send data to the headquarters are not shown on the map as they can be performed anywhere. In this example, dots are coloured according to the familiarity distance metric. One can click on a dot and see the positions of other resources that have been offered the corresponding work item. For example, by clicking on the dot representing the work item Take photo_4, other resources, represented by triangles, are shown (see Figure 3a). As for work items, overlapping triangles representing resources are combined. For examples, the larger triangle shown in Figure 3a represents two resources. This component provides also a zooming feature in order to make split joint-dots. Figure 3b shows the result of zooming in a bit further on the map of Figure 3a. As can be seen, As can be seen, neither dots nor triangles are overlapping anymore.
Figure 3b shows also what happens after clicking on a triangle representing a resource (specifically resource leader). Clicking on a triangle causes work items offered to be seen. The colour of these work items is determined by their value for the chosen distance metric. A zooming feature is also provided.