Project Description

Overview | Software | Pitches | Meetings | Proposals | Peer Project Reviews | Interim Writeups | Final Presentations/Reports | Sample Outlines | Example Projects | Back to 547 Home


There are three kinds of projects: programming, analysis, and survey. You may do the projects solo or in teams of two or three. The total amount of work done must be commensurate with the size of the group.

Programming: For a programming project, you will implement a visualization system of your own. You may use existing components as the base for your system. Note that research novelty is not a requirement for a course project. The three common varieties of programming projects are:

Analysis: For an analysis project, you will pick an application domain to address, and write a combination survey/analysis paper about it. No serious programming is required, so this option is suitable for non-CS students. You will include a detailed survey of previous work in the area. This survey should be more considerably detailed than the required previous work section in the programming project writeup. You will pick one or more existing software tools to to analyze a dataset from that domain, so no serious programming is required. (You may need to write some scripts to change data formats, however.) The analysis should analyze the strengths and weaknesses of those tools, and discuss in detail whether they are effective for the task that you have chosen.

Survey: For a survey paper project, you will need to read many papers in a particular domain and write up a detailed survey. Talk to me for more details. Again, the writeup will be much longer than for a programming project, and this option is particularly suitable for non-CS students.


The language and platform for your project is your choice. You will submit your code along with to your final report, but I do not necessarily expect it to compile on my own machine.

There are pointers to datasets, and software packages/toolkits that you might use to build your final project on the Resources page.


You will briefly pitch your project idea(s) to the whole class. You'll have just 3 minutes each - like the proverbial elevator pitch, but in a really slow elevator... Slides are required. These pitches will give you (and me) have situational awareness of what other people are thinking of working on. You might find project partners, either because you find somebody else interested in what you care about, or you're more intrigued by a new idea than your previous plan. You must rehearse ahead of time to get your timing down! Pitch slides are due by noon on pitch day (Thu Feb 16) as PDF. You cannot use your own laptop, I'll compile them together on mine.


You must meet with me in person to discuss your project at least once before submitting a proposal. It may take more than one meeting for me to sign off that you're ready to move on to the writeup stage.

Your proposal should be based on an idea that we've discussed and I've approved. When you come talk to me about your proposal, I'll give you some pointers to background reading in the area of your interest. You need to meet me between Feb 28 and Mar 3 at the latest; earlier would be better. I will not hold meetings over reading week Feb 20-24. While I can sign off on some projects after only a single meeting, some people have needed two or three meetings to find an appropriate project that gets approved.


You're submitting a proposal, not a specification - it's natural that your plans will change somewhat as you refine your ideas. I advise that you start by thinking about what you want your software to do, and only then think about how you would implement it (languages, platforms, etc). The key is to find some domain and task that both interests you and presents an opportunity for infovis. That is, there is some task where a human needs to understand the structure of a large dataset. You're definitely welcome to link the infovis project to another class or research project. You may also build on existing software, but your project should include some implementation work of your own if it is a programming project.

I do not advise that you start by deciding on a language, and then look around for some task that you might be able to do in that language - that's backwards, and is likely to stifle your creativity.

Proposal format: your writeup should be at least two pages and include:

One proposal per project (whether it is individual or team) is due on Mar 6 by 5pm, as PDF by email with the subject header

547 submit proposal

For some guidance on the distribution of marks, a recent marking breakdown is domain/bg 10%, abstraction/solution 30%, scenario 15%, implementation 10%, milestones 15%, prev work 10%, style 10%. Note that this rubric might change.

I strongly recommend that you read the relevant section of the final report expectations below to understand more about what you will do, before writing the proposal.

Peer Project Reviews

There will be two peer project review sessions, on Mar 21 and Apr 24.

Interim Writeups

Update: I'm eliminating the written status updates since I've got situational awareness through the peer review sessions. What's now due on Fri Mar 31 is only the previous work section, as below!

A written project status update is due at the end of March. Tell me what you've gotten done so far, what obstacles you have encountered, and whether/how your plans have changed as you have gotten to work.

It should include a complete draft of the Previous Work section that will appear in the final paper. While you will be allowed and even encouraged to make minor changes, the bulk of your mark for this section will be assigned in this grading pass.

With the exception of the previous work section, the writing style can be more informal than the proposal and the final reports. I want you to spend time on the project not the writing, my goal is to make sure you've all gotten a good start instead of putting things off until the last minute, and to give you feedback if I see any signs of danger, and to make sure you've done due diligence with previous work before it's too late to make additions if need be.

Final Presentations/Reports

The final presentations will be the afternoon of Tue Apr 25 from 1-5pm. Refreshments will be served.
Final presentation length: The length will be announced once the final enrollment numbers are clear. Solo projects will have 12 minutes, two-person groups 15 minutes, and three-person groups 18 minutes (N/A this year). This time includes questions.
Final paper format: PDF
Code format: tar/gzip/zip package

You will present the results of your project with both a presentation and a written report. The final presentations are two weeks into the of the exam period; there is no exam. The report is due 3 days later. Showing live demos of your software in action is encouraged in the final presentation. If you are giving a demo, be sure to practice in advance so that you don't run over your time slot, and make sure to have screenshots (or video) prepared as backup in case of problem. The reports should be at least 6-8 pages of text (programming) or 14-18 pages (analysis and survey), and should include screen snapshots of your running software (programming and analysis). There is no length restriction, feel free to use as much space as you need for images.

Your final report should be a standalone document that fully describes your project. Do not assume the reader has seen your original proposal. It should have both the structure and form of a conference paper (with a few exceptions, as below). Use the latest InfoVis conference templates. Pay attention to my writing correctness and style guidelines.

You are encouraged but not required to also submit a supporting video, with or without voiceover. You are encouraged but not required to make your project available as open source. You are encouraged but not required to have a live demo of your project posted publicly.

A good article on technical writing is The Science of Scientific Writing Gopen and Swan, American Scientist (Nov-Dec 1990), Volume 78, 550-558.

Your code should be packed up as well. You must include a README file at the root giving a brief roadmap/overview of the organization of what you're handing in: which parts are your code, which parts are libraries, and so on. It should also state how to compile and run the program. I do not necessarily expect that your software compiles on my machine if you developed for a different platform, but I want to see what you've done.

Sample Outlines

Below are sample outlines for papers for each kind of project, based on my experience in marking a mix of strong and weak papers in past offerings of the course. This structure is halfway between a suggestion/guideline and a requirement. The requirement part is that I do expect you to include at least the material that I indicate. The suggestion part is that you may also include other material as well (for example, as additional sections), and you may choose alternative structures (for example, different ordering). Feel free to consult with me for advice if you're wondering about the pros and cons of different writeup structures.

The first outline of design studies is the most detailed - in the other three I don't repeat all the relevant information, but instead focus on how they differ structurally from this common case.

Example Past Projects

A few examples of particularly strong projects/papers from previous courses:

Here's the complete set of projects from previous years, to help you judge scope and consider possibilities:

Note that the writeup instructions for courses before 2014 were somewhat different: although there was still emphasis on analysis and abstraction, there was not the requirement of following the book's analysis framework (since it wasn't out yet).

There are several previous infovis courses that have project components, browsing through the final reports may help you think about what you might like to do, and what scope is realistic for a course project. Note that the scope of the projects may be different at other universities, so see in particular the ones in the previous versions of this course, listed above, for calibration.

Back to 547 Home
Tamara Munzner
Last modified: Tue Oct 24 05:01:36 PDT 2017