Alejandro Ortega Arranz

ELECTRICALANDCOMPUTERENGINEERINGDEPARTMENT

ELECTRONICSANDCOMPUTERSDIVISION

DESIGNAND DEVELOPMENTOFAN EDITOR FOR LOCATION-BASEDGAMES

DIPLOMA THESIS OF ALEJANDRO ORTEGA ARRANZ

UNIVERSITY OF VALLADOLID

Supervisors: PROF. N.AVOURIS

DIPLOMA THESIS NUMBER: PATRAS JULY 2014

CERTIFICATION

It is certiﬁed that the Diploma Thesis with the title:

Design and Development of an Editor for Location-Based games

Of the student of University of Valladolid, Spain:

ORTEGA ARRANZ, ALEJANDRO

(Eπωνυµo) (Oνoµα) (Πατρωνυµo)(AM)

Was presented in public at the Department of Electrical and Computer Engineering of the University of Patras, Greece on July 10th, 2014.

The Supervisor The Head of the Electronics and Computers Division N. Avouris E. Housos Professor: N. AVOURIS Student: ALEJANDRO ORTEGA ARRANZ

Title: Design and Development of an Editor for Location-Based games

Abstract Nowadays, mobile games and applications have turned around in essential elements in the current society. But, at the same time that world does not stop (society, tendencies, ... it changes daily), mobile games and applications should update and modify their contents. Thus, content providers play an important role and turn around important. The Human Computer Interaction (HCI) group from University of Patras, have developed some mobile games with a playful and educative scope, and also its content editors. But, could be possible stopping developing one editor for each game and make one in common? even could we extend it to other games not developed by the HCI group? This will be our purpose during this document. Trying to create a content editor despite the fact of the differences of the games, logic, user interface and other many aspects which differ them. Therefore, the content provider should be able to create, edit or update the information or content without changing the performance of the games. For carrying this out, ﬁrst of all we should analyze which things the games have in common and then, to get an abstraction. This abstraction should work for all the games although they have incompatible properties among them. Then, for this kind of properties, we should add somehow a visibility parameter. By this way, that properties will be invisible for games which do not use them. Hence, this common content editor should be able to add, modify and delete objects of the games which have been developed and can be played everywhere in the whole world. Acknowledgements

The work described in this Diploma Thesis has been done at the Laboratory of Human-Computer Interaction Group of the University of Patras, Patras, Greece in the period between February 2014 and July 2014, and was supported by an Erasmus Student Exchange Grant.

First, thanks to my parents and my brother Hector,´ because they are every- day supporting me. To my whole family who have been sustaining me during my life. To my friends, because they have been always there, although they are not close. To Rodrigo, for his company and collaboration developing Tagging Creaditor. I cannot forget my tutor, Christos and Menita for their valuable guidance and advice, trusting me. And also, to those who came to help me with the Evaluation of the application in a summer Sunday.

To all people I have met during my Erasmus in Greece.

You are really great people.

With all one’s heart, Thank you all!

Table of Contents

1 Introduction 1 1.1 Motivation ...... 1 1.2 Objectives ...... 2 1.3 Location-based gaming ...... 2 1.4 Linking games ...... 3 1.5 Referenced games ...... 3 1.5.1 MuseumScrabble ...... 4 1.5.2 City Scrabble ...... 5 1.5.3 Benaki Museum Scrabble ...... 5 1.5.4 Taggling ...... 8 1.5.5 Other Games ...... 8 1.6 Main common features ...... 10 1.7 Main different features ...... 11

2 Application’s design 13 2.1 Abstractions ...... 13 2.2 Requirements ...... 15 2.2.1 Name of application ...... 15 2.2.2 Client-Server architecture ...... 15 2.2.3 Common database ...... 15 2.2.4 Collecting data ...... 16 2.2.5 Basic functions ...... 16 2.2.6 Doing real-virtual relationships ...... 16 2.2.7 Location identiﬁcation ...... 16 2.2.8 Mobile implementation ...... 16 2.2.9 Recommendable features ...... 17 2.3 Hierarchical model ...... 18 2.4 Terminology ...... 19 2.5 Initial database ...... 19 2.6 Initial design ...... 22 2.7 Use cases ...... 25

vii viii TABLE OF CONTENTS 3 Implemented technologies 29 3.1 Web-based applications ...... 29 3.2 Web programming languages ...... 30 3.2.1 Markup languages ...... 30 3.2.2 Cascading style sheets (CSS) ...... 32 3.2.3 JavaScript (JS) ...... 32 3.2.4 PHP ...... 34 3.3 Zurb foundation ...... 36 3.4 Data base management systems ...... 36 3.5 Data exchange ...... 37 3.6 Web server ...... 37 3.7 Location services. Google Maps...... 38

4 Development and implementation 39 4.1 Introduction ...... 39 4.2 Database ...... 39 4.3 Welcome screen ...... 44 4.4 Main screens ...... 45 4.4.1 Game list ...... 45 4.4.2 Location/Element ...... 46 4.4.3 Topic/Key ...... 47 4.4.4 Easy-way linker ...... 47 4.5 Secondary screens ...... 48 4.5.1 New/Modify game ...... 49 4.5.2 New playspace/New theme ...... 49 4.5.3 New location/New topic ...... 49 4.5.4 New element ...... 49 4.6 Extra functionalities ...... 50 4.6.1 Support for languages ...... 50 4.6.2 Support for kinds of devices ...... 51

5 Evaluations and results 53 5.1 Evaluation ...... 53 5.2 Results ...... 54 5.3 Future work ...... 56 References ...... 58

A Screenshot of the application 59

B Evaluation of TaggingCreaditor 65 B.1 Evaluation sheet ...... 65 B.2 Scenarios ...... 66 TABLE OF CONTENTS ix C Desktop-version User Guide 69 x TABLE OF CONTENTS List of Figures

1.1 Topic Selection (left) and Exhibit Association screens (right) of MuseumScrabble game...... 4 1.2 The three different screens of CityScrabble game: Selection (left), Object assignment (center), and Map(right)...... 6 1.3 New Screens in Benaki Museum Scrabble...... 7 1.4 New Screens in Benaki Museum Scrabble...... 7 1.5 Screenshots of Taggling...... 9 1.6 A couple of Invisible City screenshots...... 9 1.7 A couple of Invisible City screenshots...... 10 2.1 First hierarchy abstraction of the application’s model. . . . . 14 2.2 Adaptive response moving from desktop to mobile version. . 17 2.3 Example of possible values of a game object created with our tool...... 19 2.4 Initial data base for Tagging Creaditor...... 20 2.5 Recommended procedure for creating content with Tagging Creaditor...... 26 3.1 Example of HTML code used in Tagging Creaditor. . . . . 31 3.2 Result of Fig. 3.1 HTML code...... 31 3.3 Example of CSS and HTML code among with the result in Tagging Creaditor...... 32 3.4 Example of JS, CSS and HTML code among with the result in Tagging Creaditor...... 33 3.5 Example of JQuery code used in Tagging Creaditor. . . . . 33 3.6 Process of generation of a dynamical webpage...... 34 3.7 Example of PHP, CSS and HTML code used in Tagging Crea- ditor...... 35 3.8 Short piece of Taggling Database using phpMyAdmin. . . . 37 4.1 Code used for supporting different languages in gameList.php. 51 4.2 Code used for supporting different kinds of devices. . . . . 51

