There are no enforced prerequisites. Grad students from other departments are welcome. Either or both of CS5630: Scientific Visualization and CS5610: Computer Graphics are very helpful but not required. It is possible for students in other disciplines to take this course without a significant programming background by picking an analysis project. At a minimum, projects will require simple scripting skills for wrangling data.

Information Visualization: Principles, Methods, and Practice (pre-publication draft), Tamara Munzner, AK Peters, (to appear 2012). Note from Tamara: these book chapters are an early draft and are far from finished. Do not quote. Many things will change!

Grades in this course will be determined by:

• 50% project
  • 20% proposal
  • 10% update
  • 5% final presentation
  • 30% process book
  • 35% content
• 25% presentations
  • 70% summary and analysis
  • 30% presentation style and context
• 25% participation
  • 75% written questions
  • 25% in-class discussion

There will be no final examination in this course, final project presentations will be in a 2-hour slot during the final exams period (Tues May 1st from 1-3pm).

I will send you email with detailed feedback on your work over the course of the term as it is completed. In many cases I'll be binning individual components of your grade based on on a scale of the sort {great 100%, good 90%, ok 80%, poor 70%, zero 0%}, although the exact weighting may vary.

Your final project will be in one of two flavors: programming, where you will implement a visualization system of your own; or analysis, where you will analyze a data set of your choosing using a variety of existing visualization systems. In both cases you will be responsible for acquiring data, creating a data and task abstraction of the problem your visualization system(s) will address, surveying existing visualization methods, and analyzing the results -- depending on your type of project you will emphasize these aspects to different degrees.

You may do the projects individually or in teams of two. The total amount of work done must be commensurate with the size of the group. Note that research novelty is not a requirement for a course project.

PROGRAMMING PROJECT: For a programming project, you will implement a visualization system you design and develop yourself. Common varieties of programming projects are:

• problem-driven design studies based around a specific dataset and questions of interest
• technique-driven explorations of how to carry out specific visual encoding or interaction ideas
• implementations of previous published algorithms

ANALYSIS PROJECT: For an analysis project, you will analyze a dataset/problem of your choosing using a variety of existing visualization tools, as well as analyze the strengths and weaknesses of those tools and discuss in detail whether they are effective for the data and task that you have chosen. These projects are problem-driven design studies in nature. No serious programming is required, so this option is suitable for non-CS students. You may need to write some scripts to change data formats, however. A (not necessarily complete) list of visualization tools can be found on the resources page. This style of project will require a much more extensive survey of previous work than a programming project.

-meetings, Feb 14 - 23
-proposals due, March 9 at midnight
-project update presentation, March 27, 29, and April 3
-final presentations, May 1 from 1-3pm
-process books due, May 3 at noon

Written proposal length: several pages
Written proposal format: PDF

Prior to submitting your proposal you will meet with me in person to discuss your project at least once before submitting a proposal. It may take more than one meeting for me to sign off that you're ready to move on to the proposal writeup stage. You'll need to meet with me between Feb 14 and Feb 23 at the latest, and earlier would be better.

I advise that you start by thinking about a domain/dataset/visualization method that you are interested in exploring more deeply. 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 welcome to link the infovis project to another class or research project. Keep in mind that you're submitting a proposal, not a specification -- it's natural that your plans will change somewhat as you refine your ideas. But 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.

Your proposal should include:

• project title

• names and email addresses of all people on this project team

• a description of the target domain, users, questions of interest, and data. Also briefly describe the level of experience or knowledge of the group members in the application area.

• your translation of the problem into abstract data types and visual analysis tasks. You should also include a description of the data transformations/aggregations/summarizations you anticipate needing. Abstraction is critical here!

• for programming projects: a description of your visualization design including illustrations of what the interface will look like and your proposed implementation approach. For the implementation description 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.

• for analysis projects: a description of your design requirements and the tools you plan use to analyze your data. You should also include how you plan to analyze the effectiveness of these tools. For example, are you going to compare several tools that were designed for the same type of data and tasks? Are you going to analyze the usability of a series of tools that support different aspects of your data analysis?

• a scenario of use including illustrations. 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.

• milestones and schedule. Include a list of project milestones, breaking down the work into a series of smaller chunks. Milestones should be associated with target dates.

• previous work. While this section will not be as complete as in your final process book, you should begin to discuss what has been done in this area. Your bibliography can include both academic work and any relevant commercial tools.

Pointers to advice on good writing can be found on the resources page. One proposal per project (whether it is individual or team) is due on March 2 by midnight, as a PDF by email with the subject header

