Abstract
User tasks play a pivotal role in visualization design and evaluation. However, the term ‘task’ is used ambiguously within the visualization community. In this article, we critically analyze the relevant literature and systematically compare definitions of ‘task’ and the usage of related terminology. In doing so, we identify a three-dimensional conceptual space of user tasks in visualization, referred to as the task cube, and the more precise concepts ‘objective’ and ‘action’ for tasks. We illustrate the usage of the task cube’s dimensions in an objective-driven visualization process, in different scenarios of visualization design and evaluation, and for comparing categorizations of abstract tasks. Thus, visualization researchers can better formulate their contributions which helps advance visualization as a whole.
Introduction
Tasks are an issue discussed frequently in the visualization community as they are pivotal to how we design and evaluate our work. In many, if not all, scenarios of empirical visualization research1,2 tasks are either central to the study setup (e.g. in controlled experiments or case studies) or an emergent study result (e.g. transcription of observed visual data analysis and reasoning processes). This is further illustrated by the role of tasks in widely used design frameworks such as the Data–Users–Tasks Design Triangle 3 or the Nested Model. 4
However, there is continuing confusion about what the term ‘task’ means in a visualization context. Even if we consider tasks only for visualization users and neither for developers of visualization systems nor for the audience of a presentation, there are many nuances of what such a visualization task can be. It may be as open-ended as ‘detect anomalies in recent public health data’ or ‘identify the main drivers of climate change’ but also as crisp as ‘find yesterday’s most profitable product’ or “buy a train ticket” 5 p.2433. Already in 1994 it was widely acknowledged that “the notion of ‘task’ is increasingly difficult to pin down” 6 p.410, and nowadays the word ‘task’ is still regarded as “deeply overloaded in the visualization literature” 4 p.921. Based on our own experience throughout multiple visualization design and evaluation projects and inputs from fellow researchers, we regard this confusion as unsatisfactory. A commonly agreed understanding and terminology of tasks is needed.
Therefore, this article investigates user tasks in visualization design and evaluation using the three conceptual dimensions, referred to as the task cube, as a theoretical compass.
The primary contribution of this article is the conceptual space and its dimensions perspective, abstraction, and composition, which we define and describe in the section of the same title. We also compare our dimensions systematically to definitions from relevant literature on visualization and human-computer interaction (HCI).
Furthermore, we emphasize the central role of tasks in visualization in the next section. On the one hand, we present visualization as a task-driven endeavor by putting objectives and actions to the foreground of visualization processes. On the other hand, we illustrate the role of tasks in different scenarios of visualization design and evaluation.
Finally we survey 37 categorizations of abstract tasks found in theoretical frameworks and state-of-the-art reports and systematically compare these categorizations along the dimensions of the task cube.
Thus, instead of proposing a categorization of individual tasks, the task cube and its dimensions help visualization researchers navigate the conceptual space of task categorizations—in particular when working on theoretical task frameworks and collecting state-of-the-art reports. In addition, the reduced ambiguity allows visualization researchers to better formulate their contributions. This article builds on contributions presented in a previous workshop article 7 with revised definitions, an objective-driven visualization process, an illustrative example, and a survey of abstract task frameworks as major extensions.
Conceptual space
In an effort to clear the aforementioned confusion around the term ‘task’, we analyzed the scientific literature on HCI and visualization for definitions of what tasks are and what roles they play in visualization (see section on Comparison to literature). In addition, we surveyed and compared task categorizations published in theoretical frameworks and state-of-the-art reports (see section on Categorizations of abstract tasks). Our materials have a focus on visualization and visual analytics of time-oriented data and graph data. Visual analytics 8 has a particular emphasis on developing a science of interaction 9 and to support higher-level reasoning. Nevertheless, we consider our results applicable to the visualization field in general.
Our literature review confirmed that the term ‘task’ is not consistently defined but refers to different concepts. Consequently, our analysis concentrated on characterizing these concepts and we identified three dimensions—abstraction, composition, and perspective—spanning the task cube (Figure 1). For this purpose, we treat composition and abstraction as continuous dimensions along with the why/how dichotomy for perspective. Thus, a concept of task can be placed either on the top or on the bottom plane of the figurative cube. As we demonstrate below these dimensions are non-redundant and sufficiently expressive to explain the conceptual variety of user tasks in different visualization design and evaluation scenarios.

