Professional Documents
Culture Documents
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
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 fr mobile Endgerte ist in den letzten Jahren stark gewachsen und hat mittlerweile eine Gre erreicht, bei welcher es sich kein modernes Unternehmen leisten kann, diesen zu ignorieren. Native Anwendungen fr alle Smartphone-Gertetypen zu erstellen, kostet Zeit und Ressourcen, da jeder Hersteller unterschiedliche Gerte und Entwicklungswerkzeuge zur Verfgung stellt. Eine Lsung dieses Problems ist die Erstellung von gertunabhngigen Anwendungen. Diese werden in einem Webbrowser angezeigt, knnen daher auf allen Betriebssystemen und Plattformen ausgefhrt werden und erreichen somit die grtmgliche Anzahl an BenutzerInnen. Der theoretische Teil dieser Masterarbeit beschftigt sich mit der Struktur des SmartphoneMarktes und vergleicht native und plattformbergreifende Anwendungen. Verschiedene Usability-Methoden und -Richtlinien werden in einem weiteren Abschnitt aufgezeigt. Ergebnis dieser Masterarbeit sind Richtlinien zur Erstellung von benutzerfreundlichen, gerteunabhngigen Anwendungen. Diese zeigen, wie unterschiedliche Webbrowser und gertespezifische Fhigkeiten bestmglich genutzt werden knnen. Die Richtlinien basieren auf weitreichender Recherche der Fachliteratur, Beobachtungen von BenutzerInnen bei der Bedienung von Smartphones und Usability-Tests der gerteunabhngigen UnserWein-Applikation. Diese Masterarbeit richtet sich an DesignerInnen, Benutzerschnittstellen-EntwicklerInnen und Personen, die Interesse an der Gestaltung von plattformunabhngigen Anwendungen haben.
Schlagwrter: web-basierend, gertunabhngige Anwendung, Usability, Smartphone, Usability Testing, Benutzerschnittstelle 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.
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
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
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
Participants ................................................................................................................................ 40 Test tasks .................................................................................................................................. 41 Stages of a test ......................................................................................................................... 43 Other usability methods ............................................................................................................... 45 Observation ............................................................................................................................... 45 Thinking aloud ........................................................................................................................... 45 Questionnaires .......................................................................................................................... 46
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 makers 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.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
7.2 7.2.2 8 9 10 11 12 13
7.2.1
BIBLIOGRAPHY ............................................................................................................................. 82 TABLE OF FIGURES ...................................................................................................................... 84 LIST OF TABLES ............................................................................................................................ 87 WEB LINKS ..................................................................................................................................... 88 ATTACHMENT QUESTIONNAIRE ............................................................................................ 89 ATTACHMENT RECORDING CONSENT FORM ..................................................................... 90
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 browsers capabilities and display an application in a manner which minimizes the negative aspects of cross-platform applications. This paper focuses on this problem and its aim is to create a guideline for creating a usercentered application.
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 browsers 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.
11
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 Microsofts side with its Windows Phone operating system and Nokias Symbian. As of 2011, Microsoft showed a minimal market share, rounding around 2%. However, by the year 2015 the estimation shows over 20% of
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 Microsofts market share to 20% is due to the decision made on February 11, 2011, when Nokia chose Windows Phone operating system as their primary platform for smartphone devices. Even though Symbian operating system will continue having technical support for the following five years, based on IDC report (Drake, et al., 2011, p. 7) from December 2011 IDC believes that competitive pressure from other operating systems and changes in OS strategy by its biggest supporters will result in lower market share in the years to come. All these facts considered, for the purpose of this thesis three mobile operating systems were chosen iPhone, Android and Windows Phone. Android and iPhone were chosen for their current as well as future market positions and Windows Phone platform for its potential in the years to come. These operating systems are going to be analyzed and later on, based on their capabilities, a guideline for creating a user centered cross-platform application will be created.
13
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 dont optimally use all the capabilities of a particular smartphone device and therefore are not as optimized as the device-specific languages. Figure 1 shows Trip Advisor as three different native applications, running on iPhone, Android and Windows Phone.
Figure 1 Trip Advisor native applications on iPhone (left), Android (middle), and Windows Phone 7(right) Source: The authors own visualization
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
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
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.
16
Figure 4 Web Based mobile version of youtube.com on Windows Phone (left), iPhone (middle) and Android (right) Source: The authors 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
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
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 authors own visualization
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).
doesnt require an internet connection as it makes use of local data and therefore can be used in locations with no reception or wireless connection.
2.3.2
This previous section focused on the problem of when to choose a native application over a cross-platform one. This section will focus is on the other side of the problem; namely, when to choose a cross-platform application over a native one. The solution is very simple. According to Brian Fling (Fling, 2009, p. 150), if the application doesnt 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.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 Androids 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
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 isnt very dramatic and doesnt have as much of an impact on the designing process, as the aspect ratio of width and height remains unchanged (David, 2011, p. 6).
(right)
Source: The author's own visualization
Figure 9 Screen size of Samsung Omnia 7 (Windows Phone operating system) Source: The author's own visualization
24
Figure 10 Various resolutions of mobile devices in portrait mode Source: The author's own visualization
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 didnt 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.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
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.
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.
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
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.
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
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 Androids 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 users preference VoiceOver, Zoom or White on Black.
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
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 designers job. Therefore the aim of this chapter is to provide an introduction to the topic of usability and the principles of user interface design, which help to design user-centered applications.
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 products goals are identical with those of its users Specific context of use users are using the application in a certain environment and it is essential that the application is designed to be used under those terms In the book Usability Engineering Jacob Nielsen uses a different approach when defining usability and describes it as a property of user interface with multiple components, which include the attributes learnability, efficiency, memorability, errors and satisfaction (Nielsen, 1993, p. 26). But regardless of the exact definition, the question remains: how can effectiveness, satisfaction or memorability be measured? Usability is measured in such a way where a number of users, or so called participants, are trying to accomplish a set of predefined tasks (Barnum, 2011, p. 6). Based on this statement, it can be deducted that usability is a rather subjective discipline; however there are certain guidelines which have been proven to ensure high usability despite its subjective perception. The following sections will aim to illustrate some of them.
34
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 users memory load by not requiring him to remember information from one dialog to the next. 7. Flexibility and efficiency of use Allowing users to personalize their frequent actions as well as use of accelerators often speeds up the interaction between the system and the user (Figure 22).
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.
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.
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 masters degree at Technikum Wien - What are the librarys opening hours?
Scenarios
Next step is to filter these tasks and decide which ones are the most critical or difficult to use. Once this is done, these tasks need to be transformed into scenarios. Scenarios
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 masters degree at Technikum Wien You have just finished your Bachelors degree and now you are interested in studying the Masters degree in Multimedia and Software development at Technikum Wien. Apply for this program.
Pilot test
After tasks have been filtered and transformed into scenarios, it is advisable to pre-test these tasks in a pilot test (Krug, 2010, p. 54). The purpose of a pilot test is to make sure that the tasks are well understood, complete and can be finished within the given time frame. If not, there is still time to make the necessary adjustments.
Print outs
The last step in preparing tasks for usability testing is to print them out in two formats. One format is for the users, where each task is written in big font and covers half a page. The other format is for the observers or the facilitator, where all tasks are printed on one page. Instead of printing out the test tasks, it is possible to use dedicated usability testing software such as Morae. Morae supports the whole process of usability testing and one 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
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 participants 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.
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 facilitators influencing the participants 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.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.
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
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.
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
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 winemakers booths. These QR codes (Figure 30) reference the winemakers 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 winemakers 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.
51
52
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
54
Figure 36 One of the environments where usability testing took place Source: The author's own visualization
55
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 winemakers 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 Dockners 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.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.
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.
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 winemakers 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
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 winemakers 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.
63
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.
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.
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 dont 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
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
Figure 41 Unserwein.at logo - The current design (left) and the new proposal (right) Source: The author's own visualization
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
Figure 44 Bottom menu - the current design (left) and the new proposal (right) Source: The author's own visualization
70
Figure 45 Number of entries - the current design (left) and the new proposal (right) Source: The author's own visualization
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)
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
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.
75
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.
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.
application is well implemented, I dont 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 doesnt 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.
79
these assumptions the author expects software companies to have a higher tendency to focus on the cross-platform approach.
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 authors own visualization ..........................................14 Figure 2 Native application advantages Source: The authors own visualization ............15 Figure 3 Native application disadvantages Source: The authors own visualization ........16 Figure 4 Web Based mobile version of youtube.com on Windows Phone (left), iPhone (middle) and Android (right) Source: The authors own visualization .....................17 Figure 5 Cross-platform application advantages Source: The authors own visualization ..............................................................................................................................17 Figure 6 Cross-platform application disadvantages Source: The authors 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 Androids 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 authors 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
88
12 Attachment Questionnaire
89
90