Anger Flanker, an arcade game-inspired interactive space that allows users to vent their anger, is finally done developed. Previously, we were focusing on keeping all things together, including finishing the code, creating new graphics, and making enclosure. In these past 7 days, we were still continuing on finishing up everything. Also, we improved some features and making the enclosure more sturdy. This past week, we were thinking to sell this sort-of-game to some companies, so that their employees have more spaces to release their stress. Seriously, not kidding.
User Testing #2
Last week, we did our last user testing. That time, we were almost done with the content and fabrication. So, we could expect real experience from the users.
The user testing went well. It was surprising that the users were very excited to play with it. They smashed, screamed, even jumped. Also, they kept interacting with it. Even though we didn’t tell them what to do in the beginning. We’re glad that the design is pretty good. We didn’t have to explain everything to the users. But still, we got some insights to keep improving our project.
- Users kept interacting without thinking what to do.
- Users knew what to do without being explained at first.
- They need to know how hard they’re punching. So that they could measure how strong they were to keep going.
- A lot of users don’t know what’s happening when they’re screaming.
- Some users didn’t feel comfortable to scream.
- Users felt good after they were playing with it.
- Some users broke the enclosure.
What We’ve Improved
There were a lot of insights from the last user testing. This past week we were trying to improve several things to make it more interactive. We weren’t just focus on make the enclosure real solid, but also to improve user experience.
Make Sure Circuit Connected Perfectly
Last time the circuit wasn’t connected perfectly, and that affected the user experience, because sometimes the sensors didn’t work. So, this week we made sure all wires connected perfectly, by soldering and taping them. For the sensors, as Tom suggested, we put rubber feet on top so that it will give pressure easily to the sensors.
More Durable Enclosure
Since this is a product which people hit, we needed to make sure that it’s absolutely solid. That’s why we used more solid plywood. We also used nails and screws rather than just glued them.
Easy to Replace Parts
“We need to hide the circuit”. But not just hiding it, we need to make it easy to be replaced, if something wrong happened. That’s why we made an opening on the back, so that all cables can go through it. Also, we needed to make an enclosure for the circuit. To make sure it’s more safe.
We want to make a product that has good user experience. So we need to think about every detail that the user will interact with. It might be a small difference, but we need to differentiate between user smashing or pressing. Our objective is to make user hits to control the game, not to press it. Yes, it would be cheating to press on it. So that we made some adjustment in the code.
Below is the diagram between force value and time, when user is smashing and pressing.
What we had previously was: every time the force value passed the threshold, it would activate one action, no matter if the user was hitting or pressing. It means that if the user was keep pressing, and the force value kept going up and down, it would activate the actions every time it passed the threshold. We didn’t want this happen. We wanted to make sure that if the user press on it one time, no matter if the force value keep up and down, it’s still considered as one action.
So that we needed to adjust the code:
- If the user hit it, it will activate one action
- If the user press it, it will still activate only one action. So that the user cannot be cheating.
We used timestamp in the code. We record the time when the user start touching the sensor, and when he releases his hand from the sensor. The time between touching the sensor will activate an action if it passes the threshold. We knew that smashing will make the value goes from 0 to some values and back to 0, then there will be a delay for the next smash. But pressing will make the value from 0 to some values, keep going up and down without delay. So we needed to handle it.
We adjusted the code so that if there’s a noise at the time the user’s pressing, it’s still counted as pressing, and only one action will be activated. It’s considered as a noise if the value going down and up passing the threshold in < 500 millisecond.
More about Anger Flanker? Visit our website (later, still working on it).