Static Recreation of Course Web for CS 765 Data Visualization

As I mentioned in class Wednesday (the benefit for those who came on time!) – there is a no-cost extension for Phase 1 of DC3 (nominally due today) for a week. However, next Friday is a hard deadline.

We’ll talk about DC3 in class on Wednesday

We encourage everyone to come to the demo session on Friday – you can learn a lot by seeing what other people have done!

For people who volunteered to do demos (the 15 people/groups who did):

• These demos are during the class time slot (11-12:15) on Friday, November 16th.
• We will be in 312 Wendt (this is the normal M/W room). Not 311 (the usual Friday room). 312 is a much better room.
• The room has an HDMI connection. I will have an HDMI cable. I also have a mini-displayport to HDMI adapter. If you need another adapter, please bring it.
• If your demo runs on the web, you can use my laptop if you like. (running Chrome). I will not install software on my laptop.
• I will have some new data sets from real classes for you to try out. You don’t have to try them – but you can.
• The timing is tight – 15 demos in 75 minutes. Everyone gets 5 minutes (on average). So please try to be efficient.

In class, we ended up talking about high dimensional data and dimensionality reduction. Lectures connected to the readings will be rescheduled.

Coincidentally, I forgot to write a discussion prompt.

So, this week, we’ll have a “week off” from discussions. There’s nothing to discuss!

Please do the following survey – whether you want to do a demo or not (it’s a way to let us know):

https://go.wisc.edu/0ds4wi

(this should take you to a google form)

Please do this survey on Monday, November 12th.

Class Meetings

• Mon, Nov 12 – Lecture:High-Dimensions
• Wed, Nov 14 – Lecture:Modeling
• Fri, Nov 16 – OPT:DC2 Demos

Week Deadlines

• Reading: Week 11 – Uncertainty and Modeling (due Mon, Nov 12 – preferably before class)
• Quiz 11: 11: Uncertainty and Modeling (due Tue, Nov 13)
• Online Discussion 11: Uncertainty (first post due Wed, Nov 14)
• Seek and Find 11: Something Uncertain (due Fri, Nov 16)
• Design Challenge: DC3:Plans&Tasks (due Fri, Nov 16)

Last week, we talked about the challenges of scale. But we only really got to talk about reducing the number of items. We didn’t deal with the problems of having too many dimensions. And also a lot of DC2 work happened.

This week, we’ll spend more time talking about scale: starting with the problem of dealing with too many dimensions. The discussion of scale will lead naturally to the discussion of modeling and uncertainty: basically, models tend to be summaries.

One change for this week: I am going to try to better integrate ICEs into the regular lectures, since otherwise the lectures become too much of monologues.

Also, we will do DC2 demos – stay tuned for details. But basically, we’ll have class Friday (in 312, not 311) where we’ll give people the chance to show off their projects. Unfortunately, with a 60 student class, we cannot do all the demos in one class period – we’re still working out a plan.

You may want to look at this week’s learning goals Learning Goals 11: Week 11 – Uncertainty and Modeling.

Readings (due Mon, Nov 12 – preferably before class)

While uncertainty is a critical topic, there is no obvious good reading for it. Last year I gave a whole long list.

This year, I want you to read two:

1. Boukhelifa, N., & Duke, D. J. (2009). Uncertainty visualization: why might it fail? In Proceedings of the 27th international conference extended abstracts on Human factors in computing systems – CHI EA ’09 (p. 4051). New York, New York, USA: ACM Press. doi:10.1145/1520340.1520616 (ACM – free access on campus or using UW library proxy).
2. Correll, M., & Gleicher, M. (2014). Error Bars Considered Harmful: Exploring Alternate Encodings for Mean and Error. IEEE Transactions on Visualization and Computer Graphics, 20(12), 2142–2151. doi:10.1109/TVCG.2014.2346298 (web)

The point of uncertainty is that it means there is something in the data that is too hard for us to measure/model. Which makes a nice segway to considering modeling (since uncertainty usually involves a model), which is a hot topic because of that’s what Machine Learning is all about. This paper is particularly relevant if you are interested in the connection between Vis and Machine Learning (or Data Science more generally).

1. M. Gleicher. A Framework for Considering Comprehensibility in Modeling. Big Data 4(2), June 2016. (page with PDF)

Optional

If you want to read more on uncertainty, I recommend:

• Cumming, G., & Finch, S. (n.d.). Inference by eye: confidence intervals and how to read pictures of data. The American Psychologist, 60(2), 170–80. doi:10.1037/0003-066X.60.2.170 (pdf)

The statisticians have a lot to say about how we should think about uncertainty, especially in experiments. This paper gets at many of the issues (it is statisticians explaining to psychologists what they should do).

I will hold an extra office hour tomorrow (Friday, November 9th) during “class time” (11-noon).

I am happy to talk to people about DC2 designs, or anything else Vis related.

For example, if you have interest in a Vis beyond the class, please come talk to me!

Because of how course grading works, we had to give everyone a specific “letter” grade (A,AB, …). However, we are aware of things that are borderline, and can take that into account at the end of the semester when we assign final grades.

If you feel like your assignment was graded incorrectly, you may ask us to regrade it. We need this request before noon on Friday, November 9th. If we regrade your assignment, we will do a complete reassessment – your grade may go down (since we may find flaws we missed).

This started out as a list of replies to specific DC3s, but seeing that someone else got this feedback might be useful for you to help think about your assignment. Some of these things are general things that didn’t apply to any assignment in particular, but I thought of while looking over the assignments.

In many of the assignment responses, I pointed to a specific number – that means I thought that the comment (in the list below) is particularly appropriate. But, you might want to read through the list because more of these may apply to you than I was thinking at the time.

1. The sample data may not have interesting enough things going on with it to show off your design. You may need to generate your own sample data. (you can use my sample data generator as a starting point, or make data by hand). If you make some interesting sample data and are willing to share it, let me know. If you provide good example data that others can use, we’ll reward you (part of your assignment can be creating sample data – but really only if its good example data, and provided early enough that it is useful for others).
2. At demo time, we will have some additional data that may be more interesting to try things out with. However, it may not be interesting in the ways that you want.
3. Providing standard chart types can be an effective way to answer some of the simpler tasks. We were hoping that people would think of richer tasks that require showing the structure/relationships (which are hard to show in standard charts), and use this to motivate non-standard charts.
   But, if you make standard charts, be sure to describe why they are appropriate and why the ones you made are well-adapted to the questions you are asking. Questions with simple answers (e.g., “which group has the most messages”) may not need of a visualization, questions that dump simple data (e.g., “what are numbers of messages in each group” as a bar chart) are unlikely to be considered as great assignments. A simple chart type might be a really appropriate design for an interesting question – but it would probably need to be coupled with some interesting data transformation.
   Combining sets of simple charts in interesting ways (where they are used together) can become a non-simple chart.
4. In some cases, people said they are making a design, but said little about what the design is so we can’t comment on it.
5. Since last year’s data was anonymized, the actual dates don’t match up. (the whole semester was shifted). I think that the entire data file was shifted by the same amount (so you can see there are, for example, 2 deadlines per discussion assignment – but it could be that the friday deadline got shifted to tuesday or something like that). You can look at last year’s web site to see the structure of the assignments (it was different).
6. Many people have discussed either trying to learn a new programming environment, or are exploring different libraries to use with an environment they already know.
   On one hand, I’d like to encourage this: since learning about available tools is a good thing.
   One the other hand, it can take away from the assignment: if you spend 4 weeks learning a new tool, you may not have much time to use it to make something that addresses the assignment. At an extreme case, learning to use an entire different programming modality (like learning Javascript and enough stuff to make something in D3 from scratch) is hard enough to get to make something simple in 4 weeks, never mind an an implementation that addresses the assignment well.
   This makes it hard to compare assignments: someone who came in as a D3 expert can probably make fancier things than someone who decided to learn everything from scratch. Or someone who focused their energy on making good designs with tools they know (even if its pen and paper) will succeed differently than someone who spent weeks doing a thorough evaluation of different python libraries to choose an appropriate one, and only had limited time to come up with good designs.
   This leads to #7…
7. If you spent a large amount of time learning new tools, please explain this in your project description. (see #6).
   This might be anything from “I learned Javascript” or “I did a thorough evaluation of 7 different Python graphics libraries to choose an appropriate one.” Give us a sense of what you learned or found (if you did evaluate a lot of libraries you can tell us why you chose what you did). We will take this into account when evaluating assignments (although, the assignment is really about creating effective designs, so that is the focus). I’m not sure exactly how this will factor in, but we will consider it. If you can convince us you learned something beyond what shows in the result, we will find a way to account for that.
8. We only gave comments to the partner who submitted.
9. In making a good design, but sure to consider what the design is good for – in your examples be sure to point it out. This probably means picking good examples (see #1)
10. Remember, you need to have at least 2 designs. It could be one system that shows multiple designs.
11. I have seen some nice looking versions of standard designs (e.g., graph views) – but think about how to adapt it to the specifics of the assignments and what tasks it address.
12. Even if you provide something that makes it easy for us to run your code (a web page, github repo, executable), we probably prefer a demo anyway – that way you can show it off.
13. Even if you deploy by GitHub (GitHub pages are a cool deployment mode for web projects), please provide us with a ZIP file of the code (easy – just have GitHub make the ZIP)
14. Providing contrasts between designs (and between your designs and the baselines) can be a good way to help us appreciate your designs. Your designs should be “better” than the baselines (for at least some tasks).
15. Think about (and explain) why the visualization adds value over simply giving a number or answer to the specific question.
16. You can “fake” interactivity in a sketch by describing it and providing a sequence of images (or using illustrations that show off interactivity). You can try a mockup tool (like Adobe XD) to make an interactive sketch. You can “implement” interactivity using links in web pages or even power point (in the old days, there was this thing called “HyperCard” that was great for this).
17. Unlike DC1, the goal is not to provide a visualization of a specific data set, but rather, to provide designs that can be applied to many data sets. You may illustrate your design on 1 data set, but consider that the design should be applicable.
18. While you can generate data (#1), remember that you can’t generate different types of data (for example, you should not assume you can get access to the texts of the messages).
19. We will have more instructions on demos next week, including some process to help people decide whether or not they “need” or “want” to give them. Hopefully, we can look at submissions and give initial feedback as to the value of a demo.
20. Yes, you may use my code as a starting point (for data generation and python assignment data wrangling). Be sure to give proper attribution. (that said, I’m not sure the code I’ve given out is all that useful)
21. For the final, upload code in a ZIP file