DC2 Phase 3 Feedback and General Tips

by Mike Gleicher on November 3, 2018

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

Previous post:

Next post: