Evaluation of the Interactive Prototype 3

Outcome and Reflection

Before doing the survey, I briefly introduced the concept of the game to the user and introduced the new features added in this stage. I also told them how to use the physical input to play the game.

The outcome of the user testing and the reflection on each specific question are listed below.

Apparently, most people thought the current homepage was neater than the previous one. It is a good change to improve the user experience of the game interface.

Same as the last question, the majority of the users felt easy to select levels by drumsticks, which means the new physical inputs is easy to use. 

Most users thought the levels were suitable. This is further confirmed by my observations as most users felt easy and won the easy level but in a muddle while playing hard level.

It seems the 'restart' feature is not that welcomed as I expected. Despite that, the feedbacks regarding it are positive in general. Half of the testers thought they want to play more and the other half thought there was not much difference as before. It seems that the willing of replaying the game is depending on how much the players like the game, and to those players who really like the game, the new feature provides the solution to them.

Overall, it is a general question. Most users thought it did so I could draw a conclusion that the new features and physical inputs achieved the goals of improving the playability and UX of the game.

Most testers found it easy to play and said they were having fun. One bug was found when a tester was trying to select a level, which was really helpful.

Besides, someone mentioned the fragile foil again, this problem existed in the last stage. Since I could not find any substitutes, I tightly stick the foil on the bottom of the coke cans to make it not hollow so that the foil won't be that easy to break as before.

Several quite good suggestions for future refinement are brought up in the feedback.

• timer
• leaderboard (high score display)
• changes of the indication, for instance, having lights to show which drum to hit or making it blink before the drum number changes.

Effectiveness

The prototype and the testing session are both quite effective. I'm glad to see that most people enjoyed playing the game and had a positive feedback to the new features. 

The testing session helped me to test the new features and the corresponding physical inputs. The overall feedbacks are positive and constructive, some useful suggestions could be applied in the future game such as the timer, leaderboard, etc.

The observation of how the testers playing the game was fun. The same issues still exist, for instance, most of the users couldn't coordinate their hands well so they tended not to move the cannon, just wait for the aliens came and shoot. In general, what I observed is consistent with the responses in the feedback, which is a mutual confirmation of the testing result.

The testing protocol is not as detailed as before because this testing session focused on testing the new features and physical inputs added in this stage. Also, I remained the style of the survey of IP2, which contained more quantitative questions and less qualitative ones.

The feedbacks are thus concise and explicit.

Constraints

The game is near polished in this stage and the concept of the game could be easily understood in the stage. And yet there are still some problems. For instance, a tester found a bug while playing the game. It slightly affected the UX and testing process despite no other testers found the problem.

Besides, the operations such as 'moving' and 'shooting' could not be conducted at the same time. Perhaps it's because of the working principles of Makey-Makey that it'll stop working while two circuits are connected simultaneously.

Implications

For future codes, I'll add some of the features such as 'timer', 'score' and 'leaderboard'. Also, I will try to find out a feasible solution of the problem that the indication is difficult to perceive while the testers are playing the drum, which will definitely improve the user experience based on the feedback.

For future physical inputs, as I didn't change it in this stage, the implications remain the same. I'll try to find more solid materials to make it tough and durable. Also, I will try to make the interface simpler and neater.

For future testing sessions, from the feedback received, I think I've balanced the number of the qualitative and quantitative questions well for this prototype. I think I'll refer to this prototype's testing plan in the future stages.

User Testing of Interactive Prototype 3

The modifications in this prototype are mostly about the code. The physical input only changed a little bit. Thus, I won't mention the building process of the physical input in this post. 

The following photos are taken on the user testing session. Thanks for all the testers and the feedbacks.

Concept and Modifications of Interactive Prototype 3

Concept
The concept doesn't change much. You can see from the following two posts.

This is the previous concept idea:
http://startrekz.blogspot.com.au/2015/08/week3prac-arefine-game-mash-up-idea.html

The iteration in interactive prototype 2
http://startrekz.blogspot.com.au/2015/10/interactive-prototype-2concept-and.html

