Readings 03: Abstraction

in All Readings
Something I forgot to mention explicitly (except in an announcement): The readings are meant to present viewpoints. Many weeks, I will give you a variety of different things to read with the idea of giving you multiple viewpoints. In many (most) CS/Math/Engineering classes, the readings tell you "the" answer; readings are the objective truth to refer to. With this class, many of the topics don't have a single correct answer, or have conflicting viewpoints to consider, or have some historical angle that is worth considering, ... Sometimes I will intentionally give you things I don't completely agree with because they can be thought provoking. In all cases, they are things I think you will benefit from reading. This came up in talking to a student about Tufte (last week's reading) after class. You don't have to agree with him. You should hear what he has to say and learn from it. Even if it is "don't make the same mistakes he does." This week, it is less that I don't agree with things than there are multiple answers, each differently useful (or historically relevant).

The topic for this week’s readings is Abstraction.

There are two types of abstraction we need to discuss: data abstraction and task abstration. Data abstraction should be familiar, but it is good to review the terminology. Task abstraction is a fuzzier, and more vis-specific thing. There are many different ways to think/talk about it. We’ll look at a few. There is a whole literature trying to come up with good ways to abstract tasks in visualization - there are no “right” answers, many things are useful.

Yes, there are six required readings this week. But, this is an important topic, and for all of the readings, they are things to read to get the key points without necessarily worrying about the details. You need to be able to think about data and task abstractly - the specifics of any particular abstraction are less important.

  1. (required)  The eyes have it: a task by data type taxonomy for information visualizations. Ben Shneiderman, Proceedings of the 1996 IEEE Symposium on Visual Languages (pp. 336–343). (doi) (web pdf)

    This is a classic. Possibly one of the most influencial papers in the field. It’s old, and newer things are far more extensive. And the field has moved on from 1996 in many ways. But the initial thinking of abstracting data and task separately, and suggesting what those abstractions might be, really started here. The information seeking mantra is a classic notion. This paper is a classic in the field.

  2. (required)  What: Data Abstraction (Chapter 2 from Munzner’s Visualization Analysis and Design) (Munzner-02-DataAbstraction.pdf 1.1mb)

    A fairly dry description of the types of data. Don’t worry about trying to remember all the terms - you can always look them up when you encounter them again.

    Despite it’s length, the chapter skips a key concept: level of measurement for scales. You might have learned this in a stats class, but please understand the difference between “scale types” (nominal, ordinal, interval, ratio). Usable Stats has a simple introduction.

  3. (required)  Forms and Functions (Chapter 2 of The Functional Art) (theFunctionalArtCh2.pdf 8.2mb).

    Cairo’s thinking about “the shape of data” is another way to think about data abstraction in a less academic way.

  4. (required)  Why: Task Abstraction (Chapter 3 from Munzner’s Visualization Analysis and Design) (Munzner-03-TaskAbstraction.pdf 0.4mb)

    Figuring out how to think about tasks is important. This chapter (and the research paper it is derived from) focuses too much on trying to put every task in a neat organization. What is important is to think about tasks. This is one way to do it, and it will help you learn to think about tasks. Don’t get too bogged down in all of her categories. What I’d like you to get from this is some vocabulary for thinking about what people are doing.

    We’re reading the book chapter, not the paper. If you’re going to work in the field, you might want to look at the paper A Multi-Level Typology of Abstract Visualization Tasks by Brehmer and Munzner, IEEE InfoVis 2013. The chapter is better, although the paper is notable for its extensive references and careful use of the terminology. If you want to read one paper, I recommend the Schulz et. al paper below for contrast.

  5. (required)  Michael Gleicher and a Dagstuhl working group. A Problem Space for Designing Visualization. Unplublished draft. (23-problemspace-draft.pdf 0.1mb)

    This paper promotes thinking about visualization problems (even more broadly than task) as requiring a range of considerations. It was strongly inspired by the Schulz et al. paper (listed as optional below, but strongly recommended) which promoted the idea of thinking about task as a multi-faceting thing using the “Five Ws and How” framework. At a workshop, a bunch of us liked this way of thinking, but thought it should be streamlined (in particular, so it would be useful in classes). We wanted to write a new version. I wanted the version in time for our class, so I was tasked with writing the first draft that you have here.

    Warning: this paper is a work in progress. I am in the process of writing it with a bunch of collaborators based on discussions at a workship in Dagstuhl Germany. The ideas are a team effort; it’s just at this point, I’ve done the writing to try to get something I can use in class.

    By the way “Dagstuhl” is a place in Germany where they hold workshops. Dagstuhl working group is a set of people I spent time with at a workshop this past summer.

  6. (required)  Amar, Eagan and Stasko. Low-Level Components of Analytic Activity in Information Visualization. InfoVis 2005. pdf doi

    An important paper because it tried to break down “analysis work” into low enough level tasks that can be named, and therefore designed for and evaluated. It is not a encyclopedic as things that come later - but that is a feature. In practice, we need to describe our task, well enough that we can design to address it. Having an encyclopedic taxonomy is useful for many reasons (it provides a vocabulary, a way to see similarities and differences, …). But its not the only thing.

    This is a useful contrast to the prior two task abstractions because it focuses on the low level. Any specific level is insufficient, but the low level is important.

    There is a more recent paper that basically takes this taxonomy and uses it to organization the perceptual science behind visualization. A Survey of Perception-Based Visualization Studies by Task gives a concise overview of Amar, Eagan & Stasko - and then uses it to organize the literature of perceptual studies to connect them to these tasks. You can look at that paper instead of the original (I was tempted to use it as a replacement), but the survey part does get a bit long.

Some optional readings.

This paper used to be required, but it was replaced by the “Problem Space” paper above. This paper inspired the problem space paper, and is discussed in it. I still think it is quite valuable, but the Problem Space paper (even in draft form) is more appropriate for class.

  • (optional)  Schulz, H.-J., Nocke, T., Heitzler, M., & Schumann, H. (2013). A Design Space of Visualization Tasks. IEEE Transactions on Visualization and Computer Graphics, 19(12), 2366–2375. (doi) (web pdf)

    This paper takes a quite different approach to Munzner in thinking about tasks. It came out at the same time as the paper behind the book chapter. It was literally in the same session of the conference. I actually find this to be a more useful way to think about task - it’s not as encyclopedic, but that’s a feature.

If you’re curious about the direct application of abstraction in order to build real practical tools (and a little bit of why Tableau is the way that it is)…

  • (optional)  Mackinlay, J., Hanrahan, P., & Stolte, C. (2007). Show me: automatic presentation for visual analysis. IEEE Transactions on Visualization and Computer Graphics, 13(6), 1137–44. (DOI) (pdf)

    This is a research paper, but it’s an unusual one. It’s easy to dismiss this paper as marketing for Tableau - but it really does give a sense of how good abstractions can help in choosing appropriate visualizations. It is timely, since Tableau will come up in class.

Many task taxonomies focus on what people do with specific types of visualizations (i.e., chart specific task taxonomies). These can be useful because they help connect what users do (tasks) to the available designs. I recommend this one as an example (I am biased, since we wrote it).

  • Sarikaya, A. and Gleicher, M. Scatterplots: Tasks, Data, and Designs. IEEE Transactions on Visualization and Computer Graphics, 24(1) — Jan 2018 . (web page)

    An recent paper that Alper (a former student) and I wrote. It focuses on a specific (but ubiquitous) kind of visualization, but thinks through the tasks and shows how thinking about the data properties and tasks helps suggest designs. I like this paper, but I am biased.

There are many task taxonomy papers. These two are notable because they are a bit “meta” in trying to understand the relationships amongst them.

  • (optional)  N. Kerracher and J. Kennedy. 2017. Constructing and Evaluating Visualisation Task Classifications: Process and Considerations. Computer Graphics Forum 36, 3 (2017), 47–59. (DOI)

    This paper explores how we evaluate task taxonomies. Given that we have so many, it’s a worthwhile question.

  • (optional)  Alexander Rind, Wolfgang Aigner, Markus Wagner, Silvia Miksch, and Tim Lammarsch. 2016. Task Cube: A three-dimensional conceptual space of user tasks in visualization design and evaluation. Information Visualization 15, 4 (October 2016), 288–300. DOI: https://doi.org/10.1177/1473871615621602

    This might just be yet another task classification system, but I like it because it explicitly takes on the variance we see in how papers have defined task.