Week 12 - Revisit Definition of a Prototype

As I learn more about digital prototyping and apply more of the concepts to my own prototype, I gained more and better understanding of prototype. One of them is as you creating a prototype, you should not worry too much about how it looks, and try to polish every detail to make it look nice. The priority is the concept and the functionality of the prototype, it should demonstrate the major functionality of the final product, but not necessarily in a fancy way. It can be pretty simple, and the elements that would occur in the final product can be represented by simple symbol or object. As long as the user can test if the functionality demonstrated works or not, we should not be worrying too much about adding good looking pictures, fancy animation and well polished images.

Moreover, at the beginning of this course, I thought that prototype should be the tool to test and implement the established functionality of the product. But as I go further in this field, I found out that actually prototype not only help us testing the functionality we decided, it also help us deciding what functionality to add, to abandon or to modify.  And this done mainly through the analysis of user testing and feedback, then refine the prototype to fulfill users’ demand. A perfect example is how we do our prototype suite, the video prototype is like a blueprint which describe how the game mashup is going work, what functionality it will provide. But we do not necessarily have to stick to the initial plan and change nothing. The users testing session is like a brainstorming, testers gave me a great amount of good advice and pointed out what I needed to refine. So I modified some functionality and abandoned some redundant feature, but also added something to make the game more exciting.

Looking at my initial description of my understanding of prototyping, I think it was pretty general and I will definitely add the new understanding above to my dictionary.  Another thing I want to change is I said the test and refine process of a prototype should be done as many times as needed. Considering that prototyping is a good way to reduce the development period of a product, it should be important trying to make every test effective. For instance by using good feedback collection method, refine the questions that will be asked to the users. Therefore I want to change my words to “the test process should be well established to reduce developing cycle”.  Reason why I came up with this idea is that in my building up the prototype suite, we got limited times to test our prototype and get feedback, then refine the concept and prototype. So I had to work very hard on deciding what functionality to demonstrate and what questions to ask. In reality it’s the same, a company may need a product to be on the market in a certain period of time, so developers have to really make every testing process count to make sure the final product can be established on time.

The Theremin - revised

According to Lorna's comment, I realized that my concepts were not really comply with the requirements, so I worked out new concepts.

Concept 1
My research indicated that playing music on a theremin is basically adjusting the distance between the performers hand and the antenna, to generate the melody the performer wished to play. In order to allow the performer to play a piece of composition consistently and accurately, there should be some visual reference to help the performers while they move their hands around. For example we can build a meter that tells the performer what kind of distance between their hand and an antenna generate what kind of sound. And we can either made a physical representation of the meter or we can use the Holographic Laser Projection technology to project the meter in front of the performer so they can use the reference while playing.

Concept 2
Another idea is to increase the range of which theremin can recognize the performers movement, which means the performer can move there hands within a larger range. And the theremin will be less sensitive to the movement of the hand, that is saying performer need to move a relatively longer distance to change the tone, this will make it easier for the performer to play a piece of composition accurately and consistently.

Comparison

To compare the prototypes, which are the implementation of the above concepts, we can use the Pugh Matrix. We can use the laser harp model in the example video as the baseline. 

Accuracy

The easiness for the performer to consistently play the key he or she want.

Practicability

Does the movement needed for playing the composition easy to achieve and can be done consistently.

Reliability of the system

Weather the system can be used to play compositions consistently without having problems.

Complexity

Weather the system is very complicated that hard to learn how to use it to play, and play consistently.

• 
  

Week 11 exercise - The Theremin

Concept 1

Create a group of small water flow falling out of a series of pipes. Electric signal can be detected when the performer’s finger interrupt with the waterfall, this will create a sound. Each water flow represents a key on a piano or a string on a string instrument such as harp. This is a very interesting way to play music, it may create good visual impact to the audience.

Concept 2

Another idea is using simple hand up and down movement to control the tone, there will be a visual meter to help performer gain the right tone. When the performer moves his or her hand up and down, some mechanism can detect the position of the hand and generate a corresponding sound, this is a very easy way to play a composition, but can be hard to control.

Comparison

To compare the prototypes, which are the implementation of the above concepts, we can use the Pugh Matrix. We can use the laser harp model in the example video as the baseline.

Accuracy

The easiness for the performer to consistently play the key he or she want.

Practicability

Does the movement needed for playing the composition easy to achieve and can be done consistently.

Reliability of the system

Weather the system can be used to play compositions consistently without having problems.

Complexity

Weather the system is very complicated that hard to learn how to use it to play, and play consistently.

Interactive Prototype 2 (Makey-Makey prototype) - feedback of testing

