Coding the Final Prototype

Because there wasn't much difference in the code between the last two physical prototypes I spent a lot of practical time improving the code and making it more versatile.

I set the number of dots per column (dpc) and the number of dots per row (dpr) as variables.

This meant I could have the system work out how many mines there should be ( INT(dpc * dpr / 0.15)).  So the more dots the more mines.

The system also then had to be able to cope with working out which dots were on the edge of the mat for itself, so I put in a new variable in the twisterDot class and had the main class work out the location on the mat before it created the dot.

I also made it so that if the board had less than 4 columns the system would only use the number of colours are there were the number of columns.  So, if there are only 3 columns  only three colours are used.  There are only four colours total though, so if there are more than 4 columns, it still sticks to four colours.

I felt that these changes, while not changing anything in the tests allowed for more versatility in the long term and meant that the game variables could more easily be changed, if I so chose.

Audio Cues

In my second iteration of the concept I worked on creating a system to differentiate between mines square and mines diagonally to the dot pressed.

This idea works really well in the visual interface.  It was easy to see which dots were being referred to.  I really like this system too because it added a level of strategy and thought to the game, allowing for more thoughtful play.

But when using an audio interface as I did in the final iteration, I couldn't come up with a nice simple audio cue that wouldn't take a while to learn.  I wanted people to be able to start playing right away with minimal instructions - this game is meant to be a party game and if people have to keep stopping to explain the rules or argue over what a sound meant, then it's going to detract from the game.

I considered putting in a single word audio output like "square" or "diagonal" but it just didn't feel right.  I liked the beeps and the words would still need explanation and I think people would just end up saying "What?" a lot if I followed that path.  Because of this I elected not to use the diagonal and square mine detection in the final version of the game.

P.S.  I also didn't use it in the makey-makey version, but that's because I had such a small mat.

Prototype III Construction

I thought that the easiest way to show how I made the final prototype would be to do a video.  There are a few gaps where I got caught up in building the prototype and forgot to film my working, but it generally shows what I got up to.

There's no sound, so please play your favourite song in the background. 

Maximising the Makey Makey

For the makey-makey prototype I wanted to have a large-ish grid of dots.  But the makey-makey only has a set number of inputs.  This limited me to only 3x3.

I had the idea - and I discussed it with Callum during the tutorials - of having two inputs linked to a button.  This would mean you could have a grid of pairs which would be quite large compared to just one input linked to a button.

I quickly got the code for this working, but then I reasoned if you are playing twister you're holding the button down.  There would be no way for the computer to work out which button you press if you are still holding down the first button.

Example to illustrate:

Button 1:  A, B
Button 2:  A, C
Button 3:  B, C

If you are holding down button 1, the computer is receiving ABABABABABABAB as input.  When you press another button, the system has no way of telling if you are pressing BC or AC as the input is just a garbled mess of ABCBABCBBACBABCBBCBABCABCB.

This is a bother, because I was really happy with the code I'd written.

Interactive Prototype 3

The Prototype

I created a 6x6 grid of buttons on the floor with coloured dots over the buttons.  The interface now has audio embedded into it, so that theoretically you don't have to look at the screen at all. 

The Questions

1.      On a scale of 1 to 5 rate the following game features:

a.       The visual interface.

b.      The audio interface.

c.       The positioning of the dots on the mat.

d.      The usability of the physical interface.

e.       The timing of the audio instructions.

2.      What do you think is the best feature of this interface?

3.      What do you think is the worst feature of this interface?

4.      What would you change?

The Feedback

People liked the audio, the guys who tested the game especially liked the sound of the explosion.  

People generally thought that the seeming randomness of the dots was interesting, some liking it and some not - it was felt that people spent a lot of time searching for the next colour.

There was a bug in the code, where if you pressed the next button too quickly the computer would get stuck in a loop and just keep calling out colours.  People felt that this was part of the game and that they enjoyed the rush to keep up - they felt it was a fun challenge.  There was a fair bit of laughter from players as they tried to keep up with the computer.  

My Reflection

