Final Project Handins

in Posts
Page content

The final projects must be turned in on (or before) Friday, December 16th. There will be a Canvas survey for turning the assignment in. Only one person per team should turn in the final project. The handin will include a writeup (up to 4 pages + references) and “artifacts” (software, a portfolio, video, …) These are detailed below.

Self-Evaluations for the project must be turned in on (or before) Sunday, December 18th. All students must turn in a self-evaluation. The self-evaluation will be a Canvas survey that is separate from the main hand-in.

Deadlines

The deadlines are strict because we need to complete grading before University deadlines.

The deadline for the main parts of the project is Friday, December 16th (any time on Friday).

We will begin grading on Saturday morning, December 17th. We will collect the assignments from Canvas and do an initial assessment and order randomization. So, if you turn things in a few hours late, we may not notice - if it’s there when we download from Canvas, then we’ll have it. I don’t recommend taking your chances - we might get up early and do it early in the morning.

If you do not turn things in on time, we will not be able to evaluate it fully. Late assignments will not be eligable for high scores.

The deadline for the self-evaluation is Sunday, December 18th (any time before Monday). We will not look at the self-evaluations before Monday, but if they are not done by Monday, we will assume you aren’t doing it.

Officially, things are due on Tuesday, December 13th, but all students get a no cost extension to the later dates listed above. Anyone who is concerned about a deadline after the last day of class is free to turn things in on the 13th.

Our Process

On Saturday morning, December 17th, we will download all the project for grading. We will sort them by theme (so we grade each theme together), and randomize the order (since there can be order effects). We will then make a quick scan through all the projects to make sure everything seems to be in place. If we spot a problem, we may send you email asking for a clarification or correction. If we invite you to respond, please do so promptly (since we need the updates for grading).

We will then do a more thorough pass where we look over all of the projects and assess them. This is the usual grading process.

Then, as a third pass… we do “grade corrections” where we tune the grading to make sure that that the grades are consistent, and that we consider any intangibles that come up from the self-evaluations.

What to turn in (Main handin)

Each team needs to turn in the “main part of the project” exactly once. Only one person on each team should complete the Canvas survey. Do not have multiple people turn in the project. There are two parts: the document, and “the artifacts”. The nature of the artifact depends on the nature of the project.

The Document

You must hand in a document as a PDF. You are allowed four pages, not including references. (references can be on a 5th page, but only references can be on the 5th page). You can have more writing and images in your “artifacts” (see below) - but the document must be self-contained. For example, you may have a few examples as images in the document, but have larger, and more details images and more examples in the artifact.

