InteractivePrototype-Group:Group 4

From CS 160 Fall 2008

Disclaimer: As we continue to improve our project, the presentation shown on Oct 29 (Wed) will be based on the newest working version that is not exactly the same version as the Interactive Prototype submission on Wiki.

Contents 1 Team Members 2 Problem and solution overview 3 Tasks 3.1 Easy 3.2 Medium 3.3 Difficult 4 Revised Interface Design 5 Prototype overview 5.1 Overview of the UI implemented 5.2 What was left out and why 5.3 Wizard of Oz Techniques 6 Prototype screenshots 6.1 MAIN MENU 6.2 "WHAT GOES HERE?" TASK 6.3 DATRIS TASK 6.4 BUGABOO TASK 7 Prototype Files

Team Members

• Witton Chou - Main Menu, "What Goes Here?"
• Kai Lin Huang - Datris, Report, Redesign/Revised
• Volodymyr Kalish - Report, Redesign/Revised
• Karen Tran - Report, Redesign/Revised
• Trinh Vo - Bugaboo, Datris

Problem and solution overview

The primary problem is that the programming learning curve is fairly steep for those who are just beginning to learn Computer Science. It is hard for newbies and children to learn concepts without going through the pain of learning syntax and compilation. Our solution is to make learning the concepts of beginning programming easy and fun, by abstracting away all the hard-to-grasp-at-the-beginning concepts and developing a fun yet intuitive interface conducive to understand the crucial elementary building blocks of Computer Science.

Tasks

• Do the tasks cover the interesting features of the project?
  • Each task has its own goal, which will be achieved through various fun techniques devised and described below.
• Do the tasks have an appropriate difficulty/complexity specified?
  • The tasks are organized in increasing difficulty level: "What Goes Here?," "Datris," and "Bugaboo."
• Do the tasks altogether form a compelling story for the project?
  • The tasks below are described in a "programming cycle" fashion, in which the user is first introduced the basics of programming by filling in the blanks, then moves on to learn building blocks of programming by learning about data types, and lastly, acquires the debugging skill through the game Bugaboo.

The three representative tasks to test the interface:

Easy

Complete this Code

Task Goal: Based on the output of a program and the given programming codes, fill in the missing code.

Initially, each of the windows: the code window, output window, and desired output windows will contain labels and instructions on how each of the windows interact with each other and how they reflect the goal of the game. In future versions, animated tutorials will carry the user through a sample code fragment with which to fill in the blanks.

At the beginning, only two blanks need to be filled for the given piece of code. As the user progresses to higher levels, the number of blanks and the difficulty of the presented code will increase to account for a wider variety of code syntax and practices.

Once player clicks "run" after filling out the blank, he/she will know whether he/she put down the correct codes. If so, the player will gain 20 points. Otherwise, the player can fix the code as long as there is time left. If the player completes the task prior to the expiration of the timer, the remaining time will be awarded to the player as "bonus points," which will encourage the user to play and practice a bit more.

Note: This task is greatly simplified from asking the user to construct a running program from given functions in the low-fidelity prototype to choosing appropriate options for blanks in a piece of code now.

Medium

Datris

Task Goal: Identify correct data type buckets and move falling data bricks to the corresponding data type bucket.

After trying out right (and wrong) codes in the easy task, player should feel more comfortable with understanding codes. A need arises at this point: the player must learn and understand importnat data types before proceding further such as debugging codes.

Player will be introduced to string, boolean, integer and double variables in the tutorial. Then the player is directed to start the game. Player will use left and right arrow keys to move the falling brick, use down arrow key to drop the brick to the desired bucket.

If a correct data type was dropped into correct bucket, the score will go up. Also, the user can make three mistakes in this game and on the fourth mistake the game is over.

After completion of each level, the speed at which data types fall down increases. The difficulty/trickinness of the data types increases as well.

Difficult

Bugaboo

Task Goal: In this game the user will have to visually "hunt" for the buggy lines of code.

Each line of code will appear inside a circle (target) for some time on the random spot within a "hunting ground" (the playing area).

If that line of code is buggy and the user clicks on it, it will flash green and disappear while rewarding the player with some points.

