Test video: https://drive.google.com/file/d/1VjWs9XvbtSQxb0JJEkcue5Dtv2v6pDmz/view
Conception and Design
From the beginning throughout the end, we have always wanted our project to be accessible and available for everyone, so we tried as best as we can to eliminate physical contact and interactions that require precision (ie. keyboard and mouse). This doctrine is what we have always stuck to so we made a few decisions around it. The major decision we had is to use Leap Motion. After we borrowed it from the ER and tested it, we found that it is very delicate and sensitive, easy to operate for almost everyone, and more importantly, it does not require physical contact. We used several very BIG pushbuttons to make it easy for the user to push. Also, since the Leap Motion has a detection boundary and we wanted to be visible to the user, so we had a fabricated frame to indicate the boundary.
During our talk with Young, he pointed out that we should focus of one type of disability instead of expanding our user to everyone with limb disabilities. Therefore, we decided to make this project targeted for people with hand disabilities. We then made a few alterations to our project, for example, we adjusted the code of Leap Motion to make it detect only the wrist rather than the entire hand.
Actually, in the beginning, we wanted to use a joystick to control the brush instead of leap motion because we thought it is easy to use a joy stick even for people with hand disabilities. However, after we studied the Xbox Adaptive and consulted our friends, we found joystick is even not easy to use for people without disabilities, so we abandoned it and turned to leap motion.
Fabrication and Production
The fabrication and production process was generally smooth. One of the biggest trouble was the save feature. Our design is that pushing a button would save the current frame into the computer. We used the “saveFrame” function in processing, but every time we press the button, it would automatically save more than one frame. We studied for hours and found that it was the serial communication that caused it. When we press the button, several signals would be send to processing during the contact time to save multiple frames. To solve the problem, we modified the button code so that only one signal would be sent when the button is released. Also, during the user test session, Rudi suggested that we should add a thumbnail feature. So we spent another few hours figuring out how to make it happen.
Despite all the adaptions to make our project better, the real significant thing happened during the process was the change in our project context and target user. During the user test session, both Rudi and Young pointed out that our project didn’t look like a device specially designed for people with disabilities. What they said made us carefully rethink our project, and we found that there were actually better ways help people with disabilities draw. For example, we could design a drawing game on Xbox and use Xbox Adaptive as the input because it is a manufactured product and must have been tested thousands of times. Our project looked more like a fancy device for amusing and entertaining people without disabilities. I mean, it is not that people with disabilities may find our device friendly, but that the device is might not be the best choice for them.
Therefore, after user test, we decided to make our project an educational one, which educates people about people with hand disabilities. We want the project to educate people that, even with many measures to ensure accessibility, it is still difficult for people with hand disabilities to create art works. To make that happen, we used tape to bind the user’s fingers and put a red sticker on their wrist in order to make them pretend they have hand disabilities. In addition, we added a QR code on the canvas which directs to a Wikipedia page of hand disabilities.
Conclusions
Our initial goal was to make a project that enables people with hand disabilities to draw free from restraints, but in the end, we changed our goal to make an educational project that educates about the hardships that people with hand disabilities are facing. Despite, that we think our project generally aligns with our definition of interaction, which is a process which 1) involves two or more actors, 2) at lease two of the actors should be cognitive systems, 3) requires input, processing, and output, 4) gives clear and proper feedback. It will raise people’s awareness of hand disabilities and empathize with them.
The real important lesson I myself get from this experience is that, to build a project that really targets your user, you should really find those users to give advice even before you design it. We concluded that the reason why people didn’t think it is a device for people with disabilities is that, we did not consult people with disabilities nor have them to test it. If we had more time, we will probably stick to our initial goal and invite people with disabilities to talk about what they really need, and invite them to test our product.