Week 13: Final Project Update

This week I spent time fabricating the project enclosures and finalizing the interface.  I purchased a open top bamboo box from the container store to use for the board enclosure.  I printed the board panel on a piece of plywood and connected it to the top of the box using velcro.  I placed the electronics inside securing the RFID modules with tape to the underside of the board panel.  I completed the coin fabrication by gluing two rings to each coin top.  I used command hook strips to adhere the RFID fob to the inside of the coin and then to connect the bottom piece of the coin to the key fob.  Figure 1 shows this iteration of the board and coin enclosures.

Once this was complete, I conducted a final user testing session with my classmates.  Figure 2 shows an example from the user test.

Figure 2

Overall, the user testing went well however I identified a few minor adjustments that needed to be made.  Using velcro for the panel mount was not substantial enough for the use.  Also since the RFID modules have a small range they needed to be carefully place in the center of the detection circle in order for them to properly work.  Also, It was suggested that I include an artists statement in order to make the motivation for my project clear.  Lastly, it was clear that a space between the words on the submit panel was needed in the code.  For the most part, users liked the feel of the wood coins. Using the advice and observations I made during user testing, I made final modifications to the project.  Figure 3 shows the process I went through to improve the board enclosure.

Lastly, I developed an artists statement to have on display next to the project (Figure 4) and I updated the code to include a space between the words (Figure 5). 

Figure 4

Figure 4

Figure 5

Figure 5

Week 12: Final Project Update

This week I completed planning the circuit/code and began the fabrication process. 

To complete the circuit I needed to add the clear/restart and submit buttons.  I then needed to adjust the Arduino and p5 interface codes to accept these inputs.  I ended up creating a four element key code for myself to send serially.  Each element within each byte describes the RFID reader, RFID card, clear/restart button state, and the submit button state, respectively.  For example a serial reading of “0L00” would mean the letter “L” RFID card was scanned on reader 0 and none of the buttons were pressed.  The Arduino and p5 codes can be found at these links.  Figure 1 shows the breadboard circuit with the buttons attached.

Figure 1

Figure 1

Once this was complete, I moved on to fabrication.  I began by planning the coin design.  Figure 2 shows a test of the coin design. These coins were laser cut out of 1/8” plywood. Each coin consists of 4 wood pieces and is designed to conceal the RFID tag without gluing them inside the coins permanently.  The top piece is a 2 inch diameter circle with the alphabet symbol engraved on one side.  The next two layers are rings with an outer diameter of 2 inches and an inner diameter of 1.75 inches.  These layers create a housing for the RFID tag to sit inside.  Next another solid round layer closes the RFID tag inside the cavity.  I plan to use wood glue to attach the top to the two middle rings.  However, in order to access the RFID if something breaks, I plan to use strong adhesive or velcro to attach the tag to the wood and the wood bottom to the rest of the coin.

Figure 2

Figure 2

Once I came up with this design I checked that the thickness of the wood did not impair the RFID scanning (Figure 3).

Figure 3

Next I laser cut the entire visual alphabet (Figure 4).

Finally, I soldered the circuit onto a perfboard (Figure 5) and prepared the final design for the display panel (Figure 6).

Figure 5

Figure 5

Figure 6

Figure 6

This display directly took into account elements that were conveyed by individuals who completed my playtest.  The headphones and monitor symbols were suggested to me during the playtest.  In the coming week I need to complete the enclosure and coin fabrication and conduct user testing.  Once the user testing is complete I will make any minor changes necessary to get a final product. 

Week 11: Final Project Update

Over the past few weeks I have conducted a playtest with my project and solidified the majority of the technical sides of the project.  The following is an update on the steps I have taken on this project since my last blog post.  

Figure 1 shows an updated project plan and bill of materials as of today (Monday, November 26).

Figure 2 shows some pictures from the playtest.

