Project No. 2: Flow

Contents

Flow

Information takes many forms in the world; for our purposes, anything that could be said to be observed can be interpreted as information. For instance, “information” could be contained in the brightness of a light bulb, the greenness of a leaf, the power of a punch, the pitch of a performer’s scream, the quietness of a room, the coldness of a freezer, or the rate of the Monongahela’s flow. Information also is encoded in lots more complex ways, too, of course—the tone of a person’s voice as they say “please,” the timbre of a violin’s plucked string, the eyebrows’ positions on somebody’s forehead as they steal a quick glance, or the thickness of a calligrapher’s stroke.

All of the first range of examples given above can be said to be immediately quantifiable in some way: we have direct and straightforward ways of measuring brightness, color intensity, mechanical force, sound volume, temperature, and the speed of a river’s flow. In contrast, all of the second range of examples are for different reasons harder for a machine to measure; a computer can’t easily be taught to interpret the particular meaning of a whining “please?” as compared with the barked order, “please!”

Many interactions we have with the world can to some extent be relabeled (or reconceptualized) as a sort of flow of information. You flip a switch to make the room bright, and in so doing you are transmitting a sort of information from your mind, into your hand, into the switch, into the lamp, and then into the room. The traveling impulse, if we think of it that way, could be said to change forms many times in its journey: in your brain, it is an electrical signal, in your hand it is a mechanical movement, in the switch it is mechanical as well, in the wire it is electrical, in the lamp it is heat and light, and finally in the room it is illumination.

Transduction

Each time an impulse changes form or medium, it can be said to be transduced: etymologically it’s been lead across from one form to another. These transductions may be near-instantaneous (it takes very little time for an LED to light up once it gets power), or might take longer (it could take ten or twenty seconds for a large motor to reach full speed after it gets power). A transduction may need to be mediated by a purpose-built circuit or machine (e.g. a device that turns light intensity into a sound pitch), or it may occur through a natural process (e.g. ambient humidity makes the scales of a pine cone move in and out).

Transduction is constantly occurring across many domains all the time. A light wave moving from air into water has changed media, and in so doing it is refracted (and some of it may also be reflected). Depending on circumstances, the transduction may be nearly totally efficient, or it may be very lossy (energy inefficient). For this assignment, we are more interested in active flows of energy that are totally kinetic/instantaneous; so while one could speak of the chemical energy of gasoline being transduced into mechanical motion of a car, that couldn’t be neatly categorized as a true flow per se. (The moment the car is shut off, the potential energy just sits in the gas tank, no longer changing forms at all.)

Assignment

Build an interactive device, experience, performance, ritual or mediated happening which uses actual (not Wizard-of-Ozzed or otherwise artificial) mechanized/automated means to transduce at least one input signal into at least one output signal that is in a different domain.

The piece may take a social/political/ideological stance, or may be closer to a science museum interactive piece. It may focus on the transduction process itself, or simply use the transduction in the service of a particular purpose.

Requirements:

You will build a device to transduce a signal.
You will incorporate and consider how performance relates to the interactivity of your piece’s transduction. Maybe your piece is a solo performance where transduction plays a vital role during the quiet or the climax of your piece. Or instead, does the audience interact in a performative way? Do they have to crawl through a tunnel, climb a ladder, run, jump, or yell to cause the transduced outcome?
The interactivity should be bigger than your body. That does not mean that the device is large, but that how one interacts is larger than a body.
The input and output signals must be in different domains—i.e. if light levels are read as input, the output cannot be light.
The transducer, or transducer system, can have as many internal pieces as you wish.
The system should accept, and accordingly output, a range of values. This is to say that if it’s measuring a light level as input, then its output should have one strength/value when the input is at 0 lux, a different (smaller or greater) output when the input is 10,000 lux, and a different (smaller or greater) output when the input is 1,000,000 lux. The size of “step” between different inputs and outputs can vary as needed, but there should be a minimum of 10 steps available across the input and output ranges.

We are able to allocate course budget for purchasing materials for your project needs; please fill out the Course Purchase Request Form as soon as you have certainty about what material(s) you’ll need so that we can place orders with plenty of lead time!

Important Dates

Thurs, October 10 – Three Project Ideas are DUE

Prepare three distinct project ideas to turn in during class. Please turn these in on clean sheets of 8-1/2″ x 11″ paper. You may want to consider making copies before you turn these in on Thursday.

EACH PROJECT IDEA SHOULD INCLUDE:

A page-length (~300 word) narrative description addressing:

1. 1. 1. Intended interaction mode by members of the public and/or performers and/or yourself (whatever is appropriate to the piece)
    2. Intended siting (where will it live and how will it be installed?)
    3. Intended experience for the audience
    4. Theoretical underpinnings (e.g. what led you to this idea, what about it intrigues you, etc.)
    5. Relevance to you and your practice
At least three drawings showing the proposed build (drawings need not be high-fidelity; sketches are certainly fine)
Basic listing of needed materials as well as sources (on or off campus) for those materials (this need not be a finalized purchase list!)

We will review your proposals with you individually in class and you will provide group feedback to each other. We will also provide you with written feedback.

Tues, October 15 – Embodying Flow

Create a short performance (30 seconds – 3 minutes) that illustrates the use of transduction in your Project No. 2.

Please use one or multiple people as your parts of your transduction machine.
In order to communicate your idea to your performers, please come to class with a simple cartoon-style diagram of the intended signal flow, where the performers will be located, and the specific locations of each of the signal inputs and outputs. This diagram should include both text and sketches. Please consider:
1. Different qualities of movement
2. How the piece will engage with the Media Lab space
3. How to communicate those ideas clearly and efficiently
Be sure that your system does not only respond to binary input and only produce a binary output, but instead is sensitive and responds to a range of input stimuli, i.e.: your system/choreography should map a continuous input range to a continuous output range.

