Redesign and Gamification of a Social-Intensive Software Learning Environment

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Redesign and Gamification of a

Social-Intensive Software Learning

Environment

Pedro Manuel Monteiro Albano

Mestrado Integrado em Engenharia Informática e Computação Supervisor: Nuno Honório Rodrigues Flores

(2)

(3)

Redesign and Gamification of a Social-Intensive Software

Learning Environment

Pedro Manuel Monteiro Albano

Mestrado Integrado em Engenharia Informática e Computação

(4)

(5)

Abstract

The use of frameworks has become an important factor in improving the large-scale reuse of software and ensuring quality standards are maintained. As the world demands for more and more computer based solutions and applications, software developers are faced with an increasing amount of different frameworks available and the need to effectively learn how to properly use them in their professional lives to solve problems. Frameworks are often complex and good doc-umentation helps reducing the learning curve for professionals to apply them, but is not always available or adequate to one’s learning needs.

Previous work resulted in the creation of DRIVER, a social intensive learning platform mod-eled around the concept of a Collective Knowledge System. There, learners contribute to the com-munity’s global knowledge on a framework by sharing how to reach specific goals by the means of publishing learning paths, a set of sections and pages visited in order to reach a milestone, described by the use of tags.

Despite providing developers with a set of tools to enhance the learning aspect of working with a framework, DRIVER lacks adherence due to general problems with its usability and low incentive for users to make use of the tools advantages, effectively creating an additional workload on the task of learning.

In order to make the platform more appealing, the use of Gamification was considered. Gam-ification is shortly described as adding game-based mechanics to activities or tools, such as char-acters, points or rewards, in order to foster the user’s motivation to engage with them, and subse-quently their productivity.

The objective was to create a new version of DRIVER integrating these concepts and observe the impact they had on the developers’ learning process, but not without attempting to solve the inherent user experience problems the tool had. This resulted in the creation of a whole new piece of software that redesigned the original features present in DRIVER to perceivable simpler and more intuitive ones, while implementing a customizable avatar and experience point system built around unlocking rewards for making use of the platform’s features.

Following a short study evaluating two deployments of the updated learning environment, one with Gamification related features enabled and one without them, there was no significant difference observed in the performance of the participating subjects, however, small traces indicate the Gamification features employed, appealed the interest of some of the users and might produce the intended benefits in the long term.

Keywords: gamification, collective knowledge systems, documentation, frameworks, learning, software, DRIVER

(6)

(7)

Resumo

A utilização de frameworks tornou-se num fator importante no que toca à melhoria da reutilização softwareescalável e de forma a garantir que os padrões de qualidade são mantidos. Ao mesmo tempo que a procura no mercado por soluções informáticas aumenta, a necessidade que os de-senvolvedores de software têm em aprender a utilizar o número em constante crescimento de frameworksdisponíveis na sua vida profissional aumenta igualmente. Estas frameworks são por muitas vezes complexas, mas a sua boa documentação ajuda a reduzir a curva de aprendizagem dos profissionais que as tem de aprender a utilizar, contudo nem sempre está disponível ou não é adequada às necessidades de todos.

Trabalho anterior, resultou na criação do DRIVER, uma plataforma de aprendizagem social-mente intensiva, modelada em volta do conceito de um “Sistema de Conhecimento Coletivo”. Nesta ferramenta, os seus aprendizes contribuem para o conhecimento global da comunidade so-bre uma framework, através da partilha de como chegar a objetivos específicos, pela publicação de “caminhos de aprendizagem”, que se definem por um conjunto de secções e páginas visitadas com o objetivo de chegar a uma determinada meta, descrevendo-se pelo uso de etiquetas.

Apesar de fornecer aos desenvolvedores de software um conjunto de ferramentas focado em melhorar o aspeto da aprendizagem relacionado com o trabalho de uma framework, o DRIVER é pouco utilizado devido a problemas gerais na sua usabilidade e ao facto de não conferir grande in-centivo aos utilizadores em fazer uso vantajoso das suas funcionalidades, que efetivamente provo-cam uma carga de trabalho adicional na tarefa de aprender.

De forma a tornar a plataforma mais apelativa, o uso de Gamificação foi considerado. De-screvendo de forma resumida, Gamificação é o ato de adicionar mecânicas de jogo a atividades ou ferramentas, tais como personagens, pontos ou recompensas, de formar a criar motivação para que os utilizadores interajam com elas, e consequentemente aumentar a sua produtividade.

O objetivo era criar uma nova versão do DRIVER que integra-se estes conceitos e observar que impacto que eles tinham no processo de aprendizagem dos programadores, mas não sem a tentativa de resolver os problemas implícitos na experiencia de utilizador que a ferramenta tinha. Isto resultou na criação de uma nova peça de software que redesenhou as funcionalidades originais existentes do DRIVER para serem mais simples e intuitivas, ao mesmo tempo que se implemen-tou um avatar personalizável com um sistema de pontos de experiência contruído em volta do desbloqueio de recompensas pelo uso das funcionalidades da plataforma.

No seguimento de um pequeno estudo que avaliou duas implementações da versão atualizada da plataforma de aprendizagem, uma com as funcionalidades relacionadas com a gamificação ati-vadas e outra sem elas, não se constatou diferenças significativas no desempenho dos participantes, contudo, há pequenas indicações que a funcionalidades de gamificação aplicadas, apelaram ao in-teresse de alguns dos utilizadores e podem vir a produzir os benefícios desejados a longo prazo.

(8)

Palavras-chave: gamificação, sistemas de conhecimento coletivo, documentação, frameworks, aprendizagem, software, DRIVER

(9)

Acknowledgements

I’d like to begin by showing a much deserved gratitude to Cecília Monteiro and Francisco Albano, my mother and father. Their outstanding support across my entire life is the reason why i have the privilege of being one of the many that partake in works like this, across many, many other things. A special thanks goes to my supervisor and this dissertation’s proponent, Nuno Flores, who has always helped me with everything necessary to develop this project smoothly and gave me the freedom to add a little bit of “me” into it.

To my friends, i will be ever so thankful for their support and programming tips, with a special attention to the constant reminders there’s no such thing as “too much time” to do a dissertation work like this.

Last and not least, i would like to thank all of the developers and contributors for the free software libraries and frameworks they make available all around the web, that the products of this dissertation were built of. Works like this wouldn’t be possible without them.

(10)

(11)

List of Figures

2.1 Overview of the framework learning process . . . 4

2.2 Screenshot of the DokuWiki installation guide running on the software itself . . . 5

2.3 Screenshot of the React docs “Getting Started” page . . . 6

2.4 Screenshot of a documentation page produced by Doxygen . . . 7

2.5 An example of code usage as seen in the React framework’s tutorial . . . 8

2.6 An Interactive Snippet on Mozilla’s MDN web docs . . . 9

3.1 Screenshot of a page written in the DRIVER platform . . . 12

3.2 Overview of a Q&A type Collective Knowledge System . . . 13

3.3 Overview of the Learning Path creation process in the original DRIVER . . . 14

3.4 Widget for searching Learning Paths in the DRIVER tool . . . 15

4.1 Screenshot of the Foldit game . . . 18

4.2 Screenshot of one of the Dragonbox Math Apps . . . 19

5.1 Gantt chart of the dissertation’s development schedule by weeks . . . 24

6.1 Overview screenshot of the DRIVER 2.0 platform . . . 32

6.2 General system architecture of the DRIVER 2.0 platform . . . 33

6.3 Core interface elements of the DRIVER 2.0 platform . . . 35

6.4 A documentation page within DRIVER 2.0 . . . 36

6.5 A page section within DRIVER 2.0 . . . 36

6.6 Comparison between a normal and an highlighted section . . . 37

6.7 DRIVER 2.0’s page editor . . . 37

6.8 DRIVER 2.0’s recommendation widget . . . 38

6.9 DRIVER 2.0’s contextual recommendation feature . . . 39

6.10 Recommendation widget being influenced by the user’s selected tags . . . 39

6.11 Matching vs non-matching section while context tags are active . . . 40

6.12 DRIVER 2.0’s search tool . . . 40

6.13 DRIVER 2.0’s My Path Menu . . . 41

6.14 Manually adding a step to Learning Path from a documentation section . . . 41

6.15 Visual anatomy of a Learning Path step . . . 42

6.16 DRIVER 2.0’s Path Editor . . . 42

6.17 DRIVER 2.0’s Path Wallet showing a list of the user’s creations . . . 44

6.18 Description of a list item from the user’s Path Wallet . . . 45

6.19 A Learning Path’s sharing page within DRIVER 2.0 . . . 45

6.20 DRIVER 2.0’s Tutorial Page . . . 46

6.21 DRIVER 2.0 sidebar’s user profile widget . . . 47

(16)

LIST OF FIGURES

6.23 User’s profile page showcasing the customization options for the avatar . . . 48

6.24 User’s daily objectives in DRIVER 2.0 . . . 49

6.25 DRIVER 2.0’s Weekly Challenge page . . . 50

6.26 The leaderboard as seen in DRIVER 2.0 . . . 51

6.27 DRIVER 2.0 with Gamification features disabled . . . 52

6.28 Images part of an introductory video to the original DRIVER tool . . . 53

(17)

List of Tables

7.1 Statistics of the “Background” part of the pre-experiment questionnaire . . . 62 7.2 Statistics of the “External Factors” part of the post-experiment questionnaire . . . 64 7.3 Statistics of the “Overall Satisfaction” part of the post-experiment questionnaire . 66 7.4 Statistics of the “Development Process” part of the post-experiment questionnaire 68 7.5 Progress statistics of the tasks solved in the validation experiment . . . 69 7.6 Statistics of the “About the Framework” part of the post-experiment questionnaire 70 7.7 Distances from the correct answers in the “About the Framework” questions . . . 71 7.8 Statistics of the “Gamification Features” part of the post-experiment questionnaire 72

(18)

(19)

Abbreviations

Admin(s) Short for “Administrator(s)” API Application Programming Interface CKS Collective Knowledge System CSS Cascading Style Sheets

FEUP Faculdade de Engenharia da Universidade do Porto HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment IRC Internet Relay Chat

JS JavaScript

JSON JavaScript Object Notation

MIEIC Mestrado Integrado em Engenharia Informática e Computação MMORPG Massively Multiplayer Online Role Playing Game

MPA Multi Page Application Q&A Question and Answer SPA Single Page Application

UI User Interface

URL Uniform Resource Locator WOW World of Warcraft (Video Game)

(20)

(21)

Chapter 1

Introduction

This chapter introduces this dissertation’s context and motivation for work, discussing in a brief introduction its importance and the problems it looks to address, finishing by describing the overall document structure and the topics discussed in the following chapters.

1.1 Context

DRIVER[FA16] is a platform that was created following research into how to improve a devel-oper’s task of learning how to use a framework. Its a tool for housing documentation that supports sets of known design elements and techniques needed to produce framework learning artifacts, while adding on top its own features to make the task of learning frameworks an easier and more productive one.

This dissertation project comes from University of Porto’s Faculty of Engineering (In Por-tuguese: “Faculdade de Engenharia da Universidade do Porto”) as part of the Integrated Master’s in Informatics Engineering and Computing (In Portuguese: “Mestrado Integrado em Engenharia Informática e Computação”) and continues the platform’s development process into evolving into a tool that can better help learning professionals with their task of mastering frameworks.

1.2 Motivation and Goals

Frameworks have become an important asset in producing software, fostering its scalability, re-usability and high quality standards. The use of these software libraries has become a substantially large necessity in the task of producing applications due to the overall benefits they provide to the development process.

As such, as more and more frameworks appear and their level of sophistication increases, it has become part of a developers work to learn and master their use as effectively and quick as possible. Good documentation helps a lot with the task of learning how to use a framework, but

(22)

Introduction

is not always available, as it often may be hard to navigate for less experienced users and may not be adequate to the needs of different learning individuals.

DRIVER plays an important role in enabling learners to acquire implicit knowledge within documentations through it’s social component, improving the ability to learn from a set of docu-mentation pages and the accessibility to its knowledge. However, DRIVER sees low adherence and usage, due to problems in its usability and an overall lack of incentive to make use of its tools. As it is, it creates an additional workload to generate benefit from using the platform, unappealing to those tasked with the effort of learning how to use a framework.

Gamification is a concept that revolves around adding game mechanics to activities in order to improve interest in them, aiming an increase of the overall productivity of such activity and the satisfaction of the people performing it. Gamification has a successful record in achieving these objectives and has sometimes produced results above the expectation.

Given DRIVER’s issues, the goal of this project was to progress DRIVER’s development into a new iteration of the platform. This new iteration focuses on the use of gamification elements to improve the appeal in using it, so that users can better take advantage of its unique features, expecting to see an increase in their overall productivity and satisfaction. Parallel to this, due to the previous iteration’s known usability issues and the need to create a structure to implement the new gamification features, a ground up redesign of the platform was performed aiming to rework the user interface and its features into a simpler and more intuitive experience.