xi xii LIST OF FIGURES 5.1 Diagram with the comparison between the best results and ours...... 56 A.1 Initial design of Location/Element Screen...... 59 A.2 Initial design of Topic/Key Screen...... 60 A.3 Initial design of Easy-way Liner...... 60 A.4 Final database of Tagging Creaditor...... 61 A.5 Welcome Screenshot...... 61 A.6 GameList Screenshot...... 62 A.7 Location/Element Screenshot...... 62 A.8 Topic/Key Screenshot...... 63 A.9 Easy-way Linker Screenshot...... 63 List of Tables

2.1 Example of score representation for relationships between real and virtual content...... 15 2.2 Basic functions that application at least should include. . . . 16 2.3 Comparison of real objects names in games and new content provider...... 20 2.4 Comparison of virtual objects names in games and new content provider...... 20 3.1 Classiﬁcation of programming languages depending on where are interpreted...... 30 5.1 Results of the SUS questionnaire for the desktop application. 55 B.1 Personal data of testers...... 65 B.2 SUS questionnaire for the desktop/mobile applications. . . . 68

xiii xiv LIST OF TABLES Chapter 1

Introduction

In this chapter we will explain the motivation which has led us to develop the application, and also work with location-based and linking games. First, we will set some objectives that we will mainly try to develop during the whole project. Afterwards, we will make a detailed study about the core of this project, the location-based and linking games. Finally, we will analyze the games and applications already developed by the HCI researching group, because they represent the kind of games that our application is going to give service.

1.1 Motivation

Currently, with the evolution of programming, the use of a different content editor for each game is a waste of resources and time. Hence, the creation of a tool able to manage the largest number of games at the same time will entail great beneﬁts: (1) developers will not waste time programming editors for games or applications; and (2) the ﬁnal users will only need to get familiarized with just one editor. However, the creation of only one editor for all kind of games and applications is an impractical task due to the huge amount of game types. Thus, the editor we will develop will be fo- cused on games with two main features: (a) location-based games; and (b) linking games. Nowadays, this kind of games is becoming popular because the current widespread smartphones have the technological devices, such as cameras and GPS among others, embedded on them, needed to execute these games.

1 2 CHAPTER 1. INTRODUCTION 1.2 Objectives

As we said before, our main goal will be to develop an application able to provide content at least to four games used as reference. We want that our content-provider tool should be the most abstract as possible with the aim to use it for other games of the same kind, and even, for other type of games. Moreover, the application not only must be capable of creating content, but also of editing the information of the content previously inserted. We will also complete other important objectives and we will develop secondary features of the content-provider tool. It should provide an adaptive response for any mobile device, in such a way that the tool can take information related to the current position of the user, such as the GPS or network location, at any moment. Another required feature is that the application can be used by many people simultaneously, either for creating content or for editing the information of the same game or different games. Despite the complex structure needed to provide the application abstraction, it should be intuitive and easy to use. In this way the final users will not require to be experts in technological knowledge. Also, during the development of our tool will rise new minor objectives that will be explained in the following sections. We will proceed as follows. We will analyze the properties of the game types with we are going to work. Then, we will focus on four games that constitute our workbase. After study them, we will create an abstraction with their common features. Finally, we will design, with this information, an user interface implementing some initial functions. These functions will be modified during the tool creation for a better performance and better reli- ability of the application. These modification will be reported in along this document.

1.3 Location-based gaming

A location-based game is a type of pervasive game in which the gameplay evolves and progresses through player’s location. Thus, these games can be only played with devices that can report its position, such as GPS or WiFi (most common in outdoors games), or even other kinds of antennae. Most of the location-based games are developed for mobile phones because this kind of devices are generally embedded in these mobile platforms. This is the reason they are often called as location-based mobile games. The first location-based game was developed in Sweden in 1999. It is called “Pirates!”. The first commercial location-based game, named “Bot- fighters” appeared one year later, in 2000. The players of this game consists 1.4. LINKING GAMES 3 sent a SMS (Short Messaging Service) to see if there were any other player in their area. Then, when the game server received a SMS, it checked if there were more players in the same GSM (Global System for Mobile) antenna. If so, the server enables them to play each other via SMS. Currently, most of the location-based games use a client-server architecture which is the responsible of managing the positions and all the information related to the game. It is necessary to use this scheme because if the game is played in big areas, mobile devices does not have enough capabili- ties to send large quantities of information towards far distance using an ad hoc architecture. Location-based games can be classified in many ways. We will follow the classification criteria presented in (Avouris & Yiannoutsou, 2012): Ludic tradition, Pedagogic tradition and Hybrid tradition games. The games of the first category are developed for the enjoyment of the players. Most of location-based games belong to this group. Pedagogic games are related to those ones that have been developed with the explicit objective of self- learning. Finally, Hybrid games are designed for both purposes. The games we will use belong to this last category.

1.4 Linking games

Some location-based games provide an augmented reality. It is a combination of both, real-world and virtual-reality components. Then, the objective of some of them is to connect real elements with virtual components. We call this kind of games as Linking Games. In order to reach this purpose, all the real components should be linked to a mirror object that identiﬁes them in the virtual section. Taking a picture of the element we want to know its information, getting close to it or putting the mobile in front of it, among others, are examples of obtaining the related QR code or the RFID tag associated with this element. Then, the server should use the database to recognize which element has been obtained. Once it will retrieve it, then the user can link it with the virtual components.

1.5 Referenced games

In order to develop the application, ﬁrst, we will analyze some of the location- based games developed by the HCI Group. Later, we will study them looking for similarities between them in order to create a proper abstraction level for our tool. At the end, our project should be able to give to the user the possibility of providing content for these games. 4 CHAPTER 1. INTRODUCTION

Figure 1.1: Topic Selection (left) and Exhibit Association screens (right) of MuseumScrabble game.

