Don’t hide the code!: empowering novice and beginner programmers using a

HTML game editor

Theodor Wyeld, Flinders University, theodor.wyeld@flinders.edu.au,

Zak Barbuto, Flinders University, barb0115@flinders.edu.au

Abstract—Novices and beginners have multiple motivations to

learn how to program. The greatest hurdle for them to

overcome is the intimidation of the code itself. Making the code

easier to understand and operate on assists them in the task of

learning to program. This paper reports on a novel HTML

games editor interface for assisting novice and beginner

programmers to create games for mobile devices. Visualising

the results of their programming in the form of a game helped

them overcome their initial anxiety. The HTML games editor

was developed using a cycled evaluation study to best meet the

novice and beginner users’ needs. The goal for novices and

beginners to create a game suitable for playing on a mobile

device in 1.5 hours was achieved.

Keywords-component; HTML, games editor, Heckel,

evaluation, novice, beginner.

I. INTRODUCTION

Programming languages have been simplified over time to better accommodate the novice and expert programmer alike. However, for the novice, the programming interface can still be a source of intimidation. Helping novices better understand a programming language that leads to useful outcomes can be an empowering experience for them [17].

There are many examples of attempts to make programming for novices easier. They range from simplification of complex coding languages to, compile emulators and live code visualisers. Kelleher and Pausch [17] have compiled a taxonomy of programming environments and languages for novice programmers. From this they found the key elements to helping novices learn programming include: motivating, empowering, enhancing, entertaining and educating systems. Others approach it by reducing the complexity of the language to a subset of simplified actions [20], or combine these features [21]. Simplifying a complex language or emulating a compiler still requires the user to understand the underlying code. A live code visualisation, on the other hand, does not require the user to have a deep knowledge of the underlying code.

Live code visualisers tend to focus on literately visualising the code actions [11, 12, 14, 15, 19, 22]. Their use of animations of code actions help users visualise what that part of the code is doing in real-time [9, 18, 22]. Much of this animated code research has been focused on helping children to program – where animating the actions helps them better understand how the language works [10, 16, 17, 18]. Hundhausen and Brown [21] discuss a live-coding tool

used for teaching first-year computer science students programming that offers both coding and direct manipulation – such as the ability to type characters into a visual representation of an array as it updates the code. They go on to claim, because “…novice learners are known to have difficulties with formulating syntactically-correct code, and with conceptualizing the execution effects of program code [13], it would appear that novice learners in particular would stand to benefit from such edit-time feedback” [22, pp140].

While most of these innovations in making programming easier apply to students of the computer sciences (CS), the participants in this study are not all CS students – they range in background and interest from educators to graphic designers. Hence, learning the code itself was not the prime motivation. Instead, the purpose of this study was to simply not hide the code, and empower the users by making the code directly editable in a straightforward manner with feedback in the form of a playable game. Using the ‘live coding’ method of providing sliders for values embedded in the code’s functions only adds another layer of abstraction and mystery for the user to overcome. Thus, providing the user with a straightforward HTML interface to interact with was chosen as the least intimidating method for this project.

Using a HTML editor to develop a basic game suitable for playing on a mobile device was the method chosen by the authors of this paper to empower students to learn the underlying code. The HTML games editor made the code highly visible and editable for the users while making changes. This connected the abstract (code) with the concrete (playable game) [6]. By seeing the effects of their code changes, the user could better predict the outcome of future changes. Over time, they developed a legacy of code structure and syntax – not abstract but applied and thus more memorable than simply memorising code structures. This proved to be an effective teaching method.

There are many motivations for novices to want to learn how to program. These fall into two main groups: those who need to know how to program for their careers (software engineer, web developer, games developer etc); and, those who only need to know enough to be able to develop the small applications that assist them in careers that otherwise do not require any advanced programming skills (graphic designer, visual effects artist, online educator etc) [7, 10]. This paper focuses on the latter. The goal of the tool is to lower the barriers between the code and programming for novices and beginners. The tool aims to make users more

2014 18th International Conference on Information Visualisation

1550-6037/14 $31.00 © 2014 IEEE

DOI 10.1109/IV.2014.56

125

comfortable in a coding environment rather than necessarily encourage them to code more.