1.3 This document’s structure

In addition to this introduction, this document contains 6 additional chapters:

• Chapter2discusses the state of the art in terms of framework learning and existing solutions. • Chapter3provides a more in-depth look at the original DRIVER platform and its

function-ality, as well as discussing its issues.

• Chapter4introduces the concept of gamification and discusses the state of the art in terms of gamification projects for learning.

• Chapter5takes a look at the planning and methodology followed in this dissertation work, the goals and plans behind the upgrade process of DRIVER and its expected results. • Chapter6approaches the redesign and gamification efforts of the new DRIVER iteration,

taking an in-depth look at how the new version of the platform works, its capabilities and the motivation behind the new design’s choices.

• Chapter7describes the validation experiment performed in order to determine the impact of adding gamification features to DRIVER and evaluates its results.

• Chapter8looks into the conclusions taken after realizing the dissertation project and future work.

(23)

Chapter 2

Framework Learning

This chapter describes the state of the art regarding framework learning. It presents the overall process on how developers acquire knowledge on how to make use of frameworks, the existing solutions to host online documentation pages and design practices used to enrich their learning experience. It should be noted that the majority of the topics described in this chapter come from the original DRIVER research work[FA16], which takes a more in-depth look at them.

2.1 Introduction

DRIVER inserts itself in a group of solutions fostering the learning process of developers in how to use frameworks. Every developer learns in different ways, however, the methodology to do so usually takes foundation in looking at generic places based on an order of relevance, reliability and availability. An overview of this process is described in Figure2.1.

Developers start with examining the documentation pages (or wiki) of the framework. These are written by the authors, who can have the most in-depth understanding of the software’s capabil-ities, as such, this is usually the desirable place to look at when learning how to use the software as, in general, they’re accompanied with guidance on how beginners can make use of these resources and a more experienced audience can locate details regarding more advanced functionality. How-ever, this often does not work as planned. In reality documentation is often structured in confusing ways that may not allow learners to easily access the knowledge contained in them, it may con-tain insufficient detail on how the software works or on how to use it for determinate goals. An example would be the “Getting Started” section of the documentation having all the needed detail in order to setup the usage of the framework, but the rest being as bare bones as only including method headers and describing their parameters.

As documentation fails to satisfy the learner’s needs, they throw their attention at the next source of knowledge. This can be as straightforward as querying in web search engines like Google[Goob] or looking in Q&A forums dedicated to programming such as Stack Overflow[Sta].

(24)

Framework Learning

Figure 2.1: Overview of the framework learning process

Nowadays, internet access is highly widespread and there’s a very large amount of individuals contributing answers in these places making a developer’s task an easier one, but naturally these answers might not end up being adequate or correct so it’s up to the developers judgment to review their suitability, for example, in matters like respecting security standards.

So afterwards developers end up calling for the aid of specialists, individuals more fluent in the usage of the framework of interest, whom might not be available or not have the time to share their knowledge on the matter. This last crowd has the particularity of having already gone through the process of learning how to use the software, which in prior to their grading as a “specialist” in the area, the only reliable source of information would have been the documentation, thus having learned from it.

This circle points to the high importance of a framework’s documentation being a highly re-liable source of knowledge in its usage, so this chapter takes a look at the existing ways to host documentation online and the design practices to apply in them to increase their overall quality.

2.2 Documentation Pages

Documentation pages come in a few different flavors but ultimately share the same goal of explain-ing how to use a framework (or anythexplain-ing else when lookexplain-ing outside of this project’s scope). These could be classified in 2 groups. The first group would be documentation pages entirely written by the authors, in either supporting software (like DRIVER) or made from scratch solutions. The other group would acquaint documentation pages generated from the software’s source code.

2.2.1 Written in Wiki Software

The structure of a Wiki and a Documentation artifact are rather similar, in truth, you could say they end up being equivalent to a certain degree. Wiki software gets along well with the needs of

(25)

Framework Learning

Figure 2.2: Screenshot of the DokuWiki installation guide running on the software itself

writing documentation. It enables the creation of a well organized structure that can be browsed and searched conveniently by its users when looking for information.

Software like DokuWiki[GD], as seen in Figure2.2, supports standard rich text formatting, embedding media such as images and videos and includes the ability to write snippets of code, potentially using relevant to language code highlighting, ideal for displaying contents targeting the learning of a framework.

Writing documentation in this sort of solution is advantageous to the learners because when several documentations use the same software the learner can skip the process of getting used to the environment surrounding it.

2.2.2 Written in Custom Web Pages

Its often the case where documentation pages are written in their own custom solutions. The reasons for this can be diverse. Aesthetics, including features incompatible with existing Wiki software or even just preference. Sometimes this can be done to demonstrate frameworks in ac-tion, like the case of many web oriented ones such as the React[Facb] documentation, as seen in Figure2.3.

The final product in this scenario doesn’t usually diverge much from the sort of Wiki structure from the previous section, but is obviously more prone to lacking features fostering the learner’s tasks and loses the advantage of following a sort of standard environment for learning.

(26)

Framework Learning

Figure 2.3: Screenshot of the React docs “Getting Started” page

2.2.3 Generated from Source Code and Annotations

Another sort of documentation are the ones generated from source code and annotations. These are usually produced by annexing comments, following a format, in the source components of software and later transformed into sets of pages by the means of a tool analyzing the code. An example of this kind of documentation are the ones generated using Doxygen[vH]. Figure 2.4 showcases an API documentation page produced by Doxygen for an implementation of a piece of software called D-Bus[Thea].

This sort of documentation has the advantage of covering more in depth the internal function-ality of frameworks, however, it isn’t ideal for learning practices as it’s more targeted towards working as a reference material. It should be noted that more experienced users of a framework may favor this sort of documentation as they are usually already acquainted with the overall re-quirements of the technology.

2.3 Documentation Design Practices

An important part of writing documentation is the usage of elements that can better transmit the knowledge implicit within. These design practices aim to make the contents of the documentation clearer and easier to understand to its learners, making concepts easier to locate, guiding their users into adopting the appropriate means to use a framework and possibly avoiding streaks of intensive trial and error to figure out how to produce given functionality.

(27)

Framework Learning

Figure 2.4: Screenshot of a documentation page produced by Doxygen

Next are some of the deemed most important ones to producing documentation. It should be noted not all of them are covered here, other kinds of practices exist, but overall all work towards the same goal.

2.3.1 Design Patterns and Pattern Languages

