The task within which a resource is used is a very important element for the definition of Contextualised Attention Metadata. In this paper we discuss the requirements of a task model that allows representing current and potential attention allocation of the user. And we discuss how such model has been implemented in the AtGentive system.
Task models represent a very important element in the definition of Contextualized Attention Metadata (CAM). As CAM aims at tracking resources usage, identifying the specific context in which such usage takes place enables a much better understanding of the value of each resource [10]. The task within which a resource is used is a very important element of such contextual definition. For example, in order to truly understand resource usage it would be important to distinguish whether a user accesses a book review because he is writing a research paper, or because he is preparing a reading list for a course, or because he is selecting gifts from a wedding list. These three types of usages correspond to access to the resource book review in the context of different tasks. The definition of users' tasks is therefore one of the essential elements for the identification of the context of resource usage.
Modeling user tasks in a manner that is both complete and operational is far from being an easy undertaking. Based on the work done in the Atgentive project [2,16,17,19], this paper discusses how tasks may be modeled in order to support the implementation of attention management services. In the process we will also highlight another important relation between CAM and task modeling, i.e. the fact that not only (as mentioned above) tasks may be associated to resource access, but also resources may be associated to task descriptions.
In the context of the Atgentive system a task represents the target of an attentional focus (e.g. writing a paper, accessing some resource, ...). Since we aim at applicability in combination with a number of different types of applications, the key design issue with the definition of tasks has been to make it as application independent as possible. In particular, the questions of task granularity, task structure, and task attributes, have been addressed.
In section 2 we give a brief description of the Atgentive system. We summarize the goals of the project, introduce the different modules of the system, and explain how the Reasoning Module provides functionalities supporting users' attention allocation. The analysis of such functionalities has provided us with the most critical requirements for the AtGentive task model. Whilst the AtGentive System aims at providing many task-oriented services, in this paper we concentrate only on those that support interruption management and task switching. In section 3 we discuss the requirements that these services impose on task modeling, section 4 briefly overviews the issues commonly encountered in task modeling, and section 5 details the AtGentive task model.
The objective of the AtGentive project is to investigate the use of artificial agents for supporting the management of the attention of young or adult learners in the context of individual and collaborative learning environments.
The AtGentive system observes the user's activity and generates interventions aimed at supporting his/her attentional choices. Such interventions may either be designed to help users sustaining their current focus of attention (e.g. help user to find the best way to complete a task), or they may be designed to shift the user's attention to a different focus (e.g. communicate important information that has become available).
The main components of an AtGentive system include: one or more (1) applications, and (2) user tracking components providing information about the users activity, both these types of components communicate with (3) a reasoning module -see figure 1. Applications, users, and tracking modules inform the reasoning module about the state of the user and the environment by generating events. The reasoning module supports the user in his attentional choices by generating interventions that are then sent to the user.
Events generated by the application either describe the user activity (e.g. the user has started working on a certain task) or relevant changes in the environment sensed by the application (e.g. new information is available that the user could access).
Events generated by users may describe their preferences (e.g. "don't interrupt me when I am working on this task"), or provide a direct feedback on the reasoning module's interventions.
Finally, The tracking devices monitoring the user physical state and activity may generate events describing for example the user keyboard activity, the level of noise in the room, or the presence (or absence) of the user from the screen.
On the basis of these events the reasoning module (which is implemented as a multi-agent system) tracks what the users current focus is, creates a list of possible alternative foci, and finally, evaluates those alternative foci and, using interventions, communicates those foci (if any) that seem to be most beneficial to support the user attention.
While processing events, the reasoning module maintains an optimized list of foci that have been identified as most relevant for the user. Each focus is composed of a target, a priority, and a state. Possible states are: current, inactive, or suspended. Normally one of the foci is active (this is the user's current focus). Suspended foci are inactive foci that have been previously active. Inactive foci are those that the reasoning module has evaluated as interesting for the user but the user has never activated (e.g. the focus associated to an email that the user has not yet read). The priority is an estimate of how important/urgent the task associated to the focus is for the user. The target of the focus is either a user task or a message. A user task is an instance of a generic task for the specific user in the specific situation (see section 5.1). A message is something that needs to be communicated to the user without any concrete actions related to it, e.g. some motivational feedback for a learner who has completed an assignment.
The reasoning module is designed as an application independent, general purpose entity capable of generating suggestions about attention management. Within the AtGentive project the reasoning module is being tested in the framework of two different applications: AtgentSchool, and AtgentNet. AtgentSchool is an eLearning platform for elementary school aged children, and AtgentNet is a virtual community platform supporting knowledge exchange in knowledge communities.
In the context of the AtGentive project we have identified several task-oriented services aimed at supporting learners and knowledge workers in environments characterized by frequent interruptions and multi-tasking. These include: interruption management, support to task switching, orienteering within resources (e.g. searching and ranking), and self and community awareness.
For sake of brevity, in this section we only discuss the first two services with the aim of detecting the characteristics that a task model should have in order to enable the implementation of such services.
Interruption management services are services that may either automatically select the time and mode of the interventions that have been generated , or may provide notification services that help the user making the decision on when to attend newly available information.
With respect to interruption management, the task model should enable reasoning about cost/benefits of interruptions and allow determining the most appropriate time for interruption.
In order to decide whether to interrupt a user, the system must be able to consider the costs / benefits of the interruption.
For example, the system could decide to intervene and suggest that the user attends some newly available resource if:
[a] the resource is relevant to the task currently in focus or [b] the resource is relevant to an inactive or suspended task with a high priority Note that a resource may be relevant to a task both if it is relevant to the task or if it is relevant for a sub-task of that task.
Further considerations may intervene if enough knowledge about the user tasks is available. For example, in case [b] notification may be delayed if the user is about to complete the current task.
Observatory studies report that returning to long term projects is particularly challenging and makes such tasks potentially more vulnerable to the harmful effects of interruptions, compared to more common, shorter tasks, such as writing e-mails [7]. The expected time that a task on average takes to complete, the number of subtasks, and the number of windows and resources that need to be available, could help determining if a task is a long term project and hence, interrupting it is more costly than interrupting some shorter task.
Following the above considerations, in order to reason about costs/benefits of interruptions, a task model should allow identifying:
[REQ 1]The user's current task [REQ 2]The priorities of the current task and of other (inactive or suspended) tasks [REQ 3]The resources that may be relevant to a task [REQ 4]The advancement state of tasks execution
Several studies have demonstrated that the exact time when an interruption is presented may make a very significant difference on both how easily the information presented is acquired by the user, and on how much disruption it generates in the task being interrupted [1,6].
In order for the system to determine the most appropriate time for interruption, the task model should support the [REQ 5]Description of task hierarchies.
As noted by Bailey et al. [4] when tasks are organized into hierarchies the task model can be used to infer "breakpoints" i.e. times when interruptions are less disruptive for the user. Bailey and his colleagues [1,5] represent tasks as two level hierarchies composed of coarse events further split into fine events (for example, a coarse event would be the selection of the email application, which would then be further decomposed in selecting the email application, typing in the username, and typing in the password). The authors then measure the impact of interruptions as they occur at various points within these hierarchies and demonstrate that the best times for interruptions correspond to coarse breakpoints. The availability of such a hierarchical task model enables the system to infer the best time for interruption. In the AtGentive system, when there is a switch in the users current task, the magnitude of the break in attention is evaluated on the basis of the depth of the task in the task hierarchy. Further, a shift to the next subtask can be identified as a low strength break in the users attention whilst a jump to a task that is not a child or a parent of the current task may be interpreted as marking a stronger break in the users attention.
If tasks are organized so that lower level tasks divide a higher level task into logical sub-steps, the level at which a task switch to a next subtask happens may be used to infer the magnitude of the break in the users attention, possibly with a more accurate value. A switch at a lower level marks a smaller change in attention than at a higher level. This would however need the task model to allow specifying if a task does indeed refine the parent task or if the parent task exists just to group subtasks, as could be in the case of a math exercise in a learning environment authored as a task hierarchy like [Task T1, "exercise 1", T1.1, "exercise 1.1", T1.2, "exercise 1.2", ..., Task 1.2.n, "3 + 9 / 3 = " ]. In the latter case a task switch to a next subtasks would actually mark a smaller break in user attention on a higher level task than when the switch to the next subtask happens at the level of the concrete leaf tasks with the actual cognitive work.
Major motivation for services supporting task switching comes from the observation that people can only focus on one thing at a time and as several authors have indicated [e.g. 18], switching from a task to another is costly. Services supporting the user with task switching operations such as restoring task context, task reminders, and support for task continuation require a comprehensive task model.
When task switches and interruptions are frequent, the activities required to restore the task context of a resumed task can be expected to result in a significant increase in cognitive load. A diary study tracking the activity of knowledge workers to investigate these effects, reported that: (1) participants rated switching to tasks that were previously interrupted to be significantly more difficult than to others, that (2) the resumed tasks were in fact twice as long as other, more short-term projects and that (3) they required significantly more resources than other tasks [7]. Automatically providing access to such resources when a task is resumed would represent a significant help to users. Providing such service requires that:
[REQ 6]The task model associates to interrupted tasks information describing the resources in use when the task was interrupted.
Another problem related to switching tasks is one encountered frequently when a task needs to be performed at a specific moment (at an absolute time or in response to some event). Prospective memory failures, which occur when something cannot be remembered at the right time, may account for up to 70% of the memory failures in everyday life [14]. This has been shown to have a very eminent effect on performance in work and learning environments. Also, these memory failures intervene differently in different age groups.
Providing services that remind users of important dates and deadlines, or notify them of certain events could be used to alleviate this threat of prospective memory failures daunting so many activities planned to take place in the future. Further, task reminders could prove particularly useful to help users remember tasks that they have suspended earlier as a study has reported that in fact over 40% of tasks that have been interrupted, are not resumed again [15]. For example if a user suspends a task T1 to work on another more urgent task T2, the system could remind him of the interrupted task T1 once T2 has been completed.
In order to provide support with task reminders, it will be necessary to allow:
[REQ 7]Associating to tasks information either about the time when the task should be executed, or about the events that should trigger the execution (or resumption) of the task
When there are several tasks that the user is working on in parallel or there simply are several tasks to choose from, for example when a task has been completed, it could be beneficial for the user if there were services that could take off some of the cognitive load that is related to choosing the next activity.
Especially so when the user might not have much knowledge about the relevant properties of the different tasks (e.g. how long a task is expected to last).
On the basis of the task structure it is possible to find some potential and logical, yet arguably more or less simple, continuation options for the user. More complex and useful guidance can be achieved by applying some timing strategy in the evaluation, maybe by preferring tasks that may be completed before their deadline. If the evaluation also considers the priorities of different tasks or gets otherwise more sophisticated, the reasoning could be expected to have a real effect on the cognitive effort required from the user.
When a user completes a task, enabling a smooth transition to the next activity may entail restoring the context where the choice to start the now completed task was made. This could amount to reminding the user of the task that was suspended when the user moved to the current task or, reminding him of the current task sequence (e.g. the next subtask, the next required task or the parent of the task in the hierarchy).
In both situations the requirement for a hierarchical task structure ([REQ. 5]) is reinforced.
Further, elements that will intervene in the evaluation of valid continuations include prioritization (already listed as requirement [REQ. 2]) and timing:
[REQ 8]Allow the definition of task deadlines
On a more sophisticated level also expected duration of tasks, is required, this is listed below as [REQ 14].
Diaper quotes Shepherd [20] as saying that "'Task' is seldom defined satisfactorily" and continues suggesting that this might actually never be the case [8]. Some difficulties in defining tasks, such as the specification of application independent task taxonomies, have been repeatedly encountered and seem inherently difficult. Some other issues may be easier to address but need a comprehensive approach. For example whilst it would not be difficult to provide adequate contextual information for tasks, this information is often missing from task models. This section briefly overviews what we consider the main open issues in task modeling.
One clear problem when modeling tasks is the difficulty of defining a sufficient taxonomy. It would be useful to classify tasks, for example, by type of operation. Finding generic actions or operations independent of application types has however proven very difficult [8]. One of the few generic tasks that Diaper & Johnson [9] were able to identify in their work on TAKD (Task Analysis for Knowledge Description) was insert. TAKD is a method capable of modeling tasks in a wide range of applications and within this work insert was found common for a number of different objects in different application domains (namely microelectonics, automated office applications, and computer programming). Inserting could here mean either inserting text in a word processor or a program editor or alternatively inserting components on a Printed Circuit Board. Whilst it could be possible to identify some actions possibly totally independent of application domains, such as insert, the set of such actions seems to be simply too small. Whilst Diaper [8] does not see the development of task taxonomies as totally impossible, it is obvious that we are far from having such a tool and probably the definition of ontologies allowing the integration of several such taxonomies is the most promising direction of research.
Traditionally tasks have been described at the level of the application, i.e. tasks correspond to very specific users' actions within a specific application, e.g. create document, attach document, submit form. In order to support the user in his attentional choices tasks should be described at a level that corresponds better to the user's objectives, (e.g. write a paper, complete an exercise). This type of task description has been suggested by some researchers [11,13] and corresponds to the one used in the AtGentive project. In order to achieve this objective we require that:
[REQ 9]The task model should allow different types of applications to define their own tasks and task structure [REQ 10]The task model should allow describing tasks at any level of granularity
Failing to provide contextual information within a task is another pitfall of several task modeling efforts. Contextual information such as relevant resources and users, deadlines, complexity, priority, state of advancement, and location of the task in a task hierarchy is something that is clearly needed for many services supporting attention management. The inclusion of some of these attributes is represented by several requirements already listed above, further task attributes we have identified include:
[REQ 11]Keywords may be associated to tasks.
Keywords provide a way to relate tasks to resources (e.g. by keyword matching)
[ REQ 12]Maximum allowed idle time may be associated to tasks
The Maximum allowed idle time specifies the time limit within which the user is expected to act to avoid being recognized as idle by tracking devices. This information is used both to identify breakpoints and to provide help or solicitations to users who seem to have difficulties continuing a task.
[REQ 13]Task difficulty levels may be associated to tasks Indications on the difficulty of a task may help in the evaluation of the cost/benefits of interruptions, as well in the selection of the help to be provided to users.
[ REQ 14]Expected duration of the task may be associated to tasks.
This attribute specifies the average expected time to complete the task. Combined to the task advancement indication ([REQ. 4]), it enables a better evaluation of the best time for interruption. Further, task continuation services may implement strategies in which, under certain conditions, tasks with certain durations (e.g. tasks that can be completed quickly) are preferred over other tasks.
[REQ 15]Actors relevant to the task may be associated to tasks Relevant actors could for example include a teacher in the case of a learning environment or the creator of a resource when the task is simply to attend some resource. In general actors relevant to tasks will be defined within a social network associated to the user model. This information is both useful to evaluate the relevance of newly available information, and to provide community awareness services.
[ REQ 16]Support tasks may be associated to tasks (see section 5)
Currently we assume that most of these parameters are manually entered (e.g. by the user himself, or by a teacher setting up a learning sequence -as is done in the AtgentSchool application), in the future we expect that the system may be capable of generating estimates of parameters such as maximum allowed idle time, task difficulty, expected duration time, etc. by observing how several users act on the task, and by inferring the possible behavior of a specific user.
Whilst defining tasks, their structure and resources presents, as described above, a series of challenges, a further, possibly more complex challenge is represented by the automatic recognition of tasks. This requires that, on the basis of the observation of user's actions, the system is capable of matching actions sequences to specific tasks. The problem here is that if simple sequences of actions are observed (such as typing some characters on the keyboard) the system may not have enough semantic information to associate the action sequence to a specific task. In fact a very large number of higher-level tasks may be associated to simple action sequences. Within AtGentive we base task recognition on three possible inputs. First, an application, which has a much better knowledge of the semantics associated to simple user actions may recognize that the user is working at a specific task and communicate this information to the reasoning module. Second, AtGentive may use its knowledge about a small subset of all possible user tasks that are most likely to be performed by the user at a given time, and use this information to recognize that a simple action sequence is actually contributing to a specific task. Third, the user may explicitly indicate that he is performing a certain task.
The task model implemented in AtGentive's Reasoning Module distinguishes between two different categories of tasks: main tasks and support tasks. Main tasks are in essence anything the user may decide to do. Support tasks are aimed at helping the user perform a given main task and manage his attention within that task.
Both main tasks and help tasks represent abstract task properties. Whenever main tasks, or help tasks are activated concrete instances are created as user tasks. This results in creating a hierarchy of user tasks corresponding to the hierarchy of the main tasks and support tasks. User tasks instantiate all the properties for the concrete execution of that task, such as a deadline, progression etc, for one particular user. For example, one may have a main task "prepare lecture" which has abstract properties such a title, and an average expected duration, and is organized in a hierarchy of sub-(main)-tasks such as "collect resources", "create draft", etc. each having their abstract properties. For each user, there would then be a corresponding user task structure to actually execute the task, with for example individual deadlines for those users.
Main tasks (and the related user tasks) represent actions the user might perform, e.g. write a paper, prepare for a meeting, complete an assignment. These tasks can be formed into hierarchies as pleased as all main tasks could have other main tasks as subtasks.
A main task can then be described to consist of a number of finer level tasks. Task T1, Writing a paper, could for example consist of the more concrete tasks T1.1 (do research) T1.2 (write abstract), ..., T1.n (discuss future work). The hierarchical organization of main tasks allows for varied granularity when defining tasks; nothing forces one to define tasks at a finer level so for example writing a paper could in some environments be modeled as a single high level task if the task is, perhaps, known to be already well understood by the target users. In another environment the same task could be represented as one with a number of subtasks (possibly on several levels). Besides allowing granular description of task execution, subtasking can be used to distribute support more accurately where it is needed. This could in fact be one way to author tasks; first identify how the entire task needs to be supported (e.g. support for doing research, support for writing the abstract, ...) and divide the task in subtasks accordingly.
In defining task structure we have identified further requirements for the task model these include:
Tasks may be defined as optional or required. Required sub-tasks are necessary (i.e. they must be executed) for the completion of the parent task. Tasks defined as optional allow the user to skip certain sub-tasks in the execution of a main task. In a learning environment some exercise for example, may be marked as optional.
The order in which a task's subtasks need to be performed could either be specified as free for the user to choose, or mandated. In a learning environment an assignment might for example consist of reading a book and then writing a summary about it. Here it would make sense to mark the ordering of the assignments subtasks to be mandated.
Note that, if ordered execution is required, optional subtasks can still be skipped.
Tasks may either be visible or invisible. Invisible tasks are always inner nodes in the task hierarchy and allow describing abstract tasks that, although not executable, are useful to conceptualize a certain grouping in sub-tasks. A group of root tasks that are not related to each other could for example be grouped under one common invisible root task. Invisible tasks could also be useful if there is a need for a more complex ordering than what otherwise would be allowed by the task model (without adding mundane tasks that only include selections between subtasks).
The task model does not support certain task sequencing constraints. For example its is not currently possible to specify the requirement that the user completes a certain number of subtasks (say for example 2 tasks out of 3).
Support tasks help the user in performing various types of activities that the user might attend at different stages of a tasks execution. For example, a support task might help a confused user gaining a better understanding of the task at hand, another support task could provide some motivational feedback such as statistical information about the users time usage after a task is already completed.
Support tasks differ from main tasks mainly in two ways. First, they cannot be organized into hierarchies and they do not have further support tasks themselves. Although hierarchies of support tasks might be a valid concept, we didn't identify a pressing need for them and therefore we didn't include the concept in the model. This helps us avoiding introducing unnecessary complexity in the model. Essentially for the same reason we don't consider the concept of support tasks for support tasks. The other key difference to main tasks is the classification of support tasks. Support tasks are classified in two ways. First they are classified based on when they will be relevant to the task that they support. This could either be before (pre-task support), during (on-task support) or after the task (post-task support). In addition, support tasks are classified by the type of support they provide.
Based on scaffolding models [3,12,21,22] we have divided support tasks into four categories: behavior, cognitive, metacognitive and motivational support tasks. Cognitive support task have a focus on mental activities of the user. Metacognitive support task are directed at orienting, monitoring and evaluating activities. Behavioral support task are focused on physical activities of the user. Motivational support tasks are directed towards feelings of the user [12]. The term scaffolding was introduced by Wood, Bruner, and Ross [22] and it is defined as providing assistance to a student on as-needed basis, fading the assistance as the competence increases. The general idea behind scaffolding is that some of the control within the learning environment is temporally transferred from the learner to another more experienced actor to support the learner to acquire all abilities to fully self sustain his learning. The scaffold help supporting the execution of a task that the student could not have done on its own and it is removed when it is no longer necessary. Especially in innovative learning arrangement where student are provided with more control of both learning content and learning procedures scaffolds can support them to deal with this increased responsibility. The task support model allows specifying and selecting the support tasks that assists the learning process of specific learners based on an assessment of their attentional states.
In this paper we have identified the major requirements for a flexible and operational task model supporting the implementation of attention management services. We have also indicated how most of these requirements have been implemented within the AtGentive system. We consider the work presented in this paper only a starting point for attention oriented task modeling and the definitions provided will need to be both extended and further detailed. We are currently in the process of evaluating the performance of the AtGentive system in the two pilot environments and we trust that such evaluation will significantly contribute to the further development of the reasoning module as a whole and of the task model in particular. While the task model we have presented does not have the same objectives of many of the task models presented in the field of human-computer interaction, some of them may be used to guide future development of our model.
The work described in this paper was partially sponsored by the EC under the FP6 framework project Atgentive IST-4-027529-STP. We would like to acknowledge the contribution of all project partners.