QR Codes as a Complementing Global Positioning Method
-
Upload
sebastian-borggrewe -
Category
Documents
-
view
956 -
download
0
description
Transcript of QR Codes as a Complementing Global Positioning Method
QR CODES AS A COMPLEMENTING GLOBALPOSITIONING METHOD FOR LOCATION AWARE IPHONE APPS
SEBASTIAN BORGGREWE - 513015 - [email protected]
FACHHOCHSCHULE DÜSSELDORFUNIVERSITY OF APPLIED SCIENCE DÜSSELDORF
FACHBEREICH MEDIENDEPARTMENT OF MEDIA
DEGREE PROGRAM: MEDIAINFORMATICS
FIRST EXAMINER: PROF. DR.-ING. MARKUS DAHM MSCSECOND EXAMINER: PROF. DR. CHRISTOPH THIEL
2
I . AF F I DAT I 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
Sebastian Borggrewe
3
I I . ABS T RAC T
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.
4
!
T AB L E O F CO NT ENT S
I.! AFFIDATIV 2!
II.! ABSTRACT 3!
1.! INTRODUCTION 6!
2.! BASIC TECHNOLOGIES 8!
2.1! GPS 8!
2.2! QR CODES 9!
2.3! IPHONE 9!
3.! SCENARIO 11!
4.! ANALYSIS 13!
4.1! CRITERIA 13!
4.2! FITNESS FOR PURPOSE OF THE QR CODE 14!
4.3! REQUIREMENTS REGARDING THE IMPLEMENTATION 14!
5.! IMPLEMENTATION 17!
5.1! THE TOUR CREATOR WEB FRONT END 17!
5.1.1! NAVIGATION 18!
5.1.2! CREATING A TOUR 18!
5.1.3! THE TOUR DEPLOYMENT PDF 20!
5.1.4! USER HELP 21!
5.2! THE TOUR TAKER IPHONE APP “MYTOUR” 22!
5.2.1! START SCREEN 23!
5.2.2! TOUR KICKOFF 23!
5.2.3! TAKING A TOUR 24!
5
5.2.4! THE CONTEXTUAL HELP 27!
5.3! EVALUATION 27!
6.! CONCLUSION 28!
7.! FUTURE OUTLOOK 29!
LITERATURE INDEX 30!
APPENDIX 31!
1 Introduction 6
1 . I NT RODU C T I 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.
1 Gartner, Ten Mobile Technologies to Watch in 2010 and 2011, p.4, l.11-12
1 Introduction 7
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 8
2 . BAS I C T EC H NOL OG I 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 9
2 .2 QR C ODE S
The QR Code2 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
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 machine-
readable 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 H ONE
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.
2 QR Code is registered trademark of DENSO WAVE INCORPORATE
Figure 1: QR Code Caption
Source: ISO/IEC 18004
2 Basic Technologies 10
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 Scenario 11
3 . S C 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.
3 Scenario 12
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 Analysis 13
4 . ANAL Y S I 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 well-
suited 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 Analysis 14
4 .2 FI TNE SS FOR P U RP OSE OF TH E 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 TH E 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.
4 Analysis 15
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 16
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 Implementation 17
5 . I M PL EM ENT AT I 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.
5 .1 TH E TOU R C RE A TOR W E B FRONT E ND
The web front end is implemented with the help of a PHP framework called Code Igniter. I
chose this framework because it provides a basic structure for developing a web based
platform without being highly complex. Since the web front end consists basically of one view
manipulated by javascript, this framework was best suited in my case.
The purpose of the tour creator application is the creation and alteration of tours as well as
the provision of the QR Codes via PDF (cf. 5.2.3). As seen in Figure 3, which is the home page of
Figure 2: Data exchange between web front end and iPhone App
5 Implementation 18
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.
5. 1. 1 N AV IG AT IO N
The navigation offers only the options that are
absolutely needed for creating a tour and
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 EAT IN G A T O U R
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.
3 The map used is provided by Google Maps 4 In Germany, the imprint is required by law.
Figure 3: Web front end
Figure 4: Navigation
Figure 5: Editing tour information
5 Implementation 19
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.
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 6: Editing stop information
Figure 7: Marking the location on the map
Figure 8: Location has been marked on the map
5 Implementation 20
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 T HE T O U R D EP L O Y MEN T P D F
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 9: Save the tour
Figure 10: Tour deployment instructions
5 Implementation 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.
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.
5. 1. 4 U S 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 12: Example for a tour stop QR Code
Figure 11: Kickoff QR Code
5 Implementation 22
5 .2 TH E TOU R TA KE R I P H ONE 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.
Figure 13: User Help
5 Implementation 23
5. 2. 1 S T AR 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 context-
based help mentioned
above (bottom right).
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 T O U R 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 15: Tour Management Figure 14: Help on first launch
Figure 16: QR Code Capture
5 Implementation 24
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 T AKIN G A T O U R
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
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.
Figure 17: Tour detail screen (tour hasn't
been started yet)
Figure 18: Tour detail screen (tour has
been started)
5 Implementation 25
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 19: Map Screen
Figure 21: You have reached... dialog Figure 20: Stop details
5 Implementation 26
(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 27
5. 2. 4 T HE CO N T EX T U AL 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.
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.
Figure 24: Help System - Tour Details
6 Conclusion 28
6 . C ONC L U S I 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 29
7 . F U T U RE OU T L OOK
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.
30
L I T ERAT U 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.denso-
wave.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-to-
date/
31
APPENDI X
Figure 26: Flow Chart Web Application
Figure 25: Flow Chart iPhone App