1.5.1 MuseumScrabble MuseumScrabble (MS) (Sintoris et al., 2010) is a location-sensitive multiplayer mobile game for museums. Players try to scan the correct exhibit using a hint that is displayed on their mobile devices. It is based on the scrabble board game. Originally, the game was developed for the Museum of Solomos and Eminent Zakynthians (Zakynthos, Greece). Additionally, it could be used in others museums just only changing the content of the game. In past versions, the identiﬁcation of the exhibits are RFID tags. Later, it has been updated to QR codes. It could be also updated in order to be de- tected by another kind of identiﬁcation processes, such as exhibit proximity or exhibit photographic capture. Currently, the dynamic of the game consists on: several players are or- ganized in teams that win points by making right connections between the exhibits and the hints. These teams compete to obtain the maximum punc- tuation till the game ends. It ends when all available links have been established. However, this ending criterion can be changed for a period of time instead. Figure 1.1 shows the different screens that the game displays: (left) the “topic selection screen”; and (right) the “exhibit association screen”. The players have to choose one of the proposed topics, and later, they will have 4 different hints. These hints are available as long as other players do not have linked them before. The players link one of the exhibits they have been previously scanned with one of these hints. The captured exhibits are virtu- 1.5. REFERENCED GAMES 5 ally shown in the bottom part of the “exhibit association screen” (see Fig. 1.1 (right)). In there, we can see that all the topics and exhibits have a picture, title, and description. We should take into account these properties for our application.

1.5.2 City Scrabble CityScrabble (CS) (Sintoris, Papadimitriou, & Yiannoutsou, 2012) is a location- based game for open areas. The game target is the same as MuseumScrabble, but in this case it can be played in any open space such as city centers, ar- chaeological parks or other sites of some importance. It can also be played in closed spaces such as museums or any other relative large space. The only thing that you need is a mobile Android device as a smartphone with possibility of Internet connection. As we said before, the target is the same but it has different names to call the elements which take part of the game. Thus, players has to locate objects (exhibits in MuseumScrabble) and link them with small sentences called keys (hints in MusseumScrable). The way to get the identiﬁcation of the objects can also be by different possibilities, such as triggering a GPS proximity sensor or scanning a QR tag. Once the player has the identity in the mobile she can connect it with a key and try to get points if the relation is meaningful. Each key can be connected only by a single team in each game session. In this game is introduced the session concept, the same game with the same content can be played by different players who are not competing between them concurrently at the same time. Although this addition should not affect on how provide the content on the game. The end of the game can be changed by the authors game, but for CityScrab- ble use to ﬁnish when a timer is over. This timer will depend on the size of the area but normally it is around 30 minutes. We can see in Figure 1.2, that the screens are quite similar comparing them with the MuseumScrabble ones, although with a renewed graphic interface. But also players have a new screen: Map screen, where they can see the remaining objects which can be still connected with keys. CityScrabble has the same properties than MuseumScrabble: title, description and picture, but it also include the GPS coordinates for the map.

1.5.3 Benaki Museum Scrabble Benaki MuseumScrabble (BMS) (Sintoris & Yiannoutsou, 2012) is a location- sensitive mobile game, developed for the Benaki Museum in Athens. The 6 CHAPTER 1. INTRODUCTION

Figure 1.2: The three different screens of CityScrabble game: Selection (left), Object assignment (center), and Map(right). game aims to engage visitors (mainly student groups) in a process of dis- covering relationships between museum exhibits and objects that are not exposed. All that players or teams need is a mobile device able to scan QR tags and follow the progress of the game. Commonly the teams are made by 2 people and they will try to beat the rest of the teams. One of the main different of this game with the precious ones is that it is played in rounds in which players are competing as the other games for getting the right link before than others. At the end, the team with more points wins. As the other games, points are got by making right relationships. In this game, also the objects have different names. The exhibits which are exposed are called Physical Artifacts (exhibits in MS, objects in CS) and virtual information which is related with exhibits not exposed are called Digital Objects (not exactly this concept neither in MS nor CS). Making a deeper analysis, we can see in Figure 1.3, an example of the first screens displayed to the player. The first one is the game topic selection with different levels of difficulty and number of players established. Once selected a description of the topic selected introduces the scenario to the players. When the introduction finish and at the beginning of each round, a digital object is displayed on the devices of all groups along with some clues (hints in MS, keys in CS) for the physical artifacts that should be connected with the digital object displayed, as shown in Fig. 1.4. Now is time for the players, who have to look for physical artifacts in 1.5. REFERENCED GAMES 7

Figure 1.3: New Screens in Benaki Museum Scrabble..

Figure 1.4: New Screens in Benaki Museum Scrabble.

the halls of the museum and scan, using their devices, QR tags of they that players think are relevant to the “clues”. When they ﬁnd the right one before another team, all they have to do, is to make the connection with the digital object displayed at the beginning of the round.

We can also see in Fig. 1.4 that teams can see the progress of the game (rounds completed and left) in the upper part and their scores. 8 CHAPTER 1. INTRODUCTION 1.5.4 Taggling Taggling (Manoli & HCI Group, 2014) is an educational game that takes place in a contemporary arts museum. It is a real-time multiplayer game although it can be played by one player. All players need is a mobile device (phone or tablet) and a new approach in the eyes of contemporary art. The name proceeds from the mixture of tagging (placing tags) and tangling (shuffle, jumble, occupation). The target of the game consists on putting in the right order shuffled tags while players take a look to the exhibits of the museum. These shuffled tags are described by a number of concepts, words, phrases or names which have a direct relation with the exhibit. Tags (hints in MS, keys in CS, clues in BMS) help to the players to get an idea or knowledge of which is the exhibit that they are referring by characterizing or describing it. Then players should be able to go until there, take it identity and make the connection. But this game is not like the others before, unfortunately, these tags are mingled. Some of them jumped to other exhibits and some of them are hidden in the players’ devices. The winner is the player who has won the most points by doing the right connections at the end of the game. Players have to scan the Qr codes of the exhibits to remove and pick up tags they believe do not belong to the exhibit them by taking away to their device to transfer them to the right exhibit. Also if player scans it, he/she can add tags, obtained before, from their device to the exhibit if fits better. So one by one all tags will be put back in their right places. Players get points when they make the right connections between real and virtual objects by putting the correct tags on the right exhibit. Also, they will receive more points (bonus) when they complete all the correct tags of an exhibit. They also can lose points when they place wrong tags, consequently, they can see their progress while playing. Tags with the same importance and meaning are grouped in categories, for example Artist or Technique. It indicates that the tags represent the artist or the way a work of art was made. Moreover, each category has a specific color which distinguishes it (see Fig. 1.5).

1.5.5 Other Games During the development of the application, we also have been analyzing other games in order to have a wider vision of the kind of games. These are for example, Invisible City (Group, 2014) or (Niantic Labs, 2012), which we will make a brief summary of them. 1.5. REFERENCED GAMES 9

Figure 1.5: Screenshots of Taggling.

Figure 1.6: A couple of Invisible City screenshots.

