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.
Design
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 [
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.
reasoning about cost/benefits of interruptions
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 [
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 [
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. [
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 [
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 [
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 [
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 [
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 [
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 [
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: [REQ 17]The task model may include a requirement level for a task [REQ 18]The task model may include task ordering [REQ 19]The task model may include task visibility These properties are tightly related to the execution of tasks at a given moment and are useful to support task continuation (see 3.2.3), they are briefly described below.
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 [
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-027529STP. We would like to acknowledge the contribution of all project partners.