Interactions Modification
Apart from the drums, drumsticks, and gongs in the last prototype. Two more physical inputs are added in this stage, a 'replay' panel and three 'level selecting' panels. The player could use the drumsticks to tap the panels to choose a specific difficulty before entering the game. After the player wins the game, he could tap the 'replay' panel to play the game again. The interactions of the original physical inputs remain the same.

overall look

replay panel

select difficulty

Codes Modification
To incorporate the suggestive feedback received from the last stage, also to make the game more fun and visually comfortable, several new features are added to the game. The modifications are listed below:
1. Multiple difficulties for the users to choose;
2. A new class that holds the new homepage;
3. Replace the original schematic shapes to real icons of the cannon and aliens.
4. Add the restart function so the player could play the game again after it ends.

 new homepage

Evaluation of the Interactive Prototype 2

Outcome and Reflection

Before doing the survey, I briefly introduced the concept of the game to the user and then asked them to play the game. In addition, I told them how to use the physical input to interact with the game.

The outcome of the user testing and the reflection on each specific question are listed below.

From the pie charts, we can see that the concept got across well, and the physical inputs function well. In terms of the speed setting, it seems half of the user thought the speed of the cannon and bullets is a bit slow compares to the moving speed of aliens. I'll increase the speed in the next stage.

Based on the 4th and 5th question, most users found it not difficult to play the game and the physical inputs had enhanced the interestingness of the game. And from my observation, most users are more practiced after the first round. Besides, there're some major reasons that make the game difficult to play:
- eye-hand coordination.
- the random drum for shooting changes too fast.
- afraid to break the foils(materials) while playing the game.

From the design rationale, the essence of the game is the eye-hand coordination and it is also the most challenging part of the game. Therefore, I won't completely change the feature. However, I would probably add more levels in the game with different difficulty, varies in the frequency of changing the random index. In addition, in the future physical input, I'll use some more tough materials to prevent the drums break.

In terms of the potential problems of the current physical inputs, the testers all thought that the foils were easy to break so they had to be careful while playing the game. As for the desired features that could be incorporated in the future, many users suggested that I could add more levels. Also, they thought the cannon could move forward and back as well. Besides, they thought I can add some effects of tapping the drums. Those feedbacks are all inspiring and feasible, I'll try my best add these features to the future codes.

Effectiveness

The prototype and the testing session are both effective. And I'm glad to see that most people enjoyed playing the game. 

Although it is a brief version of the final game, it has already covered all the key interactions of the game. The testing session also helped me get some useful feedback that can be applied in the future game such as the difficulty levels, sound effects of drumming, etc. I also observed how each user holds the drumstick, how they beat the drum, how they coordinate both hands, and how they destroy the enemies. For instance, most of the users couldn't coordinate their hands well so they tended not to move the cannon, just wait for the aliens came and shoot. However, some more practiced and 'aggressive' users tried to chase the aliens and shoot to destroy them.

The testing protocol is not as detailed as the one of IP1. I found the survey of IP1 was too many for the user. Many testers just skipped 1/3 questions. Therefore, I removed some useless questions in IP1 and simplified it to just eight questions that focused on the evaluation of the physical inputs.

Constraints

Although I added new features such as winning message and some sound effects, it is still an unpolished prototype just has part of the functions. And the physical interactions are just an approximation of the intended physical interaction. The testers thus might not have a comprehensive understanding of the game and my general plan in the future. Fortunately, the game itself was intuitive so there was barely no constraint for the testers to understand or play the game.

Besides, due to the fragile foils, which wrapped around the paper cups and coke cans but leave the middle hollow, most testers are afraid of breaking them so they played the game carefully and lightly. Even so, the gong was broken after the user testing as someone accidently poked it with the drumstick. This really impacts the fun of the game.

Implications

For future codes, I'll add some of the features such as 'drumming sound effects', 'difficulty mode', 'real character icon'. Also, I will try to add a virtual drum on the screen, once the user beat a drum, the corresponding drum will have the effects to indicate it is beaten, which I believe will improve the user experience.

For future physical inputs, I'll use more solid materials to make it tough and durable. Also, I will use some fancy materials to make the interface simple and neat.