Overall, the results of the playtest were positive.  From the responses and observations I determined that the version of the board with two RFID scanners was more intuitive to use than the alternative.  I received good feedback on the sound quality and the visuals.  One suggestion a playtest volunteer had was to prompt the user to spell a specific word instead of prompt them to write any word.  This way the program could tell the user if they spelled the word correctly or not.  While I like this suggestion, I ultimately decided to stick with the format I currently have.  I noticed that it was very difficult for users to decode the visual language.  Thus, I do not want to complicate the instructions by prompting them to write a specific word.  In the end, if I change my mind, this feature will be relatively easy to implement later on.  Thus I will revisit this feature later on.  I found the playtest to be successful but also somewhat limiting.  The way I designed the playtest, there were some key features that were missing from the playtest that would be solved by the final design.  Thus I found that my responses to comments during the playtest was a description of how the final product will differ and solve the stated issue.  Thus, in the future I think I could do a better job of designing the playtest that more closely resembled the actions one would take while using the final product.  None the less, I felt confident in my design since most of the comments and suggestions that were made were being addressed all ready in the final product. 

Using the feedback from the playtest I continued to built the program and set up the RFID scanners.  Using this resource and this library I manipulated this example code for my own two  RFID modules.   First I set up one RFID reader (Figure 3) using this modified code.  

Figure 3

Figure 3

Using this p5.js sketch I was able to send the reader value and the unique chip ID from the Arduino to a p5 sketch.  From here I began to work on the user interface using p5.js.  First I developed a program that would take user input from the keyboard to write a word and display it in my visual language.  Then when you press the down key (aka the submit button) the word you wrote would be displayed along with previous user inputs (Figure 4).

Figure 4

Once I completed this interface I decided to change the submit display to only show the visual language.  Figure 5 shows a video of the second version of this interface.

Figure 5

Once this interface was complete I connected two RFID scanners (Figure 6) and combined the serial communication code with the interface code.

Figure 6

Figure 6

I also added the sound library to the interface code so that when a letter was scanned on the “learn” reader, the letter sound would play.  Here are the Arduino and the p5.js codes for this stage.  Since I currently have only 23 tags, I only have the letters A-V set up.  Figure 7 shows a video of these components working together. 

Figure 7

At this stage, I have most of the electronics working successfully.  Next, I will add the clear and submit buttons to the computation and physical sides of the project.  After that I will begin fabricating the coins and enclosure for the project.  At this stage I feel I am making good progress.  I have given myself enough time to complete the fabrication side while still having time to make adjustments as they are necessary.

Week 10: Final Project Playtest & Update

This week I spent time solidifying a project plan and developing a paper playtest to user test the initial idea with my classmates. 

Figure 1 shows a general project plan for the coming weeks.

Figure 1 : General Schedule

Figure 1: General Schedule

Figure 2 shows a detailed step by step project plan for the coming weeks along with a general materials list.  The completed column is updated for week 10 and represents what I have completed thus far. 

To begin, I experimented with various visuals to represent each letter of the alphabet.  Using p5.js and some tutorials (tutorial 1, tutorial 2) I recorded my voice saying different letters of the alphabet.  I created various sketches to visualize the recordings before deciding on which one to use.  Figure 3 highlights one of the graphing methods I developed to visualize each letter of the alphabet.

In the end I decided to use the method represented in Figure 4 because it created images that were unique enough from each other while following the same general format.  As you can see in Figure 4A, I included a button in the program to save the canvas at any given time.  As a recorded each letter, and I would click this button to download the recorded letter visualization.

Figure 5 shows a video that of the program running and how each letter was recorded.  The p5.js sketch to create these circular visualizations can be found here.

Figure 5: Making the Visual Alphabet

Once I decided on this method I recorded and saved a visual alphabet library to use for the remainder of the project (Figure 6). 

Figure 6 : Complete Visual Alphabet

Figure 6: Complete Visual Alphabet

After completing the visual alphabet, I turned my focus to a paper prototype that I can use to playtest. First, I brainstormed different options for the board setup (Figure 7).  Some options involved two RFID scanners while others involved only one. 

Figure 7 : Board Brainstorm

Figure 7: Board Brainstorm

In the end I decided to playtest my two favorite board setups to get feedback on the importance of one or two RFID scanners (Figure 8).

Figure 8 : Playtest Plan

Figure 8: Playtest Plan

From here I came up with a plan for the playtest and began designing it.  The two playlets setups are shown in Figure 9.  The playtest will involve three example letters from the visual alphabet I created.  The user will be instructed to learn these three letters and write the word CAB with the coins.  When the users interact with this board, I will advance this p5 sketch based on their actions.  If the user places a coin on the learn section, I will tell the computer to play the letter recording.  If the user places a coin on the write section, I will tell the computer to display the letter on the screen.  I will change up the board for every other user so that I get feedback on the two options for the board setup. After completing the playtest, I will ask the volunteers to complete this form.

