User Centered Cross-Platform Application Development for Mobile Devices

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.

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 SmartphoneMarktes 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 3 user interface, usability test, Leitfaden, benutzerschnittstelle, mobile ?

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 crossplatform 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
4

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.

5

Table of Contents
1 INTRODUCTION ............................................................................................................................... 9 1.1 1.2 1.3 1.4 1.5 2 Motivation ......................................................................................................................................... 9 Research Questions ....................................................................................................................... 9 Methods .......................................................................................................................................... 10 Structure ......................................................................................................................................... 11 What is not contained in this thesis ............................................................................................ 11

MARKETS FOR MOBILE APPLICATIONS .................................................................................. 12 2.1 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 Market structure ............................................................................................................................ 12 Mobile applications ....................................................................................................................... 13 Native mobile application ........................................................................................................ 14 Cross-platform application ...................................................................................................... 16 Choosing between native and cross-platform application ...................................................... 19 Reasons for choosing a native application ........................................................................... 19 Reasons for choosing a cross-platform application............................................................. 21

3

COMPARISON OF MOBILE DEVICES ......................................................................................... 22 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 Screen Size.................................................................................................................................... 22 Android ....................................................................................................................................... 22 IPhone ........................................................................................................................................ 23 Windows Phone ........................................................................................................................ 24 Screen size summary .............................................................................................................. 25 Display density .............................................................................................................................. 25 IPhone ........................................................................................................................................ 26 Windows Phone ........................................................................................................................ 27 Android ....................................................................................................................................... 27 Density-independent pixels ..................................................................................................... 27 Changing portrait/landscape view .............................................................................................. 29 User Input ....................................................................................................................................... 30 Touch input ................................................................................................................................ 30 Gestures .................................................................................................................................... 31 Keyboard input .......................................................................................................................... 31 Hardware buttons ..................................................................................................................... 32 Other input methods ................................................................................................................. 33

4

USER-CENTERED APPROACH ................................................................................................... 34 4.1 4.1.1 4.2 4.2.1 Usability .......................................................................................................................................... 34 General usability guidelines .................................................................................................... 35 Usability testing ............................................................................................................................. 38 Testing environment ................................................................................................................. 38
6

4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 5

Participants ................................................................................................................................ 40 Test tasks .................................................................................................................................. 41 Stages of a test ......................................................................................................................... 43 Other usability methods ............................................................................................................... 45 Observation ............................................................................................................................... 45 Thinking aloud ........................................................................................................................... 45 Questionnaires .......................................................................................................................... 46

UNSERWEIN.AT – USER CENTERED CROSS-PLATFORM APPLICATION ......................... 47

5.1
5.2 5.2.1 5.2.2

Introduction of the company UnserWein.at ............................................................................... 47 Vievinum/UnserWein.at application ........................................................................................... 47 Homepage ................................................................................................................................. 48 Wine maker’s page................................................................................................................... 50 Wine page.................................................................................................................................. 52 Bookmarking winery/wine ........................................................................................................ 53 Additional features .................................................................................................................... 54 Usability test preparation ............................................................................................................. 55 Testing environment ................................................................................................................. 55 Test tasks .................................................................................................................................. 56 Participants ................................................................................................................................ 58 Combining usability methods .................................................................................................. 59 Usability test execution ................................................................................................................ 59 Preparation ................................................................................................................................ 59 Introduction ................................................................................................................................ 60 The test ...................................................................................................................................... 60 Debriefing .................................................................................................................................. 61 Test results .................................................................................................................................... 61 First impressions of Vievinum/UnserWein.at ........................................................................ 61 Task 1 evaluation ..................................................................................................................... 61 Task 2 evaluation ..................................................................................................................... 62 Task 3 evaluation ..................................................................................................................... 63 Task 4 evaluation ..................................................................................................................... 64 Task 5 evaluation ..................................................................................................................... 64 Questionnaires evaluation ....................................................................................................... 65 Evaluation of the discussions ................................................................................................. 68 New design proposal .................................................................................................................... 69 Additional improvement proposals ............................................................................................. 73

5.2.3 5.2.4 5.2.5 5.3 5.3.1 5.3.2 5.3.3 5.3.4

5.4
5.4.1 5.4.2 5.4.3 5.4.4 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.5.5 5.5.6 5.5.7 5.5.8 5.6 5.7 6

GUIDELINE FOR CREATING A USER-CENTERED CROSS-PLATFORM MOBILE