Invisible City: Rebels vs Spies is a location-based game, but not a linking game. The aim is to visit locations in a city by playing a group game that engages you to interact with buildings, monuments, streets etc... (Group, 2014), we can see some screenshots of the game in Fig. 1.6. Actually the content of the game is only for the city of Patra (Greece), that is why we will also try to apply our application on it. The gameplay is that the player belongs to a team of Rebels who ﬁght for a cause. To meet the cause, Rebels have to carry out different kind of missions. But it is not so easy for the Rebels, there are some Spies who are inﬁltrated in Rebels team and will try to avoid the cause by sabotaging the missions. 10 CHAPTER 1. INTRODUCTION

Figure 1.7: A couple of Invisible City screenshots.

Ingress is an almost-real time location-based and augmented-reality multiplayer game. It was developed by Google and is played in the whole world. There are only two teams, the Enlightened and the Resistance, once down- loaded, player has to choose one of them. The gameplay consists of getting the most territory in the world for your team through “portals”. Portals are special places located in areas of interest such as monuments, squares, sculptures, landmarks... In Fig. 1.7, we can see some examples of screenshots with the picture of one real portal and a map with the virtual portals. For further information check (Niantic Labs, 2012).

1.6 Main common features

The thing that makes that they have a large number of common features is that all of them are linking and located-based games. Players only have a mobile device which let them to play with different content, whose target is to get fun and learning. The most important feature of the main referenced games is the purpose of the game: get points by achieving right connections between the physical objects (exhibits, locations, objects and so son) and the keys (hints or digital objects). All the physical objects belong to a topic and the game can have one or more different topics. In turn, in the digital part, topics consist of keys. In all of them you have always title, description and sometimes image of the real and virtual objects. The points that players win are related with the relationships, they have a preset score which can be 0 (null) or distinct of 0. Normally in these games 1.7. MAIN DIFFERENT FEATURES 11 there are only one right relationship for each object. Another important point is the relationships between the teams, players and devices. In all of games we have teams and each team can consist of one or more players. Each team plays with a mobile device and all the teams competing must play in the same session. Of course, we can also have different sessions with different teams in each session.

1.7 Main different features

Although the purpose of the game is the same, the games do not have the same way of ﬁnishing. Properties of them can be changed and ﬁnishing the game by time, by rounds played in case of BMS or by the number of links made. Relating with the previous different is the evolution of the games. In MS and in CS is the same, but as well as in them you are free of choosing the topic, in BMS do not, and in Taggling you only can play with the objects that you have found. As we have seen during the analysis of the games, each game has a different terminology. For example, what means “object” in BMS is totally different from what means in CS. Some of the games have very different and incompatible properties from the others, such as the idea of hide the tags in the real objects or the concept of Digital Objects in BMS. The last main difference is that some games are indoor and others outdoor, and GPS does not work properly in indoor places. This means, that not all of them use the same location mechanism. 12 CHAPTER 1. INTRODUCTION Chapter 2

Application’s design

The design of the application is the planning and implementation of the all concepts and functionalities which have been studied for the development of the application. It does not mean only work the graphical interface up, also the remaining features of the application, for instance, terminology used, data bases or media interaction. During this section, we will try to develop all the main features of our applications model. The steps will be, ﬁrst of all, analyze all of the features of the referenced games and then try to abstract them for a global application. Then, we will brush up all the software requirements needed for a right performance of the application. We will go on with the used model for organizing the content and the characteristics, and comparing the terminology used in the referenced games with the new one of our application. Afterwards, we will design the format of the data base that will store all the content for the games. Once did it all of this, we should be able of create a initial design with the graphical interface and locating in it the main functionalities. The chapter ﬁnishes with the different use cases and examples of how the users should act when they get the application.

2.1 Abstractions

Firstly we will try to model the objects in a hierarchy abstraction, taking into account that this model is not the last designed. It is the ﬁrst approach to the game abstractions. It consists of four hierarchical levels and it is divided into two main worlds, the physical and the virtual, as it is shown in Figure 2.1. However, all the games only have three levels (counting Game as a level), but we have decided to add one more to make a more abstract vision and group the objects in a better way. The physical world consists of everything which is touchable in the real world such as exhibits in a museum or the places where the games are played. On the other hand, the virtual world contains all

13 14 CHAPTER 2. APPLICATION’S DESIGN

Figure 2.1: First hierarchy abstraction of the application’s model. the virtual content information. All the games are linking games. As we have seen before in Linking Games section, a real object is connected with a virtual one. In the games, these objects are the lowest levels of the previous hierarchy. In the real world they are going to be called Elements and in the virtual Keys. But we cannot relate them without anything which represents the real element in the virtual world. That is the Identity, which all the elements of the game has but are different and are called different too. And this Identity also can be different in the element of the same game. Thus, elements should have a specific property which defines this. For the different properties of the games which cannot be abstracted we will probably create an option in the content provider to allow enabling these properties in the game. All of these properties will be explained in the Initial Data Base section of this chapter. The target of the game is the same, at the end of the game the team with more points win. But not all the games finish in the same way, even the same game in different version but with the same content can finish in different ways. So, the abstraction Game should have a property to store the way of finish it. That points that players win are related with the relationships, they have a preset score which can be 0 (null) or distinct of 0 and can be represented as a table. We can see an example in the Table 2.1. Normally in these games there are only one right relationship for each object. Abstracting, we can have more than one for each object. 2.2. REQUIREMENTS 15 Virtual Key 1 Virtual Key 2 Virtual Key 3 Physical Element 1 0 points 0 points 100 points Physical Element 2 100 points 0 points 0 points Physical Element 3 0 points 100 points 0 points

Table 2.1: Example of score representation for relationships between real and virtual content.

2.2 Requirements

This study will include all the tasks related with the determination of the necessities for a right performance. After the abstract requirements seen in the previous section, now we will analyze the properties needed for could apply logically the previous features studied in the application. That is, for example, if the games use the location as a main property of the objects, application should provide a way to show it correctly.

2.2.1 Name of application Firstly, although it is not a needed requirement for the correct performance of the application, every application or game has a name to recognize it. We were thinking about many proposed games, but at the end, we decided to call it Tagging Creaditor. It is because app will create (Crea) and edit (ditor) content for games, but for linking games which use tags (Tagging) to identify the real objects in the virtual world.

2.2.2 Client-Server architecture Because the games are real-time application and there are a lot of content in some games, the managing of them could be insupportable in some devices due to hardware and software problems. Therefore, our application also should use this kind of architecture and store in the server the application.

2.2.3 Common database Tagging Creaditor should have only one data base accessible via Internet in order to users can create or modify content at the same time for the same or different games. Then once created or edited the content, it should be visible for the rest of the people who can work on it. This also allows to can access to the content from everywhere and consequently to create content for any game with this properties in the world. 16 CHAPTER 2. APPLICATION’S DESIGN ABSTRACTION FUNCTIONALITIES THE EDITOR SHOULD HAVE Game New game Delete game Edit game Topic Add topic Delete topic Edit topic Keys Add key Delete key Edit key Exhibit Add exhibit Delete exhibit Edit exhibit

