ARTG 5330 - Visualization Technologies 1: Fundamentals

A. Proposal

The proposal must be uploaded as a PDF or Google Doc through Canvas. It is expected that your plans will likely change as you refine your ideas. Please read the final report outline below to better understand the outcome you'll be aiming towards.

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

• Header
  • Project title (possible to change later)
  • Student's name and email address
• Introduction: A brief description of what you're proposing to do, at a high level.
  • Personal expertise: If you have expertise in the area you're proposing to work in, briefly describe it. You can say something like, "This aligns with a project I'm working on for another course. I've recently started reading in this area." Or, "I've been working on this for a year through an RA position." Or, "I've been somewhat interested in this area for years, so I occasionally read about it." Of course, you can also say, "I don't know the area at all, but this seems like an interesting problem."
• Related work: While this section will not be nearly as complete as in your final report, you can begin to discuss what has been done in this area. Consider both academic/research work and any relevant commercial tools or efforts from practitioners.
• Data and task abstraction
  • 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.
• Solution: Your proposed visualization system.
  • You may not have much detail yet on visual encoding & idiom, but write down what you can.
  • Implementation: 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.
  • Results: You won't have any results yet, of course, but what to include here in the proposal is 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 you currently think the interface will look like must be included in the scenario. Hand-drawn sketches scanned in or mockups made with a drawing program are fine.
• Milestones: You obviously won't have the actual dates and deliverables, but do come up with estimates. Also include your plans for how the work will be split up between weeks. This is one of the most important parts to put thought into at the proposal stage!
• Bibliography: Your proposal document should have an actual bibliography with references.

B. Updates

The update milestone is a time to do a second pass on your writing component and get another round of feedback, about both project content and the write-up itself. It would be wise to aim towards completing your Related Work section, so that you can just re-use it in your final report. You 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 actual 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.

C. Final presentation/report

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 before the term ends; there is no exam. The report is due a week later.

• Final presentation length: 12 min video/talk, 3 min live Q&A.
• Final paper format: PDF
• Code format (if applicable): zip package

Presentation

You will either submit a pre-recorded video presentation, which will be shown during the presentation session, or do a live talk. Then we will do a 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 visualization system 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.

You may invite anybody who you think would be interested; faculty and students from the digital media and IDDV programs will be invited. 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.

Report

The reports should be at least 6-8 pages of text, and should include many screenshots of your visualization system. 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. Use the latest VIS conference templates.

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.

Code

Your code (if applicable) 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 you wrote, versus what existing libraries you're building upon. Make that distinction extremely clear in the README.

Report sample outline:

• 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 hard requirement to establish research novelty, if you choose to do a course-specific project, you should still discuss how the previous work is similar to or different from your own work.
  • 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 abstraction
  • 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 a 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.
  • 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.
• 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 analogous 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 of hours it took, estimated date of completion, actual date of completion.
• 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.
  • Be consistent with your reference system.