547 Project Structure

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

You are also required to submit a teaser image showcasing your project (normally, a screenshot) that is suitable for a medium-sized thumbnail image for the projects web page. 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. What I really want to understand is what code your team wrote, versus what existing libraries you're building upon. Make that distinction extremely clear in the README.

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.
  • Milestones
    • Include a list of project milestones, where the work is broken down into a series of smaller chunks that are meaningful and useful for your specific project. Your milestone list shouldn't just be completely generic (eg "requirements analysis, design, initial coding, iterative refinement, final presentation preparation, final paper writeup"). While something analagous to these stages may well make sense for your project, you should also be thinking about how to break down the work into components that are appropriate for your project in specific (eg "create database view", "Complete League View, begin lower ranked features").
    • Milestones should include four numbers: estimated number of hours to carry out each task, actual number hours it took, estimated date of completion, actual date of completion. The Teamline proposal has a good example of this approach. You should also document how the work is split up between team members. Remember that the scope of the work should be commensurate with the size of the group: roughly 80 hours per person.
• 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.
  • make sure to save all screenshots with lossless compression (PNG) not lossy compression (JPG) so that the text is readable not jaggy.
• 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
  • make sure to check if arxiv papers have been later published in formal venues, forward link is on many pages!
  • 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

• 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)

• 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)

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

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

• Structurally identical to design study paper, although content within some sections will be a bit different.

• An Eye-Tracking Visualization Towards Predicting User Distraction (good example of data abstraction and implementation sections, led to published paper)
• Visualizing the Bias-Variance Tradeoff (explainer)
• CrimeVis: A tool for crime visualization in Vancouver (thoughtful and well written, good discussion what what did not do, and future work)
• Teamline: Visualizing small team code contributions (design study)
• 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, led to job with Boston Celtics)
• SEQIT: Visualizing Sequences of Interest in Eye Tracking Data (design study, led to InfoVis 2015 poster)
• PaperQuest: A Visualization Tool to Support Literature Review (design study, led to CHI 2016 poster)
• Visualizing Ontologies - A Literature Survey (survey, led to published paper)
• 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 led to InfoVis 2004 poster)
• BinX (technique, led to InfoVis 2004 poster)
• SkyScope (design study)
• Prawn (technique)

• Fall 2019
• Fall 2017
• Spring 2017
• 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).

Note also that the instructions for proposals were different in previous years, and there were no update writeups.