Once I was done preparing the paper prototype I took some time to get a little further on the actual prototype.  I found a recording of the alphabet and saved each individual letter separately into a sound library.  I will use this library in my future code for the ‘learn’ side of the board.  Lastly, I spent time testing the RFID reader to make sure I knew how to use it and that it was the correct module to use for this application.  Using this page for hookup and code instructions I connected the RFID.  Then I used this code example and this library as a guideline to read the RFID UID code.  Once this was hooked up, I connected a simple p5.js script to test the serial communication between the Arduino RFID side and the sketch side.  The results are shown in Figure 10. When I touch one RFID card to the scanner the letter A is displayed on the canvas, when I touch the other the letter B is displayed on the canvas.

Figure 10: RFID Communication Test

These are the steps I completed this week.  Next I plan to catalog the results I receive from the playtest and adjust my plan as necessary.  Then I will begin to fabricate the coins and further design the computer interface. 

Week 9: Final Project Plan

About the idea:

As a dyslexic, I have become increasingly frustrated with the general public’s understanding of dyslexia.  People often think that being dyslexic means that you read letters or words backwards and upside down or you have a low IQ because you are dyslexic.  I want to develop an experience that puts the user into a dyslexic’s shoes.  Of course, dyslexia is a complex learning disability that affects no two people the same way.  However, I hope to make an experience that highlights both the gifts and struggles people with dyslexia typically face.  

Dyslexia effects parts of your brain that process language and thus most dyslexics have difficultly decoding sounds and relating them to letters.  This can slow down their reading rate and make spelling a challenge.  In order for others to experience this language processing barrier, I would like to build my own visual alphabet for any user to learn and then to spell words.  The barrier between the user and this new alphabet will hopefully mimic the barrier dyslexics face while learning the real alphabet.  I want to use elements which tell a story about dyslexia beyond creating this message through the mimicked barrier.  One way I would like to do this is through the development of my alphabet.  I would like the new alphabet to be made out of sound graphs.  Each letter will be represented by a different sound wave graph.  I want this visual alphabet to have patterns that people can recognize while they learn it.  Generally, dyslexic’s have good visual processing skills and thus excel at pattern recognition.  Thus, dyslexics may have an easier time learning the alphabet that others.  The alphabet itself, is a representation of the exact challenge that dyslexics face.  Sound processing is the origin of all the other effects of dyslexia, and thus this project will use a visual representation of those sounds.

How it will work:

Here is how I imagine this project will work.  First there will be an alphabet like the one represented in Figure 1.  The letter “A” will be represented by one unique sound graph, while the letter “B” will be represented by another sound graph, etc.

Figure 1 : Alphabet

Figure 1: Alphabet

Each of these “letters” will be printed onto a physical disk, called letter coins (Figure 2).

Figure 2 : Letter Coins

Figure 2: Letter Coins

The final interaction will look something like Figure 3.  There will be two boards.  One which helps you learn the letters through sounds and the other which helps you write words using the letters.

Figure 3 : General Setup

Figure 3: General Setup

I imagine the letter coins being scattered on a table randomly.  The user will put on the headphones associated with the learning board.  When the user places a letter coin in the designated spot on the learning board, the name and sound of the letter will play through the headphones.  This is how the user would learn the alphabet.  Once the user is ready to make a word, they can place the letter coins on the writing board.  When they are ready to input it into the system, they will press a “ready” button and the word that they made will be displayed on the screen in both the new and real alphabet.  This interaction may look like Figure 4 in the end.  Perhaps, each word entry will enter into a library of words and all the previous word entries will be represented in a graphic similar to this one.

Figure 4 : General Interaction Result Example

Figure 4: General Interaction Result Example

Questions I still have:

Before I begin building this project, I need to identify solutions to two main problems.  First of all, I need to understand different ways to visualize sound with a graph and find a method which develops unique graphs for each letter.  I would like to look at amplitude, tone, pitch, and other sound elements and determine which graph will be the best to use for this application.  Another technical problem which I need to solve is how the project will identify each coin that is placed on the boards as a letter and send that information to the computer and/or the headphones.  I am thinking of using a sensor to identify a unique color on each letter coin.  When a coin is placed on a circle, the sensor detects its unique color and tells the computer or headphones to display or play the corresponding letter.  Perhaps with some research, I will think of other ways to send this information using the coins. 

