Final 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 on Piazza in the fp-team folder.

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-kanitw 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 org.

Submission

Fill the final project team registration form and submit a pdf file via Catalyst Dropbox. Please name the file proposal-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf (e.g., proposal-jheer-kanitw). 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 the rest of the class on Final Project Progress Presentation. 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. We recommend that you end your talk with a slide containing questions you'd like feedback on.
• Keep your presentation as brief as possible -- no more than a few (3-4) minutes. Use at least half of the 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.

Submission

Put your slides in pdf and progress report on Catalyst Dropbox by 5pm on 2/26. Name the files slides-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf and progress-uwnetid1-uwnetid2-uwnetid3-uwnetid4.pdf (e.g., slides-jheer-kanitw.pdf and progress-jheer-kanitw.pdf).

Final Poster Presentation

We will hold a public presentation of the final projects on March 13th the Atrium of the Paul 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.

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 7am on 3/20.

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-kanitw 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 just 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.

Since each repository are listed on our CSE512-14W repositories list. Please write 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).

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

Paper

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-14w.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.

Code

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.

Submission

• 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.