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. It may be overly complex to make a point. It might be funny, deadly serious, confusing, or plain and straightforward. Consider how material/fabrication/aesthetic choices drive meaning or affect your audience’s reading and experience of it.

Requirements:

  • You will build a device to transduce a signal or signals.
  • 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 “read” in, and correspondingly “write” out, a range of values. This is in distinction to the fundamentally binary Gates project. As an example we can imagine a device that uses a microphone to listen to the level of ambient sound, and varies the brightness of an output light. If the ambient sound is very quiet then the output light might be dim; if the ambient sound were medium the light would be medium brightness; and if the ambient sound were loud the light would be bright. Note that louder input does not need to lead to brighter output—these could be reversed (louder input leads to dimmer output), or there could be a more complicated relationship (medium-loud input leads to bright output, but quiet or loud inputs lead to dim output). The size of “steps” between different inputs and outputs can vary as needed, but there should be a minimum of 10 different levels across the input and output ranges.

We are able to allocate course budget for purchasing materials for your project needs; please email us with those requests as soon as you have certainty about what material(s) you’ll need so that we can place orders with plenty of lead time.

Grading scheme

  • 10pt: Initial Ideation
  • 5pt: Group Check-in
  • 10pt: Proof of Concept Tech Demo & Lo-fi Maquette Presentation
  • 60pt: 100% Complete (Final Critique)
  • 15pt: Final Documentation

Important Dates

Wednesday, October 26 – Initial Ideation Due

Prepare three distinct project ideas to turn in and discuss.

Each of your three project ideas should include:

  1. A block diagram showing the flow of data through your system. This is an accounting of all inputs, computational steps, and outputs. Use our draw.io library’s “Block” elements to create these diagrams, and then export the diagrams as PNGs or SVGs to add them to your ideation. Each block diagram should include:
    1. All of your system’s inputs towards the left, connected by arrows to:
    2. Any/all of your system’s computational steps in the middle, connected by arrows to:
    3. All of your system’s outputs on the right.
  2. A page-length (~300 word) narrative description addressing:
    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
  3.  A representative drawing of your proposed build (drawings need not be high-fidelity; sketches are certainly fine). Consider illustrating how your piece will live in context and not just what the objects will look like. This will help us understand scale and spatial concerns.
  4. Basic list of needed materials as well as sources (on or off campus) for those materials (this need not be a finalized purchase list!)

To share these ideas with us, make a new post on the course site (this site); use the category “Ideation,” which is a sub-category of “Project No. 2.” At the bottom of your post, under “Content Permissions,” select “Instructor” as the role who is able to view this post (this way, the initial post will be visible to Erin and Zach but nobody else).

We will review your proposals with you individually in class. We will also provide you with written feedback.

 

Wednesday, November 2 – Low-fi Maquette Presentation

You will present a lo-fi maquette of your project to the class. 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:

  • 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)

This piece must shows clear progress towards your final goal. Use this time to focus on the interactive and aesthetic aspects of the project.

Requirements:

  • A low-fi maquette with sketches that represent the physical embodiment/fabrication of the envisioned final project. For example, if your project is going to made out of rubber, you don’t need to make a maquette out of rubber. Create a maquette with craft materials and include more detailed sketches and images of your design.
  • A first pass at the electronics. Figure out your electronics needs and try to start!
  • Three materials lists:
    • Things you have already
    • Things we have available on campus
    • Things that need to be ordered

In class, we will discuss the prototypes. This deadline is meant to help you prepare to deliver a polished finished project two weeks later.

Bring your maquette to share in class. Submit your materials list in Canvas via this assignment.

Wednesday, November 9 – Group Check-in

 

Monday, November 21 – Final critique

You will present your projects for ~5 minutes with an additional ~25 minutes for critique. Your presentations should address the following:

Tuesday, November 29 at 5:00pm – Documentation is due

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 Erin 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. See below for instructions on uploading and presenting images.
    2. Detail photo of any part that you’d like to highlight (up to 3)
    3. .mp4 (preferred) or .gif (acceptable) that shows the piece working (i.e. interacting with an input(s) and the output(s) that are derived). See below for instructions on uploading and including these movie files.
  • 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 “Final documentation,” which is a subcategory under “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.
  • Adding movie files
    • Convert your files to .mp4 (preferred) or .gif (often lower-quality and a larger file size) prior to uploading. You should be able to convert whatever movie format you have to .mp4 using a command-line program like ffmpeg, another piece of free downloadable software, or a web service.
    • To add an .mp4 video to your post, upload the file to the Media Library, and under the “Attachment Display Settings” dropdown, select “Embed Media Player” before clicking “Insert into post.” This will ensure that the video itself, rather than a link to the file, appears in your documentation.
    • To add a .gif, simply upload and insert it as you would any other static image file.