Prior to this study, Adobe’s Flash ActionScript was used by the class as a teaching tool to create compiled Flash games for mobile devices. It was found that the layered format where code fragments work on a particular object or frame in Flash led to some confusion and obfuscation of the role of the code in the game’s design and execution. Finding the code and knowing what changes to make on which layers and objects in the Flash interface was also problematic. This made it particularly difficult for novices and beginners.

Existing tools for novice and beginner programmers of a HTML game include: stripped back languages (Tululoo); breaking the code into smaller segments specific to a particular task (Tululoo, GameSalad, Construct 2); or, use entirely graphical programming languages (GameMaker: Studio). Hence, to help novices and beginners explore programming for the purpose of creating a useful application, a HTML games editor that did not hide or obfuscate the code was developed. A games editor was used to expose students to coding because it leverages contemporary interest in playing games on mobile devices, thus providing the motivation to engage in the study.

Four existing HTML games editors were evaluated for their suitability and usability for novices and beginner programmers. It was found that, despite their developers’ claims of being suitable for novices, they either removed too much control from the user or relied on too much prior programming experience. Hence, a simplified HTML games editor was developed.

The HTML game editor developed was cycled through a series of evaluations until most of the difficulties reported by the novice users were resolved. It was thus possible in this process to observe how participants approached the task of learning the code necessary to produce a simple 2D game suitable for a mobile device. At the end of the evaluation cycling, most participants were able to achieve the initial goal set by the developers to complete a simple 2D game within one and half hours.

II. STUDY BACKGROUND

Few tools exist to help novices and beginners to create a 2D HTML game for a mobile device. The tools that are available either remove too much control from the user or are designed by programmers, using programming terminology and paradigms. In this study we attempted to create a tool that allows novices and beginners to create 2D HTML games.

Thirty-five second-year Interaction Design university students participated in this study. They were introduced to the core Interaction Design concepts via a series of projects and lectures. The concepts include understanding the user, designing for usability and usability testing. Students who took part in the course come from varying backgrounds and degrees ranging from Education and Media to Computer Science and Information Technology.

An audit of student mobile devices showed that touch-screen smartphones and tablets were the preferred choice of mobile device. Due to the different platforms these devices

operate on HTML was seen as a suitable method for supporting most mobile device types using the installed browser.

A. Goals

The goals were to:

• develop a 2D HTML game editor that novices and beginning programmers can, with little or no assistance, use to program a working 2D HTML game playable on a mobile device within 1.5 hours; and,

• provide the main JavaScript code in a format that is directly editable which can then be visualised in action as a game displayed on a mobile device via the device’s browser.

B. Definition of Novices and Beginners

To provide a HTML games editor for novice and beginner programmers we need first to define what a novice or beginner programmer is. According to the Oxford Dictionary, a novice can be defined as someone who is new to, or inexperience in, a certain task; and a beginner is someone who has just begun to learn or experience something new. The task that is reported in this project is the programming of a 2D HTML game for a mobile device. Therefore, we define a novice as someone who is new to or inexperienced in the task of programming a 2D HTML game for a mobile device; and the beginner as someone who has just begun to learn or experience the programming of a 2D HTML game for a mobile device. We can further differentiate the elements of the task into experience in programming a:

• mobile application;

• computer game; or,

• website. Of the 35 students who participated in this study, only 1

participant was not new to or inexperienced in the task of programming a 2D HTML game for a mobile device. The remaining 34 can be divided between those who are new to all, one, two, or three elements of the task. From this, we can define the participants as either novice, beginner, intermediate, proficient or expert. Only the participant who self-reported that they had experience in programming a 2D HTML game for a mobile device is considered expert. From this, we find there are 14 novices, 10 beginners, 8 intermediate, 2 proficient and 1 expert participant (see Tables 1 & 2).

TABLE I. NUMBER OF PARTICIPANTS BELONGING TO EACH USER

TYPE

User Type Count Total Experience in

Novice 14 none of the task elements

Beginner 10 24

1 of the task elements

Intermediate 8 2 of the task elements

Proficient 2 3 of the task elements

Expert 1

11

all of the task elements

126

TABLE II. NUMBER OF PARTICIPANTS WITH EXPERIENCE IN EACH

TASK ELEMENT

2D Mobile

application

Computer

game Website

2D 1 1 1 1

Mobile

application 1 3 3 3

Computer game 1 3 11 11

Website 1 3 11 21

Hence, more than half of the participants (24:11, N=35)