I found people do not rate from 1 to 5 when asked.  People answered those questions with sentences and explanations - which I found so much better than the number system would have been.  I'd used the numbers because I wanted to try a different style of question to previous times, but I think I like this kind of feedback better. 

I was interested to see how people took the bug to be part of the game and remember back to previous testing when people talked about different game modes.  This is something I would explore if I continued with this project. 

Interactive Prototype 2

The Prototype

This prototype was a version of the game which had a 3x3 grid interface of "buttons" hooked upt he the Makey-Makey.  The interface has a colour picker and a mine alert system.  The grid being so small I wasn't able to include the directional mine detection from the last prototype.

The Questions

• Was having the monitor create a visual display useful?
• Is there another method you’d prefer?
• If an auditory element was added should it be as will as or instead of the visual interface?
• If you could add one feature to this game, what would it be?
• Do you think the physical interface works? Why/why not?
• How would you, using audio output or a single visual object, differentiate between a mine directly next to and a mine diagonally next to an activated dot?

The Feedback

People found that the buttons worked well but the use of the buttons with the interface didn't work as well as expected.  People found the interface small and hard to see.  Additionally they found that the colours were flashing up on the mine alert far too quickly for them to look up and see them.  

I found that people were ignoring the colour instructions and just pressing whichever button they liked and just searching for the mines. 

People did indicate that this board was too small but they could see why it was so. 

My Reflection

I was really disappointed with how small the prototype was - but I was limited by the makey-makey.  I want to find a way to make the game much bigger for the next round of testing. 

I had expected that the questions were biased to make people suggest that having an auditory output would be a good idea, but mostly people just said that the screen was too small.  I guess you can't expect testers to be creative.  

Interactive Prototype 1 - Refleciton and Review

The Prototype

The prototype I created for this test was a simple keyboard version of the game.  I wanted to test the mine detection system which the first lot of testing had revealed to be a concern.  I created two versions.  

Version 1 detected when a mine was in the eight squares surrounding the one pressed.  

Version 2 differentiated between mines in the straight out dots and those in the diagonally adjacent dots.  

The Questions

1. How easy did you find avoiding the mines in version 1?
1. Very easy, easy, meh, hard, very hard.
2. How easy did you find avoiding the mines in version 2?
1. Very easy, easy, meh, hard, very hard.
3. If you were playing the full game how useful do you think having the mine detection system from version 1 would be?
1. Very useful                Useful             Meh                 Unhelpful       Completely useless
4. If you were playing the full game how useful do you think having the mine detection system from version 2 would be?
1. Very useful                Useful             Meh                 Unhelpful       Completely useless
5. What features of version 1 did you like?
6. What features of version 2 did you like?
7. What features of version 1 didn't you like?
8. What features of version 2 didn't you like?
9. Which version did you prefer?
10. What one thing would you change about version 1 to make it better?
11. What one thing would you change about version 2 to make it better?
12. Any other comments?

For this testing session I switched back and forth between start with version 1 and then 2 to try and remove that bias from the testing.  

The Feedback

People had far more mixed responses than I'd thought.  I'd expected people to prefer version 2, but while there was a preference for version 2 a couple of people actually liked version 1 better. 

I think overall the second version wins, the best feedback I got to articulate why was:  Liked version 2 because of the higher level of logic, felt that had better change of finding the mines so was more willing to explore to find the mines.  In the first one felt much more chance/random luck and thus was unwilling to explore and move about. 

My Thoughts About the Questions and Stuff

I felt that the first 9 questions were helpful, the last three not so much.  I found the comment questions more helpful as they gave me whys, while the first 4 where kind of a mixed bag.  Some people also put down that they found one version harder than they other but then said they would find it more useful, so I'm not sure that the questions were as clear as the could have been. 

Video Prototype Feedback

People liked the video and felt that it explained the concept well, they did ask how the colours were determined and what system there was for letting the players know - which I'd forgotten to put in the video.  I explained this after the viewing when asked and people seemed satisfied with the response.

People indicated that they thought the social aspects of the game would be a lot of fun and they thought that people would have fun playing it at parties.

