Wednesday 30 September 2015

Prototype 3: Physical Prototype


Physical prototype for game MathsFun fully simulates the game. MathsFun is an interactive game that makes it fun for kids to learn basic Maths skills. The concept of the game did not change and is available in this post.  To make the prototype interactive and fun to use in the physical world - voiceover was added. Thus, the physical input prototype provides a complete sensory experience for users in real life context.

#1 Hypothesis to Test:
Kids play at least 3+ game sets (maths questions of 10).
How much time kids spend playing the game is a direct indicator of game quality. If users "stick" to the game and return to play it later - the game is successful and user experience is engaging. Since the prototype is close to the final version of the game - this is the crucial hypothesis to be tested that makes or breaks the game.

#2 Observations: 
This time I'll be observing users to test: size of numbers, size of circles, quality of voice over to notice any design issues that need fixing. Since the prototype is "high fidelity" - it's not the time to pay attention to design details. To collect this data - I'll be using Google Survey with open questions and just regular observations and making notes.

Game survey is available here.




Makey-Makey Inputs Structure
When a user types W - in fact - it means 0. Change from numbers to letters is necessary to make the prototype work with Makey-Makey.

Here is the basic input structure to make it work on Makey-Makey:
W -> 0
A - > 1
S ->  2
D -> 3
F -> 4
G -> 5
Up -> 6
Down -> 7
Left -> 8
Right -> 9 

Rules for voice recordings and changes in ActionScript: 
1. Play Greeting, if a user didn't step on 1 and "connect" buttons - play Greeting Wait
2. Wrong Answer - Play On no!, then - NoNoNo, then - No!
3. Correct Answer - Play Oh yes!, then - Yes!, then - Well done
4. Once a set of questions is finished - offer to Play again
5. Each Maths problem has a voiceover - to make the game more interactive.

File saving has been removed from the game, since it was used to test hypothesis in the ActionScript version of prototype.

Updated Class Diagram was generated using Crocus Modeller.


Putting It All Together


Makey-Makey Contact Prototype Versions

While coming up with the most effective solution for connecting numbers with Makey-Makey - I did 2 additional prototype versions.




Sensor Button

Membrane Button

I decided to stick to a version of Membrane button - since testing prototype barefooted would be ineffective.


Materials Used 
- cardboard - foil- wires- glue :-) - Makey-Makey

Final Look & Feel


Testing Process
1. Invite participants to test the game.
2. Give background information: the game is for kids to help them learn Maths.
3. Ask them to start the game and play 1 round. Observe participants and take notes.
4. Ask if they would like to play more. 
5. If yes - see point 3.
6. If no - ask to fill out a survey on Google Docs.


Wednesday 23 September 2015

Week 9: In-Class Exercise - Experience Prototypes

This week we were asked to go deeply into experience prototyping which helps designers to present a solution and test its features by asking users to actively participate in the process. 
After getting to know some key peculiarities of this type of prototype, we were given a practical exercise: we were asked to review the current experience people have in restaurants and consider ways of improving it with new technologies.
Here’s the list of questions to be discussed for 3 stakeholders - customers, waiters and chefs:
  1. What is the existing experience?

  2. What external/internal factors impact on the experience?

  3. What aspects of the existing experience could be enhanced/augmented/supported with technology?

  4. How would introducing technology into this context change the experience?

  5. What experience scenarios might you test with the technology?
Let’s look at the experience of each stakeholder.

Customers


The existing experience: Customers are given some kind of food and drinks in exchange for money.
External factors: Weather, time of the day, surrounding atmosphere, other customers, attentiveness of the restaurant staff, quality of food and service, speed of providing services, etc.
Internal Factors: Mood, familiarity with a place, level of relaxation or rush, patience level, appetite, intoxication level, etc.

New technology ideas: Since in rush hours it sometimes takes too long to order a dish, customers can be provided with tablets with a special app installed. The app allows to just click on particular dishes to order them.  Customers are provided with a device where are buttons next to each dish. This seems to be easier as it saves customers’ time (usually spent on waiting for the waiter to come) and minimizes the interaction with waiters (that may be a real challenge for some people). Besides, it eases the waiter’s work  as there’s no need to come to customers each time they want to place an order.

