547 Project Structure


Project Overview | Pitches | Pre-Proposal Meetings | Three-Pass Writeups | Proposals | Updates | Peer Project Reviews | Post-Update Meetings | Final Presentations/Reports | Sample Outlines | Example Projects |

Project Overview

There are three kinds of projects: programming, analysis, and survey. You may do the programming and analysis projects in teams of 2 or 3, or by petition solo projects may be permitted in exceptional circumstances. Survey projects must be solo. The total amount of work done must be commensurate with the size of the group, scoped to around 80 hours per person across the term.

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 four common varieties of programming projects are:

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. There are pointers to datasets, and software packages/toolkits that you might use to build your final project on the Resources page.

You may also build on existing software, but your project should include some implementation work of your own if it is a programming project. The scope of what you attempt will depend on your goals: some people actively want to learn the low-level details of a toolkit like D3 and will "roll their own"; others want to use one or more layers of libraries in order to build something more ambitious than what's possible when doing all the coding from scratch.

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; do be careful to be specific about the scope of your infovis class project compared to the other work that may occur before, after, or during it. That's especially crucial when one team member has been working on something for a while and is joined by other people on the team.

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 analyze a dataset from that domain using one or more existing software tools to conduct visual data analysis, 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.

Pitches

You will briefly pitch your project idea(s) to the whole class. This year, project pitches can be presented either through a video that you make in advance (see video production guide) or through a live talk. Pitch slides (and videos if you're choosing that route) are due by noon on pitch day (Wed Sep 29).

You'll have just 2 minutes each - like the proverbial elevator pitch, but in a really slow elevator... Slides are required (or other visuals such as animations). Audio soundtrack is required for videos. Note you can simply make a video of you talking through your slide deck. You should rehearse ahead of time to get your timing down!

Pitches serve multiple purposes. They are a deadline to get you to seriously think about what to do for your project. They can help make connections between potential project partners: you may find somebody else interested in what you care about, or find that you're more intrigued by a new idea than your previous plan. Even if you've already settled on a group, you'll gain situational awareness of what other people are doing.

If you have already decided on a group, you can have a single pitch for the whole group (with time equivalent to 2*X minutes where X= group size). If you have not finalized a group, then you need to create your own pitch. There may also be some pitches from external people who have interesting data and/or problems, that you might want to tackle.

We will be watching the pitch talks and videos all together during the class session that week, with brief Q&A following each one. We also will use Piazza for near-real-time continued discussion. We'll make a post for this discussion that's pre-populated it with one followup per pitch, so that you can easily add comments to each. This thread may be helpful to matchmake for project teams.

Pitch examples: 2020, 2019, 2017 Fall, 2017, 2015

Pre-Proposal Meetings

Groups need to be finalized by Thu Oct 7 8pm, at latest. Your entire group will meet with me to discuss your project the week before proposals are due. I will give you feedback on your ideas, to help you assess the viability of your plans, especially about whether you've picked the right scope (not too big, not too small). I may give you some pointers to useful papers as seeds to get started on your literature review.

You're also encouraged to meet with me earlier in the term, to discuss your project ideas, but that's not mandatory.

Writeups

Your project will be written up in three passes: the proposal, the update, and the final report. The first two passes are milestones that allow you to get formative feedback about both the content of your work, and the form that you've written it up. The last pass will be summative feedback, in the form of your final mark.

The overall structure and format of the document will be the same for all three passes, but the content will change. Some sections may be empty or minimal or preliminary for the first (proposal) or second (update) pass. If you've already gotten feedback that a section is in good shape in an earlier pass, you can rest easy and focus your attention on other parts of the writeup.

Proposals

One proposal per project group is due by Thu Oct 21 by noon, by uploading the PDF into Canvas. (We will enter your groups into the system.)

You're submitting a proposal, not a specification - it's natural that your plans will change somewhat as you refine your ideas, that's fine. Definitely read about the final report outlines below to understand more about the final version of the writeup that you'll be aiming towards, before writing the first-pass proposal. The description here is focused on the differences between the proposal and the final report, and assumes you understand what should be in the final report.

Proposal format: your writeup should be at least two pages and include:

Updates

The update milestone is a time to do a second pass on your writeup and get another round of feedback, about both project content and the writeup itself. For most teams, it would be wise to aim towards completing your Related Work section, so that you can just re-use it in your final report. For design studies, most teams will need to do a careful second pass on Abstractions, to refine them after the preliminary version that was in your proposals. Presumably you're making progress with the Solution, and do fill in screenshots for whatever you've done so far. It's not a problem to show work that's preliminary or imperfect, the goal is to provide a status report. Definitely update the Milestones section to explain clearly what parts of the work are done, vs in progress, vs not started yet: fill in actuals numbers for the items that have been completed, and you may be revising the breakdown of work into more or different items as the project has evolved over the first month. This update milestone is a good time to reflect on scope, possibly re-planning if reality is diverging from your original estimates.

Peer Project Reviews

There will be one peer project review session, on Wed Nov 17. It takes place after your team submits the written update document on Tue Nov 16. You'll get two different kinds of feedback on the update: fast-turnaround feedback from one other team on your project at this in-class review session in just a few days, in addition to feedback from me in a meeting the following week.

Pairs of project teams will be assigned to work with each other, I'll release the matchups before noon on Tue Nov 16. You will then have one day to read the update for the team you're matched with, which is required to be done before class time on Wed Nov 17 (3pm).

During the synchronous session, the teams will give feedback to each other through discussion about the project. In the first half, one team (the reviewers) will be giving feedback to other (the presenters); in the second half you'll switch roles. The feedback session can start with the reviewers talking through their initial reactions to the project. Reviewers can also ask about any aspects of the project that weren't clear when they read the update document. The presenters can show demos of their system in action so that the presenters can get a sense of how the interaction works. There can be a two-way discussion about design choices and tradeoffs.

Tips on giving feedback:

  • The reviewing team is responsible for writing down the feedback: ideally as you go, but if you're not taking notes incrementally then make sure to allocate enough time near the end of your time slice (5-10 minutes) to get those recorded before your turn is up. This "braindump" doesn't have to have polished grammar/syntax and can be a bullet list, the point is to get all the ideas that came up in the session recorded. What you write down should include the specific feedback from the reviewing team, plus any thoughts from the presenting team that were sparked by the discussion. The braindump should include the names and roles of the people in the discussion, and should be entered into the googledoc assigned to your pair of teams.

  • The goals of this exercise include

    Post-Update Meetings

    I will give you feedback on your written updates through a real-time meeting and discussion; your entire group should attend, as with the previous round of meetings. The time slots will be all of the class time block, along with some additional times TBD. More details on timing will be announced once the total number of teams is finalized.

    Final Presentations/Reports

    The final presentations will be the afternoon of Wed Dec 15, 2-6pm (PST). You may invite anybody who think would be interested; I do publicize the session to the entire CS department (typically a dozen or so folks have shown up for past in-person presentation sessions). Slides are required (and do include slide numbers). You may choose whether to make a pre-recorded video or give a live talk. In either case you will also submit the slide deck.
    Final presentation length: Group projects 10 min video/talk, solo projects 8 min video/talk. Both will have 2 min live Q&A after video plays.
    Final paper format: PDF
    Code format: tar/gzip/zip package

    You will present the results of your project with both a presentation (prerecorded video or live talk) and a written report. The final presentations are one week into the of the exam period; there is no exam. The report is due 2 days later.

    You will either submit a pre-recorded video presentation, which will be shown during the presentation session, or do a live talk. Then your team will do real-time Q&A. In either case, your presentation should use slides (do include slide numbers!), and you must also submit the slide deck. Showing live or prerecorded demos of your software in action is strongly encouraged. If you are giving a demo, you will likely need to practice in advance of actually shooting the video to ensure you don't run over the allotted time for that part of the presentation.

    The reports should be at least 6-8 pages of text (programming) or 14-18 pages of text (analysis and survey), and should include many screenshots of your running software (programming and analysis). There is no length restriction, feel free to use as much space as you need for images.

    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

    Below are sample outlines for papers for each kind of project, based on my experience in marking a mix of strong and weak papers in past offerings of the course. This structure is halfway between a suggestion/guideline and a requirement. The requirement part is that I do expect you to include at least the material that I indicate. The suggestion part is that you may also include other material as well (for example, as additional sections), and you may choose alternative structures (for example, different ordering). Feel free to consult with me for advice if you're wondering about the pros and cons of different writeup structures.

    The first outline of design studies is the most detailed - in the other three I don't repeat all the relevant information, but instead focus on how they differ structurally from this common case.

    Example Past Projects

    A few examples of particularly strong projects/papers from previous courses:

    Here's the complete set of projects from previous years, to help you judge scope and consider possibilities:

    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.


    Back to 547 Home
    Tamara Munzner
    Last modified: Thu Dec 2 16:50:45 PST 2021