were either novices or beginners. The editor used in this study has been designed to meet their needs primarily. Intermediate, proficient or expert users’ feedback was collected. However, emphasis was on feedback and goal setting from the novices and beginners.

C. Scripting or Programming?

There is often confusion about the difference between scripts and programs. They are more similar than different. However, there are some fundamental differences. Scripting, such as JavaScript, is a high-level programming language that tells another low-level program what to do such as a program written in C++. C++ is a low-level programming language that compiles to machine code that controls the computer. The script is interpreted (explained, provides meaning to, or translated into computer language) by the program which has been compiled (assembled, organised, collated, or brings together all of the necessary elements to tell the computer what to do) so it can execute (carry out, finalise, or perform the task told to it by the program to do) the instructions given to it by the script.

Using a scripting interface, rather than a compiler per se (a program that processes statements into machine language or 'code'), the user can make simple changes to existing code (such as changing variables) without concern for the need to translate their intentions. Although, they do need to attend to syntactically (grammatically, structurally) correct sentences/statements peculiar to the scripting language used.

JavaScript was chosen as it is a fully-fledged scripting language which supports error messaging. It is a language which follows a logical structure and is easy to learn. However, syntax errors are still the primary source of frustration with programming for novices and beginners. JavaScript’s error messaging support ameliorates some of this frustration – at least providing a clear indicator of where (line number) and what type of error (eg syntax) has occurred in the script.

The application discussed in this paper uses scripting to assist novice and beginner learners use a scripting language to build a basic 2D game suitable for execution in a browser on a mobile device. It is crucial to ensure the novices experience programming at a level that produces visible results and is easy to learn, individually and in a group setting. Scripting provides the least intimidating interface for typing instructions to the computer [8].

Although scripting and programming differ in their depth and control of the computer, rather than using the terms scripting and programming interchangeably, for the sake of

consistency, henceforth, we use the term programming to imply scripting and/or programming.

III. HTML GAME EDITORS - AN OVERVIEW

Most of the existing tools available for HTML games creation are JavaScript libraries which provide short-hand functions for games programming. Programmers building HTML games typically use JavaScript libraries such as Impact.js, Crafty.js and Lime.js to speed up their programming. Few editors exist for the creation of games in HTML. The Graphical User Interface (GUI) editing tools that attempt to target novice and beginner programmers tend to suffer from some common problems. The most common problem is over-simplification (which removes control from the user) and/or the use of programming terminology that confuses novice and beginner users.

IV. METHODOLOGICAL FRAMEWORK

Of the many possible evaluation frameworks that could be used to evaluate a HTML games editor an abbreviated form of Heckel’s [3] principles was used. While other frameworks were reviewed [1, 2, 4] they were found to be either only suitable for guiding development or evaluating user needs, not both. The abbreviated form of Heckel’s [3] framework, on the other hand, is suitable for both evaluation of existing tools as well as the proof-of-concept tool. Heckel’s framework was suitable for this project as it provided a strong method to follow for both the tool’s development and evaluation. By following this method we were able to achieve the goal of producing a 2D HTML games editor usable by novices and beginners.

Heckel's framework succinctly captures all of the relevant information needed to ensure a usable product. Heckel’s principles can be summarised to:

1. What is the system for? 2. What are the features of the system? 3. How is the system used? 4. What are the problems with the system? 5. How could the system be improved?

In this case the ‘system’ refers both to an existing and a to-be-developed or improved system.

This 5-part framework was applied to each of the four existing HTML games editors evaluated. The goal was to gain a low level understanding of what was required for a HTML games editor suitable for novices and beginners; what are the common problems in existing editors and how these problems could be ameliorated.

Using the 5-part evaluation framework, many problems were found with the existing HTML games editors evaluated. These problems, and their proposed solutions, formed the framework for a new proof-of-concept (PoC) HTML games editor. The new PoC HTML games editor is designed for novices and beginners to be used in teaching low-level programming skills in an Interaction Design course.

To ensure a rigorous methodological approach, the 5-part evaluation framework was also applied to the Poc HTML games editor at each stage of the development process. This was cycled throughout the evaluation process in order to

127

create a tool that serves its purpose at a very low level. By cycling the process throughout development, the features included in the editor were all goal-driven so user's needs could be accommodated.

V. REVIEW OF EXISTING EDITORS

The existing HTML game editors evaluated for this project included:

• GameSalad (gamesalad.com)

• Construct 2 (scirra.com)

