Project Description

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.

Software

Guest lectures from Matt Brehmer will briefly cover some of the software packages and toolkits that you might use to build your final project; the Resources page contains those pointers.

Pitches

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 20 and Oct 30 at the latest, and earlier would be better. 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.

Proposals

• project title

• names and email addresses of all people on this project team

• a description of the domain, task, and dataset that you're targeting.

• personal expertise. If you have expertise in that area, briefly describe it: anywhere from "this ties in with a project I'm doing for another course, I've just started doing reading in the area" to "I've been working on this for a year through an RAship" to "I've just been somewhat interested in this area for years, so I read about it occasionally". Or, of course, to "I don't know the area at all, but this seems like an interesting problem."

• your proposed infovis solution. You should propose an infovis solution, and of course relate it to your domain task and dataset. Abstraction is critical here!

• a scenario of use. A definition from TCUID:

  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.

• illustrations of what the interface will look like must be included in scenario. Hand-drawn sketches scanned in or mockups made with a drawing program are fine.

• your proposed implementation approach. You don't need lots of detail, just high-level things like which language and platform(s) you will use, and whether you will build on any pre-existing software or toolkits.

• milestones and schedule. Include a list of project milestones, breaking down the work into a series of smaller chunks. Milestones must be associated with target dates.

• previous work. while this section will not be as complete as in your final report, you should begin to discuss what has been done in this area. Your bibliography can include both academic work and any relevant commercial tools.

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

547 submit proposal

Status Updates

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.

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

