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.
In lecture, I will briefly discuss some of the
software packages and toolkits that you might use to build your
final project. A detailed (but not necessarily complete) list of these
packages is on the Software Resources page.
You're submitting a proposal, not a specification - it's natural that
your plans will change somewhat as you refine your ideas. But 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 Oct 10 and Oct 19 at the
latest, and earlier would be better. I will be out of town Oct 20-28. 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.
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
October 28 by 5pm, as PDF by email with the subject header
Do not assume your classmates have read your proposal. I have;
they probably haven't. You should
prepare a short presentation where you summarize what you're doing:
the problem and proposed solution for design study projects, the
technique ideas for technique exploration projects, the scope and
preliminary taxonomy for survey projects. Make sure you leave enough
time to explicitly discuss the progress you've made so far.
You will present the results of your project with both a presentation
and a written report. The presentation will occur during the final
exam slot for this course, and the report is a day and a half later.
The reports should be at least 8-10 pages of text (programming) or
15-20 pages (analysis), and should include screen snapshots of your
running software. There is no length restriction, feel free to use as
much space as you need for images. 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! Also remember that the audience has seen your project
update, so you don't need to repeat all of that. Focus more on your
results.
In contrast, 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, using the InfoVis templates. Your
paper should include the following information:
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.
A few examples of particularly strong projects/papers from previous courses:
Software
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.
Proposals
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.
A scenario spells out what a user
would have to do and what he or she would see step-by-step in
performing a task using a given system. The key distinction
between a scenario and a task is that a scenario is
design-specific, in that it shows how a task would be
performed if you adopt a particular design, while the task
itself is design-independent: it's something the user wants to
do regardless of what design is chosen.
533 submit proposal
Updates
The class sessions on November 14/16/21 will be used for project
update presentations. You should aim for 18 minutes each.
You must have slides, PDF or PPT or Keynote allowed. If you
want to use video, contact me the day before so that we can test
codecs.
If you're using my laptop, email your slides to me by 11am,
with the subject header 533 submit update
If you want to give a
demo on your machine, you can try, but have backup slides in your
slide deck in case it doesn't work immediately. Or a backup video.
If you're using your own laptop, email slides to me by 6pm (an hour after class).
Final Presentations/Reports
Final presentation length: 15 minutes total. 12 minutes present, + 3 minutes for questions
Final report format: PDF
Code format: tar/gzip/zip package
A good article on technical writing is The Science
of Scientific Writing Gopen and Swan, American Scientist (Nov-Dec
1990), Volume 78, 550-558.
Also, see my Writing Correctness and Style Pet Peeves list!
Here's the complete set of projects from previous years, to help you
judge scope and consider possibilities:
Projects From Other Courses
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 533 Home
Tamara Munzner
Last modified: Wed Nov 30 22:21:27 PST 2011