Contextual Inquiry-Group:Group 4

From CS 160 Fall 2008

Team Contributions

Witton Chou - Contributed to Task Analysis Questions, interface design sketches, and some general editing.
Karen Huang - Interface design descriptions, sketch design and editing.
Volodymyr Kalish - Target user interviews and user description, contextual inquiry.
Karen Tran - Target user interviews and user description, contextual inquiry.
Trinh Vo - Analysis of approach, interface design sketches.

Target Users

The game’s goal is to provide a fun, interactive way for anyone who is interested in learning programming. The game hopes to serve as entry-point to people who would like to get a taste of what programming is. Therefore, the range of users targeted for this game is very broad. For our contextual inquiry, we interviewed three target users.

All names were changed to protect the privacy.

Target user Andy: 22 year old male student, wants to become a police officer. Didn't study computer science. Owns a pretty good desktop computer and uses it for video editing. Runs a website about fishing, so he knows some things about HTML and website design.

Likes to learn new things, such as programming language. Enjoys working on computer. Likes to solve problems using trial and error and educated guess. Video games.

Dislikes solving complicated problems in head.

Priorities: personal life and fun.

Target user Dorian: 25 years old male, works as a security officer. From conversation made an impression of an advanced computer user. Owns a good desktop computer plus a laptop. Knows how to install and setup software on computers. Did some simple scripting.

Likes to learn new things, such as programming language. Did a good deal of self education on scripting. Likes solving hard problems in head prior to trying the solution.

Dislikes guessing the solutions to problems.

Priorities: girlfriend, family.

Target User Kate: 18 year old first year college student. Although her major is Integrated Biology, she has a great deal of interest in Computer Science and considers minoring in Computer Science during her college career.

During her free time, she loves to read and write fanfiction for characters from her favorite TV dramas. She used the internet extensively for reading news and research. She works for a professor at Cal by translating from English to Chinese and vice versa. Procrastination is her favorite hobby.

Dislikes loud parties and all food that is fried.

Although she’s intrigued with programming, her experience and knowledge with it is very limited. She has been meaning to learn Computer Science. Surprisingly, she finds that there are very few games that even come close to teaching programming.

Priorities: academics.

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.

Contextual Inquiry - Interview Descriptions

The interviews were conducted in a quiet living room. Eclipse was chosen as the starting point due to similarity to the interface in design (it has all the features that will be present in the interface in design). Such a setup also helped by showing the problems with the current interface of Eclipse. Everything was run from a laptop, setup on a coffee table, while the user was sitting on a comfortable couch. A simple template was provided inside the Eclipse, so the users didn't have to worry about the Java syntax.

Each user performed a set of 6 tasks (2 easy, 2 intermediate, and 2 hard) Raw interview data | Raw Interview data 2

Easy Tasks

Easy tasks included the demo of basic usage of Eclipse (saving file, running it, and viewing the results). Users had no problems repeating the tasks after the demo, so they could change “Hello World!” program to display their names. The only problem encountered here was when Andy forgot about run button and thought that if he saved the code, it should display the results right away. So a lesson extracted from this observation is the access to a single button that saves and runs the code in one click.

The third interviewee was first introduced with some simple data types needed in order to do the experiment: int, double, boolean, and String. After seeing a couple of demos on how to print a single String or a number to the console, the user was asked to perform the same tasks with different arguments. The user was able to perform those tasks without complication. However, the user had a few troubles when trying to print a concatenated String. Kate was fumbling around a lot with the syntax and very much relied Eclipse syntax helping tools such as squiggly red lines, etc, but had no idea what the error message meant. She also had trouble making the text readable and did not know how to add spaces between words/numbers.

Intermediate Tasks

Intermediate tasks included working with different data types with corresponding variables and outputting them. Working with simple for-loops. So, by observing how a print statement worked, users were able to produce asked text using the variables. A demo about dogs age was presented, using variables for dog's name, age (as integer) and boolean (just because). And then the users were asked to produce logically similar text, except with a use of a double variable for price. Surprisingly both users bothered to change the name of all the variables (and not just their contents). There was a problem in finding a simple explanation when users asked about the difference between a float and a double. In another demo, a for loop that prints numbers from 0 to 9 was presented, and the task was to output all even numbers between 0 and 10. This task took awhile and many hints and explanations about the behavior of the for loop were required. Users needed explanations about which set of variables represented the range of the loop and which variable was responsible for the step-size. One of the problems both users encountered was in computation of the next number to be printed (the "step"). For some reason they were using i = i / 2 instead of i = i + 2. Both explained that they did it because the problem asked for even numbers. So when the task asked to print every other number or every third number, then the task became trivial. There were a few off-by-1 errors and a lot of trial and error. The “undo” button proved to be extremely useful, and therefore our interface must have it as well. Another problem was the concept of incrementing the step after the body of loop is executed, so this issue must be stressed in our prototype.

The third interviewee was given some demo again as a guide before being asked to perform intermediate tasks. The demo showed the user how to print numbers 0-9 in a “for” loop. The user had trouble grasping the concept of upper bound and stepping. She did not quite understand why ‘i’ < 10 would yield the numbers 0-9 without including 10. Also, i++ was replaced with “i = i + 1” because it was much easier for the user to understand. She was then asked to print multiples of 5 from 5 to 50. She started out by copying the demo code but ran into infinite loop because user forgot to do stepping. She kept waiting for the program to finish because there’s no message on screen to tell them they should stop the infinite loop. When told to stop the program from executing, the user immediately tried to exit Eclipse instead of trying to look for the stop button in Eclipse. The user went back to fix the stepping by setting “i = i+4” instead of “i=i+5.” User also forgot the concept of upper-bound again and set “i<50,” which would not be reached in the loop. When trying to fix the stepping again, the user increased the upper-bound in increment of 5: changed “i<50” to “i<55” instead of realizing that “i” could be changed to any x with 50 ≤ x ≤ 55.

Difficult Tasks

Hard tasks included nested for loops along with recursive methods calls. The first demo was a half of an ASCII-art pyramid. The task was then to draw a full pyramid. Both users went with full replication of the demo code and then making changes to the second copy (trial and error). There were a lot of infinite loops, so it would be a great idea to have some sort of timeout for code execution, since inexperienced user might not know any better. Dorian went for a complete reverse of for-loop logic before trying it and got stuck for a while. Another task was to print numbers in a reversed order with respect to demo. The recursive calls were a piece of cake after explaining the base case and the initial call (with initial values).

The third interviewee was shown a demo and given the code for half a pyramid and was asked to complete the other half. The user had a lot of trouble understanding the “nested loop” concept. User was given walkthrough of the debugging process but was completely lost. This approach of helping the user proved to be very ineffective way to guide the user because the user was not interested in the technical details behind the code and it proved to be too much for the user to take in. In an attempt to finish the other half the code, the user copied and pasted the demo code and changed the loop values. User did not realize that the loop could be counted backward; user was stuck with the idea that ‘i’ has to be initialized to ‘0’. The user tried a few bizarre combinations to make the loop count backward. User was also stuck with the stepping concept that “i” had to be incremented in the positive direction. Moving on to the last topic of recursion, the user was introduced to concept of method calling. User thought it was really odd how a method can call itself from within itself. User is unable to visualize it. Again, the step-by-step debugging seemed lost on the user. The user is unable to write a recursion method on her own.

Common Observations

It was very hard to give out hints. Due to the fact that the interviewees are completely new to programming, it was very challenging to guide them in the right direction without having to give out the answers bluntly. Perhaps, before each task, a brief lesson introducing the users to the concept should be considered. Another reoccurring mistake is that the users either remember to compile the code first and then forgot to hit “run”, or hit “run” first before compiling. The interface should make these tools more obvious.

Task Analysis Questions

Who is going to use system?

The system is going to be used by any person who wishes to learn or supplement basic programming knowledge through Java. Users will be in High School and older with little or no experience in programming/computer science.

What tasks do they now perform?

We expect that users have basic word processing skills and understand how to use the keyboard and mouse. Although they may have experience using programs like Microsoft Word, we do not expect them to have experience using programs such as Eclipse and do not know its formatting features nor understand Java syntax.

What tasks are desired?

We want the users to have a basic understanding how code is produced, formatted, and output as well as be able to create basic programming tasks such as print statements and for/while loops.

How are the tasks learned?

Currently, those who are just beginning to learn programming typically read books and learn from textual explanations. Some will have access to professors or other human help although they are not always available to assist in the learninng process.

Where are the tasks performed?

These tasks are to be performed on the computer with editors such as Notepad, Emacs, and Eclipse. They are not to be done in programs such as Microsoft Word which employs automatic correction features which will not format code properly. These tasks are also operating system independent and can be performed on any computer with an editor, a keyboard, and a Java compiler.