Design patterns and pattern languages are what’s best described as creating a set of guidelines and standards in terms of structuring and naming source code elements, the latter is often recognized as using naming conventions. A short example would be a standard practice of naming constant values using only uppercase characters in parts of software code.

The goal here is simple. With the documentation following said patterns and the user possibly adopting them in their works, it becomes intuitive to identify the types of elements in code by quickly observing their naming and location. A function will have a distinguishing name when compared to a variable and both will usually be grouped in different locations.

The code block shown in Figure2.5follows some of these standards. The first character of the name for the class type element used in that example is written in uppercase in contrast to other types. This inherently makes it more intuitive for developers to identify the intended functionality across different components sharing the same structure and behavior.

It should be noted that like in the example shown, code editors and syntax highlighters fur-ther improve the user’s experience by visually enhancing the code’s display (by applying different coloring or other styling to it). This is usually performed by combining the used programming lan-guage’s syntax with the implicit knowledge in these patterns, so adopting them not only standard-izes the user’s perception within the documentation or their code, but also improves the behavior of the software handling it.

(28)

Framework Learning

Figure 2.5: An example of code usage as seen in the React framework’s tutorial

2.3.2 Demonstrations of Usage and Functionality

Perhaps more important than explaining functionality is the act of demonstrating how to use it and what it produces. This can range from showing how a tiny bit of the framework works, to a collection of steps needed to assemble a larger feature. Some of the practices having this as their objective are the ones such as:

Examples

Examples are an effective way to demonstrate how to make use of the framework, generating sam-ples that can illustrate core aspects of the framework’s usage that learners can easily understand.

Figure2.5 holds an example showcasing how to write a simple component using the React framework[Facb], as part of its introductory tutorial. This is a structure that is at the heart of its functionality, but could otherwise be troublesome to understand how to create for newcomers if not described using an example.

Interactive Snippets

Interactive Snippets are sort of a variant of examples. They have the same benefits as them but offer the learners a sandbox to test functionality on the spot, avoiding the need to go away from the documentation pages to do a much needed process of trial and error in figuring out how to make use of the framework’s features.

(29)

Framework Learning

Figure 2.6: An Interactive Snippet on Mozilla’s MDN web docs

Figure2.6demonstrates a running Interactive Snippet on Mozilla’s MDN web docs[MI] dis-playing a usage scenario of a Javascript method the user can manipulate to see the results change on the spot.

The caveat hindering the usage of these snippets in place of static examples is that they can’t always be made available due to the nature of how programming languages work with compiling written code into computer instructions. The implementation of such feature is most of the time not trivial. Its sometimes available for languages that are interpreted in real time and can run within the documentation software’s environment, such as the case of web ones like Javascript, but its a very rare occurrence when a dedicated solution is required to do it or the language requires pre-compilation in order to produce executable code.

Tutorials and Cookbooks

Tutorials and Cookbooks, such as the one previously mentioned in Figure2.3, play an important part in the teaching process of using a framework, as they provide step by step guides into how to reach certain goals and can incorporate the other design practices described in this section.

They’re highly effective in helping newcomers adopt a new framework or guiding in the usage of more complex features of the software. However, this sort of artifact can’t be overused in the creation of documentations, or they can possibly slow down the process of locating smaller bits of the functionality that is covered within. Most notably, this type of content can prove unfavourable

(30)

Framework Learning

when trying to convey knowledge to more experienced users, as they usually prefer quicker chunks of information.

2.4 Summary

This chapter shows how learners behave in terms of seeking knowledge to use a framework, what exists in terms of resources for writing documentation outside of DRIVER and how learners can make use of them. It can be concluded that there are several means guiding the production of good documentation, however there really aren’t many that can be used to grow knowledge outside of what’s written within.

(31)

Chapter 3

DRIVER

This chapter takes a look into the original DRIVER tool, the foundation of it, its functionality and how it tries to complement existing efforts by adding a social intensive component to the task of learning how to use frameworks.

3.1 Introduction

DRIVER[FA16], Figure3.1, was developed as a system targeting the improvement of the devel-oper’s task of learning how to use frameworks. The platform was built on top of the DokuWiki software[GD] as a plugin extending its functionality. The goal was to create a system providing authors and users the tools to create documentation pages suitable for framework learning, en-abling the design practices referred in Chapter2, while adding on top functionality promoting its usage as a Collective Knowledge System.

A Collective Knowledge System, or CKS, as conceptualized by Tom Gruber[Gru08], is a social environment where users store information and make it accessible to others through tech-nological means, enabling the community to search and review it, promoting an increase of its users overall understanding of the topics within. The system itself should offer the possibility of producing new knowledge through means of inference like recommendation engines. In short, a CKS is an environment where information can be stored and both the system and its users can manipulate it to generate knowledge.

Figure3.2 showcases an hypothetical Q&A system Gruber[Gru08] named the “The FAQ-o-Sphere”, as an example to describe the behavior of Collective Knowledge Systems. A Q&A forum like Stack Overflow [Sta] can be seen as a CKS, since:

• It allows users to propose questions (Store knowledge)

• It allows others to answer them or discuss them (Store and review knowledge) • Answers can be voted correct or incorrect (Review knowledge)

(32)

DRIVER

Figure 3.1: Screenshot of a page written in the DRIVER platform

• Anyone has access to the discussion to acquire information from it (Search knowledge) • The service can even recommend at which discussions to look at next (Generate knowledge) Looking at Gruber’s description of “The FAQ-o-Sphere”, you can see that the reality on how knowledge flows within Stack Overflow isn’t far away from it and that it follows the concept of a Collective Knowledge System.

So the idea for DRIVER, was to include a mechanism that allowed users to produce knowl-edge on where to locate information within the documentation and make it available for others to browse, quickening the process of finding the right pages and sections needed to achieve given goals and preserving this knowledge for later usage. This was accomplished by creating the Learn-ing Paths feature.

3.2 Learning Paths

Learning Paths are best described as the ordered set of sections and pages visited by a user in order to acquire the knowledge needed to implement certain functionality. They work analogous to what a click stream through a website is or even a browsing history. Learning Paths are labelled by tags to identify their purpose and users can rate them to evaluate their accuracy and/or reliability. 3.2.1 How are Learning Paths produced?

In DRIVER, to produce a Learning Path, a user begins by clicking an option to tell the system to track their browsing through the documentation. While searching through the pages, users have

(33)

DRIVER

Figure 3.2: Overview of a Q&A type Collective Knowledge System

the ability to create bookmarks to highlight pages and sections they consider important for the task they are trying to accomplish. The process ends with triggering an option to stop the tracking, sequentially providing a set of tools to prune unnecessary steps from the learning path, attribute tags to it and share/store it in the system. An overview of the process can be seen in Figure3.3

Following this, the Learning Path becomes available to all users to browse and rate. Figure3.4 showcases the feature allowing users to search for the paths stored in the platform.

3.2.2 Why are Learning Paths important? Learning Paths create a series of benefits.

Easy way to share a rich set of knowledge with others

Sharing a Learning Path is different than telling someone to look for a certain topic or providing them with a link to a web page. Learning Paths can work as small wrappers for a large amount of information, relieving the learner of the task of having to look for answers across the entirety of the documentation by providing everything in a single package. By using a Learning Path, learners receive a guide to the most relevant sections and the order they need to visit them, effectively producing a sort of lightweight tutorial or cookbook.

Preserving one’s knowledge for later

Its important to understand that Learning Paths don’t provide benefits just for others. In creating a Learning Path, the user preserves its work and knowledge of browsing through the documentation to reach a goal for later. The job of a Developer highly relies being accompanied by a reference

(34)

DRIVER

Figure 3.3: Overview of the Learning Path creation process in the original DRIVER

set. Often is the situation when one has to redo an implementation task done previously, but no longer recalls the exact process of doing so. Having the Learning Path stored creates a way to quickly recover that knowledge.

Creating a Recommendation Engine

It was noted earlier in this chapter that Learning Paths work in resemblance with click streams as they work as ordered sets of pages/sections. This information can naturally translate in the creation of recommendation processes within the system, as is the case with many websites. A good example is an online shop recommending what products to include in your shopping cart.

DRIVER includes a recommendation feature telling users what pages to follow next with foundation on the path data stored within the platform, allowing the system to infer and make

(35)

DRIVER

Figure 3.4: Widget for searching Learning Paths in the DRIVER tool

available new knowledge to its users, one of the desirable characteristics of Collective Knowledge Systems.

3.3 Usability Problems

Despite DRIVER providing an interesting aid in learning how to use frameworks through its Learning Path features, the tool isn’t regarded as appealing as it could be due to some issues within its user experience and overall interface.

Creating Learning Paths and sharing them with others is a rather manual process. It involves spending extra time and attention to produce them properly. Adding tags and pruning steps from the path at the end of its creation is specially a reasonably lengthy task, with the feature behind searching paths within the system being particularly affected by it, since it relies on Learning Paths being appropriately tagged to produce good results. The process can also suffer from some unreliability assuming the user forgets to prompt the system to either start or finish tracking the path at appropriate times, leading to it recording some potentially irrelevant or hard to refine Learning Paths, dropping the user’s interest in creating them.

The overall interface of the system doesn’t put much emphasis on its additional features, there-fore it becomes somewhat easy for a user to miss them or disregard them through the platform’s usage. In fact, even activating these features within the environment is sort of subject to additional navigation that might prove undesirable to some, as they hide under expandable controls. These problems are identified mostly through interacting directly with DRIVER and experimenting with its features.

(36)

DRIVER

In Nuno Flores’ PhD thesis[Flo12], as part of its validation process, there’s statistics that compare the overall users satisfaction over an experiment that split groups into one that used documentation with the patterns introduced in Chapter2and another that used DRIVER. While not deemed a significant difference, the group using DRIVER displayed satisfaction levels slightly below the other one. It’s a possibility that this difference could have been caused by the previously identified issues.

As years have passed since the creation of the current DRIVER version, so has progressed the development of current web technologies and browsers. While DRIVER’s interface elements could potentially use an update to match modern web application’s design components, stream-lining it with the users expectations of it, one of the issues at this time is that some of its features are no longer supporting of current web browser’s standards, most notably the previewing one, as it relies on HTML iframes to display content, which have seen their use hindered due to security concerns among the web.

3.4 Summary

DRIVER works as a complement to the technologies and practices discussed in Chapter2. It at-tempts to boost the framework learning process by introducing a social element to the environment in order to help users acquire knowledge more efficiently.

DRIVER’s Learning Paths create the means to store and use the information produced by the work of browsing documentation seeking to reach a goal, increasing the overall knowledge of the community of users of a framework.

However, there are usability issues that may be causing users’ low adherence to the platform, toning down the potential the tool could have in helping developers master the knowledge within.

(37)

Chapter 4

Gamification

This chapter takes a look at what Gamification is and where it comes from, showcases some successful Gamification projects and talks about some of the elements of Gamification targeting learning activities.

4.1 Introduction

Gamification is the act of introducing game mechanics to activities and resources in order to pro-mote their productivity and enjoyment, potentially transforming something completely into a game altogether.

Its no news that human beings like games, from the classic card game to the modern video games, these have always been known to engage their players in activities captivating their atten-tion. Its of no surprise that when a person takes part in an activity of their liking, their performance and productivity towards achieving a goal highly increases and games often stimulate this behavior by requiring their players to do so in order to win or achieve success.

The classic understanding of a game points it to an activity for entertainment, however, games have proven they can perform greatly in working as training environments for real world skills, reinforcing behavior and motivating users to perform activities they’d otherwise be not inclined to do, as noted by Karl M. Kapp in his book “The Gamification of Learning and Instruction: Game-based Methods and Strategies for Training and Education”[Kap12].

The idea comes from that players are often required to perform tasks in games that can translate into real world knowledge. They’re actually learning something and not just spending time for the sake of entertainment. Take for instance an MMORPG (Massively Multiplayer Online Role Playing Game) like World of Warcraft[Bli]. One of the core activities of the game is to organize a party of players (numbers can be in the ranges of 5 to 40) in order to defeat a dungeon filled with dangerous enemies. The party has a leader, who needs to guide the other players into success. What simply looks like a game in reality can be seen as a scenario teaching their users about

(38)

Gamification

Figure 4.1: Screenshot of the Foldit game

leadership skills, which are valuable in the real world, but in the game the players are allowed to go through a trial and error process that happens in as short as a few minutes, while in the real world this could take months to reach the point of finding success or not. It’s also more enjoyable to practice such skills in a scenario with no real world consequences, making a game an efficient solution to learn how to use such abilities.

This comes to show how game mechanics have the potential to enhance serious activities into becoming engaging and enjoyable experiences, increasing the productivity of their performers, making them more appealing, creating an environment easier to understand and promoting the adherence of their users.

4.2 Examples of Gamification

Yu-kai Chou demonstrates in his presentation “Gamification to improve our world”[Cho14] a few examples of successful Gamification projects and the impacts they had. This section picks up two of the projects mentioned as they tie in with learning activities and are deemed overall important in explaining the potential this practice has.

Foldit

Displayed in Figure4.1, Foldit[Han10] is an online game about folding protein structures. Folding a protein can be seen as some sort of a puzzle. Players engage with it in a way where the better

(39)

Gamification

Figure 4.2: Screenshot of one of the Dragonbox Math Apps

they fold the protein the higher the score they acquire. The solutions produced and their scores are accounted in a leaderboard and the top ones are reviewed by scientists working in the respective field.

This project provides an interesting challenge to its players, in return, scientists receive the solutions produced by the crowd, which can potentially be used to solve real world problems.

According to Chou, a user playing Foldit managed, in 10 days, to create a solution for a protein structure problem in the AIDS virus that top PhDs in the area had been struggling with for over 15 years.

Dragonbox Math Apps

Targeting a younger audience, the Dragonbox Math Apps[WeW] are designed to help children learn mathematics. One of the apps offers a puzzle game where the goal is to help hatch a dragon that’s inside a box, by removing all other boxes from the play area.

In Figure4.2a level of the app can be seen. To solve the challenge in the picture, the player can drag or tap the boxes present in the game area. Tapping the green portal box removes it from play, dragging the black two dot box into the white two dot box (or vice-versa) merges them into a green portal box, which can then be removed like the former, leaving only the dragon box in play, effectively completing the level.

This objectively works as an analogy to a real algebra math problem. If we consider the dragon box a side of an equation and the other boxes another, making the goal to have them be equivalent and considering the dragon box equal to 0, we can say tapping the green portals means producing a 0, dragging the two dot blocks to each other works as adding -2 to +2, which transforms them into green portal, producing another 0, finally reaching the intended value for the side of the equation

(40)

Gamification

in that isn’t the dragon box, thus solving the problem. This analogy can prove more interesting and simpler to understand for a young crowd than dealing with real numbers on paper that don’t achieve any perceivable consequence, whereas in the app, it helps the dragon come out.

4.3 Gamification for Learning

Different Gamification elements favor different outcomes, for this dissertation the focus is pointed at learning. This section takes a look at some of the Gamification elements fostering learning activities and the influence they produce, as explained by Karl M. Kapp in his book[Kap12].

Storytelling and Analogies

Stories and analogies, like the ones used in the Dragonbox Math Apps[WeW], are good elements that can work as simpler to understand examples to demonstrate concepts. Every learner is dif-ferent, some may be capable of understanding the source materials easily enough, others may strongly benefit for having an alternative situation describing the same lessons in contents more easier to empathize with.

Challenges

Challenging the learners to solve problems, as is the case with Foldit[Han10], works both as a means to stimulate their attention and entertainment, as well as an opportunity to guide them into learning determinate concepts. Solving a challenge creates a sense of accomplishment and satisfaction that motivates the learner to progress further in their quest for learning.

Competition and Cooperation

Working with and against others is an effective tool to create motivation for the learning activity. A competitive social scenario creates opportunity for one to prove their selves and measure their abil-ity against others. Likewise a cooperation scenario can stimulate the willingness for one to learn coming from the need to have the ability to help and contribute to a collective work experience.

Characters and Avatars

Characters and avatars are an effective mean of reinforcing or transmitting behavior. Its been shown that for users engaging in experiences where characters or avatars they can relate to are available, their enjoyment and productivity within the activities raises, due to the increase in inter-est these actors cause. Those characters can even be modeled around depicting behaviors related to the activities, which creates a scenario where users interacting with them are known to be more likely to adopt those behaviors than users doing otherwise.

(41)

Gamification

Intrinsic and Extrinsic Rewards

Rewards drive motivation. Creating rewards for reaching goals is often a good incentive for learn-ers to engage in related activities. It’s important to be able to undlearn-erstand the two types of rewards to be able to properly use them.

Intrinsic rewards can be described as an implicit outcome for engaging in activities, they’re the lesson learned or the reason why someone seeks to practice learning. In gamification for learning, this is naturally the knowledge that’s trying to be conveyed. Extrinsic rewards are actual obtainable rewards, acquiring them is the goal of the activity. These can range from points or credits exchangeable for higher rewards, as is common in games, to even real world tangible objects. Take as an example a student studying for an exam, the knowledge they acquire is their intrinsic reward, the grade of the exam is their extrinsic reward.

Intrinsic rewards are the most desirable outcome for a learning activity, so these should be designed around providing them, however, this sort of rewards might often not be perceived by the learners as something in their desire to acquire. This is where extrinsic rewards come in, to create motivation for activities where the learner would otherwise not be interested with engaging in. In simpler terms, extrinsic rewards should act as a motivator to make users pursue the intrinsic ones. This makes it important to balance out the amount of extrinsic rewards that an activity provides, so the goal of the activity remains in acquiring knowledge and not drive learners to single handedly focus on those rewards, losing their focus on the learning practice.

4.4 Summary

Gamification has its origins in entertainment, which is noted for being a kind of activity that capti-vates its audiences attention very well, an aspect desirable to translate into learning environments. Gamification projects can produce outcomes that turn serious activities into highly more produc-tive ones generating the same or better results in a more enjoyable experience. Game mechanics can be beneficial in helping individuals acquire knowledge, learn new skills and adopt behaviors.

(42)

(43)

Chapter 5

Planning, Methodology and Goals

This chapter describes the overall plans into upgrading DRIVER into a new iteration, the gen-eral development process behind this work, the issues attempted to be tackled and the motivation behind the choices made into the production of the new version of the platform.

5.1 Introduction

DRIVER seeks to make developers lives easier, however, the platform faces low adherence. This is mostly attributed to the user experience with the platform. It currently faces a problem where, instead of making the learning task an easier and more enjoyable one, how the tool currently works, produces in reality a reasonably extra workload for the developers to interact with the platforms features and benefit from them, as noted in Chapter3.3. Notably, its Learning Path feature doesn’t ever really invoke a sense of “Return of Investment” in the task of producing such paths. Without users making contributions to the Learning Path ecosystem, the platform loses its purpose.

This dissertation’s goal was to enhance the appeal of using the platform and its features through the means of Gamification, however, it was deemed important to also rework its foundation to solve its inherent problems, as Gamification is no sorts of a silver bullet to fix everything wrong with an appliance. Therefore, the aim was to restructure the platform in two steps, a Redesign step, focusing on improving functionality and user interaction with the tool and a Gamification step, boosting the appeal and enjoyment of using it.