Project Process Goals:

  1. Identify and test coin connection solution

  2. Identify alphabet mapping method

  3. create visual alphabet

  4. fabricate letter coins (laser cut and etch on alphabet)

  5. Test coins with sensor and serial communication

  6. fabricate learn and write panels (laser cut and etch labels)

  7. connect physical and computational pieces

  8. create visual representation of the catalog of words created by users

Likely Materials:

  • Arduino

  • computer for serial communication

  • monitor for display

  • headphones

  • wood for letter coins and top panels

  • two wood boxes

  • two panel mount buttons

  • sensor (maybe color sensor?)

Week 9: Transistor/Motor Lab

This week I completed the Transistor and Relay lab.  The results of this lab are shown in the video below.

Figure 1

Figure 1

Figure 2

Week 8: Final Project Brainstorm Concepts

For my final project, I have come up with a few general concepts.  While I am not yet set on one particular idea, here are the outlines of two of my favorite ideas from my brainstorm session.

I am dyslexic, and feel that many people misunderstand what it means to be dyslexic.  I would love to do some sort of interactive piece where the user is able to step into a dyslexic’s shoes.  Perhaps, the user will have to read a sentence while the project creates a series of obstacles that mimic obstacles that dyslexics actually encounter.  Perhaps the entire experience actually begins with the user physically stepping on outlines of shoes that are labeled dyslexic.  Of course I would need to research misconceptions about dyslexia and about different obstacles people with dyslexia face in order to develop the obstacles that the user should have to encounter. The purpose of the experience would be to educate the user on dyslexia while also have them experience the feelings we dyslexics face every day.  I would love for the experience to be as emotional as it is informative. 

In my fabrication class during the first part of the semester I developed this project. I would love to use this pattern style to create something more meaningful.  The state of politics and the world has created very polarizing relationships between people from similar or varying backgrounds.  My idea is to create a small wall with some sort of pattern like the one I made in fabrication or this one. Two users would be able to stand on either side of the wall.  The project would prompt the user with some carefully curated questions.  As the questions/answers prompt similarities between the two users, the pattern will open up more and more to expose the person on the other side.  This project would explore similarities between two people and try to expose common ground.  As you expose common ground through the answers to the questions, the wall would physically represent the exposure you gain of the other persons beliefs by literally exposing them.  Perhaps, based on the types of questions, the wall can expose different opening patterns in order to represent the area of common ground they discovered. 

Week 7: Midterm Project


Over the past few weeks I have been working with Elvin Ou to develop a Halloween themed project.  We built a Halloween candy game and a skull shaped candy dispenser.  When the user wins the game, they are rewarded with some candy dispensed from the skull’s mouth. Figure 1 shows the final product and some examples of users interacting with the piece.


During our first meeting, we settled on the concept of having the winning of a game be rewarded by some Halloween candy.  From there we sketched out the general concept of a candy dispenser that is triggered when a game is won. Figure 2 shows our sketch from our first meeting.  We knew we wanted some sort of box that would hold and dispense the candy.  Initially we thought that we would build the box (shown in Figure 2) and cover it with a halloween themed skull and neck.  After this meeting we went to the Halloween store and found a skull beer funnel. This was perfect for our application because we would not have to design and build our own box, but we could use this funnel as the main container for our project.  The hallow neck was an added feature that we could use to thread and hide our electrical wiring.

With this baseline, we split up tasks to get an initial working prototype.  Elvin built the game with p5.js while I designed a door opening system and coded the motor to open and close through a hole in the skulls mouth.  Figure 3 shows a video of the original version of the game.  The jack-o’-lantern was controlled by the users mouse.  When the jack-o’-lantern collided with the candy, the candy would go away.  The goal of the game was to collect all of the candy while avoiding the bats.  If the user collided with a bat, the game would be over.

Figure 3

Once this version was working, we connected two potentiometers serially and changed the game to be controlled by the potentiometers.  One potentiometer controlled the x-position of the jack-o’-lantern while the other controlled the y-position of the jack-o’-lantern (Figure 4).  The code for the final version of the game can be found here.

Uploaded by Eva Philips on 2018-10-24.

