To be honest, the group project I’ve participated in, which is about online space-transcending chatting room, has little to do with my midterm project. But fortunately, it did trigger my understanding of interaction, which is: the core of interaction should be output that generated based on the given input. Through the circle of input and output, all the components in a interactive system work together towards a certain goal. That is to say, a interactive system needs a clear intention and the ability to process inputs into outputs to accomplish this intention. As for the original inspiration of our midterm project, it should be “The Book of Answers”, a book of which there’s a short word or phrase on each page. It feels like everyone is encountering enormous problems that are hard to solve or don’t have a specific and clear answer; in that case, something that can give these trapped people inconclusive answers to their questions and leave them a chance to fathom the answers by themselves would be a master stroke. Considering that thought as the very original purpose, we built this project “Boxes Know Answers”. Comparing to the initial book, our project allows more space for interaction: though they are both based on randomization, a microphone set to listen to your troubles seems way more trustworthy than a dumb book which is displayed on a shelf and clearly knows nothing about your concern. In other words, our project gives those people who’re in a dilemma an exit to let out concern, something that you can pour out your own bitterness, even though the answers we offer are as blurry as the book’s.
We used a microphone-shaped object, a sound sensor, a distance sensor, some servos, and several wooden boxes to build the whole project, with no hints except for an “ASK ME” close to the micro phone. You talk to the mic about your problems, and three seconds later, a box would open, with the answer laser cut on the lid. We consider that process pretty straightforward so actually we don’t need lots of tips to tell the user how to use it. However, as a matter of fact, the original version is far different from that. At the very beginning, it occurred to us that we can use Magic Conch, a concept from Sponge Bob, as the project’s theme. In that cartoon, once you have any questions, Sponge Bob would say “Why don’t you ask Magic Conch?” Of course the conch can give them back nothing but the echo of air, but the listener could “understand” the echo from their own perspective and work out an answer by themselves. That’s almost the very image of our project thus we 3D-printed a plastic Conch and several wooden boxes, connected them together with an Arduino board, and set a button to trigger the sound sensor starting to record the question, which was finally rejected by us.
Why? If you were at the user test, you would definitely know why. Though the idea of giving a answer surprised lots of users, the whole project causes much confusion. First, the conch is always connected with listening to it rather than speaking to it, which made many users lose their ways. Besides, the conch’s style wasn’t quite suitable for those wooden boxes and seemed abrupt. What’s more, because we didn’t solve the problem that how to make boxes automatically open by steppers, the project used LED lights to show which box was the answer and the user must press the button and after the result was shown, open it manually, which is not as cool as the idea we offer. In short, the user test made us realize there were still so many problems to solve and details to improve.
So, as a result, we basically redid the whole project. Firstly, with the help from a fellow, we used servos rather than steppers to rotate and open up boxes. Plug a servo in the circuit and use analogWrite to give instruction 0° and 120°, it’s pretty much done. Now there won’t be any LED lights guidance, and as long as the program figure out an answer, a corresponding box would open by itself. And then we built a wooden microphone and put a distance sensor and a sound sensor in it: once somebody get close to the mic, the distance sensor would get a sign and give instruction to sound sensor to make it start to work. In that way, we could get rid of the button and make the process more automatic! And it comes to the code part. To be honest, it’s quite easy:
#include <Servo.h>
Servo myservo;
int VIPin = A0;
int DIPin = A1;
int DisThreshold = 80;
int V_upper_bound = 127;
int PinOut[] = {3,5,6,9,10,11};
void setup() {
Serial.begin(9600);
}
void loop() {
//Generate a box number according to the audio received.
int DisInput = analogRead(DIPin);
int BoxNumber = 0;
int Tri = 0;
if (DisInput >= DisThreshold) {
Tri = 1;
}
while (DisInput >= DisThreshold) {
int VoiceInput = analogRead(VIPin) % 6;
BoxNumber += VoiceInput;
DisInput = analogRead(DIPin);
delay(10);
}
if (Tri > 0) {
BoxNumber = BoxNumber % 6;
Serial.println(BoxNumber);
myservo.attach(PinOut[BoxNumber]);
delay(3000);
myservo.write(120);
delay(7000);
myservo.write(0);
}
delay(1000);
}
The last part of the whole project is to assemble everything together. Sounds east but when we practiced it, problems started to turn out. When we pasted the box with servos and start the program’s uploading, some boxes’ lids rotated into a super weird angle. And then we realized that we didn’t paste the most closed box with the servo’s angle 0°. A fatal fault. So we had to re-paste most of them. Since there are only six available servos from the equipment room, we designed six corresponding boxes only. Then we found out that the 5V source on Arduino board can provide enough electricity for five servos so we borrowed two adapters, directly connecting to the 220V source (and because of that, during the final assembling, we burnt out one servo thus there were only five boxes in the final version). After solving all these problems, we used big cardboard, drilled several holes on it (to contain those wires) and fixed our project on it. Below is how it works.
Our goal is to offer an answer to those who’re confused with their problems. Without any doubts, we achieve this goal. But the project still has something not align with my definition of interaction. I expect the process of interaction to be more precise and determined but now, in our project, though the input(distance and sound) drives the output’s formation, they are still not logically related and the only binder between them is randomization, which doesn’t quite fit in my definition. As for the users’ interaction, I think because our project is quite forthright so people would barely misunderstand that, while something worth thinking about, raised by another classmate, is that we need to specify or give instructions on which kinds of problems could be asked; or else, somebody will ask “what’s the weather like” and the boxes just give him/her an ambiguous answer, which is certainly unacceptable. If I could have had more time, I would work on how to put the answer on the screen rather than on boxes’ lids, just like the magic ball 8. From the failure I had,I realize that no matter what project you’re working on, you need to save enough time for the practical test in order to avoid the case that has to finish the testing part, which is utterly crucial, in a rush.
After all, I still consider our project’s interaction as immature, for the reason mentioned above; but the process of creating that did inspire me about one thing: if we want to design a really efficient and user-friendly interactive work, we must consider from a ordinary person’s perspective, who knows nothing about our project but has intense need for some certain purpose. That is to say, put our feet in users’ shoes, think about how to help a “rookie” easily understand our design and help him/her to achieve goals. Think, and think as an idiot, that would be the key.