Flow and Analogy
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.
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.
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.
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.
Points Assignment Section
20 0.0: Intro homeworks
30 1.0: Three ideas
15 1.5: One idea
15 2.0: Maquette
10 2.5: Progress check
20 2.8: 80% critique
60 3.0: Final critique
30 4.0: Documentation
200 Total points available
Prepare two distinct project ideas to turn in and discuss.
Each of your two project ideas should include:
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:
All of your system’s inputs towards the left, connected by arrows to:
Any/all of your system’s computational steps in the middle, connected by arrows to:
All of your system’s outputs on the right.
A page-length (~300 word) narrative description addressing:
What is this thing and how does it work?
Intended interaction mode by members of the public and/or performers and/or yourself (whatever is appropriate to the piece)
Intended siting (where will it live and how will it be installed?)
Intended experience for the audience
Theoretical underpinnings (e.g. what led you to this idea, what about it intrigues you, etc.)
Relevance to you and your practice
Three 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.
Basic action plan. What processes and tasks will you need to build your device? Where & how will you do them? Example: "I will create a rendering on Solidworks and use it to 3D print components at IDeATe."
Basic list of materials as well as sources (on or off campus) for those materials (this need not be a finalized purchase list!). Example: "I will source my metal sink from Construction Junction."
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.
Pick your favorite project idea from your initial three and expand upon it. This is an elaboration from what you shared on Thursday, October 24. Your ideas should be fleshed out further including: updated drawings, details, a block diagram, action plan, materials list and sources.
Make a new post to the course site to present your idea. This post can have information/text/etc. copied from your original submission but should be unique from that. It will serve as the beginning (bottom) of your project documentation blog. Submit the URL of this post to Canvas via this assignment.
We will review your proposals outside of class and provide you with written feedback.
Due at the Beginning of class:
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 exactly right. Consider the size, shape, form, location, context, and points of interaction.
Submit an up-to-date action plan and materials list to the Canvas assignment including:
Things you have already
Things we have available on campus
Things that need to be ordered
You will present an updated project that you have developed further from the maquette you shared on Thursday, November 7.
Make yourself a page (ex. "FIRSTNAME") on the course website under the subgroup "Progress Check" and share the following information:
Current Project Title (this can change)
Three images of your maquette.
Three process images with descriptive captions.
What you have done so far?
What do you feel good about?
What do you need help with?
What is your plan to get to the 80% Complete Critique?
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
In the spirit of Tom Cargill's wise words, we have this "80% complete" due date for you to show your progress at a checkpoint that's one and a half weeks out from the final due date.
Our expectation is that you show that you are at least 80% done at this point. In nearly all cases, it's only once you're fairly far along in project development that you actually discover the hidden, difficult problems that lay in between you and the end goal you're aiming for—or that you find that there's a different end goal you want to aim for. The revelation of these things is only possible by doing the work of actually building out your project, and getting it to a satisfactorily far-along place that you can take stock of where you're at.
We will ask you to share answers to these three questions:
What do you feel good about?
What do you need help with?
What's your plan from here to the Final Critique?
You will have a 20-minute window during which we'll focus on your project. The first 3–5 minutes of your slot are time for you to briefly present your piece to the audience. The remainder of your 20-minute slot will be time for critiquers, including invited guests as well as your classmates, to provide verbal feedback.
Your presentations should address the following:
Project Contextualization & Artist Introduction (10 points)
Project Title
Project statement / artist statement in which you explain how the piece is an "operationalized metaphor."
You share challenges, interesting findings, and/or lessons from your process.
You share 1-2 technical choices and explain them.
Audience Engagement (5 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 (25 points)
The project "works" as intended without significant interventions.
The audience can interact with the project's interactive elements.
The project's inputs consistently produce outputs.
Project Finish (20 points)
The project has advanced beyond the maquette stage.
The project has physical integrity and maintains its form.
The project is safe to use.
Total Points: 60
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.