Author: Hubert Chang

For this week’s user testing, I invited my good friend Clara to be my test subject. Clara has never stood on a skateboard before and this was her first time. I try to tell her as little as possible but I did tell her to feel free and grab the table in front of her if she felt unsafe or if she lost her balance.

First I asked her to simply step onto the board; this is good for me to see where her feet would naturally stand. I’m also going to use Clara as the average height of a female user from now on.

Then I got a shot from further away to see how she was naturally adjusting to the board as she got on. I pay special attention to how people bend their knees and adjust their arms when they’re leaning on the board.

Lastly, I told her to try and lean far back and far forward to see if she was comfortable.

Are they able to figure it out? Where do they get confused and why? Do they understand the mapping between the controls and what happens in the experience?

Prior to Clara, I’ve also had a few other people step onto the board and everyone so far has understood how to step onto the board safely and slowly.

However, first-timers always express that either tilting forward or backward is initially a little scary, but the other way was fine; more people indicated that leaning backward made them more nervous than learning forward.

The controls are pretty intuitive based on what I’ve asked Clara and the many other unofficial test users. Afterall, you simply learn forward or backward once you’re on the board.

What parts of the experience are working well? What areas could be improved? 

People who have never stood on a skateboard before were really excited to try; everyone so far approaches the experience with caution so that part is working great. I believe the fact that the board is stationary calms a lot of people’s nerves. It did come to my attention that a lot of people on campus might be wearing very casual and loose footwear on the day of the showcase (sandals, crocs, etc), so I should probably restrict loose footwear that doesn’t hold your foot in place very well.

I’m going to make a slideshow explaining everything about the project for people who are lining up to try if there’s someone already playing with the project.

What parts of your project did you feel the need to explain? How could you make these areas more clear to someone that is experiencing your project for the first time?

I felt like I had to explain to people that whether you skate goofy or regular was not dependent on your dominant hand, and that they should do what feels more natural to them. 

I think a quick tutorial on how to stand on a skateboard before the game starts would be great. In addition to that, I’ve placed some colored tape to indicate where to stand and especially where not to stand (like the tail).

 

I unfortunately don’t have anything physical down for this week, but I have made a lot of my own blueprints for how everything will physically be put together.

After speaking with Professor Shiloh, I got a lot of ideas on how to go about assembling my skateboard controller. Prof. Shiloh showed us this tool that could measure the diameter of round axles and drill parts; I was thinking I could use that to measure the exact diameter of my skateboard truck hangars (the long metal piece). I’m expecting around 1.8 mm right now for the hangar diameter and around 8mm for the axle itself.

I’m probably going to create a hole with the size of the truck hangars in mind if possible; otherwise, I would need to create a hole for the truck axle to spin into, which might be a bit difficult. I want to build the frame in a way where I can take it apart for ease-of-transportation.

Mount Mechanism

For the mounting mechanism, I’m going to build a wooden frame to hold the board. I want it to be tilted forwards around 30 degrees for a more intense and immersive experience. The way I’m going to do that is to make the rear wheel support columns taller than the front ones.  Here’s what it might look like:

And this is a top-down view of the frame. It would have long extensions on each side to prevent the board from tipping over when the user is playing with the board. There’s no proper dimensions for this design yet but I’ll look into what length I would need each side to be for ideal safety standards.

I’m going to be placing the infrared sensors on the wooden frame below the board. There would be a sensor on both the left and right of the board, which will provide input values to the Arduino. The reason they aren’t going on the board is because then the sensors would tilt with the board, disallowing it from detecting true distance from the ground. This is roughly what it will look like:

Arduino Input & Output

The Arduino is going to take the two Infrared Distance sensors as an input (in millimeters). It’s going to do some quick calculations to estimate the degree of tilt based on the two sensors and output a value for the tilt; It’s probably going to use arbitrary units from -100 to 100 where 0 is perfectly neutral and not tilted while negative 100 is tilting far left and positive 100 is tilting far right.

P5 Input & Output

The P5 side of things is going to take the -100 to 100 scale from the Arduino output and likely map it to what the user is controlling. If the user is controlling the X-position of a ball, the board tilting left would cause the ball to slide to the right. It’s kinda like the video game Super Monkey Ball where you physically tilting your controller (gyro controls) causes the level to tilt and subsequently roll the ball around.

This would require some physics-like exponential mapping that I’m not quite sure how to do yet but I can imagine this already being a really fun experience.

 

Production #1: Potentiometer Moves Ellipse