Building the motor mount and door system was a multi-step process. First, I laser cut a mount out of cardboard to fit inside the jaw of the skull (Figure 5A & 5B).  The motor fit inside the mount plates (as seen in Figure 5B) and four screws sandwiched the motor between the two plates.  Then I designed a simple disk to fit on the motor axle with a hole to open and close the skull jaw and to allow candy to fall (Figure 5C).

 Figure 6 shows how I attached the same acrylic pieces to mount the motor.  I ended up only using one mounting plate on the inside of the skull and secured the motor to the skull with screws from the outside that go through the motor, the skull, and then the acrylic plate.

Then I drilled a hole in the skull for the candies to dispense (Figure 7).

Figure 7

Figure 7

Together we realized that the space between the bottom of the skull jaw and the door disk would cause a problem when the candies fell through so we redesigned the door piece to fit onto the bottom of the skull and create a close to flush surface for the door to open and close against (Figure 8).

Figure 8

Figure 8

Figure 9 shows the various iterations of the mouth piece as we were prototyping.

Figure 9

Figure 9

Figure 10 shows the door and motor mount mechanism working with our first candy test. The Arduino code to control the motor can be found here.

Uploaded by Eva Philips on 2018-10-24.

Once the motor system was set, I worked on the base.  First I made a cardboard tests to map out the base (Figure 11).

 The bottom was made to screw into the Arduino and the top piece of the base was made to screw into the bottom in order to cover the Arduino.  Two holes were made on the top piece of the base for the potentiometers.  Once this was planned out, I made the acrylic version of the base (Figure 12).  Using the acrylic bender, I bent the top piece so that it formed around the Arduino and allowed for enough room for the electronics.  Figure 12E shows the layout of the electronics and the neck of the skull before the base was closed.  We used zip ties to secure the neck piece onto the base.  We also threaded a lighting gooseneck through the neck piece of the skull in order to allow it to stand up on its own, bend the way we wanted, and to thread our electrical wiring through. 

At this point, we connected all of the pieces and noticed that the candies often got stuck when two candies would fall through the whole next to each other and the dispenser would fail.  Thus we spent a lot of time changing the dispensing mechanism to ensure the candies would not get stuck.  We tried a funnel, different tube configurations, other candies, etc. Ultimately, we used a funnel and a small 45 degree copper tube to get the hole of the skull as close to the door as possible (Figure 13).

While this system helped, the candies still sometimes got stuck in the 45 degree section of the tubing.  Because of the location of the hole and the shape of the skull, we needed this 45 degree angle in the tube to access the hole in the mouth.  Thus, we ended up adding an additional feature, a vibrating motor, to shake the candy so if it did get stuck inside the tube, the vibrations would move them enough to release them down the tube.  For the most part, this solved the problem.  After doing many test, we noticed that on occasion, the candies got so stuck the vibration was not powerful enough to shake them out of place.  Thus, we decided to try to find smaller, round, uniform candies to further ensure that the candies would dispense.  After looking in many stores we came across these small jawbreakers that were exactly what we were looking for (Figure 14).

Figure 14

Figure 14

At this point the candy dispensing was working properly so we closed the base, added knobs to the potentiometers, and completed some user testing (Figure 15).

The last step was to put a top (a brain) on the skull to hide the candy and the project was complete.  Pictures of the final product can be seen in Figure 16.

Figure 16A

Figure 16B


Overall, I think that this project went well and I am very happy with the result.  We did not over extend ourselves at the beginning by creating a relatively simple design.  What surprised us the most was the time it took to fabricate the enclosures and get a working dispenser.  The computational side of things was relatively straight forward, but we spent the most time getting the physical and computational sides to work together such that the candy would dispense properly.  If I were to complete this project again there are a few things I would change.  First, I would put the dispenser hole in a place on the skull that is more easily accessible.  If the candies did not need to curve down a 45 degree tube, we would not have had as many dispensing issues.  I would also like to think more about the interactive piece of the project.  Rather than two knobs, I may want to have the user collect the candy by moving their mouth in or biting motion or by stomping very aggressively on the candies.  I think rethinking this interaction could elevate the project even more.  The addition of the vibrating motor created a good learning experience for me.  I had a feeling that we would need to add this feature to solve our problem but it would create more work on the computation side, so I was hesitant.  We spent a long time trying other solutions before eventually switching to the inevitable, adding the vibrating motor. In the end, I think we would have saved a lot of time if we had just took the time to add the vibrating motor in the first place.  Overall, the entire process to make this project was very fun.  The final result definitely resembled what be initial had in mind, which was very exciting. 

