Michael J. Mahemoff
Department of C.S. & S.E.
The University of Melbourne
Parkville, 3052, Australia
Tel: +61 3 9344-9100
Fax: +61 3 9348-1184
Lorraine J. Johnston
School of I.T.
Swinburne University of Technology
Hawthorn, 3122, Australia
Tel: +61 3 9214-8742
Fax: +61 3 9214-5501
This paper addresses the concept of generic tasks--low-level tasks which recur across different systems (e.g. remove, compare). To demonstrate the existence of generic tasks, a taxonomy of generic tasks was prepared after analysing fourteen software projects. To illustrate one application of this approach, an empirical study was then conducted. Six subjects used a standard structured technique to to propose as many new tasks as possible for two hypothetical systems. They were then introduced to the generic tasks, and the results indicated that the generic tasks helped them add many new tasks to their existing list. In addition to the brainstorming technique we have demonstrated, generic tasks could support design reuse, act as a common vocabulary among designers, facilitate interdisciplinary design, and assist novel design.
Generic Tasks, Design Reuse, Task Analysis, Human-Computer Interaction
An important component of design is the ability to imagine new possibilities for the system under consideration. If potential features are not sufficiently explored early on, the likely consequence is a system with unsatisfied users. Because system features are decided upon so early in the software lifecycle, failing to identify appropriate features leads to a costly redesign process.
One promising way to help designers generate novel ideas is to improve opportunities to reuse tasks which have been implemented in earlier applications. Designers can gain from reasoning by analogy to similar systems, as opposed to deriving a design purely from first principles. Brooks  noted that it is unusual for engineering science to rely only on basic science to formulate new ideas. Pure scientific theory can provide too much detail, making it difficult for practitioners to draw analogies between their current situation and their past experiences.
Tasks which are typically performed by users can be placed into a taxonomy of ``generic tasks'', and designers of a new system can draw ideas from this taxonomy. In a survey of user interface development processes and methodologies, Hartson and Boehm-Davis  suggested the need for task taxonomies in HCI. According to the authors, taxonomies would help us to reuse task analyses. Taxonomies of HCI-related concepts such as tasks and user classes would also be valuable to designers. Reuse of detailed software design has also become very popular, evidenced by widespread interest in software design patterns and frameworks (e.g. [2,8]). This heightens the need to reuse artefacts related to software design and code, such as task models; there are synergies to be gained if we can map between recurrent task models and recurrent software design constructs.
The concept of generic tasks also provides a structured way to generate novel ideas. It is based on the assumption that there is a small set of generic tasks which can form the basis for many systems. For example, many systems are equipped with a ``Compare'' task (e.g. comparing two graphs, comparing two word-processor documents). Involved in a vigorous design process, designers (and users) may not even consider the possibility of allowing this functionality in their work. Once the system has been implemented, including the ``Compare'' task would probably require a substantial re-engineering effort. A couple of hours browsing through a list of generic tasks including the ``Compare'' task would reduce the likelihood of such events.
Of course, practitioners need to guard against ``feature creep'', i.e. using a list of generic tasks to derive obscure ideas and then implementing them without appropriate consideration of their usefulness. Indeed, the central aim of the generic task approach as a brainstorming technique is not feature generation for its own sake, but rather risk prevention; it helps to ensure designers do not overlook critical features. The proposal here is that generic tasks be incorporated into an integrative process of the developer's choosing, which would include a selection of regular HCI techniques (user and domain analysis, participatory design, evaluation, etc.). A sensible application of generic tasks would take into account the capability of generic tasks to help explore avenues which might otherwise have been overlooked, and to do so at a very early stage. Brooks argues that in HCI, the problem and the solution are both in need of consideration. That is, we need to analyse the tasks users perform and the resultant systems which satisfy those tasks. This is analogous to a doctor describing a disease and its cure.
In this paper, we describe how we obtained a list of twenty-two generic tasks from the requirements for fourteen industry-based, year-long, student projects. This process served to demonstrate that certain tasks do recur across different systems, and also laid the foundations for our pilot study. The predominately qualitative study was conducted to understand how people apply generic tasks and how they feel about the design technique. It should be noted that brainstorming is not the only application for generic tasks: the concept could also be used to form a common vocabulary. This would support interdisciplinary design and may also aid techniques for design reuse.
Some researchers have attempted to classify low-level tasks, e.g. Foley et al.'s  concept of ``basic interaction tasks'' for interactive graphics. For programs modelling two-dimensional space, they proposed four basic tasks: specifying a position, selecting an element, interacting with text, and specifying a numeric value. The taxonomy also describes three ``composite interaction tasks'': dialogue boxes, construction techniques (e.g. specifying a line), and dynamic manipulation (adjusting previously-constructed objects, e.g. rotating an object).
More recently, Baber  described several ``generic actions'' of human-computer interaction (HCI), on the basis of ISO/DP 7942. The purpose was to establish a framework for discussing how various input devices compare in supporting particular tasks. Under this scheme, four categories were identified (with a total of seven actions): selecting objects, dragging objects, changing the orientation of objects (e.g. rotation), and entering data.
There are also higher-level approaches to reuse, e.g. Breedvelt-Schouten et al. have demonstrated that segments of task hierarchies can be reused . This work attempts to formalise the notion of recurring task hierarchies, e.g. ``Define Query'' consists of a number of ``Enter Query parameters'' followed by ``Submit''.
Our work extends these contributions by capturing a broad list of generic tasks. We have also performed the analysis in a systematic manner which could be repeated, for instance, by an organisation wishing to capture recurring tasks among its own projects. Fourteen software projects were analysed. The projects were performed by teams of about four people, as a full-year third or fourth-year software project, and each was in the order of 10,000 lines of code. Clients were drawn from both industry and academia.
We narrowed down fifty candidate projects to the final fourteen according to two criteria:
There were no criteria relating to the the final product. In fact, the final product's usability was not considered because we were focusing on the tasks which emerged after requirements-gathering, rather than the ways in which the software supported these tasks.
Key tasks were extracted from the usage scenarios. This enabled us to quickly identify a large number of tasks from a variety of domains. However, there was a concern about the depth of this approach; it is conceivable that particular families of tasks are systematically left out of these scenarios. Furthermore, scenarios are only single episodes and can be difficult to generalise from--for example, to reason about common task sequences.
|Project Description||Key Tasks|
|Contractor selection tool: To produce a ``shortlist'' of tenderers||Summarise, Add, Remove (tenderers); Navigate (through quality factors)|
|Timetabling tool: To construct tutorial timetables||Change Display Options (of timetable view); Add, Remove, Move (details); Update system state (to check against domain constraints);|
|3D Weather Visualiser: To explore weather prediction data||Change display options (e.g. wire-frame vs. solid), Enter data (display option parameters).|
|Radar Tracking System: To visualise objects being tracked by a radar||Navigate (to different map areas), Obtain guidance (about how to use the system).|
|Source Code Visualiser: To help programmers visualise source code||Change Display Options (e.g. direction of arrows), Add, Remove, Move (nodes representing source code modules).|
|Multi-lingual Botany Database: To enable queries to a plant database||Search (for matching data), Change Task Parameters (to set query language).|
|Online Tutorial System: To support real-time online interaction between tutors and students||Navigate (tutorial material), Enter Data (to answer questions).|
To address these concerns, seven diverse projects were selected for detailed task analysis (Table 1), although key tasks from the other seven were also retained. There were three principles in selecting the projects to undergo task analyses: (a) we required a diverse cross-section of projects; (b) relatively complex requirements were favoured; (c) successful projects were preferred. User documentation and requirements specifications were consulted to extract task models for the systems. The Jackson System Design (JSD) notation, adopted in the MUSE methodology for task analysis , was used to document the models. JSD was appropriate in this situation primarily because it is graphical and has a well-defined syntax. In combination, these attributes facilitate the process of analysing typical patterns.
|Tasks||Example from Analysed Projects||Corresponding Word-Processor Task|
|Add||Add a new lesson to a multimedia tutorial.||Add text.|
|Remove||Delete a company from a list of tenderers.||Delete text.|
|Replace||Replace currently-loaded video sequence with a new sequence||Over-write a selected text block.|
|Move||In a timetable representation, drag a subject cell to a new timeslot.||Move a drawing object.|
|Transform||Re-layout a network of nodes and edges.||Underline a text block.|
|Handle Entire Material|
|Store (Special case of Move; moving to storage location)||Save a recently-generated animation||Cut text to clipboard.|
|Retrieve from Storage (Special case of Move; moving from storage location)||Load source code which is to be visualised.||Paste from clipboard.|
|Duplicate||Copy a file||Copy to clipboard.|
|Search||Search for text from an online product database.||Search for text pattern within document.|
|Navigate||Request information about an element in a multimedia chemistry tutorial.||Scroll to a desired text region.|
|Summarise||Show a summary of objects which have been shown in an animation.||Perform word count.|
|Compare||Compare a weather chart on two different days.||Track document changes by comparing two different versions.|
|Change Display Options||Select desired language of query results.||Enable text-wrapping.|
|Enter Data||Enter data from keyboard.||Enter data from keyboard.|
|Select||Choose an internet relay channel.||Select a font.|
|Compose||Group together several graph nodes to form a single node representing the entire group.||Select several drawing objects at once.|
|Decompose||Ungroup a grouped node.||Select an individual object when several drawing objects have been selected.|
|Preview Task Effect||Change cursor to indicate effect of clicking within a certain area of a multimedia tutorial||View a preview of the document as it will appear after printing.|
|Obtain Guidance||Request context-sensitive help by clicking on a Help link||Select Help from an object's Properties menu.|
|Undo||Click Back button to return to previous page.||Reverse a text change.|
|Update System State||Click Verify button to see timetable cells which meet specified constraints.||Update an Include Text Field after a change to the file corresponding to this field.|
|Change Task Parameters||On a graph visualiser, modify default number of expansion levels which apply when a user adds a node's ancestors or descendants.||Change text entry mode from Insertion to Overtype.|
After recording tasks for each project and placing them into categories, we obtained a classification reflected in Table . Although exploring these relationships is beyond the scope of this study, it is worthwhile acknowledging a few ways the tasks can be related to each other. One possible relationship is for a task to be a special case of another task. Another relationship is where two tasks complement each other. Search and Navigate could be used in tandem by a user trying to locate a passage of text, for example. Sometimes two tasks are necessarily connected to each other, but can be performed in either order, e.g. when the system allows either ``noun-verb'' or ``verb-noun'' actions.
The tasks were placed into five groups. Note that the term material is used to describe software artefacts, after Riehle and Züllighoven . The groups are:
The second column of the table shows examples of the tasks extracted from the selected projects. The third column demonstrates the external validity of these tasks by showing how each is supported by a typical word-processor, MS-Word in this case. The list presents a wide range of tasks, but no attempt has been made to produce an exhaustive collection of recurring tasks. The purpose is to show that generic tasks can be systematically captured, and to investigate how such a list might be used.
The tasks are a reflection of real-life projects, rather than an idealised set of activities. It might be argued that since the system should always be up-to-date, there should be no need for an ``Update System State'' task. In reality, however, systems may not have the processing power or bandwidth to continually synchronise with the user-interface.
One possible use of the generic tasks is to provide rapid generation of ideas for new software functions. We wanted to investigate whether such a brainstorming technique was possible. Furthermore, the generalisability of tasks could be demonstrated by taking generic tasks from one set of systems, and applying them to other systems.
The methodology was to provide subjects with a standard structured method for devising new tasks, and then investigate whether introducing the generic task list could help them think of additional tasks. Six subjects volunteered to participate in the pilot study. Four were postgraduate students in the Department of Computer Science and Software Engineering Uni of Melb, and two were final-year undergraduate students in that department. All students had extensive programming experience. The subjects sat in individual sessions lasting 1.5-2 hours.
Two hypothetical systems were initially shown to subjects. One was ShopCart, a client-side application for internet shopping (independent of a web browser), and the other was Ready Reader, a hand-held reading device (Figure 1). Several sketches of screens were provided for each, along with accompanying descriptions of possible tasks at each stage. Written instructions informed the subjects about the techniques they were being asked to employ.
Figure 1: Sample hand-drawn sketches for ShopCart and Ready Reader applications. ShopCart screen shown is main menu, one of five screens. Ready Reader screen is document view, one of two screens.
In the first phase, subjects could use any means to produce the tasks. To make this stage comparable to the second phase involving generic tasks, a structured method was offered; however, it was made clear that this was only a brainstorming tool, and any other ideas were encouraged. The structured method involved asking subjects to write down users' goals in using the system, and then to identify the problems users might have in achieving these goals. From these goals and problems, subjects were asked to write additional tasks which users might be able to perform with the system. Subjects were given guidance on the structured technique, as well as a worked example, and were informed that it did not matter if they got the concepts confused (e.g. defined something as a task instead of as a goal) because the administrator would interpret their work later on. Our aim here was to encourage subjects to provide as much information as possible before being introduced to generic tasks.
When subjects felt they had exhausted their ideas for each system, they entered the second phase. The generic task list was introduced to them as an alternative method, from which more tasks could be added to their initial list. Subjects were asked to use the generic task list in a similar manner to the first approach, i.e. as a flexible brainstorming tool, so that they could feel free to suggest tasks which may not correspond directly to the generic tasks. To provide some structure, subjects were asked to step through each task, recording ideas for the system as they proceeded. Then, they were asked to write any other tasks they could think of. Finally, they were asked to step through the list and check if anything could be added. The experiment concluded with a semi-structured de-briefing discussion to clarify subjects' work and help us compare the approaches.
Subjects' work was initially processed, with any identified goals or problems being converted to tasks if that was more appropriate. Tasks were eliminated if they seemed more like goals or problems, and counted once only if the person repeated them (it was quite common for people to rewrite a Phase 1 task as a generic task).
Many tasks proposed before the generic task list was introduced nevertheless mapped to a particular task (e.g. many people suggested a search function in the initial phase). Conversely, some tasks proposed after the list was introduced did not map to any particular generic task. Thus, we classified tasks according to (a) which phase they were identified in, and (b) whether or not they fitted a generic task.
Before describing more detailed analyses, we now describe the tasks which were proposed more frequently, in both Phase 1 and 2. Following is a list of ShopCart tasks proposed by three or more people during Phase 1, accompanied by the matching generic task (the figures in parentheses indicate how many subjects listed each task).
|Search for item (6)||Search|
|Remove item from cart (4)||Remove|
|Look at previous carts (4)||Retrieve|
|Specify item quantity (5)||Duplicate|
|Change language (3)||Change display options|
|Help on usage (3)||Obtain Guidance|
For Ready Reader, tasks suggested by three or more people in the Ready Reader were as follows:
|Show tree/list of all files at once (4)||Summarise|
|Search for word across documents (4)||Search|
|Create a new folder (3)||Add|
|Search for documents, e.g. by date (3)||Search|
|Change font (3)||Change Display|
|Group documents for delete/move (3)||Compose|
It is also important to consider specific useful tasks which arose from the generic task concept. Some examples of tasks which were only suggested during Phase 2 of the ShopCart application are shown below. It is interesting to note that most of these tasks are supported by existing e-commerce sites, but the generic task list seemed to trigger subjects to consider them.
Useful or novel tasks proposed only in Phase 2 for Ready Reader were:
That subjects considered these possibilities only after being exposed to the generic tasks lends support to the notion that brainstorming can improve quality and reduce the likelihood of tasks being overlooked.
|Subject #||Phase 1||New in||Total||Phase 1||New in||Total|
|Phase 2||Phase 2|
|Average No. of Tasks||9.8||5.7||15.5||4.50||9.7||14.5|
Overall, both phases yielded results in favour of the generic task intervention, as shown in Table 3. Mean and standard deviation were calculated, although there is no statistical test performed. It is clear, however, that the generic task list had a marked effect. All subjects were able to think of several tasks before being shown the generic task list, and introducing the list led them to add several more. This result was true for both hypothetical systems.
One interesting result is the wide individual variation which occurred for both phases. This is not entirely surprising, since people will have different abilities in solving this type of problem. Some people seem to gain a lot of support using the generic tasks (Subjects B and D), while others appear to derive less benefit (Subject A). All subjects experienced relative increases in usage of generic tasks during the second exercise, Ready Reader. De-briefing discussions suggested that this was due to a learning effect in which the unusual concept of generic tasks becomes more familiar.
The previous table considered individual performances, so that a task was counted twice if two people suggested it. In this section, we consider the tasks generated by the group as a whole. In other words, we are looking at the number of unique tasks generated.
Table 4 shows that in both applications, introducing the generic tasks more than doubled the number of unique tasks suggested. This is despite the fact that individuals added fewer tasks on average in Phase 2 than they initially proposed in Phase 1 (Table 3). This demonstrates that generic tasks led to more variation among individuals; they led to many tasks which only one individual thought of. In contrast, there was more commonality among the initial tasks. People commonly proposed typical tasks such as Search for a book and Show cart total.
|Task Type||Only in||Only in||In Both||Total||Only in||Only in||In Both||Total|
|Phase 1||Phase 2||Phases||Phase 1||Phase 2||Phases|
|No generic mapping||12||1||0||13||6||2||0||8|
The table also shows that quite a few Phase 1 tasks mapped to a generic task. This makes sense, as designers presumably have their own models of generic tasks, some of which corresponds to those considered in this investigation. In de-briefing conversations, subjects indicated that in the first phase they were often considering software they had seen before. Several people commented that they had features of Amazon.com in mind when designing ShopCart.
Many tasks were suggested in Phase 2 only. A concern about this methodology is that subjects may not consider items important enough to record in the first phase, but will record them in the second phase if they see a corresponding generic task. This may have happened in a couple of instances. For instance, a Help function was not recorded initially, but on seeing the generic task ``Obtain Guidance'', three subjects proposed it. However, this was not the case for most tasks. Two useful Ready Reader tasks suggested by three people in Phase 2 but overlooked by everyone during Phase 1 were (a) grouping documents together for deleting or moving (``Compose'') and (b) changing font (``Change Display Options''). Furthermore, the ``Both Phases'' column suggests that at least for some tasks, there can be high assurance that the generic list was helpful. This column shows that there were some tasks which some users thought of initially, and others thought of later on.
Most subjects reported that they had some difficulties using the first technique to map from goals to problems to tasks. They had difficulties understanding the distinction between goals and tasks, and also found there was a very close mapping between problems and tasks (Problem: ``Does not have Search'', Task: ``Let user Search''). However, we asked subjects to show mappings between goals, problems, and tasks. This let us check how close the mappings were. It turned out that subjects were not overly-constrained by this technique, since they chose to add many tasks which did not correspond to particular goals or problems.
All subjects stated that they found it relatively easy to map from generic tasks to specific tasks in the system. Subject F--who did not perform many mappings-- stated that he did not have problems doing this, but felt that he had proposed the major tasks already.
One surprise for us was that several subjects perceived the two phases as a cohesive methodology. We had intended the first phase as an initial benchmark for the generic tasks, and we structured our instructions to give the impression that two separate techniques were being investigated (we did not identify whether any technique was our own). In fact, one Subject (Subject D) suggested that the goals helped to consider tasks based on users' perspectives, and the generic tasks act as a safeguard to ensure that any other useful tasks had not been omitted. Another (Subject F) confirmed this view, stating that if she had started with generic tasks she may not have covered everything. Therefore, she explained, it was good to start by considering users' goals, then moving on to tasks.
In the first half of this paper, we explained how studying tasks across a wide range of systems led us to a generic task list. This process demonstrated that certain tasks do recur across different programs and that generic tasks can be systematically documented. The initial classification we have provided may prove of some use to developers, as well as the method for capturing generic tasks.
In the second half, we described a pilot study which demonstrated that generic tasks can have practical implications for designers. A repeated measures methodology was adopted, in which the generic task list was introduced once subjects felt their ideas had been exhausted. Since there was no control group, it is not possible to be certain that the subjects would not have arrived at the new tasks without the generic tasks being provided. However, there is significant evidence to suggest the generic tasks themselves had at least a significant influence on the ideas of subjects during the second phase. Firstly, the second phase took place immediately after the first phase, rather than a day or even an hour later. Secondly, many of the tasks proposed during the second phase were related to the generic tasks, with subjects indicating the associations. Thirdly, the de-briefing discussions indicated that subjects felt comfortable with the generic task concept and most felt they had been able to apply them directly to the design problem.
A useful property of this brainstorming technique is that it only needs one or two hours of work, even in an industrial setting (although several iterations may be required). Thus, we were able to conduct an experiment similar in duration to an industry setting. We did not have to use contrived, small-scale, systems as examples; the hypothetical ShopCart and Ready Reader applications have a similar degree of complexity to many real-life projects.
It would be useful to expand the technique into a more integrative process which takes into account users' goals and contexts. The technique might also involve participative design, since it should be very easy for users to comprehend the generic task concept. Further research might form more quantitative findings related to factors such as individual differences and application type.
The brainstorming technique can be used to design for systems which have no obvious direct analogy. Researchers have previously suggested the consideration of related systems, e.g. MUSE's extant system analysis , and the competitive analysis described in Nielson's Usability Engineering approach . Generic tasks provide developers with a knowledge base, leading to greater confidence that existing systems have been considered.
The notion of generic tasks may be most beneficial when applied to a particular organisation's projects or confined to a specific domain. Using a method similar to the one presented here, it would be possible to ``mine'' tasks typically supported by a certain class of software. Databases, for example, support tasks such as ``View record'', ``Filter records'', ``Search for data''. Such a tool might prevent late change requests for a developer working on small projects where large-scale usability studies are prohibitive; for example, someone developing a database for video library holdings or staff management.
This paper has focused on only one application of generic tasks, i.e. as a rapid brainstorming technique. In fact, there is a broad spectrum of possible applications for generic tasks. Reusable HCI knowledge bases and design techniques, exemplified by the popular design patterns paradigm , can be informed by an understanding of the tasks users typically perform. The interdisciplinary HCI community can benefit from a common vocabulary; when a human factors specialist asks a software engineer to implement a ``Change Display Options'' task, the software engineer has a pool of knowledge to draw upon about how generic tasks may be implemented in different environments. In this way, generic tasks raise the level of abstraction from commonly-known GUI elements (``scrollbar'', ``button'') to user tasks. Researchers can also benefit, by being able to compare interaction styles according to baseline generic tasks.
This work is licensed under a Creative Commons Attribution 3.0 Unported License.