• Tululoo (tululoo.com) and

• GameMaker: Studio (yoyogames.com). These editors were selected as they allow the

programming of simple 2D games and exporting to HTML which can be played in a mobile device’s browser. These editors claim in their respective websites that the editor is suitable for the novice or beginner programmer.

A. Existing HTML Games Editor Evaluations

The 5-part abbreviated Heckel’s principles were used as a framework for evaluating existing HTML games editors. From this we found the following:

What is the system for? All tools can be used to create 2D games publishable to

HTML5. GameSalad, Construct 2 and GameMaker: Studio use drag-and-drop interfaces to allow the creation of games without direct coding. Tululoo uses simplified code, which the official website claims is user friendly.

How is the system used? On opening, all games editors require users to create an

object or actor. An image needs to be attached to the object or actor except for Tululoo and GameMaker: Studio which requires the user to create a sprite and then attach that to the object. Each games editor uses a different term to describe the canvas (in HTML5 terms) on which the graphics of the game are assembled: stage, layout, scene and room. Objects can have events, rules and behaviours assigned to them from a built in library, except for Tululoo which uses an online code generator. All games created can be tested before accessing via a mobile device, except Tululoo which requires the game to be saved first.

What are the features of the system? The features common to all editors are:

• drag-and-drop interfaces for placing objects onto the canvas area;

• support for audio as well as both still and animated images;

• example projects that show a working game in the editor; and,

• help - either in the form of a manual or tutorial. What are the problems with the system?

Problems varied across the different editors. All of the editors had interface related problems such as cluttered control panels that require extensive scrolling and poorly contrasting colour schemes. The editors also tended to use abstract programming terminology throughout their interfaces which, for novice and beginner users, could cause confusion.

How could the system be improved? Due to the abstract terminology used in all of the editors,

a suggested improvement was to simplify the language to lay terms. An alternative might be to provide simple explanations for the more complex terms. The intimidating interfaces could be improved by offering multiple layouts, such as a “basic” layout for beginner and an “advanced” layout for more experienced users. Another option might be to use progressive disclosure – hiding non-essential controls until they are requested by the user.

VI. PROPOSED PROOF-OF-CONCEPT EDITOR

From the analysis of existing editors a number of goals were identified for the creation of the proof-of-concept (PoC) editor used in this study. The goals of the PoC editor were established by applying Heckel’s 5-part framework to the initial concept design:

What will the system be for? The goal of the system is to:

• allow the user to program a simple 2 HTML game that will be playable on a mobile device;

• provide full control over the game code;

• provide a simple interface without any complex features; and,

• be useful in a pedagogical setting. What will be the features of the system?

Users will have full access to the code of their game to help them better make the connection between the code and its visualisation as a playable game and understand problems as they arise. It will run in a web browser on a PC. A selection of pre-coded games will be provided as PDF documents. Games will be playable on a PC (for testing) and mobile devices. The editor will feature support for both still and animated images (gif files).

How will the system be used? Users will first access the editor by logging in via a web

browser on a PC. They will copy and paste code from a provided tutorial PDF file into the editor and upload the supplied images. They will then save and preview their game in the editor. After testing their game they can make changes to their game code, saving as they go, and upload new images as needed. When they are satisfied with their game they can preview it on their mobile device by visiting a personal URL obtained from the editor.

What might be the problems of the system? Users may be intimidated by the code if they have had no

previous experience with programming. The users may also not know how to make desired changes to their game code or could encounter bugs when changing the code that they do not know how to fix.

How could the system be improved? The editor should feature an “undo” function to revert to

a previously saved state in the event of any bugs. The provided PDF game documents should be varied enough that the user could potentially copy code between games to make desirable modifications. A library of useful scripts – such as adding a power-up to a game – could be included. This could

128

be populated over time by recording requests for code from test users and adding them to the library.

A. A Proof-of-Concept Games Editor for Novices and

Beginners

From the evaluation studies of existing HTML game editors the initial proof-of-concept Games Editor for Novices and Beginners (GENB) was developed (see Figure 1). The GENB editor was built to suit the needs of novice and beginner programmers in an Interaction Design class. The class requires students to keep multiple code versions of their game as it progresses through their own evaluation studies. Four different versions of a game can be stored. Images can be uploaded for use in the game. A game preview popup panel is used which supports various different mobile device screen resolutions.

