Content
By noon (2 hours before class starts), you must send me email with a set of questions/comments about the material being covered that day. You should include at least one question/comment per reading. 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.

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

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

Submission Details
Submit your questions by noon (2 hours before class starts) via email to miriah@cs.utah.edu. 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

7960 submit QXX

Content
You will prepare a mini-lecture on the papers you are asked to present. 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. If presenting on more than one paper, you should compare the approaches of the papers by a specific discussion of their relative strengths and weaknesses as they relate to the lecture topic.

Often papers on systems, techniques, or methods will be accompanied by a video or demo. I encourage you to make use of these if they are available.

Presentation
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.

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

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

Submission Details
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. Submit your presentation via email to miriah@cs.utah.edu. Your email must have the subject line

7960 submit slides

Content
Your paper draft is not expected to be a complete paper -- most of your projects will likely take more than the semester to finish. You will, however, be able to describe your domain characterization, abstraction, and initial design ideas.

Now that you've read a number of design study papers you should reflect on what you thought made for a clear, concise, and persuasive paper. Keep these things in mind as you work on your write-ups. I will give you feedback on each stage of writing. We will also workshop your final drafts as a class on the last day of the semester.

Your final write-up must be in the IEEE VIS format, the details of which can be found in the Call For Papers. You are welcome to submit your domain and abstraction write-ups in whatever format you'd like.

Domain write-up, due Thurs. Feb 28
Based on feedback from the domain characterization workshop you should write-up a summary of the problem you are tackling. What is the field? Who are your target users? What questions are they asking, and what measurements have they aquired? What is the potential impact of their work? Please include only the necessary information about the domain that is needed to motivate and understand the problem.

Abstraction write-up, due Tues. Mar 12
Based on feedback from the abstraction workshop you should write-up a summary of your abstraction. Be as clear and concise as possible about the structure and type of data, any transformations you decide to do, and the specific tasks you are going to support.

Full write-up, due Thurs. Apr 12
This write-up should include an introduction with anticipated contributions, a review of relevant visualization literature, the domain description, and your abstraction. You should also discuss and justify your design ideas -- prototypes are fine here. In justifying your design, you should consider both your stated tasks and visualization design principles.

Submission Details
Submit your write-ups via email to miriah@cs.utah.edu. Your email must have the subject line

7960 submit XXX write-up

where XXX is the appropriate phase of writing.