Table 2.2: Basic functions that application at least should include.

2.2.4 Collecting data The application should have a data input and output method to keep and get the games content. It will be analyzed in the Implemented Technologies chapter. The way of insert data in the content provider should also be easy and should include all the properties that games have. It means that at least application should provide options for all kind of content used in games such as titles, pictures, coordinates...

2.2.5 Basic functions But not only the application can enter data, also the content provider should be able to edit and delete information from the virtual abstract concepts. These functions are shown in Table 2.2.

2.2.6 Doing real-virtual relationships It should make somehow, relations between the content previously introduced in the application. We could understand in the ﬁrst chapter, how linking games are and this is one of the requirements of it.

2.2.7 Location identiﬁcation In the same way that the linking games need relationships, located-based games need a way of locate the objects. The application should include a way to put coordinates in the objects.

2.2.8 Mobile implementation In this case, it should be a desktop application for laptops and computer devices. But it should be adaptive and ready for implementing in mobile devices with few changes, as we can see in Figure 2.2. Because adding content from mobile devices is very useful for this kind of game, for example taking a picture with the smartphone and uploading it in few seconds. You can 2.2. REQUIREMENTS 17

Figure 2.2: Adaptive response moving from desktop to mobile version.

ﬁnd further information about the development of this application in mobile devices in (Lopez-Romero,´ 2014).

2.2.9 Recommendable features

The next features are not requirements but it would be recommended that application have them.

1. We said before that it could be a world-used application for providing content. Then we should give the option of using the application in multiple languages. At least in English and Spanish, two of the most spoken languages in the world.

2. It would be recommendable as in most of the applications, to add the option of help included in the application in case that the user does not have the user’s guide. Also an option for contacting with the developers in case of ﬁnding bugs or having doubts about the application.

3. In order to create two games with the same content but different properties and do not to insert the data again from zero, it would be recommendable to give an option of copying the elements and the keys of an existing game. This option could be applied for totally different games but which are played in the same location and use almost the same objects. 18 CHAPTER 2. APPLICATION’S DESIGN 2.3 Hierarchical model

Using a hierarchical model is not a requirement of the application but it is helpful for organizing the content. This kind of models let to group the information in a tree structure. Making Father-Son relationships between one level and the just downer level. The content provider application is based on a 3 hierarchical level model. Each level in the real world as in the virtual content has a specified terminology, which we could see in the next section. On the other hand, mostly of based games have only 2 hierarchical levels. The first level has been created in order to group all the second level objects and then can work in a better way with the provider. On the base of the real-model hierarchy (level 3), we have Elements. They are the real physical objects such as paintings, sculptures or whatever thing that you can find in the real world. They must be linked by a Relationship with some kind of virtual content. That content is what we call Key and it is also the level 3 of the virtual-model hierarchy. It could be sentences, images, videos... Climbing up the “real” pyramid, we have Locations. It consists on a group of Elements placed in a common space, but no so large in order to have well located all the Elements, e.g. Rooms of a museum, streets... At the same time, we use a similar concept in the virtual one with Keys, we group the same Topic keys in subject-matters. Some examples could be the XIX century or famous buildings of Patra’s city. Finally, on the top, we have decided to make a more general abstraction which group at least one Location, and we will call it Playspace. In the physical part could be the city of Valladolid or the Benaki Museum in Athens. As we could see in the previous section, Tagging Creaditor should be able to copy Playspaces in order to create different thematic games with the same Locations and Elements. Although in was no necessary, the content provider behaves similar in the virtual section (Theme), but it enables to the provider to chose which is/are going to be the thematic/s of the Game, such as His- tory or Architecture. Moreover if you want to create a more complex game, providers can use more than one Playspace or Theme in the same Game. It is useful to highlight that we cannot have third level objects (Elements or Keys) which do not are part of a second level, and it is the same with the second and the first level. It should be a problem because all real elements are located somewhere and all the keys are related with at least one topic. In Fig. 2.1, we can see orderly all the concepts that we talk in this section. And also, taking as reference this figure is easier to understand the example showed in Fig. 2.3. 2.4. TERMINOLOGY 19 Real Part Playspace: Patra Location 1: Psilalonia Square Element 1.1: Sculpture of the emperor Element 1.2: Palm with a inscription of Patra Location 2: Giorgos Square Element 2.1: Upper fountain Element 2.2: Apolo Theater Location 3: Olgas Square Element 3.1: Sculpture of Queen Olga Element 3.2: Grey bench Virtual Part Theme: History Topic 1: XX century Key 1.1: She was the wife of the King Giorgos. Key 1.2: It was built as the most representative thing in the square. Topic 2: XIX century Key 2.1: It was plant there in 1898. Key 2.2: He was the husband of the Queen Olgas.

Figure 2.3: Example of possible values of a game object created with our tool.

2.4 Terminology

As we have analyzed in Sect. 1.5, all the games use a speciﬁc terminology which is not very bearable if we are trying to collect all the common features and make only one content provider. This is the main reason because we are going to use for the abstraction a different common terminology, trying to be similar with all of the based games. This new terminology will also be used as default labels used in the content provider application, but as we will see later, it should be able to be changed for making easier the creation or edition of each game with their respective terminology. In Tables 2.3 and 2.4, for real and virtual objects respectively, we can see a comparison of the terms used in each game and their “connection” with the Tagging Creaditor names. It is also important to highlight that in a ﬁrst instance, we used the word Objectives instead Themes (in Table 2.4), but we decided to change it due to it has not the right meaning. So, during this memory when we are referring to Objective, we want to mean Theme.

2.5 Initial database

In this initial database we will decide which tables the application needs for storing the content and information of the games, and the properties of the 20 CHAPTER 2. APPLICATION’S DESIGN Games/ Musseum City Benaki Taggling Tagging Editor Scrabble Scrabble Mus. Scrb. Creaditor - - - - Playspace Real Objects (Museum) - (Museum) (Museum) Location Exhibit Exhibit Physical Artifact Exhibit Element

Table 2.3: Comparison of real objects names in games and new content provider.

Games/ Musseum City Benaki Taggling Tagging Editor Scrabble Scrabble Mus. Scrb. Creaditor - - - - Theme Virt. Objects Topic Topic - - Topic Hint Key Digital Object Tag Key

Table 2.4: Comparison of virtual objects names in games and new content provider.