For future testing sessions, from the feedback received, I think I've balanced the number of the qualitative and quantitative questions well for this prototype. I think I'll refer to this prototype's testing plan in the future stages.

Building Process and User Testing of IP2

As I mentioned in the last blog, I used the drumstick idea to implement the physical interaction of the game. The user will play the game by beating drums and gongs.

Materials:

Paperboard

Paper cups

Coke cans

Straws

Foils

Wires

Tapes

Glues

Process

I use the two-layer paperboards as the base. The wires are hidden in the paperboards so it'll look neat and all other materials are built on the paperboard.

The paper cups, coke cans, and straws are wrapped with foils to simulate the drums, gongs, and drumsticks respectively. The drums are collected to the keys on the MakeyMakey while the gongs are collected to the left and right directions. The earth wires are collected to the straws so once the user beat the drums or gongs with the drumsticks, the cannon will move and shoot.

Special thanks to Lyndon for the brilliant idea. Thanks to Peter and all my friends for the tools and materials that I borrowed.

Interactive Prototype 2_Concept and Implementation

This is the previous concept idea:
http://startrekz.blogspot.com.au/2015/08/week3prac-arefine-game-mash-up-idea.html

Interactions
 The general concept of the game mashup, the gameplay, and the rules remain the same. The user will control the cannon to shoot the aliens with a random shooting key. When destroyed all the aliens, the user wins the game. However, for this prototype, we are asked to think of an innovative way to interact with our games or wearables. Thus, I changed the interactions of the game completely. Instead of the foot pad mentioned in the previous concept, 2 drumsticks (made of straws), 6 drums (made of paper cups) and 2 gongs (made of coke cans), all wrapped with foil and connected to the MakeyMakey, are designed and implemented to be the new physical input.

The drumsticks are the controller of the game. Just like beating a drum, the user will use the drumsticks to beat the 6 drums with indexes (1 to 6) on them. According to the index displayed on the game screen, the user hit the corresponding drum to shoot a bullet. In addition, the user could hit the gongs to move the cannon left or right to chase the aliens.

Codes Modification
To incorporate the suggestive feedback received from the last stage, also to make the game more appealing, I added some new features to the game. The modifications are listed below:
1. Increase the speed of the bullets and cannons.
2. Add the sound effects of shooting a bullet, hitting the enemy, winning the game.
3. Pop up a winning message after winning the game.
4. Change the position of the tiles to make the shooting key clearer to the user.

The experience of Interactive Prototype 1

This my own experience of the Interactive Prototype 1 that I want to share with you all.

1. Structure the code.
Before actually writing the code, we did an in-class exercise to think about the Classes, their Attributes (Variables) and Abilities (Functions) of our games or wearables, which was a key step to have a clearer idea of how to implement our concepts. Also, I found the learning materials, such as the pong game, are quite helpful for us to quickly familiar with AS3. I highly recommend you to study the code of the examples and figure out why the author structure the code like this.

2. Debug
The Photoshop Flash is not a good development environment as debugging is too hard and there are no detailed logs for the error. The most effective way I learned is to use trace statement to check if the code is executed to a specific line.

3. Fixing bugs
I implemented the majority of the functions but couldn't fix a bug of 'random shooting' feature. Everything seemed alright according to the code's logic. I spent a whole evening to discover why it didn't work and found the problem was caused by the 'Timer Event', but I still had no idea of how to fix it. The bug was solved by Peter eventually, he got rid of one 'Timer Event' (there were two initially) and it worked.

Besides, although I referred an example, it still took me about two days to add the 'restart' function for another game. As AS3 is just like many other programming languages such as C/C++ that have the main function, the sub-functions could not call the main function to loop the game, I had to write another two functions calling each other, using the main function as an entry. Once the game started, it'll execute the main function, then loop between the two functions and never break.

WK9_Exercise_Experience Prototype

Restaurant Dining Experience for Customers

What is the existing experience? 

- ordering food

- booking seat/ reservation

- find dining

- parking

- facility use: WiFi, add water, air-conditioning, waiting for the seat.

- pay, check the bill

What external/ internal factors impact on the experience?