If the line of code is not buggy, then the correct action would be not to touch it until it flashes green and disappears when its time expires.

In case when user doesn't identify the buggy code correctly, the points will be subtracted and the circle (target) will flash red before disappearing.

Note: All tasks are timed and scored.

Revised Interface Design

• Were appropriate changes made to address the important problems discovered?

PROBLEM:

From our lo-fi prototype interviews, we realized that our first (easy) task created a lot of confusion for the users because it was more advanced than we thought. It took too long for the users to even grasp the basic understanding of their task. It overwhelmed absolute beginners by presenting them more materials than needed.

SOLUTION:

A better approach to make the game less intimidating is to provide the users most of the code and allow them to fill in the crucial pieces to accomplish the task. We revised the first task with the intention of avoiding making the users start from scratch. In the places where the users should fill in the blanks, we provide drop-down menus of options, from which they pick their answers. This way, our users have a chance of getting acquainted with the java code without actually typing it all in.

PROBLEM:

In the Datris game, we did not have good visual/audio indicators to show whether the user made the right decision about where to drop objects into.

SOLUTION:

To make the game more exciting and interactive, we would add a ding sound for correct and a buzzer sound for wrong. Moreover, we would add visual indicators such that when a falling “data type block” is sorted into the wrong bucket, the bucket would flash red or green otherwise.

1. If the falling brick is sorted into the correct bucket, the corresponding bucket would flash green.

2. If the falling brick is sorted into the incorrect bucket, the bucket would flash red.

• Were the limitations of the low-fi addressed?

PROBLEM:

In the low-fi prototype Datris game experiment, the user cannot experience "level up" to play a faster dropping piece of data because the limitation of human's physical reaction speed compared to a computer.

SOLUTION:

We use flash to make a working Datris game that has "level up" feature to increase the speed of a dropping piece of data.

• Were appropriate constraints from the serious game considered?

PROBLEM:

Because of the context of our serious game, which is teaching programming concepts and techniques, it is better not to rotate our pieces of data that is dropping in the Datris game so that the player can read the information on the dropping pieces. In addition, we are not matching the shapes among pieces; instead, we are matching buckets.

SOLUTION:

We therefore did not include rotation because it does not fit into our context of matching data type. Our pieces would be type matching.

PROBLEM:

The Bugaboo game is certainly very challenging. It daunted the users when they are just presented a big piece of code and told to fix it without any help, as they did not know where to start. Moreover, from the feedback that we got from our low-fidelity interviews, an introductory tutorial fails to serve its purpose at this task because debugging is an acquired rather than a taught skill.

SOLUTION:

While the purpose of the task remains the same, the revision of our difficult task aims to engage the users in a more fun "shooting game" environment. Instead of making the users trace through the code to track down the bugs, the task would present the bugs in a "target" format, which the users can shoot. This approach would add an entertaining element to the task as the concept of debugging is abstracted away.

PROBLEM:

Originally, we would have the users read a tutorial before starting a task. We realized that users tend to not care much for the reading, and more often than not, they get lost as some tutorials are inclined to be lengthy to cover all necessary details.

SOLUTION:

Most of us are visual learners. Therefore, we converted the extensive text to animated tutorials. This has the benefit of cutting down the time of the tutorials; in addition, it has a tendency to let the users absorb more information.

• Are these changes well illustrated with screenshots or scripts?
  • All of these changes are illustrated with screenshots from the Prototype section below.

• Were any non-standard interactions described and justified?

We did not include very rare widgets in our games. However, there are some less commonly used widgets such as mouse pointer as a bullseye to shoot the code targets in Bug-a-Boo game.

Prototype overview

Overview of the UI implemented

Main Menu

• Single Player
  • Displays the menu of three games available: "What Goes Here?," "Datris," and "Bugaboo."
• Multiplayer
  • The same games as in Single Player mode are offered here with the difference of allowing the player to compete with other users in the network. The progress of each participants are displayed in the form of progress bars on the player's personal screen. However, we did not have time to implement this feature.
• Settings
  • More advanced features (in progress) will be added as part of Settings

What Goes Here?

• Objective: The objective of “What goes here?” task is to familiarize the users with the coding style and syntax of the Java programming language.

