1077-2626/13/$31.00 © 2013 IEEE Published by the IEEE Computer Society
Accepted for publication by IEEE. ©2013 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/
republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
A Multi-Level Typology of Abstract Visualization Tasks
Matthew Brehmer and Tamara Munzner, Member, IEEE
Abstract—The considerable previous work characterizing visualization usage has focused on low-level tasks or interactions and high-
level tasks, leaving a gap between them that is not addressed. This gap leads to a lack of distinction between the ends and means
of a task, limiting the potential for rigorous analysis. We contribute a multi-level typology of visualization tasks to address this gap,
distinguishing why and how a visualization task is performed, as well as what the task inputs and outputs are. Our typology allows
complex tasks to be expressed as sequences of interdependent simpler tasks, resulting in concise and flexible descriptions for tasks
of varying complexity and scope. It provides abstract rather than domain-specific descriptions of tasks, so that useful comparisons
can be made between visualization systems targeted at different application domains. This descriptive power supports a level of
analysis required for the generation of new designs, by guiding the translation of domain-specific problems into abstract tasks, and
for the qualitative evaluation of visualization usage. We demonstrate the benefits of our approach in a detailed case study, comparing
task descriptions from our typology to those derived from related work. We also discuss the similarities and differences between our
typology and over two dozen extant classification systems and theoretical frameworks from the literatures of visualization, human-
computer interaction, information retrieval, communications, and cartography.
Index Terms—Typology, visualization models, task and requirements analysis, qualitative evaluation
1 INTRODUCTION
Consider a person who encounters a choropleth map while reading a
blog post in the aftermath of last year’s American presidential election.
This particular map is static and visually encodes two attributes, can-
didate and margin of victory, encoded for each state using a bivariate
colour mapping. This person decides to compare the election results
of Texas to those of California, motivated not by an explicit need to
generate or verify some hypothesis, nor by a need to present the vi-
sualization to an audience, but rather by a casual interest in American
politics and its two most populous states. How might we describe this
person’s task in an abstract rather than domain-specific way?
According to the nested model for visualization design and vali-
dation [43], abstract tasks are domain- and interface-agnostic opera-
tions performed by users. Disappointingly, there is little agreement
as to the appropriate granularity of an abstract task among the many
extant classifications of user behaviour in the visualization, human-
computer interaction, cartography, and information retrieval litera-
ture [2, 3, 5, 10, 11, 12, 13, 14, 15, 19, 23, 29, 31, 37, 39, 42, 50,
51, 56, 57, 59, 61, 64, 66, 72, 73, 75, 78, 82, 83]. One of the more fre-
quently cited of these [2] would classify the above example as being a
series of value retrieval tasks. This low-level characterization does not
describe the user’s context or motivation; nor does take into account
prior experience and background knowledge. For instance, a descrip-
tion of this task might differ if the user was unfamiliar with American
geography: the user must locate and identify these states before com-
paring their values. Conversely, high-level descriptions of exploratory
data analysis and presentation emanating from the sensemaking liter-
ature [3, 11, 31, 51] cannot aptly describe this user’s task.
The gap between low-level and high-level classification leaves us
unable to abstractly describe user tasks in a useful way [41], even for
the simple static visualization in the above example. This gap widens
when interactive visualization is considered, and the complexity of its
usage is compounded over time. We must move beyond describing a
single task in isolation, to a description that designates when one task
ends and another begins. To close this gap, visualization tasks must be
• Matthew Brehmer is with the University of British Columbia. E-mail:
brehmer@cs.ubc.ca.
• Tamara Munzner is with the University of British Columbia. E-mail:
tmm@cs.ubc.ca.
Manuscript received 31 March 2013; accepted 1 August 2013; posted online
13 October 2013; mailed on 4 October 2013.
For information on obtaining reprints of this article, please send
e-mail to: tvcg@computer.org.
describable in an abstract way across multiple levels.
The primary contribution of this paper is a multi-level typology
of abstract visualization tasks that unites the previously disconnected
scopes of low-level and high-level classification systems by propos-
ing multiple levels of linkage between them. Our typology provides
a powerful and flexible way to describe complex tasks as a sequence
of interdependent simpler ones. While this typology is very much in-
formed by previous work, it is also the result of new thinking and has
many points of divergence with previous models. Central to the orga-
nization of our typology are three questions that serve to disambiguate
the means and ends of a task: why the task is performed, how the task is
performed, and what are the task’s inputs and outputs. We have found
that no prior characterization of tasks satisfactorily answers all of these
questions simultaneously at multiple levels of abstraction. Typically,
low-level classification systems provide a sense of how a task is per-
formed, but not why; high-level classification systems are the converse.
One major advantage of our typology over prior work is in providing
linkage between these two questions. Another advantage is the ability
to link sequences of tasks, made possible by the consideration of what
tasks operate on.
Our typology provides a consistent lexicon for description that sup-
ports making precise comparisons of tasks between different visual-
ization tools and across application domains. Succinct and abstract
descriptions of tasks are crucial for analysis of visualization usage.
This analysis is an essential precursor to the effective design and eval-
uation of visualization tools, particularly in the context of problem-
driven design studies [60]. In these studies, visualization practitioners
work with users to identify why and what, subsequently drawing from
their specialized knowledge of visual encoding and interaction tech-
niques to design how that task is to be supported [41]. A need for
task analysis also arises in visualization evaluation [34], particularly
in observational studies of open-ended visualization usage. Our typol-
ogy provides a multi-level code set for qualitatively describing user
behaviour in such studies.
As we expect some readers to be unfamiliar with the context that
motivated this work, we begin with a brief discussion of our current
inability to succinctly describe and analyze visualization tasks. In Sec-
tion 3 of this paper, we introduce our multi-level typology of abstract
visualization tasks. In Section 4, we demonstrate the benefits of our
approach with a detailed case study, in which we describe a sequence
of interdependent tasks. In Section 5, we summarize our typology’s
connections to related work and to its theoretical foundations. In Sec-
tion 6, we discuss the value and usage of this typology, as well as our
plans for its further validation and extension. In Section 7, we offer
our concluding remarks.
2 BACKGROUND CONTEXT
The primary limiting factor in using extant classification systems as
tools for analysis is that we cannot easily distinguish between the ends
and means of tasks. Making this distinction is a central problem for
practitioners during the abstraction phase of design studies [60] and
during the analysis phase of qualitative user studies [34].
For instance, a number of extant classification systems mention the
word derive [2, 14, 23, 37, 50, 66]. Is derive a task, or the means
by which another task is executed? A user may derive data items as
an end in itself, for example to reduce the number of dimensions in a
dataset, or as a means towards another end, such as to verify a hypoth-
esis regarding the existence of clusters in a derived low-dimensional
space. The ends-means ambiguity exists for many terms found in ex-
tant classification systems: consider filter [2, 11, 19, 23, 29, 31, 37,
42, 50, 51, 57, 61, 82], navigate [23, 64, 75], or record [23, 42, 66].
The first step towards distinguishing ends from means involves asking
why a task is performed separately from how a task is performed, a
question that is central to the organization of our typology.
The separation of why and how does not in itself resolve all con-
fusion. Consider sort, another term appearing in extant classification
systems [2, 19, 23, 37, 50]. Sorting has an input and an output; in
some cases, it is items of data within a single view [55]; in others,
views themselves may be sorted [8]. In both cases, the sorted output
can serve as input to subsequent tasks. The next step in distinguish-
ing ends from means is thus characterizing what the task’s inputs and
outputs are, allowing us to describe sequences of interdependent tasks.
To illustrate how the ends-means ambiguity arises during the course
of analysis, we will now attempt to use representative extant classifi-
cation systems to describe two example tasks:
Example #1: recall the example stated in the paper’s introduction, that
of a casual encounter with an electoral map in which a user compares
two regions; election results for each state are encoded as a choropleth
map based on two attributes, candidate and margin of victory. Further-
more, we know that this user is familiar with American geography and
its regions; this prior knowledge dictates the type of search.
Using the typology of Andrienko and Andrienko [5], we might de-
scribe this example as an elementary direct comparison task. While
richer than a series of retrieve value tasks [2], this description tells us
little about why and how this comparison was performed. Low-level
descriptions derived from a number of other classification systems are
similarly impoverished [12, 19, 59, 73, 78, 82, 83].
We might enrich our description of this task using Roth’s recent
taxonomy of cartographic interaction primitives [57], a much more
comprehensive approach that distinguishes between goals, objectives,
operators, and operands. Using his taxonomy, this task would be de-
scribed as follows:
goals: objectives: operators: operands:
procure compare retrieve; attribute–in–space
calculate (search target);
general (search level)
While the dimensions of this description are similar to the questions
of why, how, and what, the description is incomplete, particularly in
its classification of goals and objectives. Roth’s taxonomy provides us
only with a partial sense of how the comparison is performed: retrieve
does not tells us about whether the user knows the spatial location of
the regions to be compared a priori. The goal, procure, does not pro-
vide us with any higher-level context or motivation for why the user
is procuring; specifically, the user’s casual interest in these two re-
gions is lost. Finally, Roth’s taxonomy imposes a spatial constraint on
operands, leaving us unable to fully articulate what is being compared.
Example #2: in evaluation studies [34], it is sometimes necessary to
perform a comparative analysis of a task being performed using differ-
ent visualization systems. Consider a user of a tree visualization tool
who whose interest relates to two nodes in a large tree, and her intent
is to present the path between these nodes to her colleagues. Space-
Tree [20] and TreeJuxtaposer [46] are two tree visualization tools that
allow users to locate paths between nodes by means of different focus
+ context techniques. Both systems allow for path selection, in which
the encoding of selected paths differs from that of non-selected paths.
The systems differ in how elements of the visualization are manipu-
lated: TreeJuxtaposer allows the user to arrange areas of the tree to
ensure visibility for areas of interest, while SpaceTree couples the act
of selection by aggregating and filtering unselected items.
As in the previous example, task descriptions from extant classifica-
tion systems seldom answer all three questions: why, how, and what.
Using Heer and Shneiderman’s taxonomy of interactive dynamics for
visual analysis [23], we might describe this task as being an instance
of data and view specification (visualize and filter) as well as view ma-
nipulation (navigate and select). This description tells us how, but it
doesn’t specify why the task is performed.
We might complement Heer and Shneiderman’s description with
one based on Lee et al.’s taxonomy of graph visualization tasks [37],
in which this task would be classified as a topology task, namely one
of determining connectivity and subsequently finding the shortest path.
As the scope of Lee et al.’s taxonomy is specialized, we are provided
with a clear indication of what the user’s interest is, this being a path.
Unfortunately, this description provides only a partial account of why
the task is performed; we are not provided with a high-level motivation
beyond determining and finding.
Both descriptions do not relate the user’s actions to the high-level
goal of presenting information to others. Second, and more impor-
tantly, these descriptions fail to distinguish how this task is performed
using SpaceTree from how it is performed using TreeJuxtaposer.
Summary: these examples demonstrate our inability to comprehen-
sively analyze tasks using state-of-the-art systems for classifying user
behaviour. Note that we are not directly criticizing these classification
systems; we acknowledge that their scope is often deliberately con-
strained, with some focusing on low-level tasks, interactions, or opera-
tions [2, 5, 10, 12, 13, 14, 15, 19, 29, 37, 59, 61, 72, 73, 75, 78, 82, 83],
while others focus on high-level tasks or goals [3, 11, 31, 39, 51], or
on user behaviour in specialized domains [37, 57, 65]. We lack guid-
ance on how to integrate these disjoint bodies of work, to compose
task descriptions that draw from all of them. This integration is the
aim of our typology, which will allow practitioners to describe tasks
that address critical questions posed during visualization design and
evaluation, namely why, how, and what.
It could be argued that a classification of tasks should focus solely
on the goal of the user, or why visualization is used; users are often not
immediately concerned with how a task is performed, as long as their
task can be accomplished. We argue that by classifying tasks accord-
ing to how they are performed, in addition to why they are performed
and what they pertain to, we can improve communication between vi-
sualization practitioners working in different application areas, facil-
itating tool-independent comparisons, the analysis of diverging usage
strategies for executing tasks [74, 84], and improved reasoning about
design alternatives.
3 TYPOLOGY OF ABSTRACT VISUALIZATION TASKS
Our multi-level typology of abstract visualization tasks, represented
in Figure 1, is encapsulated by three questions: why the task is per-
formed, how the task is performed, and what does the task pertain
to (Figures 1a-c). Complete task descriptions, such as those for Ex-
amples #1-2 (represented in Figure 2), must include nodes from all
three parts of this typology. We denote this work as a typology, rather
than a taxonomy, as the former is appropriate for classifying abstract
concepts, while the latter is appropriate for classifying empirically ob-
servable events [6].
This structure, while unusual relative to many extant classification
systems, mirrors the analytical thinking process undertaken in design
studies [41, 43, 60]. Why, what, and how are also used in Cogni-
tive Work Analysis [74], particularly for relating abstractions within
a work domains, as well as in Aigner et al.’s analysis of techniques
and systems for visualizing time-oriented data [1], which asks what is
presented?, why is it presented?, and how is it presented?.
We will introduce why before how, as this order reflects the trans-
lation of empirically observable domain problems into abstract tasks
and subsequently into design choices: practitioners first identify why
why?
present
discover
generate / verify
enjoy
lookup
locate
browse
explore
produce
identify compare summarize
target known target unknown
location unknown
location known
query
consume
search
how?
annotate
import
derive
record
select
navigate
arrange
change
filter
aggregate
encode
manipulate introduce
what?
[ input ]
[ output ]
(if applicable)
a b
c
Fig. 1. Our multi-level typology of abstract visualization tasks. The typology spans why, how, and what; task descriptions are formed by nodes from
each part: a) why a task is performed, from high-level (consume vs. produce) to mid-level (search) to low-level (query). b) how a task is executed
in terms of methods, defined as families of related visual encoding and interaction techniques. c) what the task inputs and outputs are.
a task is to be performed, and then must decide upon how the task is
to be supported. We then discuss the what part of our typology, which
considers the input and output of tasks. Our typology supports the
description of complex visualization usage as a sequence of interde-
pendent tasks, where the output of a prior task may serve as the input
to a subsequent task, as we demonstrate in the case study of Section 4.
For clarity, we first present our typology in its entirety with minimal
discussion of the previous work that informed its organization, and
then focus on these connections in Section 5 and in Table 1.
3.1 Why?
The why part of our typology, shown in Figure 1a, allows us to describe
why a task is performed, and includes multiple levels of specificity, a
narrowing of scope from high-level (consume vs. produce) to mid-
level (search) to low-level (query).
Consume: Visualizations are used to consume information in many
domain contexts. In most cases this consumption is driven by either a
need to present information or to discover and analyze new informa-
tion [79]. However, there are many other contexts in which visualiza-
tions are simply enjoyed [17, 54, 65], where users indulge their casual
interests in a topic.
Present refers to the use of visualization for the succinct com-
munication of information, for telling a story with data, guiding an
audience through a series of cognitive operations. Presentation using
visualization may take place within the context of decision making,
planning, forecasting, and instructional processes [18, 40, 57]. Pre-
sentation brings to mind collaborative and pedagogical contexts, and
the means by which a presentation is given may vary according to the
size of the audience, whether the presentation is live or pre-recorded,
and whether the audience is co-located with the presenter [32].
Discover is about the generation and verification of hypotheses,
associated with modes of scientific inquiry [50]. Scientific investiga-
tion may be motivated by existing theories, models, and hypotheses,
or by the serendipitous observation of unexpected phenomena [4].
Enjoy refers to casual encounters with visualization [54, 65]. In
these contexts, the user is not driven by a need to verify or gen-
erate a hypothesis; novelty stimulates curiosity and thereby explo-
ration [16, 65, 67, 69]. This motivation is notably absent from pre-
vious classification systems, as shown in Table 1. Casual encounters
with visualization can be fleeting, such as in the earlier example of en-
countering a static choropleth electoral map while reading a blog post.
Conversely, these encounters might be immersive and time-consuming
experiences, such as in museum settings [54].
Produce: we use produce in reference to tasks in which the in-
tent is to generate new artefacts. These artefacts include but are not
limited to: transformed or derived data, annotations, recorded visual-
ization interactions, or screen shots of static visualizations. Examples
of produce in previous work include the production of graphical
annotations and explanatory notes to describe features of time-series
graphs [81], or the production of graphical histories in Tableau [21],
the latter being meta-visualizations intended to improve users’ analyt-
ical provenance. Additional examples of produce involving derived
data and annotations are featured in the case study of Section 4.
It is important to note that the products of a produce task may
be used in some subsequent task that may or may not involve visu-
alization. For example, some visualization tools for analyzing high-
dimensional data allow users to produce new categorical attributes
for labelling clustered data points in a dimensionally-reduced coor-
dinate space; these attributes might be used later for constructing a
predictive model.
Search: Regardless of whether the intent is to present,
discover, or merely enjoy, the user must find elements of interest
in the visualization. While terms relating to search and exploration
are often conflated [40, 69], we have imposed a characterization of
search that depends on what is being sought. We classify them accord-
ing to whether the identity or location of the search target is known a
priori. Whether the identity of the search target is known recalls An-
drienko and Andrienko’s concept of references and characteristics [5]:
searching for known reference targets entails lookup or locate,
while searching for targets matching particular characteristics entails
browse or explore. Consider our earlier example of a user who is
familiar with American geography and is searching for California on
an choropleth map; we would describe this as an instance of lookup.
However, a user who is unfamiliar with American geography must
locate California.
In contrast, the identity of a search target might be unknown a pri-
ori; the user may be searching for characteristics rather than refer-
ences [5]; these characteristics might include particular values, ex-
tremum, anomalies, trends, or ranges [2]. For instance, if a user of
a tree visualization is searching within a particular subtree for leaf
nodes having few siblings, we would describe this as an instance of
browse because the location is known a priori. Finally, explore
entails searching for characteristics without regard to their location,
often beginning at an overview level of the visualization [37]. Ex-
amples include searching for outliers in a scatterplot, for anomalous
spikes or periodic patterns in a line graph of time-series data, or for
unanticipated spatially-dependent patterns in a choropleth map.
Query: Once a target or set of targets has been found, a user will
identify, compare, or summarize these targets. If a search re-
turns known or reference targets [5], either by lookup or locate,
identify returns their characteristics. For example, a user of a
choropleth map representing election results can identify the win-
ning candidate and margin of victory for the state of California. Con-
versely, if a search returns targets matching particular characteristics,
either by browse or explore, identify returns references. For
instance, our election map user can identify the state having the
highest margin of victory.
The progression from identify to compare to summarize
corresponds to an increase in the amount of search targets under
consideration [5, 10, 72], in that identify refers to a single tar-
get, compare refers to multiple subsets of targets, and summarize
refers to a whole set of targets. As with explore, summarize is
also often associated with overviews of the data [37]. Continuing with
the choropleth map example, a user identifies the election results
for one state, compares the election results of one state to another, or
summarizes the election results across all states, determining how
many favoured one candidate or the other, or the overall distribution
of margin of victory values.
3.2 How?
We now turn our consideration to the how part of our typology,
which contains methods, defined as families of related visual en-
coding and interaction techniques [45]. This part of our typology,
shown in Figure 1b, is likely to be most familiar to readers, as
it contains a number of methods associated with interaction tech-
niques that are well-represented by several extant classification sys-
tems [19, 42, 57, 82]. We distinguish between three classes of meth-
ods: those for encoding data, those for manipulating existing
elements in a visualization, and those for introducing new ele-
ments into a visualization.
Encode: the majority of visualization tasks rely on how data is ini-
tially encoded as a visual representation. A full enumeration of visual
encoding techniques for various data types in terms of methods is be-
yond the scope of this paper and appears elsewhere [45].
Manipulate: the following methods affect existing elements of a vi-
sualization, modifying them to some extent. These methods represent
families of interrelated techniques incorporating both interaction and
visual encoding. We consider visual encoding and interaction tech-
niques in a unified way because many methods incorporate aspects of
both [41, 43], such as focus + context techniques [20, 46].
Select refers to the demarcation of one or more elements in a
visualization, differentiating selected from unselected elements [56].
Examples range from directly clicking or lassoing elements in a sin-
gle visualization to brushing methods used to highlight elements in
visualization systems incorporating multiple linked views [77].
Navigate methods include those that alter a user’s viewpoint,
such as zooming, panning, and rotating. Other methods trigger details-
on-demand views, combining navigate and select [61].
Arrange refers to the process of organizing visualization elements
spatially. Some of these methods arrange representations of data [39,
42, 80], such as reordering the axes in a parallel coordinates plot or the
rows and columns of a scatterplot matrix. Other methods allow users
to coordinate the spatial layout of views [23, 77].
Change pertains to alterations in visual encoding. Simple exam-
ples include altering the size and transparency of points in a scatterplot
or edges in a node-link graph, altering a colour-scale or texture map-
ping, or transforming the scales of axes. Other methods have more
pronounced effects, changing the chart type altogether, such as tran-
sitioning between grouped and stacked bar charts, or between linear
and radial layouts for time-series graphs. Pronounced changes in vi-
sual encoding such as these are often facilitated by smoothly animated
transitions, which reduce their disruptive effects [22].
Filter methods adjust the exclusion and inclusion criteria for el-
ements in a visualization. Some methods allow for elements to be
temporarily hidden from view and later restored, while other methods
are synonymous with outright deletion. As an example of temporary
filtering, consider a user examining an age histogram based on pop-
ulation census data. First, she decides to exclude males, then further
adjusts her filter criteria to focus solely on unemployed females. Fi-
nally, she revises the gender criteria to focus on unemployed males.
A common example of permanent filtering, or deletion, is that of
manually selecting and removing outliers resulting from errors in data
entry. Alternatively, consider a scatterplot in which some points are la-
belled with manually generated categorical tags. Deleting a tag would
remove this categorical label from all points having that tag.
Aggregate concerns methods that change the granularity of visu-
alization elements. As such, we also consider its converse, segregate,
as being associated with this family of methods. For example, a user
may adjust the granularity of a continuous time scale in a line graph,
aggregating daily values into monthly values, or segregating annual
values into quarterly values. Alternatively, a user may aggregate a
clique within a node-link diagram into a representative glyph, or seg-
regate clique glyphs into their component nodes.
Introduce: While manipulate methods alter existing elements of the
visualization, introduce methods add new elements.
Annotate refers to the addition of graphical or textual annotations
associated with one or more visualization elements. When an annota-
tion is associated with data elements, an annotation could be thought
of as a new attribute for these elements. The earlier example of man-
ually tagging points in a scatterplot with categorical labels is one such
instance of annotating data.
Import pertains to the addition of new elements to the visualiza-
tion, including new data elements. In some environments, these new
data elements might be loaded from external sources, while others
might be manually generated.
Derive methods compute new data elements given existing data
elements. Aggregating data often implies deriving data, however this
may not always be true: we further specify that derived data must be
persistent, while aggregated data need not be. For instance, a user
might derive new attributes for tabular data using a multidimen-
sional scaling algorithm.
Finally, record methods save or capture visualization elements
as persistent artefacts. As such, record methods are often associ-
ated with produce. These artefacts include screen shots, annota-
tions, lists of bookmarked elements or locations, parameter settings,
or interaction logs [63]. An interesting example of record is that of
assembling a graphical history [21], in which the output of each task
includes a static snapshot of the visualization, and these snapshots ac-
cumulate in a branching meta-visualization. Recording and retaining
artefacts such as these are often desirable for maintaining a sense of
analytical provenance, allowing users to revisit earlier states or param-
eter settings.
3.3 What?
Previous work has reached no agreement on the question of what com-
prises a visualization. Many classification systems do not address it at
all; others discuss what implicitly, as indicated by the parenthetical
terms in Table 1. Of those that classify what, some focus on the level
of the entire dataset, such as tables composed of values and attributes
or networks composed of nodes and links [61]. Others allow more
precise specification of data–attribute semantics, such as categorical,
ordinal, and quantitative [11]. A few classification systems include
not only data but also views as first-class citizens [13, 14, 23, 75].
Specific examples of what as classified in previous work include:
• Values, extremum, ranges, distributions, anomalies, clusters,
correlations [3].
• Graph-specific objects [37]: nodes, links, paths, graphs, con-
nected components, clusters, groups.
• Time-oriented primitives [1]: points, intervals, spans, temporal
patterns, rates of change, sequences, synchronization.
• Interaction operands [75]: pixels, data [values, structures], at-
tributes, geometric [objects, surfaces], visualization structures.
In this typology, we have chosen a flexible and agnostic represen-
tation of what that accommodates all of these modes of thinking: in
short, we have a “bring your own what” mentality. The only absolute
requirement is to explicitly distinguish a task’s input and output
constraints when describing sequences of interdependent tasks [72].
An extensive discussion of what that dovetails well with this typology
appears elsewhere [45], but it cannot be effectively summarized in a
few paragraphs; thus, it is beyond the scope of this paper.
3.4 Concise Task Descriptions
Our multi-level typology can be used to concisely describe visualiza-
tion tasks. Each task is defined by why it is executed, the method(s)
by which it is executed (how), and by what the task pertains to. Single
tasks may involve multiple nodes from each part of the typology, as
shown in Figure 2.
enjoy
lookup
compare
encode
values for two
known regions
example #1
present
locate
identify
encode
navigate
select
+
filter
aggregate
+
+
+
encode
navigate
select
+
arrange
+
+
SpaceTree TreeJuxtaposer
a path between
two nodes
example #2
Fig. 2. Task descriptions for Example #1 (left): casually encountering an
choropleth electoral map and comparing election results for two regions;
and Example #2 (right): presenting a path between two nodes in a large
tree using SpaceTree [20] and TreeJuxtaposer [46].
We have chosen to present these descriptions using a simple and
flexible visual notation, rather than with a formal grammar [5, 35, 72,
80]; in doing so, creating and iterating on task descriptions can be
easily integrated into existing collaborative design and ideation activi-
ties, making use of materials such as coloured sticky notes and white-
boards. A crucial aspect of these descriptions is that sequences of
interdependent tasks can be chained together, such that the output
from earlier tasks forms the input to later tasks, as discussed in the
following case study and as represented in Figure 3.
4 CASE STUDY: A SEQUENCE OF INTERDEPENDENT TASKS
Visualization tasks are seldom executed in isolation, and the output of
one task may serve as input to a subsequent task. To illustrate this type
of dependency, we present an case study in which our typology is used
to describe a sequence of interdependent tasks.
Overview [25] is a visual analytics tool for exploring large text doc-
ument collections. Overview supports the task of producing a set of
tags for semantically related documents as a new categorical attribute,
using clusters of documents as scaffolding for the discovery pro-
cess. Tags are assigned to clusters by means of annotation. How-
ever, one must first explore visualizations of the document space
and identify clusters of interest. The user is presented both with
two linked visualizations, one in which documents are encoded as
points in a scatterplot, and another in which clusters of documents
are encoded in a hierarchical tree layout. Identifying clusters
is facilitated by navigating and selecting clusters in both vi-
sualizations; upon selection, frequent document or cluster terms
and raw individual document text are shown in secondary displays.
This task too has a dependency on the result of an earlier task. Be-
fore the the data is encoded in the two visualizations, a set of two-
dimensional distances between documents must be produced: they
are derived and aggregated from the original high-dimensional
distance matrix using a multidimensional scaling algorithm.
Using our typology, we can express dependencies in which the out-
put of one task serves as the input of another, such as the relationship
between how data is derived and the choice of visual encoding tech-
nique [43]. Such dependencies are represented in Figure 3.
As in the examples of Section 2, we can compare our description
to those generated by extant classification systems. Consider Chuah
and Roth’s classification of basic visualization tasks [14], which dis-
tinguishes between three categories of operations. Using this classi-
fication, this sequence of tasks could be described as having data op-
erations (derived attributes), graphical operations (encode data), and
set operations (create set, express membership). This description does
specify how and what, but it does not express the interdependencies
within a sequence of tasks, nor does it tell us why these tasks were
performed. Neither can we easily distinguish when sets (or clusters)
are created, as this might occur before the data is encoded, such as in
the case of the cluster hierarchy, but not in the case of the scatterplot.
While the description based on Chuah and Roth’s [14] classification
is atemporal, Chi and Riedl’s operator interaction framework [13] de-
fines stage- and transformation-based operators occurring along the
visualization pipeline. Their framework does not contain a compre-
hensive list of operators, so we draw from the example operators cited
in their paper to describe this sequence of tasks as follows:
1. visualization transformation operators:
dimension reduction, cluster
2. visual mapping transformation operators:
tree layout, scatterplot
3. view stage operators:
zoom, focus, brush, details-on-demand, pick
This description does capture the interdependencies for this se-
quence of tasks, though it mischaracterizes the processes of dimension
reduction and clustering as transformations on a visualization, rather
than transformations on data, a distinction central to our definition of
derive. While this description captures up until the second task in
our description, it does not capture the final task of producing cluster
tags by means of annotation.
The description based on our typology retains the separability of
these tasks, ensuring the distinction between interim inputs and out-
puts. Another problem with descriptions generated by extant classi-
fication systems was that of coverage; the how part of our typology
includes both derive and annotate, while descriptions generated
by other classification systems could not account for the latter [2, 13],
or both [50, 61, 73, 78, 82, 83]. Finally, our description also accounts
for both why data is derived and why clusters are annotated with
tags, whereas descriptions generated using extant classification sys-
tems mention how a task is performed in relation only to when it is
performed [13] or to what it is performed on [14]. We maintain that
a task description requires why, how, and what; the question of when
for a sequence of interdependent tasks is best served by denoting task
input and output.
5 CONNECTIONS TO PREVIOUS WORK
Our typology was informed in part by related work, including extant
classification systems and established theoretical models, and in part
by new thinking with many points of divergence from previous work.
We surveyed work relating to tasks and models of user behaviour,
spanning the research literature in visualization, visual analytics,
human-computer interaction, cartography, and information retrieval.
We focus on two subsets that informed the configuration of our typol-
ogy: thirty works that explicitly contribute a taxonomy, typology, char-
acterization, framework, or model of tasks, goals, objectives, inten-
tions, activities, or interactions [2, 3, 5, 10, 11, 12, 13, 14, 15, 19, 23,
29, 31, 37, 39, 42, 50, 51, 56, 57, 59, 61, 64, 66, 72, 73, 75, 78, 82, 83],
along with twenty other references that make compelling or notewor-
thy assertions about user behaviour [1, 4, 16, 17, 18, 27, 40, 44, 52,
54, 58, 65, 63, 67, 70, 69, 71, 79, 76, 80]. The similarities between
the individual nodes of our typology and those of extant classification
systems and other related work are presented in detail in Table 1.
![Fig. 3. Use of Overview [25], a visual analytics tool for exploring large text document collections, entails a sequence of interdependent tasks. Note that task 1a and task 1b can occur in either order, and that task 2 has a dependency on both of these tasks.](/figures/fig-3-use-of-overview-25-a-visual-analytics-tool-for-ea8psy6d.webp)
![Fig. 2. Task descriptions for Example #1 (left): casually encountering an choropleth electoral map and comparing election results for two regions; and Example #2 (right): presenting a path between two nodes in a large tree using SpaceTree [20] and TreeJuxtaposer [46].](/figures/fig-2-task-descriptions-for-example-1-left-casually-nlnyepir.webp)