Overview of the conceptual space of user tasks in visualization with composition, perspective, and abstraction as orthogonal dimensions.
Next we present these dimensions in a consolidated terminology distilled from our literature analysis.
Abstraction. can be clearly distinguished from composition: a low-level task is a part of a high-level task, whereas an abstract task is a more generic category of a concrete task. This is illustrated by a low-level task demanding fewer steps to perform than the high-level task encompassing it. In contrast, if an abstract task describes a given concrete task more generically, both tasks still require the same steps. These dimensions conform to the subclass of and part of relationships found, for example, in object-oriented programming and ontology languages.
an
On the other hand, tasks using interactive features of visualization artifacts and categories of some low-level task frameworks are formulated as executable actions, such as ‘map time to y-axis’ or ‘zoom to the orange cluster’. The technical term ‘action’ is widely used and we derive its definition from Gotz and Zhou:
15
an
Since there is usually no direct relation—no decomposition—between objectives and actions, it makes sense to distinguish between a why perspective and a how perspective and to have two distinct terms to explicitly address these perspectives.
Both objectives and actions can be composed or decomposed at different levels. On the why perspective, users break down large objectives to increasingly smaller subobjectives, intentionally or unintentionally, in order to make ill-defined objectives manageable using visualization tools.11,16 On the how perspective, blocks of consecutively observed actions can be combined to action sequences, at multiple levels of composition. With experience, users will develop action strategies to solve common subobjectives with a tool and it is possible to analyze such strategies by observing users. 17 In addition, actions can be decomposed further to a level below intentional problem solving such as individual user interface events. 15 Even though the composition hierarchies of objectives and actions are connected, it makes sense to draw a clear line between them along the why/how dichotomy because objectives and actions are different concepts with different properties. Furthermore, actions can be found at the same composition level as intermediate- to low-level objectives with the mapping varying largely depending on visualization tools. For example a specialized tool for electronic health records might have the affordance to select all critical patients by a single intermediate-level action whereas a general purpose time series analysis tool requires a sequence of low-level actions to achieve the same objective.
Neither could we subsume perspective under abstraction because both objectives and actions can be described at different levels of abstraction. Above, we mentioned the concrete objective ‘find the quarter of Google’s maximum revenue’ and classified it as the abstract objective ‘indirect lookup’. Likewise, the action of changing the y-axis of a scatter plot to a different variable can be abstracted as ‘reconfigure’, 18 ‘arrange’, 13 or ‘visualize’. 19
Together these three dimensions span the task cube (Figure 1), a simple yet expressive model of the conceptual space for user tasks in visualization.
Example
To illustrate these concepts more deeply, we will follow an extensive example based on the Kronos Incident, the fictional application context created for VAST Challenge 2014. 20
The concrete, high-level objective of the Kronos Incident 20 is to support law enforcement agencies of the fictional country of Kronos in investigating the disappearance of some employees of GAStech, a natural gas production company. The VAST Challenge breaks the objective down to subobjectives of (1) reconstructing the events of the disappearances, (2) reconstructing networks of people that influenced each other, (3) finding missing information, and (4) providing the best course of action for the police force (Figure 2). Of course, these concrete subobjectives need to be broken down further. For example, to specifically analyze the network of the main suspect, an organization named the Protectors of Kronos (POK), we can identify the lower-level objectives as (2a) identifying the leaders, (2b) identifying all members of the extended network, (2c) analyzing the change of the network structure over time, and (2d) finding potential connections between the POK and GAStech.