• Sample outline: Problem-driven programming project paper (design study)
  • Abstract
    • concise summary of your project. do not include citations.
  • Introduction
    • give the big picture. establish the scope of what you did, some background material may be appropriate here.
  • Related Work
    • include both work aimed at similar problems and work that employs similar solutions to yours
    • structure into subsections based on your own synthesis of themes in the related work
    • although there is no requirement to establish research novelty since it's a course project, you should still discuss how the previous work is similar to or different from your own work (either individually or with respect to an entire group)
    • definitely cover academic work; it's often good to cover non-academic work as well (commercial software, thoughtful blog posts)
    • you may choose to reorder sections to put this one after Abstractions, if it will help you write this section more concisely/clearly.
  • Task and Data Abstractions
    • you should analyze your domain problem according to the framework of the book, translating from domain language into abstract descriptions of both tasks and data
    • you may choose to split Task and Data into separate sections; you may choose to have a separate Domain Background section before this one if there's a lot of specialized vocabulary/material to explain
  • Solution
    • describe your solution idiom, analyze it according to the framework of the book, and justify your design choices with respect to alternative possibilities
    • if you have done any significant algorithmic work, discuss the algorithm and data structures
    • you might choose to split out Interface into its own section
  • Implementation
    • medium-level implementation description. you must include specifics of what you did yourself versus what other components/libraries/toolkits you built upon. this section is one major divergence from standard research paper format, you need to provide much more detail than would normally be appropriate in a research context.
  • Results
    • should include scenarios of use and multiple screenshots of your software in action. walk the reader through how your interface succeeds (or acknowledge how it falls short) in solving the intended problem.
    • if you did any evaluation (deployment to target users, computational benchmarks), do report on that here.
  • Discussion and Future Work
    • Strengths, weaknesses, limitations (reflect on your approach)
    • Lessons learned (what do you know now that you didn't when you started?)
    • Future work (what would you do if you had more time?)
  • Conclusions
    • summarize what you've done in a way that's different from the abstract because you can count on the reader having now seen all of the content of the paper in between
  • Bibliography
    • make sure to use real references for any work that's been published academically, not just URLs
    • do pay particular attention to my instructions for checking reference consistency

• Sample outline: Technique-driven programming project paper
  • Abstract (same as above)
  • Introduction (same as above)
  • Related Work
    • while a big focus should be on work that employs similar solutions to the design choices in your proposed idioms, also include work aimed at similar problems (that is, that addresses the same combination of task and data abstractions).
    • same as above for the other four bullet points
  • Task and Data Abstractions Addressed
    • characterize what task and data abstractions your idiom work is designed to address, again using the book's framework. this section will probably be much shorter than the corresponding one for design studies, since it's closer to framing context than your core intellectual contribution.
  • Solution
    • same as above, but keeping in mind that you're putting more emphasis on describing a new idiom exactly than on justifying the use of existing idioms for the purposes of a particular domain problem. just as with design studies, you should analyze what you did in terms of design choices and justify why they were appropriate compared with alternative possibilities.
  • Implementation (same as above)
  • Results
    • same as above, but possibly with less emphasis on scenarios of how one particular group of target users might benefit and more emphasis on characterizing the breadth of possible uses of your idiom. you should still definitely include screenshots of the system in action.
  • Discussion and Future Work (same as above)
  • Conclusions (same as above)
  • Bibliography (same as above)

• Sample outline: Implementation programming project paper
  • Introduction (same as above: big picture of what you did)
  • Related Work
    • obviously the paper that you're reimplementing should be featured here, but there might also be some closely related work you want to discuss to provide a bit more framing context. this section can be considerably shorter than with the other two programming project types.
  • Scope
    • provide the big picture of what you did, especially if you cover only a subset of what was in the original paper or conversely if you've implemented work that's spread across multiple previous papers. you do not need to re-explain all of the ideas at the level of detail in the original paper. it's nice to make your writeup as comprehensible as possible in terms of a standalone document but it's reasonable to discuss similarities and differences in a way that assumes the reader has some level of familiarity with the goals of the previous work.
  • Implementation
    • detailed implementation discussion
    • as above, include specifics of when you build on capabilities of other components/libraries/toolkits versus what you coded yourself
    • a big difference is that you should also discuss issues that arose in your implementation - for example, choices you had to make that were not clearly specified in the previous paper, subtleties and nuances you discovered along the way, and challenges in adapting toolkit capabilities to your problem. this section will be much longer than with the other project types.
  • Results
    • as above, should include screenshots of your software that illustrate scenarios of how to use it
    • you should definitely include computational benchmarks to evaluate your work
  • Discussion and Future Work (as above)
  • Conclusion (as above)
  • Bibliography (as above)

• Sample outline: Analysis project paper
  • Introduction (as above)
  • Domain Background
    • analysis projects are done in the context of a particular domain problem, this section is where you explain relevant vocabulary and ideas that the reader will need to understand the rest of the paper
    • also summarize on your own previous experience and involvement with this domain and dataset, as in your proposal
  • Task and Data Abstraction
    • as with design study projects, a major part of your intellectual contribution is to translate domain-specific tasks and data to the abstractions covered in the book's framework.
  • Related Work
    • document how similar situations (at least in terms of data, possibly also in terms of task) have typically/previously been analyzed in this domain. if it's a scientific domain, then definitely include citations from that literature.
    • your main emphasis can be on previous work in the domain (similar problem), but you should also consider the previous work in terms of similar solutions (that is, how your chosen tools have been used to solve
    • as above, no requirement for research novelty, choose an appropriate subsection structure, and you might move this section earlier or later as needed.
  • Methods and Tools
    • if your specific dataset has been previously analyzed by you or others in your research group, describe how it was analyzed and what is already understood about it.
    • explain what visual data analysis idioms you have chosen to use, and justify these choices with respect to alternatives as covered in this course
    • explain what tools you have chosen to use for your analysis, and why they're appropriate (again, with respect to alternatives)
  • Analysis
    • present the results of your visual data analysis. include screenshots of the tools in action. your discussion should include two levels of analysis: the specifics of what you learned in terms of the domain problem, and your reflection on how the visualization helped you understand it.
    • discuss the strengths and weaknesses of the different approaches that you took - in terms of both idioms and tools. this analysis can either be interleaved throughout, or in a separate section at the end.
  • Discussion and Future Work (as above)
  • Conclusion (as above)
  • Bibliography (as above)

• Sample outline: Survey project paper
  • Introduction
    • discuss the scope of what you're covering, and why that's an interesting/reasonable partition compared to visualization as a whole
  • Related work
    • focus here on previous surveys, and how your work is similar to or different from them - especially in terms of coverage. it's a survey paper, so obviously you're not going to cover all previous work here!
  • main body of paper
    • break up into sections based on your own synthesis of the themes of the previous work that's within your scope
    • you might want a Background section at the start if you're doing a domain-focused survey where there's important vocabulary/ideas to establish before diving into your main discussion
  • Discussion and Future Work (as above)
  • Conclusion (as above)
  • Bibliography (as above)

• Visualizing Lemur Survival Data (problem-driven)
• The Use of Augmented Reality in the Operating Room: a Review (survey)
• Structure of a Motion Capture Database under Different Similarity Metrics (problem-driven)
• Atmospheric Sounding Visualization (problem-driven)
• Construction Change Order Visualization Analysis (analysis)
• Small-World Graphs (implementation)
• Alternate Futures (problem-driven)
• Musicland (problem-driven)
• BinX (technique-driven)
• SkyScope (problem-driven)
• Prawn (technique-driven)

• Fall 2011
• Fall 2009
• Fall 2007
• Fall 2006
• Fall 2005
• Fall 2004
• Spring 2004
• Spring 2003

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.