Figure 1. The initial version of GENB. Displayed is the code for an

example game, the game display and the various controls.

GENB is a web application written in HTML, PHP, CSS and JavaScript. Web was used as the platform for the tool as it provides flexibility for running both the tool and the games created with it. JavaScript was chosen as the primary coding language as it tends to be more forgiving than other programming languages for novices and beginners. For example, there is no need to focus on data types or include boilerplate code as in languages like Java. As a HTML tool, it also provides students with easy access to the editor outside of class as it is served externally. It features a coding area and testing emulator window rather than removing programming from the tool (such as in Construct 2 and GameSalad). The program is created in a way that supports core understanding of the underlying code. Giving students full access to the code - rather than a subset of pre-defined functionality (such as the behaviours in Construct 2) allows students to explore within the code parameters.

How novices and beginners used the interface was evaluated to determine the minimum functions that are needed for novices and beginners to program a basic HTML game. This was cycled and changes implemented as needed.

VII. CASE STUDY

GENB was evaluated over a series of Interaction Design classes. These classes included a major project where students were required to create a 2D game for their mobile device and refine the game over a series of evaluation studies.

There were two tutorial groups of approximately 17 students each. The students who participated in this study were completing the task as part of a graded assessment in the Interaction Design topic, hence they had a vested interest in using the tool to its full extent.

In total, five sessions were conducted with each tutorial group. Students worked together in groups of two to five to create and evaluate their mobile game. Students were able to work on their games outside of class, as the editor was served externally.

A. Demographics

A total of 35 students participated in the study (23 males and 11 females). Students ranged in age from 19 to 28. Of the 35 participating students, 23 self-reported having some previous programming experience, and 21 had previously made a website, mobile app or game. 27 students play games on a regular basis (5 hours or more per week spent playing computer, mobile or console games).

B. Setting

Classes took place over the course of a semester in a computer lab. There were enough computers for each student to work individually but groups tended to work on a single computer using a second computer for artwork. Each class lasted for two hours.

C. Method

Using the 5-part Heckel framework, students provided feedback via a proforma. Detailed descriptions of problems could be obtained and students were encouraged to propose solutions. Below is an example of a completed proforma sheet adapted from [5]:

Evaluator: User

Version: 1.0

Participant/s: 4 Date: 16/9/13

Rating: Intermediate

Problem: “I copied the code across but the

game isn’t working”

Screenshot (if applicable): N/A

Description: Users are receiving errors related to missing braces but are

unaware of what is causing the error. The general source of the problem is

users missing a brace when copying the code from the provided PDF files

Solution: Include more descriptive error messages such as “you may be

missing a brace at line x”.

Developer’s Comments: Print the JavaScript error message and show

line numbers.

D. Evaluation of GENB

GENB was evaluated in class over five sessions of two classes each. At each of the evaluation cycles changes were made to better accommodate the students concerns and needs. Heckel’s 5-part framework was again used to evaluate the final version of the tool after the initial evaluation cycling:

What is the system for? GENB was developed for creating simple 2D mobile

games in an educational setting. Novices and beginners should be able to create a basic, working, HTML game within one and a half hours.

What are the features of the system?

129

• 4 PDF tutorials on initial, complete games

• Users have full control over the code of their game

• The game code is highlighted for syntax

• The code for the example games is commented in lay terms

• Games can be play tested within GENB

• Games can be played on the user’s mobile device

• The editor runs in a web browser, and so requires no installation and minimal downloading

How is the system used?

• Access GENB through the browser of a PC

• Log into GENB

• Select the game version, starting with version 1.0

• Copy and paste code from the tutorial PDF

• Upload provided images to use as placeholder art

• Save the game and test it in the browser

• Make changes to the code

• Save and test the code at each stage in the browse

• Preview the game via the personal URL on the mobile device when ready.

• Iterate through game versions as needed What are the problems with the system?

Within the groups of 2-5 students each, typically the student with the most prior exposure to programming and scripting tended to fill the role of programmer.

It was noted that copying and pasting code from a PDF file caused difficulties, as it was easy to miss even a single character which caused the game to malfunction. Users also tended to add their own comments to the code, resulting in very large code files and clutter.

How could the system be improved? The system could provide users with a list of the

available games so each can be previewed. Selecting a game to use as a base game could then initially populate the user’s folder with the code and images for that game avoiding the need to copy and paste from a PDF document. The editor could also provide a space for notes which could reduce the need for over-commenting of the code.