Visual task decomposition of the Kronos Incident as described in the Example section.
To break down the concrete subobjective (2a) even deeper, we follow the solution of Saraf et al., 21 winners of the Grand Challenge Award. They first (2a1) located co-occurrences of the terms “POK” and “leader” in news articles over time. This resulted in three time ranges when both terms peaked simultaneously. Then they (2a2) browsed through word clouds of persons retrieved from named entity recognition of articles in these time frames.
It is possible to abstract the high-level objective by domain as a law enforcement objective. The subobjective (2a) can be abstracted as ‘discover/explore/compare’ using the three-level why-typology of Brehmer and Munzner. 13 We can abstract the low-level objective (2a1) of finding co-occurrences of the terms over time as ‘discover/locate/summarize’ 13 or as a ‘synoptic inverse comparison task’. 10 The following concrete objective of finding the most mentioned name in each time frame can abstractly be considered an ‘elementary comparison’ task according to Andrienko and Andrienko. 10
Saraf et al. 21 solved the concrete low-level objective (2a1) by entering the terms in a search box of their visualization artifact and then used the date range widget for subobjective (2a2). Both concrete actions can be abstracted as ‘filter’ in the frameworks of Yi et al. 18 and Gotz and Zhou. 15
Comparison to literature
In colloquial English a ‘task’ is understood as “a piece of work that has been given to someone: a job for someone to do”. 22 The Merriam-Webster Dictionary emphasizes that tasks are characterized as being externally assigned, having a deadline, and being hard or unpleasant. Surveying the HCI and visualization literature we can however discover a shifted focus and a multitude of nuances of this general definition. Next, we analyze these along the three dimensions presented above.
In addition, some task frameworks introduce explicitly named composition levels (Figure 3), which contrasts with abstraction, which to our knowledge has no such hierarchies. Norman 24 p.15 introduced a composition level above tasks: “an activity is a coordinated, integrated set of tasks”, and emphasized that design should be centered on these activities. Gotz and Zhou 15 p.46 described how “analysts typically follow a divide-and-conquer approach, performing several sub-tasks to achieve the requirements of a single top-level task”.