Week 7: Serial Output From p5

This week I completed the serial output from p5.js labs and class demos.

Figure 1 shows the demo from class.  Here are the p5 and Arduino codes that accompany this demo.

Figure 1: Class Demo

Figure 2 shows the serial output from p5 lab.  Here are the p5 and Arduino codes that accompany this lab.

Figure 2: Serial Output Lab

Week 6: Serial Input with Arduino & p5.js

This week I worked with serial input using Arduino and p5.js.  Figure 1 shows the demo from class.  Here are the p5 and Arduino codes that accompany this demo.

Figure 1: Class Demo

Next, I completed the Serial Input to the P5.js IDE Lab (Figure 2). Here are the p5 and Arduino codes that accompany this lab. 

Figure 2: Serial Input Lab

Once I completed the lab, I used serial input to control an existing p5 sketch I made in my ICM class (Figure3&4).  This sketch displays an animation of a snowfall with randomized snowflake patterns.  Using serial input, I adjusted the sparkle of each snowflake based on the location of the potentiometer. Here are the p5 and Arduino codes that accompany the snowfall project. 

Figure 3: Snowfall Controls

Figure 4: Snowfall Animation with Serial Input

Lastly, I completed a new p5 sketch which creates a pattern using rectangles.  Three inputs from the Arduino adjust the pattern.  The button toggles the rectMode between the center and corner modes.  Then one potentiometer adjusts the number of squares that are displayed and the other adjusts the angle between each square. Figure 5 shows the results of this project. Here are the p5 and Arduino codes that accompany the pattern project.

Figure 5: Pattern with Serial Input

Week 5: The Discovery Element of Interaction Design

The readings this week highlighted how we as interaction designers need to collect our ideas and record them in a way that leads to successful user experiences. The tools outlined in Buxton, Sketching User Experiences: The Workbook and the Sketching User Experiences book show how important it is to keep track of all of your ideas and record them in a notebook in an understandable way.  Your sketches should contain all of your ideas, and later you can peel back to create a cleaner, more purposeful design for the best ideas. After reading these pieces and Tom Igoe’s article I thought a lot about the discovery element of designing a interactive user experience.  It is relatively easy to design an interactive piece that is pleasing to look at and polished.  What is difficult is developing the element of discovery for the user and for the concept as a whole.  You need to cut back on the design to allow users to discover parts of the interaction in order to make the interaction more personal and meaningful for them.  At the same time you also want the experience to be somewhat open ended to allow for unpredictable solutions.  Creating a discovery element for the user requires scaling back on the design.  Often simpler is better.  However, stepping back and allowing your idea to have a life of its own is more challenging.  As a designer we want to control what we are designing, when in fact, good interactive pieces should lead to as much discovery for the maker as the user.  If a piece creates unexpected results and a variety of meanings for various users, then it is profound and thus successful.  The key is that we must guide the user without leading them.  We may want the user to touch one of three buttons to initiate the experience so we make the buttons brightly colored, but in order avoid leading them to press one button over the other, you make them identical in shape and color.  Overall these readings taught me the power of recording all of your ideas, prototyping often, user testing to ensure you are guiding without leading, and being open to changes in your designs.  

Week 4: Servo & Tone Labs

This week I completed the servo and tone physical computing labs.  The following images show the resulting circuits…

Figure 1: Servo motor controlled by a force sensor

Figure 2: Piezo speaker with frequency control via light sensors

The following images represent other applications that I developed that use servo motors and speakers.  Figure 3 shows a project I worked on last year that uses a moisture sensor to control the watering of a plant.  If the sensor detects dry soil, the motor will turn and water the plant.  In addition, this project used wifi communication between the motor and the sensor, so there were no hard wired connections between the input and outputs of the project.

Figure 3: Servo motor watering system

After completing the tone lab I designed a new project represented in Figure 4.  Here I used a potentiometer to control the tone duration.  Each button controlled a different note, so when it was pressed the note would sound and when it was released, the note would turn off.

Figure 4: Tone project with potentiometer and buttons

Figure 5 shows the code associated with this tone project. 

Figure 5 : Tone project code

Figure 5: Tone project code

Week 3: New York Hall of Science, Connected Worlds