Link to P5 Sketch #1

Production #2: P5 Controls LEDs

Link to P5 Sketch #2

I modified it to also take “A” and “D” keys as input just like the mouse clicks

From the very week of the semester when I learned what the final project would involve, I wanted to implement my skateboard into it as a controller.

The Digital Side of Things

I’m not quite sure of how the P5 side of things would look yet, but one of the ideas I had was to create an experience that commentates on the shaking feeling of anxiety and expresses it as speed wobbles going downhill. I’m not quite sure I can simulate that safely or even have a mechanism that provides movement to the board at all, but it could be a fun idea. You would have to balance the board at certain times but also lean in to either side to make decisions.

Another idea I had was to make a more simple arcade-styled game that uses the skateboard controller. For example, I could make a pong game with two skateboard controllers that have the same mechanics as my midterm project (the forward and backward velocity factors). This would definitely be a little easier on me on the programming side but I’m not sure how I would do two separate skateboard controllers, or if it’d even be fun.

The Physical Side of Things

I have actually thought extensively about how the board might be physically situated.

I want the skateboard to sit stationary so I’m probably going to create something like a wooden frame to hold the board either by the trucks or by the wheels. If I want the frame to hold onto the trucks, I would need to unscrew the wheels and create screw holes in the wooden frame. If I want to keep the wheels on, I would make a mold to hold the board with the wheels on.

For the input sensors, I would need a pair of two distance sensors, one for each side of the board. Each of them will be placed on the ground facing upward to detect how tilted the board is. If the distance between ground and board is closer on the left side than the right side, that means the rider is probably tilting left to turn left. I’m not sure if there’s a more efficient way of approaching this but that’s the idea I have so far.

I want to take advantage of resources we have in the IM lab and scene shop but I’ve never worked with physical materials on this scale before so I’m not sure where to start. That’s definitely one of the bigger pain points on the table right now.

Ultimately, there’s a good chance I might change the concept of my project entirely to fit a little closer to the scope of my current abilities. I realize there’s a lot of unfamiliar territory I want to explore here and it might be best to play it safer.

One of the most interesting points Pullin makes in his book is the idea that lots of design standards around disability is to cover it up rather than embrace it or emphasize it. There is always a strong push towards “normalcy” in the design world. His example of how glasses went from medical necessities to a fashion item; I believe most people may acknowledge someone wears glasses out of necessity but we also subtly know that the style of glasses they wear is also an expression of themselves. I imagine as prosthetics become more advanced and fine-tuned, humans will find a way to embrace these tools as more than just their functions but also introduce an expressive layer to them. An easy example of how that might look is if someone needs a prosthetic arm, they might want a prosthetic arm that resembles their favorite prosthetic-using character in fiction (like Edward Elric, Luke Skywalker, or even Guts). This agency and idea of co-design can empower non-able-bodied folks.

Pullin actually mentions that prosthetic arms are much more intimate than prosthetic legs; arms inherently serve more than their function, and it’s not just about nails, veins, or perceived texture. If it’s trying to resemble a fleshy human arm, it creates a serious sense of disappointment and is often off-putting. Pullin mentions the best approach here is often to NOT hide the fact that the arm is artificial and instead emphasize it while giving the functions of a fleshy arm. This was all really interesting to me, especially his example of how certain clients of Monestier would hate the feeling when the hand would initially fool new acquaintances until they had their moments of realization.

As I read this article, I thought about how prosthetics in fiction are often romanticized. A sick metal arm that can turn into a cannon or extend out to become a grapple hook are often framed as “upgrades” but I imagine not having complete dexterity and fleshiness creates quite a sense of void that most fiction rarely explores. I thought of this as a connection to last week’s reading on a “Brief Rant on the Future of Interaction Design”, which I also thought was very insightful. There must be an inherent, strong emotional gap on prosthetic function and feeling, and I think our portrayals of disabled characters in media could use some more commentary on losing their sense of touch.

This week Yongje and myself paired up to make our very own musical instrument.

I thought about the capabilities of the arduino speaker and was unimpressed with the sound “texture” of it, so we discussed what we could do with a rather limited range of sounds we could generate. I’m not much of a musician so I suggested what if we made a simple beat recorder, kinda like a metronome of sorts? Yongje informed me that what I was describing is called a “loopstation” and we got to designing.

Concept (With Visuals) – Hubert

After we planned what we wanted to do, I decided to visualize the user interaction side of the project first before designing the schematics and technical side.

The red button would be to start/stop the recording process. A red LED would indicate whether it was currently recording.