APPLICATION ......................................................................................................................................... 75 7 DISCUSSION ................................................................................................................................... 78 7.1 Research questions ...................................................................................................................... 78
7

7.2 7.2.2 8 9 10 11 12 13

Future perspectives ...................................................................................................................... 79 Cross-platform applications .................................................................................................... 80 Vievinum/UnserWein.at application ....................................................................................... 80

7.2.1

BIBLIOGRAPHY ............................................................................................................................. 82 TABLE OF FIGURES ...................................................................................................................... 84 LIST OF TABLES ............................................................................................................................ 87 WEB LINKS ..................................................................................................................................... 88 ATTACHMENT – QUESTIONNAIRE ............................................................................................ 89 ATTACHMENT – RECORDING CONSENT FORM ..................................................................... 90

8

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.

1.1 Motivation
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 usercentered application.

1.2 Research Questions
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.

9

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 endusers: 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.

1.3 Methods
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 crossplatform 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

10

1.4 Structure
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.

1.5 What is not contained in this thesis
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.

11

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.

2.1 Market structure
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 (%) Android Blackberry OS iPhone OS Symbian Windows Phone Other 2011 Market Share 49.0 11.1 18.2 16.4 1.9 3.3 2015 Market Share 46.5 10.0 19.3 0.1 20.6 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
12

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.

2.2 Mobile applications
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?

13

2.2.1 Native mobile application
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 Programming Language Google Android Java Apple iPhone Objective-C Microsoft Windows Phone 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

14

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
•Full access to all capabilities of a device •Native user interface •Disconnected mode

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

15

Disadvantages Native application •Deployment and development 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.

2.2.2 Cross-platform application
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.

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

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
•Easy portability Cross-platform •Centrally managed distribution •Low-friction deployment advantages •Cross-platform

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

17

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

Cross-platform •Access to device sensors disadvantages •Connectivity

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.

18

Summary
The following Table 3 is presenting the advantages and disadvantages of a native and a cross-platform application in a summarized form. Advantages Native application    Cross-platform application     Full access to all capabilities of a device Native User Interface Disconnected mode Easy portability Centrally managed distribution Low-friction deployment Cross-platform   Access to device sensors Connectivity  Disadvantages Deployment and development

Table 3 Advantages and disadvantages of native and cross-platform applications Source: The author’s own visualization

2.3 Choosing between native and cross-platform 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.

2.3.1 Reasons for choosing a native application
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).
19

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
20

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.

2.3.2

Reasons for choosing a cross-platform application

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 crossplatform one. This not only creates a long-term platform for mobile application, it also reduces the costs for development and deployment.

21

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.

3.1 Screen Size
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.

3.1.1 Android
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: extralarge, 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:

22

Category Small Normal Large Extra-large

Viewing distance Under 7,5 cm 7,5 cm to around 11.5 cm 11.5 cm to around 25 cm Over 25 cm

Resolution At least 426 x 320 dp resolution At least 470 x 320 dp resolution At least 640 x 480 dp resolution 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.

3.1.2 IPhone
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.

23

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

Figure 8 Screen size of iPhone 3GS (left) and 4S

(right)
Source: The author's own visualization

3.1.3 Windows Phone
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 9 Screen size of Samsung Omnia 7 (Windows Phone operating system) Source: The author's own visualization

24

3.1.4 Screen size summary
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).

Figure 10 Various resolutions of mobile devices in portrait mode Source: The author's own visualization

3.2 Display density
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
25

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.

3.2.1 IPhone
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.

26

3.2.2 Windows Phone
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).

3.2.3 Android
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 Small Medium Large XLarge 1.9% 0.7% 0.2% 19.6% 2.3% 5.8%
Source: (Google Inc., Screen Sizes and Densities, 2012)

Medium PPI

High PPI 2.5% 64.6%

Extra High PPI 2.4%

Table 5 Market share of Android devices with different combinations of screen sizes and densities

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.

3.2.4 Density-independent pixels
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

27

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

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.

3.3 Changing portrait/landscape view
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 14 eBay web application in landscape mode Source: The author's own visualization

Figure 13 eBay web application in portrait view Source: The author's own visualization

29

3.4 User Input
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).

3.4.1 Touch input
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
30

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

3.4.2 Gestures
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.

3.4.3 Keyboard input
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.

31

3.4.4 Hardware buttons
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

32

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

3.4.5 Other input methods
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.

33

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.

4.1 Usability
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.

34

4.1.1 General usability guidelines
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
35

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
36

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

37

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.

4.2 Usability testing
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).

4.2.1 Testing environment
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

