Wednesday 11 November 2015

Prototype 3: Testing Session Results

Since I missed the testing session on Monday - was doing my best to get on top of my exam on Maths on Tuesday - had to arrange my own testing session with friends/family. 

I had a total of 6 testers/3 pairs of people.






The two hypothesis that I had were: 
  1. 2 people or kids will find a way to self-organize to get the correct answers to the questions asked
  2. In pairs people will enjoy playing the game more than if they were to play alone. 
Both hypothesis were correct. People did enjoy playing as a team more than playing on their own. From my observations - somebody would take a leading role and say - who has to do what:
  •  "You step on 9, I'll step on 1" and this is how we'll do that
The other person would follow the instructions. 

When playing on their own - one of the participants was a 6 y.o. girl - she had no difficulties figuring out how to play the game at all. 

Here are the comments from test participants: 






100% of participants preferred to play as a team/with a friend more - it was more fun for them.

Test Limitations: 
  • most of test participants were adults, this is a limitation
  • occasionally some of the buttons wouldn't work - that's technology limitations
I do think that the game is successful, useful and, perhaps, could even be successfully built and released to the general public.






Saturday 7 November 2015

Interactive Prototype 3: Description

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 game even more fun - I made the game social so that it can be played by 2 kids simultaneously.

Hypothesis 1: 
  • 2 people (or kids) playing the game will find a way to self-organize to get the correct answers to the questions asked 
Pass/Fail: Most people got their questions right. When they don't get their questions - they are just fooling around intentionally.

Hypothesis 2: 
  • In pairs people will enjoy the game more than if they were to play alone. 
Pass/Fail: Will be tested in the form of close-ended question by users doing self-reporting. If users report that they enjoyed the game more when playing together - this would mean that the hypothesis is right. Optionally - I could do 2 rounds of testing - 1. test as 2 people then 2. test with the same testers as 1 person - and then do self-reporting.

A complete survey is available here: Game Survey



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 

Game Logic:
Assume the question is how much is 11 + 4 and the correct answer is 15.
- Wait for 1 user to stand on 1... 
- Wait for 2nd user to stand on 5... 

If a user stands on 1 - and then on 5 - the answer is correct or stands on 5 - then on 1 - the answer is correct.
If a user stands on a wrong answer - "Zero" the results, say - wrong answer.

Since 2 people cannot stand on 2 numbers simultaneously, during the testing process I will be providing users with instructions. 

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

Final Look & Feel









Testing Process
1. Invite 2 participants to test the game.
2. Give background information: the game is for kids to help them learn Maths. When answering questions - one person has to push on one number, another person has to push another number.
3. Ask them to start the game and play 1 round. Observe participants and take notes.
4. Offer 1 participant to play on their own. 
5. Ask 1st participant to fill out a survey. 
6. Offer 2nd participant to play on their own.
7. Ask 2nd participant to fill out a survey.   

















Sunday 25 October 2015

Week 13: Planning the Next Prototype

Time to think through the logic of the last prototype for the course in detail, as I have several days to get it done.

So - I'll be testing Social Interactions and assume that 2 people will have fun playing the game and will find their way around as a group. 

Hypothesis 1: 
  • 2 people (or kids) playing the game will find a way to self-organize to get the correct answers to the questions asked 
Pass/Fail: Most people got their questions right. When they didn't get their questions - they were just fooling around intentionally.

Hypothesis 2: 
  • In pairs people will enjoy the game more than if they were to play alone. 
Pass/Fail: Will be tested through self-reporting in the form of close-ended question. If users report that they enjoyed the game more when playing together - this would mean that the hypothesis is right. Optionally - I could do 2 rounds of testing - 1. test as 2 people then 2. test with the same testers as 1 person - and then do self-reporting.

Fixes from the last prototype: 
- record voiceover under the coat :) 
- make numbers bigger in size 

Game logic changes: 
The main issue is to find an event that would indicate that the answer is correct, since 2 numbers have to be pushed. 

How I could do that: 
Assume the question is how much is 11 + 4 and the correct answer is 15.
- Wait for 1 person to stand on 1... 
- Wait for 2nd person to stand on 5... 

If a person stands on 1 - and then on 5 - the answer is correct or stands on 5 - then on 1 - the answer is correct.
If a person stands on a wrong answer - "Zero" it, say - wrong answer.

+ I need to change the questions I ask so that I end up with 2-digit responses. 

A problem that 2 people cannot stand on 2 numbers simultaneously. This is a limitation that I cannot find a way around. So, I guess I'll have to explain this to people in the form of instructions.

That's about it.







Tuesday 13 October 2015

