user centered cross-platform application development for mobile devices

8/22/2019 User Centered Cross-Platform Application Development for Mobile Devices

1/90

MASTER THESIS

Thesis submitted in partial fulfillment of the requirements for the degree ofMaster 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


2/90

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/90

3

Kurzfassung

Der Markt fr mobile Endgerte ist in den letzten Jahren stark gewachsen und hat

mittlerweile eine Gre erreicht, bei welcher es sich kein modernes Unternehmen leisten

kann, diesen zu ignorieren. Native Anwendungen fr alle Smartphone-Gertetypen zu

erstellen, kostet Zeit und Ressourcen, da jeder Hersteller unterschiedliche Gerte und

Entwicklungswerkzeuge zur Verfgung stellt. Eine Lsung dieses Problems ist die

Erstellung von gertunabhngigen Anwendungen. Diese werden in einem Webbrowser

angezeigt, knnen daher auf allen Betriebssystemen und Plattformen ausgefhrt werden

und erreichen somit die grtmgliche Anzahl an BenutzerInnen.

Der theoretische Teil dieser Masterarbeit beschftigt sich mit der Struktur des Smartphone-

Marktes und vergleicht native und plattformbergreifende Anwendungen. Verschiedene

Usability-Methoden und -Richtlinien werden in einem weiteren Abschnitt aufgezeigt.

Ergebnis dieser Masterarbeit sind Richtlinien zur Erstellung von benutzerfreundlichen,

gerteunabhngigen Anwendungen. Diese zeigen, wie unterschiedliche Webbrowser und

gertespezifische Fhigkeiten bestmglich genutzt werden knnen. Die Richtlinien

basieren auf weitreichender Recherche der Fachliteratur, Beobachtungen von

BenutzerInnen bei der Bedienung von Smartphones und Usability-Tests der

gerteunabhngigen UnserWein-Applikation.

Diese Masterarbeit richtet sich an DesignerInnen, Benutzerschnittstellen-EntwicklerInnen

und Personen, die Interesse an der Gestaltung von plattformunabhngigen Anwendungen

haben.

Schlagwrter: web-basierend, gertunabhngige Anwendung, Usability, Smartphone,

Usability Testing, Benutzerschnittstelle


4/90

4

Abstract

The mobile market is growing rapidlyand has reached a size where no software companycan 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 manufacturershave 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 anddisadvantages. 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/90

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/90

6

Table of Contents

1 INTRODUCTION ............................................................................................................................... 9

Motivation ......................................................................................................................................... 91.1

Research Questions ....................................................................................................................... 91.2

Methods.......................................................................................................................................... 101.3

Structure ......................................................................................................................................... 111.4

What is not contained in this thesis ............................................................................................ 111.5

2 MARKETS FOR MOBILE APPLICATIONS.................................................................................. 12

Market structure ............................................................................................................................ 122.1

Mobile applications ....................................................................................................................... 132.22.2.1 Native mobile application ........................................................................................................ 14

2.2.2 Cross-platform application ...................................................................................................... 16

Choosing between native and cross-platform application ...................................................... 192.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.................................................................................................................................... 223.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 .............................................................................................................................. 253.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 .............................................................................................. 293.3

User Input....................................................................................................................................... 303.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 .......................................................................................................................................... 344.1

4.1.1 General usability guidelines .................................................................................................... 35

Usability testing ............................................................................................................................. 384.2

4.2.1 Testing environment................................................................................................................. 38


7/90

7

4.2.2 Participants ................................................................................................................................ 40

4.2.3 Test tasks .................................................................................................................................. 41

4.2.4 Stages of a test ......................................................................................................................... 43

Other usability methods ............................................................................................................... 454.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 ............................................................................... 475.1

Vievinum/UnserWein.at application ........................................................................................... 475.2

5.2.1 Homepage ................................................................................................................................. 48

5.2.2 Wine makers page................................................................................................................... 50

5.2.3 Wine page.................................................................................................................................. 52

5.2.4 Bookmarking winery/wine........................................................................................................ 53

5.2.5 Additional features.................................................................................................................... 54

Usability test preparation ............................................................................................................. 555.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 ................................................................................................................ 595.4

5.4.1 Preparation ................................................................................................................................ 59

5.4.2 Introduction ................................................................................................................................ 60

5.4.3 The test ...................................................................................................................................... 60

5.4.4 Debriefing .................................................................................................................................. 61

Test results .................................................................................................................................... 615.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 ..................................................................................................................... 635.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 .................................................................................................................... 695.6

Additional improvement proposals ............................................................................................. 735.7

6 GUIDELINE FOR CREATING A USER-CENTERED CROSS-PLATFORM MOBILE

APPLICATION ......................................................................................................................................... 75

7 DISCUSSION ................................................................................................................................... 78

Research questions ...................................................................................................................... 787.1


8/90

8

Future perspectives ...................................................................................................................... 797.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/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.

Motivation1.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 andtechnical 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 versionsof 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 browsers 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 Questions1.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/90

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 browsers capabilities and display an application in a

manner that will minimize the negative aspects of cross-platform applications.

Methods1.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-datestatistics about the market

shareas 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/90

11

Structure1.4

After the introduction, the first theoretical part of this thesis will provide the reader with themost 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 betterunderstanding 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 thesis1.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/90

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 willsummarize the reasons for choosing either a native or a cross-platform application.

Market structure2.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, 2015Source: 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 seenin Table

1, a big shift in the mobile market is estimated on Microsofts side with its Windows Phone

operating system and Nokias 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/90

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 inthe 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 Microsofts 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 applications2.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/90

14

Native mobile application2.2.1

A few years ago, the only approach considered when developing an application for mobiledevices 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 PhoneProgramming 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 authoradds

that even though it is possible to use other languages for native applications than the ones

illustrated in Table 2, they dont 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 authors own visualization


15/90

15

From Figure 1 it is instantlyrecognizable 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. Theseare 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


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 adevice

Native user interface

Disconnected mode

Nativeapplicationadvantages


16/90

16

Disadvantages

Figure 3 Native application disadvantages


Deployment and development

As mentioned before, the greatest disadvantage of a native application is the amount of

resources required for thedeployment 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 application2.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

Nativeapplication

disadvantages


17/90

17

Figure 4 Web Based mobile version of youtube.com on Windows Phone (left), iPhone (middle) and

Android (right)


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 onthe type of a

mobile application.

Advantages

Figure 5 Cross-platform application advantages


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-platformadvantages


18/90

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.


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


Access to device sensors

Cross-platform application also has a few drawbacks, one of which beingthe inability of a

web application to access the sensors (with a few exceptions) of a mobile device (Olson, etal., 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 inweb-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

ConnectivityCross-platformdisadvantages


19/90

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


Cross-platform

Access to device

sensors

Connectivity

Table 3 Advantages and disadvantages of native and cross-platform applications


Choosing between native and cross-platform2.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 maybe situations where this might not be clear.

Reasons for choosing a native application2.3.1According 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 customers side

(Fling, 2009, p. 146).


20/90

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 users

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 devices 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 WideWeb Consortium) to implement direct access on devices 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 devices

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/90

21

doesnt 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 application2.3.2This 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 doesnt 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/90

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 Androids, iPhones and Windows Phones 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 screensize, high quality resolution, changing portrait/landscape view, input devices and HTML5

support.

This thesis focuseson 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 Size3.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.

Android3.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 Androids 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/90

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.

IPhone3.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 haveconstrained the resolution to a certain value.


24/90

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 isnt very dramatic

and doesnt 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 Phone3.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)


Figure 9 Screen size of Samsung Omnia

7 (Windows Phone operating system)



25/90

25

Screen size summary3.1.4

This thesis focuses on only three operating systems and already more than five differentresolutions 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 density3.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/90

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.

IPhone3.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 didnt change, the resolution doubled.

This means that the pixels shrank, thus allowing a higher quality resolution on the samesized 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/90

27

Windows Phone3.2.2

Windows Phone devices, like the iPhone, have a fixed resolution which is set to 480 by800 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).

Android3.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 pixels3.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/90

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.


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/90

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 view3.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 devices orientation and rotation. Depending

on the angle, a web application rotates accordingly. The portrait and landscape view onlysupport 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 systemsAndroids, iPhones as well as Windows Phones 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



30/90

30

User Input3.4

When working on a desktop or laptop computer, the most common input devices is a

keyboard, a mouse, or a touchpad, all of whichallow very precise input methods. Mobile

phones work differently. They are constrained to a relatively small screen and not only is

the devices 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 input3.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/90

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).

Gestures3.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 input3.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


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 makingdata entries.

User interfaces should therefore be planned accordingly.


32/90

32

Hardware buttons3.4.4

Hardware buttons, which are placed on the front-facing side of mobile phones, are anothermeans 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 16Androids on-screen buttons on Galaxy Nexus and hardware buttons on Motorola Droid


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 users preference

VoiceOver, Zoom or White on Black.

Figure 17 iPhone Home Button



33/90

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


Other input methods3.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/90

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 designers 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.

Usability4.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 products 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/90

35

General usability guidelines4.1.1

General usability guidelines are well-known principles for all user interfaces which shouldbe 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


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



36/90

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


5. Error preventionErrors 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 visiblereduces the users 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



37/90

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


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/90

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 testing4.2

The usability testing is the most fundamental usability method (Nielsen, 1993, p. 165). Itspurpose 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 users 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 asthere 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. Onthe 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 environment4.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/90

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 laboratoryIn 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 theytend 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/90

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).

Participants4.2.2Usability 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 audienceand 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/90

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 tasks4.2.3

Another keyword in the definition of usability is the word tasks in the context ofaccomplishing 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 timenot 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 masters degree at Technikum Wien

- What are the librarys 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/90

42

provide participants with themissing 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 masters degree at Technikum Wien

Scenario: You have just finished your Bachelors degree and now you are

interested in studying the Masters 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 ofthe 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/90

43

Stages of a test4.2.4

Once the testing environment has been selected, the tasks chosen and participantsrecruited 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 thesoftware 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 participants reactions, emotions and proceeding with the test.

These can later be used for presentation purposes and to highlight the problem sections ofa 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/90

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

user centered cross-platform application development for mobile devices

Documents