1. external:

- decoration

- location

- car park

- views/surroundings/noises

- entertainment

- temperature

- food (flavor, time)

- price

- service

2. internal:

- mood

- personality

- gender

- age

- occupation

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

- App for finding car parks.

- use a mobile app to increase the efficiency to place an order

- a digital menu that shows the ingredients and energy of the dishes. It also can calculate the total energy of the food.

- provide an automatic pay machine on each table.

How would introducing technology into this context change the experience?

The new technology could facilitate the customer by promoting the service efficiency, such as the app for finding car parks or the automatic pay service. On the other hand, some technologies would create a better user experience, such as the digital menu that shows the ingredients and energy of the dishes.

What experience scenarios might you test with the technology?

The digital menu, for example, I'll ask a young female customer to order food and provide both the paper menu and the digital menu to her. Observe what menu she chooses, how she uses the menu and orders the food.

Evaluation of the Interactive Prototype 1

Outcome and Reflection

Before doing the survey, I briefly introduced the concept of the game to the user and then asked them to play the game. Besides, I did not tell them how to interact with the game at the beginning, some users thus were struggling with shooting the bullets. And not until then did I tell them how to shoot the enemy.

The outcome of the user testing and the reflection on each specific question are listed below.

From the feedback, apparently most people had a more concrete and intuitive recognition of the
game than the video prototype. Only two users felt confused about how to play the game and they both wanted some hints to guide the user.


Every user completely understood how to interact with the game and I was happy to see that. One user had no idea how to win the game, which had no relevance with the question but still worth consideration. I think I'll pop up a winning message after the player destroys all the aliens to tackle this problem.



From the pie chart, we can see that more than half of the users thought the attractiveness of the interactions of the game is just around an average grade rather than a full grade, some among those gave me very good suggestions.

- add a timer to count the game time
- add background music
- add a death state to the player
- create difficulty modes

According to the plan, the background music and 'death state' features are what I'm going to incorporate in this game at the refinement stage. The timer idea was good, which might increase the tension of a game to make it more exciting. The difficulty modes are also feasible and suggestive, I just need to develop varies types of enemies with different speed and firepower. This will also improve the user experience because the user will be given options to play the difficulty mode they want.



Problems
- bullet speed is a bit slow compared to the aliens' speed.
- display instructions when destroy all the enemies.
- the player can die.
These problems are completely the same as the problems mentioned in the last section. I won't expand them again.

Concerns of changing the interaction from keyboard input to physical input.
- use the characters instead of numbers
- provide a 'random' instruction on the screen that can be easily perceived even when the player is moving his body.
The second suggestion was really good because based on my observation, even after I told the user
how to shoot, some of them still having trouble pressing the right key. The reason might be that the key code is displayed at the bottom-right corner of the stage and not too big or bright to perceive. I would reconsider where and how to show the random key code in the future game design.

The overall impression of the prototype was good, and most users thought the prototype had grasped the essence of the game concept. However, most of the users thought the prototype is at a medium complexity. I've asked Peter if I need to add more features at this stage because I also thought it was simple, but he told me the complexity was enough for this assignment. Thus, I decided to ignore this feedback.

4 out of 5 testers who had answered the last question misunderstood the question. What I wanted to get was their own experience of building this prototype rather than the suggestions for my prototype. Only one guy said he knew my pain, I think I know who he is.

Effectiveness

The prototype and the testing session are both effective. Although it is a brief version of the final game, it has already covered all the key interactions of the game. The testing session also helped me get some useful feedback that can be applied in the future game such as the timer, difficulty modes, etc. Besides, the observation of how they played the game, how they strugglled with shooting, and other phenomena while they playing the game also gave me a glimpse of the game. For instance, the layout made it difficult for half of the users to perceive the random key code and connect it to 'shooting' operation even after I pointed out there were connections between different elements on the screen.

The testing protocol is more detailed than the last one. I designed 6 groups of questions for this testing session. Based on the reflection on the last testing session, I put more qualitative questions in the survey this time in order to get more constructive feedback. And for this reason, I told the user to skip the questions if they had no clear answers to them to ensure the accuracy of the feedback.

