DC2 Final Handins

in Posts

You will turn in your DC2 project using the canvas handin quiz: DC2 Phase 5 (Canvas Wed, Dec 15). You may receive an extension as disccused on DC2 Final Dates and Presentations. This posting will explain what we would like you to turn in, and how to turn things in.

One key point: we don’t have a fixed format. We ask that you give us a report, and whatever we need to run your program. And beyond that, its up to you to give us things so we can (quickly) figure out what you’ve done, and see how great it is.

The Questions on Canvas

All students must complete the Canvas Hand-in Quiz. Only one person per team should upload the final report and the “artifacts”. All students must complete a self-evaluation.

We will ask you to upload the following:

  1. Project Report as a PDF (this is the main piece - discussed below)
  2. Code Artifact (ZIP upload or alternate - discussed below)
  3. Self-Evaluation (PDF upload - note that everyone must turn this in!)
  4. Data or Demo Artifact(s) (ZIP upload or alternate)

Note: do not upload files more the 20-25MB. If you have a bigger file, we will make an alternate arrangement to transfer it.

And, we’ll ask the following questions (beyond the simple ones like who is your partner): (Only the handing-in partner needs to answer these questions)

  1. Is there an alternate way for us to try out your project?

    If you can provide us a way to try your project without having to unzip and build it, please explain in this text box. Usually, this is a URL. But, if you do something else, you can describe it here. (for example, if you have a docker container we can download)

    If there are instructions (beyond “go to this website” please explain). This includes Docker containers (yes, I need instructions on what to do with them).

    You are strongly encouraged to provide a runnable version on the web. Ideally, this would either have sample data built in, or provide easy instructions to get sample data.

    Note: even if we can run your code on the web, please make sure you turn in your code artifact with a README.

  2. What data did you use for testing your program/design?

    Please describe the data you used for testing your program. The assignment asked you to identify data beyond what we provided.

    We would appreciate if you can provide pointers to the data sources. If you needed to process the data heavily to work with your program, you may want to provide it to us. You can upload it as your “Data or Demo Artifact” or put it somewhere (like Box or Dropbox) and provide us with a link.

  3. Anything we should know about your code artifact?

    This is an open question, but it is a place to say things that aren’t in your README.

    If you upload a ZIP file, give us a rough sense of what we’ll get inside of it.

    If your project is on GitHub, you can turn it in by giving us a link to the repository. If the repo is private, please give read (clone) access to gleicher and abhayk1201.

  4. What other things would you like to turn in?

    This is a place for you to explain the contents of your “Data or Demo Artifact”. But, since you might want to turn things in using a mechanism other than a ZIP file, you can use this as a place to point us to things.

    Since the ZIP file can only be 20-25MB max, you might want to put big things (like data sets or videos) somewhere on the web and including a link. The University provides box.com accounts for everyone (which are quite convenient). Be sure to share things with us correctly.

Some comments on what to turn in

The format for the documents are not fixed. But there are a few requirements and expectations…

Code Artifacts

If you built something, we would like you to give us everything we need to build it and try it out.

We would prefer that you also give us a way to try things without having to build it (e.g., find a way to host it on the web). But you still have to turn things in.

You can turn things in either as a ZIP file, or by giving us access to a GitHub repository.

You code must have a README file, that describes (at least):

  1. any instructions needed to build and run the system
  2. what tools are needed to build and run the system (for example, what verion of Python, what libraries , …)
  3. please list what libraries and tools you used (even if there is a requirements file)
  4. some basic sense of how to use things. for example, if the user needs to load data, give examples to try. You will probably want to have more detailed instructions in your report document

Data and/or Demo Artifiacts

If you created data artifacts for your project (for example, converted data sets into a form to be used by your program, or generated new data sets), you may want to provide them to us (so we can use them to try out your program).