5.2 Development Methodology

Figure5.1displays a rough schedule on how the project evolved over time, showing the method-ology behind producing its work. Next are displayed the descriptions of each of the steps behind realizing this dissertation work.

(44)

Planning, Methodology and Goals

Figure 5.1: Gantt chart of the dissertation’s development schedule by weeks

Planning (September 16 - September 29)

The work began by experimenting with technologies to determine which ones would be suited for the development process of the platform upgrade. This process was accompanied by the specifi-cation of the requirements for the new DRIVER iteration, modeling its new design and features. It should be noted that a lot of this planning, the literature review and research for it, was performed during a previous semester while undergoing the “Dissertation Planning” course, which precedes the focused development of this dissertation work.

Development (September 23 - December 08)

This encapsulates the entire development process of the platform, it began by implementing the basic functionality, continued into the Redesign and Gamification stages of the process and fin-ished in a period of testing for potential issues and small refinements to the new version of the tool. The development was accompanied by regular meetings with the dissertation’s supervisor in order to ensure consensus between the implementation and plans previously made.

Validation Experiment (November 11 - December 15)

Time dedicated to conceiving and performing the validation experiment in order to obtain ar-guable results regarding this dissertation project. Began with the planning and location of pools of potentially available test subjects, followed by producing the required materials and preparing the platforms necessary for running the experiment and collect its results. Naturally finished by performing the validation experiment itself.

Dissertation Documents (December 16 - January 31)

This period began with reviewing the results of the validation experiment in order to find the inherent conclusions coming from it. It was then that the development progressed into writing this dissertation document, taking the time to evaluate the outcome of the produced work and the conclusions that have been taken from producing it.

(45)

Delivery and Presentation (January 27 - February 24)

The final stage of the dissertation project. This involved an initial delivery of the produced doc-uments for evaluation, followed by an open discussion of the produced work, finally concluding the project through the final delivery of the produced documents and artifacts.

5.3 Redesign Plans and Goals

The Redesign aspect of this dissertation aimed at solving inherent problems within the interface and user experience of the original DRIVER platform, in an attempt to solve issues that would preemptively tone down the use of gamification within the project. The following paragraphs note the major plans going into the redesign process and the goals behind each one of those.

Rework the Learning Path feature

The plan revolved around making the path tracking start automatically and reduce the workload necessary into producing appropriate ones.

In terms of tracking, for example, when a user would open the platform, their path would start recording immediately. If the user had been away/idle from the the platform for a while, the tool would offer to cut the path and start tracking from scratch.

The new system would make use of the user’s bookmarks throughout the documentation sec-tions as cues to perform cuts in a path. Upon the process of storing a path the users would be offered several options to more quickly clean up unnecessary steps from the path and the system would now attribute tags to it based on the pages and sections it contained instead of relying on the user’s input, significantly reducing the workload needed to produce Learning Paths.

This had a simple goal, to turn Learning Path production into an easier and simpler process by automating more parts of it, so users would be less likely to see it as an extra “chore” in using the platform.

Replace the mechanisms of sharing paths and searching/browsing for them

It was deemed that sharing a path in the original DRIVER tool doesn’t really promote self benefit, its something that seemingly only creates value to others and not the person producing them. Browsing for Learning Paths doesn’t work exactly as an intuitive thing to do as well, as an user is rather used to searching for concepts and wrappers of them.

So the idea was to revamp the feature for publishing Learning Paths, removing the search mechanism and giving users more control over their created content. Now instead, users would keep the paths for themselves, in a personal wallet/storage, creating a sense of ownership and keeping those references for their later use. With this new scenario, paths would inherently influ-ence how the platform displays its contents, instead of exclusively relying on sharing to improve other’s perception of the documentation.

(46)

The plan was to create an highlighting feature for documentation sections and pages based on the paths users had stored in the platform. A section present in more paths would have a distinguishable different highlight compared to others.

It should be noted that Learning Paths would still be able to be shared, however this time around, these wouldn’t be something that would appear on a search-able catalogue, instead, they’d be artifacts users could directly share with acquaintances, reinforcing the sense of owning and producing content within the platform.

The goal behind these changes was to enhance how Learning Paths work within the platform so that they more proactively affect how users navigate content through the documentation. The users would now have direct feedback on the consequences of making use of the feature and potentially be more likely to engage with it.

Improve the user interface and experience

The plan was to introduce a new user interface, easier and more intuitive to use, promoting the visibility of the features available in the platform while preserving the core concepts behind the features of the original DRIVER. An example of what this new interface would do, would be keeping the recommendation widget always visible as opposed to being hidden in a fold-able tab by default, having its knowledge always easily accessible by the user.

The goal here was to make it so widgets with important information would always be displayed to users, such as their current learning path, as well as turning the overall interaction with the platform simpler and more comfortable, reducing the necessary steps and transitions needed to make use of its features.

Increase the scalability of the platform

Its been noted in Chapter3, that the original DRIVER platform works as a DokuWiki[GD] plugin. While this has its own merit, the way it works can be rather constricting to the implementation of new features in the platform (such as Gamification ones). The redesign process involved recreating the tool, as such, one part of it involved evaluating existing technologies to choose better suitable ones to meet this dissertation’s goals. In doing this, it was established that a goal for this project would be choosing the technologies and potentially design the platform around enabling future scalability efforts.

5.4 Gamification Plans and Goals

The Gamification aspect of this dissertation focused on turning DRIVER into a more appealing platform, to foster the adherence of its users and to create incentive to make use of its distin-guishing features. The target of Gamification here, was to benefit and improve the quality of the learning experience.

(47)

It should be noted that special attention was put into moving motivation towards the use of Learning Paths, the feature that turns the platform unique and learners are not accustomed to using, making developers not rake the potential benefit the feature provides.

So the general goal of the Gamification effort put into the new version of the DRIVER plat-form, was to make the tool more likely to captivate its users and drive their motivation , so their productivity in using it would increase. The following paragraphs describe the major Gamification mechanics that were planned in being added to the new DRIVER iteration.

Customizable User Avatar/Character

The plan was to give users an Avatar they could customize, a character or mascot to represent themselves in the platform. This could work, not only as a means to transmitting behavior, but also as a reward engine to create awards for using the platform’s features.

For example, as the user would unlock more customization options for their avatar, by using the platform’s features, the avatar’s appearance evolving could work as an indirect indicator of the user’s progress through learning how to use the framework described in the documentation. This would also work as reinforcement to the idea that the behavior behind creating Learning Paths is a rewarding one, intrinsically, as the user acquires and shares knowledge with others by using it, and extrinsically, as the user obtains customization options for their avatar.