E. Final Iteration of the HTML Games Editor

From the in-class evaluation studies the final iteration of the HTML games editor was produced. Evaluation cycling and iterative improvements made to the editor, included:

• line numbers;

• syntax highlighting;

• error messages;

• multi-file upload;

• greying out of background in preview mode; and,

• deleting stored images. Collectively, these improvements supported novices and

beginners by making the task of programming a 2D game for a mobile device as straightforward as possible and with logical assistance when errors occurred. Compared to the existing games editors reviewed, GENB leveraged their best features, removed the abstract features and focused on empowering the users to take control of the code for their own productive needs. There was little learning of the

interface needed and in the final version of GENB, participants could complete a basic game within one and a half hours (see Figure 2).

Figure 2. Screenshot of the final version of GENB with syntax

highlighting and line numbers.

VIII. DISCUSSION

Evaluation cycling resulted in fewer and fewer problems reported. This suggests that the feedback was reliable. The initial interface supported only JavaScript code, saving and previewing. Critical changes were made to the initial interface as a result of the cycled evaluation feedback. This included the key features: syntax highlighting; line numbers; saving hotkeys; multi-file upload; and deleting images.

While most students with little or no background in programming can be intimidated by a programming interface such as that used in this project, and despite some early reservations, most of the participants quickly learned how to use the interface to create the games required. Despite the restrictions that HTML places on the students’ creativity, compared to programming games in other languages, this also meant students tended to focus more on what was possible within well-defined parameters. This was due also to the effort required to make changes with JavaScript – particularly large gameplay changes. Students tended to make incremental changes, viewing the results as they went. Thus, students made connections between the code and what was displayed on the screen. This transition from the abstract to the concrete was almost instantaneous. Their enthusiasm for seeing the changes manifest in the game meant they did not dwell on their lack of ability with programming. Instead, they focused on the outcomes. This revealing of the code and the empowering that followed was supported by their use of the evaluation framework and key Interaction Design concepts introduced in class.

Furthermore, by displaying the code for the game as a single script rather than smaller code fragments, such as that used previously in Flash, students were better able to make connections between the code’s elements. Everything related to the game is both visible and editable meaning that students were given full control over the code for their game.

IX. CONCLUSION

GENB is a tool created to allow novice and beginner programmers to create a 2D HTML game for a mobile

130

device. Cyclical evaluation using an abbreviated form of Heckel's principles was used to establish a design concept and usability goals. Following this methodological approach, the core usability goal that a novice or beginner programmer could program a working 2D HTML game playable on a mobile device within 1.5 hours, with little or no assistance, was achieved.

From cycling the evaluation and implementing the necessary changes to the editor’s interface, it was found that the number of usability problems was reduced and the needs of beginners and novices were better accommodated for. The final tool gives users full control over the code for their game - allowing exploration and experimentation - whilst still being suitable for use by novices and beginners.

JavaScript proved to be a scripting language suitable for novices and beginners learning to program. Being able to visualise the results of their script changes connected the abstract code with a concrete, playable, game. Moreover, JavaScript’s logical structure and syntax error messaging proved crucial to overcoming perceived difficulties in programming.

The choice of a HTML games editor to help novices and beginners explore programming leveraged their interest in mobile gaming. This proved to be a critical motivating factor also. The games produced by the students were playable, enjoyable, and the students took pride in their new-found ability to program [17]. Most students commented at the beginning of the study that they were ‘overwhelmed’ by the amount of text (code) on the screen before them when initially engaging with the HTML games editor. At the end of the study students were asked if they still felt overwhelmed by the text editor. Most responded that ‘actually it was easier than I thought’. Many suggested they felt ‘confident to try to make a new game [without assistance]’.

By providing the game as a visual representation of an otherwise abstract construct (the code) we were able to make students more comfortable in a coding environment. Students who were apprehensive to make changes at first gained a better understanding of how small changes could have a large impact. Students started to become aware of the fact that they did not need to understand every single line of code in the game’s script in order to make their desired changes.

It would be interesting to compare the method outlined in this paper with a similar process using ‘live coding’. The pedagogical benefits of each method could be compared against a control group using traditional methods (raw coding in notepad or other text editing software).

REFERENCES

[1] D. Benyon, P. Turner & S. Turner, "Designing interactive systems: People, activities, contexts, technologies," Pearson Education, 2005.