The blue button would be there for the user to tap in their beat.

When you are done with your beat, you can save it by clicking the red button once again. You can see whether it was properly stopped by the indicator turning off. Then you can press the green button to play your recorded beat.

Schematics & Planning – Hubert

Before we started connecting metal to metal, I made a schematic to quickly map out everything we needed to connect.

 

Code & Difficulties Encountered – Yongje

There are 3 main parts to the code.

The first is figuring out debouncing logic, which is used to remove the state when the system is bouncing between true and false when the switch is pressed. The second part is playback, actually playing back the recorded soundLastly, the third which is the hardest part: finding how to store the beat recording.

I’ll start by explaining the hardest part first, which is storing the beat recording.
The beat recording logic works by tracking the time of each button press and release while the device is in recording mode. Every time the beat button is pressed, the program calculates the gap since the previous press (gap = now – tRef) to capture the spacing between beats. When the button is released, it measures the duration the button was held (dur = now – lastPressTime) to record how long that beat lasted. Both values are stored in arrays (gaps[] and durs[]), building a timeline of when each beat starts and how long it plays. Figuring out this logic was the most difficult part.

Now onto explaining the playback logic. The playback logic is responsible for reproducing the rhythm that was recorded. It does this by reading through the stored arrays of gaps and durations in order. For each beat, the program first waits for the gap time, which is the delay before the next beat begins and then plays a tone on the speaker for the duration that was originally recorded. Because each recorded gap includes the previous beat’s duration, the playback code subtracts the previous duration from the current gap to get the true silent time between beats. This ensures that the playback matches the timing and spacing of the user’s original input, accurately reproducing both the rhythm and the length of each beat. I had to create a logic to turn negative silence time to positive because sometimes it gave errors when the inputs and the durations of beats were too short. This is explained in depth in the comment section of the code.

Finally, the debounce logic ensures that each button press or release is detected only once, even though mechanical switches naturally produce rapid, noisy fluctuations when pressed. When a button’s state changes, the program records the current time and waits a short period to confirm that the signal has stabilized. Only if the input remains steady for longer than this debounce delay does the program treat it as a valid press or release event. This filtering prevents false triggers caused by electrical noise or contact bounce, giving the system clean, reliable button inputs for recording and playback control. At first, I didn’t have this debounce logic implemented and had a hard time figuring out why the system sometimes failed to recognize button presses or seemed to trigger multiple times for a single press. Once the debounce logic was added, the button responses became stable and consistent.

Reflection

I believe this project turned out really well, and it was very interesting to work on our first group project of the semester.

My initial impression regarding the”Brief Rant on the Future of Interaction Design” reading was that it was formatted in a very engaging way. As someone with ADHD, I tend to read long paragraphs a lot slower than individual sentences structured this way; this made me trust in the credibility of the author’s perspective on interaction design.

The way the author transitions from explaining the importance of touch to the complete lack of it in our touchscreen technology was really done, and I couldn’t agree more. Using touchscreens is really un-stimulating, and if anyone who has tried texting without haptics will know it feels incredibly unresponsive– but that also seems to be the future we’re headed towards. The images Bret Victor chooses to accompany his texts are hilarious too; there really aren’t many things we naturally need our hands to swipe on other than manmade touchscreens. Victor’s explanation of how humans naturally transition between grip-styles is pretty interesting to me too.

This reading gave me a lot to think about. One of the things that came to mind was the experience of using a controller versus mouse & keyboard when playing video games. For those unaware, let me explain the main differences between the two.

When you use a controller (or gamepad as some call it), you’re primarily using your thumbs for everything from the analog sticks to the surface-buttons. Using just your thumb to control your camera controls can be quite difficult if precise and delicate movements are required.

When you use a keyboard and mouse, your arm and wrist are capable of microadjustments while holding the mouse to input much more precise and delicate movements; not to mention your keyboard hand is using way more than just your thumb to control what’s happening on screen.

So going by what I’ve said, many would probably wonder why anyone would ever use a controller, but that’s the thing– I haven’t explained the one thing that makes this remotely a difficult decision.
Controllers give an extra layer of immersion by both letting the user relax their arms and lean back, but also provide the user with haptic feedback and vibrations in response to what’s happening in-game. Imagine you’re playing a game where explosions are involved– the controller would vibrate violently in your hands as explosions affect your character. This is why you turn to keyboard and mouse for precision but controllers for immersion.