• How to play: The game starts out with the user being presented a brief tutorial. The player will be shown an almost complete snippet of code with blanks, which will be filled in through user input with a text field. After a certain number of the problems are fixed, the player moves on to the next level.

• Logistics: The player is given a limited time to complete the code snippet. At the end of the task when all the blanks have been filled out correctly, the remaining time gets converted to bonus points in addition to points rewarded for getting the right answers. If all the tasks are completed in the given time, the game is won; otherwise, the player loses.

Datris

• Objective: The game aims to familiarize the users with the concept of data types. Data types are essential to any computer programming language. Without them, it becomes very difficult to maintain information within a computer program. Since the main principle behind computer programming is to take information, process it, and deliver the information in a different form to the user, data types obviously play a large part in determining how this is achieved. Datris introduces some of the most common data types used across programming languages: String, int (integer), double (decimal), and Boolean (true/false).

• How to play: Once the Datris Task is picked, the User Interface for the game is displayed. At the main screen, the user can start playing Datris by clicking on the “START” button. Player can use left and right arrow keys on the keyboard to move the falling brick, which is representative of a data type. The task is to sort the brick into the appropriate data-type bucket at the end of the screen. There are five buckets: String, int , double, true and false. The description of each bucket is self-explanatory. If a falling brick contains a String, the brick should be directed to fall into the String bucket, etc. One note to make here is that the Boolean data type has been split into two buckets, represented by True and False. If a falling brick contains an expression, which evaluates to true, it should be sorted into the True bucket; the same goes for the False bucket. On the right hand side, the current score of the game is shown at the top corner in the score panel. Underneath that, there are four buttons available to the user. For any reason, the user can choose to restart the game by clicking the “REPLAY” button. If, at any point, the user needs to be reminded of the game rules and the mechanics of the game, the user can choose to pause the game by clicking the “PAUSE” button or by pressing the ‘p’ key on the keyboard; either action will transform the "PAUSE" message into that of "RESUME". The “HELP” button, when clicked, will display an overview of Datris. When the player is ready to resume the game, he or she can click on the “RESUME” button. There is also a “MAIN MENU” button, which will quit the game and redirect the user back to the main menu. Moreover, below the buttons shows the remaining number of Health Points (“HP”), each represented by a red heart, the player has left.

• Logistics: The game starts out with the player in level 0. For each brick the player correctly sorts into the appropriate bucket, the player earns one point. For each 20 points the player earns, he or she is promoted to the next level, which translates into an increase in the speed, at which the subsequent bricks fall. The game is won when the player earns 100 points at level 4. For each brick that is sorted inaccurately, the player loses a Health Point, which will be updated accordingly with a decrease in the number of red hearts left in the “HP” panel. When all four Health Points are used up, the game is lost, at which point a message will display, allowing the player to retry the game by clicking on the “REPLAY” button, or to quit the game by clicking on the “MAIN MENU” button.

Bugaboo

• Objective: The objective of this game is to teach users to identify bugs by just looking at the line of code. It was designed in the spirit: "It is better to learn on someone else's mistakes than make your own", so the most common bugs a lot of beginners make will be introduced in thins game.

• How to play: Once the Bugaboo Task is picked, the User Interface for the game is displayed. At the main screen, the user can start playing Bugaboo by clicking on the “START” button. Once the game started, the user can pause the game (by pressing "p" or clicking on the "pause" button) or quit the game (by pressing "stop" button or going back to the main menu by clicking on the "main menu" button). The rules of the game can be looked up by using the help button. When each line of code appears, it appears inside a blue circle. Then, the user looks at the line and tries to identify whether there are any bugs in it. If the line is buggy and the user spotted that it is, he/she would click on it and the circle would change the color from blue to green (with an appropriate sound). Otherwise, if the line had a bug, the user didn't see it and the timer had expired, the circle would turn red (and an appropriate sound would flag an error). Same thing would happen if the line of code didn't have a bug and the user thought that it did and clicked on the circle. Because if the line of code is bug-free, the player should leave it alone and let the timer expire (in this case the circle would change green before disappearing and the appropriate sound would sound).

