You will construct a machine that allows people (or a person) to directly manipulate input(s), or indirectly affect some input(s). Based on the inputs that are selected at any moment, the machine will produce some outcome(s) that may be audible, visible, tactile, or in some way observable. You have freedom in defining your inputs and output(s), but they should be mediated by logic gates; these may be constructed mechanically, electrically, electronically, or otherwise. It’s possible for a person, or more than one person, to participate inside the logic of the machine, but they should follow a defined logical rule.
Your machine might be fanciful, silly, useful, artful, conceptual, socially conscious or ridiculous. It could provide predictions about the future, commentary on the past, unsolicited advice, pretend to reproduce the decision-making of a person, or illustrate the behavior of a mutinous machine. It can add up numbers incorrectly, help someone decide what not to eat for dinner, whom to love, whom to hate, when to turn off the lights so somebody goes to sleep at the right time, or provide commentary on an event based on the current position of all the participants. It could predict stock prices based on how sunny it is and how many leaves have fallen from a nearby tree. It can require four people working in concert to operate properly. It can help a child decide how many jumping jacks they should do or provide mordant social commentary or elicit a smirk, or both. In short:
(interactive AND logic-driven) AND (useful OR meaningful OR piquant OR probing OR otherwise rich) —> successful
Prepare three distinct project ideas. Each one should have:
A narrative description (~200 words) addressing:
Intended interaction mode by members of the public and/or performers and/or yourself (whatever is appropriate to the piece)
Intended siting
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
Relevant word equation, logic diagram, and truth table (can be hand drawn and scanned)
At least three drawings showing the proposed build (drawings need not be high-fidelity; sketches are certainly fine). These could consist of three different angles of the final object; three different ways a person might engage with it; three different stages it will be in; or any three drawings you think help tell the story.
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 have an opportunity to provide group feedback to each other. We will also provide you with written feedback.
Due at the beginning of class:
Pick your favorite project idea from your initial three and expand upon it. This is an elaboration from what you shared on Wednesday, September 6. Your ideas should be fleshed out further including added details, drawings, and an updated relevant word equation, logic diagram, and truth table.
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.
You will have 5 minutes to share your refined idea and receive group feedback.
This first assignment should focus on the use of integrated logic chips and physical gate. It can incorporate software, but that should not be the main driving force behind you mechanism.
Due at the beginning of class:
Build a small scale maquette of your concept – consider its design and points of interaction.
Write the correct word equation, logic diagram, and truth table for your concept.
You will share your physical maquette along with your word equation, logic diagram, and truth table.
Images and descriptive documentation including your word equation, logic diagram, and truth table should be submitted to your process blog. This submission will become the beginning of your project documentation for Gates.
This need not be a perfectly scaled model, but instead a helpful and generative tool to aid in your progress.
We expect you to use craft materials (clay, wood, toothpicks, tape, paper, cardboard, found objects, etc.).
Label points of interaction (for instance, make a mark where a user would press a button, or draw a light where that light would be). Even better is if you can actually integrate little buttons/etc. into your device so that the action itself can be modeled by a user.
No need to spend $$ or many hours crafting all of the finest details of this maquette.
Be thoughtful, fast, simple, and illustrative. This is an opportunity to explore your idea.
Show us where it will live (is it attached to a wall, worn on the body, or placed on the ground, etc.).
If you need help writing the correct word equation, logic diagram, and truth table, be sure to ask!
You will present your projects for 18 minutes. Your presentations should address the following:
Title
Individual physically-built projects
Challenges along the way, interesting findings, and/or lessons you’d like to share.
What to submit for your final finished project documentation (requirements):
You will post your final documentation to the course Google Sites website. If you have any questions about the submissions requirements, or run into technical problems, be sure to contact either Petra or Zach.
Your submission must include:
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.
Submit at least eight still images and these must include:
Overall photos for proportion and scale (at least five different angles)
Detail photo of any part that you’d like to highlight (up to 3)
A short video that shows the piece working (i.e. interacting with an input(s) and the output(s) that are derived.) You may add multiple videos if you like.
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 a 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.
If applicable: 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.
Why document your work?
"Next to the original physical work itself, good documentation is the best long-term investment you can make in your art practice. It will be the backbone of your art archive, and the primary factor in how your entire practice is viewed long-term. Remember that just because you may have strong work doesn’t mean that it will be perceived that way through your documentation. Bad documentation = bad work.
How you document your work determines everything from how it is reproduced in print publications to how it is seen online. Visual documentation will often be the only thing curators, writers, or grant panels will see of your work, and good documentation can mean the difference between getting a grant or securing an exhibition, or being rejected and passed over for opportunities.
Many times, documentation is all that is left over from non-permanent work, like temporary site-specific sculpture, happenings, social practice projects, performances, etc. In cases like these, the documentation will be the only thing that survives, and can actually become the work itself. This is why it is very important to plan how you will document your work ahead of time."
– Getting Your Sh*t Together : Making Artists Lives Better
Three Ideas (30 points)
One Idea (15 points)
Maquette Presentation (30 points)
Audience Engagement (15 points)
Maquette (15 points)
Final Presentation (55 points)
Presentation (25 points)
Contextualizing Project (10 points)
Technical Summary (10 points)
Audience Engagement (5 points)
Project Function (15 points)
Project Finish (10 points)
Project Risk-Taking (5 points)
Final Documentation (30 points)