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

Norman's Design Principles

In the following, we want to show how
Norman's design priniples affected our design process:

1. Visibility

Our design does not include any hidden menus, therefore granting a good degree of visibility. Furthermore, the action of pressing any button in our application will be made easily understandable by implementing a progress bar filling up while the user has to keep the selection.

2. Feedback

Our application includes various sounds to give an audible feedback to the user. In addition to that the game state is displayed as a score panel at the top of each player's screen.

3. Constraints

The users are restricted to move their pad only in their respective play area.
Another constraint is realized in the fact that a potential second player needs the agreement of the first player to join the game, so no one can interfere negatively with a player's game.

4. Mapping

Pong itself is perfectly mapped from the real world version of the game.
Also, mapping is given by the implementation of each player's UI elements in a single color for each player.

5. Consistency

Throughout the application we only use a single kind of button or interactivity, therefore consistency is given.

6. Affordance

As mentioned above, a progress bar for each button will be implemented to ensure a high degree of affordance. This is in accordance to EyeToy and similar environments, so experienced users have very easy access to our application and do not have to relearn the controls.

task done by: Benedikt

Screenshots of Prototype