Constraints

The unpolished prototype just implemented part of the functions that covered the key interactions. The testers thus might not have a comprehensive understanding of the game and what will it look like in the future. Fortunately, the game itself was intuitive so there was barely no constraint for the testers to understand or play the game.

Besides, as the survey contains so many questions, and most of which are text questions that need to do more thinking and brainstorming, many testers thus seemed a bit tired of the survey and skipped many questions. You can see from above that the average number of comments for each text question were around 5, which is just half of the testers who did the survey.

Implications

For future projects, I'll add some of the features such as 'audio', 'game restart', 'timer', 'difficulty mode', 'player status', 'real character icon', and 'winning message' to refine it and make it more fun and exciting. Moreover, in order to improve the user experience, the layout, color scheme, and the random key display also need modification.

For future testing sessions, I'll balance the number of the qualitative and quantitative questions. Try not to make it too simple or too boring. Also, I need to reduce the total number of the questions and focus on the key aspects that are supposed to be tested in the current stage. For instance, this interactive prototype 1 is more focusd on the interactions of the game, so the questions for the testing session should be also designed to get the feedback which is related to the interactions. 

WK8_exercise_Innovative Physical Interactions

We were asked to come up with at least 5 different physical interactions (focus on tangible and/or embodied) for Email, Twitter, and Super Mario Bros.

Email:
- a steering wheel. Turn it to select emails and honk to check the detailed content.
- a card case with business cards. Remove a card from the card case to delete an Email.
- a switch. Switch it on to mark an Email as unread while switch it off to mark an Email as read.
- a flag shape on a board. Press the shape to flag or unflag an Email.
- a real mailbox. Open the mailbox to enter the inbox and close to go back to the default page.

Twitter:
- a bird to read tweets and post your tweet by speaking to it. A sensor will be embedded to interpret the sound to text.
- a valve. Spin to retweet.
- a metal letter board to type in the tweets.
- piano keys. Press white key to comment, black key to retweet.
- a pen and a paper. Write on the paper and it'll automatically convert to digital text on the screen.

Super Mario Bros:
- a seesaw to control the moving direction and the jumping of Mario.
- two drumsticks and a drum. Beat the drum by a single drumstick to move forward or backward, beat the drum by both drumsticks to jump, and hit the two drumsticks to shoot.
- a scale. Put the weights on one side to control the moving direction
- a gun to control the shooting.
- a wire coil on a metal tube. Spin the coil clockwise or counterclockwise to control the moving direction. Move the coil up or down to jump.


As my game mashup idea also has the features of moving and shooting which are similar to the Super Mario Bros. I'd like to apply the drumstick idea to the Makey-Makey project.

Reflection of the survey design of video prototype

I asked 8 questions in total for the video prototype testing session. 5 of them are quantitative questions with concrete scores to measure the aspects that I focused on while the rest 3 questions are qualitative questions asked to get in-depth suggestions for the video prototype and the whole concept. These questions are listed below.

1.Can you understand the basic rules of the game? (1-5)  ----------------- Multiple Choice
2.Do I communicate the design rationale clear enough? (1-5)  ----------------- Multiple Choice
3.Do you think it's an interesting game?  (1-5)  ----------------- Multiple Choice
4.Why or why is it not interesting? ---------------- Text Question
5.Can you foresee any problems of the game? (e.g. rules, interactions, etc) ---------------- Text Question
6.Do you have any suggestions to refine the game to address the potential problems that you concern? ---------------- Text Question
7.What do you think of the quality of the video?  (1-5)  ----------------- Multiple Choice
8.What do you think of the quality of the audio?  (1-5)  ----------------- Multiple Choice

The type of study we did on the class was A/B testing and survey, but, unfortunately, I missed the A/B testing part. Therefore, what I really did was just an online survey by inviting the class to watch my video.

The purpose of the question 1 was the clarity of the game rules. It's pretty straightforward to get the feedback of whether the basic rules are communicated well and understood by the audience. From the feedback, I'll have a general idea of whether the game rules was clear or not.

The purpose of the question 2 was the clarity of the design rationale of the concept, which was very similar to the first one.