While at MakerFaire this past weekend, I observed a piece of interactive technology at the New York Hall of Science called Connected Worlds.  Connected worlds “is a large scale immersive, interactive ecosystem” displayed on the walls of the Great Hall (1).  Figure 1 is a professional video taken from the New York Hall of Science website that highlights the piece and shows the types of interactions that it creates (2). 

Figure 1: New York Hall of Science, Connected Worlds Exhibit Promotional video (2)

Before entering the space, instructions are printed on the walls to show the types of gestures you can make (Figure 2A).  For example, to plant a seed in the ecosystem you  place your palm face up in front of the screen or to change the flow of the water, you move the location of the physical logs on the floor.  Figure 2B highlights some features of the ecosystem for the user to look out for.

Although, it is helpful to read these signs, I found the most of the people I observed actually entered the space without needing to read the signs and just observing what others were doing.  Since this is an installation in a museum, enough people cycle through the space at a time that the instruction is mostly created by the users.  I imagine the first couple people in the morning would have to read the instruction before entering.  However, once a few people are using it correctly, other users can follow their lead and not need to read these instructions.  While observing I noticed that the people interacting with the walls were of all ages.  Some were alone, others were in groups.  The people who interacted with the physical logs were mostly younger.  However, older individuals enjoyed watching while children moved the logs to change the flow of the water on the floor.  For the most part, this interaction was very easy for people to pick up and implement themselves after observing another person.  For those the read the sign, little to no difficulties occurred.  For those who did not read the sign, their first interaction sometimes created more difficulty than the ones following.  Because they were following what they observed a neighbor doing, their first interaction sometimes was not the right gesture.  For the most part once they observed and learned each gesture, people had an easy time repeating that gesture at different locations.  People were very fascinated in the discovery aspect of this installation.  As you observed your neighbors, you discover more gestures and thus discovered more that you could do with the ecosystem.  Thus, people stayed and interacted with this piece for anywhere from 1 minute to 10 minutes or more.  The individual interactions themselves ranged from a few seconds to about 20 seconds.  However, most people performed multiple interactions before leaving the space.  I think that the way this breaks up the attention of the user into short intervals keeps the user engaged for longer.  The longest part of the entire experience is taking the time to read the instructions and watch others.  Most people, however, don't even read the instructions so their experience is built on repeated 20 second interactions instead of one long interaction that requires greater focus.  I think this is the biggest success of the project.  The interactions engage the user to focus rather the user needing to focus first in order experience the interaction.  

While I was observing people in this installation, I considered Bret Victor’s article called “A Brief Rant on the Future of Interaction Design.”  This article highlights the importance of creating designs that use your entire body and not just the swipe of your hand.  Because people are using new gestures that use different parts of their bodies, they want to stay longer and explore the experience.  The type of interaction that this creates, causes more meaningful interactions than swiping a screen of an iPad.  This is the most powerful aspect of the Connected Worlds exhibits.  It’s ability to grasp peoples attention and sustain it through the interaction it generates.  In Norman’s article called “Attractive Things Work Better,” he nots that pleasing things then to work better and are easier to use.  This concept is also apparent in this exhibit.  The exhibit is beautiful and creates a pleasing scene to look at and explore, and thus, it is what Norman qualifies as good design.


  1. http://design-io.com/projects/ConnectedWorlds/

  2. https://vimeo.com/131725811

Week 3: Digital & Analog Input/Output Labs

This week I completed the Digital Input/Output lab in addition to the Analog Input lab.  The following images show the resulting circuits.

Figure 1: Digital Input Button

Figure 2: Digital Input/Output

Figure 3: Analog Input/Output

After completing these labs, I designed a circuit that would help someone determine if they were pressing hard enough while taking a pulse.  Figure 4 shows the set up.  As the user pressed on the wrist, the colored LEDs would light up.  If the user was pressing hard enough, the red LED would turn on.  If the user was pressing to lightly, the other LEDs would turn on based on the level of pressure. Figure 5 shows a video of the circuit. 

Figure 4 : Pulse Testing Circuit

Figure 4: Pulse Testing Circuit

Figure 5: Pulse Testing Video

Week 2: Electronics Labs

This week I followed the initial ITP physical computing labs to get reacquainted with my Arduino and electronics.  I have worked with an Arduino before and built projects that incorporated some medium level circuits. Therefore, most of these electronics labs were review.  In the past, I have mainly used the multimeter to measure voltage so the way these labs used the multimeter was new.  I can see how the multimeter can be used as a much more powerful tool in the future.   