38

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

39

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

4.2.2 Participants
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.

40

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.

4.2.3 Test tasks
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
41

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: Scenario: Apply for a master’s degree at Technikum Wien” 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

42

4.2.4 Stages of a test
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.

43

-

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

44

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.

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

4.3.1 Observation
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.

4.3.2 Thinking aloud
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 outloud 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.”

45

4.3.3 Questionnaires
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.

46

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.

5.1 Introduction of the company UnserWein.at
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 Figure 26 UnserWein logo than 500 national and international wine Source: The author's own visualization 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 crossplatform 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.

5.2 Vievinum/UnserWein.at application
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

47

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.

5.2.1 Homepage
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
48

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

49

5.2.2 Wine maker’s page
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

50

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

51

5.2.3 Wine page
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

52

5.2.4 Bookmarking winery/wine
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.

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

5.2.5 Additional features
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.

54

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

5.3.1 Testing environment
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

55

5.3.2 Test tasks
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:
56





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



57

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



5.3.3 Participants
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
58

5.3.4 Combining usability methods
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 crossplatform 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.

5.4 Usability test execution
Once the usability test has been prepared and the participants recruited and scheduled for testing, the next step was to execute the plan.

5.4.1 Preparation
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.

59

5.4.2 Introduction
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.

5.4.3 The test
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.

60

5.4.4 Debriefing
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.

5.5 Test results
This section will present the results of the usability tests conducted on the Vievinum/UnserWein.at application.

5.5.1 First impressions of Vievinum/UnserWein.at
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.

5.5.2 Task 1 evaluation
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
61

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

5.5.3 Task 2 evaluation
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
62

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.

5.5.4 Task 3 evaluation
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.

63

5.5.5 Task 4 evaluation
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.

5.5.6 Task 5 evaluation
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.

64

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.

5.5.7 Questionnaires evaluation
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 crossplatform 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.

65

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.

66

Question

P 01
With a cross-platform application I can perform the same tasks as with a native application. 2 If a cross-platform application is well implemented, I don’t care if I use a 3 native or a cross-platform application I always prefer a native application Layout of the Vievinum/UnserWein.at application is well displayed on my mobile phone The font size is exactly right 3 4 4 The application is neatly arranged The information and notations of the application are easy to understand The application appears modern 3 4 3 The color composition is attractive 2 The design fits well with the content 2 of the application The application is of high quality 3

Table 6 The distribution of points on the questionnaires Source: The author's own visualization
67

P 02
4 4 1 4 4 4 4 3 4 4 4

P 03
3 4 3 4 4 4 4 4 4 4 4

P 04
2 3 3 3 4 4 4 4 4 4 4

P 05
3 3 4 4 4 4 4 4 4 4 4

P 06
3 3 4 4 4 4 4 4 4 4 4

P 07
2 3 4 4 3 4 4 4 4 4 4

P 08
1 2 4 4 4 3 3 4 4 4 4

P 09
4 4 1 4 2 3 4 4 2 3 4

P 10
4 4 1 4 4 4 4 3 4 4 4

P 11
4 4 3 4 4 4 4 4 1 2 2

P 12
2 2 4 4 4 3 4 3 4 4 3

Average 2.8

3.3

2.9

3.9

3.8

3.7

3.9

3.7

3.4

3.6

3.7

5.5.8 Evaluation of the discussions
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.

68

5.6 New design proposal
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

69

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
70

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

71

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

Figure 47 The bookmarking page - the current design (left) and the new proposal (right)

Source: The author's own visualization

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
72

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

5.7 Additional improvement proposals
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.

73

Figure 50 Proposed changes to user interfaces for Vievinum/UnserWein.at Source: The author's own visualization
74

6 Guideline for creating a user-centered crossplatform 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.

75

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.

76

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.

77

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.

7.1 Research questions
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
78

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.

7.2 Future perspectives
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

79

these assumptions the author expects software companies to have a higher tendency to focus on the cross-platform approach.

7.2.1 Cross-platform applications
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.

7.2.2 Vievinum/UnserWein.at application
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

80

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.

81

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-release030212-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 924111. Krug, S., 2010. Rocket Surgery Made Easy. Berkeley, CA, USA: New Riders.
82

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

83

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

84

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
85

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

86

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

87

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

88

12 Attachment – Questionnaire

89

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 “UserCentered Cross-Platform Application Development for Mobile Devices” and for the optimization of the vievinum.unserwein.at application exclusively. Signature_______________________________ Name_________________________________________ Date____________________________________

90