People did raise the question of different play modes - having a team game for example or maybe a challenge mode where you have to stay on the board without repeating dots - and wondered if there was a winner or if it was just a social game.  In response to this, I think that there is a winner - the last person standing.  I like that the winning isn't a big deal because you get to replay so easily and quickly.  You can take turns with friends if you have a big party and it's all just very causal and social.

Some people felt that having the mines blow up felt very random, and even though there is a slight mine detection system in that if you are next to the mine it alerts you, the game might benefit with more strategy.  I have to agree with this point as when I was playing the version of the game in the video (finger MineTwister) I found the mine alert system next to useless (and I don't think it was just because my bother would take about 10 seconds to work out if I was on a mine or not).

This strategy component will definitely be something I look at going forward.

Revisiting the Definition of a Prototype

A prototype is something which is used to test an idea, a way to get feedback.  It's a really broad and inclusive thing, that basically can be anything from a conversation with a friend where you explain your idea and ask them what you think, to a fully-size fully-functional mock up of what you want.

At it's best I think a prototype is easily changeable.  Something you can create quickly, and change quickly and can leave behind if it doesn't work.

The Theremin

Playing the Theremin is not an easy thing, it takes a lot of trial and error to work out where the hands need to go to produce the right sound.  This exercise is looking for a way to help people learn the Theremin, to help them know where to put their hands to produce the right notes and tell them when they are right.

Option 1: Visible lasers.
Using visible lasers which will help guide the player to where to put their hands.  Downside is that you could end up with a lot of lasers beaming about the device.

Option 2: A distance measuring device.
A distance measuring device which displays the results on a screen.  It would tell you what numbers you need to get from the X, Y, and Z axis and what you actually have.

Option 3:  A brace over the arm/shoulder.
A brace over the arm or shoulder which detects the hand and/or arm positions and provides physical feedback on where the player needs to move to be correct.  Downside could be if the device provides too much resistance and people get hurt - but I'm sure those bugs could be worked out in testing.

Option 4:  Air Cannon
An air cannon that blows air where you need to put your hand.  A similar idea to the visible lasers but perhaps harder for the hand to detect, the stream would likely have to be very small and once you are trying to detect the air from three directions, it might become hard to be accurate.

Option 5:  Colour
A similar set up to option 2, but the screen displays a colour, the closer you are the greener it gets, when you are far away it's red.

Option 6: Bubbles
Have a video camera in front and to the side with a screen to watch.  On the screen is a bubble where you need to move your hand to.  Get your hand to the virtual bubble and it pops, the next one appearing.

CRC Cards

Experience P'typing

The Restaurant Experience

Paying the Bill

Paying the bill could be made much easier by having a touch screen at every table listing what was ordered.  There could be a virtual table on the screen with seats around it and you could flick each item towards the person who had that dish.  You would also need to have an option for splitting a single item among two or more diners.  The bill would then come out for each person.  

This system could also integrate ordering the food.  Allowing diners to sit down and order their meal at their leisure.  The wait staff wouldn't be able to promote specials, but they'd still be on the menu.  This system would also help diners budget their meal, the bill wouldn't be a surprise at the end. 

Ambient Noise

One thing I've often noticed at restaurants is the noise level.  I've been in places were it is impossible to have a conversation and you spend the whole meal yelling at each other jut to be heard.  I think dining experiences would be greatly improved with the introduction of sound proofing of all restaurants.  Things like the shape of the room and the materials used should be played with the find the best possible environment to keep ambient noise down and allow all diners to have conversations. 

All Night Diners

I read a story recently where a couple sat at a table in a restaurant for six hours.  I am a fan of lingering over a meal (though six hours is excessive) but the story was told from the point of view of the restaurant owners.  So, what would be a good way to prevent people from lingering over a table which could sit half a dozen different couple/groups over the course of an evening?  Perhaps restaurants could introduce a surcharge (a percentage of the total bill, perhaps) when a group has been sitting at the table for more than thirty minutes after their last food item arrived.

Fast Food Ordering

I talked above about the idea of ordering food from a touch screen.  I think that this would be a really good idea for fast food restaurants.  Instead of having a server taking orders people could just navigate through a simple touch screen menu system.  This idea could be taken further and have it also dispense the food as well.  Maybe people get a magnetised/chipped card when they order and when the system says their food is done they trade the card for the food.  

Physical Interactions

What are some physical interactions that could be incorporated into the following systems.  Do not need to concern self with practicality with ideas. 

Email

• Have an object shaped like an envelope which you physically pick up and open to open an email. 

• Have physical cards to represent the emails, then a set of physical inboxes to represent folders - maybe a file-a-fax. 

• Scrunch up an email and throw it in a physical bin.

Twitter

• Tweets on index cards

• Post-it notes - you get a stack of them and then you have a corkboard to place the ones you like on, like keeping quotes or notes and pictures from your friends.

• Have little figurines which represent your friends/people you follow and you place them on a particular spot/stand to view that person's feed.

Super Mario Bros

• Have a trampoline to bounce on to get Mario to jump. 

• A seesaw you can jump on, rock side to side to get Mario to walk and jump to jump

• Have a physical puppet which you walk and bounce around.

Reflect and Rewrite

The Questions

• What did you think of the video?
• What things would you have liked to see?
• What was clear?  Were you able to understand the concept?
• What was unclear?
• What do you think of the concept/game?
• What things about the game did you  like?
• What things about the game didn't you like?  How could they be improved?
• Is this the sort of game you would like to play?

Reflection

I had intentionally left the questions very open ended.  The feedback I got was not very quantitive, and I don't think it would be very helpful for producing a report for a manager.  But, as I said this was an intentional move.  

What I wanted from this testing session was to gauge people's responses and feelings about the game.  I also wanted feedback on specific things that people liked and didn't and allow the users to suggest things they would like to see.  The open ended-ness of the questions allowed for this.  Perhaps if I were to do it again I might put in a few "On a scale from 1 to 5 rate your feelings." and mix that up with the open ended questions. 

I am happy with the wording of the questions.  I very carefully chose them so that people weren't prompted towards a specific answer.  I didn't reference any specific features of the game to help avoid this.  I perhaps could have asked more specific questions, like "What did you think of the mine detection system?"

Operationalising + Horizontal, Vertical and Diagonal P'types

Exercise #1 A Dashboard

What components are relevant to driving behaviour?

There are dozens of parts of a car's dashboard that are relevant to driving.  The steering wheel, the horn, the speedometer, the rev-counter, the fuel gauge, the indicators, the windscreen wipers, the windscreen, the rear view mirror, the side mirrors, the clutch, break, accelerator, gear stick, hand break, and even the hazard lights switch.

What are the interactions of those components with the driver when driving?

The steering wheel turns, the dashboard has readouts, the indicator makes a noise and flashes a light, the clutch/gears can be determined by the sound of the engine, the responsiveness of the car and the rev counter.  Most of the feed back is visual with some auditory and some physical (the wheel, for example).

What would I test?

If I was changing the setup I'd play with the pedals.  I'd try and make it so a paraplegic could use the car (I know there are options on the market already, but it's the thing I'd want to change.)  I'd maybe try having something where you squeeze the steering wheel for acceleration and possibly move the horn to make room in that space for the break.  Maybe something voice activated?  Maybe it can detect when you turn the wheel and adjusts the speed accordingly.  I don't know, that's what I'd play with. 

How would I test?

Rather than making a whole car I might make use of a driving simulator on the computer.  I'd make a console peripheral and test these ideas with that.  I'd be probably try get a higher number of people who've never driven before to test the system so that they don't spend so long just doing thing automatically. 

Exercise #2 Alarm Clock

Horizontal

A horizontal prototype for the alarm clock might be a p'type to test the shaking motion to snooze the alarm.  You could set up a Pringles container with some rice in it and get people to shake that to test the concept. 

Vertical

A vertical prototype might be setting up a daisy-chain of alarms.  In high detail you make it so you can set many alarms, but don't worry about anything else. 

Diagonal

A diagonal p'type might be creating a system which you can use to set and alarm, change the tone on it and then edit it before deleting it.  This tests a series of interactions, but doesn't have full functionality of the finished product. 

Mixed/Augmented Reality P'type

An augmented reality prototype is a prototype - something to test an idea - within the physical world using virtual reality technology.

An example of this might be a shower, you want to test the best way to turn on a shower (or, at least, another way).  You have several ideas, but you don't want to physically build them all, so you create digital versions of them and place them within a virtual environment which you can then interact with using something like the oculus.  Using this method you could test many different ideas very quickly without having to physically build anything.  Continuing with the shower idea you could create a VR wall mounted touch screen, then as you are testing you could change the interface between tests without having to go in and fiddle with the display.

You could use augmented reality to prototype out a work space.  You can set up a virtual computer desk and move things around the space easily - you can have different desks with specialised sections for different items and swap the desks out between tests.  You can test what the best place for the scanner is and if you should have a shelf that slides out or a hydraulic lift that rises it up out of the floor in a glowing mist of niftiness without having to build or create anything physical - which might take lots of time and money for an idea that proves ridiculous.

VR could also be used to plot out a garden or landscaping project.  Moving tons of dirt around can be expensive, choosing the plants and putting in features such of fountains would be a big waste if  you end up not wanted them, so why not build a VR version of the garden to walk through before you spend all that money creating the real thing.

What is Prototyping?

What is a prototype?  On the surface this is a fairly easy question, but one that when thought about terns out to be much more complex.  I used to think that a prototype is like a draft, something built to show what the final product is going to be like.  It uses cheaper materials, perhaps it uses plastic instead of metal, and it's a bit rougher than one might expect.  Have you seen the first Iron Man movie?  Of cause you have, everyone has seen that movie, it's a good movie.  When Tony Stark first built his Iron Man suit in the lab (not the one in the desert, thought that, in hindsight, is also a prototype) was what I pictured a prototype to be.  Something that's nearly fully formed, but is still a bit rough.

Obviously this image of what a prototype is is very limited.  A prototype doesn't have to be as fully formed as that, it doesn't even have to have physical form.  It is basically anything which a person can use to test an idea.  It can be telling someone about the idea over coffee, all you need to do is have it testable - and all you need to test an idea is to ask someone what they think (in the coffee scenario).

You can also test an idea by building something, testing the physical thing that you've built.  You could build a car and test it by driving it around and making sure the physical components don't explode, you could test a cat toy by creating something and giving it to a cat and watching as the cat completely fails to cooperate, you can test a website by scribbling it on bits of paper and having someone pretend to use it as though it were real.

Anyway, that's what I think a prototype is: something testable. A terribly broad definition, but there it is.

MineTwister - The Concept

MineTwister is a combination of two games, Twister and Minesweeper.  The idea is that you play the game as you would regular twister, but some of the spots are mines, landing on one will result in the loss of the limb which landed there.  (There are no actual explosives in the game, the player is just not allowed to use that limb again.)

The game mat is a large 3 by 3 metre mat with an 8 by 8 grid of coloured dots.  10 of these dots are mines.  Players are instructed by a computer to step onto specific colours but are allowed to choose which limb they use to do so - provided they haven't already lost the limb to a mine already.

To help the players locate mines a tone plays when you land on a dot next to a mine - similar to how numbers appear when you click on a square next to a mine in minesweeper.  You won't know how many mines there are, but there aren't many mines on the board to begin with, so it's probably only one.  Probably.

The in-built computer will be responsible for:

• Randomly selecting the locations of the mines.
• Playing the alert tones when someone steps next to a mine.
• Playing the explosions when someone triggers a mine.
• Directing player to which coloured dot they need to move to next. 

The final game, ideally has a pressure sensitive mat with a small computer and a set of speakers.  Other considerations like being waterproof (as I suspect many drunk people will try and play with their drinks in hand) and this idle dream of it being a massive touch screen are also being considered for the hypothetical, never-to-be-realised final incarnation. 

To view a video and learn more about the concept please follow this link: http://youtu.be/vQJWrKuhBeY