Embed Size (px)
Citation preview
MASTER THESIS
Thesis submitted in partial fulfillment of the requirements for the degree of
Master of Science in Engineering at the University of Applied Sciences
Technikum Wien - Degree Program Multimedia and Software Engineering
User Centered Cross-Platform Application
Development for Mobile Devices
By: Jana Mrazova, BSc
Student Number: 1110299042
Supervisor 1: Benedikt Salzbrunn, MSc
Supervisor 2: Dipl.-Ing. Mag. Dr. Michael Tesar
Vienna, 15.05.2012
Declaration
„I confirm that this thesis is entirely my own work. All sources and quotations have been
fully acknowledged in the appropriate places with adequate footnotes and citations.
Quotations have been properly acknowledged and marked with appropriate punctuation.
The works consulted are listed in the bibliography. This paper has not been submitted to
another examination panel in the same or a similar form, and has not been published. I
declare that the present paper is identical to the version uploaded."
Place, Date Signature
Any statements contained herein are to be understood as gender neutral. For brevity the
masculine form is being used.
3
Kurzfassung
Der Markt für mobile Endgeräte ist in den letzten Jahren stark gewachsen und hat
mittlerweile eine Größe erreicht, bei welcher es sich kein modernes Unternehmen leisten
kann, diesen zu ignorieren. Native Anwendungen für alle Smartphone-Gerätetypen zu
erstellen, kostet Zeit und Ressourcen, da jeder Hersteller unterschiedliche Geräte und
Entwicklungswerkzeuge zur Verfügung stellt. Eine Lösung dieses Problems ist die
Erstellung von gerätunabhängigen Anwendungen. Diese werden in einem Webbrowser
angezeigt, können daher auf allen Betriebssystemen und Plattformen ausgeführt werden
und erreichen somit die größtmögliche Anzahl an BenutzerInnen.
Der theoretische Teil dieser Masterarbeit beschäftigt sich mit der Struktur des Smartphone-
Marktes und vergleicht native und plattformübergreifende Anwendungen. Verschiedene
Usability-Methoden und -Richtlinien werden in einem weiteren Abschnitt aufgezeigt.
Ergebnis dieser Masterarbeit sind Richtlinien zur Erstellung von benutzerfreundlichen,
geräteunabhängigen Anwendungen. Diese zeigen, wie unterschiedliche Webbrowser und
gerätespezifische Fähigkeiten bestmöglich genutzt werden können. Die Richtlinien
basieren auf weitreichender Recherche der Fachliteratur, Beobachtungen von
BenutzerInnen bei der Bedienung von Smartphones und Usability-Tests der
geräteunabhängigen UnserWein-Applikation.
Diese Masterarbeit richtet sich an DesignerInnen, Benutzerschnittstellen-EntwicklerInnen
und Personen, die Interesse an der Gestaltung von plattformunabhängigen Anwendungen
haben.
Schlagwörter: web-basierend, gerätunabhängige Anwendung, Usability, Smartphone,
Usability Testing, Benutzerschnittstelle
user interface, usability test, Leitfaden, benutzerschnittstelle, mobile ?
4
Abstract The mobile market is growing rapidly and has reached a size where no software company
can ignore the need to participate in it any longer. Creating a native application requires
lots of resources and might cause problems with development and deployment, since all
leading mobile device manufacturers have different devices and development tools. One
solution to this problem would be to create a cross-platform application which is available
on all operating systems, as it runs in a browser and therefore can reach the largest
possible number of end-customers.
The theoretical part of this paper focuses on the structure of the smartphone market and
compares native and cross-platform applications highlighting their advantages and
disadvantages. As cross-platform applications run on multiple platforms this thesis
analyzes the differences between them. The last section of the theoretical part discusses
usability methods and guidelines.
The main purpose of this thesis is to create a guideline for designing user-friendly cross-
platform applications which take advantage of multiple browsers and device capabilities.
The guideline is based on literature research, observations and a usability test conducted
on a real-world cross-platform application, and is introduced in the practical part of this
thesis.
This master thesis targets designers, user interface developers and everyone who is
interested in designing cross-platform applications.
Keywords: web-based, cross-platform application, smartphone, usability, user interface,
usability testing, mobile operating system
5
Acknowledgements
I would like to thank my mentor, Benedikt Salzbrunn MSc, for his valuable ideas, tireless
efforts and countless hours spent reviewing my thesis and providing feedback. Without his
help this paper would not have achieved the final form which you see today.
I also want to thank Bernhard Gschwantner and Thomas Ungrad from UnserWein.at for
their continuous encouragement during my work on the practical part of this research.
And lastly, this master thesis would not have been possible without the love and support
from my fiancé and best friend Peter Koen.
6
Table of Contents
1 INTRODUCTION ............................................................................................................................... 9
Motivation ......................................................................................................................................... 9 1.1
Research Questions ....................................................................................................................... 9 1.2
Methods .......................................................................................................................................... 10 1.3
Structure ......................................................................................................................................... 11 1.4
What is not contained in this thesis ............................................................................................ 11 1.5
2 MARKETS FOR MOBILE APPLICATIONS .................................................................................. 12
Market structure ............................................................................................................................ 12 2.1
Mobile applications ....................................................................................................................... 13 2.2
2.2.1 Native mobile application ........................................................................................................ 14
2.2.2 Cross-platform application ...................................................................................................... 16
Choosing between native and cross-platform application ...................................................... 19 2.3
2.3.1 Reasons for choosing a native application ........................................................................... 19
2.3.2 Reasons for choosing a cross-platform application............................................................. 21
3 COMPARISON OF MOBILE DEVICES ......................................................................................... 22
Screen Size.................................................................................................................................... 22 3.1
3.1.1 Android ....................................................................................................................................... 22
3.1.2 IPhone ........................................................................................................................................ 23
3.1.3 Windows Phone ........................................................................................................................ 24
3.1.4 Screen size summary .............................................................................................................. 25
Display density .............................................................................................................................. 25 3.2
3.2.1 IPhone ........................................................................................................................................ 26
3.2.2 Windows Phone ........................................................................................................................ 27
3.2.3 Android ....................................................................................................................................... 27
3.2.4 Density-independent pixels ..................................................................................................... 27
Changing portrait/landscape view .............................................................................................. 29 3.3
User Input ....................................................................................................................................... 30 3.4
3.4.1 Touch input ................................................................................................................................ 30
3.4.2 Gestures .................................................................................................................................... 31
3.4.3 Keyboard input .......................................................................................................................... 31
3.4.4 Hardware buttons ..................................................................................................................... 32
3.4.5 Other input methods ................................................................................................................. 33
4 USER-CENTERED APPROACH ................................................................................................... 34
Usability .......................................................................................................................................... 34 4.1
4.1.1 General usability guidelines .................................................................................................... 35
Usability testing ............................................................................................................................. 38 4.2
4.2.1 Testing environment ................................................................................................................. 38
7
4.2.2 Participants ................................................................................................................................ 40
4.2.3 Test tasks .................................................................................................................................. 41
4.2.4 Stages of a test ......................................................................................................................... 43
Other usability methods ............................................................................................................... 45 4.3
4.3.1 Observation ............................................................................................................................... 45
4.3.2 Thinking aloud ........................................................................................................................... 45
4.3.3 Questionnaires .......................................................................................................................... 46
5 UNSERWEIN.AT – USER CENTERED CROSS-PLATFORM APPLICATION ......................... 47
Introduction of the company UnserWein.at ............................................................................... 47 5.1
Vievinum/UnserWein.at application ........................................................................................... 47 5.2
5.2.1 Homepage ................................................................................................................................. 48
5.2.2 Wine maker’s page ................................................................................................................... 50
5.2.3 Wine page .................................................................................................................................. 52
5.2.4 Bookmarking winery/wine ........................................................................................................ 53
5.2.5 Additional features .................................................................................................................... 54
Usability test preparation ............................................................................................................. 55 5.3
5.3.1 Testing environment ................................................................................................................. 55
5.3.2 Test tasks .................................................................................................................................. 56
5.3.3 Participants ................................................................................................................................ 58
5.3.4 Combining usability methods .................................................................................................. 59
Usability test execution ................................................................................................................ 59 5.4
5.4.1 Preparation ................................................................................................................................ 59
5.4.2 Introduction ................................................................................................................................ 60
5.4.3 The test ...................................................................................................................................... 60
5.4.4 Debriefing .................................................................................................................................. 61
Test results .................................................................................................................................... 61 5.5
5.5.1 First impressions of Vievinum/UnserWein.at ........................................................................ 61
5.5.2 Task 1 evaluation ..................................................................................................................... 61
5.5.3 Task 2 evaluation ..................................................................................................................... 62
5.5.4 Task 3 evaluation ..................................................................................................................... 63
5.5.5 Task 4 evaluation ..................................................................................................................... 64
5.5.6 Task 5 evaluation ..................................................................................................................... 64
5.5.7 Questionnaires evaluation ....................................................................................................... 65
5.5.8 Evaluation of the discussions ................................................................................................. 68
New design proposal .................................................................................................................... 69 5.6
Additional improvement proposals ............................................................................................. 73 5.7
6 GUIDELINE FOR CREATING A USER-CENTERED CROSS-PLATFORM MOBILE
APPLICATION ......................................................................................................................................... 75
7 DISCUSSION ................................................................................................................................... 78
Research questions ...................................................................................................................... 78 7.1
8
Future perspectives ...................................................................................................................... 79 7.2
7.2.1 Cross-platform applications .................................................................................................... 80
7.2.2 Vievinum/UnserWein.at application ....................................................................................... 80
8 BIBLIOGRAPHY ............................................................................................................................. 82
9 TABLE OF FIGURES ...................................................................................................................... 84
10 LIST OF TABLES ............................................................................................................................ 87
11 WEB LINKS ..................................................................................................................................... 88
12 ATTACHMENT – QUESTIONNAIRE ............................................................................................ 89
13 ATTACHMENT – RECORDING CONSENT FORM ..................................................................... 90
9
1 Introduction
This introductory chapter first outlines the motivation, which explains why the subject of this
thesis is relevant. Additionally, research questions and their corresponding scientific
methods are introduced. The final part illustrates the structure of this thesis.
Motivation 1.1
The market for mobile applications is growing rapidly, reaching a size where no software
company can ignore the need to participate in it. The mobile market leaders all have
different devices and means of development tools and creating an application that runs
natively on all these operating systems requires a lot of resources such as developers,
time and technical know-how.
An alternative to this solution are cross-platform applications. These types of mobile
applications are available on all operating systems, as they run in a browser and can
therefore reach the largest possible number of end-customers without the need to
expend resources on multiple native versions of an application; however, this solution
also has a down-side. A cross-platform application cannot leverage the advantages of
an operating system such as predefined design guidelines and interactions, or sensors
which users are used to. The solution to this challenge is to create a user-friendly
application that would make the best use of a browser’s capabilities and display an
application in a manner which minimizes the negative aspects of cross-platform
applications.
This paper focuses on this problem and its aim is to create a guideline for creating a user-
centered application.
Research Questions 1.2
The purpose of this thesis is to provide an overview of usability methods and guidelines in
order to create the best possible design for a cross-platform application, which would make
the best use of the multiple browser and device capabilities.
The first question that needs to be answered before proceeding onto other topics is: Which
mobile operating systems are the most common? This question is essential as it provides
an overview of the distribution of mobile browsers and will be useful later when creating a
guideline, to focus on the platforms with the highest current market share and potential in
the future.
10
To better explore the capabilities of cross-platform application and to be able to assess the
suitability of the solution presented in this thesis it is necessary to answer another
question: What are the advantages and disadvantages of cross-platform application
development compared to native application development?
To expand on the previous question, it is also very interesting to find out the acceptability
of end-users towards cross-platform applications. Can a cross-platform application deliver
the same results as a native application? To better understand this problem, another
question will be explored within this thesis: What type of application is preferred by end-
users: cross-platform or native?
Once the foundation has been set, the last remaining question is: Which usability principles
should be followed when designing a cross-platform application for mobile devices? The
result will be a guideline that will help design a user-friendly cross-platform application
which will make the best use of a browser’s capabilities and display an application in a
manner that will minimize the negative aspects of cross-platform applications.
Methods 1.3
In order to answer the referenced research questions in a highly qualitative and
comprehensive way, the following scientific methods will be employed in this thesis:
1. Which mobile operating systems are the most common?
Internet/Literature research – the most up-to-date statistics about the market
share as well as predictions for the future
2. What are the advantages and disadvantages of cross-platform application
development compared to native application development?
Comparison, Internet/Literature research – description of the possible
advantages and disadvantages of native and cross-platform applications
3. What type of application is preferred by end-users: cross-platform or native?
Questionnaire – participants of the usability test will conduct a survey at the
end of their test
4. Which usability principles should be followed when designing a cross-
platform application for mobile devices?
Best practice, Observation, Internet/Literature research – the general
usability guidelines will be extended based on the usability tests conducted
on a real-life cross-platform application
11
Structure 1.4
After the introduction, the first theoretical part of this thesis will provide the reader with the
most recent statistics about latest market leaders as well as predictions about market
shares in the year 2015. Later the focus will be on mobile applications in general. First it
will be explained what native and cross-platform applications are, and they will be
compared to each other to provide a better understanding of the advantages and
disadvantages of such applications. As a cross-platform application runs on multiple
platforms, the focus of the second part will be on analysis of requirements of devices
based on the list of operating systems that were chosen in the first theoretical part.
The third part will describe the general usability guidelines. For the purpose of better
understanding the usability test, which will be conducted in the practical part of this thesis,
its preparation and process, will be explained.
The final two chapters of this thesis will have a practical focus and will make use of all the
knowledge collected in the theoretical part of this thesis. A cross-platform application
created by an Austrian company called UnserWein.at will first be introduced and later on it
will be closer examined by conducting usability tests. Based on the results, observations
and previous experience of the author, the last part of this thesis will introduce a guideline
for creating user centered cross-platform applications.
What is not contained in this thesis 1.5
The focal point of this thesis is creating a guideline for designing user centered interfaces
for cross-platform applications, independent of technology. Therefore describing the
technology of implementation, development and deployment of web-based applications is
outside of the scope of this thesis and will not be examined closely.
12
2 Markets for mobile applications
The first part of this thesis will provide the reader with an overview of the current mobile
market, as well as an estimation about the future market share of mobile operating
systems. This type of introduction is necessary in order to better assess the potential of
these platforms and put the focus of this thesis on the companies which show the greatest
potential for being the future market leaders.
Later this chapter will focus on native and cross-platform applications in general. These
applications will first be explained and then analyzed in order to better understand the
advantages and disadvantages of both application types. To enable better decision making
when planning an application for mobile devices, the last part of this chapter will
summarize the reasons for choosing either a native or a cross-platform application.
Market structure 2.1
As of today the mobile market has five major companies competing against each other with
their mobile operating systems – Google, Apple, Nokia, Blackberry and Microsoft. Based
on a report (Drake, et al., 2011, p. 12), released in December 2011, Table 1 shows the
shipment share by operating system in year 2011, as well as an estimate for the year
2015.
Operating system mix (%) 2011 Market Share 2015 Market Share
Android 49.0 46.5
Blackberry OS 11.1 10.0
iPhone OS 18.2 19.3
Symbian 16.4 0.1
Windows Phone 1.9 20.6
Other 3.3 3.5
Table 1 Worldwide smartphone shipments by operating system, 2011, 2015
Source: IDC December 2011 (Drake, et al., 2011, p. 12)
Based on the data in Table 1 it is clear that Android as well as iPhone OS are the current
market leaders, possessing a combined total of more than 67% of the mobile market
share. Also, as the estimation for 2015 shows, it is believed that both of these operating
systems are going to keep, with a very little fluctuation, their market share in the future.
On the other hand, where a high fluctuation in numbers occurred, as can be seen in Table
1, a big shift in the mobile market is estimated on Microsoft’s side with its Windows Phone
operating system and Nokia’s Symbian. As of 2011, Microsoft showed a minimal market
share, rounding around 2%. However, by the year 2015 the estimation shows over 20% of
13
the market share. This percentage seems to come from Symbian operating system,
whereas in 2011 the market share was relatively high with 16.4%, in 2015 it is estimated
that Symbian, with 0.1% market share, will no longer play a major role in the smartphone
market.
According to ICD (Drake, et al., 2011, p. 7) the reason for excluding Nokia from
smartphone market in 2015 as well as increasing Microsoft’s market share to 20% is due to
the decision made on February 11, 2011, when Nokia chose Windows Phone operating
system as their primary platform for smartphone devices. Even though Symbian operating
system will continue having technical support for the following five years, based on IDC
report (Drake, et al., 2011, p. 7) from December 2011 “IDC believes that competitive
pressure from other operating systems and changes in OS strategy by its biggest
supporters will result in lower market share in the years to come”.
All these facts considered, for the purpose of this thesis three mobile operating systems
were chosen – iPhone, Android and Windows Phone. Android and iPhone were chosen for
their current as well as future market positions and Windows Phone platform for its
potential in the years to come. These operating systems are going to be analyzed and later
on, based on their capabilities, a guideline for creating a user centered cross-platform
application will be created.
Mobile applications 2.2
The world is facing a new mobile era and the latest research in the field of smartphones
market share conducted by Canalys only supports this statement. This research (Alto,
2012, p. 1), released on February 3, 2012 states that in 2011 for the first time in history,
more smartphones (488 million) were shipped than client PCs (415 million). This has had a
great impact on the market, as well as mobile application development, as it clearly shows
the shift from personal computers to mobile devices, where mobility and handling have
won over the users.
These days it is more important than ever for software companies to cover as much of the
mobile market as possible with their applications. However the question that needs to be
asked is what kind of mobile application this should be – a native application or web-based
so called cross-platform application?
14
Native mobile application 2.2.1
A few years ago, the only approach considered when developing an application for mobile
devices was to create a native application, as it was much easier to deliver a compelling
user experience this way than by any other means. According to (Rodger, 2012, p. 32)
native applications are “written in a device-specific language, using device-specific
programming interfaces and they can access all capabilities of the device and can take
many forms, from simple utility apps to advanced 3D games”. These device-specific
languages are showed in Table 2.
Operating System Google
Android
Apple
iPhone
Microsoft
Windows Phone
Programming Language Java Objective-C C#
Table 2 Smartphone operating systems and languages
Source: (Allen, et al., 2010, p. 5)
In “Pro Smartphone Cross-platform development” (Allen, et al., 2010, p. 5) the author adds
that even though it is possible to use other languages for native applications than the ones
illustrated in Table 2, they don’t optimally use all the capabilities of a particular smartphone
device and therefore are not as optimized as the device-specific languages. Figure 1
shows Trip Advisor as three different native applications, running on iPhone, Android and
Windows Phone.
Figure 1 Trip Advisor native applications on iPhone (left), Android (middle), and Windows Phone
7(right)
Source: The author’s own visualization
15
From Figure 1 it is instantly recognizable that these three instances of the same application
differ from each other on many levels – such as the placement of controls, navigation, color
scheme and design elements.
This approach therefore requires a lot of resources in terms of development and
deployment. These are necessary for creating applications for multiple operating systems,
which might be seen as a disadvantage. Therefore, the following sections will name the
various advantages (Figure 2) and disadvantages (Figure 3) of native application to better
understand its flexibility and field of application.
Advantages
Figure 2 Native application – advantages
Source: The author’s own visualization
Full access to all capabilities of a device
The main advantage of a native application is its ability to access all capabilities of a device
such as geo-location services, accelerometer, camera, gyroscope and many others (Olson,
et al., 2012, p. 10). These sensors are a necessity when designing complex application
which requires different means of input, such as a shake or a compass.
Native user interface
According to (Olson, et al., 2012, p. 10), another advantage of native application is its
ability to make use of the native user interface features of an operating system, which add
both the flexibility and richness to the user experience. It is worth mentioning that iPhone,
Android and Windows Phone all have their own design guidelines which, when followed
properly, create a consistent and user friendly experience within that particular operating
system.
Disconnected mode
Another important advantage of a native application is its ability to work in offline mode
(Olson, et al., 2012, p. 10). This can either be done constantly, where data is directly
available on the device, or intermittently, where only when necessary the data is
downloaded from a server.
•Full access to all capabilities of a device
•Native user interface
•Disconnected mode
Native application advantages
16
Disadvantages
Figure 3 Native application – disadvantages
Source: The author’s own visualization
Deployment and development
As mentioned before, the greatest disadvantage of a native application is the amount of
resources required for the deployment and development of such applications (Olson, et al.,
2012, p. 10). The term deployment refers to the necessity of having multiple distribution
channels for each platform, as well as the time consumption involved when updating an
application. Development of a native application requires a lot of resources in the forms of
technical and designer know-how, time and costs.
Cross-platform application 2.2.2
Cross-platform application is, according to Richard Rodger (Rodger, 2012, p. 2) a webpage
which is designed to run like an application. It is centrally deployed on a server, and
therefore is nondependent on the operating system as it is running in a web browser
(Olson, et al., 2012, p. 10). This type of application leverages some disadvantages of a
native application such as deployment and development, as one universal instance of an
application can be run on every operating system with a web browser.
Figure 4 illustrates a cross-platform mobile version of youtube.com on Windows Phone,
iPhone and Android operating systems. Apart from different controls and navigation, it is
clear that the layout, as well as the general design of all three applications is identical,
meaning that all three operating systems are using the same instance of a YouTube
application available via the web browser.
•Deployment and development
Native application
disadvantages
17
Figure 4 Web Based mobile version of youtube.com on Windows Phone (left), iPhone (middle) and
Android (right)
Source: The author’s own visualization
As with native application, a cross-platform application also has many advantages (Figure
5) as well as disadvantages (Figure 6) that might be crucial when deciding on the type of a
mobile application.
Advantages
Figure 5 Cross-platform application – advantages
Source: The author’s own visualization
Easy portability
The first advantage according to (Olson, et al., 2012, p. 10) is the easy portability of cross-
platform applications to new forms of computing such as tablets. What this means is that if
the code is written in a clean way – logic separated from user interfaces – it is possible,
with minimal adjustments, to adapt the application to new smartphones versions, or tablets.
•Easy portability
•Centrally managed distribution
•Low-friction deployment
•Cross-platform
Cross-platform advantages
18
Centrally managed distribution
As cross-platform applications are uploaded on a server, and not on a device, it means that
they are centrally managed (Olson, et al., 2012, p. 10). This makes the deployment as well
as updates much easier to implement.
Low-friction deployment
Richard Rodger (Rodger, 2012, p. 5) extends the previous point and adds low-friction
deployment to the list of advantages. According to his book, in the process of deployment
there is no third party that would slow down the approval process and therefore the
application is ready for immediate launch.
Cross-platform
As the title suggests, a cross-platform application has its field of application on a number of
operating systems and devices (Rodger, 2012, p. 5), without the need for creating multiple
instances for an application.
Disadvantages
Figure 6 Cross-platform application – disadvantages
Source: The author’s own visualization
Access to device sensors
Cross-platform application also has a few drawbacks, one of which being the inability of a
web application to access the sensors (with a few exceptions) of a mobile device (Olson, et
al., 2012, p. 11). There are certain applications which are dependent on the use of device
sensors and if they cannot be accessed it might be a reason to opt for a native application.
Connectivity
As a cross-platform application is nothing but a webpage which is displayed through a
mobile browser, it can be deduced that such an application requires an internet connection
(Olson, et al., 2012, p. 11). This failing in web-based application is a big disadvantage, as it
may not only bring about additional charges from the mobile providers, but also
unavailability in certain regions due to lack of reception.
•Access to device sensors
•Connectivity Cross-platform disadvantages
19
Summary
The following Table 3 is presenting the advantages and disadvantages of a native and a
cross-platform application in a summarized form.
Advantages Disadvantages
Native
application
Full access to all
capabilities of a device
Native User Interface
Disconnected mode
Deployment and
development
Cross-platform
application
Easy portability
Centrally managed
distribution
Low-friction deployment
Cross-platform
Access to device
sensors
Connectivity
Table 3 Advantages and disadvantages of native and cross-platform applications
Source: The author’s own visualization
Choosing between native and cross-platform 2.3
application
The previous sections explained both mobile application types, however the question
remains: when is it better to develop a native and when a cross-platform application? The
advantages and disadvantages of both application types already provide some answers to
this question, but there still may be situations where this might not be clear.
Reasons for choosing a native application 2.3.1
According to Brian Fling there are a few cases when it is necessary to develop a native
application (Fling, 2009, p. 147). These include:
1. Charging for it
When the finalized version of an application is to be sold to customers, it is advisory to
make it a native application. The first reason for creating a native application it is that
purchasing a web application using a credit card may not be secure on some older
devices. Another solution to this problem includes using secure websites, but this is no
longer a single step process and might lead to a lower acceptability on the customer’s side
(Fling, 2009, p. 146).
20
2. Creating a game
Another reason for choosing a native application over a cross-platform one is game
development. The reason for this is that users already have certain expectations towards
games which are available on their devices such as resource intensive graphics, or the
usage of device sensors. There are means of creating games for mobile web browsers;
however, these do not provide the same experience as a native application. Therefore it is
advised that if one wants to create a commercially successful application in the field of
mobile gaming, a native application has better chances of success (Fling, 2009, p. 147).
3. Using specific locations
Applications that make use of location services should, according to (Fling, 2009, p. 147)
be developed as native applications. Fling states that it is possible to detect the user’s
location on web based applications, however this is connected with privacy issues and as
long as these issues remain unsolved, the number one choice for location services should
remain a native application.
4. Using cameras
Some applications require the use of a device’s camera. With native application this step
can be implemented directly into the application and therefore simplifies the whole process
of image making (Fling, 2009, p. 148). There are certain attempts by W3C (World Wide
Web Consortium) to implement direct access on device’s camera via web application,
however this feature remains unimplemented and it is therefore advisable to use a native
application instead.
5. Using accelerometers
Accelerometer is a favorite means of input into a mobile device, as it detects the device’s
rotation and physical movement. Usually there are other means of input as well, but if it is
necessary to use an accelerometer in an application, the only way to go about it is to
develop a native application (Fling, 2009, p. 148)
6. Accessing the file systems
Getting access to data stored locally on a mobile device is another motivation for choosing
a native application (Fling, 2009, p. 149). This feature is necessary in order to access
contacts, saved images or files which are required by some applications. For the time
being it is not possible to access a local file system with a cross-platform application.
7. Offline users
Disconnected mode is not only a big advantage of a native application, but oftentimes it is
also a reason for choosing this type of application (Fling, 2009, p. 148). Offline application
21
doesn’t require an internet connection as it makes use of local data and therefore can be
used in locations with no reception or wireless connection.
Reasons for choosing a cross-platform application 2.3.2
This previous section focused on the problem of when to choose a native application over
a cross-platform one. This section will focus is on the other side of the problem; namely,
when to choose a cross-platform application over a native one. The solution is very simple.
According to Brian Fling (Fling, 2009, p. 150), if the application doesn’t require any of the
features which were mentioned previously the application should be developed as cross-
platform one. This not only creates a long-term platform for mobile application, it also
reduces the costs for development and deployment.
22
3 Comparison of mobile devices
The focus of this thesis is on cross-platform application. This type of application is running
on multiple platforms and there are a number of factors that need to be taken into
consideration when designing a cross-platform application. Therefore the aim of this
chapter will be to analyze and compare Android’s, iPhone’s and Windows Phone’s devices
to be able to assess the capabilities of each platform. Such a comparison is crucial as it
helps us to understand the challenges faced by web application when attempting to
provide the best possible running of a cross-platform application.
According to (David, 2011, p. 5), there are several major features of mobile devices, which
have an influence on the final user interfaces of mobile application. These include screen
size, high quality resolution, changing portrait/landscape view, input devices and HTML5
support.
This thesis focuses on creating a guideline for creating user interfaces for cross-platform
application and not on technical implementation. Therefore the point regarding HTML5 is
outside the scope of this paper.
Screen Size 3.1
Designing a web based application is a big challenge, as it requires many viewing angles
to be able to visualize what the final application is going to look like on a number of
different devices. The first factor is the screen size in terms of screen resolution.
Android 3.1.1
Out of the three platforms being closely examined by this thesis Android is the only one
which does not constrain the screen size of its devices. The first devices which were
released with Android 1.0 beta in 2007 all had the same screen resolution. However, this
changed in 2009 when Android’s devices started to be released with different resolutions
(Allen, 2012, p. 271).
At the moment Android differentiates between four generalized sizes of displays: extra-
large, large, normal and small screens. These are not only divided based on their screen
size, but also on the distance from which the display is observed (Allen, 2012, p. 47). The
following table (Table 4) taken from the book Beginning Android 4 illustrates these
categories:
23
Category Viewing distance Resolution
Small Under 7,5 cm At least 426 x 320 dp resolution
Normal 7,5 cm to around 11.5 cm At least 470 x 320 dp resolution
Large 11.5 cm to around 25 cm At least 640 x 480 dp resolution
Extra-large Over 25 cm At least 960 x 720 dp resolution
Table 4 Android multiple screen size categories
Source: (Allen, 2012, p. 47)
Figure 7 illustrates four Android phones, each with a different screen resolution and
different size category from Table 4, ranging from extra-large on the left to the small one on
the right.
Figure 7 Four Android phones with their display resolution illustrated in the figure. From left to right –
screen size categories extra-large, large, normal and small
Source: The author's own visualization
The fact that Android does not regulate the size of its displays is an important constraint
that needs to be taken into account when designing applications in general. It means that
the final application can be viewed on as small screen as 120 pixels, all the way up to the
high desktop resolutions.
IPhone 3.1.2
IPhone and Windows Phone are two platforms that have decided to go in a different
direction. To ensure the compatibility of their applications and devices, they have
constrained the resolution to a certain value.
24
With the iPhone versions 2G, 3G and 3GS the resolution was set to 320 x 480 pixels.
However, starting with the version iPhone 4 the resolution doubled the size to 640 x 960
pixels (Figure 8, right).
This change isn’t very dramatic
and doesn’t have as much of an
impact on the designing process,
as the aspect ratio of width and
height remains unchanged
(David, 2011, p. 6).
Windows Phone 3.1.3
Windows Phone platform is the newest arrival on the
smartphone market, appearing in late 2010. In contrast to its
forerunner Windows Mobile operating system, Microsoft has
set a requirement on a screen, which has to be 800 x 480
pixels (Figure 9). This decision makes it easier to develop
mobile applications and to focus on different areas of
development (Lee & Chuvyrov, 2010, p. 6).
Figure 8 Screen size of iPhone 3GS (left) and 4S
(right)
Source: The author's own visualization
Figure 9 Screen size of Samsung Omnia
7 (Windows Phone operating system)
Source: The author's own visualization
25
Screen size summary 3.1.4
This thesis focuses on only three operating systems and already more than five different
resolutions for mobile web applications have been discussed (Figure 10). Other companies
on the market are also using different screen sizes and there will no doubt be many more
to come, meaning that it is very difficult to know upfront exactly what the available screen
space will be. Even if this information is available upfront, all mobile operating systems
have different status bars, menu bars and URL bars,
which also constrains the visible part of the screen,
leaving even less space for the content than initially
planned for.
In the past, the solution to the various screen sizes was
to set a fixed width to an application, which up to a
certain point provided a reliable rendering of an
application (Fling, 2009, p. 168). Today, however, this
approach is limiting the capabilities of bigger screen
sizes.
To resolve this problem, Brian Fling (Fling, 2009, p. 169)
recommends using a design that allows fluid user
interfaces which automatically adapt to the width and
height of a web application. Not only is the fluid design
the only long-lasting solution to variable screen sizes, it
also takes into consideration the screen orientation. This
solution is also suggested by Allen Grant (Allen, 2012,
p. 273).
Display density 3.2
For many years a pixel was the favorite unit for defining the screen resolution. It is an
easily understandable concept and has worked just fine for many years. These days,
however, mobile displays are changing and the concept of pixels is not comprehensive
enough to apply to screens with density changes (Allen, 2012, p. 274).
What a display density means can be best explained by the following example. What
defines a smartphone is the fact that it is mobile. It can be taken anywhere and fits
comfortably in the palm of a hand; therefore a phone has certain size constraints.
Technology never stops evolving and is always looking for new ways to increase the
Figure 10 Various resolutions of
mobile devices in portrait mode
Source: The author's own
visualization
26
resolution of a screen without changing the size of a device. Density change means that
the same screen size of a device contains more pixels. This has an impact on the size of a
pixel. If more pixels are placed on a regular screen, pixels effectively shrink (Allen, 2012, p.
274). Display density is expressed in PPI, or pixels per inch (Fling, 2009, p. 130). PPI can
be calculated as screen width in pixels divided by the width of display in inches. The higher
the number, the sharper the screen appears.
IPhone 3.2.1
IPhone 3rd Gen vs. iPhone 4th Gen (Figure 8) is a great example for density change. Even
though with the new 4th generation the display size didn’t change, the resolution doubled.
This means that the pixels shrank, thus allowing a higher quality resolution on the same
sized display (Figure 11).
Figure 11 Low-density display on iPhone 3GS (left) vs. high-resolution display on iPhone 4 (right)
Source: (David, 2011, p. 7)
IPhone 3rd Gen has 163 pixels per inch and 4th Generation of iPhones has 326 pixels per
inch, which is considered a very high display density. Just to compare, as of April 2012 the
highest pixel density on the mobile market were featured on the devices Sony Xperia S
and HTC Rezound. They are both ran with Android operating system and with 342 pixels
per inch they provided the highest possible user experience in terms of display quality to
date.
27
Windows Phone 3.2.2
Windows Phone devices, like the iPhone, have a fixed resolution which is set to 480 by
800 pixels. Display sizes range from 3.5 inches to 4.3 inches, which means that they
provide a relatively high quality resolution ranging from 198 PPI (HTC Titan II) to 267 PPI
(LG Quantum).
Android 3.2.3
Android is another operating system which supports a number of display densities, albeit to
a much greater extent than iPhone or Windows Phone platforms. For the purpose of
simplicity when describing display size Android distinguishes between low, medium, high
and extra high screen densities. To better comprehend the diversity of Android devices,
Android conduced a research showing the market share of their devices with all possible
combinations of screen sizes and densities. This research (Google Inc., Screen Sizes and
Densities, 2012) collected data on those devices which had accessed Google Play over a
7-day period time. The following table shows the resulting data.
Low PPI Medium PPI High PPI Extra High PPI
Small 1.9% 2.5%
Medium 0.7% 19.6% 64.6% 2.4%
Large 0.2% 2.3%
XLarge 5.8%
Table 5 Market share of Android devices with different combinations of screen sizes and densities
Source: (Google Inc., Screen Sizes and Densities, 2012)
This research suggested that the highest number of Android devices which accessed the
Google Play during the research phase had the combination of medium screen size with
high pixel density. However as Table 5 illustrates, there are multiple other combinations,
which have to be taken into consideration as during designing process these multiple
screen and density combinations might cause a problem. The reason for this is the size of
the resulting pixel.
Density-independent pixels 3.2.4
A high resolution display with high pixel density provides users with a better overall viewing
experience, but only in those cases when they are fully exploited.
The problem with the size of a resulting pixel is this: if an icon with 40 pixels is placed on a
regular screen with medium density, it can be perfectly clicked by any finger. But if the
same icon is placed on a screen with high density, the pixels might become so small, that
28
the icon may no longer be finger-friendly. This problem is independent of any specific
operating system.
The following figure (Figure 12) shows three Android devices with low, medium and high
density screens displaying same sized pixel square. It is clear that the square on a high
density device is considerably smaller than one displayed on medium or low density
screens, which might render it no longer user-friendly.
Figure 12 Android devices with low, medium and high density screens. They illustrate the inability to
correctly scale the content on high density displays when dimensions are defined in pixels.
Source: The author's own visualization
In this case, as already suggested at the beginning of this section, the pixel is no longer the
most suitable unit for describing the component dimensions of user interfaces as it does
not scale according to the screen density (Allen, 2012, p. 274). Allen Grant suggests that in
order to solve the problem of the inability to scale pixels to different density screens, the
dimensions should be defined in density-independent pixels (dp) instead of normal pixels.
The advantage of density-independent pixels is that they map pixels 1:1 for a screen with
160 pixels per inch and they scale from there.
For example: 100 density-independent pixels on a 160 PPI screen would be depicted as
100 pixels (aspect ratio 1:1). However, if the same 100 density-independent pixels were to
be displayed on a 320 PPI screen, the resulting size would be 200 pixels (aspect ratio 1:2).
29
This means that 100 density-independent pixels at 160 PPI screen have exactly the same
visible size as 100 density-independent pixels at 320 PPI.
Changing portrait/landscape view 3.3
The previous section illustrated screen density on various mobile phones, albeit only in
portrait mode. But cross-platform applications have another unique feature, which allows
the changing of portrait and landscape view (David, 2011, p. 6). A web based application
runs in a mobile browser, which itself is a native application. This allows browsers to make
use of hardware accelerators to determine a device’s orientation and rotation. Depending
on the angle, a web application rotates accordingly. The portrait and landscape view only
support the idea of fluid design, as in landscape mode the dimensions of an application are
exchanged and therefore add to the number of different screen sizes and resolutions.
All three operating systems – Android’s, iPhone’s as well as Windows Phone’s native and
third-party browsers — allow this feature of portrait/landscape view, unless deactivated.
The following figures show the eBay web application in both portrait view (Figure 13) and
landscape view (Figure 14).
Figure 13 eBay web
application in portrait view
Source: The author's own
visualization
Figure 14 eBay web application in landscape mode
Source: The author's own visualization
30
User Input 3.4
When working on a desktop or laptop computer, the most common input devices is a
keyboard, a mouse, or a touchpad, all of which allow very precise input methods. Mobile
phones work differently. They are constrained to a relatively small screen and not only is
the device’s display used for viewing the content, but also for touch input. This implies that
a finger is considered as a primary input method for smartphones (David, 2011, p. 6).
Touch input 3.4.1
Touch input allows users full control over the device and its navigation via finger
movements. In general this type of input works very well, however it is necessary to keep
in mind that a finger is not a mouse and there are certain constraints that need to be
considered, such as finger perspective (Picchi, 2011, p. 110).
A computer mouse is exact, having only one or two pixels at the top of it; fingers on the
other hand, are much bigger and less precise. Some users have thin fingers, others
broader ones. However, disregarding the finger size it is still close to impossible to tap a
typical link from a desktop webpage. Therefore it is necessary to design mobile
applications – both cross-platform and native in a finger friendly manor. All three operating
systems – iPhone, Android and Windows Phone have their own set of rules, which if
followed should create a very finger friendly user interface and maximize the user
experience.
Android states in their designing guidelines that touchable user interface elements should
be at least 48dp high and wide (Google Inc., Metrics and Grids, 2012). The reason for this
number is that it translates to about 9mm on a screen and is therefore an accurate target
for all types of fingers.
IPhone defines in their Human Interface Guidelines (Apple Inc., 2012, p. 59) that the target
area should be no smaller than 44 by 44 points in order to be finger-friendly. According to
the latest user interface guidelines for Windows Phone platform, the recommended size of
a user interface component should be greater or equal to 9mm, without specifying the
exact number in pixels (Microsoft Corporation, Interactions and Usability with Windows
Phone, 2012). In cases where the space is constrained, 7mm is the minimum size of a
target area.
To summarize these numbers, it is clear, that all platforms are reaching for at least 9mm or
an equivalent in pixels as the minimal size for user interface components to assure a
31
finger-friendly touch input. This number has not been chosen arbitrarily, but rather it has
been proven by many usability tests that nine millimeters have the lowest average error
rate of 1.6 percent (Microsoft Corporation, Interactions and Usability with Windows Phone,
2012).
Gestures 3.4.2
Gesture is a type of input which is very closely connected to the touch input. Gestures are
specific single or multiple finger movements on a touch screen, which are associated with
a specific action (Firtman, 2010, p. 259). Some examples of standard gestures are tap,
flick, pinch or touch and hold.
Keyboard input 3.4.3
Another type of input for mobile devices is a keyboard – either on-screen or hardware
(Figure 15). When planning user interfaces it is important to take into account that once a
text field is activated the on-screen keyboard will obstruct a large proportion of the display.
Figure 15 On-screen and hardware keyboard
Source: The author's own visualization
Even though only a very small number of smartphones have a hardware keyboard, it is
necessary to note that they might be used in landscape mode when making data entries.
User interfaces should therefore be planned accordingly.
32
Hardware buttons 3.4.4
Hardware buttons, which are placed on the front-facing side of mobile phones, are another
means of user input.
Android
All Android devices released prior to version 3.0 have four hardware buttons. These are
Home, Back, Menu and Search (Figure 16, left). Starting with version 3.0, the hardware
buttons were considered optional, as they could be replaced by onscreen buttons
(Ostrander, 2012, p. 19). With the same release the Menu button no longer needs to be
provided (Figure 16, right) (Google Inc., Menus, 2012).
Figure 16 Android’s on-screen buttons on Galaxy Nexus and hardware buttons on Motorola Droid
Source: The author's own visualization
IPhone
IPhone provides only one button on the front side (Figure 17). In general, pressing the
Home button navigates the user to the start page. However, to provide the user with more
shortcuts for common features such as task switching or voice control iPhone have
extended the functions of the Home button based on the length and number of taps
(Pogue, 2011, p. 12). One quick press in sleep mode wakes up the phone. One long press
activates the voice control, starting the virtual voice-controlled assistant – “Siri” – in the
iPhone 4S. Two quick presses start either the task switcher or the widget bar. Lastly, three
presses can activate one optional accessibility feature of the user’s preference –
VoiceOver, Zoom or White on Black.
Figure 17 iPhone Home Button
Source: The author's own visualization
33
Windows Phone
Windows Phone devices are equipped with three buttons – Back, Start and Search, and
are located below the display (Figure 18) (Petzold, 2010, p. 4). Back is used for navigation,
the start button directs users back to the start screen and the search button is dedicated to
the Bing search engine.
Figure 18 Windows Phone hardware buttons
Source: The author's own visualization
Other input methods 3.4.5
There are numbers of other input methods such as accelerometers, voice, hardware
buttons or camera. Their purpose is to increase the functionality and implement features
that are of use to users (Betts, et al., 2010, p. 222). These input methods are in general not
supported by cross-platform applications and therefore will not be examined.
34
4 User-centered approach
Just as the usage of mobile phone and smartphones is growing ever year, so are users’
expectations of the mobile user experience. Users expect applications that are easy to
work with, have quick reaction times and feature simple yet attractive user interfaces.
These applications have to know what users want to achieve and to support them in doing
so. As easy as this may sound, it is actually the biggest challenge of a designer’s job.
Therefore the aim of this chapter is to provide an introduction to the topic of usability and
the principles of user interface design, which help to design user-centered applications.
Usability 4.1
The International Organization for Standardization in its part “Guidance on Usability”
defines usability as “the extent to which a product can be used by specified users to
achieve specified goals with effectiveness, efficiency and satisfaction in a specified context
of use” (International Organization for Standardization, 1998, p. 6). Carol Barnum (Barnum,
2011, p. 11) analyzed this rather formal definition and highlights the importance of following
elements of the previous usability definition:
Specific users – the importance of specific users is that the focus is not on all
users, but only on the target group for the particular product
Specific goals – specific goals mean that the product’s goals are identical with
those of its users
Specific context of use – users are using the application in a certain environment
and it is essential that the application is designed to be used under those terms
In the book Usability Engineering Jacob Nielsen uses a different approach when defining
usability and describes it as a property of user interface with multiple components, which
include the attributes learnability, efficiency, memorability, errors and satisfaction (Nielsen,
1993, p. 26).
But regardless of the exact definition, the question remains: how can effectiveness,
satisfaction or memorability be measured? Usability is measured in such a way where a
number of users, or so called participants, are trying to accomplish a set of predefined
tasks (Barnum, 2011, p. 6). Based on this statement, it can be deducted that usability is a
rather subjective discipline; however there are certain guidelines which have been proven
to ensure high usability despite its subjective perception. The following sections will aim to
illustrate some of them.
35
General usability guidelines 4.1.1
General usability guidelines are well-known principles for all user interfaces which should
be followed in the designing process to ensure the highest possible usability of a particular
system (Nielsen, 1993, p. 91). In general they include hundreds of rules that ought to be
followed to create a user-centered design. This number was so high that it was causing a
great deal of confusion amongst designers. In order to make the guidelines more
understandable, Jacob Nielsen and Rolf Molich have revised the list and created ten
general principles for user interface design. In literature the term “heuristics” is also used,
as it suggests that these are more of “rules of thumb” than specific principles. The following
paragraphs describe these ten principles (Barnum, 2011, p. 62)
1. Visibility of system status - This rule suggests that users should always be
informed about the status of a system. A good example is a progress bar (Figure
19). Sometimes certain content takes a while to download and it is important that
the user is aware of this.
Figure 19 Progress bar on Android – Galaxy Nexus
Source: The author's own visualization
2. Match between system and real world – User interfaces and the information
which they display should use terminology that is well understood by users (Figure
20). This means using words, phrases and concepts with which the users are
familiar from real-world conventions.
Figure 20 Well understandable message on a Windows Phone 7 device
Source: The author's own visualization
36
3. User control and freedom – Another important principle according to Nielsen and
Molich is that every system should support undo and redo, in order to be able to
leave the unwanted state.
4. Consistency and standards – if a certain name was used to describe a situation
or action, this name should be used throughout the whole system, to prevent user
confusion (Figure 21).
Figure 21 Good example of consistency in naming on Windows Phone 7
Source: The author's own visualization
5. Error prevention – Errors sometimes happen and once they do, they should have
an understandable error message about what happened. The best way to deal with
them, however, is to eliminate their occurring entirely.
6. Recognition rather than recall – Making objects, actions and options visible
reduces the user’s memory load by not requiring him to remember information from
one dialog to the next.
7. Flexibility and efficiency of use – Allowing users to personalize their frequent
actions as well as use of accelerators often speeds up the interaction between the
system and the user (Figure 22).
Figure 22 Customization example on iPhone
Source: The author's own visualization
37
8. Aesthetic and minimalist design – Removing clutter and information that is
irrelevant or rarely needed provides a better overview of the information that is
important to users.
9. Help users recognize, diagnose and recover from errors – Provide users with
an understandable error message that describes what happened in easy-to-
understand language (Figure 23).
Figure 23 An example of good error message on iPhone
Source: The author's own visualization
10. Help and documentation – In general the best scenario is when users can use a
system without any help. Sometimes, however, it might be necessary to provide
some documentation. It is essential that this document is kept simple and is not too
large.
These rules are of utmost importance and should always be considered, as they are
applicable to all types of user interfaces and therefore also bring added value to mobile
phones and their applications. In addition to these guidelines by Nielsen and Molich, all
mobile platforms discussed in this thesis – Android, iPhone and Windows Phone have their
own set of product-specific design guidelines. A reference to these guidelines can be found
at the end of this thesis in Chapter 11. They provide tips and samples for optimizing the
design, controls, general workflow and consistency in look and feel within that particular
platform.
38
However, what these general usability heuristics and product-specific guidelines do not
include are the specific characteristics of cross-platform applications (such as those
introduced in Chapter 4), which in general require a different approach when designing
their user interfaces. The aim of this thesis is to create such a set of guidelines based on
an evaluation of usability tests conducted on a real-world cross-platform application. Before
this thesis can explain the process of the origination of the final guideline it is essential to
understand the process of usability testing and other usability methods. Therefore the
following section will briefly explain those.
Usability testing 4.2
The usability testing is the most fundamental usability method (Nielsen, 1993, p. 165). Its
purpose is to find out how real users interact with a product while they are being observed
accomplishing specific tasks that are of interest (Barnum, 2011, p. 13). The “product” in
this context refers to “any element or component of the design that contributes directly or
indirectly to the user’s experience” (Barnum, 2011, p. 6) such as software, hardware, or a
website.
The reason why usability testing is so important is that every product is designed to be
used in a certain way. That design is only going to work if the application can anticipate
how users perceive the application and how they go about solving tasks. And as long as
there is space for creating unexpected interpretations of user interfaces, there is a high
probability that users are going to do it. To solve this, the purpose of usability tests is to
detect these unexpected interpretations, find out if the system meets its intended purpose
and help to improve user interfaces (Nielsen, 1993, p. 170).
Depending on the point when the usability testing takes place and on the expected result,
there are two types of usability testing – formative and summative testing (Barnum, 2011,
p. 14). Formative testing is conducted during the development phase of a product. It is
based on small studies and its purpose is to identify and fix user interface problems. On
the other hand, summative testing requires larger number of users and generally takes
place after the product has been finished. Its goal is to evaluate the overall quality of
interfaces based on metrics (Nielsen, 1993, p. 170).
Testing environment 4.2.1
As technology has progressed, usability tests can now be conducted anywhere and
anytime. It is possible to do very simple tests, which only require a user and a product in a
quiet room or to set up a testing environment which includes a fully equipped usability lab.
The decision of which testing environment is the most optimal one, depends mainly on
39
available resources; however, other factors, such as physical location of users may have
some influence as well.
A Quiet room
A testing environment might have many different combinations of set up and equipment,
but the minimum requirements of a test room include a quiet space with a table and two
chairs (Krug, 2010, p. 65). This set up offers a comfortable and undisturbed course of
testing for both the facilitator and the user. Depending on the product, a laptop with internet
connection might also be required.
Usability laboratory
In a more professional and controlled environment the previous set up can be enhanced by
using a camera, a microphone and/or logging software, which are useful for later analysis
of a product, or to highlight the essential discoveries made during the course of the
usability test.
A more sophisticated set up of a testing environment for usability tests might include two-
room labs. These consist of two parts – a test room and an observation room, which is
used for other people to observe the test, without disrupting the participants (Nielsen,
1993, p. 200).
The advantages that a dedicated usability laboratory offers are, for example, the
commitment of a company towards usability testing or convenience that creates an ideal
testing environment, ready to accommodate any planned or unplanned demands that the
product might require (Barnum, 2011, p. 26).
Field testing
Although a dedicated usability lab offers many advantages, sometimes it is preferred to
conduct the usability testing directly in places where users are present and where they
tend to use the product (Barnum, 2011, p. 38).
This type of testing allows a facilitator to perform the test in real environment and to better
understand the conditions, such as lighting, internet connectivity, or workspace, in which
the product is going to be used. Disadvantages are possible disruptions or lack of privacy
during a test (Barnum, 2011, p. 40).
40
Remote testing
Remote testing changes the whole perception of usability tests, as it is no longer a
requirement that a facilitator and users be in the same location. The idea is very simple,
with only screen sharing software and an internet connection it is possible to learn from
users no matter where they are. This type of testing is very flexible, the recruitment of
users is much easier and it produces almost the same results as other means of usability
testing (Krug, 2010, p. 135). However, there are also drawbacks. With remote testing it is
not possible to see the participant, the setup time might require some experience and as it
is not a controlled environment, disruptions might also be a problem (Barnum, 2011, p. 43).
Participants 4.2.2
Usability tests are all about observing users using a particular product and therefore it is
crucial to pick the correct target group to which the product is of most interest. As some
products are designed to be used by people with specific domain knowledge or skill level,
this might provide the first hints about the target group of participants for usability testing.
Carol Barnum suggests that if the study is rather small, including only five to six users, it is
advisable to pick one subgroup from a target audience, create a profile based on this
subgroup and make this the basis for recruiting users.
If a study is bigger, it is possible to pick more profiles that represent the target audience
and lower the number of participants per subgroup, as the probability is rather high that the
results will resemble each other (Barnum, 2011, p. 18).
Another relevant factor to usability testing is the number of participants. Based on
research conducted on six projects by Nielsen and Molich in 1990 it was found that one
single user can find about 35 % of usability issues within a project (Nielsen, 1993, p. 156).
By cumulating these results from multiple users, they were able to achieve a much higher
proportion of usability problems found. The following figure shows the correlation between
the number of participants and the percentage of usability issues found.
41
Figure 24 Correlation between number of users participating on usability test and problems found
Source: Usability testing essentials, Carol Barnum (Barnum, 2011, p. 16)
Based on the Figure 24 Nielsen and Molich defined that the optimal number of users
participating in a usability test is between three and five (Nielsen, 1993, p. 156). According
to them, this number of participants delivers the highest relation between cost and benefits.
Test tasks 4.2.3
Another keyword in the definition of usability is the word “tasks” in the context of
accomplishing them while being observed. It is essential that these tasks represent the
most important features of a product and are relevant to the users that are working with it.
Steve Krug provides a few hints about to how pick suitable tasks for a test and how to
transform them into scenarios that are easily understood by users.
Tasks
According to Steve Krug (Krug, 2010, p. 51) the first step in this process is to write down
the most important tasks that a user can carry out with a product. These tasks should be
small enough that they can be completed within a given time frame, while at the same time
not too small, as they might become too trivial.
The following are good examples for usability testing tasks:
- “Find out when your next class is”
- “Apply for a master’s degree at Technikum Wien”
- “What are the library’s opening hours?”
Scenarios
Next step is to filter these tasks and decide which ones are the most critical or difficult to
use. Once this is done, these tasks need to be transformed into scenarios. Scenarios
42
provide participants with the missing context of a task, motivate users to accomplish them
and are easier to understand and follow. The following is an example of such a
transformation of a task into a scenario:
Task: Apply for a master’s degree at Technikum Wien”
Scenario: You have just finished your Bachelor’s degree and now you are
interested in studying the Master’s degree in Multimedia and
Software development at Technikum Wien. Apply for this program.
Pilot test
After tasks have been filtered and transformed into scenarios, it is advisable to pre-test
these tasks in a pilot test (Krug, 2010, p. 54). The purpose of a pilot test is to make sure
that the tasks are well understood, complete and can be finished within the given time
frame. If not, there is still time to make the necessary adjustments.
Print outs
The last step in preparing tasks for usability testing is to print them out in two formats. One
format is for the users, where each task is written in big font and covers half a page. The
other format is for the observers or the facilitator, where all tasks are printed on one page.
Instead of printing out the test tasks, it is possible to use dedicated usability testing
software such as Morae. Morae supports the whole process of usability testing and one of
the features is saving the tasks into the software. These tasks are than available to the
facilitator, to the observers and are presented to the participants through a session to guide
them (Figure 25).
Figure 25 Morae: dedicated usability testing software – the user is presented with a test task
Source: (TechSmith, Record Automated Sessions with Autopilot, 2012), the author's own
visualization
43
Stages of a test 4.2.4
Once the testing environment has been selected, the tasks chosen and participants
recruited the next step is to start the usability test, which usually runs in four stages –
preparation, introduction, the test itself and debriefing (Nielsen, 1993, p. 187). After the test
has been finished, the next step is to evaluate it.
Preparation
The preparation stage of usability testing ensures that everything is ready for the usability
test to start. Based on the testing environment as well as the equipment used for, the
typical tasks of the preparation stage might include for example making sure that the
required documents are printed out and ready. If a computer is part of the test, all the
software that might distract the participants and is not part of the test should be disabled. If
a webpage is tested, it is advisable to bookmark it to allow quick access. It is also
essential that all the changes made in the previous test are reset before the next user
starts the test.
If possible, it is also recommended to record the session. The recording can include the
audio, the screen capture, the participant himself or any combination of these. The
recordings are capturing the participant’s reactions, emotions and proceeding with the test.
These can later be used for presentation purposes and to highlight the problem sections of
a product.
Introduction
The second phase of a usability test is introduction. During this phase the facilitator, a
person sitting next to a participant leading the testing, welcomes the participant of a test
and explains how the test is going to work. There are many scripts that focus on the exact
wording of the introduction to make sure that nothing important is left out. Some people
prefer to improvise as it promotes more natural behavior in the facilitator. But whether the
instructions are read to the users or said spontaneously, the following topics should
definitely be mentioned:
- Aim – The aim of the usability test is to improve user interfaces and the more input
(positive or negative) given by a user, the better
- Subject - The subject of a usability test is the product and not the participant, so
there is nothing that the user can do wrong
- Participation – The user is participating in the test voluntarily and therefore may
stop the test at any time.
- Time - Provide the approximate duration of the test.
44
- Observers – If there are observers watching the session, the participant should be
made aware of this and explained why it is important that they are being observed.
- Confidentiality – Even if the test is going to be recorded the user needs to be
assured that the recorded data will be kept confidential and only used for the
purpose of usability testing. It may also be recommended to have users sign a
recording consent form
- Questions – Users need to be told that they are free to ask any questions if
anything is unclear, although there is a high likelihood that the facilitator will not be
able to provide the answer during testing as it might influence the test results.
- Specific instructions – This may include any specific instructions about the
equipment used, or other methods used with usability testing
During the introduction phase it is also good to verify the physical set-up of the testing
environment, such as the position of the mouse in the instance of a participant being left-
handed, or the need to adjust the height of a chair. If the session is planned to be recoded,
the recording software should be started. Once all prerequisites have been met the test
itself can begin.
The test itself
In this phase the facilitator walks users through the test by presenting the prepared tasks,
helping them verbalize their thoughts and taking note of the observations made during the
test. At the beginning of every task, the user is given instructions printed out on a piece of
paper. The instructions are read aloud by the facilitator to prevent any misunderstandings.
After this a user is left alone to solve the task. It is essential that the facilitator does not
express his own thoughts or help the users solve the tasks, as this might influence the final
results of the test.
Debriefing
After the final task is completed, the users are debriefed. This might include filling out a
satisfaction questionnaire or asking them to provide additional feedback about the product.
Any additional discussion should be conducted after the questionnaire has been filled out
to avoid the facilitator’s influencing the participant’s feedback. The facilitator then thanks
the user for participating and leads him out of the usability lab. As soon as the user has
left, the facilitator should check that all the forms, questionnaires and/or recordings are
appropriately labeled. After the test the facilitator and the observers (in case they were
present during the testing), write down the most serious usability problems and sort them
according to their priority (Krug, 2010, p. 103).
45
Test Evaluation
The evaluation should take place as close to the testing as possible. The purpose of a test
evaluation is to focus the resources on the most serious usability problems (Krug, 2010, p.
109). To achieve this, first the summarized usability problems are analyzed. Those that are
the most serious are chosen and steps to how they will be solved are proposed. The
decision of which usability issues are the most pressing is best made with the
stakeholders. They know their product and its future course best and therefore are the
most competent to decide which changes are feasible to implement.
Other usability methods 4.3
Although usability testing is the most important method of usability, it is certainly not the
only one. There are various other methods, such as observation, thinking aloud or
questionnaires, which can either be applied separately or combined with other usability
methods and deliver even better results and discover even more usability problems. A few
of them will be shortly introduced in the following sections.
Observation 4.3.1
Observation is one of the simplest methods employed for usability engineering (Nielsen,
1993, p. 207). As the title already suggests, its aim is to observe users as they work with a
product. The observer usually takes notes on the session (also done in the form of a
recording) and tries to avoid interfering with the user during observation. Observation is a
great method for finding out how users use the product in unexpected ways.
Thinking aloud 4.3.2
If observation is one of the simplest methods, thinking aloud is one of the most valuable
methods of usability (Nielsen, 1993, p. 195). The idea behind this method is that users are
asked to verbalize their thoughts the whole time while using the system. This thinking out-
loud method helps the observers and the facilitator to understand what the users are
seeing, what causes most of their problems and how they interpret user interface while
working with the system. Jacob Nielsen (Nielsen, 1993, p. 196) states that “the strength of
the thinking-aloud method is to show what the users are doing, and why they are doing it
while they are doing it in order to avoid later rationalizations.”
46
Questionnaires 4.3.3
Questionnaires come from a category of indirect methods, as they are not directly studying
user interfaces, but are simply asking users for their subjective opinions about a product
(Nielsen, 1993, p. 209). It is conducted in a form where users are asked a set of questions
and their answers are recorded. This method is very well suited to finding out which
features of a product users like or dislike. It can cover a large number of users, as
questionnaires can be distributed via multiple channels such as email, post or in person.
47
5 UnserWein.at – user centered cross-platform
application
This chapter will make use of all the information introduced in the previous chapters. It
focuses on conducting a usability test on a real-world cross-platform mobile application
from the company UnserWein.at. Based on the results, the last chapter of this thesis will
present a guideline for creating user-centered cross-platform applications.
Introduction of the company UnserWein.at 5.1
UnserWein.at (Figure 26) is a young Austrian company established in February 2011 by
Bernhard Gschwantner and Thomas Ungrad. Their product, a mobile application, which is
also called UnserWein.at, is oriented to wine connoisseurs and enthusiasts. This
application is based on the concept of a
virtual wine cellar, where users have
access to an extensive database of
wines and can keep track of the wine
bottles they have in their real-world wine
cellars.
In the year 2012, the company
UnserWein.at started cooperating with
Vievinum - the biggest and most
important Austrian wine event, with more
than 500 national and international wine
producers, importers and distributors
presenting their wines. Based on this
cooperation, UnserWein.at is responsible for the comprehensive presentation of all wine
makers and their wines before, during and after Vievinum. For this purpose a cross-
platform application was created, which can be accessed for free via the following
webpage: www.vievinum.unserwein.at. This application will be used for the purposes of
this thesis. Its interface language is German, but for the purpose of this thesis the author
attempted to translate all terms into English as accurately as.
Vievinum/UnserWein.at application 5.2
The Vievinum/UnserWein.at application is a cross-platform mobile application, which has
been optimized to work on all mobile phones and tablets. It targets wine experts, wine
enthusiasts and people visiting the fair (from here on referred to as users). It shows all the
Figure 26 UnserWein logo
Source: The author's own visualization
48
winemakers and the wines that will be presented at Vievinum. The launch of the
application is planned for May 1st 2012.
At the time when the author started cooperating with the company UnserWein.at (March
2012), the application was in the development phase. The user interfaces had already
been designed, but only partially implemented. This was the stage at which the usability
tests took place. The following pages illustrate this state and describe some of the features
of the Vievinum/UnserWein.at application.
Homepage 5.2.1
The homepage is the first screen that the user can see and interact with (Figure 27). The
company UnserWein.at has chosen a very clear and modern looking user interface.
Figure 27 Homepage
Source: The author's own visualization
49
The dominant place in the upper part of the screen features the Vievinum and
UnserWein.at logo. The UnserWein.at logo is present on all user interfaces and is also a
hyperlink to the home page. The lower part of the home page includes a list view with
further information about UnserWein.at and two menu points – “home” and “about us”.
An unregistered user can search or browse for details of wine producers and wines. The
number in the circle next to the description represents the total number of wine
makers/wines stored in the database.
When searching for a wine maker, a user can either browse by wine region, by hall (where
they will be during the Vievinum), or search for them by name. Wines can be browsed
through based on their region, grape variety or name. The following figure (Figure 28)
shows the content while browsing wineries by hall (left) or wines by region (right).
Figure 28 List of wineries browsed by hall (left) and wines browsed by region (right)
Source: The author's own visualization
50
Wine maker’s page 5.2.2
When looking for a particular wine maker, the user can choose between browsing the
region, halls, or using the search function. The search function also provides the user with
real-time search suggestions (Figure 29) to simplify the input of search terms. This means
that as the user is typing, the letters are automatically compared to the database and the
user can see the results immediately.
Figure 29 Search suggestions
Source: The author's own visualization
Once the user is at the Vievinum fair, he can use another type of input: QR Codes. A QR
Code, short for Quick Response code, is a matrix barcode which contains encoded data.
UnserWein.at has created a distinct QR code for each winery. These QR codes are
present in a booklet that every visitor at Vievinum receives and are also on the tables in the
winemaker’s booths. These QR codes (Figure 30) reference the winemaker’s web page in
the Vievinum/UnserWein.at application. To use a QR code, the user has to have a QR
reader installed on his device.
Figure 30 Sample QR code referencing a wine maker in the application
Source: The author's own visualization
51
Once a user is on the winemaker’s page, an overview of the winery is provided (Figure 31).
He can also see the selection of wines that the wine producer is bringing to Vievinum. A
registered and logged in user can bookmark that particular winery or any one of their wines
which interest him.
Figure 31 A wine maker's page
Source: The author's own visualization
52
Wine page 5.2.3
The wine page (Figure 32) presents the user with a basic overview of all the properties of a
particular wine. These include in the upper part the vintage, region, wine type and quality.
in The lower part of the web page displays all additional information in the form of a list
view. Initially, when the page loads, all list views are collapsed. When the user clicks on
one of the expansion arrows, the content of the list view item becomes visible.
Just as with the wineries, each wine can be bookmarked for later.
Figure 32 A wine page
Source: The author's own visualization
53
Bookmarking winery/wine 5.2.4
A logged in user can bookmark any wine or winery that is of interest to him. There are two
ways this can be done. The user can choose to bookmark a wine or a winery via their
page, where all the details are displayed (Figure 33).
Figure 33 Bookmarking a winery (left) or a wine (right) from the details page
Source: The author's own visualization
The other option is through the listings of wineries or wines. These can be accessed via
the main page, for example when browsing for a particular wine type. This action is marked
by a little green flag on the right side of the screen (Figure 34).
Figure 34 Bookmarking a winery (left) or a wine (right) from the overview
Source: The author's own visualization
Once a wine or a winery has been bookmarked, the user is redirected to a new page. This
page is identical for both winery and wine (Figure 35). Here a user can add a rating, save a
note about the wine/winery and specify details of the bookmark by setting its category to
either “interesting”, “to taste” or “shopping list”. After a user has finished entering notes, he
can confirm the input by pressing the save button at the top of the page.
54
Figure 35 Bookmark pages, where a user can specify additional data about the winery (left)
or wine (right)
Source: The author's own visualization
Additional features 5.2.5
Once a user bookmarks a winery or a wine, he can then manage these lists and view/edit
the additional information that he specified. When this master thesis was compiled, these
screens were not fully implemented and therefore will not be closely examined.
At a later point of development (approx. October 2012) a full integration with the
UnserWein.at product is also planned.
55
Usability test preparation 5.3
UnserWein.at intends to offer their users an application that is easy to learn, efficient to use
and is optimized to work correctly on all mobile platforms. This has had a positive effect on
users, as they are in general more satisfied with the product.
To improve the usability of the Vievinum/UnserWein.at application it was decided to
conduct usability tests on the screens which were presented in the previous section. It is
expected that the usability tests will improve the overall user experience of the application
and help optimize its use on multiple operating systems.
The usability tests were conducted by the author at the beginning of April 2012. The
following sections describe their proceedings.
Testing environment 5.3.1
For the usability testing it was decided to conduct testing in a quiet room with Wi-Fi
connection, a table and two chairs. The following figure (Figure 36) is illustrating one of the
environments where testing took place.
Figure 36 One of the environments where usability testing took place
Source: The author's own visualization
56
Test tasks 5.3.2
The participants received five different tasks. These tasks were carefully chosen to cover
the most important features of the Vievinum/UnserWein.at application. Each task defined a
line of actions that needed to be carried out in order to complete it successfully. This
allowed the comparison of the actions that the participants took with the planned
proceedings and it could be clearly seen if they differed in any way. Some actions were
dependent on each other. Before the first task, users were asked to open their web
browser and enter the www.vievinum.unserwein.at address.
1. Test Task 1 - Imagine that you would like to visit the winemaker Peter Skoff at
the Vievinum fair. Have a look at his details page. In which hall is his booth
located?
This is a relatively simple task that aims at making the users familiar with the
application. It observes how users search for a particular winemaker. It is
also important to see whether the search suggestions are correctly
displayed on the screen and whether the users are able to locate the
information about the hall.
Correct steps to solve this task:
o Start on the main page
o Invoke the search function
o Enter the name of the winemaker
o Choose Peter Skoff from search suggestions
o Locate the hall
2. Test Task 2 – Search for all other winemakers which are going to be in the
same hall as Peter Skoff. Find a winemaker of your choice and bookmark his
winery into your favorites.
This task builds upon the previous task. Its aim is to see if users can identify
the hall name as a hyperlink which redirects users to the list of all other
winemakers which are located in the same hall. Once another winemaker
has been picked, the task is to bookmark him. There are two ways how this
can be done - via the overview, or through the winemakers’ details page.
Users are observed to see which action they chose.
One way to solve this task:
o Tap on the hall name
o Choose any winemaker from the list
o Open the winemaker’s details page
o Bookmark the winemaker
Another correct way to solve this task:
57
o Tap on the hall name
o Choose any winemaker from the list
o Bookmark the winemaker directly from the overview
3. Test Task 3 – At the Vievinum fair you have just visited the winemaker XYZ
and you are very interested in his wines. You just noticed the following QR
code on his table <image>. Scan this image and have it show the associated
content.
This task was designed to see how many users recognize a QR code and
know how to handle it. For this task users need a QR reader on their device.
If they do not have one installed, they are provided with instructions on how
this can be done. These instructions are placed around the fair and are also
available in the booklets distributed at the fair.
Correct steps to solve this task:
o Start the QR reader
o Scan the image
o Open the link
4. Test Task 4 – Choose any red wine from Tom Dockner and find out the food
pairing recommendation for the wine as well as its residual sugar.
This task is dependent on the previous one. All entries in the
Vievinum/UnserWein.at database specify the wine type -- red, white, rose or
sweet. This specification is marked on the left side of each panel by an
appropriate color – red, green, yellow and pink. The aim of this task is to see
whether users understand this correlation. The second half of this task
focuses on finding the correct information about the wine.
Correct steps to solve this task:
o Start on Tom Dockner’s page
o Choose a red wine
o Expand the list view analysis data
o Expand the list view food recommendation
58
5. Test Task 5 – You would like to bookmark the red wine you have previously
chosen. Specify the bookmark category to one that suggests that you want to
buy it. Give the wine the best possible rating, write a note that says
“amazing” and save your bookmark
This task is specified to improve the bookmark page. Users are observed to
see whether they understand the naming of individual bookmark categories,
and which rating is the best one.
Correct steps to solve this task:
o Start on the wine page of the previously chosen wine
o Tap the bookmark button
o Choose “shopping list”
o Move the slider to number 5
o Type in the message
o Tap the “save” button
Participants 5.3.3
All participants who took part in the usability testing comply with the definition of usability,
which means that the product Vievinum/UnserWein.at is of interest to them. The target
group for the usability testing consists of users who are wine enthusiasts. Usability tests
were conducted on the users’ own smartphones. Participants were aware of this fact
during the recruitment. The reason for this decision was that the users are most familiar
with their own devices and mobile operating systems. This puts the focus on the
application and not on problems which might be caused by an unfamiliar device or
platform.
Additionally, for the purpose of testing the application on different platforms, three
subgroups were defined – Android, iPhone and Windows Phone users. The usability test
was conducted with four participants from each subgroup, making a total of twelve
participants. Each subgroup consists of two female and two male testers. The following
Figure 37 shows the age distribution of the participants.
Figure 37 The age distribution of participants
Source: The author's own visualization
59
Combining usability methods 5.3.4
Usability testing is one of the most important methods of usability engineering, but it is
certainly not the only one. Jacob Nielsen suggests that it is best to combine different
methods to optimize the results. This creates a higher probability that more usability issues
will be uncovered with each method (Nielsen, 1993, p. 226). The usability tests of the
Vievinum/UnserWein.at application were combined with observation and the thinking aloud
- method. The fundamentals of these methods are described in section 4.3.
Additionally, users were asked to fill out a questionnaire. This usability method is best
suitable to gauge the users’ satisfaction with the product. First users were asked to specify
their gender, age and the smartphone model that they used for the test. This enabled the
creation of an approximate profile for each user. This part was followed by eleven
questions, where the answers ranged from 1 to 4 with 1 representing “doesn’t apply at all”
and 4 as “applies fully”.
The first three question of the questionnaire focused on the users’ acceptability of cross-
platform applications. The rest of the questions allowed the users to express their
subjective opinions about the Vievinum/UnserWein.at application. A complete
questionnaire translated into English can be found in Chapter 12.
Usability test execution 5.4
Once the usability test has been prepared and the participants recruited and scheduled for
testing, the next step was to execute the plan.
Preparation 5.4.1
Before every test, the user was contacted to confirm the time and place of the usability
test. It was verified that the environment which the participant chose was suitable for
testing. Users were reminded that the usability test would be conducted on their own
mobile devices.
Before the test the facilitator set up a computer where he would take notes about his
observations during the test. Additionally the tests were recorded as audio. For each
participant the facilitator prepared a consent form for the recording as well as the
questionnaire. Additionally the facilitator printed each task on a separate piece of paper.
These were placed on the table in the order in which they were to be presented to the
participant. The following figure illustrates one of the environments where testing took
place.
60
Introduction 5.4.2
At this stage the facilitator welcomed the participant and he was asked to sit down. It was
essential that the facilitator had a good view of the display. Therefore if the user was right
handed, he was sitting on the left side next to the facilitator and vice versa.
In the next step the participant became acquainted with the proceedings of the usability
test. This included explaining the aim, the subject of the usability test and their volunteering
participation. The test was estimated to take about fifteen minutes. There were no
observers watching the session, therefore it was irrelevant to mention this possibility. Each
usability test was to be recorded as audio; therefore users were asked to sign a consent
form. In this form they grant the facilitator permission to record them during the session.
The exact wording of the consent form can be found as an attachment at the end of this
thesis. Once the participant signed the form, the facilitator started the recording software.
Additionally the participant was told that he could ask questions anytime, although it might
not always be possible for the facilitator to answer them right away. The user was asked to
think aloud and verbalize all his thoughts so that the facilitator could better understand his
interpretation of the user interfaces.
Before the test the facilitator asked the participant to connect to the Wi-Fi and start a web
browser on his smartphone.
The test 5.4.3
Before the facilitator started with the first task he asked the user to visit the
www.vievinum.unserwein.at webpage. The web address was handed out on a piece of
paper to avoid mistyping. The user was asked to look at the main page and without tapping
anything, provide some thoughts about the product – what is it used for, the structure and
the layout. This was supposed to make the participant familiar with the product.
Next the facilitator started presenting the individual tasks. First the task was placed in front
of the user and read aloud by the facilitator. Then the user was asked to begin the task.
During testing the facilitator helped the user to verbalize his thoughts and took notes of his
observations.
61
Debriefing 5.4.4
After completing all tasks the user received a questionnaire. Following the questionnaire
the user was asked if he had any additional comments, improvement proposals, or
questions about the system which were then immediately discussed. Afterwards the
facilitator stopped the recording and thanked the user for his participation.
Test results 5.5
This section will present the results of the usability tests conducted on the
Vievinum/UnserWein.at application.
First impressions of Vievinum/UnserWein.at 5.5.1
At first the participants were asked about their impression of the Vievinum/UnserWein.at
product and encouraged to comment on what they thought it was used for, as well as their
impression about the structure, color composition and layout of the product.
All participants were able to identify that the product had something to do with winemakers
and wine. Both, UserWein.at and Vievinum were correctly identified as partners on this
product. However, some participants were not familiar with the company Vievinum and
were looking for a brief description. In general the participants liked the fact that the
application structure was simple and described it as very neatly arranged. On all operating
systems – Android, iPhone and Windows Phone the font size was described as suitable.
Some participants also commented on the color composition. Five participants expressed
the opinion that the colors were very well fitted to the topic of wine and the other four
commented that they would have liked to see more colors.
Three participants also correctly recognized the numbers in the circle next to the
winemaker and wine categories as the number of entries saved in the database. They also
pointed out that the four-digit number next to the wines was touching the borders of the
surrounding circle, which made it less aesthetically appealing.
Task 1 evaluation 5.5.2
Imagine that you would like to visit the winemaker Peter Skoff at the Vievinum fair.
Have a look at his details page. In which hall is his booth located?
All participants were able to solve this task without any problems. All users used the search
function, either typing in the first or last name of the winemaker. In both cases the system
delivered the same results – namely Peter Skoff. Participants very much appreciated the
62
search suggestions. Two participants, one using a Windows Phone 7 device (Samsung
Omnia 7) and one Android user (Galaxy Nexus) commented on the fact that the keyboard
was overlaying most of the search suggestions and that they were able to see only one
result (Figure 38). In order to see the rest they had to either scroll down or deactivate the
virtual keyboard. They suggested that the height of the search suggestion field should be
decreased. Once the participants visited the winemaker’s page, they all were able to find
the hall where his booth was located.
Figure 38 Search suggestions - when the keyboard is activated the users are able to see only one
search result
Source: The author's own visualization
Task 2 evaluation 5.5.3
Search for all other winemakers which are going to be in the same hall as Peter
Skoff. Find a winemaker of your choice and bookmark his winery into your favorites.
One of the aims of this task was to find out if the participants could correctly identify the
hyperlink to other winemakers which were located in the same hall as Peter Skoff (Figure
39).
Figure 39 The word "Zeremoniensaal" illustrates how a hyperlink is marked
Source: The author's own visualization
63
Seven out of twelve participants were able to recognize the hyperlink; the rest of the users
went back to the main page and browsed the halls to find the one where Peter Skoff was
located. What was interesting was that those participants who chose to go back to the
main page stated in the debriefing that this task was very easy and the system supported
them very well in solving it. This suggests that even though they did not choose the
simplest method, all additional steps to solve it were self-explanatory and did not require
any additional thinking.
The second part of this task was to bookmark a winemaker from the previous list. There
were two ways this could be accomplished. Four participants bookmarked the winemaker
directly from the overview; the rest of the participants went via the winemaker’s page. Two
participants who chose to go through the details page mentioned that they saw the green
icon in the overview, but that they could not associate any action with it. They were missing
a label.
Task 3 evaluation 5.5.4
At the Vievinum fair you have just visited the winemaker XYZ and you are very
interested in his wines. You just noticed the following QR code on his table
<image>. Scan this image and have it show the associated content.
All participants were able to identify a QR code and tell how it could be used. Ten out of
twelve participants stated that they had already used this type of input in the past.
To solve this task the participants had to use a native application on their phone to see the
content of the QR code. Four participants first searched for the application to find a QR
reader or some instructions; the rest had already assumed at the beginning that a native
application will be required.
Out of all the participants, seven had a QR reader installed on their mobile phones (one
Android, two iPhones and all Windows Phones as a QR reader is installed by default).
Those who did not have a QR reader installed on their phone were provided with
instructions on how to get one. These same instructions will be readily available at the
Vievinum fair.
All participants shared the opinion that the QR code was a great alternative as an input, but
they did not like the fact that they had to use another application for it. Some of them
additionally stated that they expected more support from the application when it came to
how to use it.
64
Task 4 evaluation 5.5.5
Choose any red wine from Tom Dockner and find out the food pairing
recommendation for the wine and its residual sugar.
All participants were able to identify the wine color based on the stripe color next to the
wine. The only confusion that arose was caused by the yellow stripe marking sweet wines
(Figure 40), as it was placed in the middle of the whites wines (marked with the color
green).
Figure 40 The sweet wine (marked yellow) misplaced between white wines (marked green)
Source: The author's own visualization
On the wine page the wine properties were saved in the list view. Residual sugar was
saved in the “analysis data” and food recommendations could be found under the list view
with the same title. To find the residual sugar five participants first tried the list view with
the title “wine description”, but their second guess was analysis data. These participants
stated that they did not see themselves as wine experts and therefore would not have seen
this as an issue. The food recommendation did not cause any problems.
Task 5 evaluation 5.5.6
You would like to bookmark the red wine you have previously chosen. Specify the
bookmark category to one that suggests that you want to buy it. Give the wine the
best possible rating, write a note that says “amazing” and save your bookmark.
None of the participants had any problems bookmarking the wine. Once on the page, all
users were able to identify the correct category, called “shopping list”.
One area where some problems did occur was the rating part of the task. Two users
identified the value 1 as the best possible rating. They later stated that they overlooked the
description “stars”. Their suggestion was that the slider should be replaced with stars to
avoid this confusion. Also, the slider appeared not to be working on any of the Windows
Phone devices. The slider reacted only to tapping and not sliding.
65
Writing a note did not cause any problems and all participants solved this task
successfully. One user suggested that the background of the note field should be changed
from grey to white, as the current color gave the impression that the field was deactivated.
In general, the participants did not have any problems finding the save button, although
some stated that it ought to be located at the bottom of the page. Others mentioned that
they did not understand why saving was necessary at all, as they expected that the
bookmark would be automatically saved.
Questionnaires evaluation 5.5.7
This section evaluates the questionnaires which were distributed to the participants after
the usability test in order for them to express their subjective opinions about the product
and cross-platform applications in general. Error! Reference source not found.
summarizes the assessment of points given by the participants.
The first three questions were designed to find out how people perceive cross-platform
applications in general. Question One: “With a cross-platform application I can perform the
same tasks as with a native application” scored on average 2.8 points, which is the lowest
score out of all the questions. Just as a reminder, 1 represents “doesn’t apply at all”, and 4
“applies fully”. This score suggests that users are aware that the capabilities of cross-
platform application are not the same as those of native applications. This finding is also
supported by the third task in the usability test, where the QR reader was not implemented
in the application directly. To complete the task, the participants had to use an external
application which was described by participants as “not the most optimal solution”.
The second question: “If a cross-platform application is well implemented, I don’t care if I
use a native or a cross-platform application” scored on average 3.3 points, which is a
relatively high score. From this result it can be deduced that although users believe the
capabilities of cross-platform applications are not as good as those of native applications,
they are willing to accept cross-platform applications if it is well implemented.
The last question “I always prefer a native application” received 2.9 points. This result
concludes that if a native application is available, there is a high probability that users are
going to choose it over a cross-platform solution. However, it is not to be underestimated
that three of the twelve participants answered that this did not apply at all.
The rest of the questions focused on the Vievinum/UnserWein.at application. These
questions were designed in such a way as to find out the participants’ opinions on the color
composition, layout and structure, as well as how they perceived the application.
66
In the questionnaire the participants rated the layout, the font size and easy-to-understand
notations in the application very highly. This suggests that the Vievinum/UnserWein.at
team had made the right decision in choosing a fluid design for their user interfaces as they
adjusted to the different display resolutions very well.
The users also evaluated the application as nicely arranged, modern and of high quality,
giving it an average rating of 3.7 points. This suggests that the product is a well
implemented cross-platform application. The lowest score, 3.4 points, was given to the
color composition of the Vievinum/UnserWein.at application. The reasons for this were
supposedly the comments that the participants already provided during the testing, where
they mentioned that the color composition was too simple and could have done with the
use of more colors.
67
Question
P 0
1
P 0
2
P 0
3
P 0
4
P 0
5
P 0
6
P 0
7
P 0
8
P 0
9
P 10
P 11
P 12
Average
With a cross-platform application I can perform the same tasks as with a native application.
2 4 3 2 3 3 2 1 4 4 4 2 2.8
If a cross-platform application is well implemented, I don’t care if I use a native or a cross-platform application
3 4 4 3 3 3 3 2 4 4 4 2 3.3
I always prefer a native application 3 1 3 3 4 4 4 4 1 1 3 4 2.9
Layout of the Vievinum/UnserWein.at application is well displayed on my mobile phone
4 4 4 3 4 4 4 4 4 4 4 4 3.9
The font size is exactly right 4 4 4 4 4 4 3 4 2 4 4 4 3.8
The application is neatly arranged 3 4 4 4 4 4 4 3 3 4 4 3 3.7
The information and notations of the application are easy to understand
4 4 4 4 4 4 4 3 4 4 4 4 3.9
The application appears modern 3 3 4 4 4 4 4 4 4 3 4 3 3.7
The color composition is attractive 2 4 4 4 4 4 4 4 2 4 1 4 3.4
The design fits well with the content of the application
2 4 4 4 4 4 4 4 3 4 2 4 3.6
The application is of high quality 3 4 4 4 4 4 4 4 4 4 2 3 3.7
Table 6 The distribution of points on the questionnaires
Source: The author's own visualization
68
Evaluation of the discussions 5.5.8
After all tasks had been completed and the questionnaires were successfully filled out, the
participants had the opportunity to ask questions and offer up additional insights about the
application. This section will highlight the most important additional improvement
proposals.
“About unserwein.at”
The lower part of the application contains a list view entitled “About unserwein.at”, which is
expanded by default. Participants have noted that this is not necessary as it takes up too
much space on the screen. The problem is that even after the list view is collapsed, once
the page reloads the list view loads again as expanded.
Wine vintage
The vintage is definitely one of the most important properties of a wine. According to two
participants, the vintage on the wine details page is too close to the upper border, making it
hard to see.
Bookmarking page
The majority of the improvement proposals from the participants were concerning the
bookmarking page. The participants did not like the fact that a wine or winemaker could
have only one category specified. A good example is a wine that the participant finds
“interesting” and would like to put it on his “shopping list” as well. At the moment this is not
possible as the categories are in the form of radio buttons.
Some confusion was also caused by the “save” button. The participants did not understand
at which point the bookmark was saved. For example, if the participant did not wish to
specify the category, the rating or add a note, the participants did not know if it was also
necessary to press the save button.
69
New design proposal 5.6
The following pages will introduce planned changes to the user interfaces. The aim of
these changes is to improve the overall usability of the product.
Unserwein.at logo (Figure 41)
Current design – unserwein.at logo is in gray scale
New design – userwein.at logo should be used in its original colors – black and
dark red
Reason – the original logo improves the brand recognition and adds some color to
the user interfaces making them more appealing
Figure 41 Unserwein.at logo - The current design (left) and the new proposal (right)
Source: The author's own visualization
“About unserwein.at” list view (Figure 42)
Current design – list view “About unserwein.at”, visible on all user interfaces, is
expanded by default
New design – list view will be collapsed by default and visible only on the main
page
Reason – collapsing the list reduces scrolling, removing it from all other user
interfaces except the main page eliminates clutter
Figure 42 About unserwein.at list view - the current design (left) and the new proposal (right)
Source: The author's own visualization
70
About Vievinum 2012 list view (Figure 43)
Current design – no description of Vievinum is available
New design – a short description of Vievinum fair is added at the bottom of the
main page in form of a list view
Reason – users can better understand the purpose of the application
Figure 43 About Vievinum 2012 list view - the current design (left) and the new proposal (right)
Source: The author's own visualization
Bottom menu (Figure 44)
Current design – a menu with “home” and “about us” buttons
New design – the menu at the bottom will be completely removed
Reason – menu is redundant and completely overlooked by users
Figure 44 Bottom menu - the current design (left) and the new proposal (right)
Source: The author's own visualization
71
Number of entries (Figure 45)
Current design – four digit numbers do not fit into the circle
New design – the font size of the numbers will be minimally decreased
Reason – even four digit numbers will fit neatly within the circle
Figure 45 Number of entries - the current design (left) and the new proposal (right)
Source: The author's own visualization
Vintage (Figure 46)
Current design – the wine’s vintage is too close to the upper border
New design – the wine’s vintage is moved down by a few pixels
Reason – vintage is easier to recognize
Figure 46 Vintage - the current design (left) and the new proposal (right)
Source: The author's own visualization
72
Bookmarking page (Figure 47)
Current design – only one bookmark category possible, rating in form of a slider,
“save” button
New design – multiple bookmark categories via toggles, slider in the form of stars,
save button will be completely removed
Reason – a user can bookmark multiple categories, slider cannot be used properly
on Windows Phone devices, save button caused confusion
Wine order (Figure 48)
Current design – wines are not correctly ordered
New design – wines will be sorted based on their color – first white wines with
green label, than rose with pink, than red wines with red label and last sweet wines
with yellow label
Reason – wine are easier to find, because the sorting is consistent
Figure 48 Wine order - the current design (left) and the new proposal (right)
Source: The author's own visualization
Figure 47 The bookmarking page - the current design (left) and the new proposal (right)
Source: The author's own visualization
73
Winemaker’s webpage (Figure 49)
Current design – winemaker’s webpage is a part of the bottom menu
New design – webpage link will be placed in a separate list view
Reason – Bottom menu got eliminated from the application
Figure 49 Winemaker's webpage - the current design (left) and the new proposal (right)
Source: The author's own visualization
Additional improvement proposals 5.7
The reader might be wondering why some requests from participants have not been
implemented - such as decreasing the height of the search suggestions, or making the
hyperlinks more visible. After all, these improvement proposals were identified by some
users as desirable.
The reason for this is that the content of an application can always be interpreted in many
ways. What one user experiences as a perfectly usable application, can be perceived
completely differently by another user. This makes it somewhat difficult to satisfy the
requirements of all users. It is up to the stakeholders to decide which proposals will be
taken into consideration in order to improve the usability of a product and the above
mentioned suggestions were chosen as those with the highest priority. For example, it was
decided that the hyperlinks would not be changed in any way because although some
participants did not recognized them as such, the other path of finding the desired
information that they chose did not require any additional thought or thorough searching.
The following figure (Figure 50) illustrates the proposed changes to user interfaces for
Vievinum/UnserWein.at.
74
Figure 50 Proposed changes to user interfaces for Vievinum/UnserWein.at
Source: The author's own visualization
75
6 Guideline for creating a user-centered cross-
platform mobile application
This chapter presents a guideline for creating user-centered cross-platform mobile
applications. This guideline is based on an observation, usability tests conducted on the
Vievinum/UnserWein.at application and the author’s experience from previous projects.
Additionally, some principles from the general usability guideline, introduced in chapter
4.1.1, are especially important for cross-platform applications. These will be pointed out
and more closely examined in this chapter.
Fluid design
When designing a cross-platform mobile application the user interface has to support the
highest possible number of different screen resolutions. To achieve this, the application
should support fluid design, which is much more flexible than fixed design. Fluid design
allows the content to adjust to the screen size of a device and therefore can optimize the
user interfaces on multiple resolutions and devices.
Simple user input
User input on a mobile device requires a completely different approach to common desktop
applications, where precision is driven by a mouse and a keyboard. The primary input
method for smartphones is a touch screen, which is typically quite restricted in terms of
size. Native applications also have the advantage of using sensors to some extent, but
these are usually not available to cross-platform applications. This is one of the reasons
why designers should pay extra attention to user input on cross-platform applications.
This can be done by simplifying forms and asking the user only for information that is of
high priority. Login and registration can also be simplified by integrating services such as
Facebook or Twitter, which allow users to sign in using these portals or their already
cached credentials. Cross-platform applications can use location-based services and
therefore, if suitable, this feature should be integrated as well.
Where direct user input is the only option, controls should be finger-friendly and allow at
least 7 mm between individual elements. Additionally, features such as search suggestions
and autocomplete reduce the number of taps required.
76
One task per screen
The individual screens should be planned in a “one task per screen” manner. This means
that the user is presented with only one idea per user interface and any secondary features
or actions should be only one tap away. This allows users to focus on the task at hand and
make the best use of the limited display capacity of the device. Splitting content via
multiple interfaces is not advisable as users might get lost in navigation.
Navigation
Navigation is one of the key elements to a well usable cross-platform application. Users
should always have a way of knowing where they are at any given moment; therefore each
subpage must have a title. Every interface should also include a “home” button – typically
in the form of a logo or icon placed in the upper left corner of the application.
The home screen displays only the main actions that the user can perform, and any
additional tasks are shown individually based on the context of a subpage. Navigation
should never contain more than four sublevels as any more subdivisions may cause
confusion. The forward navigation is to be done by using elements contained within the
interfaces, the back navigation via browser or hardware buttons.
Clear feedback on progress
The user must be informed about the progress and different states during which the
system might appear to be inactive. Clear feedback on progress is particularly important in
cross-platform applications as the response time is more dependent on factors not in the
developer’s control, such as internet connectivity or hardware specifications of the device.
Additionally the application should always clearly indicate that an element has been
tapped, for example by highlighting the control in a different color. This is especially
important as a user has less control of what he taps with his finger due to occlusion of the
touch display while tapping.
Colors and contrasts
Users use devices with different display qualities or brightness settings. In order to
maximize the readability of content, cross platform applications should always use solid,
bold colors with high contrast and no gradients. The color scheme should be consistent
throughout the whole application. Colors can also be used to add meaning to user interface
items such as distinguishing the wine type through different colors.
77
No native elements
User interface designers of a cross-platform application should always keep in mind that
the application might be used on any available mobile platform. Therefore these
applications have to be designed in a way that no design elements or interactions from one
particular platform, such as context menus or specific navigation paradigms are used. If
such elements are used, users on other platforms might not be well served with such
interactions; the consequence being a worse user experience and usability of an
application leading to lower user satisfaction.
78
7 Discussion
This is the last part of this thesis and it is divided into two blocks: research questions and
future perspectives. The first one will answer and summarize the research questions which
were stated in the introduction. Additionally the author will critically evaluate the findings of
this thesis. The second, titled “future findings”, discusses the prospective direction of
cross-platform applications in general and the future development of the
Vievinum/UnserWein.at application.
Research questions 7.1
Which mobile operating systems are the most common?
The first question was answered based on a report released in December 2011 by the
market research company IDC. This report states that the current market leader is Android
with 49% of the market share, followed by iPhone (18.2%), Symbian (16.4%), Blackberry
OS (11.1 %) and Windows Phone (1.9%).
The future estimation again puts Android as the market leader at 46.5%. However, the IDC
delivers a surprising estimation with the Windows Phone operating system, predicting it to
take over iPhone’s second place in 2015 with over 20% of the market share. The reason
for this is the argument that Nokia has chosen Windows Phone as the main platform for
their smartphone devices.
The author believes that there is a high probability that Windows Phone will gain significant
market share, albeit not to the extent that IDC predicts, as the current sale numbers of the
first Nokia/Microsoft devices do not suggest such development.
What are the advantages and disadvantages of cross-platform application
development compared to native application development?
Extensive literature research was the main method used to find the answer to this
question. Cross-platform application has the following advantages: it is easily portable,
uses centrally managed distribution, has low friction deployment and can be used on
multiple platforms. In contrast to this, a native application has access to all sensors, can be
used in disconnected mode and uses native user interfaces that provide a better user
experience.
What type of application is preferred by end-users — cross-platform or native?
The purpose of this question was to find out the acceptability of cross-platform
applications. To find an answer to this question the author used a questionnaire where
twelve participants answered the following three questions - “With a cross-platform
application I can perform the same tasks as with a native application”, “If a cross-platform
79
application is well implemented, I don’t care if I use a native or a cross-platform application”
and “I always prefer a native application“. Answer possibilities ranged from 1 to 4, where 1
represents “doesn’t apply at all”, and 4 “applies fully”.
The answers suggest that users are aware of the fact that the capabilities of cross-platform
applications are not identical to those of native applications. However, if the cross-platform
application is implemented correctly the users are ready to overlook these limitations. Yet ,
the interviewed users answered that when both types of applications are available they are
more likely to choose the native application.
The author would like to add that only twelve users participated in this study. For better
results on this research question the author suggests using at least thirty participants to get
a more representative result.
Which usability principles should be followed when designing a cross-platform
application for mobile devices?
This research question was answered based on the usability test, which was conducted on
a real-world cross-platform application: Vievinum/UnserWein.at. Additionally, the author
used previously gained knowledge from past projects coupled with observations of user
interactions with web based applications. The result was a guideline for creating user
centered cross-platform applications. This guideline contains the following seven points:
fluid design, simple user input, one task per screen, navigation, clear feedback on
progress, colors and contrasts, and finally also no native elements.
The author believes that these points cover the most important aspects of creating a user
centered cross-platform application and, if followed correctly, will significantly improve the
overall usability of the resulting user interfaces.
Future perspectives 7.2
The focus of this thesis is on cross-platform applications. Their main advantage over native
applications is that they run on any operating system, as they are displayed in a web
browser. At the moment three major operating systems – Android, iPhone and Symbian,
share over 83.6 percent of the smartphone market, and it may therefore still be profitable
for software companies to develop native applications for each of these platforms.
However, there are other companies on the smartphone market and it is likely that new
operating systems will join it in the coming years. This might result in a different distribution
of market shares in the future, as well as higher number of operating systems needed to
reach the same market coverage as today when developing native applications. Based on
80
these assumptions the author expects software companies to have a higher tendency to
focus on the cross-platform approach.
Cross-platform applications 7.2.1
Therefore the question is: How is cross-platform application development going to evolve
in the coming years to increase its competitiveness? The biggest disadvantage of web
based applications is the inability to control the sensors. The World Wide Web Consortium
(W3C) is responsible for releasing standard application programming interface (API) that
allow access to device’s sensors via the web browser. At the moment only geo location is
available for use on all devices. According to the latest summary released by W3C in
February 2011, some work on additional sensor support, such as accelerometer or camera
has been initiated, although, over a year later (May 2012) there have still been no tangible
results. Another important aspect of sensor support for cross-platform application is that
even if sensor integration is made possible, the security aspects (e.g. sensitive data
revealed to potentially harmful application) of this solution will always remain questionable.
An interesting alternative to standard web based applications are cross-platform native
development frameworks such as Phone Gap. These frameworks, the author believes,
may be the future of cross-platform application development because they combine the
advantages of cross-platform applications with those of native applications.
Phone Gap compiles the application’s code, written in JavaScript, HTML and CSS, and
creates a native application, which can be deployed on individual platforms. Phone Gap
currently supports Android, iPhone, Windows Phone, Blackberry, Bada, webOS and
Symbian. Such an application can run on all platforms while software companies have to
write code only once and still have access to all sensors of a device. The disadvantage is
that the application is not going to look native on any of the platforms as it remains at its
core a cross-platform application designed as a web page.
Vievinum/UnserWein.at application 7.2.2
The Vievinum/UnserWein.at application has benefited greatly from the usability testing
conducted. Even though the proposed changes were relatively small, they contributed
positively to the overall usability of this application and therefore increased user
satisfaction.
In general it is advisable to plan new usability testing after the proposed new design has
been implemented in order to compare how users react to the changes of the new user
interfaces. To ensure that the Vievinum/UnserWein.at application meets the highest
usability standards the author and the company UnserWein.at have agreed to ongoing
81
cooperation and the continuation of usability tests based on the new design, which are to
be scheduled in the near future.
As for the future of the Vievinum/UnserWein.at, the author believes that as long as QR
code reader remains an important component of user input, the use of a native application
is recommended. Using the camera sensor for scanning QR codes requires the use of
another application and therefore lowers the overall user experience in a cross-platform
application. The stakeholders confirmed that in later development stages of the
Vievinum/UserWein.at application this option will be considered.
82
8 Bibliography
Allen, G., 2012. Beginning Android 4. New York, NY, USA: Apress.
Allen, S., Graupera, V. & Lundrigan, L., 2010. Pro Smartphone Cross-Platform
Development: iPhone, BlackBerry, Windows Mobile and Android Development and
Distribution. New York, NY, USA: Apress.
Alto, P., 2012. Smart phones overtake client PCs in 2011. [Online]
Available at: http://www.canalys.com/static/press_release/2012/canalys-press-release-
030212-smart-phones-overtake-client-pcs-2011_0.pdf
[Accessed 6 April 2012].
Apple Inc., 2012. iOS Human Interface Guidelines. Cupertino, CA, USA: Apple Inc..
Barnum, C. M., 2011. Usability Testing Essentials. Burliington, MA, USA: Elsevier.
Betts, D. et al., 2010. Windows Phone 7 Developer Guide. s.l.:Microsoft Press.
David, M., 2011. Building Webside with HTML5 to Work with Mobile Phones. Oxford, UK:
Elsevier Inc..
Drake, S. D., Stofega, W., Llamas, R. T. & Crook, S. K., 2011. Worldwide Smartphone
Mobile OS 2011-2015 Forecast and Analysis, s.l.: IDC.
Firtman, M., 2010. Programming the Mobile Web. Sebastopol, CA, USA: O'Reilly.
Fling, B., 2009. Mobile Design and Development. Sebastopol, CA, USA: O'Reilly Media,
Inc..
Google Inc., 2012. Menus. [Online]
Available at: http://developer.android.com/guide/topics/ui/menus.html
[Accessed 11 May 2012].
Google Inc., 2012. Metrics and Grids. [Online]
Available at: http://developer.android.com/design/style/metrics-grids.html
[Accessed 24 April 2012].
Google Inc., 2012. Screen Sizes and Densities. [Online]
Available at: http://developer.android.com/resources/dashboard/screens.html
[Accessed 24 April 2012].
International Organization for Standardization, 1998. Guidance on Usability. s.l.:ISO 9241-
11.
Krug, S., 2010. Rocket Surgery Made Easy. Berkeley, CA, USA: New Riders.
83
Lee, H. & Chuvyrov, E., 2010. Beginning Windows Phone 7 Development. New York, NY,
USA: Apress.
Microsoft Corporation, 2012. Interactions and Usability with Windows Phone. [Online]
Available at: http://msdn.microsoft.com/en-us/library/hh202889(v=vs.92).aspx
[Accessed 24 April 2012].
Nielsen, J., 1993. Usability Engineering. Orlando, FL, USA: Academic Press.
Olson, S., Hunter, J., Horgen, B. & Goers, K., 2012. Professional Cross-Platform Mobile
Development in C#. Indianapolis, IN, USA: John Wiley & Sons, Inc..
Ostrander, J., 2012. Android UI Fundamentials. Berkeley, CA, USA: Peachpit Press.
Petzold, C., 2010. Programming Windows Phone 7. Redmond, WA, USA: Microsoft Press.
Picchi, A., 2011. Pro iOS Web Design and Development: HTML5, CSS3, and JavaScript
with Safari. New York, NY, USA: Apress.
Pogue, D., 2011. IPhone: the mission manual. 5th ed. Sebastopol, CA, USA: O'Reilly.
Rodger, R., 2012. Beginning Mobile Application Development in the Cloud. Indianapolis,
IN, USA: John Wiley & Sons, Inc..
TechSmith, 2012. Record Automated Sessions with Autopilot. [Online]
Available at: http://www.techsmith.com/tutorial-morae-record-automated-sessions.html
[Accessed 15 May 2012].
84
9 Table of Figures
Figure 1 Trip Advisor native applications on iPhone (left), Android (middle), and Windows
Phone 7(right) Source: The author’s own visualization .......................................... 14
Figure 2 Native application – advantages Source: The author’s own visualization ............ 15
Figure 3 Native application – disadvantages Source: The author’s own visualization ........ 16
Figure 4 Web Based mobile version of youtube.com on Windows Phone (left), iPhone
(middle) and Android (right) Source: The author’s own visualization ..................... 17
Figure 5 Cross-platform application – advantages Source: The author’s own visualization
.............................................................................................................................. 17
Figure 6 Cross-platform application – disadvantages Source: The author’s own
visualization ........................................................................................................... 18
Figure 7 Four Android phones with their display resolution illustrated in the figure. From left
to right – screen size categories extra-large, large, normal and small Source: The
author's own visualization ...................................................................................... 23
Figure 8 Screen size of iPhone 3GS (left) and 4S (right) Source: The author's own
visualization ........................................................................................................... 24
Figure 9 Screen size of Samsung Omnia 7 (Windows Phone operating system) Source:
The author's own visualization ............................................................................... 24
Figure 10 Various resolutions of mobile devices in portrait mode Source: The author's own
visualization ........................................................................................................... 25
Figure 11 Low-density display on iPhone 3GS (left) vs. high-resolution display on iPhone 4
(right) Source: (David, 2011, p. 7) .......................................................................... 26
Figure 12 Android devices with low, medium and high density screens. They illustrate the
inability to correctly scale the content on high density displays when dimensions are
defined in pixels. Source: The author's own visualization ....................................... 28
Figure 13 eBay web application in portrait view Source: The author's own visualization ... 29
Figure 14 eBay web application in landscape mode Source: The author's own visualization
.............................................................................................................................. 29
Figure 15 On-screen and hardware keyboard Source: The author's own visualization ...... 31
Figure 16 Android’s on-screen buttons on Galaxy Nexus and hardware buttons on
Motorola Droid Source: The author's own visualization .......................................... 32
Figure 17 iPhone Home Button Source: The author's own visualization ............................ 32
Figure 18 Windows Phone hardware buttons Source: The author's own visualization ....... 33
Figure 19 Progress bar on Android – Galaxy Nexus Source: The author's own visualization
.............................................................................................................................. 35
Figure 20 Well understandable message on a Windows Phone 7 device Source: The
author's own visualization ...................................................................................... 35
Figure 21 Good example of consistency in naming on Windows Phone 7 Source: The
author's own visualization ...................................................................................... 36
85
Figure 22 Customization example on iPhone Source: The author's own visualization ....... 36
Figure 23 An example of good error message on iPhone Source: The author's own
visualization ........................................................................................................... 37
Figure 24 Correlation between number of users participating on usability test and problems
found Source: Usability testing essentials, Carol Barnum (Barnum, 2011, p. 16) ... 41
Figure 25 Morae: dedicated usability testing software – the user is presented with a test
task Source: (TechSmith, Record Automated Sessions with Autopilot, 2012), the
author's own visualization ...................................................................................... 42
Figure 26 UnserWein logo Source: The author's own visualization ................................... 47
Figure 27 Homepage Source: The author's own visualization ........................................... 48
Figure 28 List of wineries browsed by hall (left) and wines browsed by region (right)
Source: The author's own visualization .................................................................. 49
Figure 29 Search suggestions Source: The author's own visualization.............................. 50
Figure 30 Sample QR code referencing a wine maker in the application Source: The
author's own visualization ...................................................................................... 50
Figure 31 A wine maker's page Source: The author's own visualization ............................ 51
Figure 32 A wine page Source: The author's own visualization ......................................... 52
Figure 33 Bookmarking a winery (left) or a wine (right) from the details page Source: The
author's own visualization ...................................................................................... 53
Figure 34 Bookmarking a winery (left) or a wine (right) from the overview Source: The
author's own visualization ...................................................................................... 53
Figure 35 Bookmark pages, where a user can specify additional data about the winery (left)
or wine (right) Source: The author's own visualization .......................................... 54
Figure 36 One of the environments where usability testing took place Source: The author's
own visualization .................................................................................................... 55
Figure 37 The age distribution of participants Source: The author's own visualization ....... 58
Figure 38 Search suggestions - when the keyboard is activated the users are able to see
only one search result Source: The author's own visualization............................... 62
Figure 39 The word "Zeremoniensaal" illustrates how a hyperlink is marked Source: The
author's own visualization ...................................................................................... 62
Figure 40 The sweet wine (marked yellow) misplaced between white wines (marked green)
Source: The author's own visualization .................................................................. 64
Figure 41 Unserwein.at logo - The current design (left) and the new proposal (right)
Source: The author's own visualization .................................................................. 69
Figure 42 About unserwein.at list view - the current design (left) and the new proposal
(right) Source: The author's own visualization ........................................................ 69
Figure 43 About Vievinum 2012 list view - the current design (left) and the new proposal
(right) Source: The author's own visualization ........................................................ 70
Figure 44 Bottom menu - the current design (left) and the new proposal (right) Source: The
author's own visualization ...................................................................................... 70
86
Figure 45 Number of entries - the current design (left) and the new proposal (right) Source:
The author's own visualization ............................................................................... 71
Figure 46 Vintage - the current design (left) and the new proposal (right) Source: The
author's own visualization ...................................................................................... 71
Figure 47 The bookmarking page - the current design (left) and the new proposal (right)
Source: The author's own visualization .................................................................. 72
Figure 48 Wine order - the current design (left) and the new proposal (right) Source: The
author's own visualization ...................................................................................... 72
Figure 49 Winemaker's webpage - the current design (left) and the new proposal (right)
Source: The author's own visualization .................................................................. 73
Figure 50 Proposed changes to user interfaces for Vievinum/UnserWein.at Source: The
author's own visualization ...................................................................................... 74
87
10 List of Tables
Table 1 Worldwide smartphone shipments by operating system, 2011, 2015 Source: IDC
December 2011 (Drake, et al., 2011, p. 12) ........................................................... 12
Table 2 Smartphone operating systems and languages Source: (Allen, et al., 2010, p. 5) 14
Table 3 Advantages and disadvantages of native and cross-platform applications Source:
The author’s own visualization ............................................................................... 19
Table 4 Android multiple screen size categories Source: (Allen, 2012, p. 47) .................... 23
Table 5 Market share of Android devices with different combinations of screen sizes and
densities Source: (Google Inc., Screen Sizes and Densities, 2012) ...................... 27
Table 6 The distribution of points on the questionnaires .................................................... 67
88
11 Web Links
Android guideline http://developer.android.com/design/index.html
IPhone guideline http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introd
uction/Introduction.html
Windows Phone guideline http://msdn.microsoft.com/en-us/library/hh202869(v=vs.92).aspx
89
12 Attachment – Questionnaire
90
13 Attachment – Recording consent form
I agree to the recording of the usability tests for vievinum.unserwein.at conducted with
Jana Mrazova.
The gathered data will be treated as confidential and used for the master thesis “User-
Centered Cross-Platform Application Development for Mobile Devices” and for the
optimization of the vievinum.unserwein.at application exclusively.
Signature_______________________________
Name_________________________________________
Date____________________________________