• Logistics: The user gets 5 points for each correct answer and 0 points for incorrect answers. Each line of code appears for 5 seconds, giving the player enough time to really look into it and identify whether something is wrong with it. The user can win the game when the score reaches to 100 points, or lose the game by making 4 mistakes.

What was left out and why

1) We designed to exclude real time updates of game competitor's progress bar on the user's screen to see how fast they compare to their rivals in the same set of tasks. Adding the multiplayer functionality is unimplemented because it is not practical given the time constraint and the UI will not have significant changes. Moreover, to incorporate real time updates between two competitors, our networked multiplayer mode would involve networking protocol knowledge that would bring a lot of new problems and has little to do with User Interface Design. It appears to us that it is more crucial to make the game work for single user at this point.

2) In "What Goes Here?" game we don't produce every single possible output for incorrect answers because the number of outputs grows exponentially O(2ⁿ) (if there are only 2 choices per "blank") with the number of "blanks" per piece of presented code. And it becomes even more complex as the number of selections per "blank" increases. So, that's why it is infeasible to store all the possible outputs. There is another way to go by actually running code on JVM underneath of our interface, but with the time constraint we have it will be impossible to implement. It will be difficult inform the user about an infinite loop which could potentially crash our app if left unattended for a long time.

3) Some of the sound effects will not be implemented due to time constraints.

4) In the Datris game, the "RESTART" button does not function properly after the player wins the game. At this stage we thought that it wasn't important enough to spend time on making it functional (not many users would want to replay a game after winning it).

5) Animated tutorial is missing because it is too time consuming to make.

6) Progress bar is missing (no time for little things...)

7) When the user is about to interrupt his/her game by exiting or going back to main menu, there is no confirmation. So, accidental clicks on some button can ruin a game.

8) The Settings option on the Main Menu is not implemented at this point because it is not part of the basic blueprint of the game. As the game increases in complexity, more advanced features might be added as part of the "Settings" section.

Wizard of Oz Techniques

• Most sound effects and audio indications of right/wrong users actions during gameplay will be performed by group4 members.
• Another wizard of oz technique that we use is to manually handle the transitions between the different games (What goes here?, Datris, and Bugaboo). It turned out that integrating different parts of the project into one unified file proves to be more problem-some and time-consuming than expected. As of this point, we will assume that when you click on a game task, the transition to that selected game will happen smoothly.

Prototype screenshots

MAIN MENU

1. The entry screen of Programming4Lyfe game.

2. When a Single Player option is chosen, a menu is shown, displaying three different games the player can play.

"WHAT GOES HERE?" TASK

1. The main screen for "What Goes Here?" User clicks OK! when ready to play.

2. When the user inputs values in the appropriate fields, the output dynamically updates.

3. We win!

DATRIS TASK

1. The initial Datris screen displayed when DATRIS TASK is selected.	2. Shows falling brick that the player has to sort into the correct bucket.	3. When PAUSE is clicked, the label of the button changes to RESUME	4. At any time, the player can pause the game and read an overview of Datris by clicking the HELP button.
5. The game is won when the player earns 100 points.	6. The game is lost when the player loses all four Health Points.

BUGABOO TASK

1. The initial Bugaboo screen displayed when Bugaboo TASK is selected.	2. One of the expressions has a bug and another does not. Timer expired.	3. The expression has a bug and the user clicked on it.	4. The expression does not have a bug and the user clicked on it.
5. At any time, the player can pause the game and read an overview of Bugaboo by clicking the HELP button.	6. The game is won when the player earns 100 points.	7. The game is lost when the player loses all four Health Points.

Prototype Files

• Is the prototype accessible and working?
  • it is working and can be accessed [here]
  • The .swf files may be accessed through this zip file.

• Can users complete the three tasks with the prototype?
  • it is not fully functional, but the users definitely can complete the three tasks

• Were appropriate tradeoffs made between functionality and completeness?
  • as far as tradeoffs go, we aimed for functionality and completeness and cut off any cosmetics and sound effects due to time constraints

• Are the limitations and tradeoffs described and justified in the report?
  • we justified every unimplemented feature and tradeoff we made in "Revised Interface Design" and "What was left out and why" sections.

• Does the README file summarize these limitations and any other details needed?
  • the README file adresses all limitations and can be accessed here.