CSE512 Data Visualization (Spring 2015)

Final Project

The purpose of the final project is to provide hands-on experience designing, implementing, and evaluating a new visualization method, algorithm or tool. Projects will be carried out by a team of 2-4 people. Your project should address a concrete visualization problem and should propose a novel, creative solution. The final deliverable will be an implementation of the proposed solution and a paper written in the format of a conference paper submission. Though the majority of projects concern the development of 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.

In addition, each group will be responsible for presenting the project twice. The initial presentation should describe the visualization problem that the project will address, relevant related work, current progress, and final milestones. Take advantage of this presentation as a chance to get feedback on the direction of the project from the rest of the class! At the end of the class we will have a public final project poster session so that groups can show their work to others and a number of invited guests from academia and industry.

Prior to starting your project, it is helpful to gain a sense of what goes into formulating a successful visualization project. We encourage you to read the following guidelines for writing visualization research papers. It is an enjoyable read and should help you avoid common pitfalls, even if you do not have a research focus:

Suggested Project Topics

In collaboration with researchers here at UW, we have a number of exciting final project suggestions for you to consider.

In addition, Edward Tufte's site is another place to look for project ideas. His question/answer area is full of ideas that would make good class projects.

Several previous visualization courses have had project components. Browsing through the final reports may help you think about what you might like to do. These descriptions may also help you determine the realistic size and scope of a project.


Team Registration & Project Proposal

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.

Register your team in our Google Docs form. Similar to A3, we will use form responses to generate GitHub teams and repos for final submissions. You should work in teams of at least two people for this assignment. You may not work in groups larger than 4 people. If you are looking for project partners, please post to Canvas in the relevant discussion.

After the proposal deadline, we will add you to a team and create a repository named fp-uwnetid1-uwnetid2-uwnetid3-uwnetid4, in which you should put your code, project page, readme and final submission. Use our fp-jheer-domoritz-jsnydes repository for a submission template. (See Final Deliverables section.)

The repository is public by default so people can see your work. If you have any restriction such as data privacy, you can make it private. You can also make it private first and make it public once you finish. Please contact us as soon as possible if you can't access the GitHub organization.


Fill the final project team registration form and submit your proposal document via Canvas. Please name the file proposal-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf (e.g., proposal-jheer-domoritz-jsnydes). UW Net IDs in the file name should have the same order as in the registration form.

Project Progress Presentation

A good way to assess the strengths and weaknesses of your project is to present your ideas to your classmates for feedback. Thus, each group will be expected to present their project idea and current status to a subset of the class. The presentation should expand on the the project proposal and include the following material.

Your presentation to the class should include:

  • A description of the problem you will address and motivation explaining why it is worth addressing.
  • In your description you should mention 1-2 pieces of the most relevant prior work, and discuss how your project is different.
  • Your current progress. Use sketches, storyboards, and/or prototype images to communicate your ideas. It is a good idea to highlight issues of design or implementation for which you would like to get feedback from the class. End your talk with a single slide containing questions you'd like feedback on.
  • Keep your presentation concise – no more than a few (3-4) minutes. Use at least half of that time to discuss your design ideas and completion plan. It is difficult to communicate effectively in such a short time span: carefully revise your materials and practice your talk to avoid rambling and unnecessary description.

You should also submit a progress report, which include:

  • Literature Review. A background survey of related work and a full list of references.
  • Project Plan. A list of milestones breaking the project into smaller chunks and a description of what each person in the group will work on.


Submit your slides (as PDF) and progress report on Canvas by 5pm on 5/20. Name the files slides-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf and progress-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf (e.g., slides-jheer-domoritz-jsnydes.pdf and progress-jheer-domoritz-jsnydes.pdf).

Final Poster Presentation

We will hold a public presentation of the final projects on June 8, 5-8pm in the Atrium of the Paul G. Allen Center. The poster session will give you a chance to show off the hard work you put into your project, and to learn about the projects of your peers. Be prepared to give a 5 minute oral presentation at your poster to both the instructors and visitors. You should include a demo of your project along with the poster. The poster will be considered a final deliverable, so don't forget to apply good visual design principles to your poster as well as your project. The final poster should include the following information:

  • Problem: A clear statement of the problem your project addresses.
  • Motivation: An explanation of why the problem is interesting and what makes it difficult to solve.
  • Approach: A description of the techniques or algorithms you used to solve the problem.
  • Results: Screenshots and a working demo of the system you built.
  • Future Work: An explanation of how the work could be extended.

You can use CSE's poster printer to print the poster. See CSE Lab for instructions. If you are not a CSE student, please talk to the teaching assistants to arrange printing well in advance of the poster session.

Submission: After the presentation, put your poster-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf file in the final folder in your github repo before the final paper due date.

Final Deliverables

Submit final deliverables on your Github Repo by 8am on 6/11.