Waiters


The existing experience: Waiters take orders, bring them to chefs and then provide customers with prepared meals.
External factors: The number of people waiters need to serve to, time of the day, the number of other waiters on the shift, etc.
Internal Factors: Mood, experience level, loyalty level, attitude to people, enthusiasm for the job, etc.

New technology ideas: Since waiters are usually busy, they do not always see if customers have left the table. As a result, when new customers come, the table may be not cleared yet, and they need to wait. To solve this problem, weight sensitive chairs can be created: when the chair is vacant for a particular period of time, the waiter is notified via a special app that a table needs to be cleared. This will make the service faster and, thus, will lead to having more customers. The idea can be tested perfectly well in malls or fast food restaurants as these are the places with the biggest flow of customers. 

Chefs


The existing experience: Chefs prepare food for customers.
External factors: The quality of food provided by suppliers, kitchen layout and tools, professionalism of the supporting staff, the number of customers they need to cook for, etc.
Internal Factors: Professionalism level, motivation, mood, stress level. etc. 

New technology ideas: Since popular restaurants have a heavy workload, it may be useful to divide the cooking process into several steps, and then combine these steps if similar ingredients are to be cooked. To simplify and ease the chef’s work, it’s possible to create an app that shows the chef what dishes should be cooked and divides the roles of participants. For example, if there are 4 persons in the kitchen, one of them is notified that he/she needs to cut vegetables for this and that dishes, the other one needs to fry potatoes, etc. When each one gets the tasks via an app, the chef doesn’t need to waste time on sharing the tasks. He/she can concentrate on particular things and gets ready ingredients. 




Monday 21 September 2015

Week 9: Makey-Makey Prototype Implementation Plan


So, I did some thinking about what and how I will build for my Makey-Makey prototype.
The basic interface will be as follows. Appears to be pretty straightforward and easy to understand.


The only thing I still need to figure out is the exact size of the mat - so that it fits kids who are about 1m height... ? Need a bit of research here.

 Things I'll need to fix in my ActionScript: 

1. do voice recordings for interactions:

- intro/greeting: Hello there. Do you want to play? Step on foot sign & 1 to get started.
If he/she didn't step on it within 10 secs - Still here? Step on foot sign & 1 to get started.

- well done/oops - mistake: Oh no!, No-no-no..., N-o-o!, ; Yes!, Yeaaah!, Oh yes!

- end of game: Well done! Do you want to play again? Step on any number for Yes.

If a user is making mistakes on the go - come up with some fun voice recordings, like:
- No, no, no... or Yes! Yeaaaah! .. :-) to add some emotion

2. change inputs - use letters/arrows instead of mouse clicks

Materials I will need: 
- rubber mat for the foundation/first layer
- foil for connections
- some wires to increase the length of the Makey-Makey wires
- something to cover it on top & hide all the wires

and that's about it :)







Friday 18 September 2015

Week 8: Playing with Makey-Makey & Twister Inpirations

We've started playing with Makey-Makey this week. You can come up with some cool physical interactions with Makey-Makey.

As I am thinking about the best way to come up with a prototype for my Maths game - digging into Twister inspirations done using Makey Makey is really handy. 

Here is an example:




Image Source: Makey Makey Mash Up 

Here is another cool one - with images/instructions on how to use it (like feet allowed :-) 
When building mine - I probably will come up with some instructions as well. I bet it'll be more fun to test it :-) 




I might even come up with my own theme/style for it :-) 

I am excited about this prototype :-) Mainly because finally I'll manage to come up with something decent and lack of skills in coding/ActionScript/editing a video will not be a constraint. Excited to come up with something great and fun :-) 

2nd Prototype: Interpretation of Testing & Results

Testing session has been finished and here comes interpretation and analysis of the results. I had 9 test participants - all of them played the game. My main concern or limitation of the testing approach is that all of the participants were adults rather than kids.

