2.5. Project 1: One-in One-out

The projects are the core of this course: we want to design, build, and document devices which blend digital and physical processes in expressive or useful ways which answer a human question. It is the activity which blends the technical lessons, collaboration, and process management with an awareness of context. This first project is intended to familiarize you with the collaborative workflow and identify any important gaps in your skills. Our goal is to keep the deliverable objectives modest so the production process is not onerous.

The following material is included in this brief by reference. Please familiarize yourself with the details of the documentation requirements and schedule.

Also, IDeATe has committed to exhibiting at the Pittsburgh Maker Faire on October 10 and 11, so we will be looking for good projects to show and students willing to volunteer to staff the table. Project 2 won’t be done by then, so we will choosing from among Project 1 results.

2.5.1. Objectives

For this project, we are asking you to render a version of your big idea as a single-input single-output system (SISO). A guiding principle of the course is that all ideas can be rendered at all scales. Your grand notions from the ideation exercises can be abstracted into forms where the essential questions can be tested with simple prototypes. The simplest processes we can use involve just a single transformed signal.

We are also asking that the input and output inhabit different sensory domains, e.g. a sound input creates a light output, or a light input creates a mechanical movement, etc. This reflects our emphasis on embodiment and transformation. We will interpret this objective liberally; if you are concerned an idea doesn’t fit, just ask us.

We highly recommend sticking with basic electronics at this stage. If you must use an Arduino, you will be expected to justify why it is necessary. Previously we have required this and students have produced many effective projects without computation.

These are intended to be research and exploration projects: the whole point is to learn something new, and no one is paying you for the result. Reasonable ambition is encouraged, so we’d like you to try new things, and failure is part of the process. However, we will attempt to guide you away from directions which we think are unlikely to succeed or require unreasonable levels of effort. But you are the ultimate arbiter of this: we won’t outright say no because we want you to learn to assess your own ambitions and skills and don’t want to stand in your way.

2.5.2. Milestones

  1. Pair selection. We prefer that students work in pairs. At this point in the semester, it is ideal to find a partner with complementary skills so you can teach each other. Solo workers and groups of three will need to make a pitch for an exception. Groups of four are too large for this project.
  2. Proposal. See Proposal Prompt for specifics. Ideas are cheap; it is in the exploration that the interesting work begins. We recommend a strategy of committing to a general idea early and then thinking through as many details as possible at the drawing and planning stage. We find this is much more efficient that jumping into building too soon.
  3. Proof-of-concept. Nearly every proposal plan leads to a set of key questions which form the primary hurdles. We recommend a strategy of choosing a quick experiment to tackle the most difficult part first. Either the unknowns will resolve into a feasible development plan or you can fail fast on one approach and revert to another. Either way, you won’t have wasted effort on secondary development which becomes obviated by a problem. The proof of concept will usually be a partial prototype, and in many cases it can be modified into a full prototype if successful.
  4. Presentation and in-class critique. See In-Class Project Reviews. An important learning goal of the course is clear and efficient communication between disciplines, and the critiques provide an opportunity to hone your skills. Ideally, your project will be functional and you can perhaps give a live demonstration and succinct explanation. If your project has failed, then please explain why and how it failed and whether there is a general lesson to be learned. Our critiques will consider the relative difficulty of the attempt. Ambitious project ideas frequently do not work out as expected but can still be reframed to expose an alternative interpretation as well as explain the hidden traps of the original idea.
  5. Report. See Project Reports. For all of our projects, the documentation is the most tangible and durable work product. It is also an important stage for reviewing and reflecting on the process and outcome. The same considerations about success and failure outlined above also apply to the written documentation. The report due date comes two days after critique to allow incorporating verbal feedback.
  6. Peer evaluation. Each individual should write a brief Project 1 Peer Evaluation Form response about your partner or teammates to be submitted confidentially. This serves two functions: it is the primary opportunity for you to reflect on the collaborative process itself, and it helps your instructors identify potential collaboration issues.
  7. Disassembly. Unfortunately, we do not have enough parts and resources to keep all projects intact even for the duration of the semester. Unless your project is designated to show at the Maker Faire, please disassemble all components and return them to the storage bins. This may seem obvious, but please be sure to complete all documentation prior to this point: students frequently end up taking something apart and then wishing they had one more photo or video.

2.5.3. Proposal Prompt

The proposal is the counterpart to the final report: ideally, it raises all the questions which the project might answer, even though more will be discovered during the process.

The primary review of the proposal will be verbal in-class commentary in order to provide the fastest possible approval. To speed this along, please provide in-class a one-page document which concisely summarizes the project plan. Please also submit a PDF version of the document to Blackboard before the end of the day on which the proposal review occurs. Only one document need be submitted per group, but be sure to include the names of all contributors.

A good proposal will answer as many of the following questions as pertinent. These are prompts, not a checklist, so use your judgment as to how to formulate a brief proposal text or outline with supporting sketches.

  1. What is your big idea, in a sentence or two? What human need does it address?
  2. If you apply why-how laddering, can you identify an essential underlying question? What is the simplest abstraction of your idea?
  3. Who is the audience? This might include user, viewers, or passive bystanders. What is the experience of the audience? What might they remember?
  4. Are there existing projects you have referenced? Please include citations.
  5. What are the concrete objectives of a one-in one-out formulation of your idea? What’s the hardest part?
  6. What will your proof-of-concept entail? Can you sketch it? Can you sketch the engineering elements (circuits, mechanical drawings)? Good drawings at this stage are invaluable, they can identify many potential problems much more efficiently than fabrication.
  7. How do you propose to divide the tasks among the team? What roles will you each undertake and for which parts?
  8. What features do you specifically propose to ignore? E.g., a project involving a wearable device could focus on sensing and actuation but choose to ignore battery operation in favor of a wired supply. In general, we’d prefer you keep your workload under control by emphasizing interesting behavior or interactivity over fit and finish.
  9. What features do you specifically propose to test? How will we know if it worked?
  10. How might the final project look? Can you sketch it?

2.5.4. Summary of Deliverables

  1. In-class proposal review and supporting PDF file.
  2. In-class demonstration of proof-of-concept.
  3. In-class presentation of result for critique.
  4. Report zip file package as per Project Reports, including link to brief project video (less than one minute).
  5. PDF or plain text file for peer evaluation.