Course Components

The course components will contribute to your final grade as follows:

Participation

Participation is important: you're expected to attend all classes, demo coding experiments, read the papers, and contribute to class discussions. As a rule of thumb, try to contribute to discussion at least 1 or 2 times each class: ask a question, comment on a topic, clarify a point, etc.

Attendance alone is not enough for your participation mark. You must participate.

Micro-Reviews

Two days before each class with seminar papers, you will submit a compact three-part review of each paper being presented. The micro-review must answer three specific questions:

1. What is a specific strength? e.g. Is something very original and innovative? Is some aspect a particularly elegant insight or solution? Was there something surprising that you learned?
2. What is a specific weakness? e.g. Is there a weak or flawed assumption? Is there a methodological problem? Is there a better solution to some part? Was some aspect unclear or not fully explained?
3. How could you use the results? e.g. Could this justify a research decision? Could you extend or incorporate this in your research? t This could be an idea for a course project.

Each question must be answered in less than 300 characters.

All micro-reviews will be made public to the class after the submission deadline (with the first name of each student).

Seminar papers are marked with an 'id' consisting of the first author's name and year (e.g. "smith95").

You do not need to do a micro-review for the paper you are presenting on, for any paper or seminar not marked with an 'id', or for any related papers.

Coding Exercises

You'll experiment and extend the code and techniques from coding workshops (and possibly take-home exercises) to create an artwork-like coding "sketch". The goal is to demonstrate some innovation and competent execution of both an artistic aspect (the "concept") and in how the code was implemented (the "technical"). At the start of the following class, you'll demo your coding sketch for the class and say some words about your concept and technical approach.

Seminar

Every student is required to lead one 40 minute paper seminar and discussion.

Sign-up

You can request specific seminars or even certain days for your seminar. We'll do our best to assign you to one of these.

Instructor Review

You must submit draft presentation slides before 9am on Monday before your presentation day for the instructor to review. Comments will be returned before 5pm Monday.

Seminar Format

Use the paper content and examples as a way to introduce and address questions that go beyond the paper itself:

• Establish a context for the paper. Who are the authors (briefly)? What's the problem area? What is the relevant background? Why do we care? Why is the problem interesting, and why is it deep?
• What's the big idea and contribution of the paper? Why do you think the paper was accepted?
• How effective are the paper's results and/or ideas? What are the strengths and weaknesses?
• What are other related papers? Look for other papers by the same authors, references, and later papers that cite this one.
• What are potential applications, extensions, and/or future work?
• What did you learn? How could this paper apply to your course project?

As a rough guide, keep specific summary of information in the paper to less than a third of your talk and the rest for answering the questions above. Spread the specific content of the paper around and use it to ground the discussions of the more important seminar questions. Remember, everyone in the class will have read the paper ahead of time to create their micro-reviews, so everyone already has a good grasp of what the paper is about. Whatever you do, do not simply give a summary of the paper contents (the grading rubric below makes it clear you will not do very well if you do).

If you find that your slides cover all sections of the paper in the same order in which they appear, and you only show figures and tables from the paper, then you are creating a summary presentation. Don't do that.

Class Discussion

You are responsible for leading discussion during (and perhaps after) your presentation. Be prepared to get the class started by seeding the discussion with open-ended questions and some controversial statements.

You'll have access to the class micro-reviews about 48 hours before your seminar, so budget some time to read through them, and summarize the responses on your slides. You should call on specific individuals in the class during the discussion to expand or justify their responses (you'll have their names associated with the micro-reviews).

You'll have to manage the class: this means keeping people on topic, encouraging everyone to speak, and making sure the discussion isn't dominated by a few people.

Length and Structure

You have 35 - 40 minutes, but this will include significant class discussion.

• Make your presentation content about 15 - 20 minutes (about 15 slides), but spread these across the whole seminar.
• Many of your slides will be discussion points. You explain something from the paper, then get the class to contribute their opinions, ideas, etc.
• Use the content of the student micro-reviews, and call on specific people in the class to get their input.
• You should have at least 1 micro-review comment from everyone who submitted a micro-review, that way everyone has at least one guaranteed chance to participate.

Project

The final project is an interactive artwork described in a related "pictorial" research paper with an accompanying documentation video and source code repository. You'll give a live demonstration of your artwork in the final class in a "critique" format.

Proposal

Submit a description explaining your concept and technical approach. Include hand-drawn sketches and screen captures of your initial code experiments for support. No specific format is required.

Studios

Attend studio classes to discuss your in-progress project with the instructor.

Demonstration and Critique

You'll have 10 minutes to demo your artwork and field comments from the class.

Pictorial

You'll submit a 5-10 page pictorial paper.

A pictorial is a type of research paper that emphasizes visual communication (i.e., lots of images). The ACM SIGCHI Conference on Designing Interactive Systems (DIS) provides the following description:

Pictorials are papers in which the visual components (e.g., diagrams, sketches, illustrations, renderings, photographs, annotated photographs, and collages) play a major role in conveying the ideas and contributions of a study in addition to the accompanying text.

The link above gives a good description of general structure in "Pictorial Formatting," but the templates are not visually appealing, and there is no LaTeX version available. Instead, please use the "legacy" SIGCHI Extended Abstract format available in Word and LaTeX.

Here's an example of a pictorial using the "legacy" format:

Elvin Karana, Elisa Giaccardi, Niels Stamhuis, and Jasper Goossensen. 2016. The Tuning of Materials: A Designer's Journey. In Proceedings of the 2016 ACM Conference on Designing Interactive Systems (DIS '16). Association for Computing Machinery, New York, NY, USA, 619-631. https://doi.org/10.1145/2901790.2901909

As a general rule, your pictorial should have these sections:

• Introduction: Pitch your high-level idea to the reader, situate it in the context of HCI and related artworks (if applicable), and state what you contribute (an art experience, a tool for creatives, etc.). Include an evocative "teaser" figure that conveys the main look or idea of your project: this could be an installation view still, an example screen capture, or even some schematic of an underlying theory your project explores.
• Context: What papers inspired and/or informed your approach? Are there existing papers with similar artworks or systems? (It's ok if there are, a graduate course project does not need a "publishable" level of novelty.) As a general rule, I'd expect one or more references to the papers we read in this course. If not those exact papers, then similar ones published at the same kinds of venues they were published in (e.g., CHI, DIS, Creativity & Cognition). If your pictorial only references papers from other areas of CS or unrelated topics, you may want to check with the instructor. You should be using figures of related work in your write-up (remember, it's a pictorial).
• Experience: A detailed description of your artwork or system from a human-computer interaction perspective. This means describing what people see when they use it, what it can be used for, and why it’s interesting or useful. Figures like schematic flow diagrams, screen captures, video frame stills, etc., will be necessary to explain this clearly. Figures are crucial in this type of paper; in many cases, they convey more information than multiple paragraphs of text. Make sure you write descriptive captions for your figures.
• Concept: For artworks, describe what your artwork means or what it's intended to reference and suggest. This is a good place to justify your choices for graphics, color, layout, text, etc. Your goal isn't that viewers should "decode" this when viewing, but a good artist has strong justification for virtually every aesthetic and functional aspect in an artwork. For systems, justify why you chose the user interface design, the messaging, the color palette, etc. UX design should also have some intentionality.
• Implementation: Describe how you built the artwork or system. What libraries did you use? What's the general organizational structure of your code? What was the hardest part to implement? What part are you most proud of? You could show some excerpts from your code, but don't go overboard with full implementations. You may want to express key parts only, and you could also use pseudocode or a diagram. You don't need to provide enough detail for someone to fully reproduce your implementation: just enough to clarify the main structure and highlight the most interesting parts.
• Discussion: Reflect on what you did, suggest implications for artists, UX designers, or HCI researchers, provide some high-level self-evaluation regarding technical or user performance, and acknowledge the limitations of what you did. Be positive about what you did, but also frank and honest when discussing limitations and aspects like technical and user performance.
• Future Work: Briefly suggest future directions you would pursue if you had more time and/or provide advice for others considering similar work. One good topic would be a brief description of what kind of formal user evaluation and/or technical evaluation could be done in the future.

Remember, this is a pictorial, so your text should be concise and brief. You should be supporting/extending your text with pictures: photos, screen caps, conceptual diagrams, code excerpts, sketches, etc.

Video

You'll submit a link to a 1-2 minute video demonstrating your artwork.

The video should have a title and clearly demonstrate the artwork or system in operation. It isn't a presentation summarizing what's in the accompanying pictorial paper. Depending on your project, it may require a mix of screen captures and real-life shots of people interacting with it in an "installation view." The best time to capture real-life footage of your installation is just before or after your final class presentation.

• It should be landscape: this isn't a social media post on TikTok.
• Avoid adding background music or using fancy transitions; keep it minimal and honest.
• Use a tripod to avoid unintentional "shaky cam."
• When recording screen captures, the view should generally be fullscreen without debug information. Editing should remove startup and shutdown sequences unless they are relevant to your project.

Do not submit the video file. Upload it to a service (e.g., YouTube, Google Drive, or a UWaterloo server) so that there's a stable URL for you to include in your pictorial.

Code

You'll submit a link to your project code repository.

• You can host it on GitLab, GitHub, or another similar service.
• If your repo is private, please grant the instructor access.
• In most cases, your code should be clonable and runnable. Speak to the instructor if this is not the case.
• You should have a README in the root, but it can be brief and refer to the pictorial and video for more information. Provide any instructions to clone and run the code.