Figure 2.4: Initial data base for Tagging Creaditor. each one. It is important to highlight that this is a initial model, probably and due to the later implementation it would be necessary to make minor changes on it. One of the most important things that we should keep in mind and pre- serve for future changes is to keep the database in the third normal form (3NF). 3NF is a level of normalization in databases designed to reduce the redundancy information in the relational databases, making it easier to understand. 2.5. INITIAL DATABASE 21 The graphic description of the initial database can be shown in Figure 2.4, but now we will proceed to explain all the details about it. Before explaining the main properties of the tables, we have to detail some things about the Figure 2.4 because it does not represents all the information needed for a database. First of all, in the mockup are not included the numbers of objects which are included in the upper object. It is the kind of relation, one-to-one, one-to many and so on. In this model, all the relationships are one-to-many (at least one) being one the father, and many it sons, except some cases. The relation Game → Playspace and Game → Objective (Theme) are many-to-many due to as we said before, the same playspace and/or theme can be part of different games. That is what we called it before “cloning”, for games which have almost the same elements or keys. The relation Element → Identity is also different. This is one-to-one because each element has only one identity which represent it in the virtual world. Since this is a model, it is not included neither the primary keys nor the intermediate tables which relate each other. Thus, the primary key of the drawn tables will be always a property ID, excluding the table Score which will be the mixture of the ID’s of the Element and the Key. The intermediate tables will be included and shown in the ﬁnal design which can be found in the Sect. 4.2. Most of properties are related with the information of the object such as the ID, the name, the description which are common in almost all the objects. But It is worth to explain some of these properties which are speciﬁcs:

Game Property ‘end of game’: It represents how is going to finish the game because as we said before, even the same game can finish in different ways, by time, rounds and/or relationships made. Playspace Property ‘type’: It stands for the place where the game takes place. For instance, two possibilities can be ‘indoor games’ (e.g. museum) and ‘outdoor games’ (e.g. Patras city center). Location Property ‘type’: It represents a specific subdivision where the physical elements are located. For example, in a museum game the ‘type’ could be ‘rooms’ and in an outdoor game could be a ‘street’. Element Property ‘location’: This property is used to represent the elements of location-based games which show their position in a map. Probably by a coordinates system. Identity Property ‘Action’: Initially we had though that the action that you have to do in order to get the virtual content of the element could be a 22 CHAPTER 2. APPLICATION’S DESIGN different abstract object, but we think the action is related to the identity so that it could be represented as a property of Identity.

Topics Property ‘difﬁculty’: It is used in BMS and can be used in other games in order to choose automatically the next round topic depending on the score obtained in the previous round.

Keys Property ‘visibility’: It is used to the games in which it is possible to pick up the keys from the exhibits and add keys from the device to the exhibits.

2.6 Initial design

Once decided the main properties and requirements of the content provider, the graphical user’s interface (GUI) plays an important role in the application. Initially we will try to create it with all the proposed targets and features, but probably it changes during the development of the application, trying to meet new requirements and more functionalities in order to everything works properly. The design and consequently, the ﬁnal GUI, should be intuitive, beau- tiful, not very complex and specially easy to use. But at the same time it should have all the requirements and properties explained before for the different kinds of games. One of the main reasons of this design is because the provider most of the times will be an inexperienced person in this kind of technologies. Probably he/she would like to change the content of the game in the less time as possible but at the same time that everything work. Even so, in the annex is attached a quick-start manual for learning how to use the main functionalities of the application. This design consists on one page which we will call List Games, with the list of the games already created and whose content or information can be modiﬁed. Then you can modify the content of any of them by three different but not with so different appearance pages. They are called Loca- tion/Elements, Topic/Keys and Easy-way Linker.

List Games This page should show to the user the list with the games already created, also inform us if there are no games saved in the application and in both cases, if we want to create a new one or delete the already created. More- over, we should see the properties of the games, can modify them and edit their content. Thus, the functionalities that we have to include here are 2.6. INITIAL DESIGN 23 showGame(), modifyPropertiesGame(), modifyContentGame(), addGame() and deleteGame().

Location/Elements

Represented by the mockup in Fig. A.1. It is clear that we have four differentiated sections. The header with the name of the application, a finder to make easier the search of information and also global options like the “help but- ton”, and the footer with the buttons which redirect to the three main pages of the application as we said before. This two elements, the header and the footer should be common in all the games and in all the pages of the app. If we focus on the left side, we can see a drop-down panel when clicked in each object with all of the objects which are included in the selected game that we are now modifying. They should be ordered and included in their top hierarchical level doing easy to find any element of the game for the user. Up to here, we do not have implemented any functionality because all of them are in the right part of the page along with the properties of the objects too. But the properties are shown depending on the last object clicked in the left part. That is one of the reasons because we should have a dynamical web-based application. As we have seen in the previous sections, application has three hierarchical object levels and then we should have three different situations. Last clicked on one Playspace, then all the properties of it should appear with the functionalities of editing, adding new location inside and deleting it. Moreover, if we have no playspaces included in the game we are editing, in that part should notify it to the user. When a Location is clicked, it should be the same behavior than when playspace is. All the properties are shown and also functionalities of editing, adding a new element inside and deleting it. In the base of the hierarchy we have the Elements. They are quite different in properties than locations and playspaces and also are the objects which are related with the virtual content of the games. That means that we have to add more blocks to the detail box where we can modify the properties or delete the object. The first one is the identity block, it shows how is the connection between the real object with the virtual. And the second is a summary of the linked keys of the clicked element. It should also allow to the user modify, delete and add new relationships. 24 CHAPTER 2. APPLICATION’S DESIGN Topic/Keys We can see the design in Fig. A.2. It follows a similar schema as Loca- tion/Element section changing only the location of the objects and their features. The remaining parts are the same than in Location/Element expla- nation. Its function is showing all the properties of the virtual objects of the games. And also, it has to give the opportunity to the user to modify, create or delete all the things that he/she thinks that are necessary for the game which are editing. In the virtual part we also have a three hierarchical classification which determines three dynamical situations. Following the previous order, when we click on one Theme we have the same block as in Playspace with the same features, but also we have included here the option of choose the way that the game is going to be over. In the beginning we thought to locate it here because depending on the theme that you want to use for the game, you should choose how to end the game. The problem came when one game uses more than one theme and also because you could use the same theme in different games but with different end. These are the reasons because we put this block as a property of the games, and it should be displayed in the GameList section when a game is clicked. Next in the sequence is Topic, once clicked, as in Location, the keys included on it are displayed with a drop-down panel and all the features of the topic are shown in the other side. Giving the opportunity to the user to modify or delete it, and also of including a new key inside. Clicking on a Key, we should have to blocks. The first one with the virtual information content and the relationships box. Both behave as their respective blocks explained in the Element section.