A video can be a good way to document your project. A recording of a demo may be better than expecting the course staff to figure things out. Making good video is hard. But we appreciate reasonable efforts. If you make a video, it will probably be too big to upload to Canvas - so put it someplace and include a link.

Some notes on videos:

  1. Keep it short. There is no hard limit, but it is unlikely that you can make video of sufficient quality that we would want to watch it for more then 4-5 minutes.

  2. Don’t go too fast. You know how things work, so you can race through a demo. A viewer needs time to realize what is happening. This might seem like a contradiction to #1, but it actually goes together. Be strategic: show a few things well, not a lot of things that go by too fast for anyone to know what is going on.

  3. Use titles and motion to guide the viewer’s attention. In a demo “look in the upper right” is easiest to follow if there is mouse movement or something to direct attention.

  4. Have a voiceover - yes, record yourself explaining what is going on.

There are things other than videos… You might provide a powerpoint presentation (which is a different genre than a written project report).

Final Report

The main thing we will look at will the the written document provided as the “final report”. It should stand alone - write it as if it is the only thing we will look at, and that we have forgotten what the assignment was.

While there is no fixed format, I recommend that you cover the following points:

  1. Be clear about the specific problem you are trying to solve. Use examples.
  2. Explain the idea behind your solution. What is it? What is the rationale? Why is this a good solution (or a reasonable thing to try - since you might have tried something to learn that it actually isn’t a good idea)
  3. Explain what you made to prototype and demonstrate the idea. This is the implementation - explain what it does.
  4. If there are interesting things in how the prototype works, explain that - in general, we are more concerned with what the implementation does than how it does it. But, if there is something you think we should know.
  5. Provide examples of what the implementation does - show off that your prototype really does show off the idea.
  6. Provide examples that show the idea in action: can you demonstrate that the idea really solves the problem?
  7. Evaluate the idea: how well does it solve the problem? Note: this may be independent of how well the implementation realizes the idea. You might have an implementation that barely shows the idea, but is good enough to prove the concept when you analyze some examples.
  8. Discuss the limitations of the idea and the prototype.

To do 5 and 6, you might want to walk through a “use case” with pictures illustrating what the user might do/see in order to achieve their task in some scenario. Don’t expect that the reader will watch the video or play with the system to do this themselves. In fact, often a well described use case can inspire the reader to try things out themselves.

Note that in 7&8 you are evaluating your idea and your implementation, not your work/project. (that’s the self-evaluation below). A great project might build a crude prototype that is good enough to convince the reader that a seemingly plausible idea doesn’t work. Some aspect of your project should be great. It might be a great design (idea) that you have a convincing rationale for, but only a proof of concept implementation in a simple case. Or it might be a simple idea with a really compelling implementation and convincing use cases.

Self-Evaluation

Every student must turn in a self-evaluation. There is no set format. A strong preference that you keep it to a page or less.

The education science tells us that taking time to reflect on a project, to think about what you’ve learned from it, really helps improve the amount of learning that happens. So I ask you to take the time to do the reflection.

Give an honest assessment: This is a place to say that you had bigger goals but had to scale back to fit the reality of a 4-week class project, or that you are really pleased with what you’ve done. Please give your honest assessment of your familiarity with the tools that you used, and how much of your energy for this project went into learning those tools. For example, you might say “I am an experienced Python programmer, and used to having to learn new APIs, so picking up Bokeh wasn’t a big deal” or “I had never done any JavaScript programming, so I spend a ton of time working through a lot of tutorials to learn D3”.

I recommend that you describe what you learned from doing the project. This can be at all levels. Some examples:

  1. mechanics (e.g., you learned a new library or programming trick or algorithm)
  2. problem specifics (e.g., you learned about dimensionality reduction, or issues in chart sizes)
  3. general project things (e.g., how to break down a problem, how to inform design with literature, how to test an idea)
  4. general visualization ideas (e.g., how to choose color maps, choices for dense scatterplots)

Note: if you want to get “credit for learning tools” please be clear what you did.