Reading: Reading 5: Abstraction (at least read the Munzer Chapters before class on Monday Feb 13):
Discussion (initial posting due Monday, Feb 13): On Canvas – see the description below. Each student must make 2-3 (or more) “initial postings” providing a visualization and an analysis, as well as have some discussion around these examples. You should do a first posting Monday Feb 13, and some more later. See the description below. And please reply to at least two other posts.
Seek and Find 5: Comparison Exercise. This is part of the Design School, and it is due as normal on Friday, Feb 17.
Design School Redesign Assignment: This is due (online) Tuesday, February 14th – the night before class on Wednesday, February 15th. Remember that you also have to bring your designs on paper (2 sheets 1-before, 1-after) to class.
Description
The topic of this week is abstraction. This is a central and important topic, but one we often take for granted. It’s not as glamorous a topic to think about (as say perception, or specific design types), but it provides a critical foundation.
Since the Design School is kindof mixed in, we’ll have to shuffle the assignments a bit.
The idea of this discussion is to make sure that students understand the two key types of abstraction (Data and Task) that are critical for visualization. If you’re a computer scientist or mathemetician, you are probably pretty fluent with the concept of abstraction – even if you don’t think about it explicitly.
- Data abstraction is key because it lets us map our visualization designs to the right kinds of data. When there are mismatches, there are problems.
- Task abstraction is key because it lets us see how general solutions can map to many specific problems.
Thinking about data abstractly is easy (or seems so to me). Thinking about task abstractly is more challenging, and it’s only in the past few years has the visualization community come up with good ways to talk about it.
There are many ways to think about tasks abstractly. I haven’t seen one yet that totally nails it. Munzner’s (which actually comes from a longer paper where they have an even more complete model) is about as good as I’ve seen so far. But view it as a structure for thinking about task, not the definitive way to do it.
So this discussion assignment has the twin goals of making sure you think about data abstraction and making sure you think about task abstraction. Maybe I should make two assignments, but to keep it simpler for book-keeping, we’ll try to have it as multiple posts in one discussion.
For you intitial postings, I want you to pick a visualization (in the style of a seek and find – please either upload a picture or give a link) and:
- Describe the DATA abstractly
- Describe some TASKS concretely
- Describe these tasks more abstractly (in your own words)
- See how these tasks fit into Munzner’s taxonomy (or not)
I’d like everyone to do this for 2-3 different visualizations. Once you’ve done your first 1-2, you can look at what others have done and comment on them. Do you agree? Can you identify different tasks? Can you find different ways to abstract the tasks? For the first one you do, you won’t be able to see the others in your group – but after that, try not to duplicate (in fact, try to come up with as much diversity as you can). It is OK to pick things from the seek and finds.
If you get it “wrong” (especially for your first one) – don’t worry. Correct it by adding a comment (or if someone else does, acknowledge that you agree). Hopefully, you will get better at this with practice. For evaluating this assignment, we want to make sure you are thinking about it, and hopefully are beginning to get it right. We’ll do some in class to practice as well.
For timing: please do a first one (vis with analysis) Monday. Normally, I’d say do 1-2 (at least) more by Friday, but we also understand that this week there are the design school assignments, so it’s OK if your 1-2 more spill into the weekend.
As an example, consider the thing I did in class in my first lecture (the week I was there) in looking at the rounding errors in grades:
- The DATA are records (it’s a table) corresponding to students, although I am really only looking at two values per student: computed grade and assigned grade. Both of these are quantitative values. I think of them as interval, rather than ratio scales (i.e., it’s hard to say an A (4.0) is twice as good as a C (2.0) – it’s like temperatures). One is continuous, the other is descrete.
- The TASK I described was identifying students who were hurt by the rounding errors when we assigned the quantized grades.
- A more ABSTRACT description of this task is to identify/examine boundary cases in grouped data.
- In Munzner’s taxonomy, this might be an “Identify” Query task. (although, there are some other categories you might argue it falls into).
Evaluation: Each student must do 2-3 (you can do more). I would say “at least 2 good ones” so if you aren’t happy with your first, then do two more as you get better at it. Each student also needs to contribute to the conversation about the other examples from their group.