6964 submit proposal

Update presentation length: 12 minutes total. 10 minutes to present + 2 minutes for questions

The class sessions on March 27, 29, and April 3 will be used for project update presentations. You must have slides in either PDF, PPT, or Keynote format. If you're using my laptop, email your slides to me by noon, with the subject header

6964 submit update

Do not assume your classmates have read your proposal. You should prepare a short presentation where you summarize what you're doing and why, your data and task abstraction, and your plan for analyzing the data, whether its the design of your system or details of the tools you plan to use. Make sure you leave enough time to explicitly discuss the progress you've made so far.

Final presentation length: 6 minutes total. 5 minutes to present + 1 minutes for questions

You will present the results of your project with both a presentation and a process book (discussed below). The presentation will occur during the final exam slot for this course on May 1 from 1-3pm. Showing live demos of your software, or the tools you analyzed, in action is encouraged in the final presentation. If you are giving a demo, be sure to practice in advance so that you don't run over your time slot! Also remember that the audience has seen your project update, so you don't need to repeat all of that. Focus more on your results.

Process book format: anything you want! A paper, slides, notebook, a book you bind yourself...
Code submission format: tar/gzip/zip package

Your process book tells the story of your project from its beginning to the final design. Equally important to your final results is how you got there! Your process book is the place you describe the space of possiblities you explored at each step of your project. It is not, however, a journal or lab notebook that describes every detail -- you should think carefully about the important decisions you made and insights you gained and present your reasoning in a concise way.

I strongly advise you to include many figures in your process book, including sketches of potential designs, images of your prototypes, screen shots from different visualization tools you explored, etc. Several images illustrating changes in your design or focus over time will be far more informative than text describing those changes. Instead, use text to describe the rationale behind the evolution of your project.

Your process book should include the following topics, however the specific format and content of the book is completely up to you. Depending on your project type the amount of discussion you devote to each of the following topics will vary:

• description of the problem: data, tasks, and users.

• related work

• problem abstraction. If your abstraction changed or evolved over the course of your project, be sure to describe how and why.

• design evolution
  • programming projects: What are the different design aspects you considered? Justify the design decisions you made, and show any major changes to your ideas. How did you reach these conclusions? Provide clear and well-referenced images demonstrating the design evolution.

  • analysis projects: What are the different tools that you considered? Why these tools, and what are their pros and cons? What data transformations did you explore and why? Provide clear and well-referenced images demonstrating your exploration of the data and tools.

• final design. Describe the design and functionality of your final design (for programming projects) or of your visualization workflow (for analysis projects). Provide clear and well-referenced images showing key elements of the final design. What was left unimplemented and why, or, what is missing from the workflow? What would you do if you had more time?

• analysis of data. What did you learn by using your visualization system or workflow?

• for teams, each team member's role over the course of the project

As this will be your only chance to describe your final project in detail make sure that your process book is a standalone document that fully describes your results and/or final design. Your process book and code (if you are doing a programming project) are due two days after the final presentations.

If you are submitting code it 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.

A few examples of process books. These are meant as inspiration and are not necessarily indicative of the scope for your specific information visualization projects.

• Magic Lens: A visualization of www.metadesign.com
• A Furniture Design Process Book

A few examples of projects from Tamara Munzner's infovis course at UBC:

• Structure of a Motion Capture Database under Different Similarity Metrics (problem-driven)
• Construction Change Order Visualization Analysis (analysis)
• Small-World Graphs (implementation)
• Alternate Futures (problem-driven)
• Musicland (problem-driven)
• BinX (technique-driven)

There are several other infovis courses that have project components that can be found on the resources page. 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.

Your presentations on the readings will take place in the second half of the course. Only the presenter is required to do the additional readings for a topic, although all students are welcome to do so. You will present 3 papers. At least 1 of them should be from the set that I assign. For the other 2, you're free to choose any papers on the topic, or to pick others from my provided list.

-topic choices due, March 7 at noon
-presentations, April 5, 10, 12, 17, and 24

• application domains
  • software vis
  • databases/datamining vis
  • cartography
  • bioinformatics vis
  • social media vis
  • vis for the masses
  • story-telling with vis
  • ...

• data domains
  • time-series data vis
  • text/document collection vis
  • tree/hierarchy visualization
  • graph drawing
  • high dimensional data vis
  • ...

• techniques/approaches
  • interaction
  • focus+context
  • navigation/zooming
  • glyphs
  • animation
  • brushing/linking
  • statistical graphics
  • ambient
  • ...