During the test session, I had 8 people tested my Makey-Makey prototype of The Hurt Locker. And through their feedback on the questionnaire, I found out that none of them have ever played any bomb defusing game which allows them to physically cut the wires. This indicates that this should be very fresh and fascinating to them. Also their response has proved my worry about the size of the computer interface was totally unnecessary, the vast majority of the tester think it is appropriate. Moreover, all the tester agreed that the feedback provided by the computer interface was clear.

However, some tester did point out that making the wire layout totally random, which make it a game of luck do reduce the fun of the game to some extent, they hope there is some way they can speculate which wire is which. An existing solution of this problem is that the locations of different wires are set by your opponent, and you can ask your opponent one true or false question before you cut each wire to help you locate the bomb or disarm wires. But I will still be working on an alternative solution, which involves the computer give the user feedback to help locating different wires, something very similar to the mechanism in the game Minesweeper. I will finally decide which solution to implement and demonstrate it in my final prototype.

Besides, some tester think the game is so quiet for this kind of topic. I will definitely add some sound effect to reinforce the feedback user get when they cut a wire, hope this will help keeping them excited. I was also suggested that there should be some clear signal to show up when the user loses or wins the game, for instance some animations. I will also be working on that to make a prototype that is fully functional and usable.

Restaurant experience exercise

As a customer, I found that sometimes it can be a bit hard to get attentions of waiters or waitresses in a restaurant, because they are wiping the table or serving food and doesn’t look at you. Meanwhile, you cannot just call them loud or snap your finger, which may annoy people sitting at the table beside you.  Basically you have to wait until they look at you and wave to them.

Me myself had been working in two different restaurants as a waiter, I did not realize that you have to be really good at multitasking to be a good waiter before I got those two jobs. I had to take customers to their table, take the order, serve food, get bills for them, and sometimes those tasks all comes together at the same time. I really had to work my head around those tasks and sometimes I may not notice that some customers are trying to get my attention.

The experiences described above are actually subject to some internal and external factors. For instance, if there are only one or two small group of customers, it is pretty much impossible for a waiter not to notice that they need help. However, when it is peak hour during diner time, all the tables are occupied and seems everybody needs something, then it may make those experience even worse.

Another factor that may affect the experiences is the characteristic and capability of the manager. One of my managers has very bad temper and he shouts at us when we do something wrong or we do things in a way that he doesn’t like, even if everybody would think our way is better. This makes everybody is a bit stressed while working, and we were forced to follow his immediate order regardless what we are doing at the moment. This made it harder for us to fulfill the customers’ needs as much as possible.

Technologies can be introduced to those circumstances to make it easier for the waiter to identify who needs help. For example a button can be placed on each table which can be pressed by the customer when they need help. The computer of the restaurant gets the signal and automatically queues the demand when multiple customers need help. On their portable device, waiters and waitresses can see whom at what table needs help. This is very similar to the system Apple use in their retail stores.

The use of this technology may highly reduce the chance of customer waiting impatiently to be served, or waiters do not remembering who should they serve first and get stressed. The experiences of both stakeholders are enhanced.

To test this technology, I would choose a busy restaurant at a busy dinner time, first do one test without this technology and get some feedback from waiters and customers. Then implement the technology and do another test another evening, get feedback from the stakeholders to see exactly how much better or worse their experience gets.

Makey-Makey prototype documentation

As I started building my Makey-Makey part, or the physical part of this prototype, my initial ideas was to get all 9 keys on Makey-Makey, which are controlled by the 9 wires on the panel, connected to the ground on Makey-Makey.  To do this, I had to use a lot of play-doh on my wire panel to make sure all the wires are connected to the ground, and make it easy to reset the wire panel after each test.

In this way, the computer will read it as all 9 keyboard keys are pushed down simultaneously, when a wire is cut, the computer will detect a key-up event which I coded in as3.

However, I found it is possible that the play-doh to be ripped through when I try to reset the wire panel, and this will cause wires failure of connecting to the ground. And more importantly, my test indicated that the computer cannot detect the key-up event of some keys when all the 9 keys are pressed simultaneously. I tried to modify my code but I could not get it working no matter how I change the code. I then searched web and found out seems our computer keyboard are not capable of test that many keys pressed or released simultaneously, so I started thinking about variations on the physical prototype.

Finally, I decided to connect the scissors to the Makey-Makey ground and when cutting a wire with the scissors, it is inevitable that the scissors and the copper will be connected at one moment and disconnected afterwards, the computer will read this as a key pushed-down and released. Therefore, the computer will easily capture the key-up event and give back the reaction I designed.

What's more, I don't even need the play-doh in this way which will make the prototype more tidy and easy.