Comparison of composition levels in different hierarchies. The grey area denotes whether the level is regarded specific to the used tool.
Tasks at the leaf-level of the hierarchy are often treated distinctively. Preece et al. 6 p.411 defined an action “as a task that involves no problem solving or control structure component” and is performed by “the human physically interact[ing] with a device”. Tasks at a similar level of composition are also referred to as ‘simple tasks’ or ‘unit tasks’. 6 Fuchs 11 p.10 used ‘basic tasks’ for the leaf-level and differentiates them from ‘actions’, which “describ[e] the functional properties beyond the conceptual task decomposition”. He defines an ‘action’ as “an atomic operation that is executed upon an artifact, by an entity that is involved in the completion of the task (user, computer, . . .)”. Similarly, the action tier of Gotz and Zhou 15 p.46 represents “an atomic analytic step performed by a user with a visual analytic system”. They consider yet another level below actions: “events correspond to the lowest-level of user interaction events (for example, a mouse click or a menu item selection) which carry very little semantic meaning” p.43. Norman 24 p.15 described tasks as “composed of actions, and actions [as] made up of operations”. ConcurTaskTrees 23 distinguished at the leaf-level between ‘user tasks’, ‘application tasks’, and ‘interaction tasks’. They referred to tasks composed of such subtasks as ‘abstract tasks’.
The selection of tools also plays an important role in task decomposition (Figure 3). Both Preece et al. 6 and Cooper et al. 25 used it to distinguish between ‘goals’ and ‘tasks’. For Fuchs 11 it is the ‘action’ that involves an artifact such as a task-specific visual representation.
On the one hand, the why perspective describes a task by the ends or the intended outcomes. Preece et al. 6 p.411 defined an external task or goal “as a state of a system that the human wishes to achieve”. Roth 14 p.2357 distinguished further between “an ill-defined task, or goal, motivating use of the visualization” and “a well-defined task, or objective, that can support the goal”. In visualization, the why perspective is often formulated as a question or a query to be answered based on the data at hand. Andrienko and Andrienko 10 p.49 “use[d] the word ‘tasks’ to denote typical questions that need to be answered by means of data analysis”, Amar et al. 12 categorized tasks by questions or queries asked, and Munzner 4 p.921 denoted a task described in domain terms as ‘problem’. In her book, 26 p.45 she referred to abstract why tasks as ‘action’. For Gotz and Zhou 15 p.46 the “task tier captures a user’s high-level analytic goals”.
On the other hand, the how perspective addresses the means or actions by which users perform the task. Preece et al. 6 p.411 defined a task, in particular an internal task, “as the activities required, used or believed to be necessary to achieve a goal using a particular device”. Fuchs 11 p.10 understood a task “as a single, conceptually distinguishable but not necessarily atomic step within a composite activity or work flow”. Cooper et al. 25 p.15 wrote “both activities and tasks are intermediate steps (at different levels of organization) that help someone to reach a goal or set of goals”. For Schulz et al. 27 p.2366 visualization tasks are “activities to be carried out interactively on a visual data representation for a particular reason”. For Brehmer and Munzner 13 p.2376 “abstract tasks are domain- and interface-agnostic operations performed by users”. Roth 14 p.2357 distinguished a third category: “a system function, or operator, that may support the objective”.
Bridging between the extremes and taking an abstract view on an intermediate level appears as a promising direction. Yi et al. 18 proposed to categorize actions by user intents, i.e. “what users achieve by using the interaction techniques rather than how the techniques provided by Infovis systems work”. Schulz et al. 27 established a five-dimensional design space of visualization tasks that encompasses both why and how as well as dimensions pertaining to the data (characteristics, target, cardinality). Likewise, Brehmer and Munzner 13 represented a task as a triple composed of why, how and what (data).
In contrast, our work does not aim for such a single intermediate level that captures all diverse forms of tasks. Instead, it emphasizes the diversity of task concepts. The task cube can accommodate for different task categorizations that suit different visualization scenarios and application domains. Thus, it proceeds from previous work considering its dimensions. On the one hand, Munzner 4 proposed a 2x2 matrix of task concepts by abstractions and composition. On the other hand, Roth 14 distinguished between different concepts for why (goal, objective) and how (operator). Pike et al. 28 combined the why/how dichotomy and the level of composition. They described “analytic discourse as the relationship between [interaction] techniques and the user’s goals and tasks, which involve low-level choices about manipulating interactive controls and higher level goals surrounding the problem being investigated” 28 p.265. Brehmer and Munzner 13 proposed three dichotomies to compare task categorizations: level (high vs low), temporality (sequences vs constraints), and specificity (general vs specific). What the task cube adds is a more fine-grained understanding of abstraction and a terminology that can distinguish between why and how tasks. In particular, we need to emphasize that visualization often addresses open-ended objectives. When solving such objectives, the users can follow different strategies and there are often no definite mappings between the why and the how. Furthermore, HCI scholars have long warned against a design approach that focuses on hierarchical analysis of operational tasks and not on the goals and characteristics of the users.6,24,25,29
Next, we will explore the role of objectives and actions both in a concrete process and in different scenarios of design and evaluation.
Role of tasks in visualization
We conceptualize visualization-supported data analysis as a process that is largely driven by objectives. This process combines and extends existing process models by expanding the gulf of goal formation16,31 beyond actions towards higher-level objectives and by adding emphasis on objectives and their breakdown to the knowledge generation model 30 and the hypothesis-driven model of Lammarsch et al. 32 For this purpose we rely on a few technical terms (model, finding, insight, hypothesis, and knowledge) from the knowledge generation model. 30
This visualization-supported data analysis process (Figure 4) starts with a user, data, and an objective. 3 While the data resides in a more or less structured form within a computer, the user brings in the objective and his or her background knowledge.5,30 The objective can originate from the user’s personal goals, from the goals of the user’s organization, 6 or out of pure curiosity. 33