The following images highlight the circuits I made in the lab this week…

Figure 1  A simple circuit to light up an LED

Figure 1 A simple circuit to light up an LED

Figure 2 A simple circuit with a button switch to light up an LED

Figure 3  LED circuit in series

Figure 3 LED circuit in series

Figure 5 LED circuit with potentiometer

Figure 6 LED circuit with switches in parallel

Once I completed the labs I made this felt fish with a switch and LED circuit (Figure 7).

Figure 7 : Felt Fish

Figure 7: Felt Fish

I punctured an LED through the felt eye on the fish.  I then created a switch circuit similar to the one seen in Figure 2.  Here however, I used a conductive metal snap to make the switch (Figure 8).  This way when the fin is up the switch is open and the light is off.  When the snap is closed, the switch is closed and the LED turns on. 

Figure 8 : Snap on the fish

Figure 8: Snap on the fish

Week 2: Discussing Usability vs Aesthetics

I have read the entirety of Norman’s Design of Everyday Things in the past and believe that all inventors, engineers, and designers should do the same.  Norman’s breakdown of everyday products makes you think about the world differently.  After reading the book I started noticing poorly designed doors and poorly labeled buttons everywhere.  You gain an appreciation for products that just work and are intuitive and gain a distain for ones that don’t.  One message from the book that has stuck with me is that when a product does not work, it is not the users fault, it is the fault of the design.  Since reading this, I constantly analyze the objects that I interact with to determine their design success.  Of course the most common one we all encounter is a Norman door.  Doors that are meant to be push yet I pull them, or visa versa.  It may seem like this is an irritating way to live, however, I have found it insights my own ideas.  The frequency with which I am effected by poor design has inflicted on me a passion for creating designs that are successful and thoughtful.  Once we have an idea, we cannot just run with it, we need to consider its usability.  One area where the book lacked, however, was a discussion on the importance of attractiveness.  One may walk away from reading the book, thinking that usability is much more important than aesthetics.  However, in this new article by Norman, “Attractive Things Work Better,” Norman addresses this hole in his earlier book.  Using new research in psychology Norman ultimately concludes that aesthetics is equal to usability.  He writes, “A short summary is that good human-centered design practices are most essential for tasks or situations that are stressful: distractions, bottlenecks, and irritations need to be minimized.  In pleasant, positive situations, people are much more likely to be tolerant of minor difficulties and irrelevancies.”  I find this fascinating.  Our reactions to products change depending on the situation and our mood.  This makes the challenge of making well designed things harder.  If you are designing for all types of situations and all types of users, the task can be quite daunting.  This discussion also made me think about the importance of aesthetics vs usability and workability for the maker.  When someone has an idea and starts to prototype it, the first quality they are looking for is that it works, no matter the looks.  The next quality they look for is that it is usable.  And the last quality is that is looks good.  So usually, the way we design puts workability and usability before aesthetics.  However, Norman is saying that they are all equally important.  Perhaps we sometimes need to re-order these focuses in order to create more balanced products that work, work properly, and look beautiful.  

Week 1: Discussing Interactivity

The beginning of Crawford’s The Art of Interactive Design properly summed up the discussion we were having in class regarding the spectrum of interactivity.  In the coming years, while designing at ITP, it will be important to consider the interactions we produce.  We must understand the level of interaction we are asking for and consider its importance.  In his discussion on the power of interactivity, Crawford writes, “interactive communication is superior to conventional, one way communication.”  This statement really stuck with me.  If done right, the projects we produce can insight or make someone feel a way words cannot.  This sentiment makes me excited for what I will create.  Similarly, Bret Victor’s “A Brief Rant on the Future of Interaction Design” made me realize why these interactions can be so meaningful.  Productive interactive and thus good design often involves your body, not just the swipe of your finger.  While designing, Victor says that we must consider human capabilities and use them to our advantage.  Thus, it is simply wrong to think of screen interaction as the “vision of the future.”  I definitely agree with this sentiment.  It seems as though we often see this type of “vision of the future” portrayed in ads, shows, and movies because it is the easy solution.  However, all these interactions are the same.  In fact the designs of the future will use technology to create much more meaningful interactions because they will use different parts of our bodies and create tangible interactions.