[2] H. Beyer & K. Holtzblatt "Contextual design: defining customer-centered systems," Access Online via Elsevier, 1997.

[3] P. Heckel "The Elements of Friendly Software Design," SYBEX Inc., 1991.

[4] J. Preece, Y. Rogers, & H. Sharp, "Interaction Design: Beyond Human-Computer Interaction," 2nd edn, John Wiley & Sons Australia, Limited, 2007.

[5] Gamasutra - Better Games Through Usability Evaluation and Testing. [ONLINE] Available at: http://www.gamasutra.com/view/feature/130745/better_games_through_usability_.php?print=1. [Accessed 22 August 2013]

[6] J. Dewey, Experience & Education, New York: MacMillan, 1957.

[7] C. Kelleher, & R. Pausch, “Lowering the Barriers to Programming: A Taxonomy of Programming Environments and Languages for Novice Programmers,” in ACM Computing Surveys, Vol. 37, No. 2, 2005.

[8] D. Norman, “Cognitive engineering,” In Norman, D. & Draper, S., Eds. User Centered System Design: New Perspectives on Human-Computer Interaction. Lawrence Erlbaum Associates, Hillsdale, NJ, 1986.

[9] J. Stasko, A. Badre, & C. Lewis, "Do algorithm animations assist learning? An empirical study and analysis," In: Proceedings of ACM INTERCHI'93 Conference on Human Factors in Computing Systems ACM Press, New York, pp. 61-66, 1993.

[10] J. F. Pane, B. A. Myers, & L. B. Miller, "Using HCI techniques to design a more usable programming system," In: Proceedings IEEE 2002 Symposia on Human Centric Computing Languages & Environments IEEE Computer Society, Los Alamitos, pp. 198-206, 2002.

[11] M. Kölling, B. Quig, A. Patterson, & J. Rosenberg, "The BlueJ system and its pedagogy," Journal of Compuer Science Education 13, 249-268, 2003.

[12] M. Carlisle, T. Wilson, J. Humphries, & S. Hadfield, "RAPTOR: A visual programming environment for teaching algorithmic problem solving," In: Proc. ACM SIGCSE 2005 Symposium ACM Press, New York, 2005.

[13] T. R. G. Green & M. Petre, "Usability analysis of visual programming environments: A 'cognitive dimensions' framework," Journal of Visual Langauges & Computing 7, 131-174, 1996.

[14] C. D. Hundhausen & S. A. Douglas, "Low fidelity algorithm visualization," Journal of Visual Languages & Computing 13, 449-470, 2002.

[15] C. D. Hundhausen & J. L. Brown, "Personalizing and discussing algorithms within CS 1 Studio Experiences: An observational study," In: Proc. 2005 International Computing Education Research Workshop ACM Press, New York, pp. 45-56, 2005.

[16] J. P. Chin, V. A. Diehl, & K. Norman, "Development of an instrument measuring user satisfaction of the human-computer interface," In: Proc. 1988 ACM SIGCHI Conference on Human Factors in Computing Systems ACM Press, New York, pp. 213-218, 1987.

[17] C. Kelleher & R. Pausch, "Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers," ACM Computing Surveys 37, 83-137, 2005.

[18] K. Kahn, "ToonTalk: An animated programming environment for children," Journal of Visual Languages & Computing 7, 197-217, 1996.

[19] A. Ko & B. Myers, "Designing the Whyline: A debugging interface for asking questions about program failures," In: Proc. ACM SIGCHI 2004 ACM Press, New York, pp. 151-158, 2004.

[20] P. Brusilovsky, E. Calabrese, J. Hvorecky, A. Kouchnirenko, & P. Miller, "Mini-languages: A way to learn programming principles," Education & Information Technologies 2, 65-83, 1997.

[21] E. Wilcox, J. Atwood, M. Burnett, J. Cadiz, & C. Cook, "Does continuous visual feedback aid debugging in direct-manipulation programming systems?" In: Proceedings CHI '97 ACM Press, New York, pp. 258-265, 1997.

[22] C. D. Hundhausen & J. L. Brown, "What You See Is What You Code: A radically dynamic algorithm visualization development model for novice learners", In: Proceedings 2005 IEEE Symposium on Visual Languages & Human-Centric Computing IEEE Computer Society, Los Alamitos, pp. 140-147, 2005.

131