Now onto Victor’s follow-up article– I thought his response to voice was pretty amusing, “I have a hard time imagining Monet saying to his canvas, “Give me some water lilies. Make ’em impressionistic.” It’s amusing because that’s literally how our modern generation approaches stuff they don’t know how to do.

One other thing that really caught my attention in the follow-up was this quote, “The density of nerve endings in our fingertips is enormous. Their discrimination is almost as good as that of our eyes. If we don’t use our fingers, if in childhood and youth we become “finger-blind”, this rich network of nerves is impoverished.” I wonder if late-gen Z and gen alpha have any indicators of finger blindness as so many of us grew up with touchscreen devices as our main source of entertainment.

 

I initially really struggled to come up with a concept for this week’s project. While I understood how to use analog and digital switches, I wasn’t sure how I would use them in conjunction to create something engaging and interesting. I slept on it and woke up with the idea to build off the theme of security from week 8 and make a lock mechanism using analog inputs like the potentiometer.

One of my biggest concerns was that I wasn’t sure how to draw a proper schematic so I looked online and used Tinkercad Circuits for a while but it wasn’t exactly the simple schematic drawing I wanted so I decided to save the site for future use instead.

This was the schematic I came up with. I knew I was going to mess up and have to move stuff around so I did it digitally using simple shapes and lines on canvas. I barely knew what I was doing and to be honest it made a LOT more sense to just start putting wires and pieces together on the breadboard but this schematic was how I thought it would look.

And this is how it looked physically with all the relevant pieces attached to the breadboard.

I knew the wiring would get pretty crazy as I started to connect everything so this is how I color-coded them:

• • Red: Power Source (+)
  • Black: Ground (-)
  • Green: Inputs Connections to Arduino Uno (Switch, Pot Meter, etc)
  • Yellow: Output Connections to Arduino Uno (LEDs)

On the code-side, I made sure to declare each pin I was going to use at the very top so I could quickly change it if I needed to swap stuff around.

int greenButton = 7; //button to open lock
int blackSwitch = 2; //part of the lock (the black on/off switch)
int potMeter = A4; //part of the lock (the roating blue one)

int greenLED = 12; //lock is open
int redLED = 11; //indicates lock is still locked

//LOCK COMBINATIONS
int blackSwitchANSWER = LOW;
int potMeterANSWER = 1000; //above X value to be correct

This is what the final product looked like:

I didn’t run into many bugs when coding but I did initially accidentally set the red light to always be on unless I was holding down the green button. I had to search online how I could fix this and I eventually found I could set the pinmode for the button to “INPUT_PULLUP” which was useful for inputs that otherwise would have no stable value when not pressed.

pinMode(greenButton, INPUT_PULLUP); //INPUT_PULLUP is good for buttons that automatically spring back uppinMode(blackSwitch, INPUT_PULLUP);
pinMode(potMeter, INPUT);

pinMode(greenLED, OUTPUT);
pinMode(redLED, OUTPUT);

I did have a physical difficulty where I was testing different kinds of inputs with the switch and the potentiometer and forgot what the correct combination actually was– and with no way to know if the green light was even going to turn on when it WAS correct. Thankfully a minute of trial and error and making sure the code side of things was correct got me to return to the original combination, but that could’ve been pretty annoying if the lock was any more complicated.

When it came to the LED light responses. I originally had the appropriate light turn on for 2 seconds and then turn off. I felt like this didn’t feel quite right so I made a creative decision to flash the appropriate light as feedback instead; I did this by creating a for loop that would flash the light 5 times with a small delay. This felt a LOT more responsive than the brief moment that the light would turn on previously. Below is the full if-statement that checked whether the confirm button, the green one, was pressed.

if (greenButtonState == LOW) {  
  if (LockIsUNLOCKED == true) { 
    digitalWrite(redLED, LOW); //turn OFF red light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(greenLED, HIGH);
      delay(150);
      digitalWrite(greenLED, LOW);
      delay(150);
    }

  } else {
    digitalWrite(greenLED, LOW); //turn OFF green light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(redLED, HIGH);
      delay(150);
      digitalWrite(redLED, LOW);
      delay(150);
    }
  }
}

I am very proud of how it turned out in the end with both the technical difficulties that I solved and how it feels to interact with it. Below is a demonstration of the lock working; you need to toggle the black switch to the right side and twist the potentiometer counterclockwise to the end.

Link to ino File (Google Drive)

