The purpose of the final project is to scale up the hands-on experience you developed with A4 in designing, implementing, and evaluating visualization methods. In particular, your project should address a concrete visualization problem and propose a novel, creative solution and its scope and ambition should reflect the roughly 6 weeks you have to work on it. Though the majority of final projects typically involve developing a software artifact, design studies or evaluations of visualization techniques may also be acceptable projects — please talk to the course staff if you have questions.
Projects will be carried out in teams of 1-3 people (PhD students taking this class for TQE credit may work in teams as well). The final deliverable will be an implementation of the proposed solution and a short paper written in the format of a conference paper submission. In addition, you will be responsible for participating in a design review and presenting your final results as part of a final project showcase (e.g., see the showcase from last year).
Prior to starting your project, it is helpful to gain a sense of what goes into formulating a successful visualization project and to beware of common pitfalls. We encourage you to read A Nested Model for Visualization Design and Validation by Tamara Munzner (required reading for Week 12).
The proposal should include the names of the members of your group and a short (1 to 2 paragraph) description of the visualization problem you plan to address and the dataset(s) you’ll be working with. If your final project will be building off your A4, your proposal should include description to help us gauge how your extensions will represent concerted effort from all team members for approximately 6-weeks worth of work.
Register your team in our Google Docs form by Friday 4/16, 11:59pm ET. Unless granted instructor permission, you may not work in groups larger than 3 people. If you are looking for project partners, please use the #teamsearch Slack channel.
Note that you should submit the form even if you are working individually.
After you submit the form, your team will need to set up a GitHub classroom repository as follows:
Develop an initial prototype of your project and publish your work in your GitHub repo. If applicable, publish any web-based visualizations using GitHub Pages. Your work will be reviewed by the course staff and critiqued by your peers (similar to A4) to provide feedback on your designs and progress. It is fine if your project is not yet in a “complete” state; however, by this point, you should have made substantive progress, including working (if rough) prototypes of your main visualizations and interactions.
Similar to A4, your milestone materials should be pushed to GitHub Pages and you should add a link to your 5-minute (max) video to this Google spreadsheet by lecture on Monday 5/3 (2:30pm ET). During the lecture on lecture on Monday 5/3 (2:30pm ET), we will split the class into multiple parallel sessions to watch your presentations and conduct peer design critiques. Videos will be cut off at 5 minutes sharp during the in-class demos. Your team should create a 5-minute video presentation that covers the following content:
(~1 min) A short introduction to your dataset and goals of your project: what is it that your visualization is trying to help a reader with, and why it is important?
(~2 mins) A demonstration of your Final project so far.
(~1 mins) A discussion of some of the key design decisions you’ve made so far (e.g., did you do any exploratory data analysis, and did it reveal something interesting? Why did you pick these particular visual encodings, or interaction and animation techniques? What alternative ideas did you explore or are you considering? etc.)
(~30 secs) A brief list of questions that you would like your peers in the class to comment on as part of their critique
After each presentation, we will have a 1-2 minute Q&A session. Engaging presenters with questions or suggestions will count towards your participation grade. (If you attend class asynchronously, leave questions/suggestions in the #final-project Slack channel.)
During this week, each of you individually will also be assigned three projects to critique. For each project you are assigned, we would like you to not only pay close attention to their presentation videos but also spend some time interacting with the visualization itself. You should then compose a critique following the structure we’ve used in class (“I like… I wish… What if…?”) and cover the following concerns:
Visual Encodings. Are expressive and effective visual encodings applied? How well do they reveal the most important features or trends of the underlying data? Is critical data easily seen, or is it unnecessarily “hidden” and only revealed in response to interaction? Is the target audience likely to understand the visualization?
Interaction & Animation Techniques. Do the supported interaction and animation techniques enable more effective discovery of interesting trends, patterns, or outliers? Do they engage the viewer in a process of meaningful exploration or learning? Are they well-implemented, without notable performance issues or usability problems?
Design Quality. Assess the overall design quality in terms of organization and presentation. Are elements appropriately titled or labeled? Is there appropriate spacing, layout, legible type, and other forms of design styling? Is it clear where to begin viewing/interacting with the design? Is the overall display confusing or cluttered? How successful is the prototype in meeting the intended goals?
Critiques should be about 2-3 paragraphs, and all three critiques will be due by Thursday 5/6, 11:59pm ET. Submit each critique individually using this form. We will grade your critiques on how thoughtfully you’ve engaged with the team’s visualization, and how constructive and actionable your feedback is.
All final deliverables should be in your GitHub Repo. All deliverables are due by Wednesday 5/19, 11:59 pm EST. Please also complete the submission form on Canvas by providing a link to your Project Page.
The specific final deliverables include:
Video Teaser: a 1-minute video that should demonstrate your working visualization. Consider this video to be a “trailer” for your project: rather than trying to exhaustively demonstrate your entire visualization in 1 minute, can you instead surface 1-2 interesting insights that leave your viewer wanting to explore your work more deeply? Your video will be due by the start of class time (2:30pm ET) on Wednesday, 5/19 as we will watch all videos during that final lecture.
Paper: a 2-4 page paper (not counting references) written in the form of a conference paper submission. The paper should present your goals, related work, a detailed description of your system, and a discussion of your design. This should be in pdf format and named “FinalPaper” in your Github repository.
Project Page: List title, team members, summary image, abstract, link to the paper, video, running instructions for the software, and other optional materials. Preferrably host the page with Github Pages.
Readme File: In the repository’s readme.md, include a breakdown of how the work was split among the group members and a commentary on the project process.
Code: an implementation of your system (source code and, if necessary, MacOS executable or build instructions).
Application: if feasible, publish your visualizations on GitHub pages. You can also use a different service but make sure you provide the relevant links and the code should still be in your repo. You might get little or no technical staff support if you are using a different service.
Final Project Showcase (optional): Typically, we would host a final project poster session so that external visitors would be able to interact with your work. Last year, due to the pandemic, we hosted a virtual showcase which received a lot of publicity on social media and we’d like to do that again this year. If you’d like to participate this year, please fill out this Google form. Participating in the final project show case is entirely optional and will have no bearing on your grade.
The final paper should be in the style of a conference paper submission. The paper might include content that is typical of papers that appear at IEEE VIS, or CHI. In particular, it should contain:
Introduction – An explanation of the problem and the motivation for solving it.
Related Work - A description of prior research or work related to your project.
Methods – An explanation of the techniques and algorithms you used or developed.
Results – The visualizations your system produces and any data to help evaluate your approach. For example, you might describe a case study that illustrates how your visualization(s) address your chosen problem.
Discussion – What has the audience learned from your work? What new insights or practices has your system enabled? A full-blown user study is not expected, but informal observations of use that help evaluate your system are encouraged.
Future Work – A description of how your system could be extended or refined. We have read papers from a number of conferences throughout the course, but if you are having trouble figuring out how to write your paper, take a look at representative papers from the conferences listed above.
Your final paper should be formatted using the 2 column formatting of papers that appear at IEEE VIS or ACM CHI. Although there are some differences in format between these conferences, you are free to pick from either of these. If you need help finding a formatting template talk to us. Templates for VIS and CHI are available online. Your paper should be between 2-4 pages, not counting references.
Your implementation should be able to handle typical data sets for the problem at hand and run at a speed compatible with the intended use (for example interactive visualization should run at interactive frame rates). Developing algorithms that scale to large data sets can be particularly challenging and interesting. However, the project is not a programming contest and mega-lines of code are seldom associated with a good project.
We are very flexible about the underlying implementation of your projects. However, we encourage you to use an available visualization toolkit (see Resources) that supports web-based publication. However, software projects must include some new code written by your group. You should not simply use existing software such as Excel, Tableau, Illustrator, etc. to create the visualizations for your final project.
Explain how we can run your code on the project page. If your application is web-based, include a URL and if possible publish it using GitHub Pages. Note that GitHub Pages only supports vanilla HTML/CSS/JS; it does not support server-side logic. You will likely need to use another hosting option for your application if you need server-side logic support. If your project is not web-based, provide detailed build and running instructions as needed.
Remember to acknowledge all appropriate sources not just in your write-up but also directly on your visualization itself (including the source of your data, and any example visualization you drew inspiration from).
Put your final paper pdf file and your video in the final folder in your project repo’s master branch.
Include a project page on Github Pages (your docs folder) with your project title, team members, summary image, abstract, link to the paper, video, running instructions for the software, and other optional materials. (Or in README.md if you have privacy concerns.)
Include a breakdown of how the work was split among group members and a commentary on the research/development process in the README.md.
The final code (and, if not web-based, executable binary) should also be in the default main branch. If your visualization is web-based, also publish it online using GitHub pages.
The final project will count for 40% of your final grade in the course. We will consider the novelty of the idea, how it addresses the problem at hand, the methodology you employ in doing the research, and your proficiency in implementing the idea. We will particularly focus on the usefulness of your results, as well as your choice of visualization and interaction design decisions.
Do not submit late! You can’t use slack days for this assignment and late submissions will not be accepted!