Project Description

The idea of the project is to take the knowledge about visualization that you are gaining in the class and apply it to a real problem and real data. You are free to choose whatever application and data you like as long as the scope of the project is reasonable. I'm also providing you with a list of possible projects that you can pick from.

You will choose an application area and set of tasks and implement either a visualization technique or a system of your own. You may use any existing components or toolkits to help you build your system. The language and platform is also up to you.


Group Size: 2-3 students.
Expectations will be adjusted according to group size.

Important dates:

Project Types:

There are three types of possible projects: Technique projects, System projects, and evaluation projects. The three types of projects may be combined in some circumstances but please talk to us first.


You may choose the software that gets the job done best or that you are most comfortable with. A fantastic list of available software resources can be found on Tamara's page.

For a technique project I am expecting a significant programming effort on your part.


This year we require that you submit each milestone as well as your presentations to Moodle. There is a submission entry for each stage of the project. Note that you as a group have a total of two grace days for the various milestones but this does not include the presentations.


The project is worth 45% of your final grade.
Marking of the project will be broken down as follows:

20%: M2: Lo-Fi prototypes
    10% Content
    10%: Written report

20%: M3: Hi-Fi prototypes
    10% Content
    10%: Written report

5%: M2 or M3 presentation

60%: M4: Final
    10%: Presentation
    35%: Content
    15%: Written report

Presentations will be graded based on:

The content of your final report will be graded based on the completness and success of the followed guidelines given below. Finally, the written report will be graded based on:

This is all summarized in the grading sheet that we use.


M1: Project proposal (due Nov 05)

The project proposal does not count for marks. It is the first iteration of your proposal and a chance to get feedback on your proposal before it is marked.

Meet with us in person after you prepare your summary. While it might be ok to sign off on your project after only one meeting, it might require several iterations. Hence, please do not wait until the last day for talking with us and brainstorming together. In past years the groups that met with us beforehand to discuss their project had a much easier time.

I'd also suggest to not worry about any software systems to use until you have a clear understanding what visualization problem you are trying to tackle. What are the requirements and what are the expected outcomes? What user interaction will be required? Only after you have a clear understanding of the visualization issues, only then go and figure out which tools might be best suited to help you accomplish these set goals. Sometimes no single tool will accomplish what you need and you either have to pipeline different tools together or write custom code to extend a particular tool.

Prepare a webpage with the following information then, sign up for the project using the google form:

M2: Lo-Fi Prototyping (due Nov 19)

Expand and revise your Project proposal webpage. Include all of the information required for the proposal (you may update it or revise it) plus:

M3: Hi-Fi prototype (due Dec 10)

Starting from your Lo-Fi prototypes, you need to incorporate the feedback from us, as well as feedback from friends and colleagues to converge to a single high-fidelity prototype that you know realize within the platform of your choice (Tableau, D3, VTK, etc.). The main idea is that you can load actual, real data and play with it and test how well you will be achieving your goals.

For this milestone you will need to:

Your resulting prototype (and final version) must be a single integrated tool. Furthermore, it must employ at least 4 of the following techniques we discussed in the lecture:

M4: Final Submission (due Jan 21)

It may seem that once your software prototype is done there is not much left to do with the project. Not so! While you should spend time between M3 and M4 refining your software prototype based on feedback, the majority of your time should be spent analyzing your approach on your data and illustrating the pros and cons of your implementation. This typically requires a fair amount of trial and error and writing it up well takes time so plan accordingly

Due date: Jan 21
Report format: PDF document
Software submission: zip file

Your final submission should be both a report detailing your complete project as well as the software implementation of your project. Please combine the PDF report and software together and submit them as a zip file to Moodle.

Your software submission should be runnable from the submission file. Please include a readme file describing how to run your code. If the code does not run when we grade it then it will count as 0.

The final report should be a stand-alone document describing your complete project. You should assume the reader has no prior knowledge of your project and has not read your proposal. Include the following information in your report:

Your report should include screen shots of your software that demonstrate how it functions. There is no specific page limit so take as much room as you need for images. As a general guideline, reports should be approximately 8-10 pages long. Some of the above sections will be much longer than others. (I would advocate to write your report using the latex templates used for the Vis conference.)

If you don't object to it, your report and software will be available for future classes to get an idea what range these projects have.


A word on presentations in class. Here you have to give two presentations. Either you present M2 OR M3. In addition you will have to give a final presentation about M4. Make sure your presentations are well thought through and structured, practiced, and on time; don't 'wing it'. Your presentation should be prepared in a presentation tool such as beamer, powerpoint, keynote, or similar. Other requirements include

Include some questions or discussion points in your presentation to help you obtain useful feedback from the class. Also, please be mindful of the presentation time and practice so that you stay in time.

A simple outline for your M2 or M3 presentation could be:

For your final presentation (of M4), interested people from outside the class will be invited so you should expect a few members of the audience who have never seen your project idea. Give a complete description of your project, including the problem, approach, results, and an analysis of the strengths and weaknesses. Focus more on the results and analysis since most of the audience will have seen your proposal and update. Demonstrate how your software works through screen shots or a live demo. (If you choose to do a live demo, make sure you have screen shots available as a back-up in case something goes wrong.) Leave a bit of time at the end for audience questions.

Also, please practice your presentation so that you stay in time.

Projects from other courses

Several visualization courses from other schools have past projects posted online. Viewing these previous projects may give you some ideas or help you determine what scope is reasonable. A fairly comprehensive list of other courses can be found at Tamara's pages. What follows is a list of projects from the University of Vienna: