SEBASTIAN BORGGREWE - 513015 - ME@SEBASTIANBORGGREWE.
QR CODES AS A COMPLEMENTING GLOBAL POSITIONING METHOD FOR LOCATION AWARE IPHONE APPS
FACHHOCHSCHULE DÜSSELDORF UNIVERSITY OF APPLIED SCIENCE DÜSSELDORF FACHBEREICH MEDIEN DEPARTMENT OF MEDIA
DEGREE PROGRAM: MEDIAINFORMATICS FIRST EXAMINER: PROF. DR.-ING. MARKUS DAHM MSC SECOND EXAMINER: PROF. DR. CHRISTOPH THIEL
I . AFFI DATI V
Ich, Sebastian Borggrewe, geb. 18.06.1987, versichere, die Bachelorarbeit selbständig und lediglich unter Benutzung der angegebenen Quellen und Hilfsmittel verfasst zu haben. Ich erkläre weiterhin, dass die vorliegende Arbeit noch nicht im Rahmen eines anderen Prüfungsverfahrens eingereicht wurde.
Düsseldorf, den 01.07.2010
The objective of this Bachelor Thesis was to evaluate the use of QR Codes as a complementing global positioning method for location aware iPhone Apps. It shows the surplus benefit of using QR Codes as a fallback method, in case GPS is not able to precisely identify the location of the handset. In order to confirm this thesis, a scenario of a guided tour was created and implemented: A web front end for creating a tour and an iPhone App for taking the tour. In addition this scenario was analysed regarding its usability. In this study, the QR Code was identified to be suited for the purpose of being used as a complementing method for location awareness and the use-case implemented proved its suitability for daily use.
TABL E OF CONTENTS
I. ! AFFIDATIV II. ! ABSTRACT 1. ! INTRODUCTION 2. ! BASIC TECHNOLOGIES 2.1 ! GPS 2.2 ! QR CODES 2.3 ! IPHONE 3. ! SCENARIO 4. ! ANALYSIS 4.1 ! CRITERIA 4.2 ! FITNESS FOR PURPOSE OF THE QR CODE 4.3 ! REQUIREMENTS REGARDING THE IMPLEMENTATION 5. ! IMPLEMENTATION 5.1 ! THE TOUR CREATOR WEB FRONT END 5.1.1 ! NAVIGATION 5.1.2 ! CREATING A TOUR 5.1.3 ! THE TOUR DEPLOYMENT PDF 5.1.4 ! U SER HELP 5.2 ! THE TOUR TAKER IPHONE APP “MYTOUR” 5.2.1 ! START SCREEN 5.2.2 ! TOUR K ICKOFF 5.2.3 ! TAKING A TOUR 2! 3! 6! 8! 8! 9! 9! 11 ! 13 ! 13 ! 14 ! 14 ! 17 ! 17 ! 18 ! 18 ! 20 ! 21 ! 22 ! 23 ! 23 ! 24 !
5.2.4 ! THE CONTEXTUAL HELP 5.3 ! EVALUATION 6. ! CONCLUSION 7. ! FUTURE OUTLOOK LITERATURE INDEX APPENDIX 27 ! 27 ! 28 ! 29 ! 30 ! 31 !
1 . I NTRODU C TI ON
Location Based Services are currently a feature to be found in various mobile applications. They help to supply information in a location-dependent context and make this information therefore more useful for the user because it is contextual. Enhanced location awareness of mobile application is according the recent Gartner Study “Ten Mobile Technologies to Watch in 2010 and 2011” one of the mobile trends at the moment. This thesis deals with one special issue that comes along with GPS in mobile devices. Although GPS is in theory very precise, various factors can influence this precision. For example, certain weather situations, restricted availability of satellites, high buildings, and particularly inside positions can influence accuracy. Also, due to the lack of high performance GPS antennas in handsets, GPS signals are not strongly available the way they should be and often they lack quality. While assisted GPS technologies are able to improve this situation for urban areas (for instance by supplying the almanac over GSM for quicker satellite recognition), there is still no convenient and inexpensive way to get an exact position in areas where GPS signals are weak or unavailable. The question to be asked: How can location awareness be established in those areas? According to Gartner “GPS will be the primary, but not the only, means of establishing handset location [...]”1 in the future. Still there is no solution that satisfies my requirements for a cost-efficient, convenient and flexible solution. This Bachelor Thesis deals with the problem of restricted location awareness by virtue of limited GPS availability among mobile devices. By introducing a complimenting global positioning method, namely the QR code, the lack of precise location-dependent information will be solved.
Gartner, Ten Mobile Technologies to Watch in 2010 and 2011, p.4, l.11-12
1 Introduction The outcome of the thesis shall be a universal approach for exactly identifying a mobiles’
location and product type thus showing the capabilities of improving location awareness with the help of a universal complementing method.
2 Basic Technologies
2 . BASI C TEC HNOLOGI ES
2.1 GP S
The (NAVSTAR) Global Positioning System was originally developed by the U.S. Department of Defense (DoD) for military purpose only. It’s primary objective is the accurate determination of position, velocity and time on a continuous basis. Owing to the request of the U.S. Congress, the DoD started to promote its civilian use as well which later lead to a wide spread application in civilian technologies such as GPS navigation devices. In order to provide a GPS receiver with the necessary information for location calculations, each satellite continuously sends the following data: • • • Time of the message transmission The ephemeris (precise orbital information) The almanac (System health and rough orbits of all GPS satellites)
The data received enables the GPS receiver to determine the time the message was sent in order to calculate the pseudo range with the communicating satellites. This computed data along with the satellite’s location is used to calculate latitude, longitude and altitude by means of trilateration. Since a clock error results in a large positional error, at least four if not more satellites are necessary to accurately calculate the current position including four unknown latitudes, longitudes, altitudes and clock errors.
2 Basic Technologies
2.2 QR C ODE S
The QR Code 2 Standard is a development of the DENSO WAVE INCORPORATE and was approved as an AIM International (Automatic Identification Manufacturers International) standard in October 1997. QR Codes are basically two-dimensional
Figure 1: QR Code Caption Source: ISO/IEC 18004
advancements of the barcode. They have a small printout size, are able to store more and various types of information (alphanumeric, binary and Kanji compared), have error correction capability, are omni-directional readable due to position detection patterns and are capable of dividing information in multiple codes. Conceptually the QR Code works like every other barcode. Information is stored in a machinereadable format and can therefore be processed by scanning and interpretation. The major difference is that information can be stored in two dimensions with contrast to only one dimension in the barcode approach.
2.3 I P HONE
The “original” iPhone, Apple’s first mobile phone, was introduced on June 29, 2007 in the United States and over 50 million units have been sold to date. That makes the iPhone one of the most popular smart phones worldwide. Due to its technical specification, the iPhone is perfectly suited for location aware mobile applications. The current version of the iPhone (3GS) is equipped with assisted GPS, a digital compass, wi-fi and cellular capabilities for location sensing purposes.
QR Code is registered trademark of DENSO WAVE INCORPORATE
2 Basic Technologies In addition, Apple provides the “iPhone Human Interface Guidelines”; a guide on how to implement usable applications. Apple itself already defines basic navigation and user interaction concepts.
This frees the developer partly to come up with his/her own concept of offering features to the user and provides a concept for a homogenate user interface.
3 . SC ENARI O
In order to show the capability of my approach using QR Codes as the complementing technology to improve location awareness, I need a suitable scenario. I chose a simple yet universal scenario that could easily be altered to fit a more specific purpose: A guided tour. A guided tour consists of multiple stops that can be located either inside or outside and is perfectly suited for the underlying concept. The one who creates the tour, the “tour creator”, should be able to name the tour and provide additional information. Furthermore he/she defines the location of the stops and provides additional information for each. The tour creator is provided with a document holding a QR Code for beginning the tour and a QR Code for every single stop. This ensures location awareness regardless GPS availability. The one who takes the tour named “tour taker” further in the course of this thesis can now visit the stops and receive the information belonging to individual stops. A map view helps the tour taker get to the different stops by showing the current position and the stops available. Whenever GPS is available, the tour taker will be notified when he/she reaches a stop and the information will automatically be shown. In case of weak or non-existent GPS signal, the user will be allowed to retrieve the information himself /herself using a QR Code that has been displayed in the target area by the tour creator. Within this scenario there is a distinction between two tour types: “guided tour” and “scavenger hunt”. Both of them are based on the basic scenario explained above. The guided tour consists of stops in an unspecific order. All the unordered stops taken together are called “guided tour” in the following. Whenever the application senses the current location in range of one of the stops (with the help of GPS or the QR Codes), it shows additional information to the specific destination in range. In the case of the “guided tour”, all the stops are shown on the map from the beginning and can be visited without following a specific order.
In contrast, there is also a “scavenger hunt” feature. This feature shows the next stop on the tour taker’s tour and forces him/her to therefore visit the tour stops in the order designated by the tour creator. Yet, the basic principle is the same as with the guided tour.
4 . ANALY SI S
4.1 C RI TE RI A
A complementing method for establishing location awareness in areas where GPS is either poorly available or unavailable has to fulfil certain criteria in order to be suited for universal use. By identifying these criteria and applying them, I can prove the QR Code to be a wellsuited solution for the underlying problem. I identified the following three criteria that should be met; cost-efficiency, convenience and flexibility. Cost-efficiency The chosen technology should be potentially available to everyone, regardless of financial possibilities, in order to make it useable for a large number of users. If a technology is too expensive, this isn’t possible. Convenience The technology should not hinder the consumer to use it by taking too much time and effort, or by being intuitively too hard to understand. In addition, there should be a way to provide the complementing service with minimum complexity. Flexibility The method used needs to be applicable in different scenarios without experiencing disadvantages. Moreover, I considered EN ISO 9241-110 to evaluate the way the technology has to be offered to the user (cf. 4.3). The EN ISO 9241-110 is an international standard to evaluate human computer interaction by supplying seven dialog principles. These are; suitability for the task, suitability for learning, suitability for individualisation, conformity with user expectations, self-descriptiveness, controllability and error tolerance.
4.2 FI TNE SS FOR P U RP OSE OF THE QR C ODE
I apply the criteria mentioned above (cf. 4.1) to prove that the QR Code is a suitable technology for my approach. It is cost-efficient, because the QR Code standard is free for all to use and requires only a piece of paper to be printed on. Generation of QR Codes can be done by several services including the Google Chart API which is available for free. It is convenient since individual QR Codes can be automatically generated. They conceptually work like barcodes which are well-known to most users. In addition, QR Codes are widely spread in mobile applications therefore most mobile users know how to implement them. I could not completely verify the criterion flexibility because I could only go through one scenario in detail. During this scenario, the QR Code performed well (cf. 3). A QR Code can essentially store every kind of information and therefore be adapted to suit specific needs. Still there is a chance that there is one scenario it is not suited for.
4.3 RE QU I RE M E NTS RE GA RDI NG THE I M P LE M E NTA TI ON
As stated in 4.1, there is a need to analyse the way the user should deal with the QR Codes. I have specified basic guidelines for the tour creator and the tour taker application according to the seven dialog principles defined in EN ISO 4291-110. Some of the guidelines concern only the tour taker application because the user does not interact with QR Codes directly in the tour creator application itself. Suitability for the task The QR Code is a medium that can easily provide information by means of scanning, as well as it can be automatically generated. The required user interaction is therefore convenient and consumes little time. While creating the tour there should be no need for the user to care about details concerning the QR Codes. Instead, the QR Codes will be automatically generated and prepared for the user to print out.
When implementing the process of scanning, there should be just one click necessary to get the information encoded into the QR code. Keeping in mind the user receives only crucial information for this interaction, the effort is minimal and is therefore suitable for the task. Conformity with user expectations Since the QR Code works like a barcode and also looks like one in a wider sense, the user can imagine the way it works and the way the information is extracted. Still, the tour creator application is less likely to conform to user expectations. The reason for this is that most of the users have not deployed a QR Code/barcode yet. In order to compensate the lack of experience, there should be extensive resources for user help (cf. Suitability for learning). In contrast, barcode scanning is a model well known due to everyday use. For example, shops use the barcode system. QR scanning works the exact same way. The QR Code scanner implemented in my App will use the camera of the handset. There are already a large number of Apps for extracting information from barcodes the same way my QR Code capture is designed. This procedure will already be familiar to the user. Self-descriptiveness The user interface for the tour taker client will present a camera view every time a QR Code needs to be scanned. They will be informed about this procedure at the first launch of the App, however, there should be a help button in the camera view to allow him/her to view the instructions again. The way the user can use the QR Codes in the tour creator applications will be self-descriptive because he/she will not have to use them until he/she is told to do so. There will be a dialog that tells the user exactly how to proceed with the QR Codes. Suitability for learning The general concept of using the QR Codes as a complementing method will be described immediately to the user. In the tour creator application, a help dialogue has to be placed at a prominent spot in order to be easily accessed by the user; therefore the user has the chance
4 Analysis to be offered help whenever needed. However, help dialogue should not bother the user in case he/she already knows what to do. The same principle applies for the tour taker
application. The concept will be shown at first launch for giving a general overview. From then on, the help dialogue should be accessed upon request. Moreover, the tour taker application help should be a contextual help for the whole application is more complex and will offer more functionality, than the tour creator application. It should be placed at the exact spot on every screen. Suitability for individualisation This criterion of the EN ISO 4291-110 can be neglected in this case. The reason is because the approach of using the QR Codes in both applications should be implemented straight forward and without any possible variations. The dialogue should only show what the user needs in order to interact with them. Naturally, there should always be a hint/help how to use them. Individualisation in general has to be handled with care. Too many individual possibilities might confuse the user, so the two applications must have fixed ways to handle the QR Code. Controllability During the process of QR Code scanning, the user has to have the possibility of cancelling the scanning dialog in order to return to the previous screen. There needs to be feedback after successful scanning and the tour taker application retrieving the information for a QR Code. Error tolerance First of all, the QR Code standard considers several error correction measures which try to compensate errors that could occur while information decoding. This is why the user will seldom receive an error. Secondly, error regeneration just needs a repetition of the scanning process so all the user has to do is scan the QR Code again. This is a trivial process and there is no need to introduce new methods for regenerating from errors. In case of an error the App will notify the user to scan the QR Code again.
5 . I MPLEMENTATI ON
The Scenario described above (cf. 3) is divided according to two aspects; tour creation and tour taking. This is why there are two different applications. First, there is the application for the tour creator that is implemented in the form of a web front end. The reason I chose a web front end for creating the tours is it can be easily accessed by anyone who has Internet connectivity. Secondly, there is the application for the tour taker, which is an iPhone App. The iPhone, as a representative choice for a mobile device, is used because of the specifications of this handset (cf. 2.3). The advantage of dividing the two aspects of the tour into separate applications is that the tour taker is not bothered by the details of tour creation. This makes the tour taker application more easy to use. The two applications are connected via a XML interface which allows information exchange with the database of the web front end to the database of the iPhone App.
Figure 2: Data exchange between web front end and iPhone App
5.1 THE TOU R C RE A TOR WE B FRONT E ND
5 Implementation the web front end, it is optically divided into two major columns. The left is reserved for website navigation and for entering necessary information about the tour and stops. The right is for marking and showing the stops on the map3 .
Figure 3: Web front end
5.1.1 NAVIG ATIO N The navigation offers only the options that are absolutely needed for creating a tour and
Figure 4: Navigation
receiving help. 4 By clicking the navigation point “NEW TOUR”, all the currently entered information is discarded. By selecting “HOW TO?” the user reaches the user help (cf. 5.1.4). 5.1.2 CR EATING A TO UR Tour creation is done first of all by filling in the information for the tour (cf. Figure 5) and choosing its type (i.e. guided tour or scavenger hunt). Title, description and choice of tour type is therefore mandatory information and the URL can optionally be used to provide further information regarding the tour. By clicking the “+” button, the user is able to add new stops to the tour.
Figure 5: Editing tour information
The map used is provided by Google Maps In Germany, the imprint is required by law.
5 Implementation Whenever a stop is added, it appears right below the tour information (cf. Figure 1). A tour stop can also be supplied with the same information as the tour itself, but in addition needs the mandatory information “Place” which marks the stop on the map. The controls right next to the text field “Stop Title” are used (from left to right) to delete a stop, end editing stop details and change the stops’ order via drag and drop in the list of stops. By clicking the flag button the user is asked to mark the location of the stop on the map (cf. Figure 7). This location, represented by a marker with the stop order in the tour (cf. Figure 8), can be altered at any time given the tour creator miss-entered the information. He/she will only need to press the flag button again or move the marker for the specific spot around the map using the in-built drag and drop function. The whole process of stop creation can be repeated as many times as necessary. There is no constraint of the number of stops a tour can consist of.
Figure 8: Location has been marked on the map Figure 7: Marking the location on the map Figure 6: Editing stop information
In order to end tour editing and save the tour, the tour creator needs to press the save button (cf. Figure 5). The tour is saved and the tour creator is provided with additional instructions on deploying his/her tour (cf. Figure 9). This creates a link to a PDF document which contains the QR Codes for the tour kickoff and the stops (cf. 5.1.3). Also, a link is created that can be saved by the tour creator for the purpose of modifying the tour later (if he/she desires).
Figure 9: Save the tour
In addition this is the first time the user has to interact with the QR Codes as the medium to ensure general location awareness. The QR code is generated automatically. This is the general essence of the stipulation required by the guidelines defined in 4.3 and they are therefore fulfilled. 5.1.3 THE TO UR DEPL O Y MENT PDF The tour deployment PDF consists of three kinds of documents. First, a description of what to do with the PDF (cf. Figure 10). Secondly, a page with the QR Code to kick off the tour and lastly a page with a QR Code for every stop that is part of the tour.
Figure 10: Tour deployment instructions
21 The kickoff QR Code should be placed at the starting point of the tour. It will be used by the iPhone App to identify the tour and retrieve all stops connected to it. The tour taker simply needs to snap it when he is asked to so by the iPhone App. In addition, the kickoff page holds general information regarding the tour and the direction for downloading the iPhone app from the App Store.
Figure 11: Kickoff QR Code
The other QR Codes (cf. Figure 12) are assigned to the different stops defined by the tour creator. They should be visibly placed somewhere in the target area. If GPS is not available in the target area for whatever reason, the tour taker can snap the QR Code and receive the additional information supplied by the tour creator for the particular stop. This PDF is made available to the tour creator after he/she saves the tour.
Figure 12: Example for a tour stop QR Code
5.1.4 US ER HEL P The help page can be accessed when the user selects “HOW TO?” in the navigation (cf. Figure 4). It offers a basic overview regarding the controls (Quick controls overview) in the web front end. In addition, there is a short explanation of how tour creation works and what the different aspects of the creation process are.
Figure 13: User Help
5.2 THE TOU R TA KE R I P HONE A P P “M YTOU R”
As described in 2.3, I choose the iPhone as a platform for implementing the tour taker client “myTour” and showing a use-case where the QR Code is inserted as a complementing method ensuring location awareness. Its function is the provision of an adequate platform where the user can manage and take his/her tours. Generally speaking, the result is the creation of a platform which offers, complying with destination data, information in a location-dependent context by the means of a tour with multiple stops. The whole look-and-feel is based on the Apple “iPhone Human Interface Guidelines” and the guidelines defined in 4.3, which guarantees a usable implementation of the App. It is furthermore equipped with a context-based help that can be found at the bottom right of every single screen. It gives an overview regarding the functionality available in the specific screen context.
5 Implementation 5.2.1 S TAR T S CR EEN The App starts with the tour management screen (cf. Figure 15: Tour Management). As you can see it has the structure of a typical iPhone Table View with the well-known controls: edit and add. In addition the info button represents the contextbased help mentioned above (bottom right).
Figure 15: Tour Management Figure 14: Help on first launch
In case no tour has yet been added, the application launches with an information screen (cf. Figure 14: Help on first launch), giving an overview, explaining what to do and how to do it with the App “myTour”. 5.2.2 TO UR KICKO F F The implementation of a QR Code scanner is already being used for enhanced location awareness in the App. The tour kickoff (adding of a tour) is therefore done by snapping a QR Code as well (cf. 5.1.3 and 5.2.3). The user only needs to point the iPhone camera towards the QR Code and upon recognition; the tour data is collected from the XML web interface (cf. Figure 2). As you can see in Figure 16 the picture taken of the QR Code is quite blurry. Still the QR Code processing library is able, due to multiple error correction measures specified in the QR Code standard (cf. 2.2), to extract the data decoded into the QR Code.
Figure 16: QR Code Capture
5 Implementation On success the user will be directed to the tour management screen in order to select tour details and start the tour (cf. 5.2.3). In case the user accidentally snaps a different QR Code or a QR Code associated with a tour stop, the App displays an error and asks the user to snap a valid kickoff code. 5.2.3 TAKING A TO UR As soon as the tour has been kicked off, the user selects the tour he/she wants to take by clicking the specific tour on the tour management screen (cf. Figure 15). The upcoming
screen presents tour information and on-screen controls to start the tour, as well as to show it on the map and to delete it (cf. Figure 17). The shown controls depend on the current status of the tour. If a tour has not been started yet, the screen looks like such shown in Figure 17. When the tour has already been started, a “Resume Tour” and “Restart Tour” button
Figure 17: Tour detail screen (tour hasn't been started yet) Figure 18: Tour detail screen (tour has been started)
replaces the “Start Tour” button (cf. Figure 18). This measure acts as a signal to the user that he/she has already started the tour and it is possible to take the tour twice, without deleting it.
Starting or resuming the tour brings the user to the map screen (cf. Figure 19). Depending on the tour mode, the tour map shows all stops of the tour (guided tour) or only the next one (scavenger hunt). Stops that have not yet been visited are represented by the red pins. There is no additional information for these stops. When a tour stop is visited by the user, the pin turns green and the additional information provided by the tour creator is made available for the tour taker. How does the App recognize the user to be at a stop? – First of all the App tries to locate the user via GPS. If a user is within a 50 meter range around the stop, the App will automatically show the corresponding information. The 50 meter range is a value that has been determined by various tests in urbanized areas and countryside with different weather situations, which seems to be a good value if you consider these factors. If a position cannot be precisely assigned using GPS, the tour taker has the possibility of snapping a QR Code placed at one of the stops by the tour creator. To trigger the QR Code capturing the process (cf. Figure 11), the user must press the button labelled “I’m at my next stop”. In order to make this process as simple as possible, the QR Code capturing at tour stops works exactly like tour kickoff (cf. 5.2.2). When a user has reached a specific stop, recognized by either GPS or a QR Code, he/she is alerted by the App. The stop is marked as “visited” on the map and the dialog offers a button to access the additional information
Figure 21: You have reached... dialog Figure 20: Stop details Figure 19: Map Screen
(cf. Figure 20). This happens every time the App senses the user is in range of the stop or a QR Code of a stop is snapped (cf. Figure 21). Once a stop has been visited the user can access the information provided at any time in the future. The procedure mentioned has to be repeated for every single stop on the tour in order to finish the tour successfully. If a user wants to view his/her current tour progress without having location sensing switched on, he/she can access it by selecting “Show Tour on the map” in the tour details (cf. Figure 18). The user can access the stop information for the visited stops in this view as well. This map view is exactly the same as the tour taking map view except it lacks location sensing ability. As to be seen in Figure 22, the user has already finished the “FHD Freshman Rallye”. If a user wants to retake a tour he/she is able to do so by touching the “Restart Tour” button (cf. Figure 23). This action will immediately reset the tour. As the dialog indicates, the progress made is deleted. This also means that information connected to visited stops cannot be accessed anymore until the tour taker visits the stops again.
Figure 22: Show Tour on the map
Figure 23: Restart the tour
5 Implementation 5.2.4 THE CO NTEXTUAL HEL P As mentioned above, every screen has a help button located at the bottom right (cf. Figure 18 for example). If the user needs help at any time during the use of the App, he/she receives contextual help (cf. Figure 24). This help concept is in my opinion the most convenient one since the user does not have to browse through a general help file and search for the information he/she needs. Instead, the help is directly related to the screen the user is currently using.
Figure 24: Help System - Tour Details
5.3 E VA LU A TI ON
As stated in 4.3, the tour creator/tour taker application including the way they deal with the QR Code had to be implemented according to the guidelines defined. This has been done and led to a usable implementation of the scenario. The tour creator application is, as mentioned above, not the main application to deal with the QR Codes. This makes it possible to implement in a way the user disregards the details of QR Code generation. In addition, it supplies the user with the tour deployment PDF that is highly self-descriptive and suitable for the task, due to its compressed introduction in deploying the QR Codes needed for the tour. The tour taker application “myTour” conforms to the guidelines as well. QR Code interaction is done in a quick and convenient way wherein the tour taker only needs to touch one button, is offered a scanning view and the rest is executed by the App. The user can access a contextual help whenever he/she needs to and is offered precise and suited information regarding his/her current screen. Moreover the “iPhone Human Interface Guidelines” provided by Apple are used to implement a look-and-feel the user is familiar with when he/she uses the App.
6 . C ONC LU SI ON
The approach of using QR Codes as a complementing global positioning method for location aware iPhone Apps is, in my opinion, a good way to support GPS. Not only is it possible to offer this technology to a wide audience due to its free access, it is also a technology that the consumer can easily use. The reason for this is that QR Codes have become more important in mobile application during the last years and more and more mobile Apps use them in similar ways. This general awareness of the technology leads to the fact that a system using the QR Code can be implemented in a usable way. Moreover deployment does not require a great effort. Basically, it is: Print and go. Yet I want to intersperse the fact that location awareness via the QR Code is still a manual method. The user has to consciously interact with the QR Code in order to get his/her current location. There is another downside that is not as much associated with the QR Code itself, but with the idea of supplying location awareness in buildings. Publicly available map material does not show the ground plan of a building. Therefore, it is difficult to determine the exact position of inside locations. Another argument is that buildings are likely to have more than one floor. If two spots have the same location but on different floors it is impossible to distinguish the two. The user could solve the first problem if he supplies the ground plans. For the second problem I cannot provide a convenient solution at the moment. However, the complementing methods for location awareness and the QR Code in particular have to be seen as a general approach of assisting GPS in providing location awareness. This thesis proves that complementing methods can help to improve location awareness in situation where GPS signal is weak or unavailable. All in all, the QR Code shows that location awareness does not have to be established only through GPS. In addition this thesis offers a fully implemented use-case that proves the QR Code to be a fully capable technology usable with location awareness.
7 Future Outlook
7 . FU TU RE OU TLOOK
Enhanced location awareness is, not only in my opinion, one of the topics to be dealt with in mobile application during the next few years. My approach shows that it is possible to provide a manual way that is cost-efficient, usable and yet flexible. However, it is only one possible approach which still requires user interaction. The goal must result in finding a method the user does not have to be aware of. This could be with the help of different signals the handset is able to pick up, such as bluetooth or wireless. Still, these are methods that are not as easy to implement and are to a great extent very expensive. In addition they require a certain infrastructure that has to be provided. For example: access to power. It will be interesting to see whether a standard for dealing with enhanced location awareness will be implemented which helps to provide location awareness regardless of a strong GPS signal. It is also possible that GPS antennas in mobile devices will become stronger and more powerful therefore solving the problem that makes finding a complementing method obsolete. However, the problem of lacking GPS signal will, in my opinion, play a role for the next couple of years. All in all, there are two possible ways of dealing with insufficient GPS signals in the future. Either mobile devices will be equipped with stronger GPS antennas or there will be a general method to determine handset location via a third technology the user does not have to be aware of. In any case, the precision of location awareness will improve therefore leading to more location aware mobile Apps.
LI TERATU RE I NDEX
Apple Inc. (2010). Apple iPhone Specification. Retrieved 05 05, 2010 from http://www.apple.com/iphone/specs.html Apple Inc. (2010). iPhone Human Interface Guidelines. B.Hofmann-Wellenhof, H. L. (1997). GPS Theory and Practice (Fourth, revised edition ed.). Graz, Austria: SpringerWienNewYork. Dahm, M. (2006). Grundlagen der Mensch-Computer-Interaktion - Chapter 7: Normen und Gesetze. Pearson Studium. DENSO WAVE INCORPORATE. (n.d.). QrCode.com. Retrieved 05 04, 2010 from http://www.densowave.com/qrcode/index-e.html Google. (n.d.). Google Chart Tool. Retrieved 06 2010, 26 from http://code.google.com/apis/chart/docs/gallery/qr_codes.html IEC/2006, I. (2006, 09 01). ISO/IEC 18004 Information technology — Automatic identification and data capture techniques — Bar code symbology — QR Code. (Second edition). Jones, N. (2010). Ten Mobile Technologies to Watch in 2010 and 2011. Gartner Research. Kincaid, J. (2010, 04 08). Techcrunch. Retrieved 05 05, 2010 from http://techcrunch.com/2010/04/08/apple-has-sold-450000-ipads-50-million-iphones-todate/
Figure 25: Flow Chart iPhone App
Figure 26: Flow Chart Web Application