You will share these at the beginning of class on Tuesday.

Tues, October 22 – In Process CRITIQUE

You will present some sort of prototype in class for critique. It need not be high-fidelity. There is a lot of different thinking in the design world about what “prototyping” means. Designer and academic Graham Pullin, in his excellent Design Meets Disability (2011), helpfully outlines a few different approaches:

feels-like prototype: an ergonomic prototype for physical feeling in hands, etc.
looks-like prototype: an appearance model for form, color, materials, etc.
works-like prototype: an engineering prototype for electronics and electromechanical build, etc.
behaves-like prototype: an experience prototype for interactions. It may have tethers instead of being wireless, or be built larger than the proposed final size, but the fundamental user interactions are well-modeled. (p. 138)

You do not need to explicitly state what kind of prototype you are showing—but you must have something that shows clear progress towards your final goal. It may be the same physical thing that will become your final project, or it may be a version that you’re using to test out some possibilities. It is expected that you will allocate your time on the prototype as you feel makes the most sense: if you know the electronics of your project are simple, then use this due date as an opportunity to focus on the interactive or aesthetic aspects of the project. On the contrary, if the electronics or interaction will be hard, then focus on that and put it in a cardboard box (or no box at all).

In class, we will briefly critique the prototypes. This deadline is meant to help you prepare to deliver a finished project one and a half weeks later.

Thurs, October 31 – Project No. 2 DUE + CRITIQUE

Thurs, November 7 – Documentation is DUE for Project No. 2 at the beginning of class

What to submit (documentation content requirements)

If you have any questions about the submissions requirements, or run into technical problems, be sure to contact either Heidi or Zach.

Each documentation submission must consist of at least:

A “featured image” that is a good overall view of the project. This image should be one of the “well-shot” images described below, or a cropped subset of one of them.
The project title.
Careful and well-shot images of the final project. Take these using IDeATe’s PhotoZone backdrop and lighting for an especially easy professional look, or shoot out in the field if you prefer. The DSLR photography guide provides a lot of pointers.
Submit at least seven shots and these must include:
1. Overall photo for proportion and scale
2. Detail photo of any part that you’d like to highlight (up to 3)
3. Gif or gifv or little .mov that shows the piece working (i.e. interacting with an input(s) and the output(s) that are derived.)
Simple narrative description of the thing and usual operation of the thing—the type of plain and straightforward description that you might write in a letter to a child to explain what you had made. Free of judgment and totally literal and straightforward. Try to use as little technical language as possible. (E.g. “A white plastic box has a switch on the top side. When he user turns it on, a green LED flashes five times showing that the system is ready. A small white flag waves back and forth.”) For a study in the art of using simple language, see Randall Munroe’s wonderful Up Goer Five. To use a simple-language filter yourself, try the Up-Goer Five text editor.
Five progress images, each of which could be a step or misstep that happened along the development process, and each with at least a sentence or two caption. These images may capture decision points, especially interesting or illustrative mistakes, or other mileposts along the way. The idea is that these medium-quality images (though good pictures work too) are taken along the way to document progress. Sometimes you might understand these as being moments-that-matter only in retrospect! The safe route, therefore, is to snap lots of photos as you go along for later review.
Process Reflection pertaining to process and outcome. For instance, what was easy, what was hard, what did you learn? What little tweak, in retrospect, would’ve changed the direction entirely? This is an opportunity for you to reflect on your creative and technical growth through the project, and think about what growth you want to aim for next. This shouldn’t be a recital of your process, but rather a meaningful consideration of what you experienced during the creation of your piece, 2–4 paragraphs in length.
Code submission, embedded into the project page, and optionally also with a Github or other version control service public-facing link. This may be code which ran on an Arduino or on a computer in Processing, P5.js, Max, etc. In any case, your code should be reasonably commented throughout so that people other than you (the author) can better understand it. You don’t need to explain every single line—that would be overkill—but leave useful notes in a reasonable measure. Write a comment block at the top of the code including:
- the project title,
- (optionally) your name,
- a description (short or long) of what the code does,
- any description of pin mapping that would be useful to somebody else trying to recreate your work,
- appropriate credit to any other person’s/project’s code that you incorporated into your project, and
- (optionally) a license notice (i.e. copyright, CC BY-SA 4.0, the MIT License, release it to the public domain, or just follow your heart). If you have written code that you wish to keep strictly proprietary for any reason, please speak with the instructor about an exception to this documentation requirement.

To embed the code properly: on the WordPress “Edit Post” page, move your cursor to where the code should be inserted in your post. Click the “Code Insert” button in the toolbar above the post (it is marked {...}). For Language, select C. Paste the code—properly indented!!—into the window, and click OK.

How to submit (WordPress instructions)

All documentation is submitted by making a post on the course site.

Make a post with the title in the format “Project no. 2: Your Project’s Name Here.” On the right side of the page where you compose your post, under “Categories” select “Project no. 2.”
Upload your images at a reasonably high resolution; ~1000 pixels of width is the lower boundary of what you should aim for. After adding an image to the post, click on it in the editor, click on the pencil icon to get to its Image Details popup, and select Size: large or Size: original.
You can also use the Image Details menu to add a caption to an image.

Grading scheme

3% Initial ideation
3% Embodying flow
9% In-process critique
60% Final critique
25% Final documentation

62-362 Fall 2019

Legal