In case you’re wondering where grades came from…

Grading worked exactly as I said it would on the Course Policies.

For reading/discussion and seek and find, we used the scores. If you got nearly everything (missed a few, most of them complete) you got “full score” – which is the A/AB border. Each one counted for 1/3 of your grade.

The design challenges counted for the other 1/3. I computed things both weighting them evenly, and weighting them according to the number of weeks – and gave each person the one that was higher.

I then penalized people who missed a lot of the in-class assignments. (up to 1/2 grade)

I then penalized people who were chronically late. I considered anything with a day of a deadline ontime. I looked at the median lateness – if you were late more than you weren’t, there was a problem.

For people who were just below a grade boundary, I looked at the contents of your discussions and seek and finds. For a few people, I used this to give you an extra little bit if it made a difference. (it only could help)

I need to cancel office hours on Wednesday, December 13th due to travel.

If you want to schedule something earlier in the day (or week) send me email.

Week 15 (Mon, Dec 11-Fri, Dec 15) – The Finale!

• Mon, Dec 11 : Class: Topic Modeling Visualization and Serendip
• Wed, Dec 13 : Class: Summary (warning: no office hours)
• Fri, Dec 15 : No Class: Class Ends
• Reading: Week 15 – Presentations and Animation
• Discussion 15: Presentations and Animation (first post due 12/12)
• Seek and Find 15: Pick Something (due 12/15)
• Design Challenge : DC3 – Final (due 12/13)

We’ve gotten to the end of the semester.

Last week, we spoke about 3D and scientific visualization – although the two are really separate. Sadly we didn’t get to cover either in depth. Also, you (hopefully) are making good progress on design challenge 3.

This week, the topics are a little less focused. The “readings” cover two things that I wanted to get to in class, but may not get to discuss in lectures: animation and presentations. These are useful topics.

In class on Monday, we’ll talk about topic model visualization, in honor of a visitor (Prof. Eric Alexander, who got his start in visualization in the 2012 edition of this class). On Wednesday, we’ll have a “summary” lecture and I’ll talk about one of the last topics (presentations).

Remember that DC3 assignments are due on Sunday, December 17th. This is a pretty tight deadline – since I need to get grading done. (I am aware that I am behind on grading – in particular, I had hoped to get DC2 back to you).

If you haven’t already done so, please do the course evaluation aefis.wisc.edu.

Learning Goals (for this week)

This week is really “leftovers” – but these are two topics that I really want to be able to get to.

1. Appreciate the “art” of presentations, and have some ways to think about it effectively to improve your own practice.
2. Understand how animation can be used in visualization (and vice versa)

I will hold extra office hours on Friday, 11-noon (basically the class time slot). This is a chance to come and ask DC3 questions (or any other questions you might have).

I may need to cancel office hours next week – so this might be your last chance to ask questions in person.

I have added more example networks to compare for DC3.

Week 14 (Mon, Dec 4-Fri, Dec 8) – 3D and SciVis

• Mon, Dec 4 : Class: 3D
• Wed, Dec 6 : Class: SciVis
• Fri, Dec 8 : No Class:
• Reading: Week 14 – 3D and Scientific Visualization
• Discussion 14: 3D and Sci Vis (first post due 12/05)
• Seek and Find 14: 3D (due 12/08)
• Design Challenge : DC3 – Drafts (due 12/10)

Last week we talked about dimensionality reduction and graphs. We did demos for DC2 assignments (thanks again to all who participated!) And you (hopefully) all started DC3.

This week, we’ll have a completely different topic: traditional scientific visualization. However, before we get to that we need to talk about 3D. Both are topics that should be courses unto themselves. But hopefully, we can get some basics in place over the two days.

Learning Goals (for this week)

These are really two separate topics (although people often think of them together). And sadly in class, we barely get to scratch the surface of either.

