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

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

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

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.

• bibliography.

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

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

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

• 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.
  • Data and Task 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
    • typically data will need to come first, since you will need to refer to that data in your task descriptions.
    • it is very likely that you will need to first have domain-specific descriptions, followed by the abstracted versions.
    • it is often helpful to split these sections into two pieces: first have subsection where data is described in domain-specific terms, and then follow up with a next subsection where you've abstracted into domain-independent language. you may choose to have a separate Domain Background section before this one if there's a lot of specialized vocabulary/material to explain in order to have a comprehensible and concise data description.
    • similarly, it can be easier to write the tasks section by first providing a domain-specific list of tasks, and then present the abstracted version.
    • you should decide whether to split by domain vs abstract (first have both data and task domain-specific sections, followed by the abstractions for data and task) or to split by data/task (first have data domain-specific then data abstract, then have task domain-specific and finally task abstract).
  • 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. see this good example. teams of two or more people should include a breakdown of who did what work, as in this good example.
  • 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
  • Past marking scheme (note may change!): 12.5% for each of Intro, Related Work, Abstractions, Solution, Implementation, Results, Discussion, Style

• 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
  • Data and Task 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
  • Data and Task 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. it is very likely that you will need to first have domain-specific descriptions, followed by the abstracted versions. you should decide whether to split by domain vs abstract (first have both data and task domain-specific sections, followed by the abstractions for data and task) or to split by data/task (first have data domain-specific then data abstract, then have task domain-specific and finally task abstract).
  • 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)
  • Past marking scheme (note may change!): 50% for Analysis. 10% for each of Intro, Abstractions, Related Work, Methods & Tools, Style.

• 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)
  • Past marking scheme (note may change!): 60% for Main. 10% for each of Intro, Related Work. 20% for Style/Presentation/Writing.

• Visualizing Student Research though a Multi-Conditional Branching "Choose Your Own Adventure"-Style Tutorial (design study done by non-programmer, in Tableau)
• Buckets: Basketball Shot Visualization (design study)
• SEQIT: Visualizing Sequences of Interest in Eye Tracking Data (design study)
• PaperQuest: A Visualization Tool to Support Literature Review (design study)
• Visualizing Ontologies - A Literature Survey (survey)
• The Line of Time: Backgrounds and Usage of Event-Timelines (survey)
• Visualizing Lemur Survival Data (design study)
• The Use of Augmented Reality in the Operating Room: a Review (survey)
• Structure of a Motion Capture Database under Different Similarity Metrics (design study)
• Atmospheric Sounding Visualization (design study)
• Construction Change Order Visualization Analysis (analysis)
• Small-World Graphs (implementation)
• Alternate Futures (design study)
• Musicland (design study)
• BinX (technique)
• SkyScope (design study)
• Prawn (technique)

• Fall 2015
• Fall 2014
• 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.