Let's start analysis with validation or invalidation of the 2 initial hypothesis.

Hypothesis #1: 
Increasing game complexity in sets of 10 questions will sustain kids interest in the game and make it fun. 
Pass Criteria: A test will fail if a test participant fails to answer correctly from the very beginning until the end of the set. Thus - waiting for 10 questions to pass to assess the results would be too long, as kids get dissatisfied with continuous failure. 
Fail Criteria: Results are distributed evenly - and participants failing the first 2 questions may provide correct answer at the end of the game.

What I observed: 
The first 2 test participants failed to answer correctly on the first few questions (mainly because they didn't figure out the instructions at once). So, I'd say that the hypothesis passed, as the participants did recover closer to the end of the set of 10 questions.

Limitation: some participants answered incorrectly just to see what will happen next (in the middle of the game)

Conclusion: Sets of 10 questions are an efficient way to give out Maths tasks.

Hypothesis #2: 
On average it will take a user 3 - 5 seconds to respond a question. If it takes more than 5 seconds - a user is unlikely to provide a correct answer at all and there is a need to change the question or provide support/positive reinforcement.
Pass Criteria:
If answering a question takes longer than 5 seconds - and users do not provide correct results - the hypothesis is right.
Fail Criteria: 
If answering a question takes longer than 5 seconds - and users still provide correct results - the hypothesis is wrong. 

What I observed: 
Test participants answered all questions correctly. So, the hypothesis is either valid or - the game has to be tested on kids.

Considerations for future: I probably should have changed the concept, since it's difficult to evaluate test results on adults while the game is designed for kids.

Here are Participant results:
Participant 1:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 295sec; Wrong answers: 8; Accuracy: 55%;
Round: 2; Complexity: Easy; Questions: 10; Time spent: 24sec; Wrong answers: 0; Accuracy: 100%;

Participant 2:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 201sec; Wrong answers: 8; Accuracy: 55%;
Round: 2; Complexity: Easy; Questions: 10; Time spent: 29sec; Wrong answers: 5; Accuracy: 66%;

Participant 3:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 392sec; Wrong answers: 0; Accuracy: 100%;

Participant 4:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 108sec; Wrong answers: 0; Accuracy: 100%;

Round: 2; Complexity: Difficult; Questions: 10; Time spent: 26sec; Wrong answers: 1; Accuracy: 90%;

Participant 5:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 29sec; Wrong answers: 0; Accuracy: 100%;
Round: 2; Complexity: Difficult; Questions: 10; Time spent: 22sec; Wrong answers: 0; Accuracy: 100%;

Participant 6:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 40sec; Wrong answers: 3; Accuracy: 76%;

Participant 7:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 28sec; Wrong answers: 0; Accuracy: 100%;

Participant 8:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 23sec; Wrong answers: 0; Accuracy: 100%;

Participant 9:
Round: 1; Complexity: Basic; Questions: 10; Time spent: 30sec; Wrong answers: 0; Accuracy: 100%;

Round: 2; Complexity: Difficult; Questions: 10; Time spent: 21sec; Wrong answers: 0; Accuracy: 100%;

Round: 3; Complexity: Difficult; Questions: 10; Time spent: 20sec; Wrong answers: 0; Accuracy: 100%;


Week 8: Email, Twitter, SuperMario --> Getting Physical

This week task is to come with physical interactions for Email, Twitter and SuperMario. 
I’d approach the task by thinking How, When, and Where people use them as well as user needs. This then gives insight
for the best design solutions. 





Email: 
User Needs:
  • Find out as soon as possible about a new message
  • Easily respond/Forward
  • Sort/Store for later/Delete/Mark as Spam/Flag

Physical solution: 
Since most people communicate on the go - this has to be some kind of wearable device (glasses, watch, ring, bracelet) or an app. 
The easiest way to communicate on the go is by voice. So, touch/tap to check email, perhaps, integration with headphones via Blootooth or phone would be handy. 

Pre-set voice commands could be handy. 

If a person is wearing glasses or sunglasses - reading mail directly from glasses should be useful. If combined with commands/speech recognition when a person is responding to email - could be helpful. 


Twitter: 
User Needs: 
  • Communicate with others in short messages (140 symbols or less)
  • #be heard / read with a hashtag, retweet
  • respond to messages

All of this has to be done on the go.

Similar with email - I’d say that is a person could read its twitter from glasses and get notifications for things that matter to him/her (for example -when he or she was mentioned or retweeted) and communicate via voice commands on the go - altogether that could be handy. Speech recognition would also work great in this case, as this would speed up/improve the communication process.


SuperMario:
User Needs: 
  • Walking left and right
  • Jumping
  • Opening
Since it’s a game - I think that augmented reality type of extension would work best. There is no need to read “on the go” as in the previous 2 cases, but rather go with the flow - and experience to the fullest. So, some devices that extend your movement - wearable for hands to go left or right, step/jump on a spot, and, perhaps, glasses to view the game in 3D.  


Image credit:
https://www.flickr.com/photos/rahulrodriguez/9162677329
https://ca.wikipedia.org/wiki/Super_Mario_World
https://pixabay.com/en/twitter-tweet-twitter-bird-312464/

Monday 14 September 2015

Week 8: Testing the Prototype

Since my testing is based on exact data based on how participants perform - I don't really have a questionnaire - since I'll be using .xls to interpret the data. The instructions are also fairly simple - just hit the button once a user is done with the game.

Instructions to participants:
- Make sure you hit save button after you played the game.

I will then use the data from files to interpret the results and derive conclusions.

Hypothesis #1: 
Increasing game complexity in sets of 10 questions will sustain kids interest in the game and make it fun. 
Pass Criteria: A test will fail if a test participant fails to answer correctly from the very beginning until the end of the set. Thus - waiting for 10 questions to pass to assess the results would be too long, as kids get dissatisfied with continuous failure. 
Fail Criteria: Results are distributed evenly - and participants failing the first 2 questions may provide correct answer at the end of the game.

Hypothesis #2: 
On average it will take a user 3 - 5 seconds to respond a question. If it takes more than 5 seconds - a user is unlikely to provide a correct answer at all and there is a need to change the question or provide support/positive reinforcement.
Pass Criteria:
If answering a question takes longer than 5 seconds - and users do not provide correct results - the hypothesis is right.
Fail Criteria: 

If answering a question takes longer than 5 seconds - and users still provide correct results - the hypothesis is wrong. 

Sunday 13 September 2015

ActionScript Prototype: Description



The ActionScript prototype is an interface for the physical game MathsFun. MathsFun is an interactive game that makes it fun for kids to learn basic Maths skills. The concept of the game did not change and is available in this post. 

The purpose of the prototype is to test core functionality of the game that influences user experience and interaction. 

I've picked 2 most risky UX/game logic hypothesis for the tests: 

Hypothesis #1: 
Increasing game complexity in sets of 10 questions will sustain kids interest in the game and make it fun. 

Hypothesis #2: 
On average it will take a user 3 - 5 seconds to respond a question. If it takes more than 5 seconds - a user is unlikely to provide a correct answer at all and there is a need to change the question or provide support/positive reinforcement.

The first screen a user sees - is simple. A simple Math question is asked - and a user should pick the right answer.


In case a mistake is made - we offer a user try again. The results are calculated.



There are 3 sets of questions (10 questions in a set, 3 levels - Basic, Easy, Difficult). Once a user passes the first set of 10 questions - either a more complicated or an easier version of questions is asked.




The results of the game are shown on the screen. A user is offered to save a file. Then - a simple .txt file is generated. In case a user wants to play again - a new game will be served. Based on performance in the first game - either a more complicated or a more easy set of questions is served.



The results in the text file can then be used for interpretation and analysis. They'll be used to validate or invalidate the 2 main hypothesis I made when building the prototype. 




The final class diagram was generated directed from the code using a free trial of Crocus Modeller.











Week 7: Working on Prototype

As I was working on the prototype - I came up with an updated classes structure. The current version is available below


And - as I was coming up with game description, revisited survey questions from the video prototype - I had to change the logic a bit.

Here are my final hypothesis:

Hypothesis #1: 
Increasing game complexity in sets of 10 questions will sustain kids interest in the game and make it fun. 

Pass Criteria: A test will fail if a test participant fails to answer correctly from the very beginning until the end of the set. Thus - waiting for 10 questions to pass to assess the results would be too long, as kids get dissatisfied with continuous failure. 

Fail Criteria: Results are distributed evenly - and participants failing the first 2 questions may provide correct answer at the end of the game.

Hypothesis #2: 
On average it will take a user 3 - 5 seconds to respond a question. If it takes more than 5 seconds - a user is unlikely to provide a correct answer at all and there is a need to change the question or provide support/positive reinforcement.

Pass Criteria:
If answering a question takes longer than 5 seconds - and users do not provide correct results - the hypothesis is right.

Fail Criteria: 

If answering a question takes longer than 5 seconds - and users still provide correct results - the hypothesis is wrong. 

The main change is that I have to store game results somehow - since my analysis is purely close-ended questions. So, I decided to add the option to "Store results" to make sure I get the data I can interpret later.

Will be wrapping it up soon... 

Wednesday 9 September 2015

Week 7: Revisiting Survey Questions for Video Prototype

Our task was to think about survey questions again, see if there were any fallacies in them that made the questions less effective.

So, here we go!

1. Explain what the game is about and who it is for
Question Type: Qualitative

2. How does the game work? 
Question Type: Qualitative

3. Was narration clear and understandable at all times? 
Question Type: Qualitative

4. What do you think could be improved in the prototype and the game? 
Question Type: Qualitative

5. Would you recommend the game to your friends who have kids? Why or why not?
Question Type: Qualitative

6. Were there any logical/structural fallacies? 
I believe no. At least from what I know about doing testing/asking questions. 

I also think that this type of questions (open ended, asking to re-word what you've learned from the prototype) are the best ones to ask to test if the audience understood the idea. So, I do believe they are effective for their purpose given the type of prototype that was tested.

In my next prototype (interface using ActionScript 3.0.) I planned to focus on and test just a few narrow things (core game functionality). So, testing will be quantitative.

Sunday 6 September 2015

Week 6: Action Script 3.0.: Getting Ready to Code a Prototype

I'm refining my prototype, thinking about Classes, their Attributes (Variables) and Abilities (Functions).

This is also what we've done in the Lecture in class this week. Planned out classes, variables and functions.

First, let's focus on hypothesis and UI.

1 hypothesis to test: It is a good idea to increase game complexity after a set of 10 questions.
Pass/Fail test: A test will fail if a test participant fails from the very beginning until the end - thus - waiting for 10 questions to pass to assess the results would be too long.

2 hypothesis to test: On average it will take 3 seconds to respond to a question.
Pass/Fail: Responding to a question over 5 seconds - means the game should be slower.

Here is the basic screen for the prototype:



And a few more screens to interact with users:


And a few more...


And another one...



What is I will need for the prototype:

Events: 
1. on-click by mouse
2. on-click (keyboard numbers)

Lists: 
1. Questions (contains questions, their difficulty level, and answers)
2. Results (stores game results)

Class 1: Numbers
Public variables:

  • Value (0 - 9)
  • Position (x, y)
Private variables: 
  • height
  • width
  • color


Class 2: Questions

Functions:

  • give me next question (picks and gives out the next question to user - 2 complexity levels from .xml file - if less than 8 right - easy group and if more than 8 - complex group next).
  • check answer (boolean, gives out 2 answers: Correct! or Try again!)


Class 3: Store results 


    Functions: 
    • add results (adds results to a file)
    • show time (displays on screen how much time it too user to respond to questions)
    • show score (displays user score for a game) 
    • next level (serves a set of questions based on user performance)

    That's about it for now - probably will change as I dig into it...