The PDF should be “reasonably readable” - don’t use tiny fonts, … If you want to try using the “official vis format” you can try it (see https://tc.computer.org/vgtc/publications/conference/). We would probably prefer single column 11/12 pt type.

Don’t feel obligated to use all 4 pages: if you can describe things concisely, that’s great.

The document must be self contained, it must explain your project. We care about the clarity of presentation. (but content is the main thing). You can refer to things in “the artifacts”, but the reader should be able to understand and appreciate what you have done without looking at the artifacts. For example, the document should describe what your program does (so a reader can understand it without trying) - the details of how the program is used and is set up the reader can get by trying it/looking at the repository. Or, for a design exploration, you might show your “best” designs and explain them in the document, but then leave the alternative (less good) designs for the portfolio. The document might have only limited examples, and leave a broader demonstration of the range of your system/ideas to the artifacts.

In the document, be sure to explain:

  • the problem you are solving
  • the ideas behind your solution/design
  • an explanation of your solution/design
  • an evaluation of your solution/design (this can be “informal”, like a critique, or discussion of what you can see in examples) - but its up to you to convince the reader that the solution is good. (or, maybe it isn’t good - but was a plausible thing to try that the reader can learn from).

Artifacts

Note: if you turn something in by making it available on the web or GitHub, we will trust that you will not change it after the deadline (unless we instruct you to).

“Presentation Quality” does matter. We care about your README and documentation, how well presented your portfolio artifact is, etc. We appreciate that good videos are time consuming and difficult to produce, and have appropriate expectations. A video needs to be good enough to convey the ideas - if it isn’t a great video, we will look at other aspects of presentation to assess presentation quality.

Videos (including powerpoint recordings) can only help. If they are worse than nothing (e.g., it was a terrible video and gave me doubts about the quality of the assignment, I will forget that I saw it, and still think “this student at least put the effort into trying, and probably learned how hard it is.”). Historically, many students end up saying things like “I tried to make a video, it wasn’t great - but I did learn how hard it is, and get some ideas on how to do it better in the future” - is a common thing in the self-evaluation.

Program Source Code and Data

You need to turn in your source code, all data required to run the program, and instructions on how to run it.

Make sure your instructions (as a README) explains what the requirements are, what the build process is, etc.

You may either turn things in by uploading a ZIP file to Canvas or providing the Prof. and TA access to a GitHub repository (if its a private repository, add “gleicher” and “Bluejaye11” with read permission.

It is unlikely that we will try to run your program, but we are often curious to see what is there.

Interactive Programs

If you have written a program that involves interaction, you must do at least two of the following:

  1. Have the system be deployed on the web - so you give us a public URL that we can visit and try it out. It must be self-explanatory enough that we can try it out in a short amount of time, and sufficiently self-documented (or have an instruction page) that we have a chance to see the nice aspects of the system in a short amount of experimentation.

  2. Have a short (2-4 minute) video with voiceover that shows you doing an interaction with the system that shows it off. While “produced” and edited videos are preferred, a simple video or you talking over a screen recording is better than nothing. (see “videos can only help” above)

  3. Have a static document (a web page or PDF) that gives a “walkthrough” of using your system. This is usually a series of screen shots with explanation of what the user is doing.

We can only try things that are web deployed. So if your program doesn’t run on the web, you can’t do option 1. Even if your program does run on the web, there is a chance that in playing with it, we won’t see it well, which is why you still need to do #2 and #3.

This is in addition to turning in your source code.

Non-Interactive Programs

If you have written a program that is not interactive (it produces a static visualization - for example from a command line), you are responsible for providing enough examples of the program working to illustrate the ideas and the range of what it can do.

In a sense, this is like the Portfolio-Based handins, but there should be some discussion of the program (and, if you are making a video, some screen capture/explanation of how the program was run beyond the results. So refer to the next section on portfolios (again, the thing to consider is that you want to have a portfolio of results that shows off the range and success of your program).

Design Portfolio-Based Projects

If the point of your project is to present design solutions to a problem, you will probably want to provide a “portfolio” of your different design ideas.

You may have pictures of your different designs, possibly with multiple pictures given examples of your designs working in different scenarios (different data, different options). You may have both examples of the visualizations, but also versions of those examples “marked up” to point out different elements. You will probably also want to provide examples of the alternate designs that you considered (but chose not to have as the “final designs”).

You should turn in a “document” with all of these examples in addition to your write-up. You can turn this document in as a PDF, however, you may prefer to set it up as a web page - which has the advantage that you can cross link, put small versions of images in the text and link to larger versions of the image, use web formatting, etc. If you turn things in as a web page, you can either publish it on the open web (e.g., using GitHub pages or the Department web server), or turn it in as a ZIP file.

If you create a portfolio as a document (not as a web page) please convert it to PDF (do not turn in, say, a Word or LaTeX document).

If you create your portfolio as a power point slide deck (which is also a good approach), you still need to turn in a PDF (use save as PDF) - but you can also turn in the PowerPoint file (yes, turn in both). If your PowerPoint is more than static slides (for example, it has animations, or recorded voice over) - be sure to note that on the first slide.

You may optionally have:

  1. A 2-4 minute video showing off your project. A video of you talking over the system being used, or a powerpoint slide deck of the results can be effective. Especially if you use the cursor to point at things.

  2. A recorded power point presentation (use the recording feature) - again, subject to the 2-4 minute target length. I have limited experience of doing this. It probably ends up being like recording a screen capture of you talking through the power point presentation. I am not sure if PowerPoint can capture the cursor (for pointing at things).

These are optional, but strongly recommended.

The Self-Evaluation

Each student must turn in the Self-Evaluation on Canvas: DE13b: Final Project Self-Assessment (due Sun, Dec 18).

The self-evaluation is a chance for you to reflect on the assignment, and to tell us about anything we should know that may affect grading.

Presentations

Giving a presentation on the last day of class is optional. Groups must volunteer ahead of time (instructions will be given). Presentations are limited to 5 minutes, with some time for discussion ahead of time.

Giving a presentation can only help. A presentation will not take the place of any of the other hand-in components. However, a presentation can help the course staff appreciate the other hand-in materials, which often leads to a better evaluation. Feedback from the class discussion after a presentation may be helpful in improving a project. Often, questions raised give good points to explain in the final handin.

While there is not official score for a presentation, the willingness of a group to give a presentation is valued when the project is assessed.

Please sign up to volunteer at: https://forms.gle/NUbn4p95DjeAigme7