Easy-way Linker Easy-way Linker is the page where should appear only the objects of the selected game arranged, without their properties, in order to make easy how to create links among the real elements and the virtual content. It also has to include one specific block where the relationships with their scores and features are made. We have called it “Easy-way Linker” because it is supposed that you can make also links with the relationship blocks of the Element and Key section, but there you neither can see all the keys or elements of the game and in which upper level are they included nor can click them. Besides, in that block you do not have special properties such as see all elements/keys linked or uploading a document to make directly the link. In Fig. A.3, we can see a prototype with all the stuff that initially should be part of it for working properly. The header and the footer are the same that in 2.7. USE CASES 25 all other screens, is in the middle section where are included the proper tools to carry out the links between physical and virtual objects. In this section we have three differentiated parts. The left one which is just the same of the left part of the Location/Element section. It contains all the objects of the real world introduced in the application with a drop- down panel. When we click one of the objects it should display us all of the included sons on it, until we get the Elements, because clicking on one of them should put it in the relation block in the middle of the screen to create a new link with one key. On the other side, we have the drop-down panel but with the virtual content as we have in the Topic/Key section. Its behavior is the same than the previous one, clicking Keys will make that they are included in the central block for doing new relationships. The specific part of this screen is the central part. It counts with different properties related with the connections among the physical and virtual objects. In the top of the section we should have the option to see and delete all relationships of the game, and also checking if all the elements and keys included in the game are forming part of it. Also we think about some possible extensions such as download or upload made relationships from/to an exter- nal file. But the most important of the section is where the last Element and Key pressed are shown, then you should be able to add a score and submit the new relation. Remember that this is a initial design and maybe could appear new problems or features which modify it. Anyway, we will try to keep this skeleton because with the analysis in the previous sections we think that is the best for the application. Moreover, we keep in mind that the application should count with something that now we will call ”Plugging block” for those games which have single properties. With it, we will try not to disturb and make more complex the rest of the games which do not use them. It should also be applied apart from the new game function in case of we want to modify it after created.

2.7 Use cases

An use case is a description of the steps or activities which should be done for carrying out a process. In our case, we will describe the most common activities which you can do using Tagging Creaditor: Creating content for a game starting from scratch and modify the content which was already created and introduced in the editor. 26 CHAPTER 2. APPLICATION’S DESIGN

Figure 2.5: Recommended procedure for creating content with Tagging Creaditor.

Case 1. Creating Content from scratch.

The whole process can be briefly summarized in the Fig. 2.5. which we will try to explain in the following paragraphs. Step 1. New Content: The actor realizes that he/she needs new content for a game, either because someone has created a new one, or because he/she wants to introduce another content in an existing game. Step 2. Collecting info: As the name of the step says, one of the first things that we have to do is collecting the real information and thinking about the virtual information which will be related with the real objects. The actor can perform this step in different ways or even mixing them, the important point of this step is having all the media (videos, pictures), descriptions, locations,... and the virtual connections. For example, the actor can take all the information from Internet. Taking content from all over the world without moving from his/her place. On the other hand, the actor can go to the Playspace for checking and taking the information of all the elements in person. In this case, the actor can acts differently. She can decide previously which elements will form part of the new content and then he/she goes directly to take the information of the real elements with the proper stuff such as HD cameras or GPS. But if the actor has the idea of creating new content but do not know which real elements will be part of the game, he can also take with him a smart device and whenever he/she sees an interesting element can take the information. For example with a smartphone can write all the descriptions, take pictures and videos, get the coordinates... Step 3. Uploading the information from a device: The only thing that the actor needs to upload the information is a device with internet connection. It means that you can upload the content from a 2.7. USE CASES 27 smartphone, tablet, laptop... But he/she should do things in order. First of all actor has to create a new game in the application with the right properties of the destiny game. Because as we said before, some games use to have exclusive features, and depending of them he/she should collect more information in the previous step and have a special place to upload it. Once created, by using the add objects in the application, actor should be able to upload all the content got it before. In case of not introducing some mandatory information or upload wrong kind of files for the pictures, Taggling Creaditor should inform to the provider and give him the option to entering it again. Finally, user has to get the Identity of the real elements through which they will be identified by the game. It will be the translation from the real world to the virtual one. Step 4. Making the relationships: Last but not least in the application is to create the relationships among the real and the virtual level-three objects. All the actor has to do is to connect the elements with the right keys, which is supposed that it was thought before. Then the provider has to give them a score and also, if needed, inserting other properties such as kind of relation. At this point we have all the content stored in the database, and it is shown to the user via Tagging Creaditor. Step 5. Exporting the information: Finally, the content has to be exported to the database of the game. Then, provider should have or create a script for taking and modifying the information of the Tagging Creaditor database to the game database in order to fit it in the game database. For future changes on it, script should act periodically or always that one change is made in the database of the content provider.

Case 2. Editing an existing content game.

Tagging Creaditor is also used for edit properties and/or content for games which are already created. Even if the game changes its way of working, Tagging Creaditor would still be able to give it content. The use case steps for this situation are similar than the previous one but with some changes in the way to carry them out as we will see now. Step 1. Collecting new info: Probably if actor wants to modify the content or add new to the existing one, he/she will have to collect it and realizes if it is needed to add new properties to the game. If so, then in the second step besides change the information, also will have to change the properties of the game in the “Game List” page. 28 CHAPTER 2. APPLICATION’S DESIGN Step 2. Uploading new information or editing the existing one: This step is almost the same than the Step 3 of the first case. Actor can collect the new information in many ways which are described there. If the replaced information is no more useful it would be a good praxis to delete it from the content game in order to not disturb when actor tries to modify the content again. Step 3. Making the new relationships (if needed): In case of only editing some details or properties of the objects, this step is not needed because the relationships will be the same. And, although the user changes them, relationships among the third level objects (real and virtual) will remain being the same. On the other hand, if provider has added new elements or keys or also changed some key, he/she should make the new relationships in the same way that in the Step 4 of the previous case. Step 4. Exporting the information (if not transparent): As we said before, once the information is ready, it has to be moved from Tagging Creaditor database to the game database. Probably as user is modifying an existing game, the script to do it is already programmed. If so and it is executed when changes are done, provider does not have to do anything more (transparent). But, it also could be possible that actor has added a new property in the third level objects and it is needed for the game. Then the script should be modified to fit the new content on the game database. Tagging Creaditor is also ready to provide content for big games which need a huge database because the large number of objects that they have. That is because in the application, in the same game, can be working several people at the same time inserting, editing, deleting... information, although they are in totally different places in the world. Which does that a game could have content from and to any part of the world. Chapter 3

Implemented technologies

Nowadays, applications can be programmed with many different programming languages and also using different tools which provide to the program- mer facilities and helpful results. The implemented technologies in the application will also affect to the ﬁnal user. Depending on the technology used, he/she should be access to the application in a different way. There is no one best technology, all of them have advantages and disadvantages, and we will try to explain for those that we used for implementing the Tagging Creaditor, which is a web-based application.

3.1 Web-based applications