• other
  • frameworks/taxonomies
  • perception/cognition
  • evaluation
  • programming languages
  • data wrangling

Send me your top three topic choices by Wednesday March 7 at noon, with a subject header of

6964 submit topics

Presentation length: 20 minutes total. 18 minutes to present + 2 minutes for questions

You should prepare slides to accompany your talk. You may use the software platform of your choice to present these slides, as long as it's also possible to create a PDF version of your talk for the course web site. Most people use PowerPoint, Keynote, OpenOffice, or latex/beamer. There are links to advice on giving good talks on the resources page.

You may use my laptop for presentations. If you need to use anything except for PDF, Keynote, or PowerPoint, check with me in advance to make sure that the required software is installed on my machine. By noon on the day of class, send me either your presentation, or a note telling me that you're using your own laptop. In the latter case, send me your presentation right after class ends in PDF format.

Your email must have the following subject header:

6964 submit slides

Your presentation should not simply outline the papers. You will need to present the critical ideas in the paper so that your colleagues in the class have a basis for understanding your subsequent discussion. Part of this assignment is to use your judgement on what those critical ideas are and how to concisely present them. You should compare the approaches of the papers by a specific discussion of their relative strengths and weaknesses. Critique whether the proposed tools and techniques in these papers actually solve the intended domain problem.

Showing a demo or a video of one of the systems in action can be very helpful to show your colleagues the look and feel of an interactive system. If you want do this and plan to use my laptop to present, contact me in advance (at least the day before) so that we can sort whether the demo will indeed run.

This is the grading break-down I plan to use:

• content summary: 50%
• synthesis/critique: 20%
• presentation style: 15%
• materials preparation: 15%

You should do the core readings before the lectures and participate in class discussions during both lectures and student presentations. Your participation grade is based on the required reading questions you submit before class as well as in-class discussion -- both during the professor's lectures, and during your classmates' presentations.

Attendence in class is expected.

By noon (2 hours before class starts), you must send me email with a set of three questions/comments about the material being covered that day. I encourage you to also bring these with you to class and use them as a springboard for discussion. Your email must have the subject line

6964 submit QXX

Your submitted questions/comments should be thoughtful, and clearly show that you've done the reading and reflected on it. If you genuinely are confused by some aspect of the reading, then it's useful and legitimate to ask for clarification. However, simply asking something that you could trivially look up yourself is not a good question. Neither are vague statements like "I liked it" or "I learned a lot". As with any written work that you hand in, I expect correct grammar and spelling. Do be concise: a few sentences per question is good, with a maximum of one paragraph per question.

Your submitted questions/comments will be bucket-graded. Below are example questions, ranging from great to poor:

• great
  • I'm curious as to what would have happened if the authors had simply preselected the values of the free parameters for the participants in their user study, and then had the users compare their technique to the standard magnification tools present in a 'normal' application (much like the space-scale folks did). Could it be that the users are `manufacturing' a large standard deviation in the free parameter specifications by settling for values that merely produce a local improvement in their ability to manipulate the interface, instead of actively searching for an optimal valuation scheme?
  • In a related vein, the speed-dependent automatic zooming met with mixed success on some applications. Isn't this success related to how "compressible" some information is? i.e. because zooming must necessarily throw out some information, it isn't obvious which information to keep around to preserve the navigable structure.
• good
  • It would be interesting to compare the approach in this paper to some other less-mathematically-thought-out zoom and pan solutions to see if it is really better. Sometimes "faking it" is perceived to be just as good (or better) by users.
  • The space-scale diagrams provided a clear intuition of why zooming out, panning then zooming in is a superior navigation technique. However, I found the diagram too cumbersome for practical use, especially for objects with zoom-dependent representations (Figure 11).
• ok
  • This seems like something fun to play around with, are there any real implementations of this? Has a good application for this type of zooming been found? Is there still a real need for this now that scroll wheels have become prevailent and most people don't even use the scroll bar anymore?
  • Playing with the applet, I find I like half of their approach. It's nice to zoom out as my scroll speed increases, but then I don't like the automatic zoom in when I stop scrolling. Searching the overview I found the location I wanted, but while I paused and looked at the overview, I fell back in to the closeup. I think they need to significantly dampen their curve.
• poor
  • Well, what exactly Pad++ is? Is it a progarmming library or a set of API or a programming language? how can we use it in our systems, for xample may be programming in TCL or OpenGL may be ?
  • I learned some from this paper and got some ideas of my project.