Thinking About The Next Prototype

Time to start thinking about the last prototype.
So, the instructions are as follows:

Final Prototype: 
1. Refer or redesign the original prototype
2. Dark horse - do something that seems impossible
3. Add new features: test something not tested yet

Prototyping Process: 
- go through evaluation/testing sessions
- take some ideas from it
- SoD (decisions made)

As I brainstormed the different options for the prototype - I decided to stick to Option 3 - adding new features and test something that is not tested yet.

So, what I am planning to do is - make my game MathsFun social, make it work for 2 players. How I think it should work: 2 people could step on different numbers for the solution (for number 10 - one would step on 0 and another one would step on 1).

I'd focus on "social" part of it for testing.

In order to make it work, I'd need: 
- change problems that result in solutions with at least 2 numbers (so, from 10 and above)
- the physical component of the game doesn't require much changes, it can stay pretty much the same (but rebuilt again).

Looks buildable and feasible to me :) And also fun when doing the testing :)) I'll need 2 testers at a time. 

Week 11: In-Class Exercise - 3D Movements for Theremin

This week we received quite challenging tasks. At least for music illiterate people, since I don't play any musical instruments :)

So, our first task is: 

1. Generate concepts for consistently reproducing and generating 3D movement in space that allows for the musical composition to be accurately played on Theremin.

So, the regular notes look like this:


Source: Wikimedia

Theremin operating principles according to Wikipedia are as follows:

The theremin is distinguished among musical instruments in that it is played without physical contact. 

  1. The thereminist stands in front of the instrument and moves his or her hands in the proximity of two metal antennas. 
  2. The distance from one antenna determines frequency (pitch), and the distance from the other controls amplitude (volume). 
  3. Higher notes are played by moving the hand closer to the pitch antenna. Louder notes are played by moving the hand away from the volume antenna. 
So, in order to come up with instructions on how to play a certain composition on Theremin - we basically need to translate the regular notes to 3D signs/gestures people would use when playing a composition on Theremin. 

Here come the concept ideas: 
1. Translate each regular note into gesture language on Theremin and come up with a gesture for each note
2. Translate each regular note into gesture language on Theremin + play with one hand
3. Translate each regular note into gesture language on Theremin + play with 2 hands and a head :) 

The second part of a task is to come up with a Pugh Metrix to compare concepts against each other.

So, here are the criteria I believe are essential when it comes to playing musical compositions on Theremin. 

1. Learnability 
The shorter is the learning curve - the better 

2. Fun in the process 
The more people have fun when playing the instrument - the better it is. 

3. Complexity 
How complex the system is - whether a lot of things are required for initial use

4. Number of mistakes people make when playing
The fewer mistakes people make when playing an instrument - the better it is. 

5. Implementation cost
The cheaper the system is - the better. 




Wednesday 7 October 2015

Interactive Prototype 3: Testing Session Results

We did a testing session this week - it was a lot of fun. I really enjoyed testing my prototype even though it wouldn't always work as intended and sometimes would go crazy :) Mainly because Makey-Makey inputs were sensitive - so when a user stood too long on one input - my ActionScript would count that as a wrong answer. 

Overall the feedback was great: 

1. It's pretty fun, I like the idea that I need to balance at the same time as completing each math problem. My only issue is that sometimes the problems and answers don't link up e.g. when the sum total is equal to 8, 9 would work.

2. It looks amazing that i cannot wait to play the final concept. only glitch i have so far is the incorrect answers(response?) and also the touch sensibility may need to adjust.

3. It is funny. I believe that it not only bring lots of fun for children, but also can help children do the basic math question. like addition, subtraction. If the circle can flashing, it will be more appealing.

4. It is fun to play for kids as the touch points are decorated in colored and shiny papers. You may want to add a background music behind the game:) overall the game is super great I think!

The prototype was tested by 5 people. 

User 1





User 2


User 3

User 4

User 5


Here is the fully completed survey:


Now back to the hypothesis I was intending to test: 

#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.

I'd say that the hypothesis is validated, user were willing to play longer and they did enjoy 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.

As a result of observing users test the game and their feedback, here is a list of changes that can be made to improve game experience:
  • add music to the background
  • make numbers bigger in size
  • randomize numbers
  • think and come up with a solution: how to make touchpoints less responsive (I mean so that if a user stands on the same button for a bit longer - ActionScript doesn't accept it as a wrong answer - and therefore the voiceover doesn't get confusing)
Other ideas to be considered: 
  • make the game social - and test it on several users - so that people self-organize to get answers right 
  • come up with a logic that adjusts fast to current user complexity level







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...