I started this project with a few ideas. One of the ideas was to make a secret switch hidden on a bookshelf. One of the books would have a piece of copper tape underneath that would touch the copper tape beneath it on the shelf. However…I realized that I didn’t have enough books to make it look convincing so I started looking around my room for something that inherently had motion to make my life easier. So I thought– what if I used my door?

Sometimes I don’t fully close my door properly and don’t know if it’s fully closed. That inspired me to make the door a switch to act like a DIY security system. I have no experience with physical computing so I had some trouble visualizing how it would look in my head, and it didn’t help that I’ve been out sick for so long. This image below was my initial concept for it.

The idea is to set up a simple LED light on the breadboard that would light up when the door was fully closed. I think I understood that pretty comfortably, but I didn’t know how the rest would work.

One of the challenges was having a mobile power source, as I was definitely not going to use my laptop for power when the Arduino kit is all the way up on the wall. I remembered that I found a battery pack in the kit so I dug that out and went down to the IM lab to ask for help and got some spare AA batteries.

The breadboard and Arduino setup was pretty straightforward but the one thing I had to think about was which wires to leave as an open connection later. From my perspective, it made sense to have the ground be split up and later connected using the copper tape so that’s what I did, while following the color conventions of PWR and GND.

I walked over to my door and applied some copper tape and set up my Arduino & battery pack on the wall using some mounting tape. However, as I worked on setting up the rest of the copper tape, I realized that this was going to very clunky– the door’s frame is not seamless with the door itself which means I need something solid to connect it; however, the copper tape was a bit too flimsy to be that connection. This is what I had so far at the time:

 

I was pretty perplexed by this. After some critical thinking, I realized that I could set up the arduino on the door itself. And not only that– I could even take advantage of this metal piece that helps the door slide into the lock near the door handle. This was my updated plan for my switch:

When it came to positioning the wires, I thought the copper tape would suffice to keep the wires in place but it just wouldn’t stick very well; I also needed to be able to micro-adjust and tune the location of my wires to make sure the system worked smoothly. I decided to use mounting tape again to make fine tuning the position of the wires much easier on me

I think the final result turned out to be really nice, and I’m proud of myself for adapting to the difficulties encountered during the process of mounting the project on the wall. It’s a shame I have to take it down to make future projects but I had fun making it.

 

Here’s a video of the final result in action; the green LED lights up to indicate a full lock when closed properly. I would not recommend installing this as your sole security system.

 

 

For Tigoe’s “Physical Computing” piece, one of the quotes that stood out to me was the idea that pretty much everything physical computing-related has already been done before, and if it hasn’t, many aspects of your idea are inevitably going to be unoriginal, and that is okay. The main message I got from this piece was that there are endless ways of remixing things using the same concepts you see– your specific combination of physical computing-ideas is going to make your idea.

Out of the motifs he listed, I thought the tilty stands/tables were the most amusing to me. The first reason why is because it reminded me of the game Super Monkey Ball, a game I loved as a kid; the second reason is because I’ve been wanting to integrate my old skateboard into our final project since the first class, and a skateboard is basically a “tilty table” you stand on. I hope to learn more physical computing skills to eventually create an interactive experience using my skateboard.

For Tigoe’s second piece, “Set the Stage, Then Shut Up and Listen”, the title immediately reminded me of the mindset I had to approach my midterm presentation with– if my game is good, I have no need to explain anything myself. Sure enough, that was roughly the mentality Tigoe was preaching here.

I’ve heard staying quiet and watching the experience can be very frustrating for many people, but my personal belief is that the frustration is an indicator of poor user experience design. My experience with watching has always been so much fun as I get to confirm my hypothesis with how the user interacts with the game.

For example, I wanted to create a situation where players would communicate “let me handle the red ball and you get the blue ball” in my midterm game’s co-op mode. The game would only start with one ball but a second one would spawn after the ball’s second bounce, which would hopefully prompt the players to coordinate whose responsibility the new ball was. When it came to the first ever playtest in-class, I was overjoyed when Yongje and Khatira said “let me handle the red ball and you get the blue ball” pretty much word-for-word.

However, I also recognize that not every system is foolproof as there are prerequisites I had not considered for understanding the game. Many people struggled to figure out what fingers to use to press WASD or the arrow keys so they would use one finger from each hand to press WASD separately and get really confused why the controls were so clunky. Obviously, WASD is a very gamer-coded instinct so anyone who inherently doesn’t play games would not understand to put their middle finger on “W” and ring and index fingers beside on the “A” and “D” keys respectively. That begs the question of whether explaining finger placement was necessary or whether there was an unforeseen restriction on who could enjoy my project.