1. Understand how the basics of how the human visual system “sees” 3D, and the ramifications of this for visual design.
2. Understand how different perceptual cues can be used to convey depth, and how they can be used in visual displays.
3. Appreciate when 3D should and shouldn’t be used in visualization

And for SciVis…

1. Understand the challenges of working with “traditional scientific” data sets and data types.
2. Have a basic sense of the problems of field visualization (scalar fields, vector fields, …) and the basic approaches to these problems.
3. Have an awareness of the basic approaches to the most common problems (2D scalar fields, 3D scalar fields (volume visualization), …)

Design Challenge 3 has been posted!

The sample data and code will be coming soon.

Week 13 (Mon, Nov 27-Fri, Dec 1) – Graphs

• Mon, Nov 27 : Class: High Dimensions
• Wed, Nov 29 : Class: Graph Layout, ICE
• Fri, Dec 1 : Optional Class: DC2 Demos
• Reading: Week 13 – Graphs
• Discussion 13: Graphs (first post due 11/28)
• Seek and Find 13: Graphs (due 12/01)
• Design Challenge : DC3 – Sketches (due 12/03)

Last week in class started to talk about scalability concerns, but took a pre-Thanksgiving detour to talk about DC3. We’ll discuss dimensionality reduction this coming week. And DC3 is posted (at least in draft form).

This week’s topic is graphs. Which will be useful for DC3. We’ll back up and talk about Dimensionality Reduction (because it’s an important topic, and a favorite of mine).

On Friday, December 1, there will be an optional class where you can give a demo of your DC2. This is your chance to show off what you’ve done – and see what others have done. You need to have handed in DC2 before this. (it is due on Sunday, 11/26 – and we’d prefer you turn it in and move on to DC3).

Learning Goals (for this week)

1. Understand what graph and network data is and the specific challenges of it
2. Be aware of a range of standard designs for graph data, beyond node-link diagrams
3. Appreciate the challenges of node-link layout, and have a sense of the methods available

12/6/ – sample data/code enhanced with more examples and better numbering
11/30 – added link to GitHub with sample data
11/30 – Canvas hand-in links added

The Basic Idea

The purpose of this assignment is to design visualizations that help a user compare the communication networks of groups.

For a group of people, we count the number of messages sent by each person to each other person. For every pair of people, we have the number of messages in each direction. This data is a directed graph, with links between every pair of people in both directions, and weights (counts) for each edge. Examining this data for a group, you can find patterns that tell you about how the group operates. Is the group hierarchical? Is it split into smaller subgroups? Are there people who are more or less connected?

Examining one group to determine the patterns is a graph visualization problem. Which can be tricky unto itself. But, for your assignment, you need to consider how to compare between several (two or more) groups.

Schedule

• Due Sunday, December 3rd – Initial Check In. Put something into the Canvas type-in box to let us know that you’re actually working on the assignment, and if you’re working with a partner.
• Due Sunday, December 10th – Rough Draft. Upload something (to Canvas) to give us an idea of what you plan to turn in and what you’re working on. If you turn this in on time, we will provide you with some feedback. If you’re working with a partner, one partner should turn in the files, and the other should turn in a note reminding us who your partner is.
• Due Wednesday, December 13th – official deadline. No cost extension until Sunday, December 17th (the official deadline). Note: we may not be able to accept assignments past this date. Please turn in your writeup as a PDF, and any code/data that you generated. Please include pictures created with your implementation (if you made one) and enough of a description in case we aren’t able to run your program. If you’re working with a partner, one partner should turn in the files, and the other should turn in a note reminding us who your partner is.

What You Need To Do

You may work with a partner. If you work with the partner, the requirements are the same as if you’re working by yourself. We may have slightly higher expectations of quality for pairs. Both people in a pair will get the same grade.

For this assignment you must:

1. Provide a list of tasks – being specific about which ones you are going to focus on for your designs. You will need to provide a list of at least 5 tasks.
2. Provide at least 2 designs, with full descriptions and rationales. Be sure to explain how the designs were created to address particular tasks.
3. Provide an evaluation that compares the designs you created to the baseline designs for at least 2 tasks.
4. (optional) You can provide an implementation of one or more designs that allows you to show of how your design works on varying data. If you turn in an implementation, the expectations for other parts are reduced (discussed below).

Types of Tasks

You can define your own tasks (and you should specify the tasks you are considering). But roughly, your tasks are to compare the networks. In general, you should focus on trying to help make comparisons between the patterns of communications in the network (e.g., is the group hierarchical, is it well-connected), rather than simple measurements of the messages (e.g., which group sends more messages).

The line between a simple task (e.g., which group sent more messages) and a complex one (e.g., do the groups have similar structure) is a fuzzy one. To get a good grade, focus on more complex tasks.

Hardness of Problem

The problem gets harder as you have more networks to compare.

• How big are the networks (how many people in each group)?
• How many groups to compare?
• How complex are the patterns that you are comparing?
• Note: you cannot assume the groups you are comparing are the same size!

You can choose the scale of problem that you want to address. If you pick something that is easier (e.g., comparing two groups of the same small size), you’ll need to make up for it in some other way.

A reasonable expectation is to handle a few (3-6) groups of 6-12 people. Handling larger groups (20-30) is good. Handling very large groups (100 or more) becomes a different (and seemingly harder) problem because you need to find ways to summarize the patterns.

Data

We’ll provide some example data sets as CSV files. Some examples are in a GitHub Repo. There is Python code that reads and writes the files, as well as a directory of examples written with this code (in case you don’t want to run it yourself).

Rows with no commas mark the beginning of a new group. The first token (ending with a space) is the number of people in the group. The rest of the line is a “name” for the group.

Rows with commas provide the outgoing data for a person, in the order of people listed (as the rows). People will always have 0 for their “self-messages”.

For example:

3 Group One
Alice,0,5,10
Bob,6,0,9
Carol,7,8,0
2 Group Two
Debbie, 0, 3
Elaine, 4,0

In this data file, there are two groups (separate networks to compare). The first group has three people (Alice, Bob, and Carol). Alice sent 5 messages to Bob, Carol sent 7 messages to Alice.

It is OK for you to place limitations on the number and size of the networks your implementation considers.

Baseline Design

As a baseline, consider the simplest design I can think of: showing the matrix for each of the networks. You could use color encoding to help make assessing the values a little faster (I use dark for the “max” value, and white for no messages). In the baseline, the people have a fixed order (for example, alphabetical order), and I show the different groups/networks “juxtaposed” (next to each other).

You need to come up with at least two different designs (beyond the baselines). Taking the baselines and tweaking it a little (changing the color, or even using a different encoding for each cell is not really “different”).

Re-ordering the matrix (especially if you come up with clever re-orderings to address tasks) is a different design: especially if you implement a dynamically re-orderable matrix. Coming up with  re-orderings only counts as one design. And you need at least two.

A second baseline design is to create a node-line diagram with a force directed layout. Use the number of messages between a pair of people as the “strength” of the connection, and use the force-directed layout to make the strong connections have short links.

Evaluation

You need to evaluate your designs, considering the tasks that you focus on.

