Modification after Usertest

After the user tests we have had on Friday, our team were really engaged with fixing and changing stuff, that was criticized by the test subjects.

The following changes were made:

• slower down game action and ball speed; user has more time to react
• adding delete-button to the keyboard (in respect to the definition of usability phase "errors")
• replacing red-dot on user's hand with user ID
• new color scheme. more brightness 
• position of scores during the game are set father from the borders
• "misplaced text"- bugs are fixed
• paddles are bigger now
• change depth image to real background

We have set a real Background, so the users can see themselves playing the game and the control becomes more intuitive

Brighter color and better contrasts where set. Additionally, instead of the yellow progress circle on the right corner, we have put a progress bar directly into the action buttons .

The progress bar was also implemented for the keyboard. Additionally some animitions were added ( Pointing and Clicking Finger). Users can undo their inputs now, by clicking on "Delete" button

After applying users input by clicking on "Enter" , their name and play time where add to the score board

The new structure of our project

As mentioned we had rebuilt the whole structure of our project. The old "One-Class-Structure" was not designed for collaborative working. In a group which consist of 4 computer science students and 1 human factor student, its really hard to work on only one class. Besides this we only had 1 Kinect to test our application. To solve this problem we additionally add mouse control to our application. The following pictures show the packages as UML diagrams:

The package structure looks like:

pong
   - pong.feature
     |     pong.feature.Key
     |     pong.feature.Keyboard
     |     pong.feature.ProgressCircle
     |     pong.feature.Score
     |     pong.feature.ScoreBoard
     |     pong.feature.Soni
   - pong.gui
     |   - pong.gui.button
     |     |     pong.gui.button.ActionButton
     |     |     pong.gui.button.SelectionButton
     |     |     pong.gui.button.Button
     |   - pong.gui.pages
     |     |     pong.gui.pages.GamePage
     |     |     pong.gui.pages.MenuPage
     |     |     pong.gui.pages.Page
     |     |     pong.gui.pages.ScorePage
     |     |     pong.gui.pages.StartPage
   - pong.logic
     |     pong.logic.ArtificialIntelligence  
     |     pong.logic.Ball
     |     pong.logic.MovementProvider
     |     pong.logic.Paddle

Package Feature:

Package Gui:

Package Logic

Whole Project

User Tests

The tests were executed on Friday around 5 p.m. in a well-lit room in the TEL building. Our application was displayed on a 30" large display. Since our application is designed for large public displays, we preferred using a large display over notebook monitors for more accurate results.

We tested our application on two users. We asked the subjects to say their thoughts out aloud and took notes.

The subjects were asked to try and interact with the application, without prior knowledge of its contents. This task included understanding the purpose of each page of the application, understanding the icons, the buttons and the actions required to trigger these buttons, since one of our main goals is that our application is self-explanatory. We were also very interested in knowing how challenging the game is to the average user.

Our Subjects:
Carla, 23 years old, studies biology, has experience with gaming using the EyeToy on the Playstion 2, no experience with the Kinect.
Paul, 28 years old, studies chemistry, has gaming experience with both the Kinect and the EyeToy.

The subjects criticized the following features of our application:

• During the game, things happen too fast, so that the user has not enough time to decide for a proper action and react in time.
• The game concept is not identifiable
• The red paddle moves too slow
• On the border of the game, the behavior of the red paddle and dot are irritating
• The ball moves too fast
• The scoring system is not comprehensible
• There is no delete button on the keyboard in the high score page
• Having the red paddle and dot painted simultaneously on the user's hand is irritating
• The color scheme used throughout the game is not appealing
• The natural colored image is preferred over the depth image

Aside from the user feedback, the user test gave us also the benefit of reviewing our program once more. We noticed the following bugs in our application:
• when having more than 3 digits for scores, some of the digits are not properly displayed in the page and are misplaced
• after changing from the score page to the menu page, all of the displayed text is misplaced and shifted to the left.

For eliminating the detected bugs and a higher user satisfaction, we have planned the following modifications to our application:
• Using the normal color image instead of the depth image from the Kinect.
• Remove the dots that are drawn on the hands completely, or to replace them with the user ID
• Make the paddles bigger
• Make the ball slower
• Add delete button to the keyboard

Application Modifications

In order to solve the problems detected during the heuristic evaluation, we have applied the following changes to our application:

• We added a new page to our application called the Start Page, where a demo of the game is shown in the background. A text, two blinking arrows and two silhouettes are also displayed to act a guide to the user of how to start the game.
  
• For indicating the highlighting duration which a Action Button needs, we have added a progress circle to the top right corner of each page, which fills itself fully up in the highlighting duration.
  
• When a game is over, a continue button appears, which the user has to activate in order to continue.
  
• We have introduced a new page to the game, called the "Score Board", which shows a table with the names of the users that have completed the came in the shortest time. This page challenges the users so that they compete for the top rankings. This feature add to the game-challenge
  
  
  
  
  
• In a revolutionary act (;D), we have reconstructed the whole project. While the old structure consisted of only one class, which made parallel programming impossible, the new structure consists of many packages and classes. This structure allows us to work on different parts of the application simultaneously. Also, we were able to test application by easily replacing the Kinect inputs, with mouse inputs, which to some extent solved the problem of having only one Kinect and 4 developers.

         Upload as soon as possible

Heuristic Evaluation Results: Problems

The following problems with our application were identified as the result of the heuristic evaluation. The numbers indicate the severity level of a problem, where 1 stand for minor and 5 for a severe problem.

• No application information about the game itself and its contents (5)
• Necessary highlighting duration of an Action Button is not visible (4)
• No visual difference between Selection Buttons and Action Buttons not visible (2)
• No auto-starting of the game when the user is not detected anymore during the game (4)
• Depth image received by the Kinect is displayed instead of the normal image (1)

Project Specific Heuristics

We have defined the following two heuristics that are specific for our project and we have evaluated our project accordingly:

Sufficient level of challenge:

• Supported by increasing ball speed and different game modes

Continuous visual feedback to the User:

• Input from the Kinect is visible through the whole application
  
• The hand of the user which is considered as the "Action Hand" is always marked with the color of the user.

Task done by: All

Heuristic Evaluation

The following is the summary of the heuristic evaluation of our application. Both positive and negative aspects of are application were considered in the evaluation:

Visibility of system status:

• No visible feedback when selecting "Start" & "Exit" Button. These buttons need to remain highlighted for several seconds to be activated.
• No sound feedback (not practical for our scenario)

Match between system and the real world:
Overall Good:

• Camera feedback.
• Marking the users' hands which are considered as the "action hands" by our application
  
• Intuitive naming of buttons

User control and freedom:

• The subtlety of the movements is limited by the resolution of the Kinect
  
• The user must remain in the view range of the Kinect in order to interact
  
• Playing hand is predefined
  
• The first user (left user) controls the game settings
• Exit button allows the users to quit the game at any given time.

Consistency and standards:

• No difference in the appearance of a "Selection Button" and a "Hover button"
• Each player is specified by a different but consistant color throughout the game.

Error prevention:

• Introduction of the "Start Button" prevents the users from selecting an unwanted game mode.

Recognition rather than recall:

• The simple design of our application, eliminates the need for recognition and recall.

Flexibility and efficiency of use:

• Minimal, simple and well-known design leaves no room for distinguishing between novice and experienced users.

Aesthetic and minimalist design:

• The information relevant to each view of the application is limited to that view and is compact.

Help users recognize, diagnose, and recover from errors:

• If the Kinect loses track of the user, the game is still continued
  

Help and documentation:

• Not supported due to minimalist design

Task done by: All