Users understood the relationship between their actions and the game responses well. This was particularly true for tasks involving direct interactions like pressing buttons.
Engagement with Tasks: The distance sensing tasks were well-received, as participants found them to be intuitive and fun.
Sensor Integration: The integration of the potentiometer within the game mechanics worked smoothly, providing a satisfying challenge to the players.
Areas for Improvement
Animation Speed: There was a noticeable slowdown in animation frames as the game progressed, which affected the overall experience. This issue needs to be addressed to ensure smooth gameplay.
Keypad Usage: Although the Adafruit Trellis keypad was a central component of the game, many users needed additional instructions to use it effectively.
Enhancements and Future Steps
To make the game more user-friendly and engaging, here are some steps I plan to take based on the feedback:
Clarify Sensor Usage: Simplify the riddles associated with sensors or provide clearer, step-by-step tutorials that guide the users on how to interact with the game.
Improve Animations: Optimize the code to ensure that animation frames run smoothly throughout the game, enhancing the visual feedback that is crucial for interactive gameplay.
For my project, I did 9 user test in total, with the people who did not know about my game at all. The procedure is such that I invite them, I start the p5js sketch, set up the camera and let them work out without saying anything.
Gladly, out of 9 subjects, only 2 needed instructions from me, and others at one point were able to figure out the entire experience withotu instruction. The average play time/ or time needed for them to enjoy the experience without needing instructions is 3 minutes. Below are 3 sessions of the user testing.
The only parts where I needed to explain for the 2 users are (1) the user did not read the instructions on the screen and did not know they have to touch the castle and (2) The user did not connect to the right serial port.
In general, this is the feedbacks I get for improvement suggestion.
Cover the breadboard of the castle with a ladder texture to make the design more consistent and hide the electronics.
I need to be more specific in telling which serial port to choose (now I only say usbmodem).
Take out all the debugging functionalities I made for myself in the actual game.
Tell the people to stand up and play (It is more comfortable than sitting down).
Sometimes the bullet hit the enemy, but the enemy did not die (I need to adjust the collider radius).
Some users did not get the full background story, so probably have a mini comic printed out so that whoever interested can read.
Special Thanks
Special Thanks to Guglielmo Fonda, Aditya Pandhare, Aneeka Paul, Megan Marzolf, Salma Mansour, Sashank Neupane, Lingfen Ren, Lexie and Nastassja for testing my project.
The journey of transforming a concept into a tangible, functional reality is an exhilarating experience, with challenges and discoveries at every turn. The most enjoyable part of this adventure for me was definitely the user-testing phase of my final project. It’s one thing to nurture an idea in your mind or sketch it on paper, but watching real people interact with your creation adds a layer of excitement and invaluable insights.
A significant hurdle I faced was with the servos intended to be a key component of the project. Despite my efforts, I struggled immensely with integrating and programming them. The complexity proved to be beyond the scope of what could be managed within the time and resource constraints of the project I had to make the difficult decision to pivot and remove the servos entirely from the project. This decision, though tough, was necessary to maintain the project’s viability and ensure a smoother user experience.
Pivoting away from using servos forced me to rethink and simplify the design, focusing on what was most essential and functional. This redesign, though less complex, brought its own set of challenges and learning opportunities.
The insights gained from user-testing were invaluable. Observing how users interacted with the revised version of the project without the servos helped me understand the practicality and user-friendliness of my design. The feedback was instrumental in shaping the final tweaks:
Timer needs to be bigger: Users found the timer too small, highlighting the need for a more visible and accessible design. (Alongside that I believe I will increase the size of all text) Add instructions page: User suggested that there be an instructions page to clarify the objective Fix dog barking glitch: Dog barking would play over itself causing an awkward sound (potential solution is to increase the delay time between sounds
Through user testing, I improved the look of the device itself by covering the wire with insulated heat-shrinkable tubes so that it doesn’t get caught up by anything over the user’s hand. Also, an issue that was resolved after more testing was that, for some odd reason, the code kept looping over the positioning of the UFO, making it glitch after a while of playing the game.
Video of the problem:
After the improvements:
After playing once or twice, people can understand the concept, which made me realize that I needed to create an info tab to finalize the project.
For user testing, I asked two of my friends to come in and try interacting with my piece. I have so far managed to bring everything together: 1) construct the box that would come to enclose the Arduino and whose surface would act as a canvas for the sketch to be projected on, 2) make the butterfly body out of printed laminated paper and attach the wings to the servos, 3) secure the butterfly atop the surface, and 4) attach two wires, shaped like butterfly antennas, beneath the wings to convey touch signals to the p5 sketch and activate the animation and the butterfly flutters. I knew that upon seeing the piece, users might not get the intuition to touch the butterfly. They also might shy away from touching it, out of fear of ruining the butterfly’s delicate structure, or assume that some other automatic process would have to trigger the movement of the piece. To counter that, I will be displaying a name next to my piece that indicates, but does not outright reveal, that a touch signal is necessary. I have not yet settled on a name, but have told my two friends that it would be called “catch a butterfly” or “pet a butterfly” and they immediately figured out that they had to use their hands in some way. I placed the antennas facing them so that they were more likely to come into contact with them and I was glad that they did end up placing their touch close enough to the wires for the signal to be captured.
They both loved seeing the butterfly in action, but gave the following feedback, which was mainly focused on the sketch itself:
add different colors to the butterflies in the sketch
experiment with different movement paths for the projected butterflies (inward movement from outside the sketch bounds or having multiple center points for their emergence, for example) or smoothen/slow down their movement.
I expected the feedback I got from them, as I have been planning to implement those two features after I had the basic version of the project implemented. I will be working on that over the next couple of days, as well as decorating the surface some more (adding flowers to cover the base of the servos and on different parts of the surface).
The project is well on its way, and I have some updates for all of you!
First of all, let’s start with the good things, and that is that the boat structure has been successfully 3d printed and is waterproof. Yaay. The arduino as well as all the batteries and breadboard fit comfortably on the structure so the sizing was correct (for the most part).
There is a few things I need to tackle which I realized during the user testing. Firstly, the fan that I have is not strong enough to move the boat, I will need to find, or make a bigger and better one. The boats construction also needs some styrofoam on the bottom since the boat is too heavy to float, as seen in the video below.
Over the next two days I want to solve the problem with the floating and the movement on the boat so I can leave the controls for the last day.
As I was conducting user testing for my game, an actual storm was hitting Abu Dhabi, echoing the storm scenario in my game and making the experience feel all the more relatable.
I enlisted my sister to test the game without any prior instructions, which was a great decision as the game proved to be intuitive—she knew immediately that she needed to press the button. However, since I haven’t yet built the controller box, I had to hold it for her. For the wooden block, I explained that she should imagine it as a car moving on the screen.
To my surprise, she played better than I did! It was really enjoyable to watch my game perform exactly as intended. She managed to figure everything out smoothly; the only hiccup was the wooden block. If it had actually looked like a car, I wouldn’t have needed to explain anything. I also handled connecting to the serial port since she wasn’t familiar with it. For the actual exhibition, I’ll provide short written instructions for the connection to assist anyone if I’m not around.
Area for improvement:
The game runs smoothly overall, but the collision detection between the hail and the car is glitchy. Sometimes it triggers a game over even when it shouldn’t, which is quite frustrating. I plan to resolve this issue before the exhibition for sure.
So till now I incorporated one rose out of 4/5 I’m planning to show. It’s working fine with one so I’m hoping it’d be able to detect all of the roses lighting up and flowers blooming along with it. I’m also hoping to incorporate sound with each rose and have all the samples ready – just have to put it in the code (hope that’d be easy).
“Design Meets Disability” delves into a provocative reevaluation of how design interacts with disability, challenging the traditional ethos that design for disability should aim for invisibility and discretion. This text argues that such designs, exemplified by the Eameses’ leg splints and contemporary medical devices, need not shy away from aesthetics in pursuit of functionality. Instead, it suggests that these designs can embrace both, much like eyeglasses have evolved from mere medical necessity to fashion statements.
The core thesis of the book seems to be a call to shift perceptions—away from designing disability aids that blend in, towards creating products that stand out, empowering users and making a statement. This reflects a broader cultural shift in how disability and aids are perceived, a move from viewing them as merely corrective devices to seeing them as integral parts of one’s identity that can express personal style.
The examples of Hearwear and the work of designers like Sam Hecht and Ross Lovegrove underscore the potential for medical devices to be both functional and fashionable. The discussion extends to prosthetics, where figures like Aimee Mullins have not only redefined performance through innovative designs but have also challenged the very aesthetics of disability. Mullins, by using prosthetics that are visually striking, shifts the narrative from loss to empowerment.
The text critically engages with the notion of universal design and its practical applications. It reflects on the complexity inherent in designing products that are universally accessible yet simple and intuitive to use, a challenge that echoes through the design community.
“Design Meets Disability” advocates for a design philosophy that respects both function and fashion, which can transform products for disability into symbols of identity and empowerment. This approach doesn’t just serve the disabled community but enriches our cultural fabric, advocating for inclusivity and diversity in design practices. This reading fosters a deeper appreciation for the intersections between design, technology, and social values, urging us to reconsider our approach to disability not as a deficit to be concealed but as an aspect of human diversity to be celebrated.
Make something that uses only one sensor on Arduino and makes the ellipse in p5 move on the horizontal axis, in the middle of the screen, and nothing on Arduino is controlled by p5
Make something that controls the LED brightness from p5
For these two exercises, we made it so that the potentiometer that is connected to the Arduino controls the LED on the breadboard and the ellipse in the p5 sketch in the middle of the screen, and also when the keyboard keys are pressed up or down it would change the brightness of that LED light.
P5.js Code:
let LEDbrightness = 0;
function setup()
{
createCanvas(400, 400);
}
function textDisplay() //display text in the starting
{
text("PRESS SPACE TO START SERIAL PORT", width/2 - 109, height/2 - 5);
}
function draw()
{
background(255);
if (serialActive) //if serial is active
{
text("CONNECTED", width/2 - 27, height/2 - 5);
text("PRESS UP/DOWN ARROW KEYS TO CHANGE BRIGHTNESS!", width/2 -180, height/2 + 15);
}
else
{
textDisplay();
}
}
function keyPressed() //built in function
{
if (key == " ") //if space is pressed then
{
setUpSerial(); //setup the serial
}
else if (keyCode == DOWN_ARROW)
{
if (LEDbrightness != 0)
{
LEDbrightness = LEDbrightness - 20;
}
}
else if (keyCode == UP_ARROW)
{
if (LEDbrightness != 250)
{
LEDbrightness = LEDbrightness + 20;
}
}
}
//callback function
function readSerial(data)
{
let sendToArduino = LEDbrightness + "\n"; //add the next line to dimness counter
writeSerial(sendToArduino); //write serial and send to arduino
}
Arduino Code:
const int LED_PIN = 5;
int brightness = 0;
void setup()
{
Serial.begin(9600);
pinMode(LED_PIN, OUTPUT);
while (Serial.available() <= 0)
{
Serial.println("CONNECTION STARTED");
}
}
void loop()
{
while (Serial.available())
{
brightness = Serial.parseInt();
Serial.println(brightness);
if (Serial.read() == '\n')
{
analogWrite(LED_PIN, brightness);
}
}
}
Video and Photos for Exercise 1:
For exercise 1, since we were just getting started, the main problem was understanding how serial communication works. We had some kind of idea when it was being presented to us, but until we started working, we didn’t really know. Other than that, there weren’t really any specific challenges. We didn’t need to use the trim() method, we had one value coming in from the Arduino, which was the potentiometer, and we had some troubles at first, but once we casted it as an integer value (it’s received as a string), then mapped it to the width and made the mapped value the x-position of the ellipse the project was done.
You’ll notice in the image that there’s an LED. The LED was there to test whether or not there was power being outputted from the potentiometer. We added it while we were debugging.
Video and Photos for Exercise 2:
Like the previous exercise there was only one value that was being communicated between the arduino and the p5js code so it was fairly simple. The hard part was just getting it such that tapping it reduced the brightness value by a specific amount and increasing it by a certain amount.
3. Take the gravity wind example and make it so every time the ball bounces one led lights up and then turns off, and you can control the wind from one analog sensor
For this exercise, the code creation uses p5, where physics principles like gravity and wind influence the ellipse’s motion. The sketch also communicates with the Arduino, which can control an LED based on the object’s motion, specifically if it bounces.
P5.js Code:
let dragForce = 0.99;
let mass = 20;
let ledState = 0;
let velocity;
let gravity;
let position;
let acceleration;
let wind;
let force;
let bounced = false;
function setup() {
createCanvas(640, 480);
textSize(18);
position = createVector(width / 2, 0);
velocity = createVector(0, 0);
acceleration = createVector(0, 0);
gravity = createVector(0, 0.3 * mass);
wind = createVector(0, 0);
}
function draw() {
background(0,40);
// background(0);
// background(255);
if (!serialActive) {
fill(255);
text("Press Space Bar to select Serial Port", 20, 30);
} else {
noStroke();
force = p5.Vector.div(wind, mass);
acceleration.add(force);
force = 0;
force = p5.Vector.div(gravity, mass);
acceleration.add(force);
force = 0;
velocity.add(acceleration);
velocity.mult(dragForce);
position.add(velocity);
acceleration.mult(0);
ellipse(position.x, position.y, mass, mass);
if (position.y > (height - mass / 2)-30 ) {
velocity.y *= -0.9;
position.y = (height - mass / 2)-30;
ledState= 1;
if (!bounced) {
fill(255, 0, 0); // Red when just bounced
bounced = true; // Update bounce state
} else {
fill(255); // White otherwise
bounced = false; // Reset bounce state
}
} else {
ledState = 0;
}
}
rect(0,height-30,width,30);
}
function keyPressed() {
if (key == " ") {
// important to have in order to start the serial connection!!
setUpSerial();
}
}
function readSerial(data) {
if (data != null) {
// make sure there is actually a message
// split the message
let fromArduino = split(trim(data), ",");
// if the right length, then proceed
if (fromArduino.length == 1) {
let windCurrent = int(fromArduino[0]);
wind.x = map(windCurrent, 0, 1023, -1, 1);
}
//////////////////////////////////
//SEND TO ARDUINO HERE (handshake)
//////////////////////////////////
let sendToArduino = ledState + "\n";
writeSerial(sendToArduino);
}
}
Arduino code:
int ledPin = 5;
int potPin = A0;
void setup() {
Serial.begin(9600);
pinMode(LED_BUILTIN, OUTPUT);
// Outputs on these pins
pinMode(ledPin, OUTPUT);
// start the handshake
while (Serial.available() <= 0) {
digitalWrite(LED_BUILTIN, HIGH); // on/blink while waiting for serial data
Serial.println("0"); // send a starting message
delay(300); // wait 1/3 second
digitalWrite(LED_BUILTIN, LOW);
delay(50);
}
}
void loop() {
// wait for data from p5 before doing something
while (Serial.available()) {
digitalWrite(LED_BUILTIN, HIGH); // led on while receiving data
int right = Serial.parseInt();
if (Serial.read() == '\n') {
digitalWrite(ledPin, right);
int potValue = analogRead(potPin);
delay(5);
Serial.println(potValue);
}
}
}
Video and Photos for Exercise 3:
Understandably, this was the hardest of the 3. We first manipulated the code given to us (which had the wind and ball code). We changed the wind global variable in much the same way as the first exercise: The potentiometer value was mapped to the wind variable. The hard part was the bouncing. There was a point during the exercise where we felt we had written everything correctly, and after going through the code together, we couldn’t see what was wrong. We made a variable called bounced and had it such that inside of the if statement, which would be called upon when the ball was supposed to bounce, the variable would be the opposite of what it was previously (if true then false, if its false then true). We then realized we were initializing the bounced variable inside of the draw function. We made it a global variable, and then it worked.