Your evaluation can be a critique of the designs – try to give the relative strengths and weaknesses of different designs. You should have at least 4 (the (at least) two you came up with, and the baseline designs. Note: even if you only did a “real” implementation of one design, you should at least sketch a second design to compare against. Your designs should be different enough that they have different pros and cons.

Comparing against the baseline designs is a good way to show that you’ve solved the right problem.

Your evaluation should consider several tasks.

If you build an implementation…

You may build your implementation in any programming language and environment that you like. However, you should assume that we will not be able to run it. Therefore, be sure to include enough pictures of what it looks like (for different data sets), and enough description of what it’s like to use (especially if its interactive). Be sure to explain what tools you used for implementation, and give us instructions on how to tun it in case we decide to try.

If you do an implementation, you still must do all of the other parts of the assignment (task list, 2 designs with rationale, evaluation). However, the implementation gives you another way to excel. If you have a more minimal set of tasks, or your evaluation isn’t as thorough, you can make up for it with the implementation. In fact, showing how your implemented design(s) to address the task on different data sets is a good way to assess your design (you should still discuss the comparison with the baselines).

If you do not build an implementation…

The expectations for the other parts will be much greater. We’ll have greater expectations for your task list and analysis – both in terms of length and depth of description. We’ll expect more from your designs – in terms of number (you may want to have more than the minimum), and how well described they are (since we can’t see the implementation to figure it out). Give sketches of what it would look like for different kinds of data.

Your evaluation will have to be more about reasoning about the different designs – since you can’t provide real examples.

Analytic Measures

One way to compare graphs is to compute some “analytic measure” of them (a number that summarizes something) and compare that. For example, you can compare the total number of messages sent. There are fancier measures for more complex things, and I’m sure you could make up an “analysis measure” that measured a complex concept like “hierarchicalness” or “cliquiness.”

Using analytic measures may be a useful tool in this assignment, but the spirit of the assignment is to create visual representations. Consider: even if you had a measure of “hierarchicalness” that said that one group was more hierarchical than the other, you would need to show this structure to the viewer so they would trust/understand it.

Performing graph analysis (e.g., finding connected components or node centralities) can play a useful role in developing good visualizations. It’s not necessarily required.

Some Hints

This assignment is hard: it’s a hard data type, and the comparison nature of it makes it more challenging. I am aware of one research paper on a very related problem. But it’s for binary comparison of a different kind of weighted graph (it’s for brain connectivity). The tasks are somewhat different, they assume there is correspondences in the nodes, and that there are the same nodes in each graph. I’m not sure if this paper is helpful or not.

Alper, B., Bach, B., Henry Riche, N., Isenberg, T., & Fekete, J.-D. (2013). Weighted graph comparison techniques for brain connectivity analysis. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems – CHI ’13 (p. 483). New York, New York, USA: ACM Press. http://doi.org/10.1145/2470654.2470724 (free PDF in French Archive)

I think my strategy would be to come up with tasks by thinking about the domain problem. First think about what things you might want to see in the data for a single group, and then think about what it might mean to compare them.

One challenge in this comparison is that we don’t have correspondences. The groups have different people, and possibly different numbers of them. However, you might be able to define correspondences that will allow you to show groups in similar arrangements that will make the similarities clear.

There are many different ways to show graphs. Think about which ones are most amenable to comparison.

In class Wednesday, many people were interested in seeing what others have done for DC2. So, we’ll have a demo session in the class time slot on Friday, December 1st.

Showing off your DC2 is optional: we will grade them whether you give a demo or not. However, we will take the demo into account if you do one. It can only help you. If your assignment is better “on paper” than when you show it off, we’ll ignore the demo. If your demo is great, that can make up for other deficiencies.

Technically, we will accept late assignments on Friday – however, we will only let you do a demo if you have already turned in your assignment. We really want people moving onto DC3 (coming soon, as we discussed in class).

Some Notes:

1. If you want us to see your program running, the demos are the only way to insure we see it live. We will try to run people’s programs (especially if it’s easy to just open a web page or something). But we cannot spend too much time during grading to try to make everything go.
2. Demos aren’t limited to implementation assignments: you can show off your sketched design as well. That way you can describe the interactions you envisioned, or anything that was hard to draw.
3. In theory, I would like to be “strict” on the 5 minutes per project. 1 minute to set up, 3 minutes to show off, 1 minute for questions. In practice, it’s hard to cut off interesting questions
4. The room has a VGA connector – if you want to plug in your laptop, make sure to have an appropriate adapter (I will have a mini-DisplayPort -> VGA one). It’s probably best if you use your own laptop rather than relying on mine.
5. You can use the document camera to show off things on paper as well.