No name
No country
No term
No term
No language
No academic level
No academic fields
Introduction to Interactive Media
Instructors
- Pierre Depaz
- Scott Fitzgerald
- Michael Shiloh
- Aaron Sherwood
- Michael Ang
Description
With the advent of digital computation, humans have found a variety of new tools for self expression and communication. However, most of the interfaces to these toolsets are created with a computer in mind, not taking into account humanistic needs of design and usability. Additionally, computers have traditionally lacked knowledge of the richness of the physical world. As such, their understanding of our needs has been informed by click and taps, seeing the world as a binary system of on or off.
This course explores creative computation through software and hardware. By approaching software and hardware design as artists and designers with an emphasis on human-based factors, we can explore new paradigms of interaction with machines and each other. Using open source software environments and open hardware platforms, we will look at way of making these tools work for us. No background in programming or electronics is expected. A sense of play, desire to experiment, and a DIY attitude is strongly encouraged.
Learning Outcomes
- Think critically about interaction design principles for hardware (physical) and software (screen based) interfaces
- Work with basic electronics, including analog and digital sensors and actuators
- Understand and be able to implement basic principles of computer programming, including working with objects and classes
- Use a computer as a tool for self expression
- Bring information about the physical world (such as light, pressure, temperature) into the computer and process it in an interesting fashion
Topic Outlines
- Hardware prototyping with Arduino
- Software prototyping with Processing
Readings
- Getting started with Arduino, Massimo Banzi.
- Getting started with Processing, Casey Reas and Ben Fry.
- Learning Processing: A Beginner’s Guide to Programming Images, Animation, and Interaction, Daniel Shiffman.
- Arduino Cookbook, Michael Margolis.
- Make: Electronics, Charles Platt.
- Making Things Talk, Tom Igoe.
- Making Things Move, Dustin Roberts.
Grading Rubric
•10% Attendance
•10% Participation
•20% Weekly assignments
•10% Stupid Pet Trick
•25% Journal entries
•25% Final project
Assignments
- Daily Assignments: Every class you will have an assignment. Some of the time it will be reading, some of the time it will be practical. Each day there’s a “walk-through” element that will be covered in class, which you are expected to do on your own, and an improvisational aspect, where you take the lesson and make something unique and interesting based on the in-class review. We will spend time in each class reviewing your work, and using this as an opportunity to review concepts that are unclear, or investigate solutions to common problems. Expect to be asked to show your work every time we meet. Some classes everyone may demonstrate their work, other classes only a few students may, but always be prepared. All of your work must be documented on the class site (see below for details). Assignments are due before class starts on the day they are due. Each day they are late 15% will be subtracted from the grade for that assignment.
- Online Journal: You are expected to contribute to our shared online journal. The purpose of the journal is twofold. First, it is a valuable way for you to communicate to me that you are keeping up with the work in the class. I read the site to see how you are doing. At a minimum, reference to your work is expected, as well as reference to the readings, and thorough documentation of any research. Secondly, the journal is a way to document your work for your own use and that of others. You must update the journal weekly with the work you have done for class. Document your projects thoroughly as you go; don’t put it off until the end. Photos, video, drawings, schematics, and notes are all valuable forms of documentation. Explain the project at the beginning of your documentation, so that people who come to your site from outside this class can understand your work quickly. Use pictures, drawings, and videos liberally to explain your work. Don’t overload your notes with code. Code repositories like gitHub are best for sharing code, rather than blogs, so post your code to a repository and link to it from your blog. When you base your code on someone else’s code, cite the original author and link to their code, just as you would when quoting another author in a paper. If you only changed one part of an existing program, post only the part you changed, and link to the original. Make sure any code you post is well-commented, so you and others can understand what it does. Always cite the sources of your code, the places you learned techniques from, and the inspirations of your ideas. Copying code or techniques without attribution is plagiarism. Few ideas come out of the blue, and your readers can learn a lot from the sources from which you learned and by which you were inspired. So be generous in sharing your sources. Good documentation should include a description and illustration of your project. You should include what it looks like, what it does, what the user or participant does in response. When it’s interactive, mention and show what the user does. Your explanation should give enough information that someone who’s never seen the project can understand it. You should also include a section describing how the project works, aimed at a more informed reader (your instructor, or next year’s classmates). Include a system diagram to make clear what the major components of the system are and how they communicate. You should use the journal as an opportunity to write clear, concise thoughts or questions based on the weekly topics. The writing is expected to be well reasoned, grammatically correct, and written as if it were a paper being turned in. You should link to any relevant sources, and provide as much context as you can using images, video, audio, or other forms of expression. I’ll set you all up with an account the first day of class.
- One-Trick Poney: Working individually, make a simple physically interactive device that uses the skills you’ve learned in class. It must respond to a physical action or series of actions a person takes, and it must be amusing, surprising, or otherwise engaging. It doesn’t have to be practical, or complex, as long it shows that you understand the basics of digital and analog I/O and how to use them. The project must be well documented on video: – multiple shots – lighting – music/voice over – text overlay – narrative or story
- Final Project : Create a physically interactive system of your choice that relies on a multimedia computer for some sort of processing or data analysis. Your focus should be on careful and timely sensing of the relevant actions of the person or people that you’re designing this for, and on clear, prompt, and effective response. Any interactive system is going to involve systems of listening, thinking, and speaking from both parties. Whether it involves one cycle or many, the exchange should be engaging. A few examples: Musical Instruments. Performing music involves a sustained engagement between the performer and the instrument. The feedback from the instrument has to be immediate and clear in order for the performer to continue playing. The interface has to be flexible so that the musician can exercise her creativity in playing, but has to have some boundaries so that she knows what the instrument can do and what it can’t do. Game interfaces. Like musical instruments, they involve constant back-and-forth interaction and immediate response. They are often simpler than musical instruments. In fact, the standard game controller has gotten so standard that the action of many games is artificially adapted to the needs of the controller, not the physical expressiveness of the player. Pick a specific game and see if you can change that. Assistive devices. Whether it’s something as simple as a reaching device (think of pickle pickers) or something more complex, these devices are very demanding of clear, reliable response. Remote control systems. They require not only a clear interface, but must also return enough information on the remote system’s action to let you know that you’re doing the right thing. Whether it’s a remote controller for your home electrical devices or a Mars rover controller, the need for clarity and good feedback are equally essential to the person who it’s made for.
Other
This course is a production based class. You will be doing work in and outside of the class that is ideally experimental, participatory and collaborative. In lab courses we will review topics like programming techniques and circuit design, while non-lab class days will be given over to lecture and discussion based on readings, videos, audio, and interactive works found primarily online.
Course Resources
Course website
Includes the student blogs for example work.
Syllabus
Schedule
Uploaded by Pierre Depaz on 2023-07-03