Web-based applications are those tools which users can use accessing to a web server using Internet or if the application is located in the same net, Intranet, but always by means of a browser. This kind of applications are useful in the active communications among the ﬁnal user and the information, which allows to the users access to the data in an interactive way because the page will answer at every of his/her actions. Some of the main advantages of using this kind of applications are the in- dependence with the operating system, allowing that all devices can at least access to the applications. The ease for the user of neither installing nor up- dating the applications. This applications do not take up space in the internal memory only in the cache memory stored by the browser, making the application suitable for portable devices with limited internal memory. And also, they can be acceded at the same time for many people from all around the world, so helpful for collaborative works. Other minor advantages are the possibility of customize some of the features of the GUI (color, size, disabling technologies...). Also you can use Adobe Flash Player or Java Applets for developing in a easy way the GUI. And, viruses in user’s computer do not damage the stored information.

29 30 CHAPTER 3. IMPLEMENTED TECHNOLOGIES Client-side Languages Server-Side Languages HTML PHP CSS JavaScript

Table 3.1: Classiﬁcation of programming languages depending on where are interpreted.

However, this kind of applications have also disadvantages. The main drawback is that the availability of the applications depend on third people. Firstly, in the Internet service provider (ISP) because is compulsory to have an internet connection to access to the sites. And secondly in the web servers where the applications are located, they are exposed to attacks via Internet and also physical risks such as outages or fails in the wires. Web-based applications frequently give to the ﬁnal user less functionalities than the desktop do. That happens because operating systems which are the base of the desktop apps can provide more functionalities than the browsers. Thus, due to the requirements that we need for Tagging Creaditor and the previous advantages, we decided to program it with web-based technologies. There are different languages to carry it out. In the following sections we will explain those what we use to develop Tagging Creaditor.

3.2 Web programming languages

Web programming languages have appeared because the requirements of the new platforms, to make easy the programming to the application developers. They are classiﬁed in two main blocks, client-side and server-side languages, depending on where are they interpreted, as we can see in Table 3.1.

3.2.1 Markup languages Markup Languages (MLs) were created in order to standard all the formats and structures of the information because it was turning difﬁcult to process all of them. They describe the structure of the all different types of documents through couples of tags with names, referring to the structure which is being delimited. Once speciﬁed the structure of the document, it can now be understood by some software such as browsers.

HTML HTML (HyperText Markup Language) is a ML for creating web pages. It is a standard which is used for the creation of web pages. It was developed 3.2. WEB PROGRAMMING LANGUAGES 31

Figure 3.1: Example of HTML code used in Tagging Creaditor.

Figure 3.2: Result of Fig. 3.1 HTML code. originally by Tim Berners-Lee in 1991 and is still working until now being one of the most common ML used to describe the structure of web pages. This language is written with tags, rounded by angular brackets (<,>). It can also describe in a basic way, how will be the appearance of the documents and also include a script which will be performed by the browsers. HTML consists in four main components, the elements, its attributes, data types and statement of type of document. The elements are the base of HTML, they have two features: attributes and content, and they use to have an opening and closing tag. The attributes are included inside the tag and between the tags, the content. For example, Content . We can also see another example of the Tag- ging Creaditor HTML code (header of the application) with some tags, attributes and content in Fig. 3.1 and the result in Fig. 3.2. 32 CHAPTER 3. IMPLEMENTED TECHNOLOGIES

Figure 3.3: Example of CSS and HTML code among with the result in Tagging Creaditor.

3.2.2 Cascading style sheets (CSS) The style sheets make easier how to control the presentation or style of the web pages and their later review and uploaded if necessary, splitting the information related with the presentation with the related with the structure. Moreover, style sheets allow to web developers to have a better control with the appearance in the pages, giving more possibilities than HTML presentation mechanism. CSS allows to the developer the possibility of including the presentation content in the attributes by the element Style of the HTML code or in ex- ternal ﬁles by the sentence . Some of the most common properties used to improve the presentation are for example, the color, size and source of the texts, the backgrounds, the style of the tables... Going with the previous example on, now in Fig. 3.3 we can see the same HTML with CSS code added.

3.2.3 JavaScript (JS) JavaScript is a dynamic interpreted computer and website-oriented language. It is mainly used in its client-side implementation as a part of a browser, getting improvements in the GUI and in the dynamics of the web page. Also, there is a server-side implementation for JavaScript which we do not use for the Development of Tagging Creaditor. JavaScript was developed by Bren- dan Eich in 1995. 3.2. WEB PROGRAMMING LANGUAGES 33

Figure 3.4: Example of JS, CSS and HTML code among with the result in Tagging Creaditor.

Figure 3.5: Example of JQuery code used in Tagging Creaditor.

The deﬁnition of the JavaScript functions are inserted in an HTML ﬁle as a script with the sentence . Some of the examples of the most common cases in web programming with JavaScript are the validation of web formularies or the visibility of the elements on the web page depending on the mouse clicked. We can see an 34 CHAPTER 3. IMPLEMENTED TECHNOLOGIES

Figure 3.6: Process of generation of a dynamical webpage. example of how it is introduced in the HTML code in the Fig. 3.4.

JQuery JQuery is the most used library of JavaScript, it was designed to simplify the HTML documents, handle the DOM tree and events, create animations and adding interaction with AJAX applications. It was released by John Resig in 2006. It also is used for dynamical modiﬁcations in the cascading style sheet of the document. As JavaScript is, it is supported by the most common browsers. The way of how it interacts with the page is through the $() function (JQuery() alias), which receive as a parameter a CSS expression or a HTML tag. And it returns all the elements which agree with the expression. Once we get the elements, now we can use the library functions. But normally, before using the library, the browser should be able to know if the document is ready, and then if needed, executing the sentences. In Fig. 3.5, we can see part of the JQuery code used in the development of the Tagging Creaditor application.

3.2.4 PHP PHP (PHP HyperText Preprocesor) is an interpreted programming language, whose commands are executed in the server and allow the creation of dynamic HTML documents. It was developed by Rasmus Lerdorf in 1994. Its syntax is close to other languages such as C or Java. 3.2. WEB PROGRAMMING LANGUAGES 35

Figure 3.7: Example of PHP, CSS and HTML code used in Tagging Creaditor.

Some of the advantages are that it is a open code product, everyone can access to the code, use, modify or distribute it for free, making that everyone could enhance the language. Apps made in PHP can be transported from/to different platforms without modiﬁcations, it is a high portable language. Moreover, PHP allows the connection and the access to different kind of data bases managers such as MySQL or Oracle. The PHP code can easily be inserted in an HTML document. The process of generation a dynamical web page with PHP is as follows and can be summed up in Fig. 3.6: • The browser performs the request to the appropriate web server when a ﬁnal user clicks from his/her computer in a link or load an HTML document which has PHP code. • The web server locates the documents, detects that it contain PHP code and then it starts working the language performer. • This performer executes the PHP code and generates a result, generally as a web page, which is given to the browser back for display it. If we want to insert a PHP code block in an HTML document, we can use as delimiters either the symbols or or the