547 Course Structure

Description

This course will cover the computer-based visual representation of abstract data sets, designed to help people perform some task more faster or more effectively. In many cases these representations are interactive.

Delivery Mechanisms

Web: syllabus & all instructional materials, slides, videos, project deliverables
Zoom: synchronous sessions, office hours
Piazza: all asynchronous discussion, also logistics and other updates
Canvas: all handin, some marks (simple numeric)
email: some marks (written feedback)

Audience

My past experience in teaching this course shows that students need strength in at least 1 and preferably 2 of these 3 skills to succeed: programming, English, HCI.

Strong English communication skills are important for success in this course: there are substantial reading, writing, discussion, and presentation components in the required work.
Many of the project types require programming, so that skill will give you the broadest possible set of options. However, there are no enforced prerequisites, and grad students from other departments are very welcome. It's possible to for students in disciplines outside of CS to take this course without a programming background, by picking an analysis or survey project.
HCI (human-computer interaction) is helpful but not required; it's useful to take CPSC 544 (fine to do so simultaneously this term), or have taken an equivalent methods course elsewhere.
Many other skills are useful, including computer graphics, cognitive psychology, machine learning, statistics, or algorithms. Also useful is expertise in a particular application domain if you intend to do your project in it (bioinformatics, computer systems, etc).
I have found that students with weak backgrounds in all three of these areas have often not succeeded in previous years: weak programming skills, weak English (for example, if English is your second language and you struggle with fluency), and no HCI background is not a recipe for success.

This graduate course does not teach visualization libraries: most students will pick up D3 (Javascript), ggplot (R), or python-based visualization tooling on their own.
- For most undergrads, the new 4th year undergrad visualization course, next offered in January 2021, is probably a better match; D3 will be explicitly taught and a programming background is required.
Although the class is typically officially full at the start of term and often there's a waitlist, don't worry if you can't register: do show up anyway. In grad CS classes there is typically substantial churn in the first few weeks as people shop around, so it's extremely likely that you'll be able to get in. The waitlist has always been cleared in the past. I will give priority to people who have been attending all along and are caught up.

I'm open to unofficial auditors, there are usually a few each year. You'll get out what you put in: please do the reading for that session, so that you can participate in the in-class exercises and discussions. It's OK to come for the first several weeks and then stop if you get too busy with other things, but tell me that you're dropping it so that there aren't imbalances in the small-group breakouts that I assign before class.

Grading Scheme

50% Project
- 15% Final Presentation
- 25% Final Report
- 60% Content
- (25% Intermediate Milestones as pass/fail, penalty only if not submitted or not acceptable)
14% Sync: In-Class Participation

12% In-Class Exercise Participation (12 sessions, 1% per session)
2% Final Presentations Participation

36% Async: Readings & Online Discussion

9 weeks, 4% per week
Each week: 75% Comments on Readings, 25% Responses to Others

In many cases I'll be bucket-sorting individual subcomponents of your grade based on on a scale roughly following {great 100%, good 89%, ok 78%, poor 67%, zero 0%}, although the exact weighting may vary. Note that poor is not a passing mark in a graduate class.

There will be no final examination in this course, final project presentations will be during the final exams period (Thu Dec 10, time TBD).

The grading scheme is roughly proportional to estimated time spent. I assume available time is 12 hours per week across 14 weeks, for a time budget of 168 hours. The synchronous in-class meetings will take 1.5 hours per week, and occur during 12 weeks. Attending the final presentations will take 3 or 4 hours. I estimate about 7 hours of reading and writing time each week during the 9 weeks of reading and online discussion. The project should be scoped to take about 80 hours per person, spread throughout the term.

Synchronous In-Class Participation

The synchronous component of the class will include in-class exercises, working in small groups, Q&A sessions, and discussions. It will occur in the Thursday afternoon time slot (3:30-5). Participation is mandatory, I do expect you to attend and the material covered will be important for absorbing and internalizing the course material. It will be marked on a pass/fail basis: if you participate and you're engaged, you will pass. If you must miss class you should send me email with an explanation; this email should be in advance not after the fact, unless the problem is illness or emergency.

Asynchronous Reading & Online Discussion

The asynchronous (async) component of the course will take place over 9 of the weeks. For each week, you will do first do the assigned readings, then join the online discussion by first posting your own comments about the readings, then responding to comments from others. In most weeks there will be three assigned readings. In the online discussion, your own comments on the readings are due by Tuesday 3pm. You must post one comment on each assigned reading. Your responses to the comments of others are due by Thursday 3pm. You must post to at least one response to a classmate's comments each week, feel free to contribute further to the discussion as well. While you may choose to participate in the online discussion during the Tuesday 3:30-5pm time slot, feel free to do so when it is convenient for you.

Your submitted comments should be thoughtful, and clearly show that you've done the reading and reflected on it. They may either be phrased in the form of an observation or a question. Do be concise: aim for a short paragraph for each reading. 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", or anything that you could write without having thought carefully about the reading. As with any written work that you hand in, I expect correct grammar and spelling. Your responses to the observations and questions of your classmates should also be thoughtful and polite. I will also chime in to the online discussion.

For marking I'll start with pass/fail, I may fall back on explicit marking if I see quality issues.

Below are examples of graded comments from a Navigation/Zooming reading in a previous course, 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.

Back to 547 Home

Tamara Munzner

Last modified: Thu Oct 1 23:31:47 PDT 2020