Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer Science
Master thesis, 30 ECTS | Informationsteknologi
2016 | LIU-IDA/LITH-EX-A--16/051--SE
Gameful design through The
Lens of Intrinsic Skill Atoms
Jakob Bäcklund
Supervisor : Anders Fröberg Examiner : Erik Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Abstract
Creating applications and systems that effectively motivate users is very important both in business and education. Using design practises from game development in non-game settings to exploit its ability to engage players has become increasingly more popular in recent time to attract and encourage users. This study examines how to effectively and systematically develop an application using a method based in both game design and inter-action design to develop a learning application for programming. The results demonstrates the strengths of the applied iterative prototyping and powerful design tools of the specific method in a smaller scale project as well as the weaknesses of the vague description of tool usage with risk of derailing in the design steps.
Acknowledgments
I want to thank anyone who helped me in completing this study, especially those who partic-ipated in any playtesting session and delivered valuable feedback.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables 1 1 Introduction 2 1.1 Motivation . . . 2 1.2 Purpose . . . 2 1.3 Research questions . . . 3 1.4 Delimitations . . . 3 2 Theory 4 2.1 Teaching Programming . . . 4 2.2 Games . . . 6 2.3 Gameful Design . . . 8
2.4 Methods for Gameful Design and Gamification . . . 9
3 Method 14 3.1 Design method . . . 14 3.2 Implementation . . . 16 3.3 Evaluation . . . 16 4 Process 17 4.1 Strategy . . . 17 4.2 Research . . . 17 4.3 Synthesis . . . 18 4.4 Ideation . . . 18 4.5 Storyboarding . . . 20 4.6 First Iteration . . . 21 4.7 Second Iteration . . . 24 4.8 Third iteration . . . 28 5 Results 30 6 Discussion 31 6.1 Results . . . 31 6.2 Method . . . 32
7 Conclusion 34
List of Figures
2.1 Example of code blocks in Scratch. . . 5
2.2 Screenshot of the intrinsic version of Zombie Division. . . 7
2.3 The Lens of Curiosity. . . 11
2.4 General structure of a skill atom. . . 11
2.5 General structure of Deterdings skill atom. . . 11
2.6 The lens of intrinsic skill atoms. . . 12
2.7 Five steps in gameful design. . . 13
4.1 Simple sketch of the general level structure. . . 21
4.2 Main page with the first topic completed. . . 22
4.3 Completed basic task. . . 22
4.4 Error message. . . 22
4.5 All four test cases passed. . . 23
4.6 Four failing test cases. . . 23
4.7 Main page with the first snake mastered. . . 24
4.8 Rewards for finishing the first quest. . . 25
4.9 A challenge where usable functions are offered. . . 25
4.10 The names and a short description of the usable functions seen in Figure 4.9. . . 25
4.11 Main page message with no completed chapters. . . 28
4.12 Error message in case of "NameError". . . 29
4.13 Hint given to the problem of sorting a list. . . 29
4.14 The solution for the last level shown. . . 29
List of Tables
1
Introduction
1.1
Motivation
Programming is a very attractive skill in today’s labour market and the demand for com-petent programmers has increased steadily for years. Learning programming is however something that generally is seen as difficult and is said to take ten years of experience to be-come an expert in. Turning novice students into expert programmers over a course of about 4 years in computer science educations is stated as impossible [39]. To generate a bigger flow of competent programmers into the market and to raise the level of skill they possess it is important to get people interested and involved in programming.
By forming a genuine interest of software development, the popularity of programming classes and educations could be increased. It could also lead to people experimenting with software developing projects outside of school, work or other organised activities which is a good way of learning programming. By also teaching people basic programming skills they have somewhere to start from and knowledge to further develop.
Games and electronic games in particular have a certain way of engaging and motivating its users to continue playing and learning the game without much of external rewards. This has been picked up by researchers, designers, teachers among others and using games for other purposes than just enjoyment has become increasingly popular in recent years. Vari-ously advanced learning games exists in a number of forms for many different types of fields. Game design has also found it’s way into interaction design in the form of gameful design or "gamified" applications as a way to try exploiting the motivating and fun factors that comes with games.
1.2
Purpose
The purpose of this study is to examine how to create an engaging computer application to spark an interest of software development and teach people basic programming skills by incorporating practises from game design.
1.3. Research questions
1.3
Research questions
Learning something new can be very challenging and confusing, being motivated and stim-ulated all the way is important in order to keep working and achieving good results. Being given relevant information, examples and problems is important to learn skills and correct practises but is often not enough to be motivated and stimulated. Good digital games are very effective in stimulating and engaging it’s users, how could these practises be used to motivate people while teaching them something new?
1. How can a learning application be designed to be gameful in order to engage and mo-tivate users?
2. How can a system for learning programming effectively be developed?
1.4
Delimitations
The focus of this study is to examine how to develop a motivating educational system using gameful design, some effort is put in how to learn programming but this is not the focus. The scale and ambition of the implementation have to be limited to what a single person is capable of developing alone in the given time of the project. I have little to no experience in creating graphical content in form of electronic pictures and animations which will limit the inclusion of original visual content.
2
Theory
2.1
Teaching Programming
Most people have some form of connection to software via computers, smartphones or tablets but few has any greater knowledge of how the applications actually work. Software devel-opment is a very large field with a wide range of technologies, languages and terminology. Learning programming from scratch can therefor be seen as difficult and intimidating. Jenk-ins finds that a lot of students dread programming and describes how his job as a teacher shifted from presenting information and syntax to a role as motivator to engage student in programming activities [16].
Programming Languages for first-timers
There is a large number of different programming languages developed to suit various needs available today. Some languages have very specific purposes while others suits an array of situations. There is also some languages that are specifically made to be easy to learn for beginners and act as gateways to programming.
Scratch
Scratch is a programming environment that is aimed at novice programmers and especially children. Scratch focuses on media manipulation and require very little writing, instead the users combine predefined command blocks to create heaps of blocks similar to assembling puzzle pieces or building blocks. Blocks can be sequentially lined up in certain orders or ex-ist unordered with a specified action or command that triggers them. Such blocks could for example include manipulating objects, conditional statements or mathematical expressions. This can be used to create games, movies, interactive stories or presentations. The different command blocks are shortly described in English and are easy to understand, they can also be run by simply clicking them which offers the user an easy way of testing the code. This makes for an intuitive environment and learning Scratch can be done by experimenting with different blocks and combinations with relative ease. A study of children learning program-ming through Scratch in an after-school-center shows how the youth independently develop their skills [23]. Very little was explicitly taught to the youth, instead they experimented with their own chosen projects and were only assisted by mentors on request. The study shows
2.1. Teaching Programming
Figure 2.1: Example of code blocks in Scratch.
what kind of commands that were most frequently used and discovered a usage increase of less intuitive commands the more experience the user obtained. Some type of concepts such as variables seemed hard to grasp for the children but started to be used more once a knowledgeable mentor had shown them how they could be used.
Python
Python is an open source project that can be described as a dynamic, object-oriented script-ing language [30]. Bescript-ing a scriptscript-ing language it is simple and easy to use and read, dynamic typing means that is doesn’t require type and size declarations which slims down the syn-tax. Python provides more advanced programming tools than normally found in scripting languages which makes it more powerful for larger applications. Some of these tools are built-in object types such as lists and dictionaries, tools like sorting and concatenation, li-braries and third-party utilities. Python is an interpreted language which makes it possible to run the code or parts of the code without compiling entire programs, this makes it easy to experiment and test code as you go. Python is a high level language which hides a lot of whats going on in the background, this makes it easier to grasp for a novice since you do not need to know a lot of syntax and technicalities to program simple things. The language is widely used for scripting and web applications which makes it a very useful language to know. There is also a big community around Python that is constantly developing new tools and libraries that can be used, posting a numerous of guides and examples on the Internet and helping beginners to learn the language. The simplicity and yet powerfulness of the lan-guage combined with the widespread use of Python makes it a very popular lanlan-guage for first-time learners [15] and in 2014 Python was the most common language that was taught in the first programming class among the highest rated Universities in the United States [13].
Java
Java is a strongly typed object-oriented language that is designed to be portable and runnable on as many platforms as possible. It is one of the most used programming languages in the world which makes it a very useful skill for programmers. Java gives a decent view of what is going on in the background and gives the programmers good tools to keep the code well structured. Since it is strongly typed and designed as a very robust language the programmer needs to have more knowledge about what is going on to do simple things than in Python since you often need to use more code and syntax in Java and the code must be compiled to be able to run which demands a bit of instantiation and overhead. Java is still a very popular first programming language since the learner get a good grasp of how to think logically like a programmer and how programs are computed and run which can later be translated to other languages with rather ease [15].
2.2. Games
2.2
Games
Games of today come in a multitude of shapes and forms on more platforms than ever be-fore. We have the more traditional games outside on courts and streets, boardgames, card games or games with just pen and paper to electronic games on computers, consoles and mobile phones. Games can be played alone or with thousands others in massive multiplayer games, they can revolve around an elaborate story or completely lack one, have a clear end-point of when the game is finished or continue endlessly. Even though games can be so different we can easily distinguish when we are playing a game. McGonigal proposes that all games share four defining traits: a goal, rules, a feedback system and voluntary participation [24]. The goal is something to work for and gives the player a sense of purpose, the rules describes what the player can and cannot do on the way to the goal, this encourages some form of strategic thinking and practise. The feedback system lets the player know well it is performing or gives an indication of some form of progression in the game, this provides en-couragement and motivates the player to keep playing. Voluntary participation implies that all participants willingly accepts the goal, rules and feedback which allows multiple players simultaneously. The freedom to enter or leave the game at any time ensures that the experi-ence is viewed as entertaining and not mandatory. Suits offers another less precise definitions of games: "playing a game is the voluntary attempt to overcome unnecessary obstacles" [36]. This sums it all up in a sentence in a convincing manner implying that games are simply a form of accomplishing some tasks for entertainment. This is a much wanted behaviour of users of any application, the urge and motivation to continue using the application voluntarily. The four traits described by McGonigal are something to look for and use when trying to implement game-like elements.
Motivation in Games
To recognise what makes people want to play games for hours and hours it is important to know what we humans are motivated by. A well researched theory of this with empirical support is the self-determination theory which proposes that all human beings have a funda-mental psychological need for competence, autonomy and relatedness to others[31].
Competence relates to a persons sense of skill and ability to perform and accomplish de-sired things in the world. Autonomy is the feeling of acting consciously and willingly to-wards one’s own goals and needs, to fully agree with the activity one is engaged in and relatedness is the need of feeling a meaningful connection to others.
The self-determination theory gives us some form of guidelines to work around and a mo-tivational model of video game engagement based in self-determination theory was proposed in a study by Przybylski, Rigby and Ryan [29]. The study examines how gaming experiences viewed as fun and enjoyable are correlated to the fulfilment of fundamental psychological needs, common game elements such as violence is not found to be a significant motivating factor. This is an appropriate model for game elements in a non-game setting since it connects to basic human psychology, not content bound characteristics and it is based in well studied and accepted theories. Games relates very well to the need of competence since they revolve around challenges as discussed earlier [36][24], this makes up for a good opportunity to learn and most games capitalize on this by gradually increasing the difficulty of challenges in the game. This lets the player learn the strategies and skills needed to improve and succeed in the game. Game challenges also offers autonomy by letting players choose which challenges to tackle and how to conquer them given the aspect of voluntary engagement in the game. The need of relatedness may also be fulfilled if the challenges involve or affect other players in the game. This gives us several aspects to take into account when designing game chal-lenges such as creating learning curves that are not so steep that the player gets overwhelmed and frustrated by not making progress in the game nor so flat that the player gets bored of not fulfilling the need of competence. This phenomena of users seeking an optimal mix of
2.2. Games
challenging but not to difficult tasks is called flow [6] and is quite common when discussing motivation in games [19][25][14][8].
Learning in Games
Games are not only excellent in entertaining people, Norman argues that games generally upholds the essential needs for educational means and that they can create an engaging edu-cational environment [27]. Using electronic games for eduedu-cational purposes has been around since the 1950’s [7] and it has become more and more common in recent years with the im-proved technology and increased popularity of computer games. In 2001 Prensky proposed that computer games was a better way to approach students as it spoke to their habits and interests [28].
Habgood and Ainsworth analyzed the effectiveness of intrinsic integration in learning games by developing three versions of the mathematical learning game Zombie Division, playtesting it with children in the ages 7-11 [14]. In the intrinsic version mathematical ques-tions was integrated into the gameplay, in the extrinsic version the quesques-tions were given in be-tween game levels and the questions were removed all together in the control version. Intrinsic integration in learning games builds on the concept "intrinsic motivation" which means that people are intrinsically motivated to engage in activities where there is no apparent reward more than the activity itself. The study showed that the intrinsic version was the most appre-ciated and they argue that it is the core mechanics of a game that is essential to creating a intrinsic relationship between the game and educational content, not fantasy or story.
Figure 2.2: Screenshot of the intrinsic version of Zombie Division.
Kapp identifies 7 different types of knowledge or skills and existing learning techniques that are effective for each type [18]. He explains that designing gameplay that incorporates any of these different techniques in the form of challenges and game mechanics is an effec-tive way to teach the targeted knowledge or skill. Declaraeffec-tive knowledge, also known as factual knowledge is information that can only be learned through memorization, some examples are facts, terminology, acronyms and syntax. Learning declarative knowledge revolves around memorization techniques such as repetition, association, organizing facts into groupings and elaboration, linking information to a known context. An example game technique related to elaboration is creating a story which introduces information to the player in a
deliber-2.3. Gameful Design
ate context and order which encourages the player to memorize the information in order to progress and excel in the game. Conceptual knowledge is a group of related objects or ideas that share one or more common attributes, for example the concept of customer service or money. Concepts are usually taught using describing metaphors, examples and counter examples or describing relevant defining attributes of the concept. Rules-based knowledge is the informa-tion of relainforma-tionships between concepts, rules define a preferred behaviour with predictable results, a common structure of rules are "if/then" which may explain the effects of an action or fact. Common teaching techniques for rules are providing examples and role playing sit-uations where the rules apply. Procedural knowledge are ordered step-by-step instructions for performing certain actions to achieve a specific result. Organizations are filled with proce-dures to be followed and are often taught by starting with the big picture to put it in a context and teaching how and why of the procedure. Soft skills or principles are guidelines for be-haviours in social interactions including for example negation skills and leadership skill. Soft skills may be taught using analogies to existing knowledge or taking the role of a person in a certain situation where the skills are needed. Affective Domain is the domain of attitudes, values, beliefs and emotions. Most of these are things you may think need no teaching but research has shown that pro-social games can have a very positive effect in influencing be-haviour by for example encourage participation or showing possible success. Psychomotor Domain is the combination of physical skills and the cognitive plane, knowing when to dou-ble or single click on a computer or knowing how turning a steering wheel will affect the car. This domain is commonly learned through observing the skills being used by someone else and by practicing. [18]
2.3
Gameful Design
If gamification is the means of using game design elements then gameful design is typically the end result [8]. Designing for motivation and enjoyment has become increasingly more popular in recent years and this is exactly what gameful design is aiming for. The basic prin-ciple of gameful design is to mimic the way games motivate people by fulfilling their basic psychological needs and incorporate these elements in a non game system. When bridging game design with interaction design a essential problem appears since they contradict each other in an essential aspect.
Interaction design is focused around making human computer interaction as simple, easy and friction free as possible [11] which contradicts the definitions of games where players are exposed to challenges for the sake of challenges [36]. This infuses the difficulty of adding motivating challenges in appropriate forms and situations, this is an issue that also exists in the world of games, the game itself should not be difficult to use but the gameplay in it should be challenging. Juul and Norton [17] examines this idea that a good game should have a easy to use interface and difficult gameplay but argues that it is not always the case as the difficulty of using the interface sometimes is a part of the gameplay experience. This is possible since games are not designed to accomplish something of significance outside of the game. As gameful design mixes both interaction design and game design it should both be simple to use and challenging at the same time but for example adding puzzle challenges to an already confusing part of a system would not be appreciated by most users. Gameful design must be approached differently and to combine these two design styles one should not create new challenges in the system but instead identify natural, preferably skill-based, challenges in the system, repackage and present them in a interesting and motivating fashion [8]. Gameful design in a learning context should identify what type of skills or information that is to be taught and design appropriate challenges and game mechanics in order to teach this [18].
2.4. Methods for Gameful Design and Gamification
2.4
Methods for Gameful Design and Gamification
The term gamification started to be widely adopted in 2010 [9] alongside with parallel terms that are still invented and somewhat used, terms like "funware" [37], "playful design" [12] and "behavioral games" [10]. In spite of this gamification is arguably the most commonly used term and has been defined as "the use of game design elements in non game contexts" [9]. When defining gamification in their study, Deterding and his colleagues puts emphasis on the relation to games, not play as it denotes a broader more free-form of behavior than gaming. They also explain the meaning of game design elements as elements that are characteristic for games, where they are found in most games but not necessarily all and serve a significant purpose in gameplay. The study defines five levels of abstraction in game design elements according to Table 2.1. The listed game design elements are merely tools to be used and the study states that gamification is a term for means of using game design elements in non game contexts where gameful design is typically the end result [8]. Gamification is often used to transform an already existing non game system into a "gamified" system with game-like elements.
Level Description Example
Game interface design patterns
Common, successful interaction design
components and design solutions for a known problem in a context, including prototypical im-plementations Badge, leaderboard, level Game design patterns and mechanics
Commonly reoccurring parts of the design of a game that concern gameplay
Time constraint, limited resources, turns Game design
principles and heuristics
Evaluative guidelines to approach a design prob-lem or analyze a given design solution
Enduring play, clear goals, variety of game styles
Game models Conceptual models of the components of games or game experience
MDA; challenge, fantasy, curiosity; game design atoms; CEGE Game design
methods Game design-specific practices and processes
Playtesting, playcentric design, value conscious game design
Table 2.1: Levels of Game Design Elements [9].
Most research on gamification and methods for gameful design revolves around what characteristics and design values to strive for [26], some ideas of what kind of dynamics and aspects of game elements that works in certain gamification situations [21], but most research lack a distinct design method. Aparicio, Vela, Sánchez and Montes [1] propose a four-step gamification process based in self-determination theory but the process is vaguely and narrowly described and leaves out how to choose and adapt game mechanics to the system. "Smart gamification" [20] is the earliest documented industry method which revolves around creating a "player persona" and constructing a "player journey" containing goals and challenges on three levels of involvement in novices, experts and masters. A number of later methods has followed in it’s tracks [40][38][18][22][3] which all proposes a design process similar to the following one compiled by Deterding [8]:
1. Identify system owner goals.
2. Identify trackable behaviors of end users that support these goals; quantify their relative contribution in a metric.
2.4. Methods for Gameful Design and Gamification
4. Select and specify game design patterns:
a) Translate the quantified system owner value of end user behaviors into point val-ues displayed back to users.
b) Articulate an ordered sequence of explicit goals for end users, consisting of sets of behaviors or point thresholds (quests, challenges, levels).
c) Define feedback to display upon single user actions (“engagement loop”) as well as reaching point thresholds or goals (achievements, badges, leader boards), in-cluding potential rewards (virtual items, customization options).
5. Choose additional game design patterns. 6. Playtest.
7. Build and deploy.
8. Use analytics of user behaviors to monitor system performance and guide the improve-ment and release of new content and features.
But these methods falls short in some aspects as they skip to identify skill-based chal-lenges in the system, fail to describe how to select appropriate game patterns and lack fun-damental interaction design steps like iterative prototyping according to Deterding who pro-poses another design method, the lens of intrinsic skill atoms [8]. The method builds on three concepts: design lenses, skill atoms and intrinsic integration. Intrinsic integration is the idea that gameful design should build on inherent user goals in the system, the other two concepts will be explained in the following sections.
Design Lenses
Design lenses was developed in 2008 by Schell [32] as a way to examine and analyze game design without taking your own personal tastes and thoughts in to much account. A design lens is represented by a small set of questions which you should ask yourself about your game to analyze one certain design principle. For example see Schells "Lens #4" in Figure 2.3 which is created to analyze how your game sparks curiosity. Throughout the book Schell in-troduces 100 different design lenses each dedicated to a different perspective with the idea of combining a multitude of single purpose lenses to see the whole picture of your game design. Scott later saw the potential of using design lenses in other areas than games and defined 3 design lenses of different nature to show how design lenses can be useful in everyday design [33].
Design lenses does not offer specific solutions or describe how to make design choices. By consisting of questions the design lenses simply helps designers look at their work from specific points of view and shed light on all design aspects in a deliberate manner. This makes the lenses versatile and makes them appropriate for various design and domains, the lenses are not only confined to detecting issues but can also be used to further improve and develop already good parts of a design.
Skill atoms
Skill atoms is a self contained representation of feedback loops regarding skill based activities in games [5]. Cook describes a structure of event loops where the player makes a move, the game simulates the chosen action, gives feedback to the player who uses the information to update her perceived model of the game illustrated in Figure 2.4. He argues that this is how players are motivated to learn the skills and rules in a game, through practise and not through reading a manual.
Deterding takes the concept a step further by adding additional factors to the process and puts focus of the atoms on challenges [8]. The refined skill atom is illustrated in Figure 2.5 where the challenge is centered even though the purpose of the atom is still to represent how skills in the game are acquired.
2.4. Methods for Gameful Design and Gamification
Figure 2.3: The Lens of Curiosity [32].
Figure 2.4: General structure of a skill atom [5].
Figure 2.5: General structure of Deterdings skill atom [8].
To give an example take the classic word game Scrabble: the Goal is to have the most amount of points when the game is over. The actions are placing the tiles with letters on the
2.4. Methods for Gameful Design and Gamification
board (objects), the rules specify where you can lay which tiles, since they has to form valid words, how much points they give and when the game is over. The user get feedback in the form of points of all players and the challenge is placing tiles in a way that you gain a lot of points while not giving the other players opportunities to score more points than you. The motivation is generally competence need satisfaction.
The Lens of Intrinsic Skill Atoms
By combining the three concepts of skill atoms, design lenses and intrinsic integration Deter-ding landed in The Lens of Intrinsic Skill Atoms which is shown in Figure 2.6. The lens describes the elementary purpose of gameful systems and delivers essential questions to frame the core components of gameful design. The lens is quite broad and targets the entire design process as opposed to Schell [32] who developed a multitude of more narrow lenses. The lens is meant to be the at center of the gameful design method, outlining the goals, challenges and critical aspects of the design and to be used to target activities, generate ideas and analyze while iteratively prototyping but not to completetly eliminate the use of other skill atoms and lenses. Both skill atoms and additional design lenses are necessary to the design process in structuring motivational challenges and improving all aspects of the system.
In pursuing her needs, any user’s activity entails certain inherent, skill-based challenges. A gameful system supports the user’s needs by both directly facilitating their attainment, removing all extraneous challenges, and by restructuring remaining inherent challenges into nested, interlinked feedback loops of goals, actions, objects, rules, and feedback that afford motivating experiences.
1. What motivations energize and direct the activity?
2. What challenges are inherent in the activity? What challenges can be removed through automation or improving usability? What challenges remain that the user can learn to get better at?
3. How does my system articulate these inherent challenges in goals? (How might it articulate them to connect to the user’s needs and motivations?)
4. What actions does my system offer the user to achieve these goals? 5. What objects can the user act on to achieve these goals?
6. What rules does my system articulate that determine what actions are allowable and what system changes and feedback they result in?
7. What feedback does my system provide on how successful the user’s actions were and how much progress she has made towards her goals? (How might I make this feedback clear, immediate, actionable, speaking to the user’s motivations, affording a sense of competence?)
Figure 2.6: The lens of intrinsic skill atoms [8].
Design steps
Deterding proposes a design process that consists of five steps that exists in two variations, innovation and evaluation, where innovation is adapted to a process to create a completely new system and the evaluation variation is used when transforming an existing system. Fig-ure 2.7 shows the five steps of the innovation variation [8].The process is quite intuitive and is based on identifying and analyzing the user’s needs, what purpose the system should serve and what kind of challenges that arises with it. From there create skill atoms, generate ideas and develop them using design lenses, continue with iterative prototyping until satisfactory
2.4. Methods for Gameful Design and Gamification
1. Strategy
a) Define target outcome and metrics b) Define target users, context, activities
c) Identify constraints and requirements 2. Research
a) Translate user activities into behaviour chains (optional) b) Identify user needs, motivations, hurdles
c) Determine gameful design fit 3. Synthesis
a) Formulate activity, challenge, motivation triplets for opportune activities/behaviours
4. Ideation
a) Brainstorm ideas using innovation stems b) Prioritze ideas
c) Storyboard concepts
d) Evaluate and refine concept using design lenses (optional) 5. Iterative Prototyping
a) Build prototype b) Playtest
c) Analyze playtest results
d) Ideate promising design changes
Repeat steps a-d until desired outcome is achieved
Figure 2.7: Five steps in gameful design [8].
results. Deterding mentions that skill atoms and design lenses are meant to be used through out the process where it is suitable but little of this is explicitly mentioned in the steps.
3
Method
3.1
Design method
I have chosen to use a version of Deterdings design method [8] adopted to my context, goals and resources for developing the system. The following steps are based on the process de-fined by Deterding but I have chosen to skip or alter some parts:
1. Strategy
a) Define target outcome and metrics
Define the purpose and goals of the system and deciding how to evaluate it, further explained in Section 3.3.
b) Define target users, context, activities
Define the target audience and what the base of the application will be using existing programming tools as models.
c) Identify constraints and requirements
Delimit scope, budget and technical requirements has more or less been done before beginning with the design process as it was a part of planning the study from the be-ginning but it is still an important part of the process.
2. Research
a) Identify user needs, motivations, hurdles
Identify what generally motivates people to learn programming and what keeps moti-vating people who have started learning. Also to examine what types of anxieties and difficulties are generally associated with learning programming.
3. Synthesis
3.1. Design method
This step is adopted to better fit the context of learning programming. Formulating activity, challenge, motivation triplets does not seem very productive since the entire system will revolve around the activity of learning programming and the general moti-vation behind this. Therefor the focus will be to identify the skill types defined by Kapp [18] and inherent challenges in the activity. These types and challenges will be used in the brainstorming step and to serve as a base for creating skill atoms.
4. Ideation
a) Brainstorm ideas using innovation stems
Brainstorm how to make the generated activities exciting and motivating while still being informative and educational using innovation stems. Innovation stems is a tech-nique to inspire people to think in different ways to generate ideas. The basic idea is to combine different concepts to force the thought process in a certain manner. Some ex-amples are: "How might the system spark <motivation> in <challenge>?", "It’s like <existing game> for <activity>." and "How might I make <challenge> more exciting using <lens>?". A number of suitable skill atoms and design ideas of the system as a whole will be created from this.
b) Prioritize ideas
Since I am alone in this project, prioritizing will not consist of voting of any kind but will be fairly straight forward in selecting the ideas thought to work best for the system.
c) Storyboard concepts
The highest prioritized ideas will be further developed and illustrated with sketched storyboards visualizing goals, actions, objects, rules, feedback, challenge and motiva-tion. The sketches will be fairly basic due to my lack of experience in sketching and might be complemented with descriptions or pictures from other contexts, the impor-tant part is that the concept becomes more concrete and well thought trough. Various design lenses and mainly the lens of intrinsic skill atoms will be used to assure that the design is gameful.
d) Evaluate and refine concept using design lenses
Design lenses will play it’s part in earlier steps including storyboarding but an extra glance will be taken on the storyboards through the lenses to confirm that they are gameful and appropriate.
5. Iterative Prototyping a) Build prototype
This will be explained in Section 3.2. b) Playtest and Analyze playtest results This will be explained in Section 3.3.
c) Ideate promising design changes
The analyzed results will give an idea of what works in the application and what needs improvement, this feedback will be taken into consideration and some parts of the ap-plication will possibly be chosen to be in full focus when starting the next iteration.
3.2. Implementation
I skipped Deterdings steps Translate user activities into behavior chains and Determine gameful design fit in the Research step as I did not see behavior chains as a valuable asset to my project. Determining gameful design fit has been more or less done before starting the study and since implementing a gameful system is one of my research questions aborting this is not really an option, I will instead analyze the gameful fit in chapter 6.
3.2
Implementation
I have chosen to implement the system as a web application hosted by an open web server to make it easier to distribute to people in other locations than myself as it only requires a web browser and an Internet connection. It is also quite easy to create graphic content with HyperText Markup Language (HTML) and Cascading Style Sheets (CSS), the game logic is implemented with JavaScript, jQuery and Skulpt[35] which is an in-browser implementation of Python. The server is written in Python with the web framework Flask.
3.3
Evaluation
In the end of each iteration I will evaluate the application by letting people playtest it and evaluate their experience. I will try to find people in the target audience of non-programmers that want to learn to playtest but I will also let other people be test the prototype to get another point of view and opinion on aspects like programming practices. I will have to adopt the length of the playtest sessions to how big the application is at the moment and how difficult it is for the user to take in the content. Since it is not just a simple application to click through but I actually want the users to be challenged and to learn a bit of programming since I am interested in their capability of doing so and what they think about the experience.
User evaluation will be done in two different ways, the evaluation in the first couple of iterations will rely on interviews and discussions as I am interested in details of the user experience, what exactly was found difficult, confusing, good or too easy and possibly why. This will give me a better grasp of what to change and add to the next iteration as I can ask follow-up questions unlike in a question form.
The evaluation of the final version is done using Intrinsic Motivation Inventory (IMI) [34] which is an evaluation tool used to measure subjective experiences related to user ex-periments. The instrument is widely used in experiments related to intrinsic motivation and is well grounded in motivational theory and research. The evaluation scale is divided into seven categories: Interest/Enjoyment, Perceived Competence, Effort/Importance, Pressure/Tension, Perceived Choice, Value/Usefulness, and Relatedness created to measure different aspects of in-trinsic motivation in the given activity. The idea behind IMI is to choose a couple of factors out of the categories based on the purpose of your evaluation and create a form out of a number of statements regarding the factors listed in the tool. Test users answer how well each statement coincides with their experience by choosing a number on a scale from one to seven, all answers are then used to calculate average sub scale scores to be used in the analysis of the application. I have chosen to use Interest/Enjoyment, Perceived Competence, Ef-fort/Importance, and Value/Usefulness as sub-scales as they corresponds to the key aspects of my system. These factors and scores will be analyzed as the final result and evaluation of the application.
4
Process
This chapter describes how the design and implementation process was carried out by fol-lowing the steps proposed in Section 3.1.
4.1
Strategy
The purpose of the system is to motivate people to learn programming and wanting to con-tinue progressing through the application. The key aspect of the system is the ability to motivate and engage people in using the application which is a subjective matter of how the users experience the application. The IMI evaluating device in Section 3.3 is therefor used to define and access relevant and measurable metrics and scores of user experience and intrinsic motivation in the application.
I have chosen Python as the programming language to learn in the application since it is a fairly easy language to read and grasp on a basic level and it is simultaneously very powerful and widely used. I am confident that it will serve a good basis of how to think like a programmer while not having too advanced and confusing syntax. The target users are people that are open to learn basic programming in general and Python programming in particular. Learning programming is often associated with schools and universities since it is often a part of higher technical educations but there are a multitude of courses and programs on the Internet for people to learn programming on their own. This application is meant to serve a similar purpose of engaging people in learning programming on their own, I will therefor base the programming content and information on popular web guides that teaches Python to beginners to have a educational base to work with.
The scope of the project is limited to what I can achieve as a lone developer on the system. Because of this, highly advanced technical features and elaborate graphical content are not feasible in the given time frame. I will focus on developing the system around effective core mechanics and create running prototypes that work on a smaller scale rather than well polished perfect products.
4.2
Research
There are a number of different reasons to learn programming, for example to begin a career in software development, to widen ones technical competence, to develop hobby projects
4.3. Synthesis
or out of curiosity to simply get an understanding of how computers and software works. People with a lack of technical understanding and knowledge about software tend to have a hard time grasping how computer programs actually are created. This makes for a potential big hurdle and anxiety around diving into to this world which might be seen as vast and complex. An important task for the system is to defuse this tension and create a view of programming that is inviting, logical and inspiring.
4.3
Synthesis
The target activity of the system revolves around learning how to program and out of this i identified three basic main challenges: generating code, understanding code and debug-ging/correcting code. These challenges are somewhat intertwined since both generating and reading code is a part of correcting code and by learning to read code you also learn how to write code and the other way around. This makes it impossible to completely distinguish the challenges from each other but I mostly see this as a good thing since different challenges may offer different mechanics which provides more variety in the application while still serving the same purpose.
There are different types of knowledge out of the ones described in section 2.2 to be learned in the field of software development, I identified three of the most prominent types:
• Declarative knowledge represents a big part of programming since it is very relevant when it comes to learning syntax.
• Conceptual knowledge is represented as the concept of software and the writing and execution of code. There exists an array of different concepts in programming of vary-ing magnitude.
• Procedural knowledge can describe instructions for certain solutions but it is also risky to only think in strict procedures as there often exists many ways of accomplishing a specific outcome. Learning some step-by-step instructions of solving certain problems and tasks can still be very useful as it beneficial to learn good programming practices and mind-sets.
4.4
Ideation
The brainstorming of ideas was divided into two categories, level design and game structure as a whole. Level design is the package of challenges/tasks and game mechanics the player are faced with, the rules of gameplay chunks in order to make problem solving gameful. It is not necessarily a fully contained segment with a start and a finish of a problem or mission but could be more vague and mixed together with other levels or content depending on the setting. The game structure is the broader view of the system as a whole, the general idea and design of the game. How and when tasks are presented, how to progress and be rewarded by completing tasks in a gameful fashion.
Game structure
The following innovation stems was particularly useful when brainstorming structure ideas: "It’s like <existing game> for <activity>." and "How might the system spark <motivation-type> in <challenge>?". Developing a fitting structure is crucial in forming a fun and motivational design since it affects the entire application, by creating an engaging structure you have a firm platform to build on when designing levels which provide the actual learning content. Below are some of the different generated structure ideas paired with some analysis on their fit:
4.4. Ideation
1. Dividing the system into chapters containing levels representing different concepts or areas of programming. To get access to the next world you need to complete a number of levels in the current world.
This is a rather common game structure in certain game genres as it forces the player to master challenges in a certain competence area before continuing to the next which allows the designer to create a decent learning curve with learning content in a fitting order while still giving the player a sense of freedom and autonomy.
2. Solving a problem to get to the next, following a pre-determined order in a story like setting.
This is a popular game structure since the designer can focus on a single path through the game and make it extra thrilling. It is a good way to ensure that content is learned in a specific order and it is easy to tailor an exciting story that the user plays through. But on the downside it erases player options and most sense of autonomy.
3. Completed levels are scored by suitable point system (e.g. time to completion, number of code rows or number of errors) and can be replayed to achieve better scores and records. All levels are open at all times but with a recommended order of play through. The full autonomy of this structure gives the player complete power in choosing levels which is good for intrinsic motivation but can complicate level design, learning curve and good learning practise since it might be difficult to learn certain concepts or techniques with-out some prerequisites. The player might be frustrated and confused by facing problems it is not competent enough to solve. The idea of improving level scores and beating records is a good way to visualize improved competence and can quite easily be adapted to a form where players can compete with their friends and other people online with scoreboards which may fulfill the need of relatedness.
4. Finishing certain challenges rewards the player with items that are necessary for the player to reach further parts of the game.
Gathering or achieving something before getting access to further levels is a common and logical game design making the players decisions and accomplishments meaningful. The player can choose among some challenges but the order of play through is somewhat pre-determined and the order of learning content can be partially controlled, this structure motivates the players to accomplish tasks in order to progress and can spark some curiosity in what items you can find making the items an important part of the gameplay.
5. Finishing certain challenges gives you access to new functions you need to use to com-plete other challenges.
Learning and receiving new functions is a similar structure to receiving meaningful items in autonomy and content order. It injects some curiosity on what new functions to learn and additionally shows progress in competence in a very concrete way as the players clearly can see the functions they have mastered.
6. Gain points in challenges depending on how well you did by a suitable point system which you need certain amount of to unlock new challenges.
A simple structure of player choices with the limitation of having to work on earlier levels in order to progress. This makes balancing level points critical since there is a risk of unfair point distribution over levels which may lead to players struggling or on the other end skip-ping important parts because they achieved enough points anyway. It is a competitive layout as it encourages players to strive for highscores and possibly trophies.
4.5. Storyboarding
The strength and weaknesses of the ideas was weighed towards each other and analyzed in respect to self determination theory in order to pick a structure to further develop. Eventu-ally idea number 5 was chosen to further develop, creating certain key problems that blocks further levels to be reached and needs certain functions to be solvable. It fits well in order-ing content where I can use key levels to assert that the player have acquired the required function and enough knowledge to progress to new challenges and the player can clearly see that they have learned something new as they can solve a problem that they were not able to solve before learning the function. It leaves room for autonomy as I could make key levels unlock a number of new challenges simultaneously where the players can choose in which order they accomplish them.
Level design
The level design brainstorming was based on common learning techniques in declarative, conceptual and procedural knowledge and used innovation stems and design lenses to pack-age techniques in a gameful manner as tasks. The idea was not to pick one single task idea to realize but a several since they are separate concepts that can easily be mixed into the system to get some variation. Below are some of the generated ideas:
• Following a tutorial and perform specified actions. • Translate human language to programming language.
• Answer multiple choice questions regarding program output.
• Find errors by traversing code rows one by one and answering if it is correct or not. • Achieving a certain output by:
– Ordering a number of code snippets.
– Generating row by row by choosing one out of a number of alternatives.
– Choosing variable values, loop intervals and function inputs in an existing pro-gram.
– Writing code from scratch.
– Completing existing functions.
– Call available finished functions.
– Fixing broken code.
4.5
Storyboarding
A storyboard consisting of a number of sketches was created, the sketches was purposely fairly basic and lacking of details. The storyboard was created to get a view of the structure and main feature of the application, not to serve as a finished design. The basic structure was based in a main page which links to different topics containing information and tasks relevant to that topic. An example topic is Boolean, all levels in this topic are focused around teaching the concept of the data type Boolean. The different topics would be in a ordered list but are not always required to be completed in that order. The levels in a topic are strictly ordered, the user must complete the first one in a topic before it can go on to the second one. The user can always go back and forth between available levels and topics.
The general structure of levels was sketched and I decided that all levels would share this general structure to keep a uniform layout. A basic layout was designed with initial information, text describing a task, eventual hints for the task and the tools for completing the task like a code window. I chose to start with two main task types with the possibility
4.6. First Iteration
Figure 4.1: Simple sketch of the general level structure.
to add more further on if it was deemed appropriate in the iteration process. The first one would consist of a code window with a complete or near complete code example, the code can not be altered with exception for some marked words or blank spaces as seen in Figure 4.1. The idea is that the user should alter these spaces so that the code will generate a certain output. This task idea is meant to be used in the initial parts of the application since it leaves little room for misunderstanding and errors, the user is guided towards the correct answer and is provided with helpful information and hints. The focus is to get the user used to the programming environment, learn the syntax by reading and understand the general concept behind programming without putting to much pressure on them.
The second type of task consist of a code window that the user have full control over, the window will be filled with varying amount of code in it’s initial state. The goal is to generate a certain output like in the first task type but given more options and possibilities, this also requires more effort from the user to complete the task. The idea is to test the users and give them more of a challenge when they have understood the underlying concepts.
4.6
First Iteration
Prototyping
the focus of the first prototype was to construct a working website with fairly basic func-tionality, creating appropriate challenges and programming tasks paired with educational information to achieve a basis to proceed from. The iterative process and evaluation results will be used to tweak the difficulty and order of learning content and how to improve the system as a whole.
The following pictures are screen-shots from the first prototype and show some of the most important parts of it. The main page after log in displays all different topics available to the user, at first only one topic is available but more are visible and unlocked by completing certain topics. Each topic is represented by a varying number of levels which contains some new information regarding the theme and a correlating task. The user gets to the next level by completing the task with a correct result and the topic is finished when all it’s levels are completed. There is a total of 8 different topics ranging from printing strings to functions and looping over lists.
4.6. First Iteration
Figure 4.2: Main page with the first topic completed.
The tasks in this prototype all revolves around writing code of some sorts but to various extent. The first four topics only contains task where the user only fills in highlighted gaps of the code such as values and variables to achieve a desired result as seen in Figure 4.3, 4.4.
Figure 4.3: Completed basic task. Figure 4.4: Error message.
The later levels are more open and gives the user full control of the code area to write func-tions that should achieve and return something specified in the task. Sometimes the function is partially written and asks the user to correct or finish it and sometimes it is completely blank. Four test cases are run when the user presses the "Run"-button to control the validity of the function and that it outputs the correct result. The level is completed when all test cases are passed and the user can continue to the next level which is shown in Figure 4.5. If the code fails to compile or one or more test cases are false the user have to correct their errors and try again as seen in Figure 4.6. Two of the test cases input, output and desired result are shown while the other two are hidden, only revealing if they failed or not. This is because seeing the input, output and desired result of certain test cases is valuable feedback and can be used to figure out why it passed or failed. The two hidden cases are present to keep the user from hard coding specific output for the given input as it is bad programming practise. The game structure idea of needing achievable functions to complete key levels in order to progress was not fully implemented in this initial prototype, this is only present once and the
4.6. First Iteration
Figure 4.5: All four test cases passed. Figure 4.6: Four failing test cases.
level where the function is achieved is just before the level where it is used leaving little to user choice and autonomy.
Playtesting and evaluation
A smaller playtest session was conducted when the first prototype was ready where test users played through the website until they had finished all topics. The they were interviewed regarding their experience and thoughts.
The overall opinion was that the prototype was easy to use and understand while it was somewhat challenging and quite educational to complete. Even though most of the applica-tion was clear there were a number of smaller problems and ineffective details pointed out. The general idea and gameplay layout was appreciated but some aspects of the prototype was lacking in particular. The users wanted to see more feedback from the system, especially when completing a challenge or topic. The feedback from failing to compile or generating the wrong output was perceived as sufficient but more help regarding errors was sought af-ter. The amount of text for information and task explanation felt appropriate but the users thought that there could be a bit more general text regarding the purpose of the application that was funny and encouraging. The test users liked the programming tasks, they were viewed as relevant and placed in a good order to understand and learn the concepts. They liked that the structure and general layout of tasks was consistent and did not find them to repetitive. All task difficulties were deemed appropriate except for one task which was viewed as a bit to difficult to solve.
Improvements ideation
This iteration had focused on constructing a working intuitive prototype with an appropriate learning and difficulty curve and since the feedback regarding educational information and tasks where overwhelmingly positive the brainstorming was focused more on system feed-back and encouraging features for the next iteration. Feedfeed-back and encouragement are some of the key points in gameful design and a number of design lenses was used extensively to ideate improvements since the playtesting showed that the system contained suitable chal-lenges that served their purpose but the system as a whole needed a more coherent and gameful structure.
Most of the brainstorming and sketching revolved putting the levels in a larger context and how to generate more expressive feedback. A concept of gathering certain made up
4.7. Second Iteration
types of python snakes by completing topics was chosen to be developed further out of the generated ideas. This idea also contained a visual display of which snakes are currently caught and which are not. This was a mix of clearly visualising progress by awarding certain tokens and adding a little bit of story, restructuring the goal of completing all topics to the goal of collecting all snakes. The concept of using achievable functions as keys to locked topics was refined by adding challenges with key functions at the end of certain topics and levels requiring them in the last chapter.
4.7
Second Iteration
Prototyping
The iteration was started by fixing some smaller rather concrete errors and design flaws that had come up in the evaluation. The design was updated but the general structure of the website was kept. The reward system with snakes to collect was implemented with some text changes adapted to the new context. Topics were renamed quests and finishing a quest results in unlocking a snake and sometimes additional quests as seen on the reward page in Figure 4.8. A row with images displaying which snakes you have found was added to the main page where the snakes that are not yet mastered are greyed out as seen in Figure 4.7. The text changes done mostly revolved around making the text fit the new context and elements in the application but it contain fairly little story content, some lines when the user receives a snake, a little introduction and a couple of finishing words in the end. This is intentional to keep the amount of text to a minimum since the application is innately pretty text heavy. The evaluation of the first prototype indicated that the existing amount of text was appropriate but some additional text probably could be good as long as it was fun and light. This means that I could have tried to add more text and it might have improved this prototype but I decided to start small and let further playtesting and evaluation determine if even more story text is deemed good.
Figure 4.7: Main page with the first snake mastered.
Some challenges was reformulated and the challenge that was deemed the hardest and to mathematical for the context in playtesting ended up being removed completely. Three completely new levels that was intended to improve the impact and significance of achievable functions was added. One of the challenges was in the topic "Lists" where the user writes a
4.7. Second Iteration
Figure 4.8: Rewards for finishing the
first quest. Figure 4.9: A challenge where usablefunctions are offered.
function that swaps places of values in a list. The other two levels were added to the final topic "Looping over Lists" where one of them should be solved by using a function previously written in "Loops". The final level uses the list-swapping function and another function also written by the user earlier in the final quest. The extra functions are present and usable in all levels in the eighth quest as seen in Figures 4.9 and 4.10, even in the levels where they are not very suitable to use. The user is also never told when to use which functions, this is to train the user in analysing the available tools and when they are useful. The use of extra functions is never mandatory in any level, they are merely there to make the solution easier to write and better in terms of programming practise, it also shows that most problems have multiple solutions.
Figure 4.10: The names and a short description of the usable functions seen in Figure 4.9.
Playtesting and evaluation
The conducted playtesting sessions for this iteration was done with new test users not present in the sessions for the previous prototype. The playtesting was done in the same way, with the users playing through the application and being interviewed afterwards, the interview questions was mostly the same but the follow-up questions varied depending on the answers. A lot of the overall opinions were positive and the playthrough seemed to be fun for the users. The programming experience of the test users was very different which showed rather clearly in the feedback. Users with little experience in the Python language but with good programming knowledge in general went through the application rather fast and quickly picked up on the challenge setup and Python syntax. They figured out how to solve the levels and when they faced problems they could easily trace the errors and knew how to find
4.7. Second Iteration
solutions for it. A user with very little programming experience and no knowledge of Python had a bit more trouble in progressing through the quests but really liked the challenge. The user asked for help after getting stuck in one of the challenges and was helped to solve that particular level. The user thought that the information regarding the tasks and concepts was good and did not really feel that more of it was needed but the user felt that there was a bit lack of help when you got stuck. The user analysed the code but could not figure out why it generated the wrong output and would have liked more hints on why this was or how to solve it. The help that was given when the code failed to compile was viewed as better since it indicated which line that was faulty but it did not show a very explanatory error message. It showed what type of error it was but no examples on what could have caused it or common ways to correct it. The user thought that the difficulty was appropriate and the application was educational, it was the feeling of getting stuck that was a bit frustrating and deterrent.
The game design and concept of unlocking different snakes was appreciated by the users who felt like it was a fun reward and made some of them motivated to go through the chal-lenges just for the enjoyment of unlocking the snakes. Some users stated that they found the website a little static in a way, one expressed an urge for something more dynamical to make the website a little special for the specific user. It is pretty obvious that the application looks the same for each user that has progressed equally much in the quests and the user wanted something to make it feel a bit more personal, so you could see that it was your account that was playing. Others said that they would like things to happen that depended on user ac-tions, for example hints or comments that was relevant to the user in the current situation. The setup of levels was found a little similar in the long run but also that it was comfortable since there was a lot of new things at once in the content and that it would be hard to add a lot of new ways to take in the information and manage the practices. Most users said that they would have like to see more diversity in levels if the game were bigger and spanned over more concepts as it would let the user get more used to programming and how to process new things. The size of the current prototype however did not need more diversified levels and some thought it might make it more confusing.
Two people tested the application simultaneously side by side and there was a little bit of a competition among them of who were to finish first which made them very engaged and motivated. One of them said that they would have liked some way of connecting to other users and viewing their progress on the website and suggested that you could add other users as friends to compare their results with your own.
Improvements ideation
Something I wanted to address was the opinions regarding personalization and that the web-site felt a bit static. Personalization could be done in variously complex ways but my general idea of it was to adopt the application to the user and it’s current status. No evaluation showed that lack of personalization is a big problem which made me to not focus immensely on it but to find a way to make the website feel a bit more adaptive and targeted to the specific user. A easy way to target the user is to direct some messages directly to the user by using it’s provided username in the text, for example: Welcome back Jakob!
Another idea of adapting the site to user status was to show messages based on progres-sion. I the number of finished quests to be suitable measurement of progression and that I could adopt messages around this. The messages seemed to fit the main page since its the first page the user see after logging in and the page that the users return to after finishing a quest. Combining the tricks of directing a status dependant message to the user seemed like an easy way to decently personalize the application but it felt rather static to show the same welcome message every time for a user that had not progress since the last visit. I drafted a simple structure of a number of different welcome phrases and text snippets for a number of different progression levels and a way to randomize among them to make it more dynamic.
