The state of technology is evolving each year, computers get faster and smaller and more and more parts of society get enhanced with it. Education is one of these areas that could benefit from the progress made in technology. This paper explores the possibilities and benefits of mobile location-based learning games and tools for creating such applications. We built a web platform for creating locationbased content. The development process and design considerations to expand the functionality for creating context-based games will be documented in this paper. Finally, the results of two user tests will be presented. Both tests were conducted with primary school children to focus on use cases in the educational system.
The use of technology for educational purposes is not a new idea. However, it definitely has more to o↵er than what it is used for right now. Almost every student uses smartphones and at the age of 4 already 75% of all children carry such a high-end computer in their pockets [KIND+15]. The possibilities to use these devices in school do not end with playing casual games during a break. The field of mobile computing and especially mobile learning is more and more investigated and context-aware computing is a big opportunity to develop and interact with software. Particularly, location-based applications promise an appealing approach for creating interesting learning experiences. For example, the success of the mobile game “Pokemon Go”1 shows the fascination location-aware applications have on people, regardless of gender, age or education [Tak16]. The same enthusiasm could be used to enhance learning experiences.
This paper investigates how such a tool could look like and which requirements, use cases and limits of such applications exist. The method consists of a literature research to investigate the current state of location-based learning games (Section 2) and tools for creating such games (Section 3). The second part consists of the development of a prototype as a proof of concept and the evaluation through user tests (Section 4 and 5). Finally, we conclude our work in Section 6 and outline future work. 2
Location-Based Learning Games Location-based games require players to move through the physical world in order to achieve certain game objectives. Real objects or locations get connected with virtual information, which is accessible through the players mobile device. This kind of games is very flexible concerning the content and is predestined for educational use cases [SYOA+14]. Location-based systems do not necessarily require location-awareness. There are multiple examples of location-based learning applications which do not monitor or react to the users’ physical location due to the available hardware at that time. Nowadays, most projects work location-aware, in the sense that the system knows the current location of its user [BBS+10]. All three following examples use GPS (global positioning system) for locating the users. There are other possibilities as well, e.g., tracking the position via WiFi signal strength [CT09] or using QR code and RFID to confirm a location [TKK+09].
1http://www.pokemon.com/us/pokemon-video-games/ pokemon-go/, accessed 26.07.2016. 2.1
Puja & Parsons [PP11] explored the possibilities for using a location-based mobile game for teaching college students about business consulting. The game is played in teams. The players goal is to analyze a virtual company, as if they were business consultants and form a recommendation for the company based on their findings and conclusions. The students have to find di↵erent virtual interview partners each representing another infrastructural part of the company. These interview partners are bound to certain locations on the campus. Once the players are in a certain range to these locations the interview text appears on the device. After all locations are found and the students have obtained all accessible information, they prepare a final presentation about their findings and analysis. The user test showed some issues with the user interface e.g., diculties in finding their orientation with only a dot on an abstracted map. Another discovery was that they actually spent little time reading the interviews and documents. The players rated the progress bar as very useful, as a reference of their success. However, this resulted in consuming more attention from the participants than anticipated. 2.2
Wake & Baggetun [WB09] developed a location-based mobile learning game to teach students about local history in Bergen, Norway. The players take the role of Premier Lieutenant Bielke, who managed the defense of Bergen during the Napoleonic wars (1803-1815), and visit historic sites in the town to learn more about this historical episode. This concept follows the idea of place-based education, where problems and learning opportunities are based on the students’ own surroundings from that applying the learned information on a global perspective. The game is played in teams, which are competing for the lowest score (finishing the game as fast with as few hints provided by the system as possible). A user test with three teams of three people was conducted, each team sharing one GPScapable mobile device. The participants reported a clear understanding of the game and knew how to use the system. During the questionnaire, the authors found that the distance meter was a crucial tool for the success of the game, the map and hints were rated lower. 2.3
Savannah [FJS+04] is a game where children (aged 11 to 12) can take the role of a lion in the wild. The game is a rather complex role-playing simulation, where the players can move freely in a predefined area (100m ⇥ 50m) and decide their own actions. Basically, the game is about surviving as a lion, which includes hunting, drinking, staying away from trouble, managing their energy, etc. Each player carries a PDA with GPS functionality and headphones. The devices transform the playing field into the savanna by showing images and playing sounds according to the players’ position. The device also receives and displays messages like “you are too hot”, “you are hungry” or “you are dead - return to the Den”. These messages let the players know about their state in the game. 2.4
Looking at these examples, some insights can be obtained about the current state of location-based learning games. The use cases are very broad, the examples reach from games for children to college education and the fields of interests were historical, biological and economical. Thus, location-based learning games are unbiased regarding target audience and content.
The structure of these games often share certain similarities, like the process of going to a location, retrieving information about the next location once the players’ presence is confirmed and so on. Overall, all user tests confirm a positive e↵ect on the motivation of the players and their learning experience. 3
Requirements Many location-based learning applications follow the same structure. The user has to go to a certain place to acquire some new information, based on that they have to find the next location. Having such a repetitive pattern makes it easy to create tools to manage the content of such a learning experience or even create new ones without having programming skills. This kind of application could, for example, be used by teachers to create interactive, location-based content for their classes, benefiting from all the previous mentioned advantages, without the need for expensive projects to create individual location-based learning games for only one use case [SYOA+14]. Keeping such content up-to-date is another advantage of having an underlying - easy to use - system [WHC+06]. Of course, the individuality of game features developed with such a tool will not be guaranteed and complex applications like “Savanna” [FJS+04] can not be realized with such a generic structure.
Weal et al. [WHC+06] worked with teachers and curators and defined requirements for authoring tools of location-based content as follows: • The process has to fit existing practices, must be fast, simple and achievable in-between daily chores and when new ideas come to mind. • In-situ authoring should be provided, esp., if the mobile experience created is essentially connected to the real environment. The content providers will benefit from the possibility of creating the content exactly where it will be consumed. • It should always be possible to go back and refine the already created content. This kind of work does not have to be in-situ because it will probably be more time consuming and reflective than a spontaneous note. This might even profit from having to use another working environment like a desktop computer to get another view. 3.1
In-situ authoring allows the creation of content directly in the situation when being on sight on a mobile device. The other approach would be to require some kind of static desktop application. Weal at al. [WHC+06] faced the challenge of needing a system to record audio files for a location-based tour through a historic place and the guides were not able to authentically narrate their stories away from the location. As a solution, they build a mobile application which allows the guides to record their snippets for their tour directly on their PDAs, neglecting audio quality for a more authentic experience [WHC+06]. 3.2
In the examined prototypes, the design of the authoring tools and the normal consumer functionality is approached in one out of two ways. Either, the designers developed two completely separated applications, one for consuming and one for creating location-based content, or they followed the approach of being able to create and change the minimum of each location, but big changes need to happen on a di↵erent environment (e.g., on a desktop computer).
An example for the first solution is the game “Premierløytnant Bielke” [WB09]. The authors developed a web interface to easily change the content of each location, allowing non-technical users to maintain and update the content, while the game was implemented as a native mobile application.
The second approach is implemented by Weal et al. [WHC+06]. It is possible to record audio files on the field but heavier changes still need the desktop environment. Another example is the TOTEM application suite [JWBO13]. Jurgelionis et al. created two applications: TOTEM.Designer (desktop application to create data templates) and TOTEM.Scout (mobile application for filling the templates with data in the field).
A third approach would be to enable the mobile application to do all the configuration, creation and maintenance necessary for the tool to work. However, none of the found projects described such a possibility. The described project in this paper follows this approach. 4
Development Mobilot2 is a web platform for creating location-based content. Users can create “Mobiduls”, modules where they can mark arbitrary locations (“stations”) on a map, add media or text and publish such collections. The software has some additional functionality, like collaborative content editing, which supports use cases where multiple users can contribute to a collection of locations, e.g., a collection of all ATMs in a town or a city guide. The application is solely web based, even so the design is highly responsive and optimized for mobile usage. Each feature can easily be accessed on mobile devices. Therefore, in-situ authoring and creation is ensured.
The architecture of Mobilot can be seen in Figure 1. The back-end (server) is implemented with the PHP MVC framework Laravel, version 4.2, with a MYSQL database. The back-end architecture (server) is mainly a typical REST API with CRUD (Create, Read, Update, Delete) functionality. This kind of architecture is advantageous for creating multiple client applications for di↵erent scenarios or devices because the back-end can stay the same.
The front-end (client) is built with the JavaScript framework Angular.js 1.4 . This framework is designed to build big applications as single page applications (SPA). SPAs technically consist of one page even so it 2The code base is open source and available at https:// github.com/fhstp-mfg/mobilot. does not seem like it. This has some benefits, like an overall faster experience of the site. Instead of heavy page loads, the applications have to request data only when needed, saving a lot of overhead in HTTP requests. On the downside, there can be a possible slow initial loading of the page when the user visits the page for the first time because the complete application gets loaded at once.
The map feature of Mobilot is realized with the Google Maps API inside the front-end application. 4.2
The existing functionality of Mobilot lets users already easily create location-based content. However, the content was rather static and non-interactive itself. To use the platform in a learning context, we needed some new features to encourage learners to get active. We came up with the idea of extending the existing features to make it possible to easily and fast create scavenger hunt-like learning games. The basic functionality was already in place, the game itself would be a Mobidul created by some kind of game master, like a teacher, and the stations would be the di↵erent points of the scavenger hunt. We needed some way to give stations di↵erent kind of states (like ‘hidden’, ‘open’ or ‘completed’) and only display those who have already been unlocked.
Another feature, we wanted to implement, was a set of interactive components to enable users to configure the scavenger hunt more freely and create their own rules on how the unlocking of stations would work. These components should be easily configured to the need of the situations.
It was very important to focus on maintaining the mobile and in-situ authoring possibilities of a Mobidul. Therefore, we were challenged not only to create such highly configurable scavenger hunts but also ensuring the mobile use of the editor.
Additionally, we wanted to transform the existing web application into a hybrid version. On the one hand, it will allow us to use native functionality of mobile devices, which could not be used with a webbased application, like access to the Bluetooth chip. On the other hand, we can deploy the application on PlayStore by Google and AppStore by Apple, to be discoverable on those platforms. 4.3
The first step to create a scavenger hunt-like experience is to di↵erentiate between various states of a station (see Figure 2). Instead of showing the same information regardless of the context of the user, we introduced four di↵erent kinds of conditions with their own rules each station could be in.
Each station starts in hidden state. Hidden stations are not visible on the map or in any list. If players try to access it directly they will be redirected to the currently active station. Once the previous station is completed the station will be activated. Now, the station is visible on the map. In this state players can get challenged to do something in order to proceed with the game, e.g. finding the station. Afterwards, the station can be opened. Technically, the open state is equal to the previous one. The usage of this state is optional but allows new possibilities for game elements. After this, the player will continue with the next station. Finally, a finished station will stay in the completed state. This allows displaying information that should be accessible after playing the game. 4.4
The scavenger hunt Mobidules o↵er several interaction elements for configuring a station. Each of these elements o↵ers custom configuration capabilities (e.g., the label on a button or the range of a GPS tracking component) and a call to action in case it gets triggered.
• HTML Content: is a very basic non-interactive component for creating simple text and images with a WYSIWYG (“What you see is what you get”) editor. • Action Button: is a simple button to trigger an action if clicked. The label and action are configurable. • Code Input Field: is an input field with a submit button. Players will have to enter the correct code in order to trigger the success action. An error action is also implemented. • GPS Detector: If a station is configured with a GPS detector it will check the players’ position every five seconds. If the user is within a configurable range an action will be triggered. As a fallback, in case of an inaccurate GPS signal, there will be a code input component to trigger the action anyway. • Countdown: Opening a station with a countdown component will start a timer, that will trigger an action after a specified time. 4.4.1
Actions To create interactive learning experiences, it is necessary to configure custom responses to user inputs. While some components allow the declaration of two actions, one for success, one for failure, most work with only one of them. The following actions can be triggered: • Open this station: will set the status of the currently active station to “open”. • Complete this station: will set the currently active station as completed and the next station as activated. This action can also be used in activated state, which will result in skipping the open state. • Say some text: will open a dialog window with a customizable text. Can be used for hints or custom error messages. • Go to current station: will set the progress to the currently active station. This is useful for completed stations to allow players to quickly navigate back to the currently active station. 4.5
Editor The design consideration behind the editor was to make it as easy as possible even on mobile devices.
To get to the station editor, one has to either create a new station in the menu or click the edit button in the header at the desired station (see Figure 3). It is required to have editing permits to do so.
The editor is shown in Figure 4. On top, there are four tabs with di↵erent options: • Base: allows changing the name of the station as well as its content/configuration. • Place: shows a map for changing the location of the station. • Categories: lets the owner put the station into one or more categories. • Options: allows some additional configuration of the station as well as the option to delete it.
For creating a scavenger hunt, the first tab (Base) is primarily important because the game logic is managed here. Each state of the station is separated into its own tab. The editor can change between these by touching one of the state names (‘activated’, ‘open’ and ‘completed’).
Underneath the state tabs, the user can add unlimited elements to the configuration by clicking on the desired component, which will add the element to the content area underneath. If an already existing element in the content area is selected it will be displayed with a blue background. The new component is going to be placed directly behind of it.
Each component has an information and delete button. By clicking on the “toolbox” further configuration is possible.
There can only be one opened element to save screen space, which is important to think about when designing for mobile devices. If the user opens a new element the currently selected one will collapse into the preview mode. The order of the elements is changeable with a drag‘n’drop gesture. This is consistently used throughout the application to change the order of list items (also used for changing the station order or menu items).
To save the changes, the user has to click on the right button in the header. This will redirect him or her to the station view. The changes can also be discarded by clicking on the cancel button in the left of the save option. 4.5.1
Developer Tools To make it easier for Mobidul creators to test their content, the application o↵ers developer tools to change their current progress data. These tools can be seen on Figure 3. They consist of two parts. One - the connected dots underneath the station name - shows which station is currently viewed (the outline and font color gets green). It also allows changing stations quickly by clicking one of the other dots. The other feature is right underneath. User can change the state of the station by selecting one of the three tabs. The content will change immediately according to the selection. 5
Evaluation The goal of the evaluation phase was to test the new game components of the web application. The primary focus was the user experience of the consuming position, not the handling of the content authoring and configuration.
For this evaluation, two di↵erent tests were conducted. Both of them were qualitative evaluations with observation followed by group interviews. The target audience of these tests were elementary school children from “Volksschule Tullnerbach” in Tullnerbach, Austria.
Overall, we had 90 participants aged from 6 to 10 (see Table 1 for the distribution of the participants). All participants claimed to have experience in working with mobile devices. Some of the older ones even own smartphones themselves. The tests took place on two days during a project week at the school and were performed on the school grounds. They were instructed and supervised by the project leaders and developers of the software. The test content, two separated games with an objective of practicing reading while doing physical activities, was designed by a related teacher. The distinction between the two test modules was based on the age of the participants. Each test took about one hour including instructions at the beginning and a quick group interview at the end.
As test devices we provided iPhone 5, 6 and 6+ as well as iPad 2 and iPad mini. Around the school, there were five stations at wellknown places like the car park or the tennis court. The participants read instructions on their devices to go to a specific station and perform a task. These tasks were di↵erent for each station, some were achievable with just using the device, others required extra instruction and validation from a station supervisor (see Figure 5). All tasks ended with receiving a keyword, which had to be entered to complete the station and activate the next one.
This test was performed with three classes. Two of the three classes were regular ones with children aged 6 to 8 (with 23 and 18 participants) and one mixed with an age range from 6 to 10 (with 9 participants). Each class got separated into three subgroups and each one of these got three test devices. This meant the children had to share one device with one or two peers. The groups were accompanied by one of the supervisors, in case questions or problems occurred.
The participants were very motivated and rushed from one station to another. However, it was noticeable that the older ones could not immerse as much as their younger peers. Therefore, the mood of the mixed class was a little less enthusiastic. The game was designed for younger children. Therefore, an explanation for this could be that the tasks were too easy and not challenging.
The children were obviously excited about the evaluation devices. They were aware of the cost of the phones and impressed by the responsibility of carrying them. They did not have any problems handling the application, which matches their statement to be experienced in working with smartphones.
Beforehand, it was expected that they would read the instruction in these constellations, but it turned out that one person ended up reading aloud for the whole group. This kid was most times the most confident reader of the class, which made the ambition of the application a bit pointless, because the idea was to practice reading. It even hindered insecure students wanting to hold the device, so they would avoid having to read.
The game design was well received by the participants. Especially, the athletic tasks were highly rated and better memorized than the others during the final interview. The challenge to match numbers with letters was probably too abstract for the target group. From observations it also showed that it was the least engaging station of the rally, mostly leading to having one or two participants solving the task for the whole group. A preference regarding self-instructed stations compared to having a supervisor giving additional information or validation was not stated. 5.2
Reading Hike (Age 9 to 10) The older participants were tested with another module adapted to their reading abilities. Each one of the two classes got divided into two groups and the children had to share devices in pairs. Each station reveals a new chapter of a continuous story and will give a hint on where to find the next station. Additionally, the current distance to the station is displayed on screen, giving feedback if the moving direction is correct. The application will automatically show the next chapter of the story once the distance was less than 10m.
The narrative was fitted for the audience. It was the story of a young girl looking for her lost domestic pig called Norbert. While searching him, she meets several other animals and people who help finding her friend. Each one of these encounters is represented by a station and the children walk the same way as the girl in the story.
The game consists of ten stations, the walking distance is about 3km and the children needed about one hour to complete it. As a fallback, in case the GPS did not work, there were physical signs attached at each station, providing an unlock code (see Figure 6).
Unlike the reading rally, this game can be played without depending on anything but the smartphone. It should be possible for the participants to come back with their parents and repeat the scavenger hunt with their own devices. Therefore, the interface of the station view is extremely important to be easily understandable without any outside help.
This game got tested with a total of 40 children aged 9 to 10.
During the group interview the students stated that the story was appealing. Some children proposed included more media genres like videos to enhance the experience.
The devices used for this tests were iPad 2, iPad mini and iPhone 6+. The reason for choosing these devices was the assumption that it would be easier for children to read on a larger screen. This decision proved to be false, not only did the iPad su↵er the most technical related issues with GPS, but it was also too big and heavy for this kind of usage and target audience.
The main game play element was finding the next station. The most used tool to achieve this objective was the distance meter (see Figure 7). Another feature that would have been useful is the map view, but the participants did not use it at all, which could be the case, because at the initial instructions it was not shown or explained. Wake et al. [WB09] described a similar observation where the participants did not use the map but instead relied on the distance meter very heavily. They try to explain it with the participants - in this case adults - knowing the area very well (a) (b) (c) and expecting to see di↵erent scenarios with younger students. The findings could contradict this thesis, because the participants are within the suggested age range and did not know the area too well.
The participants permanently overrated the accuracy of the distance meter. They tried to find the right direction by walking a few steps and looking at the new distance as feedback. While this seems like a valid approach on solving these problems it implies a few other problems. First of all, the GPS signal is not completely reliable. The game component responsible for calculating the distance was configured to accept an accuracy aviation up to 20m before falling back into an alternative mode. The current accuracy was even displayed next to the distance. This e↵ect is also described by Facer et al. [FJS+04] who observed children attributing substantially more intelligence to the devices and technologies than there were in reality [FJS+04].
During the test, a severe bug was noticed the first time. The issue, that occurred when the GPS module of the device returned an error, led to the situation that neither the current position was checked nor the fallback alternative was displayed. To solve this problem, the user had to refresh the page, which triggers a new request for the GPS position, normally resolving the issue.
Another problem was the selection of the fallback codes, which were three random letters. The auto correct feature of the devices made it hard to input these codes and automatically replaced the text with a correction. Words that would pass the auto correct inspection would have been a better choice.
All participants were satisfied with the application. The described problems did not upset them that much. They stated that they would be interested in similar games and could imagine using such an application in their spare time and with their families. 5.3
Summary Overall, the evaluations, of a self-explanatory Mobidul (Reading Hike) as well as one with additional instructors (Reading Rally), show a successful involvement of the participants in the Mobiduls. Even so the game objectives, like solving a task or progressing in the story, were quite simple, they allowed the children to immerse into the experience. The technical side of the application was stable. However, the GPS availability of some devices had a negative impact on the users’ experience. Due to its simplicity, the user interface was easy to use and did not need a lot of instruction. 6
Conclusion Mobilot shows that it is possible to develop a tool that allows an easy and in-situ creation of location-based learning games. Many games fitting this category show a very similar structure that can be streamlined into a generic system, while maintaining its attractiveness to players.
This paper described the development of a tool to easily create location-based games as well as the outcome of two user tests. The user tests brought good results for the games and the participants enjoyed the game. Still, there is room for improvement. A next step will be the user interface evaluation of the station editor with teachers as the target audience.
The future possibilities of Mobilot seem endless. One of the next extensions will be the implementation of further context recognition like the distance to object (measured with Bluetooth signal) and social interaction. With these new features the tool belt for creating interesting learning experiences will allow the creation of wide-ranging game mechanism. Another idea is to open up the concept of the linear game structure to allow an autonomous exploration of the individual stations or the creation of conditional paths during one game session.
As for further research, it would be interesting to evaluate more mobile learning games in an educational context. Teachers should be encouraged to use technology in their classes and therefore more tools are required to support them.
Acknowledgements This work was supported by the project seekoi (no. 1154) funded by the Internet Foundation Austria (IPA) as well as the Austrian Ministry for Transport, Innovation and Technology (BMVIT) under the Austrian Security Research Programme KIRAS via the project Courageous Community (no. 850196). [BBS+10] [CT09] [FJS+04]
Chih-Ming Chen and Yen-Nung Tsai. Interactive location-based game for supporting e↵ective english learning. In Proc. of ESIAT, volume 3, pages 523–526.
IEEE, 2009.