The final deliverables include:

  • Poster: a pdf or image file of your poster from the presentation.
  • Paper: a 4-6 page paper written in the form of a conference paper submission. The paper should present related work, a detailed description of your system and a discussion of your design.
  • Project Page: List title, team members, summary image, abstract, link to paper, poster, running instructions for the software and other optional materials. 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 research/development process. If you don't won't to put any required materials in the project page, put them in readme.md file instead.
  • Code: an implementation of your system (source code and executable).

Use our fp-jheer-domoritz-jsnydes repository as a template for submission. Basically, your repository should have your code and a final folder containing your poster and paper pdf files. You can download the repo as a zip file and unzip it on your local repository or clone it and use it as a starting point for your project.

We will grade your work in your default branch (the branch that we see by default). A new repository will have the master branch as the default branch. Since you have to publish a project page (and possibly your final visualization system) on the gh-pages branch, we recommend that you change the default branch to the gh-pages branch, put both project page and your source code there, and remove the original master branch to avoid confusion.

Each repository is listed on our CSE512-15S repositories list. Please write a one-line description and put a link to your project page to facilitate navigation for visitors. (See Figure 1 Caption for how to add url.)

Figure 1. Put a short description on top of your GitHub repo page.
To display url in the repos list page, append the url to description (NOT in the website box).

Within a few hours, both description and url will be shown in the repos list page.


The final paper should be in the style of a conference paper submission. The paper should include content that is typical of papers that appear at IEEE Visualization/InfoVis, SIGGRAPH, or CHI. In particular it should contain:

  • Introduction – An explanation of the problem and the motivation for solving it.
  • Related Work - A description of previous papers related to your project.
  • Methods – A detailed explanation of the techniques and algorithms you used to solve the problem.
  • Results – The visualizations your system produces and data to help evaluate your approach. For example you may include running times, or the time users typically spend generating a visualization using your system.
  • 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 Visualization, SIGGRAPH or CHI. Although there are some differences in format between these conferences, you are free to pick from any of these three. If you need help finding a formatting template talk to us. Formatting templates for CHI can be found here.

Project Page & Readme File

All teams have to put a project page hosted on Github Pages.

The project page should list team members, title, abstract, running instructions, link to paper, poster and a summary image for the project. Please name the summary image summary.png/jpg so we can easily crawl your repo and generate a final project gallery page after the submission due date.

We have provided a project page template (index.html in the example repository). Feel free to use (or make) another template as long as you use a nicer one and have all the required contents. If you have other materials, feel free to add them. For example, our template include a project video too. If you have privacy concern, please email us to let us know and put contents you don't want to show in public in readme.md instead.

To host a project page, create a branch named gh-pages and put your index.html and your material there. If nothing goes wrong, your code in gh-pages should become available online at http://cse512-15s.github.io/your-repo-name within 10 minutes.

The readme.md file should include a breakdown of how the work was split among the group members, a commentary on the research/development process and required contents that you do not want to show in the public.


Your implementation should be able to handle typical data sets for the problem at hand, and run at speed compatible with the intended use (for example interactive visualization should run at interactive frame rates). Developing algorithms that scale to large data sets is particularly challenging and interesting. However, the project is not a programming contest and mega-lines of code is seldom associated with a good project.

We are very flexible about the underlying implementation of your projects. You can start from scratch using OpenGL or any other graphics and windowing toolkit, or use an available visualization toolkit (see Resources for some toolkit possibilities). However, software projects must include some new code written by your group. You should not simply use existing software such as Excel, Tableau, Spotfire, Illustrator, etc. to create the visualizations for your final project.

Explain how can we run your code in the project page. If your application is web-based, it would be great if people can see it online. Github Pages is an easy way to show your work online so people can easily access it. Basically, put your main visualization page (e.g., main.html) in the root location together with your project page (index.html) in your gh-pages branch and provide a link from your project page.

Note that GitHub Pages only supports vanilla HTML/CSS/JS; it does not support server-side logic (e.g., PHP, Ruby, Python). So you might need other hosting option for your application if you need server-side logic support.


Before the final paper due date:
  • Put your final paper pdf file (paper-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf) and your poster (poster-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf/jpg/png) in the final folder in your repo's default branch (gh-pages or master).
  • Create a Project Page on Github Page. Include title, team members, summary image, abstract, link to paper, poster, 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 the group members and a commentary on the research/development process in the readme.md
  • The final code and executable should also be in the default branch. If your visualization is web-based, don't forget to put your final work online.
  • Update project description in your repo and add links to the project page.


The final project will count for 40% of your final grade in the course. We will consider strongly the novelty of the idea (if it's never been done before, you get lots of credit), how it addresses the problem at hand, the methodology you employ in doing the research, and your technical skill in implementing the idea.

In small group projects, each person will be graded individually. A good group project is a system consisting of a collection of well defined subsystems. Each subsystem should be the responsibility of one person and be clearly identified as their project. A good criteria for whether you should work in a group is whether the system as a whole is greater than the sum of its parts!

We will start grading in the morning on 6/11. Please try not to submit late. If you submit late, please email us (cse512@cs) so we can re-pull your repository.