Rewards for using the platform’s features : Experience Points

Chapter4refers to intrinsic and extrinsic rewards as a good motivator to increase an user’s interest and productivity. Again, the intrinsic reward available in DRIVER would be the knowledge on how to use a framework. As a plan to increase the interest in said knowledge, a set of extrinsic rewards was planned.

The new version of the platform would introduce a set of frequently regular activities, these would be the sorts of creating Learning Paths or sharing them with other users. In performing these activities the user would acquire points, these points would then be accounted towards progressing levels in the platform and acquiring rewards. These are often regarded in games as “Experience Points” or “Exp” for short.

When combining these obtainable points with the previously mentioned Avatar, to create a progress system where the user would seek to collect them in order to obtain new customizations, an extrinsic reward ecosystem would be created so the users felt motivation towards interacting with the platforms features.

Point/Experience Leaderboard

Developers like to compare their skills against others. It was thought interesting to use competition to create motivation for the platform’s users. The experience points previously mentioned could also work as a good indicator for a developer’s work put into mastering the knowledge around using a framework. So the plan here, was that these points could also be tallied in a leaderboard,

(48)

creating a system where users could compare themselves to each other, possibly increasing their interest in acquiring those points and overall usage of the tool.

Weekly Challenges

As an additional method to obtain experience points and progress through unlocking rewards in the platform, a “Weekly Challenge” feature was planned to be added to it.

These would be weekly problems produced by the platform’s administrators that would chal-lenge the developer’s understanding of the framework documented. Users would submit answers, that when deemed correct, would reward them with a large amount of points for their work. These problems and answers would need to be simple enough so the evaluation task could be automated. One possibility was to use Learning Paths as the answers to be submitted, forwarding the impact the feature would have on the user’s usage of the platform.

This feature was deemed interesting because it could also work as a good means of guiding users into the knowledge they should obtain. Picture an academic context, a teacher could develop a problem that would require students to navigate knowledge they would potentially need later for a test or exam. In the context of an open and general framework, this could be used to introduce new features or updates for its users.

5.5 Expected Results : Gamification vs Redesign only

The primary goal of this dissertation work was to assert the impact of Gamification as a rein-forcement to improve the productivity and satisfaction of developers using the DRIVER platform. Despite the overall redesign of the tool, this remained the main topic to discuss and experiment with, in order to capture the primary results coming for the conclusions of this project.

With this, a validation plan was formulated where a test experiment would run a comparison between two setups of the new DRIVER by having test subjects attempt to solve a problem using the platform. One of the setups would use a fully featured version of the new tool, including the recently added Gamification elements, named here as the “Gamification Setup”. The other setup would host the tool as well, however, this one would have its Gamification features disabled, completely unknown to its users, dubbed the “Redesign Only Setup”.

The goal would be to measure the following metrics across the two setups: • Time to complete the problem1

• Knowledge intake2

• Satisfaction / enjoyment in using the platform3

1_{If time went over a limit, overall progress would be considered instead.} 2_{Measured using a small form post experiment.}

(49)

The expectation behind the validation experiment pointed at the following results: • The time to complete the problem would be similar across both setups

• The knowledge intake would be similar across both setups, or slightly higher for the Gami-fication Setup

• The satisfaction in using the platform would be higher for the Gamification Setup

The time spent between both setups shouldn’t differ much, one of the setups would potentially covet less interest in the tool, while the other would have significantly more features for the users to get accustomed with, balancing times out. It should be noted that in a scenario where users would’ve already been accustomed to the tool, then the difference in time should’ve favoured the Gamification Setup.

The knowledge intake shouldn’t also differ much, since both setups would be equipped with the same features regarding the knowledge of the framework within, however, it was hypothesized that since Gamification would drive the users’ interest for the features of the platform, test sub-jects could potentially be more prone to exploring the tool, hence creating a chance of a higher knowledge intake for the Gamification Setup.

Last but not least, the satisfaction in using the platform should be higher for the Gamification Setup, as the game mechanics introduced in this setup would be expected to drive the interest of the test subjects using it, more so than the Redesign Only setup. This metric is particularly important, because satisfaction in performing an activity can usually translate at a more efficient, or at least more focused, involvement in it, which in a long term scenario, could potentially apply positive influence in the other two previously mentioned metrics.

The fulfillment of these expectations would then point at the hypothesis that Gamification does indeed work as a good motivator to raise the interest and appeal of using DRIVER, and that its addition worked as a supplement to help at the developer’s productivity at the task of learning how to use frameworks.

5.6 Summary

The methodology behind the development of this dissertation followed an iterating model. It began with the review of literature and technologies together with the planning of the overall project, continued by the production of the new DRIVER tool, followed by its validation experiment and finishing by writing down the resulting documents and conclusions.

The planning scheduled a redesign of the original DRIVER’s user interface and experience so that users could better engage with the platform’s features and solve its inherent problems, putting special focus on making the most of its Learning Path component. It also aimed to integrate Gamification into the tool to further increase the appeal in using it. The expected results pointed at Gamification being a good addition to the platform and that it would increase the satisfaction of its users and potentially make interacting with the tool a more productive experience.

(50)

Redesign and Gamification of a Social-Intensive Software Learning Environment

F

E

U

P

Redesign and Gamification of a

Social-Intensive Software Learning

Environment

Pedro Manuel Monteiro Albano

Redesign and Gamification of a Social-Intensive Software

Learning Environment

Pedro Manuel Monteiro Albano

Mestrado Integrado em Engenharia Informática e Computação

Abstract

Resumo

Acknowledgements

Contents

List of Figures

List of Tables

Abbreviations

Chapter 1

Introduction

1.1

Context

1.2

Motivation and Goals

1.3

This document’s structure

Chapter 2

Framework Learning

2.1

Introduction

2.2

Documentation Pages

2.3

Documentation Design Practices

2.4

Summary

Chapter 3

DRIVER

3.1

Introduction

3.2

Learning Paths

3.3

Usability Problems

3.4

Summary

Chapter 4

Gamification

4.1

Introduction

4.2

Examples of Gamification

4.3

Gamification for Learning

4.4

Summary

Chapter 5

Planning, Methodology and Goals

5.1

Introduction

5.2

Development Methodology

5.3

Redesign Plans and Goals

5.4

Gamification Plans and Goals

5.5

Expected Results : Gamification vs Redesign only

5.6

Summary