Flow and Analogy

Building analogies, or Operationalizing metaphors

In our everyday lives, we interact with myriad digital computers; they’ve grown so small that they can fit onto our wrists, in our pockets, and on head-mounted displays. Our vehicles, food, entertainment, and entire economies are affected and mediated by digital computers. All modern digital computers have at their root a system that records information and instructions using a binary system of ones and zeros, ons and offs, trues and falses. A transformation must be enacted to use a digital computer to study the world: namely, the world has to be turned into a digital representation, or the computer has no way of considering it as data.

But there is another way of computing, which relies on a totally different paradigm: rather than turning a piece of information into an electronic digital representation (i.e. rather than storing the number 52 as 00110100), that same information can be turned into a physical representation of some sort (i.e. storing the number 52 by raising a weight up 52 centimeters). As a digital computer can store a non-integer number (like 52.34), so an analog computer can do this by raising a weight up to 52.34 centimeters.

Building analogies of systems in the world allows us to study and learn about those systems. Putting a model plane into a wind tunnel allows for careful study of how the wind will flow around the wings of the real plane; building a scale model of the water flowing around the San Francisco Bay allows for simulation of different tide and wind conditions to see what areas are prone to flooding. Systems of these sorts are direct analogs: the world is made bigger or smaller, and the synthetic world is studied carefully to shed light on the real world.

Using the weight-raising analog as an example, though, many other computations can be achieved by non-digital means. For instance, to build a computer to total a customer’s bill, let’s say $52.34 + $17.96, start by raising a weight 52.34 cm, and then raise it another 17.96 cm. Observe how high it is, and convert that back into dollars. To compute a difference so you know how much change you owe, raise the weight one distance and then lower it by a different amount. This is a very simple example, but it points to the relationship that can be built between the world and analog calculators meant to study or understand it.

In fact, much more than addition and subtraction can be computed by analog means. Multiplication, division, exponents and logarithms, trigonometric functions, and differential equations can all be modeled using gears and wheels, strings, springs, electronic circuits, and systems of flowing water. If a problem can be described mathematically, it’s likely possible to build an analog computer that can produce solutions to that problem.

Analog computers in all forms are operationalized metaphors—explorations of different ways of understanding, building sense out of, and seeking answers about the complicated world. This assignment is an opportunity to create your own analog computer.

Relevant slide deck sharing inspiration from the art world.

Assignment

Drawing from the ideas described above, build an interactive device or experience which operationalizes metaphor to show, study, trouble, or explore something in the world. All analog computers have some sort of input and produce some sort of output, and yours must, as well. Information should flow through your machine from input to output.

The piece may take an explicitly social/political/ideological stance, or may be closer to a science museum interactive piece. It may focus on the metaphor at its heart, or might simply use that metaphor in the service of its calculation. 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 an analog computer. It may be electronic, mechanical, hydraulic, or operate using any internals you like.

• It must in some way gather information and then produce some result, which is to say it must have an input and an output.

• The computer should operate on a range of values; this is in distinction to the fundamentally binary Gates project. For instance, if your computer uses a slider as an input, if it can slide to 3 and 5 it should also be able to slide to 3.2 and 4.7; or if it can go high and low, it should also have a continuous middle.

• Use this project as an opportunity for you to make skills gain(s) you’re working towards this semester, based on our earlier conversations.

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

• Initial Ideation (15 points)

• Lo-fi Maquette Presentation (10 points)

• Group Check-in (5 points)

• Final Critique (60 points)

• Final Documentation (15 points)

Important Dates

Monday, Oct. 30 – Initial Ideation Due

In order to help your ideation process, please read or listen to one of these two systems thinkers before class on Monday:

• • Robin Wall Kimmerer's interview on On Being (you can read the transcript or listen to the interview)

  • adrienne maree brown's interview on On Being (likewise you can read the transcript or listen to the interview)

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 an image 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. What is this thing and how does it work?

   2. Intended interaction mode by members of the public and/or performers and/or yourself (whatever is appropriate to the piece)

   3. Intended siting (where will it live and how will it be installed?)

   4. Intended experience for the audience

   5. Theoretical underpinnings (e.g. what led you to this idea, what about it intrigues you, etc.)

   6. 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, submit a PDF to the Canvas assignment.

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

Wednesday, Nov. 1 – Low-fidelity Maquette Presentation

Requirements:

• Bring to class a low-fidelity physical maquette that represents the physical embodiment/fabrication of your envisioned final project. Build your maquette with craft materials (like cardboard, paper, popsicle sticks, etc.) and don't concern yourself too much with getting all the details right. We just want you to consider size, shape, form, etc. at this stage.

• Identify the skills gains domains you will work on through this project (to share with the class)

• Submit a materials list to the Canvas assignment including:

  • Things you have already

  • Things we have available on campus

  • Things that need to be ordered

In class, we will discuss the maquettes, and use them to mock up and explore the interactions that your audience will have with the final work. Bring your maquette to share in class! 

This exercise is meant to help you prepare to deliver a polished finished project two and a half weeks later.

Wednesday, November 8 – Group Check-in

You will present an updated project that you have developed further from the maquette you shared on Wednesday, November 1. You will share for 5 minutes with your classmates for group feedback.

Make yourself a page (ex. "FIRSTNAME") on the course website under the subgroup "Group Check-in" and share the following information:

• Current Project Title (this can change)

• Three process images with descriptive captions.

• What you have done so far?

• What is giving trouble?

• What is your plan going forward?

Monday, November 20 – Final critique

You will present your projects with time given for critique. Please see the full project rubric on Canvas; here is a summary:

• Project Contextualization (10 points)

  • • Project Title

    • Project statement / artist statement

    • Explanation about how the piece is an "operationalized metaphor"

    • You share contextualizing decisions

• Technical Highlight (10 points)

  • • You select a technical aspect of your project to share

  • Audience Engagement (10 points)

    • You listen to and meaningfully address questions and comments.

    • You engage in critical conversation about your project with your audience.

    • Your audience can physically interact with your project.

  • Project Function (20 points)

    • The project "works"

  • Project Finish (10 points)

    • The project has physical integrity

    • The project is safe to use

Monday, November 27 at 10:00pm – Documentation is due

If you have any questions about the submissions requirements, or run into technical problems, be sure to contact either Petra 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:

  • Overall photo for proportion and scale. See below for instructions on uploading and presenting images.

  • Detail photo of any part that you’d like to highlight (up to 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.