Project Description

• problem-driven design studies, often based around a specific dataset
• technique-driven explorations of how to carry out specific encoding or interaction ideas
• implementations of previous published algorithms
• interactive explainers, similar in spirit to distill articles (new this year!)

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. This project type must be done solo, rather than in a team.

Software

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

Milestones

Pitch examples: 2019, 2017 Fall, 2017, 2015

Meetings

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 before Fri Nov 1 at 5pm. While I can sign off on some projects after only a single meeting, some people/groups have needed two or three meetings to find an appropriate project that gets approved.

Proposals

• heading
  • project title (possible to change it later, but come up with something specific now -- don't just say "CPSC 547 Proposal").
  • names and email addresses of all people on this project team. Do not include student numbers: these proposals will be posted publicly.

• intro: a brief description of what you're proposing to do, at a high level.
  • 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."

• data and task
  • for design studies: describe domain, task, data. You should definitely do so in domain terms. Get started on abstraction if at all possible, even if it's preliminary. Write down as much as you can, including domain-specific descriptions of tasks and data and the abstracted versions of them (including classification of attributes into categorical vs ordered). Make sure to discuss the scale of your dataset explicitly, including counts of items and specifics of how many levels for categorical attributes and ranges for ordered ones.
  • for technique papers: explain proposed context of use

• your proposed infovis solution.
  • You may not have much detail yet on visual encoding & idiom, but write down what you can
  • 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 yet, 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 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").
  • Also consider how you'll split up the work between group members, and write that down.
  • Milestones must be associated with target dates for completion.
  • New this year: for each milestone, also estimate of the number of hours each chunk of work will take. The Teamline proposal has a good example of this approach.
  • The scope of the work should be commensurate with the size of the group: roughly 70 hours per person (figuring 10 hours/week over 14 weeks for this course, with half of it going towards this project since it's worth half of your mark).

• previous work. while this section will not be nearly as complete as in your final report, you should begin to discuss what has been done in this area.
  • You should have an actual bibliography with references, it can include both academic work and any relevant commercial tools.
  • See references section of my Writing pet peeves

Peer Project Reviews

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. Pay attention to my writing correctness and style guidelines.

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

• 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.
• Sample outline: Interactive explainer paper
  • Talk with me if you want to try out this new project type! We'll evolve something together.

• An Eye-Tracking Visualization Towards Predicting User Distraction (good example of data abstraction and implementation sections)
• 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, later became InfoVis poster)
• PaperQuest: A Visualization Tool to Support Literature Review (design study, later became CHI poster)
• Visualizing Ontologies - A Literature Survey (survey, later became 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)
• BinX (technique)
• SkyScope (design study)
• Prawn (technique)

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