Objectives and actions in visualization-supported data analysis. The knowledge generation model 30 is extended with the notion of an objective residing at the human side, which is tackled through a plan and performed through a sequence of actions. New insights might lead to replanning.
Under consideration of his or her background knowledge about the objective, about the data, and about the available tools, the user breaks the objective down to manageable subobjectives. Then he or she develops a plan, which is a sequence of actions that he or she believes will solve the subobjective and thus will advance towards addressing the overall objective.6,11 This planning is guided but also limited by the affordances of the tool(s) used. Such a tool is typically a visualization artifact providing interaction with visual representations and models of data. Nevertheless, we should keep in mind that in many realistic data analysis application contexts users have a range of possible tools at their disposal, e.g. other computing systems, pen and paper, or mental models.
The user performs the planned actions by activating a number of events in the visualization user interface that are interpreted by interaction techniques. 15 For example, panning using a scrollbar involves a mouse-down event, several mouse-drag events, and a mouse-up event. Still, we focus on actions as the discrete steps that represent the lowest level of activity of which the user is consciously aware. Above actions we consider action sequences and action patterns as frequently occurring sequences, e.g. sort, then select the top 10. With experience, users can learn strategies involving such action patterns as generic and low-level plans to solve common subobjectives with a tool or family of tools. 17
While performing these actions, the user collects findings—potentially interesting observations from the data. Insights arise from accumulating these findings and setting them in context with the objective and knowledge. 30 These insights often lead to an update of the plan as the user develops hypotheses that make new subobjectives relevant. Furthermore, the plan will be iteratively updated as the background knowledge, the availability of tools, or even their goals can change.6,16,25,28,34
Implications for design and evaluation
Above, we observed, from the users’ point of view, concrete objectives and actions in the visualization process. While users can abstract their objective breakdown and action planning from one situation to another and from one visualization artifact to another, abstraction plays an even more important role for visualization design and evaluation. Here, theoretical frameworks serve as bonds between individual research contributions and general guidelines for the visualization discipline. Next, we will walk through different scenarios of visualization design and evaluation, describe the role of objectives and actions, and give examples.
RelEx, an example study conducted in automotive engineering, 35 described objectives at three levels of composition: the high-level objective of “traffic optimization on the signalpath network” in domain terms, mid-level objectives being abstracted to general features of social networks, and low-level objectives as queries on network relations. Another study in IT security 36 classified the objective of malware pattern analysis along the three-level why-typology of Brehmer and Munzner. 13 Both studies analyze objectives in context of the data and users as proposed by Miksch and Aigner. 3
The RelEx design study 35 illustrates how design rationale is based on clearly formulated user objectives. Based on the objectives cited above, they analyzed existing tools and postulated design requirements—in particular the requirement for rich exploration of complex, multi-way relations. RelEx meets this requirement with brushing and linking in multiple coordinated views, especially a signalpath view for 4-way relations. Likewise, the LiveGantt design study 38 tackles the objective of what-if questions in scheduling by drag and drop actions in its Gantt chart view. The ChronoLenses technique 39 addresses two objectives: (T1) single data stream transformation such as removing trends and (T2) cross-data stream analysis such as comparing two streams. These two tasks result in two types of interactive lenses.
Depending on the study’s hypotheses, a suitable composition level must be found because low-level objectives can be too trivial and high-level objectives too open-ended for quantitative analysis of time and errors. For such experiments other evaluation methods, e.g. qualitative analysis of insights,40,41 are more suitable.
Research hypotheses are often specific to an abstract objective such as ‘less errors for comparison’, whereas stimuli need to present concrete objectives that act as representative examples for the abstract objective. In some cases a concrete objective is also translated to a concrete objective in a different domain so that a sufficiently large population of test persons can be recruited. Each occasion a test person works on such a concrete objective is called trial 42 p.298. Repeated trials with multiple test persons or multiple data (sub)sets are needed to reach statistical power. For example, Javed et al. 43 experimentally compared four visualization techniques for time series by the performance of solving comparison, slope, and discrimination objectives. The SemanticTimeZoom technique 44 was evaluated using 12 objectives, which were categorized based on the Andrienko and Andrienko 10 objective framework.
For example, the experiment of Dou et al. 45 demonstrated to what extent analytical reasoning can be inferred from interaction logs alone. They noted that such inference worked best for highly interactive artifacts but worse when users got along with looking at visual representations. Another example study by Pohl et al. 17 compared the interaction logs from user studies of two visualization artifacts of the same target audience, medical doctors, to identify interaction patterns up to a length of three actions and transition probabilities between actions. In order to make actions comparable, they used the Yi et al.’s user intents 18 for abstraction.
Categorizations of abstract tasks
Beyond individual visualization design and evaluation projects, tasks are useful for systematic research in visualization. Thus, a number of theoretical frameworks that categorize abstractions of objectives and actions have been conceived. These frameworks are valuable in making the results of empirical research comparable and extracting design guidelines from visualization work.
State-of-the-art reports, in particular, can apply such categorizations to describe and systematically compare visualization artifacts. The objectives addressed and the actions provided allow these reports to structure the surveyed area, to identify similarities not evident from the original description of each individual artifact, to provide design guidance, and even to generalize beyond the scope of the report. Although, it is not uncommon for state-of-the-art reports to develop a customized task categorization for its scope. For example, Alsallakh et al. 52 categorized set visualization techniques using a list of 26 low-level objectives specific to set-typed data. Dealing with visualization systems for electronic health records, Rind et al. 53 extended the user intent categorization 18 with 20 more concrete subintents and used these for categorization.
Yet, the number of task categorizations can be confusing and in addition the abstract tasks found therein are quite heterogeneous. This is also illustrated in the typology of Brehmer and Munzner 13 that reclassifies abstract tasks from a wide range of existing categorizations. For example, it maps the abstract tasks by Shneiderman 46 to produce, summarize, navigate, filter, and record. Thus, they occur for both why and how as well as at different levels of their typology. Therefore, we propose to use the dimensions of the task cube to classify and compare these categorizations of abstract tasks.
Survey of abstract objective and action categorizations found in theoretical task frameworks, state-of-the-art reports, and domain characterization studies (not exhaustive).
The why and how columns denote whether the categorization describes objectives or actions. Three composition levels are distinguished: HI. . . high, IN. . . intermediate, and LO. . . low, and four types of abstraction: GE. . . generic, DA. . . data type, DO. . . domain, and TO. . . tool architecture. The symbol • denotes the primary class of the entry and the symbol ○ represents a partial match, for example if only a few categories fall into this class. The final column describes the expressiveness of the entry by the number of categories or similar details.
Schulz et al.’s five-dimensional space 27 has four dimensions relating to why (goal, characteristics, target, cardinality) and one for how (means).
Yi et al. 18 categorized interaction techniques along user intent. Nevertheless their objectives are characterized very similar to actions, e.g. “show me something conditionally” is almost equivalent to a filter action.
The taxonomy of Valiati et al. 64 mixes objectives like “identify patterns” with actions like “zoom”.
For composition, we identify only few categorizations for high-level objectives. For example, explore/confirm/present are regularly used categories. Alternatively, Amar and Stasko 55 presented the prototypical tasks of “complex decision making, especially under uncertainty”, “learning a domain”, “identifying the nature of trends”, and “predicting the future”. This is not unexpected as real-world high-level objectives can be very specific to a domain problem. Many objective categorizations can be positioned at intermediate-level, low-level, or both. These ambiguities results from some categorizations having a broad scope (e.g. elementary versus synoptic tasks 10 ) and that their abstract objectives can describe for various real-world objectives at these composition levels. Action categorizations are at a mostly low composition level, which is obvious because characteristic sequences of actions are specific to the concrete situations they emerged from. For this reason, there is also no abstract task frameworks for high-level actions. A few categorizations encompass intermediate-level actions such as ‘overview’ and ‘relate’ 46 or ‘cognitive offloading’. 68
Among the four types of abstraction, generic abstractions are most common for objectives (12) and actions (8). This can be explained by the fact that our survey is not exhaustive of the task categorizations collected for state-of-the-art reports and design studies. Still there is a large proportion of objective categorizations tailored by data type (9)—most frequently networks and/or time.
Discussion
We looked at the task cube from various angles of visualization design, evaluation, and research in the previous sections. Reflecting on the dimensions of the task cube, we now observe some general implications.
Likewise, objectives can be broken down to increasingly lower levels. However, decomposition into trivially small subobjectives, such as ‘read value 1, read value 2 . . .’, is often not practical and differs from how users realistically solve objectives. Combining human perception and visualization techniques, they can detect patterns at a larger scope. For example, they can spot clusters in a scatter plot or judge the trend in a line plot without consecutively reading the values encoded for individual data records. Therefore, it is important to consider objectives at an adequate level of composition, in particular when evaluating visualization techniques.
This intellectual interest in objectives and their many-to-many mapping to action sequences are our motivations to distinguish between the perspectives why and how. They are also a major difference to the traditional view of tasks in HCI that follows the assumption of a one-to-one mapping between these perspectives. 29 Yet, such an assumption holds only for operational tasks and not for such creative tasks as they are needed for the open-ended objectives addressed by visualization.71,72
However, we agree with Miksch and Aigner, 3 Munzner, 4 Andrienko and Andrienko, 10 and many other visualization experts that tasks are a useful concept for evaluation throughout visualization design and development. Yet, we propose to use the more precise terminology of ‘objectives’ and ‘actions’ instead of the ambiguous term ‘task’. Furthermore, we recommend understanding perspective, level of composition, and level of abstraction as non-redundant dimensions. While these dimensions are clearly distinct in a theoretical view of the conceptual space, it can be difficult to separate them in practice. This is also reflected in a number of ambiguities in our survey of abstract task categorizations. However these ambiguities might also be inherent as a 3D-covariance that deserves deeper investigation.
Conclusions and future work
In this paper we critically analyzed the usage of the term ‘task’ in visualization and human-computer interaction literature. We propose using ‘objective’ and ‘action’ as a more suitable terminology that reduces ambiguity and allow visualization researchers to better formulate their contributions. In addition, we identified a three-dimensional conceptual space of user tasks in visualization with abstraction, composition, and perspective as orthogonal dimensions. We looked at objectives and action in a concrete visualization process in various visualization design and evaluation scenarios, and in state-of-the-art surveys and theoretical frameworks. Finally, we emphasized the usefulness of tasks, the importance of choosing adequate composition levels, and focusing on open-ended objectives.
Concluding this article, we can identify two important areas for future research. First, to supply the visualization community with design guidelines, 37 we need not only further empirical work but also need to abstract, aggregate and compare these results. Second, tasks and in particular objectives are important to visualization as a objective-driven process. Therefore, visualization artifacts should take users’ intents into account either from explicit input or by auto-detection.
Footnotes
Acknowledgements
We thank the anonymous reviewers, the participants of BELIV 2014, and Bilal Alsallakh for their feedback and suggestions.
Funding
This work was supported by the Austrian Science Fund FWF [grant numbers P25489, P22883], the Austrian Federal Ministry for Transport, Innovation and Technology [grant number 845598], and the Austrian Federal Ministry of Science, Research and Economy [grant number 822746].