What’s the relationship between user & data?

When performing these tasks, the user typically remains on the same computer as these files are stored locally. As such, remote access is not required and ease of use is determined by the type of computer, software, and platform the user's own computer limits him to.

What other tools does the user have?

A network connection or external storage device could be used to share data between computers. Project synchronization and versioning can be utilized through software although not necessary depending on the task at hand and/or the user's current programming skill level.

How do users communicate with each other?

Users typically communicate with each other in person, through emails, by phone, and instant messaging software. Email and instant messaging are readily accessible communication media for programmers as they are already at a computer and typically have access to the internet.

How often are the tasks performed?

Programming tasks are performed several times a week depending on the amount of assigned work (if the user is taking a class) and/or how fast the user wishes to learn the material as well as how familiar he is with the covered material. Thus, some sessions may take longer and may be performed more frequently than others.

What are the time constraints on the tasks?

Time constraints on programming can range from hours to days, to weeks, to months or even years. In any case, however, the desire will be to program as efficientlyas possible (produce high performance code quickly) whether it is a small or large scale project. The programmer must accomplish a task with a minimal number of bugs and have a program that runs efficiently (uses minimal resources and executes quickly)

What happens when things go wrong?

Depending on the editor, there will be some feedback, although minimal. The feedback will primarily by syntax related, such as parentheses but many of the errors won't become apparent until the user attempts to compile or even run the program. Therefore, it is the programmer's responsibility to verify his code to the best of his abilities and use comprehensive test cases.

Analysis of Tasks

Much of the descriptions about the tasks were given in the Contextual Inquiry section. Here is a brief recap of those tasks:

Easy tasks

Print user's name. (Basic print statement akin to the generic "Hello World" introduction)
Print some strings concatenated with some integers. (Shows the user that strings and numbers can by combined by simply joining them with a '+')

Intermediate tasks

Print some complicated structure using concatenated variables. (Demonstrates the power and application of a print statement. Users learn that variables can be formatted into a print statement as well.)
Using for loop, print even numbers in some range. (The basic power of for loops is demonstrated here. Users must understand the concept of a boolean, condition tests, and increments.)

Hard tasks

Using a for loop print an ASCII-art pyramid. (Understanding that for loops can be nested is a hard concept to grasp for most beginners. The fact that there is a hierarchy of variables and when each variable is incremented is not intuitive until explained thoroughly through visuals.)
Using a method and a method call, recursively output some numbers. (The interviewee was asked to use a method which would call itself recursively to print a series of numbers. The user must understand the passing of arguments to methods to complete this task.)

Interface Design

Design Ideas

After finishing with contextual inquiry interview, we figured out that several heuristics are critical for this game.

Aesthetic and minimalist design: The visibility of the most frequently use buttons/functions are the most important aspect of the game's user interface. Our targeted users can get lost easily with a complicated interface according to our contextual inquiry interview. We try not to overwhelm players with writing the actual codes, grammar and debugging, so keeping a minimalist interface.
User control and freedom: Users should be able to manipulate functions and produce infinite possible results, so we develop the "drag and drop" idea for integrating functions into the main code.
Error prevention: Since the game is teaching learners inexperienced in computer programming, it has to prevent invalid inputs such as invalid data types in looping arguments, incorrect function placement and so on.
Match system and real world: The interface's layout of coding area and output are close to professional programming application.

Our game will be a web-based flash game, and the input device is mouse and simple keyboard inputs (such as integers).

Solution Sketches

Our programming game interface has three sections.

The code section is on the upper left corner and occupies the biggest portion of the interface because learning programming is one of the main purpose of playing this game.
- Dash-lined boxes will appear at valid locations in the code when the player tries to drag and drop a function into the coding area.

Output is shown on the bottom to keep everything on one screen so that players can compare the code and the output at the same time.
- The Run Code button will be gigantic to be visible and is placed next to the section title Output to encourage the player trying out the code, which will be compiled and run right away.

Functions on the right for the ease of drag and drop into the main coding area.
- Each function has a name bar. Clicking it can expand or minimize the corresponding function frame.
- Inside each frame, players can enter arguments in predefined fields. Warning message will be displayed if the player enters the wrong type of argument, such as letters instead of integers, and the invalid input will be clear.
- Players can drag and drop by holding the mouse button on the function name bar and moving to their desired area inside the coding area.

Note: Timer and score of the current game will be shown.

This is the Main Menu:

This is the preference window:

This is the task description window for the current game:

Scenario 1

The player needs to complete the task of printing the statement "I like to eat" in the game within 5 minutes.

1. Initial code page Available functions are to the right.	2. The downward arrow means that the menu can be expanded for function parameters.	3. Function parameters are now visible and can be edited.	4. Dragging out the bar of the function converts the function to a block of Java code to be put in the editor.
5. Once the code blocks are put into the editor, the player can press the run code button to execute the code. "I like to eat" has been printed.

Scenario 2

The player is learning loops in programming. This task is to print "haha: 1" to "haha: 5" in the game within 5 minutes.

1. Clicking the Loops bar to expand the options for the looping function.	2. The Loops is expanded, and the player can enter an integer in each of start, end, step boxes. Either for or while box needs to be checked in order to specify the type of loop.	3. for loop is selected, the player is dragging the loops box into the main function window.	4. clicking print to specify arguments and the print function will be put into the for loop.
5. Dropping the for loop into the main function inside coding area.	6. Dropping the completed print function into the for loop inside the code area.	7. Clicking RunCode in order to try the codes out.	8. Well done! The desired output is shown, and the player complete this task.

Scenario 3

The user needs to create a method call with any predefined functions within 5 minutes.

1. To create(define) a method, so the user needs to click on the Method menu to expand it (if it's not already expanded yet).	2. The user is required to type in the function name, then add/minus arguments' names plus their types.	3. The user can then drag and drop the defined method to the main section.	4. At this point, the user can still add/minus as many arguments as they want by clicking on +/- button.
5. After finishing with adding arguments, the user can implement the function body with other function modules, e.g. println)

Analysis of Approach

- Other solutions might be tutorials on programming, but tutorials don't have any specific objective, which is an important factor that pushes users to keep being interested in programming. Users want to see beforehand what they will gain afterward, so a serious game will be the best solution.

How our application takes advantage of the affordances:

- Our approach is we make functions (e.g. for, println, and user defined methods, etc...) as modules, so users can drag and drop them anywhere into the main section. This ability helps users quickly edit their codes.

- When describing new materials, we use pictures of daily used objects to help users understand the materials quickly. The benefits of using daily used objects are to help users map the materials with objects’ operations, so users can understand the concepts concretely. For example, to show users data type concepts, we use pictures of cups with different sizes. When seeing the cups, users can quickly understand that a data type is simply a cup or a container to hold data (water), and the amount of data it can contain depends on the size (volume) of the cup/container.

- In addition, when designing user interface, we were trying to give clues to the operations of things by making things as visible as possible, and creating things that users can easily relate to such as sticking-out buttons, grooves indicate that something can be dragged, and Up/Down arrow buttons indicate a module can be retractable or expandable respectively, etc. Our first priority is the usability not the beauty. (See Figure.)

Figure:

Pros:

- Using game to teach people how to program. Since this is a game, it has an objective (the prize), which could be an almost complete project (e.g. a text-based hang-man game). After learning all the concepts, users are required to fill in the blanks to achieve the objective. The objective/prize keeps people going on.

- Compared to other teaching styles, users don't have to learn how to compile their codes before they can start learning programming concepts. For many reasons, users sometimes are not able to compile their code, so they will get frustrated and quit at the beginning. Besides, they don't need to know what the compiler does to be able to learn programming. With this approach, they won't have to go through such difficulties. After a couple clicks, they can start learning how to program right away.

- Being able to see results without going through many pains, users can will be less intimated and push themselves to learn more and more.

- Concepts are visualized with animated demonstration, so users can quickly learn and thoroughly understand materials.

- Users can freely drag and drop functions (e.g. for loops, user defined methods) into the main section. This allows users to understand how each function works without worrying of trying to memorize the syntax.

- Users have full flexibilities of editing. They can either provide values for the required fields of a module before dragging it into the main section or they can just drag it into main section and then provide values for the required fields.

Cons:

- Since functions’ syntax are automatically provided to the users, users tend to get lazy of typing and memorizing the syntax, so they won't be able to remember them.

- This approach is only appropriate for beginners who want to have a quick understanding of basic programming concepts because it doesn't require the users to know the syntax, or to understand what's under the hood. With this approach, the users won't be able to compile a file themselves because everything is automatically done for them.

- It's hard to use this approach to implement higher programming level because it is heavy on coding, and users can't just keep pulling in those modular functions because the screen will become hard to read and debug.