The 3rd question aimed to know if it was a fun game. It was one of the most important questions in this survey because it could significantly affect the iteration in the future. I also used a multiple choice to get an average score of the interestingness of the game so that I'll have a rough idea of the current fun level of the game. Besides, I didn't define 'fun' in the question, it should be broken down to several more specific questions that cover all the aspects of the definition of 'fun'.

The 7th and the last questions were asked to get rough scores of the quality of the audio and video of the prototype. I made the two questions hastily and forgot to put a text comment option under each question. What I found was that just scores, without comments, were nearly pointless of helping me improve the video-making skills, it could only be an encouragement or a pain.

All these 5 quantitative questions had the same problem that the options are too vague. I could have defined or expanded the options to make it clearer and more specific. For instance, for the 1st question, it might be better if I changed the score 1-5 to the 5 measurements: 'completely confused', 'vague', 'understand part of it', 'understand most of the rules', 'completely understand'.

In terms of the three qualitative questions, question 4 was related to question 3 in order to get the underlying reason for why or why is it not interesting. As I mentioned above, the suggestion of improving the interestingness of the game was the key feedback that I wanted to get from the survey. And facts have proved that I did get some useful suggestions from this question.

The 5th and 6th question is a group, which aimed to find out and address the potential problems of the game. It was like inviting the interviewees to brainstorm for me and helping me discover the current design defects as well as the possible future challenges.

Overall, as the sample (number of interviewees) is not that big, the simple and concise quantitative questions were not as useful as the qualitative questions. I thus planned to put more qualitative questions in the next survey to get more suggestive feedbacks.

WK6 Coding Game in Actionscript 3.0

Overview

I'm thinking of modifying the current shooting control mechanism of the Space Invader game.

The new control will be the status of the squares displayed on the stage and each square is connected to a specific key-down event. For instance, there are 6 squares altogether and correspond to key 1-6 respectively. Some of the squares will randomly change the status to 'activate' (in the form of switching the background color of the squares) and the user needs to press the corresponding keys to shoot.

Object: Alien

Attributes (variables):

• shape
• x position
• y position
• speed
• status
• movement direction

Abilities (functions):

• move down
• move left
• move right
• shooting
• disappear (destroyed)

Collaborators (other objects):

• stage
• score
• bullet
• sound

Object: Laser Cannon

Attributes (variables):

• shape
• x position
• y position
• speed
• status
• times been shooted
• movement direction

Abilities (functions): 

• move left
• move right
• shooting
• reset (to the start position)
• disappear (destroyed)

Collaborators (other objects):

• stage
• score
• bullet
• sound

Object: Bullet

Attributes (variables):

• shape
• x position
• y position
• speed
• status
• movement direction

Abilities (functions):

• move down
• move up
• disappear (crashed)

Collaborators (other objects):

• laser cannon
• alien
• stage

Object: Score

Attributes (variables):

• shape
• score board x position
• score board y position
• text x position
• text y position
• counter
• text value

Abilities (functions): 

• accumulate score
• decrease score
• clear score

Collaborators (other objects):

• laser cannon
• alien
• stage

Object: Stage

Attributes (variables):

• size
• colour

Abilities (functions):

• display alien movement
• display alien disappear
• display cannon movement
• display cannon disappear
• play sound
• display shooting
• display score

Collaborators (other objects):

• laser cannon
• alien
• audio
• bullet
• twister board
• score
• shooting control

Object: Twister board

Attributes (variables):

• size
• shape
• x position
• y position
• colour
• status
• switching colour frequency
• index of the squares

Abilities (functions):

• switch colour (light up and down)

Collaborators (other objects):

• stage
• shooting

Object: Shooting

Attributes (variables):

• random quantity of the squares that will light up
• random index of the squares that will light up
• key code (corresponding to the key-down event)

Abilities (functions):

• decide which keys control shooting

Collaborators (other objects):

• stage
• twister board

Object: Audio

Attributes (variables):

• status
• name
• URL

Abilities (functions):

• load audio
• play audio

Collaborators (other objects):

• stage
• laser cannon
• alien