Touchscreen GUI Design and Evaluation of an On-Device Portal

Touchscreen GUI Design and Evaluation of an On-Device Portal Fredrik Björnskiöld and Robert Johansson

December 7, 2008 Master’s Thesis in Computing Science, 2*30 credits Supervisor at CS-UmU: Jerry Eriksson Examiner: Per Lindström

Ume˚ a University Department of Computing Science SE-901 87 UME˚ A SWEDEN

Abstract On-device Portals (ODPs) are client applications with a graphical user interface designed to improve the way specific content are presented on mobile phones. However, good and rich content is not enough to make users explore it. The content has to be easily accessible and presented in a usable and experiential way. The main goal of this Master Thesis is to present an on-device portal prototype for a touch screen mobile phone showing examples of good user experience and usability. To accomplish this goal a pre-study has been performed to investigate the end-user and the context of ODP’s. The context includes content, competitors and very much the mobile web as well as 3rd party applications. Two literature studies have been conducted to gain extra knowledge about touch screen displays as well as user experience evaluation for mobile devices. The design phase, from concept and interaction design to graphical design is motivated in design decisions and presented with screens from the iterative work. The concept has been evaluated with a focus group and the target users have constantly been in focus. The target users have been represented with personas. Finally, the prototype is presented with screenshots and motivation to the design. The belonging user evaluation is presented and the result is showing that the design is easy to use and appreciated by the test attendees. This imply that the design in many cases is a good example to follow.

ii

Contents 1 Introduction 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 On-Device Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

2 Problem Description 2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3

3 Methods 3.1 Iterative Design . . . . . . . . . . . . . . 3.2 User-Centered Design . . . . . . . . . . 3.2.1 ISO 13407 UCD . . . . . . . . . 3.2.2 The Schaffer-Weinschenk Method 3.3 Personas . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 5 5 6 7 8

4 Context Analysis 4.1 Customers . . . . . . . . . . . . . . . . . . . 4.2 Technology . . . . . . . . . . . . . . . . . . 4.3 Competitor Analysis . . . . . . . . . . . . . 4.4 Content . . . . . . . . . . . . . . . . . . . . 4.4.1 Case Study - Vodafone Live ODP . . 4.4.2 Case study - App store . . . . . . . 4.5 Customer content analysis . . . . . . . . . . 4.5.1 General content organization . . . . 4.6 Heuristic evaluation of Ericsson ODP Demo

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

9 9 9 10 16 16 17 18 18 20

. . . . .

21 21 22 23 23 25

. . . . .

5 Usability and user experience testing on mobile 5.1 Background . . . . . . . . . . . . . . . . . . . . . 5.1.1 User experience . . . . . . . . . . . . . . . 5.1.2 Usability . . . . . . . . . . . . . . . . . . 5.2 Designing for user experience and usability . . . 5.3 User experience and usability testing . . . . . . . iii

devices . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

iv

CONTENTS

. . . .

25 26 28 29

. . . . . . . . . . . . . . . . . . .

33 33 34 34 35 36 36 38 38 38 40 40 41 41 41 42 43 43 45 46

7 Design 7.1 Target group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Market segmentation . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.3 Persona based scenarios . . . . . . . . . . . . . . . . . . . . . . . 7.2 Design Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Summary of Meeting 1 - The ODP Concept . . . . . . . . . . . . 7.2.2 Summary of Meeting 2 - Competitor analysis . . . . . . . . . . . 7.2.3 Summary of Meeting 3 - Content Sorting and Interaction Styles . 7.2.4 Summary of Meeting 4 - GUI Screens Evaluation . . . . . . . . . 7.3 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Usability goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 General requirements . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Persona specific requirements . . . . . . . . . . . . . . . . . . . . 7.4.4 Other requirements on the ODP (from Meeting 3) . . . . . . . .

47 47 47 48 51 52 52 53 53 54 56 62 62 64 65 66

5.4 5.5 5.6

5.3.1 Methods . . . . . . Difficulties . . . . . . . . . Discussion . . . . . . . . . Conclusion with guidelines

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6 Designing for touch screens on mobile devices 6.1 Introduction . . . . . . . . . . . . . . . . . . . . 6.2 Touch screen hardware techniques . . . . . . . 6.2.1 Resistive . . . . . . . . . . . . . . . . . . 6.2.2 Capacitive (Inductive) . . . . . . . . . . 6.2.3 Infrared light and cameras . . . . . . . . 6.2.4 Surface acoustic wave (SAW) . . . . . . 6.2.5 Single touch and Multi-touch . . . . . . 6.3 Buxton’s three state model . . . . . . . . . . . 6.4 Navigation . . . . . . . . . . . . . . . . . . . . . 6.4.1 Zooming, Panning and Scrolling . . . . 6.4.2 Touch-n-Go . . . . . . . . . . . . . . . . 6.4.3 Radial Scrolling . . . . . . . . . . . . . . 6.4.4 Speed-dependent Automatic Zooming . 6.5 Precision . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Target size . . . . . . . . . . . . . . . . 6.6 Feedback . . . . . . . . . . . . . . . . . . . . . 6.7 Touch screen Design Guidelines . . . . . . . . . 6.8 Discussion . . . . . . . . . . . . . . . . . . . . . 6.9 Conclusions . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . . . . . . .

CONTENTS

v

8 Accomplishment 8.1 Identifying the user and the needs 8.2 Developing the design . . . . . . . 8.3 Implementing the prototype . . . . 8.4 Evaluating the result . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

67 67 67 68 68

9 Results 9.1 Prototype . . . . . . . . . . . . 9.2 Evaluation . . . . . . . . . . . . 9.2.1 Expert evaluations . . . 9.2.2 Usability test . . . . . . 9.2.3 Requirement validation 9.3 Future design proposals . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

69 69 77 77 77 82 83

10 Conclusions 10.1 The Work and the Result . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Limitations and Future work . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Final words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87 87 89 89

11 Acknowledgements

91

References

93

. . . . . .

. . . . . .

A Usability test A.1 Tasks and Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Following questions and answers . . . . . . . . . . . . . . . . . . . . . .

99 99 101

B Fulfilled requirements

105

vi

CONTENTS

List of Figures 3.1

The four main stages in the HCD process . . . . . . . . . . . . . . . . .

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Abaxia Mobile Portal . . . . . . . . . Action Engine example of Brand-n-Go Adobe Flash Cast example . . . . . . OpenWave client example . . . . . . . SurfKitchen example client . . . . . . Opera platform example . . . . . . . . Yahoo! Go 3.0 . . . . . . . . . . . . . Onskreen ODP example . . . . . . . . Screenshot of Vodafone Germany ODP

. . . . . . . . .

10 11 12 12 13 14 15 15 16

5.1 5.2

Why you only need to test with 5 users . . . . . . . . . . . . . . . . . . Test device for mobile devices . . . . . . . . . . . . . . . . . . . . . . . .

26 28

6.1 6.2 6.3 6.4 6.5 6.6

Resistive touch screen . . . . . . . . . . . . Capacitive touch screen . . . . . . . . . . . IR touch screen . . . . . . . . . . . . . . . . SAW touch screen . . . . . . . . . . . . . . Buxton’s three states . . . . . . . . . . . . . Buxton’s states adapted for a touch screen .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

34 35 36 37 39 39

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

Persona named Glenn Persona named Alice . Home screen 1 . . . . Home screen 2 . . . . Home screen 3 . . . . Home screen 4 . . . . Home screen 5 . . . . Final Home screen . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

49 50 56 57 58 59 60 61

9.1

Hierachial view of the ODP prototype . . . . . . . . . . . . . . . . . . .

70

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

vii

. . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

7

viii

9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13

LIST OF FIGURES

The Home screen in prototype . . . . . . . . . . . . . . . . . . . . . . . Stuff screen in prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . Market in prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . News in prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Search in prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Help in prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The task performance rate . . . . . . . . . . . . . . . . . . . . . . . . . . The task completion time . . . . . . . . . . . . . . . . . . . . . . . . . . Scored for Usefulness and Ease of Use . . . . . . . . . . . . . . . . . . . Histogram of the answers on the TAM scale . . . . . . . . . . . . . . . . Proposed design aimed to solve problems on the Home screen and Stuff. New location of Exit in News (the same location will be used in Market).

71 72 74 75 76 76 79 80 80 81 85 86

List of Tables 4.1

Vodafone Live! Germany ODP content overview. . . . . . . . . . . . . .

16

6.1

Basic ways of interaction and usage on a touch screen [52] . . . . . . . .

40

7.1

Persona key functionality . . . . . . . . . . . . . . . . . . . . . . . . . .

51

ix

x

LIST OF TABLES

Chapter 1

Introduction 1.1

Background

Telecom and media industry have during several years used the handset browser application as an enabler of mobile content. WAP portals and SMS have been used by mobile operators and content providers to distribute and sell content. However, these portals have not been the success which the operators expected. Slow connections, limited hardware, and weak user experience are factors that need to be improved. The idea is that the next generation of networks, device hardware, handset browsers, and branded content will solve the problems [13]. “While everyone was predicting that content is king, the industry failed to notice that user experience is queen - and you need both king and queen to rule a country.”[13] Good and rich content is not enough to make users explore it. The content has to be easily accessible and presented in a usable and experiential way. On-Device Portals are the generation of device portals beyond WAP and obtain these features [13].

1.2

On-Device Portals

On-device Portals are client applications with a graphical user interface designed to improve the way specific content services are presented on mobile phones. ODPs are access points to online content rather than stand-alone applications. ODPs consist in general of three different parts [13]: – An Offline portal with content presented so the user experiences the content to be always accessible and in real-time. The content is either proactively pre-cached or pushed. – A Store-front client-server application which imitates the experience of walking past shops and enables the user to explore, search, preview, buy and use content. – A Home-screen replacement replacing the home (idle) screen of the mobile phone, working as the starting point of the user’s journey. User experience (UX) including usability are essential in ODPs. Earlier and still existing WAP-based data services have poor user experience. The communication is 1

2

Chapter 1. Introduction

slow and several clicks are often required to choose desired content. ODP products focus on usability and experience of the service by removing these obstacles. Essential for the user experience is the blurry boundary between online/offline content, which is a major benefit in ODPs, where the boundary is clear, compared to WAP services [13].

Chapter 2

Problem Description 2.1

Goals

The assignment for this Master Thesis is to review existing and suggest new GUI proposals that link the user in an easy way to different mobile services. The focus is to present an ODP prototype for a touchscreen mobile phone showing examples of good user experience. Personalization and interactivity aspects should also be taken into consideration in the proposal. In particular it is important to suggest new forms of interaction and GUI design that would make full use of a standard mobile device’s capabilities to encourage and support mass-market users to engage with new services. It is important to consider the various alternative forms of screen sizes and format. When considering the capabilities of the device one should consider what can be done beyond the current ”browser” based experience (scroll up and down and click). The goal is to better use the power of the device for animations, transitions, and full screen navigation that makes use of the capabilities of the device. In more detail shall the prototype show cases where different forms of user interaction design demonstrated. The prototype shall provide ideas and tips on how to realize the fundamental use cases of a content storefront (browsing, previewing and purchasing diverse forms of content), media portal (consuming news, weather, stocks and other info) as well as an application manager (downloading, launching and managing different applications such as games, utilities and other services like Google Maps). Finally a usability evaluation shall be carried out where the ODP prototype’s user experience is tested.

2.2

Purposes

The thesis is performed on Ericsson Multimedia department Content and Media. Content and Media consists of IPTV, Mobile TV, Advertising, Media Management and ODP. Through the ODP area Ericsson offers a full-scale ODP solution from the ondevice client application framework to the server-side components, layout and content authoring tools. Since the user experience is essential in the ODP clients and a subject for all applications being developed, is the research made in this thesis of interest for a wide area of parties. Ericsson (Telefonaktiebolaget L. M. Ericsson) is a Swedish world-leading telecommu3

4

Chapter 2. Problem Description

nications company. They deliver end-to-end solutions of equipment and services related to their area [17]. Ericsson was founded back in 1876 by Lars Magnus Ericsson and has today its headquarters in Kista, Stockholm, Sweden. Ericsson offers mobile devices through a joint venture with Sony, named Sony Ericsson Mobile Communications [60].

Chapter 3

Methods Many methods have been used during the thesis work. Some of them have been used just for an hour and some for a longer time. This chapter describes the main methods used during the whole Master Thesis. More about evaluation methods can be read in Chapter 5.

3.1

Iterative Design

For a long time it has been known that user interfaces should be designed by using an iterative process in almost all cases. This is because it is almost impossible to design a user interface with no usability problems from the beginning. Even the best usability experts need this type of process, so a usability lifecycle should definitely be built around a concept of iteration [42]. At least thress iterations are recommended when redesigning a user interface. This is based on the fact that some usability measures often decrease during iterations if the usability engineering process has focused on improving other parameters [42]. When using an iterative design process it is most common that the feedback comes from users testing the prototype or product. When a prototype or product has been completely designed it should be user tested or evaluated to find the problems. When the testing is done the problems should be fixed and the product or prototype is ready for another round of testing. This is the concept of iterative design, fix the problems, test it again, and see if the problems really have been fixed. When fixing the problems from earlier iterations, there is a possibility that new problems occur. So, except from just fixing the usability problems, the iterations also discover the new problems [42]. If the focus is finding usability problems it is preferable to use a smaller number of test users. If a larger number is used, the data work will increase rapidly and it is not sure that more usability problem will be found. With a smaller group of subjects it is easier to set up a list of usability problems and suggestions for improvements, but if the result is for management purpose, a more quantitative evaluation is preferable [42].

3.2

User-Centered Design

User-Centered Design (UCD) is a design approach where information about the enduser is in focus during the design process. The best way to do this is to commit real 5

6

Chapter 3. Methods

users during the whole process. For example, in the beginning field studies involving ethnographic methods, videos and interviews. Later in the process different mockups and more or less interactive prototypes can be used. When end-users are not available, the user focus can be retained by using scenarios, based on observations of end-users, and personas, which each describes a typical user and are better explained in its own section below. The process are user focused compared to the traditionally based technique focused. This means that the purpose is to solve a specific problem towards a group of users instead of trying a new technique. A competent UCD facilitator should have a multi-disciplinary background to be enabled to understand humans and their interactions with alike and with computers, how computers and software operate and also the context of use [23]. UCD, which requires more investment in the earlier stages of the development process, have shown to spare both in service and development costs. Particularly is the risk for unexpected changes in the requirements, work and installation costs lessen [4]. Gulliksen et al. [23] mean that when choosing and involving users they should be involved during the whole project. It is well known though that participation during a longer time will make the user no typical anymore. Their involvement tends to be too technical when they learn too much about the project. To avoid this other representatives shall be used in evaluations and analysis for shorter periods of time. To make sure of user commitment to the project it is good to find means of the participation. One example is to let the user test the system for their normal tasks and by this see the benefits of the new system. Non-committed users is often a result of feeling lack of contribution, therefore this is an important aspect to mind. During a session with users it is essential to clearly value ideas from users and designers equally important. A problem when involving users and using mockups or prototypes is unrealistic expectations. They will easily limit the conception of ideas by the users. The ideas shall come from the user to the designer not vice versa. It is very important to interpret user reactions for success. Gulliksen et al. [23] states the example if designing a hand-held device, one should make it as simple as possible, only as a black box. The user will then immediately start looking for the power button [23]. In this thesis personas are used during the design phase, and end-user evaluation performed on the prototype in the last part of the work.

3.2.1

ISO 13407 UCD

ISO 13407 standardize the User-Centered Design process. The standard describes four principles of UCD; the active involvement of users, the correct allocation of function to the system and user, the iterative design process, and the multi-disciplinary design. The standard also describes four UCD activities; understanding and specifying the context of use, specification of organizational and user requirements, the production of multiple possible design solutions, and the evaluation of design towards requirements [4]. The ISO 13407 describes four main faces of the Human Centered Design process. They are described in figure 3.1. The model is iterative and several rounds are usually done before completion. The four stages can be further described like this [55]: 1. Specify the context of use Identify the user of the product, the purpose of their use and where, when and under which circumstances they will use it. 2. Specify requirements Identify business requirements and user goals that are required for the product to be prosperous.

3.2. User-Centered Design

7

3. Create design solutions Create the design from a concept to multiple possible solutions and finally a complete design. 4. Evaluate designs The last part in each of the iterations is the evaluation against business and user requirements. Preferably with usability tests performed on actual users and software quality testing.

Figure 3.1: The four main stages of the Human Centered Design process according to ISO 13407 [40]

3.2.2

The Schaffer-Weinschenk Method

Technical staff on Human Factors International, Inc. has for more than 20 years worked with an optimized method for user experience and performance. This method is named the Schaffer-Weinschenk Method and can shortly be described in the following steps [40]: 1. Plan Project Which are the main activities? Who are the adequate staffs? How much time is needed? Which amount of usability work is required? 2. Evaluate the Current Applications Which improvements can be made on current applications? How do competitors do? 3. Know What the Organization Wants What rules and directions does the business in the organization require? 4. Know What the Users Want What kind of different users are there? What needs do these users have? Collect a solid base for the user understanding. 5. Design the Structure How should the structure be so that the users understand what is offered, find things quickly and easily, and navigate efficiently?

8

Chapter 3. Methods

6. Check Standards Which standards and guidelines can be used to save time, improve design quality, present consistency and help concentrate creativity? 7. Design Screens When the navigation and standards are identified, create screen designs. 8. Support Implementation Give the functional specification and screens to the implementation team. Support them during their work. 9. Evaluate Usability Make a usability test of the whole application. Keep monitoring site performance, which already shall be in progress. This method is an iterative UCD process and has been used as support in the thesis progress.

3.3

Personas

Designers of software aimed towards mass-market can not confidently identify specific users for their software. Finding representative users is a challenge and it is hard to find representatives for all types of users [22]. Personas are archetypal users aimed to direct the concept and design. They identify user motivations, expectations and goals when using the product of service. The personas are fictional but based on knowledge of real users. To make them live, it is common to give them names and photos. They are also often given an age, address, family etc. A good way to further describe a persona is to write scenarios for common tasks [48]. In fact scenarios not based on personas are less effective. There is in fact common with none, or little discussion on the data on which the scenarios are based. When constructing personas it is found that extreme characters are not necessary. Extreme characters can too much stereotype the user and make the design to specific. Personas can be more or less detailed and detail level shall focus on the knowledge necessary for the design [22]. The major benefit with personas is to allow the developers and designer to not design for themselves or executives, but to design for the typical user. The goals of different user types, brought to life by personas, enable the development team to create good solutions for many users. Personas are relatively quick to create compared to collecting requirements for the whole user community. They may not be as accurate, but saves a lot of time [9]. Personas are great when needing to narrow down and prioritize potential features and options. They also help creating the correct labels in menus etc. Labels making sense to a designer might not at all be clear to the user, thinking about the persona can make the designer create better labels [48]. Further do personas help to consider different political, social and cultural aspects of different users. Personas are great when motivating user needs, design choices and features for all types of stakeholders. A persona shows to whom the design is aimed for, but can also help to exclude who is not [22]. Personas help to solve disagreements in design solutions by referring to their choice. The design can be evaluated to personas as an alternative to expensive usability tests. However, personas do not ensure a product to be easy to use and learn, usability tests are still needed for this [48]. It is important that the business goals are considered in order to create a succesful design, a design not meeting them are not feasible even though it is meeting the persona goals. The most common pitfall with personas is that they are based on marketing and sales data and not from in-depth interviews. This often make the design fit the wrong users than the actually targeted ones [48].

Chapter 4

Context Analysis This chapter described the different ODP customers and a brief description of the technology in the ODP. Furthermore, an analysis will be presented of competing ODP solutions. Following that, two case studies where the content is in main focus are described. Moreover, a customer content analysis which describes what kind of content the user wants is presented and at last there is summary of an evaluation of an ODP Demo client from Ericsson.

4.1

Customers

Four types of customers can be identified for ODP software enterprises. The first customer is operators, requiring a technology platform for supplying attractive services that raise the data traffic on their networks and maintain their brand recognition across different handsets. The second customer, is the content provider, e.g., media brands that target mobile users. The third customer, is the manufacturer of handsets looking for a technology that can help them to easily deliver operator-specific handsets. The fourth and last customer is the end-user that indirectly influence the OPDs because it is their user experience that the solutions address. ODPs provide an on-device user interface, easy to customize for the customers. This helps users to feel affinity to the brand and increase customer devotion [13]. Notice that ODPs are not positioned to replace the entire phone user interface; they are about distributing and give value to data services in a usable way.

4.2

Technology

ODPs are mainly made as client applications on the device. It can be high-end open OS devices, e.g., Symbian OS and Windows Mobile enabling easier home-screen replacement. Other techniques as Java, BREW and RIM versions are also used but have not the same possibility for home-screen replacement. Another important aspect of the ODP technology is the graphic rendering capabilities. High quality graphics and smooth transitions are important for the user experience. The ODPs also need to be able to use the device for pushed and proactively cached data and messaging functionality. 9

10

Chapter 4. Context Analysis

Server-side componenents are an often used part in the ODP package is server-side components. The server-side features content life cycle management, usage tracking and reporting, user management and client lifecycle management. The whole client GUI can be defined on the server, and changes in the GUI will be automatically updated when the client is loaded on a handset. The server-side usually also integrates with the operator’s billing system. The last part that ODP vendors provide is content and layout authoring tools which are crucial to realize and preserve successful ODP products.

4.3

Competitor Analysis

The market of OPD developers is growing and there are many companies trying to bind the operators to just their client. In this section some of theses companies are presented with a screenshot from either the ODP or some other application similar to the ODP. This will give a short brief of what is available on the market today. All facts are from an internal Ericsson study. Abaxia

Figure 4.1: Abaxia Mobile Portal Abaxia is a company that sells ODPs to mobile operators and manufacturers. The ODP is built up to consistently customize the home screen across a variety of open OS and proprietary handsets. The application can work as a service discovery dashboard, and is available as a white-label product for mobile operators and manufacturers. The application provides 2-click access to operator services, device services and message functions. The user can, among other things, personalize wallpapers and shortcuts.

4.3. Competitor Analysis

11

Action Engine

Figure 4.2: Action Engine example of Brand-n-Go Action Engine has an application named Brand-n-Go which is an offline portal for operators. The application focuses on delivering content, such as eBay, Amazon.com and restaurant finder. One advantage with the application is that the user can explore and create search requests offline before sending them to the network. The applications can use device functionality such as email, contacts and calendar which makes the application more powerful. Another different aspect is that Action Engine works directly with content providers to source the content, but sells through operators. Although Action Engine is not a direct competitor to other ODP vendors, they often compete for the same budget. Adobe FlashCast FlashCast is Adobe’s client-server offline portal application that enables content to be delivered to handsets and browsed as TV channels. FlashCast is based on the Adobe Flash Lite platform, which is the light, or mobile, version of Adobe Flash. FlashCast is made up of a group of channels which makes it easy for the user to discover and find his or her favorites, and it is all presented within one consistent navigation scheme. Users are able to add and remove channels, specify their channel preferences and refine the behavior of individual channels. Openwave Openwave was one of the founding members of the WAP forum. Today they are building more advanced applications and one of them is the Mobile Integrated Dynamic

12


Figure 4.3: Adobe Flash Cast example

Figure 4.4: OpenWave client example


13

Application System (MIDAS). MIDAS is an environment which focuses on lightweight applications and makes it possible for applications to run on top of its new application environment. The focus areas Openwave has been working with is for a instance homescreen replacement applications, media store-front, service advertisement client, music download, ”blogs”, and photo-sharing. Openwave is known to be a leader in the second wave of heavyweight ODP vendors, which make them an interesting competitor. SurfKitchen

Figure 4.5: SurfKitchen example client SurfKitchen offers one of the most feature-rich and widely deployed ODPs for operators in the market. Their client-server solution has a versatile product mix which can satisfy the various operator requirements. SurfKitchen was founded with the focus on mobile portals and is now working with ODPs and home screen applications. Their ODP named ”SurfKit Offline Portal” extends the operator portal to the devices and can supply the end-customer with information, which is cashed proactively for less waiting time. Opera Platform Opera is known as a web browser vendor for desktops and mobile devices. The Opera Platform is a browser based application for operators who are looking for a standardbased, low impact ODP. It can deliver service advertising, such as news and content teasers. Device and messaging information, such as battery status, signal strength, inbox/calendar summaries, and missed call alerts can be displayed on the home-screen. Once the user clicks onto a home-screen item, they are taken online through the Opera browser. One of the benefits is that the service development is purely browser based which makes the development cycle faster, although not without loss in the user experience.

14


Figure 4.6: Opera platform example Yahoo! Go Yahoo! Go is an ODP which lets the user send e-mails, upload photos, download maps, check stock quotes, or get news. The user is provided with updates like how many new emails await you, upcoming calendar appointments, and new photos posted by your friends since the last login. The user can choose from a selection of mobile applications from Yahoo as well as other web brands and add them to the portal. The portal is also fully customizable to fit the user’s needs. OnSkreen OnSkreen is targeted towards operators and has an application named Fusion. Fusion is a home-screen replacement client-only application that acts as a service dashboard. The big advantage with OnSkreens application is that it is not using any server components which make it easier for the operators when it comes to deploying. This can also be an advantage for smaller operators or those in emerging mobile markets.


15

Figure 4.7: Yahoo! Go 3.0

Figure 4.8: Onskreen ODP example

16


Main menu Home TV/Video Music Games Community www News Vodafone (service)

Sub menu 1 Top News Mobile TV Music charts New Games Community Web link site Latest news Mein Vodafone

Sub menu 2 What’s hot? Video Music-mix Top Games Flirt, Hot or Not? URL address bar Sport news Advice/Tips

Always visible Search bar Options -Update -Settings -Help -Info Quit Main menu

Table 4.1: Vodafone Live! Germany ODP content overview.

4.4

Content

This section takes a deeper look into the content provided in the Vodafone Live ODP and the content in Apple’s App Store. This will give a better understanding of which content an ODP can contain.

4.4.1

Case Study - Vodafone Live ODP

Ericsson has delivered an ODP to Vodafone in Germany. Table 4.1 describes the content in this ODP and Figure 4.9 shows a screenshot of it.

Figure 4.9: Screenshot of Vodafone Germany ODP The Vodafone ODP presents the content which links to WAP browser pages. Music can be pre-listened (or downloaded) and starts directly when pressed. TV and Videos start a link to the WAP browser where they can be viewed. Games can be bought

4.4. Content

17

through a link to the browser where a WAP page displays the price and download link. The community content links to WAP browser sub content. The WWW is a web/WAP browser with search bar. The News page shows News feeds linking to further reading in the WAP browser for each item. Finally the Vodafone Service page shows content selected by Vodafone concerning their services and content recommended by them, also this content link to WAP pages.

4.4.2

Case study - App store

Apple is, with their App Store, offering a wide range of applications organized in the categories below. These categories give an overview of possible applications and content that will be available for mobile phones. The categories of applications [2]: – Books – Business – Education – Entertainment – Finance – Games – Health & Fitness – Lifestyle – Music – Navigation – News – Photography – Productivity – Reference – Social Networking – Sports – Travel – Utilities – Weather The Apple products iPhone and iPod Touch is more or less an ODP itself where downloaded applications are shown on the same level as all other handset features. This is different compared to all earlier handsets where applications are hidden in a file manager or deep in the menus.

18


4.5

Customer content analysis

Ericsson Consumer lab [19] has made a study of which content that consumers find most interesting for the ODP. The study covers eight markets all over the world and shows that the ODP concept is relatively positive received, especially in India and China. The most important features amongst all customers are accessing e-mail, browsing maps and getting directions. The second most intriguing features are playing games and paying/refilling mobile phone bills. Thirdly there is a wide interest for browsing and searching the web. Among the younger audience is chatting, seeing online status, and location of contacts popular features. Local markets have different preferences that must be taken into account in the design. Looking into specific features and comparing them to the overall average the study shows that: – Accessing files, doing other stuff while downloading content and seeing if friends are online are stronger in India. While browsing and buying from specific web sites are of lower interest. – Refilling/paying phone bills and chatting with contacts are of more interest in China. – North America likes the ability to browse maps and access e-mail. While accessing files and browsing/buying tickets lower than overall average in US and Canada. – Accessing e-mail seems to be of high interest in all European markets.

4.5.1

General content organization

The three general parts of an ODP identified in the introduction; the Storefront, the Application Launcher and the Home/Idle Screen can be supplemented with a Media Portal. The Media Portal is often a part showing news feeds, but can also provide video clips and mobile TV etc. With these four parts most sub content can be organized. As a general example the content can be organized as the following: The Home/Idle or Start screen – Favorites: Applications, feeds or widgets etc. – A search bar: for web or other ODP content – The navigation menu that is always visible – Operator content: for example a logo – A sub menu containing for example: account balance and network information, themes and skins for the ODP/handset. Personalization and customization possibilities.

4.5. Customer content analysis

Media Portal – RSS feeds Search for new feeds Add new feeds Remove feeds Organize feeds – Personal feeds: for example latest Facebook or MySpace notifications etc. – Non-personal feeds: for example news feeds, sport feeds etc. Storefront – Buy; Content that can be bought Search content Top list Categories: Games, Music, Videos, Map applications etc. Add content to the ODP – Free; Content that is free Search content Top list Categories: Games, Music, Videos Map applications etc. Add content to the ODP – Favorites The user’s favorites Application and Widget launcher – Manage Remove Organize – Applications, for example: E-mail Maps Chat (MSN, Status etc.) TV CNN Media Portal – Widgets or similar, for example: Weather Stocks

19

20


The way to organize will be furthered analyzed in the design phase through card sorting and user interface mockups. These are described and discussed in the design section.

4.6

Heuristic evaluation of Ericsson ODP Demo

Ericsson research has done an evaluation on an Ericsson ODP Demo Client. The focus of the evaluation was to examine the interface in aspects of usability and user experience. Six persons with experience in usability and interaction design did a walkthrough of the interface and came up with some issues, which will work as input to later development of the client. No end-users were involved in the study and all evaluators performed the same tasks. Each evaluator had 60-90 min when doing the tasks and there were two different devices used. The tasks were based on traditional usability and user experience guidelines [18]. The general opinion about the ODP demo was: – Pleasurable design, but very inconsistent look and feel – The Media Portal provides a good overview and a smooth navigation for service and application updates – Slightly complicated navigation and categorization of content – The application loads quickly – The content presentation for each part gives a good overview of what is available – The responsiveness of the application is good, the animations are in general fast – The three different parts of the application are always available on the main menu From the result of the evaluation these ”guidelines” can be constructed: – Give feedback about internet connectivity and costs – Use a consistent design – Keep the animations simple – Use a simple language – If scrolling is available it should be possible to go directly bottom to top – If soft-keys are used, use them consistently – New and updated information should be more visible – If lists are used, it should be possible to see how many items they contain – Give feedback about download status

Chapter 5

Usability and user experience testing on mobile devices Author Fredrik Bj¨ ornski¨ old The aim of this chapter is to describe the user experience and usability in mobile phones, and how testing and evaluation can be done. The chapter starts with a brief introduction to user experience and usability. Thereafter, there is a section about designing for user experience and usability, followed by a section about testing methods and difficulties. In the end there will be a discussion and a conclusion with guidelines.

5.1

Background

“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.” -Definition of usability [28] “Every aspect of the user’s interaction with a product, service, or company that make up the user’s perceptions of the whole.” -Definition of user experience [5] In the recent years the field of human-computer interaction has been more and more used in the mobile device market. Designing these products from a human-computer perspective has been in focus. The difference in interaction style and screen size from a regular computer application has been some of the biggest challenges for designers in the market [7]. This challenge is one of the most important when it comes to design. The goal of usability and user experience is to ensure that the product or service will provide a good design and make the user feel that he or she has control and feel satisfied with the artifact. Designing a product or service which mediates a feeling where the user can feel that the artifact is easy and logical to use is of furthest importance. If the user also can get a positive emotional experience the designer has come to an excellent point in product design. However, in spite of everything good usability and user experience will result in a successful artifact, and the user will be more welcoming to adopt new services and concepts [45]. Today application designers are more aware of the user and the environment users use the products in. This is important because the environment and context of use is 21

22

Chapter 5. Usability and user experience testing on mobile devices

affecting the users experience and the way of using the application. Capturing the user experience is important and an interesting research issue. Techniques like interviews, observations, surveys have been used with different results. One problem with user experience and its evaluation is the understanding of the topic. Arhippainen and Tähti [3] think that one reason for this could be shortcomings in the definition of user experience and the relation to usability issues. Designing usable applications is tricky and there is no obvious way to go. The best and easiest method of making an application usable is to test it. The testing should be done early in the design process and preferable during the whole process. Giving the application to a potential user and letting them perform some tasks is one of the best ways to get a feeling of the user behavior. When doing this in every step of the design process you will get a good picture of potential usability issues [36]. This may sound rather simple, but doing an evaluation in mobile environments is associated with some practical problems. Doing a standard laboratory test with a mobile application loses the aspects of the ”normal” environment. And when doing tests in real life, aspects like data collection methods, user mobility, and observation methods makes everything a little bit more challenging [30, 36].

5.1.1

User experience

User experience can easily be described as the experience a person gets when he or she interacts with a product or service. The user experience is among others influenced by the environment, social factors, cultural factors, and of course the design of the product or service. The user aspects involved are for instance values, emotions, expectations and former experience [3]. These aspects are interesting and important when evaluating the user experience. User experience is trying to aim for a more holistic view than traditional usability [45]. In addition to the factors above user experience also includes aspects of utility, reliability, and technical performance as well as more consumer experience factors like pricing, advertising, and brand [13]. Designing a product which creates a positive emotional impact on the user is one of the key factors in user experience today. Succeeding with this can make the product or service different from other products or services [45]. And with more and more mobile subscribers’ world wide, the user experience and emotional impact are important factors when catching new users. And it is not just a catchphrase of the industry; it is rather the way companies need to go to drive growth [14]. When evaluating user experience it is important to do this early in the process. Naturally it is easier to evaluate existing products or services because the user has already used it for a time, and hopefully the user has got an experience of the product or service. However, evaluating new products is important and of course more challenging. Trying to find out if the right experience is mediated can sometimes be hard with just a paper prototype or concepts. Still, we need to find out if the product or the service will mediate the intended experience before it is on the market. We cannot have longrunning studies on a prototype that do not work, and we can not evaluate the ’real’ user experience when the system is just a concept on a paper [50]. The emotional experience is another important element in the whole user experience. We assume that the perceived qualities of the interactive system play a role in the appraisal process of emotional consequences. Overall judgments of products, decision for an alternative or the usage behavior, are influenced by the perception of quality

5.2. Designing for user experience and usability

23

aspects and the emotional experience [37].

5.1.2

Usability

Usability has many different definitions and more or less different descriptions. The quote in the beginning of section 5.1 is the ISO definition of usability. That is a one of many descriptions of usability, but we can not forget that usability is not only the property of the product itself. The concept usability is the view of the entire system, which is the product or service, the user using the system, the user’s needs and goals and the environment where the system is used [45]. Usability is often described as how well a user can learn and use a product or service and then achieve the goal of the user, and how satisfied the users is with this process [56]. One thing that scientists [56, 44] can agree on is that usability is ’defined’ by five aspects or components: – Ease of learning - How easy and how fast can a user complete a simple task the first time he or she uses the system? – Efficiency of use - Once the user has learned the system, how fast can he or she perform tasks? – Memorability - When a user returns to the system after a time, how easily can he or she use the system effectively? – Error frequency and severity - How often does a user make errors while using the system, how serious are these errors, and how does a user recover from these errors? – Satisfaction - How much does the user like the design of the system? These five aspects are important for a good usability. However, there are many other important attributes and one of the most important is utility. According to Jakob Nielsen [44] utility and usability are equally important. Utility refers to the design’s functionality and Nielsen’s motivation is that you are not going to use a system if it is not doing what you want, even though it looks good. And the other way around, if the functionality is great, but the user interface is too difficult to understand. To evaluate and test a system’s utility you can use the same methods that improves usability. So, why is usability important? According to Nielsen, in an example with web applications, it is necessary for survival. If the usability is bad the user will leave the website which will result in different problems. If we take an online shop for example, if the users cannot find the products they want, you will not sell anything. Leaving is the first thing a user does when he or she do not find what they are looking for. Furthermore, Nielsen states that 10% of a design budget should be spent on usability. This will, on average, double the quality metrics on websites and for other software and hardware products the improvements are smaller but still substantial [44].

5.2

Designing for user experience and usability

There are no shortcuts to ensure a good usability and user experience in products and services. The only way to reach a satisfying result is to include the user’s needs and requirements from the first stage of the process. Keeping the user’s aspects through

24


the process and all the way to after-sales stage is crucial when a good usability and specially user experience is wanted. To understand the requirements and needs of the user, verified information is needed. The user’s goals with the product or service shall be clearly known by the whole development group. This is important because all parts like implementation and design should be based on these goals. To control that these goals are being fulfilled during the development process testing and evaluation shall be performed as often as possible. The earlier design problems are discovered, the cheaper and easier it is to fix them [45]. When designing for user experience the principle of metaphors can be used. Metaphors have its power in illustrating unfamiliar entities with familiar similarities and in that way help the user to understand the unfamiliar entity. This is a good principle if it is used in a correct way. However, there are designers who do not like metaphors because they think it is an imitation of real world entities or just a simulation of it. This is something that the designer has to think about, and work out with the users and the development group [49]. Conceptual models are another principle that can be used when designing for user experience. The user’s conceptual model can be used to answer the question “Why and what is happening?” in specific tasks. To get this information, or model, from the user, the development group has to collect information through task analysis, surveys, and user requirement lists. The uses can also provide the group with this information through usability studies where the user interface for example is begin evaluated [26]. When should the usability and user experience work be done? As said before, in each step of the process and as often as possible. Jacob Nielsen [44] states that multiple studies are faster and cheaper and will enhance the usability and user experience of the product or service. The main steps he proposes are: – Test the old design before starting the new design. This will help you to see the good parts and the bad parts with the old system. – If possible, look at your competitor’s design. This may give you inspiration to the new design. – Study the users in their real environment. This is better than testing in a lab environment. – Make fast and easy prototypes of the design. You will change the design based on the test results so do not spend too much resources. – Use multiple iterations when designing. Go from low-fi prototypes on paper, to more hi-fi prototypes and test each of the iterations with users. – Study your design with established usability guidelines in mind. – When you implement the final design, test it again. Usability problems may have occurred during the implementation. Do not wait with the user testing. If you wait too long and find problems, it will cost more and needs a larger structural redesign. Nielsen also suggests that user studies should be performed once a week with real users [44].

5.3. User experience and usability testing

5.3

25

User experience and usability testing

Usability testing is today an invaluable tool when developing new software. It is a well established discipline within human-computer interaction with many well-known techniques and methods [34]. User experience testing is coming more and more when the concept of usability is moving closer to user experience. When the user experience concept is growing it is important that all involved people in a development process are aware of the user experience targets. This will help to communicate and keep the focus on the right track. If it is possible it may be good to communicate these targets between groups, which will make it easier for different teams to work toward a common goal [50].

5.3.1

Methods

Within the field of user experience and usability testing there are many methods that can be used. The most basic and useful method is according to Jacob Nielsen [44] user testing. The basic version of this method has three components: – Find some users which are representative for the subject – Let the users perform tasks with the design – Observe the users, where they do well and where they have difficulties. Let the user do the talking. This is a very basic method and enhances the possibility for further development. However, many methods build on this base. When applying the user testing method you get two major result benefits: you will see the users interact with the product or service instead of just looking at it, and the second benefit is that you can measure user behavior. This is a difference from for example focus group, where opinions are measured [36]. Interviews are a good method when is comes to user experience evaluation. One of the benefits with interviews is that it is more like a normal chat. This can make the user more comfortable and calm. Interviews make it easier to get information about the user’s background, experience, expectations etc. The problem is that it can be harder to describe feelings about the test object. In those cases the evaluator has to ”read between the lines”. Interviews can easily be combined with other methods such as user testing or surveys [3]. Arhippainen and T¨ ahti [3] states that surveys, diaries and storytelling are effective methods to get information about user experience. What is beneficial with these methods is that the user can express experiences in written form. And stories can help humans to organize experiences and communicate them to people involved in the evaluation. Evaluating mobile technology in laboratories is problematic. The problems can be that it is too time consuming, relatively fixed usage, and that the tasks must be performed during a reasonable period of time. To overcome these problem there are alternative expert-based methods like heuristic evaluation and cognitive walkthrough. These methods may help the evaluators with guidance for identifying a list of usability problems. Both methods build on the idea of an expert inspection of the product or service and hopefully find usability problems. However, inspection methods like the above have been criticized for finding fewer problems in total, and often more cosmetic problems [34]. Figure 5.1 shows a diagram of how many usability problems are found with an increasing number of users. This is Nielsen’s [44] measure and he says that testing five

26


Figure 5.1: Why you only need to test with 5 users [43] users is often enough. The time and money spent on more users will not pay back in problems found. He states that instead of increasing the number of users, increase the number of iterations.

5.4

Difficulties

With an increasing collection of testing methods the difficulties increase as well. Different methods have different difficulties which must be considered before choosing a method. The difficulties discussed in this section are not method dependent but rather general difficulties when testing. The first thing to decide before starting an evaluation or test is what the goal is. There are so many factors in user experience and usability so a clearly stated goal is important. This may not always be easy to determine, but will in the end make the test or evaluation more systematic [3]. Once a project has started it is time to verify the user experience targets for the product or service. It is important to early in the process verify if the targets are the right ones. This may be done with a user experience evaluation. The difficult part here is that targets always refer to the future and may be hard to perceive in advance. The tip here is to use reviews or interviews from experts, which may have more experience from other projects, to study the user experience targets [50]. When testing is performed it is very important to find the right participants. This is particularly important when performing early lab evaluation where user experience data is hard to collect. The participant can be unmotivated to do pre-planned tasks on a early prototype, and this may affect their experience. If the user experience targets have been clearly stated, as said before, this can motivate the participant and make the

5.4. Difficulties

27

evaluation result better [50]. When testing mobile applications it is important to find out which devices the majority of the target group uses to access your application. If the result is a smaller number of devices, plan to test them all with your application. If the number of devices is too many, try to group the devices in to different families where the user experience is similar. It is also possible to group them together according to device functionality or other characteristics. If you only have one test opportunity or a small budget then you should go for the most limited device. This is because it will hopefully work better on the other devices. If the evaluation process is iterative should a new device be tested in each iteration [36]. Mobile applications are designed to work in a mobile context. This means that they also should be tested and evaluated in a mobile context. Laboratory testing is good when it comes to collecting high quality data or experimental control, but is weaker when simulating a real ”mobile environment”. Laboratory testing should therefore be complemented with real life field studies. This will make the testing more realistic when other activities are taking place at the same time [30, 34]. The problem with field studies and established methods for testing user experience and usability is just the ”field”. Camera recording of what is happening on the screen or shadowing the user is hard in a live environment. Another problem is that the data collection is even harder when the user is moving around in an environment which we do not have control over. What can be used is software which can record what the user is doing in the application; this will not give any information from the environment though [34]. Another difficulty is the distraction that mobile users are dealing with during their use of the device. This distraction can be used in an evaluation or test. How this should be used depends on what should be tested. Little Springs Design [36] proposes two different approaches: – In a formal statistical usability test should the distraction not be used. Introducing distraction can interrupt the statistical validation in the test. – In a more in formal problem-finding test the distraction can be used to make the situation more realistic. Testing the application in the user’s normal working environment or in a café is better than in a laboratory environment. If the application can be designed to prevent for the distraction in the second approach, the design will work better overall. Handling the data collection when doing tests and evaluation on mobile devices can be tricky. Mobile devices are intended to be held and not fixed, like a desktop computer is. They are also more personal and the user may do other things with it like gesturing with it or lean back in a chair with it. When performing tests and evaluation cameras are often used to record the user interaction with the application. Making a camera following a user’s moves and gestures is hard. A solution to this problem is a product from Norm Wilcox Associates. It is a device with two small cameras which can be connected to the mobile device. One camera is pointing directly at the screen and the other one is pointing at the users face, is the user is looking at the screen. It is not very small and flexible, but is better than fixing the mobile device and pointing a camera at it (see figure 5.2) [36].

28


Figure 5.2: Test device for mobile devices [36]

5.5

Discussion

The definition of usability and user experience may differ from source to source. When working with these subjects, following a general definition may not be the most important. What is important though is that the goals of the work are well known in the group and maybe in the entire company. If all involved parts know the common goals, and work toward the goals, the result will be better. Usability and user experience both focus on the user. This must be well known by all involved people. Including the user in the development is important, and should be made as early as possible. If the user is involved in the entire process, the result will hopefully satisfy the user’s goals and desires. The methods presented in this chapter are just a few of all available. There is no standard method that should be used on certain evaluations and test. And all methods can be suited for the specific task. This means that when setting a test or evaluation up, more than one method should be considered and maybe a mix of more than one method is the best for just that test or evaluation. If the knowledge about testing and evaluation is not available in a project, the phase should not be left out. Taking someone in from another group or company may be a good option, and can furthermore give even more back in feedback because they have not been involved in the process. Where and when users or experts should be used is another hard question. The best solution is to evaluate with both users and experts. What will been seen in this Master Thesis is that experts are better at identifying the specific usability problems and the users give good feedback on the user experience. So, if time and money is no problem,

5.6. Conclusion with guidelines

29

a mix between experts and users is a good idea. Testing in the user environment is something discussed in this chapter. This is important because it gives the evaluation a more realistic touch than sitting in a quit room. The problem is that the data collection becomes harder, but there are technical solutions that may be used. Another way to test in the user environment is to use the service or product for some time in their daily life, and then evaluate their experience. This is something that relies on a good relationship between the users and the evaluators though.

5.6

Conclusion with guidelines

Usability and user experience testing and evaluation is often not included in development project until last phase. In many cases the time and money can be settling factors. Mobile application developers are often under a stricter deadline and have to deal with more complex testing and evaluation environments. This may sound like they do not need to tested as much as a regular computer application. In fact it is the opposite. Mobile applications have a more limited screen size to operate on, more limited controls, and as mentioned before, a much more complex environment. It is therefore necessary with frequent usability and user experience testing. This will ensure that you make a product or service as good as possible [36]. To conclude this chapter some guidelines for user experience and usability are presented, which may be taken into consideration when designing mobile applications. Communication New services should be communicated around a user task instead of a new technology. This may help the user to easier pick up the new service [13]. – Use standard components - Help the user to understand what different words, situations, and actions mean. Be consistent when designing [41] – Let the user feel that he/she is in charge of the system - A better feeling than that the system is controlling them [21] Discoverability Even though a user is aware of a service, it does not mean that he or she knows how to access it. A menu in a mobile application should for example be available instantly to help the user find what he or she is looking for [13]. – Use a design which is easy to remember - This may speed up the user interaction when a user returns to the system after a time [56, 44] – Entice the user to explore the system - Make the user motivated to use the system [59] – Use a consistent navigation - Standards and guidelines should be followed in order to not confuse the user [59] – Help and documentation shall be easy to understand - Use a good language, step by step guide how to solve a problem, and focus on the user’s task [41]

30


Accessibility Content within a mobile application shall not be too many clicks, scrolls, or menu selects away. Do not make a labyrinth for the user to find what they are looking for; make it accessible for the user [13]. – Services should be accessible - They should be easy to find, set up, and use [14] – Reduce the number of operations needed to perform regular tasks - This will speed up the user interaction [21] – Design for speed - The application should be up and running quickly [21] – Do not show irrelevant information - This information may compete with the relevant information [41] Ease of use When the user has found what he or she has been looking for it is important to make the content easy to use. This could for example be if a user wants to buy a new ring tone or wall paper in a mobile portal. The process from previewing the content, buying it, installing, and in the end using it should be easy to understand and operate [13]. – Inform the user about what is going on - Give the user appropriate feedback [41] – Minimize the user’s memory load - Make information visible to the user [41] – Make instructions for the use of the system visible - It should be easy to retrieve help and information whenever the usef needs it [41] – Use a language which the user understands - Do not use system-oriented terms or too technical language [41] Personalization Even if the service has a good content, users will get tired of it. This makes personalization important where the user can get relevant, personalized, and updated content [13]. – Allow user to tailor frequent actions - This may speed up the interaction for the user [41] – Use accelerators - Good for the experienced user, and the novice will not see it [41] – Support undo and redo - Give the user freedom [41] – Services should be aware of context - Providing relevant and convenient services may enhance the user experience [14] – Services should be personal - They should fit the user, his/her device, and the connections used on the handset [14]

5.6. Conclusion with guidelines

31

– Find the right balance - The right balance between information and entertainment is crucial for a good user experience [59] – Use fresh content - If the content is old the user may not use the system [59] Education There are still users that do not uses mobile application because they are afraid of costs from data traffic. This is something mobile application developers need to educate the user about [13]. – Help the user - Give the user a solution if a problem occurs [41] – Show what is free and what is not free - Let the user navigate the system for free, and charge the user for downloading and shopping [13] – The system should be easy to learn - Make the system easy to understand and learn [56, 44]

32


Chapter 6

Designing for touch screens on mobile devices Author Robert Johansson This chapter deals with technological and design solutions as well as problems when designing for a touch screen software user interface. First there is and introduction to the subject and then touch screen hardware and software solutions are overviewed. These findings are summarized into a set of touch screen design guidelines. Finally there is a discussion and some conclusions are made.

6.1

Introduction

The world-wide introduction of iPhone 3G and the answer to this from competitors will make touch screen mobiles an important interface technology to develop software for. According to Cellular News and the IMS research [10], the market share for touch screens devices are expected to be about 30% in 2011. With this knowledge, the specific criterions concerning interaction methods and design for touch screens will be important to research in order to create successful software user interfaces. This study looks into theory regarding designing for touch screen devices usually operated with only one hand and a single finger (usually a thumb). Other input methods such as the use of stylus, audio and accelerometer (tilt) are not considered deeply. The focus is to provide design guidelines for touch screen interfaces operated by a single finger click at the time. Other ways of interaction are revealed but no guidelines are provided for them. As an inspiration this quote from the usability guru Bruce ”the Tog” Tognazzini about the iPhone implies the importance of making products using advanced technologies accessible for everyone: “What’s important is that, for the first time, so many great ideas and processes have been assembled in one device, iterated until they squeak, and made accessible to normal human beings. That’s the genius of Steve Jobs; that’s the genius of Apple.” [54] The main motivation to focus the study on one-handed single finger operation is inspired by Karlson [33] that found the majority of users preferring to use their mobile phone with one hand. Other motivation comes from, also with inspiration from Karlson [33]; the environments where mobile devices are used often only support one free hand, e.g., 33

34

Chapter 6. Designing for touch screens on mobile devices

carrying a bag with one hand and operating the device with the other hand. A third motivation is that one-handed touch screen designs fit most, if not all touch screen devices and require a simple and highly usable interface. A simpler user interface is easier to fit to different screen sizes and orientations, making the wide range of display sizes and resolutions easier to access when designing software to match different hardware.

6.2

Touch screen hardware techniques

There are several ways to construct a touch screen. Each technique has its benefits and constraints. This section gives an overview of the currently most common ones.

6.2.1

Resistive

Figure 6.1: Resistive touch screen The resistive technique is today the most common type because of its low cost [39]. Resistive touch screens use a transparent touch membrane above the display. The touch membrane consists of two layers separated from each other with air spacers. When the screen is pressed the air space shrink causing the top layer and the bottom layer to connect which is locating the action [53], see Figure 6.1. When calculating the precision of a touch it is often measured as the average pixel of the finger which gives a lower precision when hitting small targets [33]. The top layer is a moving part that wears over

6.2. Touch screen hardware techniques

35

time causing worse performance and requiring repeated recalibration. The sensors are hard tuned to work well with both fingers and stylus (pens). There are also problems to have the touch membrane above the display; light, colors and reflections are influenced with negative results [53]. The resistive screen is, compared to others, the least durable one [29, 39].

6.2.2

Capacitive (Inductive)

Figure 6.2: Capacitive touch screen Capacitive touch screens use fields of stored electrons in the horizontal and vertical axes of the screen. Since the human fingers also contain electrons, the touch of a finger will cause a distortion in the reference field making it possible to locate the touch. A capacitive screen can not be used with ordinary gloves and styluses, but with special conductive pens the electron fields can be modified to detect a touch [53]. There are two main types of capacitive touch screens, surface capacitive and projected capacitive. The surface capacitive screen uses a small voltage in every corner of the screen and the touch of a finger causes a flow of electrons towards the finger, see Figure 6.2 [39]. Projected capacitive touch screens uses an array of very thin wires within the screen. These are often hidden behind a protective front surface. Each wire has an oscillation frequency. The touch of a finger causes a capacitive difference in the frequency of the wires around the finger. Through this the position of the touch can be calculated [16, 39]. Capacitive touch screens have higher light transmittance and clarity [39] than resistive; they can also be mounted behind the display and they have a have higher durability

36


than resistive displays. The technique is because of its physics sensitive to electromagnetic field interferences [29].

6.2.3

Infrared light and cameras

Figure 6.3: IR touch screen There are various techniques using different kind of light and image processing. One method is to use infrared light that is projected against the screen and IR-cameras to detect where it is reflected by a finger or similar. One way is to transmit light from two sides of the screen and place cameras (receivers) on the other two sides, see Figure 6.3 [29] The use of IR and cameras are also used in ”Frustrated total internal reflection”. A reflective medium is filled with light and the touch of a finger interrupts the reflection path and strength. The reflection then leaves the medium and becomes visible to a camera outside it [24]. Infrared touch screens have very high quality of the underlying image, they do not need to be recalibrated and they have very high durability. However, they have a slightly lower resolution on the touch surface [29].

6.2.4

Surface acoustic wave (SAW)

This technique uses an inaudible acoustic wave that is sent out on the display surface. On the edges of the screen there are transducers/reflectors that transmit/reflect sound

6.2. Touch screen hardware techniques

Figure 6.4: SAW touch screen

37

38


waves [39]. When a finger touches the display the acoustic wave is absorbed and the signal is compared to a reference signal, recorded when nothing touches the surface. The location of the touch is determined through the difference between the touch signal and the reference signal; see Figure 6.4 [35]. SAW touch screens have very high durability and transmits light very well. However the input device needs to be soft to absorb the acoustic wave and surface obstructions can cause false touches [29].

6.2.5

Single touch and Multi-touch

The concept of multi-touch is as simple as it sounds. Multiple touch points can be touched at the same time and a new range of combined movements gives the opportunity for new interaction models. For example the ”pinching” on the iPhone, causing a view to, e.g., zoom out when two finger are moved closer to each other and the opposite for zoom in [2]. Another advantage for multiple input is that more than one user can interact with the screen at once, this benefit is mostly gained on larger screens and not as useful on small mobile devices. For example Microsoft Surface table can respond to 52 simultaneous touches [38].

6.3

Buxton’s three state model

When using a touch screen, the states for the input are not the same as when using a mouse or joystick. Buxton’s three state model of graphical input describes the three states: (0) Out-of-range, (1) Tracking and (2) Dragging, see Figure 6.5. For a mouse the out-of-range state is when the mouse is not in contact with surface. The tracking state is when the mouse is in contact with the surface and no button is pressed, the cursor moves around on the screen. The dragging state occurs when the mouse button is pressed down, an object selected and can be moved, e.g., dragging an icon [8]. The mouse is an indirect input device, compared to a touch screen where the input is direct. In a direct device, the interaction is directly on display screen. When a pointing device working with a touch screen is out-of-range, it is having no effect on the system. However when the pointing device moves, it is tracking when it is out-of-range but the system does not know the location of it until the display is touched, see Figure 6.6. If looking from this point, a touch on the screen makes it jump directly from state 0 to state 2. Another point is that if state 1 is used when the screen is touched, then state 2 is unavailable. The pointing (moving the pointing device, independent if it is in state 1 or 2), is a continuous task, and selection, is binary and represents a state change [8].

6.4

Navigation

The direct input when using a touch screen enables other forms of navigating on the screen. Gestures can be used to navigate and scroll in content. The design of these gestures and other interaction styles are important for the user experience of the system. Gestures should be natural and easy to understand. A problem with handheld devices is that the screen size is limited and the content (e.g., a web page, map or photo) is larger than the screen. Because of this efficient and convenient navigation in the additional space is needed [15]. This section looks into some suggested navigation techniques. All techniques are software based since the goal is to fit all touch screen devices and

6.4. Navigation

39

Figure 6.5: Buxton’s three states

Figure 6.6: Buxton’s states adapted for a touch screen. In this model the state goes directly from 0, out-of-range or passive tracking, to state 2 dragging or making a selection.

40


Method Single tap Double-tap Finger down and hold Drag and drop Gestures

Touch, release

move,

Common actions Click buttons. Higlight or select list items Activate/Load/Start an item selected with the first tap Equivalent with mouse rightclick. Touch and hold will show a context menu. Move an object. Reorder a list. Scrolling and panning. Touch screen and drag to move content of view Open a menu by touching it, and then slide to a specific menu item and release to trigger the item. Cancel action by dragging finger outside menu and release.

Other actions

Slide finger in a predefined pattern to trigger an action, as a shortcut.

Table 6.1: Basic ways of interaction and usage on a touch screen [52]

hardware based techniques is dependent on the buttons on the device. Table 6.1 goes through basic actions when interacting with a touch screen.

6.4.1

Zooming, Panning and Scrolling

Three basic principles when navigating in content are zooming, panning and scrolling. Zooming grows or shrinks the detail or size of the content, in other words changing its scale. Panning and scrolling move the workspace; scrolling in horizontal or vertical direction and panning in any 2D-direction. Scrolling is used for example when navigating in a document and panning is for example used when navigating in a map [25].

6.4.2

Touch-n-Go

Touch-n-Go is an alternative technique for panning in an information space. It is a software based technique using direct input on the display. The goal is to find a 360 degree operable panning technique. Scrollbars, for example, can only pan horizontally or vertically [15]. Tap-and-drag, or in more detail; tap down and drag an object on the screen, is a method shown to be preferred before scrollbars, but for mobile devices it is limited by the screen size. The distance a user cans tap-and-drag an object, e.g., a map is pretty short [31]. Touch-n-Go works by touching and keeping pressure on screen. The distance and direction relative to the center of the screen correspond to the speed (the longer the faster) and the distance the information space is changing. A touch in the upper right corner, e.g., when navigating a map will cause movement to NW in the map with a high speed. Navigation and selection of targets are differentiated by touch and hold or touch and immediate release. Users testing the technique felt it was fast and easy to use, but that the speed could be too high and overshoot targets and occasionally made the users hand cover information on screen [15].

6.5. Precision

6.4.3

41

Radial Scrolling

Radial scrolling is a technique offering a different way to zoom in or scroll content. The technique work just as well for scrolling/zooming documents as to browse through pictures. A difference from scrolling by pressing an arrow is that speed can be controlled. Radial scrolling use a circular motion around a center point (compare to iPod scroll wheel). The radius of the circular motion decides the speed of the scrolling, bigger radial faster and the opposite. Testing the technique showed that, when the target is close and where continuous scrolling is suited, radial scrolling will perform better than traditional techniques [51].

6.4.4

Speed-dependent Automatic Zooming

When navigating in a big information space with high speed there is a risk that motion blur occur which is hard for the user to perceive. One example is when scrolling fast in a long document. To avoid the motion blur, the user can change the zoom level before scrolling. This alternative will cause several interface manipulations. To avoid this, a technique called, Speed-dependent Automatic Zooming (SDAZ) can be used [27]. This technique automatically zooms out when navigating faster and zoom in when slower [12]. The technique allows navigation between focused and contextual views through a simple and natural interface (e.g., dragging the mouse), several separate controls are not needed [11]. When letting users compare traditional scroll, pan and zoom methods (e.g. scrollbars, buttons for zoom in/out and pan) participants commented that these are to separate, requiring to many interface manipulations for basically the same task. But during an experiment they were missing the lack of the spatial orientation provided by scroll bars, which easily can be added [12]. Several experiments show that browsing documents and maps are faster with SDAZ than with conventional techniques. These experiments were all made with a mouse, the use on a touch screen were not considered [12, 25]. Although, since handheld touch screens are limited in size the technique seems like a good idea when needing to present big information spaces. Furthermore, does the SDAZ requires less cognitive and manipulation effort and were in experiments strongly preferred to conventional manual controls [25].

6.5

Precision

Desktop user interfaces, where the WIMP (Windows, icons, menus, pointers) interaction style is dominating, and small targets are repeatedly selected, does not fit the touch screens well [6]. Further do small screens do not fit the same amount of information. One solution is to present the same information on several screens instead, but this is not always possible and might slower information access [32]. With a stylus, smaller targets on the touch screen can be selected easier than with a finger. The finger touch area is much bigger causing lower precision. Fingertips, the user’s hand, and arm might also cover targets making it harder to give feedback. This can give problems according to where the user thinks he or she is touching (where the cursor is) and where it is actually sensed or computed. The screen orientation and the layout of the software components can change if the user has to look ”over or under the hand” [6].

42


A benefit argued for direct touch interactions is that it is more ”natural” than working indirect with a mouse or another pointing device. This is hard to measure, but generally implied is that efficiency and accuracy are improved through the ”naturalness”. Comparing mouse and touch input has shown that the touch input is slightly faster than mouse input. However, the touch input has a higher error rate if the target is harder to reach. The reason for this was that the angle of the finger changes and the contact area gets different for these targets [20]. This might not be a problem for small screens on handheld devices, but that the angle of the finger can change the contact area during the touch, should be taken into consideration. Some techniques to help gain higher precision of selection on touch screens are suggested. Some use zooming as an alternative to hit small targets other have different solutions, one of them is Rubbing and Tapping [46]. Rubbing and tapping is a fluid technique requiring only one step. Rubbing is equal to rubbing the finger back and forth. Tapping requires bimanual input, one finger is held down and the other tapping the screen. Both rubbing and tapping causes a zoom effect on the area where it is executed. These techniques were combined with different selection actions and their performance was measured. Rubbing showed to be a good technique for smooth screen with low friction. Another technique to interact with small object on small touch screens is ”Thumbspace”, using a zoom area showing a miniature of the screen overlaying the full screen. The miniature is defined by the user and placed as well as sized where the user can comfortably reach it with the thumb. The user touches the area of the object it wants to interact with inside the miniature, and a selection square is shown in the full size screen. The selection square selects selectable objects, and moving the thumb in the miniature moves the selection between objects. When the desired object is chosen, it is selected by releasing the thumb. This technique can be used on systems intentionally used for stylus or mouse interaction, making it an alternative where new design is not possible [32]. A third technique, called ”Shift” uses a zoom circle, shown just above the finger, magnifying the area under the finger and showing a selection cross in it. With the zoomed area the user can select small targets with a higher accuracy. Shift maintains the ease and speed of direct touch for large target. Shift is also compatible with a regular pen and touch input making the interaction consistent when switching between pen and touch input. This makes Shift (as Thumbspace), work with existing applications with small targets [57]. Shift does not take areas hard to reach into consideration and Thumbspace is also not suited for targets much smaller than the thumb. However, these techniques used in combination can solve both these problems [32].

6.5.1

Target size

Parhi et al. have performed a study on the size of targets when interacting with a mobile touch screen using one hand. Earlier studies have focused on stylus interaction on a small mobile display or index finger interaction on a desktop-sized display. The difference with this study is the focus on one-handed thumb interaction. Since the thumb usually is the finger with biggest contact area, it sets the limit for how small the targets can be. During the study participants performed both discrete tasks on single-targets, e.g., pressing a button, and serial tasks, e.g., entering a text. The parameter of the targets location on screen was taken into account, because of the change of the contact area based on the angle of the finger. The use of left or right finger will also affect

6.6. Feedback

43

the performance, as it makes different sides of the screen harder to reach. One solution is to place interactive objects in the middle of the screen or make the design dynamic and place targets to the right for right hand users and the opposite for left hand. The conclusion was that a minimum size of 9.6 mm targets was necessary no to degrade the performance. The same recommendation for serial tasks was 9.2 mm [47]. To make it easier to remember, and since the difference is only 4-8 mm, a general guideline is to use targets larger than 10 mm2 for one-handed finger interaction.

6.6

Feedback

When using a touch screen the lack of physical feedback compared to using a physical button is clear. Three types of alternative feedback is possible; tactile, audio and visual feedback. Tactile feedback are often made by vibrating the whole device when a target is selected, even better would it be to give a direct ”snap” on the finger that taps the screen but this require more advanced hardware. Audio feedback can be a good solution in some cases but are not suitable for noisy environments which mobile devices often is used in, e.g., public places. Visual feedback is very important to always use. The lack of physical feedback must be replaced by visual feedback so that the user instantly see that something happens when tapping a target. It is very important that all kinds of feedback are immediate; otherwise it might confuse the user or causing them to tap repeatedly feeling nothing happens or that their tap failed [58].

6.7

Touch screen Design Guidelines

This section lists guidelines that are supporting pitfalls when developing user interfaces for touch screens. The guidelines are a mix of conclusions from the theory above and guidelines directly provided by different sources. The software should support one-handed interaction. Many daily tasks require one hand to interact with the environment, making the user only having one hand available to interact with the phone. The win in usability is great when the user can operate a task with one hand, making the loss great when the user needs two hands for a task. Tasks requiring two hands frustrate the user by making him or her interrupt another task to make it possible [33]. Support localized interaction to minimize grip adjustment and offer a generalized interaction method. A grip adjustment increases the risk of dropping the device, an effect with high loss in usability. Touch screen phones have a bigger area for possible interaction than non-touch screen devices. Therefore a generalized interaction method should be offered supporting all parts in the application or across applications [33]. Design for both left and right-handed users or allow the user to configure which hand they use. The speed of diagonal movements depends on which hand the user uses. Movement in ”top-right bottom-left” direction is faster for right-handed because of the physical nature of the hand. Movement in ”top-left bottom-right” direction is slower for the right-handed. The facts are opposite for left-handed. One good way is to avoid diagonal movements and use horizontal and vertical movements instead. These movements are independent of the left or right hand [33, 58, 47]. Design for both left and right-handed users by placing interaction targets to the vertical and horizontal center of the device. Mind that the guideline say

44


in the middle of the device, not display. When designing for multiple devices it is good to consider where the center really is. Users can also be allowed to, e.g., scroll or drag (use gesture commands on) items in a list to move them to a suitable place on the screen where they are easy to interact with. Generally use the middle of the device to support both left and right-hand users [33]. Favor your design for the smaller devices, making it easier to support as many devices as possible. The size of the screen where the user interacts with it by touching it should not be bigger than that the user can interact with it using only one hand. Furthermore it is easier to scale up a small screen design on a bigger screen than the opposite [33]. Make targets that the user can interact with 1cm2 . This size support fast, accurate one-handed interaction and allows the user to use the thumb (usually the thickest finger) as well. This recommendation is made for resistive touch screens. Resistive touch screens can report only the average pixel of the finger contact area while capacitive can report the whole contact area. This enables capacitive screens to have more accurate finger selection and might give new target size recommendations in the future [33]. Also remember to give enough space between targets to avoid pushing on the wrong one. Finally take into consideration that the angle of the finger change the contact area and can cause errors [20]. This is especially important in specific interaction situations where the device is held in different way, e.g., a camera application were a photo is taken with arms stretched upward to reach higher. Offer indirect gestures to complement, not to replace direct interaction. Gestures are not as visible for the user as direct interaction objects. However, gestures can improve the users overall performance and satisfaction by offering faster interaction. Gestures are therefore a good alternative for more advanced users [33]. Be intuitive and consistent. Use a consistent interface and action strategy and try to be intuitive. Consistency for what happens when, e.g., a button is touched is important to avoid confusing the user [58]. An intuitive interface is when the user feels it clear and easy to use. To get there a good mental model is needed. The appropriate mental model is found when the designer understands the user mental model of the system [26]. Gestures can be very intuitive but is harder to discover, direct touch is the most visible and intuitive action. Use fixed areas for different interface components. Try to put input, buttons, data and status display components on the same area of the display during the whole application. Navigation buttons must be placed on a constant place. Also use Gestalt laws when arranging components [58]. Limit the number of choices. Choices shall be limited to the most necessary amount. An overflow of choices will confuse the user [58]. Always allow the user to backtrack and proceed in a clear manner. Make it clear how the user can backtrack to make changes and proceed to another part [58]. Use three icons for three states when a button is pushed. Have one icon showing when the button is visible on screen. Use another icon while the finger pushes the button to indicate that it is pushed. Use a third icon when the finger is released to indicate that the desired operation will be performed. Make the three distinctions clear to disassociate and highlight the whole icon, not just small part of it [58]. Rather use simple single-click interfaces than dragging, scrolling and double-clicking interfaces. Keep simple things simple. A single-click interface is the most easy to use. More advanced interaction can although be used for more advanced actions but should be avoided if possible [58, 6].

6.8. Discussion

45

Minimize text entry. Touch screens do not provide as fast and accurate text input as keyboards. Mobile devices have overall slower text entry possibilities. This directs to recommend minimizing text entry and try alternate solutions. Always give clear and immediate feedback. A touch screen lacks the natural tactile feedback as physical buttons and has therefore to be complemented with other feedback. Visual, tactile or auditory feedbacks are all possibilities. Important is that the feedback is immediate to avoid user confusion and frustration. Visual feedback needs to be clear. Take into account that the user’s finger covers most of the button [33]. Make navigating, e.g., scrolling, panning and zooming behave in a realistic manner. If an objects is manipulated by a gesture or touch it has to behave realistic to make sure the user feel that they are in control. For example when scrolling a list the speed of the gesture has to correspond to the impact on the list, also avoid delays [33]. Minimize the amount of user interaction required to operate the application. If the required interaction is minimized, the task flow and user enjoyment increase, and mental demand and user frustration decrease. One way is to minimize the steps needed to perform a specific task. Another way, which is especially good when using online content, is to fetch content that are of interest for the user, sparing them waiting for it [33]. Consider using alternative gesture based interaction techniques than traditional for navigating information space. Scrolling, panning and zooming through information with traditional techniques as scrollbars, tap-and-drag and +/- and up/down buttons can be changed or complemented with alternative gesture based techniques that touch screens enable. Examples of new techniques are Radial scroll, Touch-n-go and SDAZ. Avoid putting interaction targets on hard to reach areas of the screen. The opposite bottom and top corner and the nearest bottom corner are the least comfortable to reach. For example avoid placing targets in the left top and bottom and right bottom corner when using the right hand only [33].

6.8

Discussion

When designing for touch screens and finger interaction the above techniques, theories and guidelines should give a good knowledge in general problems and possible solutions. The possibilities are depending of whether one has to re-design a user interface or if one has the freedom to do everything from scratch. The touch screens are becoming consumer products and the hardware techniques described above will all develop and get better. In the current situation there is no winner and different techniques have different pros and cons. New techniques will probably show up and compete in price and functionality. Generally will the screens and touch techniques evolve in precision, which might make the recommended targets size smaller. Another area where the hardware can evolve a lot is in ”tactile feedback”, direct physical feedback on the finger would more or less erase the difference between a physical button and a touch screen. Different techniques, e.g. for navigating, panning and zooming, solve different problems with touch and small screens. Many of these are ”hidden”, the user can not see how to use them directly, and when designing one have to consider the context of use and the difficulty of the tasks. More difficult tasks can be more effective using smart gestures, but simple tasks, that are not used repetitively or often, fits better for simple direct manipulation. When looking into techniques and design solving problems considering small touch screens many of them are solutions to earlier ”poor” designs.

46


Take a look into Windows Mobile (5 or 6) for example, and it is easy to see that it is designed for stylus use and not for fingers. Generally do users not like to be forced to solve common tasks with the stylus and different hardware vendors try to solve this by putting ”skins” for common functionality in Windows Mobile. For example search the web for HTC Touch Flow 3D and Sony Ericsson Xperia Panels. A good way to think is to use alternative techniques when the standard ones do not solve the tasks effectively enough. As consumer products, the touch screen devices are pretty new and gestures like ”flick” are unknown to many users. But as the market grows and more users get used these ways of interaction they will get different expectations and the knowledge level of the target group for design will be important to consider when creating designs. Some touch designs and gestures will probably become ”standards” in a natural way because they are the best solutions. As a comparison for all designs today are Apples touch interface used in iPhone and iPod Touch, a very celebrated and successful design. The guidelines above are a good support when designing for small touch screens where the user shall interact with the finger. Some of them will be valid for a long time and some might have to be rewritten when the hardware and user expectations change.

6.9

Conclusions

As touch screen devices are becoming consumer products, more and more users will get experience of them. This experience will create new expectations and touch screen design standards will be shaped. Different touch screen hardware has various pros and cons, the techniques will probably gain success in different solution areas. Tactile feedback and precision are two areas where the screens clearly will get better; these two areas directly affect the design possibilities. Techniques that solve problems with touch screens today are often solutions to earlier poor designs but some of them might be used more often than others and some might become standards. It is hard to say today if one is better than all others, it is dependent on the complexity of tasks and context. The guidelines are a good support to avoid pitfalls, but to create successful design it is still important to test it on the actual end-users and take their knowledge and expectations into account.

Chapter 7

Design The Design chapter starts with presenting the selected target group of the thesis. The personas, functionality and scenarios are presented as well as summaries from the meetings with the focus group. Furthermore, some screen from the design phase are presented and it is discussed how they influenced the final design. The requirements made for the prototype and how they should be fulfilled are presented.

7.1

Target group

Designing an application for every kind of user is a hard task. This section introduces the reader to the selected target groups of this thesis. For the selected target groups two personas have been made. In the end of this section three scenarios are presented which were used when designing the prototype.

7.1.1

Market segmentation

The ultimate design would fit all consumers on the market. That design is impossible to create since it would need a specific design for almost every consumer. To make design pleasurable for the consumers, it needs to be divided in to segments where groups of similar users are generally described. Through this can the design reach its goals in desired target group. The segmentation can be made in many ways, as age, sex, nationality, occupation, income, interests, computer usage. The goal is to find the attributes that separate unwanted consumers from the one the design is aimed for. Good segmentation models can be used over a long time-span. This enables identification of trends when people’s behavior can be compared between years. Ericsson has constructed a user segmentation model based on over 30,000 telecom consumer interviews made over 6 years. The model is based on six identified driving forces for telecom consumers; connectivity, innovation, social awareness, stimulation, social status and tradition. Connectivity means the need to stay in touch, provided by the basic functions in a mobile phone. Innovation is the technological innovation in a product. Social awareness is the ability to be more concerned with social issues than individual needs, e.g., globalization is important for some social area people. Stimulation as a driving force is for self-oriented people looking for instant satisfaction, these people are heavy everyday technology users. Social status is the force of being socially seen and financially successful. Finally, tradition is 47

48

Chapter 7. Design

the motivation for people with the attitude that technology causes more problems than it solves [1]. These driving forces give five basic consumer segments: – Pioneers: Strongest driving force is innovation and stimulation. First adopters, likes anything new, experiment with technology and give their judgment to others. – Materialists: Strongest driving force is stimulation and social status. Early adopters to early majority adopters, self-oriented, like to have fun. – Sociables: Strongest driving force is innovation and social awareness. Early followers, positive towards new technology, especially technology giving lasting benefits. – Achievers: Strongest driving force is social status. Early to late majority followers. Self-oriented but more traditional than materialists. Likes traditional status symbols, e.g., cars and clothes. Have the latest phone, but just too impressive, don not use all features. – Traditionalist: Strongest driving force is tradition. Last to adopt a new product, called laggards in this case. Only use mobile phone when it is absolutely necessary. These segments can be further sub-divided with more analysis. The segments chosen as target groups for this thesis are subgroups of Materialists and Achievers. Materialists can be sub-divided in Young and Adult Materialists. They are materialists in different ages, where younger are exploratory and more driven towards instant gratification. These groups are pretty early adopters, and adopt new services after the first group, pioneers. The adoption is stronger if the pioneers approve the service. That is the first target group for this thesis. The second group is a combination of adult materialists, and achievers. This group is more driven by social status and a bit less driven by stimulation than the other target group [1]. This group can be called Mainstream materialists.

7.1.2

Personas

During the thesis, two personas have been made. One from each of the target groups selected for the thesis’ ODP design. They are called ”Glenn” and ”Alice” and their key attributes are shown in figure 7.1 and 7.2. Table 7.1 describes key functionality in an ODP according to each of the personas, the data were collected and discussed with the focus group.

7.1. Target group

49

Glenn a Mainstream materialist

Figure 7.1: Persona named Glenn

50

Chapter 7. Design

Alice a Young materialist

Figure 7.2: Persona named Alice

7.1. Target group

51

Key functionality

Glenn Apps, Weather widget, Local news feeds

Triggers Keepers

Cool apps to show off with Acquiring new cool apps

Alice Feeds, personal e.g. Facebook and non-personal e.g. fashion news. Social applications, e.g. messenger apps Staying updated Staying updated and possible to share content

Table 7.1: Persona key functionality

7.1.3

Persona based scenarios

The following scenarios are written to give a focus for common user tasks. The scenarios are written with the personas as main actors. Case 1: Find (store front), add (store front) and organize/move (app launcher) app Glenn is having a busy day at work, customers the whole morning and no time to relax. The forenoon break is needed and Glenn is heading for the staff room. He gets a coffee from the coffee machine and sits down in the soft couch. Glenn takes a deep breath and a sip of his coffee. He feels his new mobile phone in his pocket and a thought crosses his mind, the ODP. The portal the salesman was talking about in the store. Glenn picks up his mobile phone from his pocket and starts the ODP. The start-screen is showing the weather and a news ticker is showing the latest headlines. Glenn sees the Store front button and presses it. The store opens up; Glenn is smiling and having another sip of his coffee. Glenn presses the Top-list button. The content is presented and the first application Glenn sees is a tennis game. Glenn who is a fan of tennis presses the icon and new screen appears. He looks at the pictures of the game and would really like to try it. He sees a Buy icon and presses it. The application is being installed and Glenn is directed to the application launcher. Glenn sees the icon in the bottom line of his application grid and starts the game. After 5 minutes of playing Glenn quits the game and return to the application launcher. Glenn thought this game was fun and wants to move the game higher up in the grid. He is not sure how to do this but his intentions makes him just drag and drop it. That works out fine and the icon is now in the top corner. One of Glenn’s colleagues comes in to the staff room. Glenn wants to show his new game and starts the game and let his colleague play. The colleague likes the game and Glenn feels good from the appreciation. After that Glenn finishes his coffee and goes back to work. Case 2: Find, add and read feed Alice is on her way home from school. She has a 20 minute bus trip on the way home to her parent’s house where she lives. Sitting on the bus, Alice has some time to kill and usually does it by talking to her friend Lisa, but Lisa is ill and not in school today. Alice has a key interest in fashion, she loves to follow trends and applies them early. To keep herself updated she spends a lot of time in stores downtown and read fashion news on the web. She has a pretty new good looking mobile touch-phone with an ODP integrated by her operator. She knows that she can check out the latest news through the Media Portal with this application. She is thinking that it would be nice to check the latest fashion news with the mobile phone. She starts the ODP, getting to the start page where she directly touches the Media Portal icon. Entering the media portal she sees some news feeds added when she first configured the

52

Chapter 7. Design

ODP, the first time she opened it. She like the fact that it added some nice life-style magazine and local news feeds, but she wants a more specific fashion feed. She touches the ”search feed” -button and enters the text ”fashion”. The search is fast and quickly lists fashion feeds. In the list she finds Vogue, Elle, Zoozoom and her very favorite ”I am Fashion”-blog. She excitingly touch the add button for ”I am Fashion” and sees that it is added among her other feeds. She touch the icon and it starts up, viewing the latest headlines of the posts from the blog and giving the possibility for further reading by pressing the interesting ones. Alice almost forgets to get off the bus on her stop because the blog have so many new interesting posts today. Case 3: Customize start screen Alice is reading the ”I am Fashion” blog everyday by using the ODP and wants to easier see when it is new posts on it. She sees the news ticker on the start screens and thinks that she wants her latest favorite blog posts there. By entering the edit mode (e.g. by pressing and holding down her finger) on the start screen ticker she can choose the ”I am Fashion” as one of the feeds on the start screen ticker. She can now see the latest ”I am Fashion” post headlines directly on the start screen.

7.2

Design Meetings

During the design phase a focus group was created. This group had weekly meetings and discussed different subjects every week. The group consisted of people that could contribute to the thesis work. The people in the group had knowledge and experience from interaction design, ODPs, usability and user experience. This section presents summaries from these meetings.

7.2.1

Summary of Meeting 1 - The ODP Concept

During the first design meeting brainstorming was performed on Mental models, Metaphors and the general meaning of the ODP concept. First the Personas (see section 7.1.2) of the target users were introduced and later they were evaluated with the seven attendees. After this, a shorter brainstorming session was performed regarding the meaning and moods connected to the ODP. The result was collected and discussed. Finally another shorter brainstorming session was performed regarding mental models and metaphors for the target users with the personas as a support. This result was also collected and discussed. Material used where post-it notes and news papers where text and images were torn out. The main message from the ODP brainstorming session was that: An ODP is a portal to the world; updated, rich and dynamic content all easily accessible. The ODP shall replace the small screen’s limited (WAP) browser experience, and enable the web in an efficient and mobile phone adapted interface. The ODP shall deliver the feeling of bringing the world to your phone. The ODP should be good looking and seductive without exaggerating the look. The ODP should not present mine or the operator’s world; it should present the whole world. Since the user are not interested in the whole world at once, shall customization make it easier to access favorite content e.g., by shortcuts. The user shall not feel that it costs a lot of money to browse in the ODP, when something costs it should be clearly visualized. Updated and new content shall be easily separated from seen and old content, the feeling of looking for content is; ”right here - right now”. The ODP shall give fast access (not slow as WAP). The content shall be delivered in the same presentation model where the users feel comfortable and joyful.

7.2. Design Meetings

53

Avoid the feeling of a ”phone in the phone”; it should be something that makes the phone more useful. The best mental models and metaphors for the personas were the following: Glenn – Like my car (e.g., BMW), style it and drive where I want, fast and good looking – Wants guidance to hot content Alice – All fun in one place – Wants to be able to share and communicate

7.2.2

Summary of Meeting 2 - Competitor analysis

During the second meeting with the focus group, analysis of competitors was performed. Five systems/ODP’s namely iKivo, Vodafone Live, iPhone, Zumobi, and Yahoo Go were analyzed by all group members. In excess of the above systems, a couple of the members gave some feedback on the systems HTC Diamond, Nokia Widsets, and Ericsson ODP Client demo as well. The different systems were presented on devices and each member got 5-10 minutes with each system. Pros and cons with the systems were written down on post-it notes and in end all systems were discussed. After the meeting the pros and cons were grouped together and gone through again. Requirements were created based on those pros and cons which actually could be converted into requirements. These requirements and further requirements are presented in the section 7.4.

7.2.3

Summary of Meeting 3 - Content Sorting and Interaction Styles

The third meeting with the focus group was about content organization and interaction within content. 60 different words related to the ODP were delivered to the members of the group. The task was to think ”How would Glenn and Alice organize these words and with that build up a possible structure of the ODP?” The first session was about organizing the words. The second session was a presentation and discussion of the result. It was not necessary to use all words; just those the member thought would fit in. Post-it notes were provided if the members wanted to set a title or subtitle to a group. The interesting parts from the result were the similarities among the meeting attendees. After a comparison of the different ”systems” nine main similarities were found. This is shown below and the result is the words that were grouped together: – Account information, phone bill, and operator - there might be an interest for how much money the user has spent and other billing information. – Personal and non-personal - content could be divided into more personal content and more non-personal. – Quit and help - quit and help are easy to find in all ”systems” organized. – Friends, community, blog, chat, status, and messaging - these words were grouped together by all members. These may be a vital part of the ODP, especially for Alice.

54

Chapter 7. Design

– Store, top-list, new, and tips - top-list, new, and tips were often related to the word store. – WWW and browser - WWW or browser were easily found in all ”systems”. This may indicate that the Internet should not be far away. – Music, video, applications, games, ringtones, and wallpapers - these words were commonly related to the word store. May show that this is what people want or expects to buy. – Alice specific - Fashion and music - Fashion and music were often ”tagged” with a Alice note – Glenn specific - Sports, news, and weather - sport, news, and weather were often ”tagged” with a Glenn note. From the above results, the second session and further discussions in the focus group, the following conclusions can be made: – Glenn has a greater purchasing power. – Alice is more personal and social. She is more sensitive to cost and use more free content. – 3 of 4 made a distinction between beneficial and pleasurable services / applications. – A tutorial to configure the ODP (first time it is started) would be a good way to populate the ODP with content of interest. – The Facebook web page feed is a good inspiration when wanting to show updated / new content mixing content, e.g., images, comments, messages and requests. – Ring-tones, wallpapers and games are no longer the most central content in an ODP. – Personalization is an important aspect that can lift the concept even more and is a thing not possible in a wide sense in the iPhone. – Sharing is important, especially for Alice. What content shall be possible to share? What is sharing? Rating, commenting, reviewing, sending? – Feeds can be personal and non-personal. Personal feeds are, e.g., from communities where a membership is required. Non-personal feeds are, e.g., news, sports from public sources. – There is some general functionality that is grouped outside the content: search, help, quit.

7.2.4

Summary of Meeting 4 - GUI Screens Evaluation

Meeting four was a one hour session where GUI proposals were presented on papers and later evaluated. The GUI proposals consisted of a Home screen, a market (storefront), an application launcher and a media portal (feeds reader). The parts were presented and linked together in different ways in the proposals. All attendees evaluated all of the proposals and wrote down negative and positive feedback for each one of them. Screenshots of Home screen proposal can been seen in section 7.3. The most important feedback is generalized in the following list:

7.2. Design Meetings

55

– Keep it simple! The simplest suggestions were the most popular and gained most positive feedback. – Give the content / information as much space as possible. – Only show navigation necessary for the moment to save space for content in focus. – Do not show too much information on the homepage - avoid a cluttered views. – 4 icons in a row is good. – Provide a search function which gives all results in categories. – Use images to provide information when possible, e.g. rainy weather could be visualized by clouds and rain instead of text. – Icons and numbers are good to give notifications. – Good to show battery and network information. – A grid is simple and intuitive. – Avoid putting buttons to close. – Buy/Free is a good separation in the market. – Good with the home button easily accessible. – Good to always show menu but it might take unnecessary space. – A headline is enough for a news item for the user to choose whether to read it or not. – Use transitions to provide additional information, e.g., for wind, air pressure and forecast in weather widget. – Use a wizard the first time the ODP is started to let the user populate the ODP with some initial personal content. – Categories in market are good when exploring for fun, not searching for specific content. – Provide a visual hint when a flick is possible. – Do not provide personal information on the home screen, e.g., an e-mail with text. – Make it possible to customize the look and feel. This feedback was used in the continuous design process as new proposals were made.

56

Chapter 7. Design

Figure 7.3: Home screen 1

7.3

Screens

During the design phase of the thesis several sketches and screenshots have been made. In this section some of the different ”Home screens” made will be presented and described. The first five are proposals made in Adobe Illustrator and added to an image of a HTC Diamond mobile phone. The texts on the side of the figures are descriptions of functionality and design in the different proposals. These five were printed and paper and presented for the focus group. The design of the proposals did not have any requirement on richer graphical components, but rather showing functionality and interaction. The last one is a screenshot of the final design. The screenshot is taken from a SonyEricsson W950 emulator. Screenshots like the ones made of the ”Home screens” in Illustrator were also made for all other parts of the application, e.g., the ”Application launcher”, ”Media Portal” and ”Storefront”. All these were evaluated and discussed in Design Meeting 4. Figure 7.3 shows one of the first screens made during the design process. What is not described in the figure is that the shortcuts and menu button at the bottom of the screen as well as the shortcuts in the top should be accessible in the entire application. The feedback from the focus group was: – “Good with shortcuts”

7.3. Screens

57

Figure 7.4: Home screen 2 – “Good with a shortcut to the home screen always available” – “Can the background be filled with content?” – “Nice with a personal background” – “Is it possible to flick the widget?” The feedback resulted in further work on visualization of flicks and using the free space. The shortcuts in the top have been redesigned and kept in the final design. Figure 7.4 is also one of the earlier screens made. What is not described in the figure is that the shortcuts, menu button and the notification area should be accessible in the entire application. The feedback from the focus group was: – “Good” – “Different categories and detail level mixed?” – “Pretty simple home screen” – “Good with notifications” – “The menu is not obvious”

58

Chapter 7. Design

Figure 7.5: Home screen 3 This design is a little bit more detailed and the layout is more computer interface based. The notification area was well received. The only question was if it was necessary to always show it. One person thought it was too much information, and one person thought it was pretty simple. That resulted in a more customizable home screen where the user could choose how much information he or she wants. Figure 7.5 shows one of the later designed screens. This screen was developed during a sub-phase where only home screens were made. What is new with this design is the clearly marked field for searching, and all the shortcuts to applications and news feeds. The feedback from the focus group was: – “Need possibility to be able to easily add bookmarks to here from browser” – “Good and simple” – “Clean approach” – “Google search bar is a good entry to the web” – “Add an icon for ”other bookmarks” – “Is the search function necessary on the first page?” – “Good clean way of highlighting notification”

7.3. Screens

59

Figure 7.6: Home screen 4 This design gave a lot of positive feedback. The only negative feedback was that it did not look like a natural home page. The search bar has been used in the final design, but not on the home screen. The shortcuts have also been used, but the mix is now applications, bookmarks and widgets. The news feeds has been moved to another part of the application. Figure 7.6 is a home screen with a simplicity influence. It is also designed with a computer based interface influence. The shortcuts in the top are more like desktop shortcuts and the menu in the bottom has a more simple design. The feedback from the focus group was: – “Good! Clean!” – “Simple with four favorites” – “Make the background an active widget” – “Too much information in notification” – “Remove the clock and add Google and something more” The four favorite icons have been kept in the final design. A transparent background has been put behind them to make the stronger when lighter backgrounds are used. The menu button and home button in the bottom have been kept and redesigned.

60

Chapter 7. Design

Figure 7.7: Home screen 5

7.3. Screens

61

Figure 7.8: Final Home screen Figure 7.7 shows a screen with a desktop/sidebar influence. The design is very customizable and the user can put the content where and how they want it. The feedback from the focus group was: – “Too much on screen” – “Too hard to customize” – “Gives the user freedom to organize content how they want” – “Hard to implement in a good way” – “Put the icons together” None of the design elements have been kept in the way it is presented above. However, the design gave new inspiration to further design. Figure 7.8 shows the final home screen in an emulator. The four favorite icons have been kept in the top and the menu in the bottom is now having the buttons Options, Home, Stuff and Search. There are two ”widget rows”, where one is presented with a weather widget and the other one is just showing a handle. The handle symbolize that a flick is possible. The menu is available on the home screen and stuff screen. This design are evaluated by users later in this thesis.

62

Chapter 7. Design

7.4

Requirements

After meeting 2 with the focus group some requirements for the ODP were constructed. They have been divided into functional and non-functional requirement. The ones that are possible to evaluate with users during the thesis work will be evaluated. N = Non-functional requirements F = Functional requirements

7.4.1

Usability goals

Understandability

# 1

N/F N

Requirement GUI elements should be easy to understand

2

N

Texts and language should be clearly understandable for the target users

Measure 80% of the users shall without problem be able to navigate in the application Button labels and help function shall use natural language

Learnability

# 3

N/F N

4

N

Requirement The help should be context sensitive and explain how to achieve common tasks The system should be easy to learn

Measure The help function shall show relevant information and be instructive After 30 minutes of use the user shall be able to complete common tasks and navigation

7.4. Requirements

63

Operability

# 5

N/F N

Requirement The GUI actions and elements should be consistent in main and sub menus Error messages should explain how to recover from the error Undo functionality should be available for most actions Actions which cannot be undone should ask for confirmation

6

N

7

N

8

N

9

N

The system shall give consistent and direct feedback

10

N

11

N

12

N

13

N

The response on interaction shall be direct Interaction shall be possible with one finger at all time Feedback for what is happening during loading shall always be given Information about location in space shall always be given

Measure The same GUI elements shall be used in the entire application Messages shall use natural language and be instructive A clearly marked undo functionality shall be available Confirmation shall use natural language and the user shall be able the cancel the confirmation Feedback shall be clearly visible and if the feedback consists of text; natural language shall be used Response time shall not be more than 21 second No multi-touch functionality shall be used Loading screen shall clearly describe what is going on Scrollbars or other similar marking shall be available

Attractiveness

# 14

N/F N

15

N

Requirement The screen layout and color should be attracting for the target group The flow in animations/transitions and change of views shall be smooth and not lag

Measure 80% of the target group shall find the layout and colors attracting The flow shall be perceived as smooth by the users

64

Chapter 7. Design

7.4.2

General requirements

# 16

N/F F

17

N

18

F

19

F

Requirement When possible should a search feature be accessible by one click New and updated content shall be visually separated from old content The ODP shall be configured the first time for the user to map interest with content Make home/start always accessible

Measure Search functionality shall be available and easy to access The user shall be able to see what is new and what is old A tutorial with choices for personal interests shall be available Home/start shall be maximum one step away

ODP moods and meaning

# 20

N/F F

21

N

22

F

23

F

Requirement Easy access to desired content; It should be easy to find and zoom in on information Good looking: It should be seductive but not to much Cost: Show the user what the price is, or if it is free Good overview: what is hot right now?

Measure Provide shortcuts to favorite content 80% of the user shall find the application good looking Information about cost shall use a natural language and shall be easy to understand The application shall provide a good overview of the content

7.4. Requirements

7.4.3

65

Persona specific requirements

Glenn

# 24

N/F N

25

F

26 27

F F

28

F

29

F

Requirement “I want it to be like buying and own my nice car, style/specify it and then drive where I want, fast and good looking” The best selection of content- Tell me what is hot “I want to read local news” “I want to check local weather for the barbeque tonight” “I want applications that are fun to share with others”, e.g., the iPhone Beer app “I do not know it, but a mail notification in the ODP could release me from having to start my computer every once in a while just to check my mail.”

Measure Give the user a feeling that the application belongs to oneself

Requirement “I want it to be all fun in one place, so I can stay updated, fulfill my big social needs, all in my phone.” “I want to be able to share content” “I want the latest fashion news” “I want to check local traffic timetables” “I want to check my mail” “I want to use instant messaging and have a status” “I want to keep track of my communities”, e.g., Facebook “I want to check local news”

Measure The application shall be fun to use

Show the user what is popular and what is the latest content Give the user access to news Give the user access to weather data Update the application with new content Give the user access to e-mail

Alice

# 30

N/F N

31

F

32 33

F F

34 35

F F

36

F

37

F

Give the user ability to share content Give the user access to news Give the user access to timetables Give the user access to e-mail Give the user access to instant messaging clients Give the user access to web communities Give the user access to news

66

Chapter 7. Design

7.4.4

Other requirements on the ODP (from Meeting 3)

# 38

N/F N

39

F

40

F

41

F

42

F

Requirement Shall be fun to use Phone bill etc. shall be an application Help should be found on the same place in the entire ODP Feeds are one-way communication Multimedia (music, wallpapers, ring tones etc.) are reachable only through a file browser and not through the ODP itself

Measure 80% of the user shall find the application fun to use Give the user access to operator based information The application shall have a help function available, and it shall be easy to access Feeds shall only be readable, can include web links though Downloaded content will be saved on the phone, not in the ODP

Chapter 8

Accomplishment This chapter summarizes the accomplishments from the different phases in the thesis. This spans from day one to the evaluation of the prototype. More detailed explanations of the phases can be found in previous chapters.

8.1

Identifying the user and the needs

The first thing done when starting this thesis was to understand what an ODP is. Information on the web as well as internal documents were read and a better understanding of how the concept was built. A good introduction in the beginning was a Ericsson usability evaluation presentation that we could attend. This gave even more information about the ODP concept, and an early glimpse of some competitors. To understand who the user of the ODP is, a lot of information from the internal Ericsson Consumer Lab were processed. This gave information about location, type, age etc. of the user that use the ODP. During this work the target group of our prototype was discussed with people from the Consumer Lab. This resulted in two target groups which have many things in common. This choice was based on how these groups of users are affected by new technology. The concept of an ODP became clearer and the next step was to investigate how competitors built their ODPs. A competitor analysis was made and a few companies and their ODPs were analyzed. A customer branded ODP (delivered to a customer of Ericsson) was installed on a device and analyzed from a functional perspective. One of the last stages in this phase was to find out what kind of content the target group was interested in. Some content were chosen from Consumer Lab data for the chosen target group, and some content from competitors.

8.2

Developing the design

When the ”Design phase” started a focus group was set up. The people chosen for this group were people that we and our internal supervisor thought could make a contribution to the design. They were invited to weekly meetings were the week’s work was discussed and evaluated. This gave us invaluable feedback which has been taken good care of. The design itself started with a brainstorming where sketches were made. Empty screens were printed out and filled with ideas and information. After a while they were 67

68

Chapter 8. Accomplishment

discussed and filtered. An iterative process was performed and in the end a couple of sketches were chosen for the next step in the phase. The sketches were evaluated with the focus group and new ideas were born. The new ideas were now illustrated using Adobe Illustrator, this gave the design a more realistic look. In the last meeting with the focus group the illustrated screen was presented and evaluated. The focus group gave positive and negative feedback to the different proposals and the final design were started to take form. When the final design had been chosen all screen that was supposed to be implemented in the prototype were illustrated in Adobe Illustrator. The graphics were made and saved for the coming implementation phase.

8.3

Implementing the prototype

When the thesis work started the implementation for the prototype was thought to be in Adobe Flash Lite. After some time this was changed to an XML based framework named ECAF. This was because Ericsson uses this framework when developing mobile application, plus that the touch functionality support in the framework was under development. This gave the thesis a unique opportunity to test the new functionality in the framework. ECAF (Ericsson Client Application Framework) is a framework where all graphical components and user interaction are defined in XML-pages. These XML-pages are written and structured in accordance to how the ECAF interprets the XML-logic. ECAF could be thought of as an Internet browser. One major difference is that while your general browser parses HTML-pages, ECAF parses XML-pages. While HTML does not really allow for any sophisticated user interaction, XML does. The XML-pages that defines the applications look-n-feel, the user interaction and all the other application content, may reside on a server. ECAF can not parse just any XML-page. The XMLpage has to be encoded especially for ECAF. Thus the creator has to know what kind of design structure to follow and what kind of tags to use. When working with ECAF the software platform Eclipse has been used. All XML has been coded in Eclipse as well as some Java. When testing the application an emulator from SonyEricsson was used and in reality a touch screen mobile phone from Samsung named F480 acted as a test device.

8.4

Evaluating the result

The evaluation phase started with setting the tasks and questions together. The requirements from previous chapter were the source when constructing the evaluation. After the evaluation was constructed users, who fitted in the target groups, were contacted and asked if they wanted to participate in the evaluation. The evaluation was tested on a pilot user and four regular users. Furthermore, three usability experts did a design walkthrough with a following discussion. When testing the regular users a software named Usability Datalogger was used for documentation and analyzing the result from the evaluation.

Chapter 9

Results The Results chapter summarizes the major results of the thesis. First the most important screens in the prototype are shown and described. This part shows the resulting touch screen ODP design proposal as a general result of the whole thesis. Further on one can read the result of the usability evaluation of the prototype. After that the result is validated towards the requirements and in the end is future design proposals made that might solve the problems the appeared in the evaluation.

9.1

Prototype

This section shows the most important screens in the design and complement them with a hierachial diagram showing how they are connected. Information about the most important propositions in the thesis design proposal are also given. Figure 9.1 shows a diagram of the prototype. It is built up from the Home screen, which is the start screen in the prototype. The different screens and functions that are shown in the diagram is what have been implemented in the prototype. What is not shown are parts like gestures, back buttons, widgets, application start screens, and other smaller things. The number of clicks from the Home screen is also shown, which shows how deep the prototype is. Figure 9.2 shows the Home screen. The icons at the top of the screen are favorite shortcuts that the user has chosen. This could be anything that the user wants to have easy access to and the users can make a shortcut to everything that is available in Stuff. The background is changeable and the user can personalize the look and feel of the prototype with different skins (not implemented). There are two rows where the user can add widgets like weather, stocks, RSS-feeds etc. To view another widget, the user can just make a horizontal flick on the screen and other widgets are shown. If the user wants a clean background the widgets can be hidden, like the one in the upper row. A small handle is visible to show that there are widgets available. The menu bar at the bottom has Options where the user can move and remove shortcuts and widgets. It is also possible to quit the application from the Options menu. The white square shows that the user is at the Home screen right now. Pressing Stuff will take the user to the Stuff screen. Search will take the user to the search function where the user can search the Internet as well as the market and newsreader. Figure 9.3 shows the Stuff screen. Stuff is like a file manager where the user has all the downloaded content as well as the preinstalled applications. The content can be 69

70

Chapter 9. Results

Figure 9.1: Hierachial view of the ODP prototype

9.1. Prototype

71

Figure 9.2: The Home screen in prototype

72

Chapter 9. Results

Figure 9.3: Stuff screen in prototype

9.1. Prototype

73

applications, games, widgets, and web bookmarks, all content is presented on the same level. The small rectangles at the top of the screen are page indicators showing how many pages of content that is available. The content is presented in three rows and four columns. To change the page the user can just flick the screen and a new page will be shown. The menu bar at the bottom is the same as in the Home screen, this makes the prototype more consistent. Figure 9.4 shows the Market where the user can buy and download content to the ODP. The Market is designed as a list which the user can scroll by dragging on the screen. The list elements show an icon, the title, type of content and the price or if the content is free. The menu bar at the bottom is almost the same menu as in Home and Stuff except for the two middle buttons. In market the user can choose to show the latest content or the top content. In the Options menu in Market the user can filter the content (not implemented) and download updates to previously downloaded content (not implemented). It is also possible to exit the Market application from the Options menu. The Search button will take the user to the general search function, but will only show hits in Market. The lower screen shows information about a Tennis game. The user can buy the game by pressing the Buy button. The button will change to a confirmation button, and the user has to press it again to confirm the buy. The screen also shows more information about the game and the user can rate and read reviews about the game (not implemented). Figure 9.5 shows the News application where the user can read different RSS-feeds. News is designed, just like Market, as a list which the user can scroll by dragging on the screen. The upper screen shows the start screen in News. The list elements are different sources and show an icon, the latest headline, date and time, and an icon showing if the source has been updated since the last visit. The menu bar at the bottom is almost the same menu as in Home and Stuff except for the two middle buttons. In News the user can choose to show his or her favorite feeds or the most read feeds. In Options the user can move and remove feeds in Favorites and exit the News application. The screen to the left shows the CNN source. It is possible to add the source to Favorites and read the different articles. The right screen shows an article from CNN. It is possible to share the article with others as well as reading more on the web (not implemented). Figure 9.6 shows the Search screen and search results. The user has in this screen searched for ”CNN” and the tab ”All” is selected. ”All” shows hits from the web, News and Market. If the user just wants to see hits from the Market only, the user can just press the tab. The result list is the same as in Market and News and is scrollable. The list element shows an icon from the source, title and information and an icon showing where the result belong to (Web, News or Market). If the user wants to make a new search, her or she can just tap the search field at the top and a software keyboard will appear. Figure 9.7 shows the Help screen. Help is available in Stuff and has four tabs for the different main screens and applications. The user can also start the wizard, which is thought to start the first time the application is started. In the wizard the user can choose his or her interests and by that fill the ODP with content based on the interest. It is also possible to search in Help (not implemented). Finally, without showing a screenshot, an important part of the ODP design is the Personalize application which can be seen in the grid in Stuff (figure 9.3). The proposal is that this application should provide the functionality to customize the look and feel of the ODP. For example different skins/themes can be pre-installed or to buy/download. This feature can be event based, e.g., when a popular artist is on tour the operator can

74

Chapter 9. Results

Figure 9.4: Market in prototype

9.1. Prototype

75

Figure 9.5: News in prototype

76

Chapter 9. Results

Figure 9.6: Search in prototype

Figure 9.7: Help in prototype

9.2. Evaluation

77

provide an artist skin giving a background, ringtone, ODP colors and icons etc.

9.2

Evaluation

This section begins with a description of an expert evaluation of the prototype and then present the result of a usability test of the prototype. These results are in the end validated towards the requirements in the last part.

9.2.1

Expert evaluations

Before the usability test the prototype were evaluated with three different usability experts. This was made through a design walkthrough for about and hour with each expert. Issues that came up was replaced with new design solutions before the usability test. The issues are therefore not presented in the report but their proposed solutions can be seen in the prototype.

9.2.2

Usability test

To validate the design of the prototype a usability test was conducted. Four test persons, where two where supposed the persona Alice, and two Glenn, performed 15 tasks. The chosen test attendees where asked to think aloud when performing the tasks and observations where printed on a paper. The time for each task was measured. After finishing the tasks the test attendees where asked questions to validate requirements and to measure Usefulness and Ease of Use. The number of test persons is not statistically secure but gives a clear indication of most important design errors. The numbers below represent the tasks performed by the test attendees. The performance rates as well as the task completion time will be discussed and compared. The result is visualized in figure 9.8 and 9.9. 1. The performance rate is a little bit ambiguous. 50 percent of the users succeeded in their first try and 50 percent needed assistant. This can be based on how they explored the prototype in their ”free time” before starting the tasks. However, as 50 percent needed assistant, maybe it should be clearer how to flick the widgets on the home screen. The completion time is one of the lowest for the tasks, this can depend on that the users started on the home screen. 2. 75 percent of the users completed this task relatively easily. The user, 25 percent, who needed assistance, did not notice that the application already was in Favorites when adding it to Favorites. The reason why this was possible was a bug in the application and has now been fixed. So, if not looking at the result of the bug, 100 percent of the users completed the task with no or just a few problems. The time is justifiable because the user needs to go 5 steps from the home screen. The spread of times are not that big. 3. 75 percent of the users completed this task relatively easily. The user who needed assistance, did get confused in the Options menu in News when exiting News from the previous task. This resulted in the user quiting the whole application. After some searching the user needed help to accomplish the task. The time is almost the same as the previous task, which is understandable because it is the same

78

Chapter 9. Results

”distance to go”. The spread is larger because the restart of the application took some time. 4. This task had the highest time and the largest spread. The task is based on Options navigation, which showed to be a big problem for all test users. The result is mixed, but shows that this must be improved. Design proposals of Options aimed to solve the usability issues is presented in section 9.3. 5. Reading the CNN news was an easy task for all the users. 50 percent completed the task in the first try and 50 percent had small problems to succeed. The problem was that they thought they had a news widget on the home screen, and tried to reach the news from there. The time is however pretty low so even with small problem the task was completed well. 6. The move widget task was a more difficult task for the users. This was because they did not have much or no experience from touch screen devices and this task included to drag and drop to a hidden area. This is shown in the result which is mixed from easy to hard. The times are also mixed. The task and how/where to perform flicks are something the user will learn when using the application. 7. Buy a game was one of the easiest and fastest tasks. None of the users had problems and this may show on that the buy flow is well designed with no room for mistakes. The time is low and the spread is almost none. 8. 75 percent of the user completed this task with a ”medium” result and 25 percent needed assistance. The problem with this task was that users were looking for some kind of personalization on the home screen. This made them click on Options and lose time. It also took them some time to find the personalize icon in Stuff. This may indicate that the personalization needs to be clearer marked or moved to another screen. The time, as said, was high and the spread depends on how fast they found it in Stuff. 9. The start game task was easy except for one person, 25 percent. The test user had forgotten about the second page in Stuff and was looking in another screen for the game. The times are low with a max time for the ”hard” user. Maybe a clearer page indicator could help the user to remember the second page in Stuff. 10. The task had a relative good result. 25 percent completed the task with no problem and 75 percent with just some small problems. The time is average and some of the users clicked the source first, and the found out that they should click the options icon. This task can be even easier with a new design of options. 11. The move application task has some mixed results. 50 percent completed the task with no problem and 50 percent had some problems. The times are not that high but have a relatively large spread. This task includes the options menu, which has caused problems before. A new design may make it easier for the users. 12. The updated news task was hard for the users. 25 percent, one user, completed the task with no problem, this because the user explored the markings during the ”free time”. All others users had problems and even needed assistance. The times are not that high but, the users had problems and the markings for updated news should be clearer.

9.2. Evaluation

79

Figure 9.8: The task performance rate. The scale shows how the four test persons performed in each task. The scale is Easy = 1st try - no problem, Medium = 2nd/3rd try - Observed difficulty, Hard = 3rd/4th try - expressed difficulty, Assist = succeeded with assistance, Fail = Failed or gave up. 13. The result from the remove application task is interesting. It is almost the same task as remove shortcut, #4, which had a high time. This task was easy for the user though. All users completed the task with no or small problems, and they did it quickly. Why this task went better may depend on that the users have used the options menu for a while and maybe learned how to operate it. However, the other tasks including the options menu have not gone perfect so the menu needs a redesign. 14. This task was easy for the users who remembered that they had seen the ”Add new widget” in the widget row. One user, 25 percent, was looking for it in other screen and therefore scored a higher time and more clicks. The design is something that the user will learn, but it should maybe be possible to add widgets from another place as well. 15. Exiting the ODP went well for all test users. One user, 25 percent, did go to the home screen from stuff and then Options and Quit. This is one unnecessary click and therefore the score was ”medium”. The new design of the options menu will make the ”Quit” icon more accessible. After the tasks and the following questions in the evaluation, the users graded statements related to the perceived usefulness and ease of use, see figures 9.10 and 9.11. If these two are separated the result shows a higher grade for the ease of use. The usefulness grade is lower and that may depend on that the target group named Glenn graded the usefulness questions lower than the target group Alice. Statement 3, 4, and 5 are the only ones who have a grade mean lower than 4, which is the mean of the scale. These statements are related to the usefulness, and this is the reason to the lower grade. Why usefulness gets a lower grade may depend on the concept of the ODP. The target users had not used ODPs before and just a description of the concept and an hour of use may not be enough for the users to understand the usefulness. If the users could use the ODP for a week or so, and then evaluate the usefulness the result may be different. Statement 11 and 12 scored the highest grade with 5.5 and 6.0. This is very positive because a lot of work has been done for a good usability. 9 out of 12 statements scored higher than

80

Chapter 9. Results

Figure 9.9: The task completion time for each of the usability test tasks. The diagram shows the medium, min and max times.

Figure 9.10: This figure shows the mean scores for the Usefulness and Ease of Use measured by the TAM scale.

9.2. Evaluation

81

Figure 9.11: This figure shows a Histogram of the answers on the TAM scale for Usefulness and Ease of Use. 4.0 which is a good result for the first evaluation of the prototype. Question 8 (see Appendix A.2) from the following questions was not related to a specific requirement. The result showed that the users found the content organized logical but needed small changes. The users thought, and if related to the task result, that the personalize functions should be moved to the home screen. The search function in unclear and should more visualize what is being searched. Both the favorite icons and the search function could be moved to a widget to save space and be hidden when not needed. Question 9 (see Appendix A.2) from the following question was thought to give a concluding answer from the users in the evaluation. The overall design impression was described with just positive words like: fun, rich of content, elegant, cool, simple, good looking, adaptable and good balance between function and design. This is of course very nice to hear because the user experience has been in focus during the whole thesis work.

82

9.2.3

Chapter 9. Results

Requirement validation

The following section describes the requirements that were not testable, failed in the prototype or vaguely fulfilled. All other requirements are fulfilled and validated in Appendix B. Vague requirements #1 GUI elements should be easy to understand - 80% of the users shall without problem be able to navigate in the application Cause: The usability test shows that the requirement seems to be fulfilled in all tasks except in the Options menu. Users have hard to understand the functionality in the Options menu. All test persons did press on the help texts in options instead of the icon buttons. They also had problems to understand the way of first pressing Move/Remove and then perform the actual editing. Solution: A proposed solution is presented in section 9.3, Future design proposals. #2 Texts and language should be clearly understandable for the target users - Button labels and help function shall use natural language Cause: The words Options and Stuff are not totally clear to all test persons. Quote: ”Options was unclear. Edit or Manage is a better word. Search is also hard to understand, search what?” Solution: No clear substitutions are given. Edit or Manage are alternatives for Options that need to be tested. #17 New and updated content shall be visually separated from old content Feedback shall be clearly visible and if the feedback consists of text; natural language shall be used Cause: The usability test, task #13, shows that this is not clear for the user in News. The requirement is not generally tested for other parts of the application. Solution: Make an overview of the design and look where new content can appear, then make a proposal how to indicate and test it on users. Failed requirements #12 Feedback for what is happening during loading shall always be given Loading screen shall clearly describe what is going on Cause: There is no ”loading screen” in the prototype providing this information. Solution: Add a ”loading screen” / ”progress bar” that gives the information when content is loaded/downloaded. #19 Make home/start always accessible - Home/start shall be maximum one step away Cause: There is two taps to Home/Stuff in Market/News. First Options then Exit, this caused a problem for the user in the usability test as well. Solution: See section 9.3, Future design proposals.

9.3. Future design proposals

83

Requirements not testable #3 The help should be context sensitive and explain how to achieve common tasks - The help function shall show relevant information and be instructive Cause: The help text is not implemented, just a example ”Lorem ipsum” text. Solution: Write help texts and then test them. #6 Error messages should explain how to recover from the error - Messages shall use natural language and be instructive Cause: No error messages are implemented in the prototype. Solution: Implement error messages and then test them. #22 Cost: Show the user what the price is, or if it is free - Information about cost shall use a natural language and shall be easy to understand Cause: This is not clearly implemented in the prototype, the only place where one can see a price is in the market. Generally do ODPs not charge extra for data traffic, it is up to the subscription and the operator to inform about this fee. Solution: Clearly implement when there is a cost for something. #28 I want applications that are fun to share with others, e.g., the iPhone Beer app - Update the application with new content Cause: The prototype is offline and not changing content over time. Solution: A real solution should provide this functionality. #42 Multimedia (music, wallpapers, ring tones etc.) are reachable only through a file browser and not through the ODP itself - Downloaded content will be saved on the phone, not in the ODP Cause: No multimedia is available in the prototype, but there is a link to an application called ”Files” in Stuff. Solution: A real solution should take this into account.

9.3

Future design proposals

This section describes proposed design that hopefully solve the problems that occured during the usability test. Figure 9.12 shows the following: – Since test attendees wished to hide the shortcuts, arrows are placed in the bottom corners of the shortcuts area. When the user presses an arrow, the shortcuts will slide up and hide. The arrows will then point down instead and be placed in the top of the screen. Pressing the arrows pointing down will show the shortcuts area again. – The ”search button” in the bottom right corner is replaced by ”Quit”. This will make Quit easier to find. The search functionality has been moved to a widget where the user directly can search on recent search phrase or press the input field to view a keyboard for input. The widget is shown above the weather widget.

84

Chapter 9. Results

– ”Options” is replaced by ”Edit”, hopefully a better label. The lower part of figure 9.12 shows the new ”edit mode”. Dragging items will move them, dragging them to the trash bin and release them there will remove them. If the user wants to abort changes he or she can press Cancel, otherwise Confirm. The edit menu will look and work the same way in Stuff and News. This will hopefully solve the problems that occured with ”Options” in the usability test. A new test is required to try it. Figure 9.13 shows a proposal to solve the problem test attendees had to find Exit in News and Market. The Exit button is moved from the Options menu to be located directly in the top right corner in the start views. The symbol to use for the Exit button is impossible to decide in a good way without testing it on users. Therefore some suggestions are presented in the figure.

9.3. Future design proposals

85

Figure 9.12: Proposed design aimed to solve problems on the Home screen and Stuff.

86

Chapter 9. Results

Figure 9.13: New location of Exit in News (the same location will be used in Market).

Chapter 10

Conclusions The conclusions chapter summarizes and draws conclusions from the work. The section also describes limitations of the work and how it can be continued in the future.

10.1

The Work and the Result

When this thesis started in June 2008, the main goal was to create an implemented prototype for a touch screen mobile phone, with a good user experience and usability. To reach this goal a pre-study, theoretical focus, a design phase and user experience evaluation has been performed. The work during the thesis has been performed without any larger problems thanks to high ambition and god planning. One of the first tasks performed when starting the thesis was to set up a time plan. This time plan has been followed as exactly as possible and the time dedicated to each phase has been enough. Doing this detailed time plan has been a great benefit because it has never been any problems to know what we should do every week. The time plan has also been very helpful to restrict the different parts of the thesis work from growing too much. The theoretical methods used in the thesis have been of great support when collecting data enabling to create and motivate a good design. The UCD ISO 13407 and Shaffer-Weinschenk methods have been used all the time to verify that all phases are needed and have also been of great use. The use of iterative design; proposals, evaluation, new proposals solving problems and so on, feels like a good way to create a good design and motivates design choices. The thesis began with a pre-study phase. This phase included ODP market analysis, competitor analysis, customer cases, content review and consumer analysis with help from Ericsson Consumer Lab. The phase required much reading and gave a good understanding of the parts of the ODP concept that are needed to create a good client design. The pre-study can be concluded in: – That the market is evolving and that ODPs available for customers today are packaged like “the operator’s content chosen for the customer”. The visual look of an ODP is also operator ”branded” and there is less opportunity for personalization. This will probably change to the opposite in the future. – The content possible for ODP’s are pretty much the whole web packaged for the mobile phone. Three main areas are identified; standalone applications, built in widgets and web sites. 87

88

Chapter 10. Conclusions

– Customers that are targeted for the ODP are many. The design shall be adapted for the operator’s target group. In case of this thesis, target group are chosen to be the one which we believe will and need the ease of use in the ODP to get extended functionality and web access in the phone. The target group was settled first in the design phase. These data gathering was then complemented with two theoretical focus areas regarding ”User experience testing” and ”Designing for touch screens” that generated useful guidelines as support when performing the design phase. The design guidelines has helped us avoiding pitfalls and been appreciated when shared to others. The design phase began with settling and creating personas for the target group. The personas, named Glenn and Alice, have been a great support to assure that we do not design for ourselves but focus the design best suited for the target group. The design work began in the conceptual phase of the ODP, what does it mean today and how will it evolve? What is an ODP for the target users? One sentence trying to summarize the result of the ODP concept design can be; ”an ODP is an online portal to the world, making the web, mobile applications and current online content easily accessible in a nice package that is both fun to use and possible to make personal”. After the discussion and elucidation of the concept, the design of competitors was analyzed to find good and bad examples of ODP design. This analyze was summarized in the requirements in order to validate that the thesis design would not do the same mistakes and reuse good solutions. The third part in the design phase was about how content should be organized and which interaction styles that should be used. Card sorting was used to see how people tend to organize different words that can appear in an ODP. Some conclusions could be made, mainly that the wide variety of content is best supported by a simple and flat design. This makes it easier to fit in new types of content and avoids the unability to fit in some types of content. The fourth phase in the design began with creating GUI screens (more than 100 views roughly calculated). These screens were then evaluated, re-made and finally evaluated by others. The best suggestions were re-made again until a strong design was found. The most important parts in the design are: – It is flat and simple to fit many types of content, to be easy to use, easy to adapt and make personal. – Use a wizard to help a new user populate the ODP with personal content. – Show only necessary navigation at each time to give the content more space. The design phase was all the time supported by 4 focus group meetings, one of the best contributions during the thesis work. The people involved in this group have been very helpful and skilled on different areas which has helped us much. After the design the implementation work began. Working with an XML-based client application framework (ECAF) has been useful and has its pros and cons. These are not further analyzed in this thesis but we believe that without the framework, having to program everything in Java-code, the prototype would not be as advanced as today. It has been great to contribute in the touch feature development of the framework. When finishing the implementation, the prototype was evaluated on potential users. The implementation and evaluation phase was hard to plan from the beginning. However, the weeks that were dedicated have been enough and all functionality that was planned has been implemented. The evaluation shows that test attendees think that

10.2. Limitations and Future work

89

the design is overall easy to understand and use. The major problems were the Options menu and how to find Quit/Exit in the different parts of the portal; proposals to solve these problems are presented in the last part of the thesis. The following questions insinuate that the design delivers the intended concept in a good way; the attendees answered positively to the design and spoke like they had understood the possibilities with an ODP in their phone. An evaluation performed earlier in the thesis could have given even more information about the user, but the time plan did not have time for that. Having people around you that have knowledge and want to share it has been good. Using these resources in the thesis has made everything better. The requirements and goals that were set up in the beginning and during the thesis work have been validated. 3 requirements are vaguely fulfilled, 2 failed and 5 are not testable in the current situation. In total there were 42 requirements, 35 currently fulfilled (including the vague). Looking deeper in the Problem Description, it says that it is important to consider alternative screen sizes and formats. This consideration is not followed up during the thesis. But the design is made for a small screen with the lowest available resolution on the market today. This implies, according to guidelines, that it should be easy to adapt for higher resolutions and bigger screens because it is much easier to go this way in contrast to the opposite. All other goals from the Problem Description are clearly fulfilled.

10.2

Limitations and Future work

The thesis consider many parts, each of them can be analyzed or studied further. The use of personas instead of real users during the design phase is not as accurate, but it is good when time is limited and really gives the benefit to avoid design only for oneself. The prototype have some limitations, it tends to stop working sometimes, visual bugs can occur and all functionality is not implemented. This is common errors for a prototype and should of course not be acceptable in a real product. The first thing to do for a future study would be to test the new design proposals on users and see if they solve the problems. Since the ODP is a wide concept consisting of many parts can each and every one of them be designed in detail and then evaluated. This thesis design proposal is considering how to present the concept and the main parts in it in a good and dynamic way.

10.3

Final words

Writing this thesis and working with the ODP has given us a lot of new experience and we have learned many new things. Working with a project and real company has been a good experience in the end of our education. The thesis has given us the possibility to use much of what we have learned during our five years at university, and we have seen that these years are well invested. Planning and setting everything up for the thesis has given us more knowledge in project planning and the methods used during the work. The prototype shows how an ODP can look like in a touch screen mobile phone. The functionality implemented works fine, even though some content and information are simulated. One of the goals was that the prototype should have a good usability and a high user experience. This main goal has been accomplished and is verified by the evaluation of the prototype.

90

Chapter 10. Conclusions

Summarizing this Master Thesis shows a successful project. We, Ericsson, and the users are satisfied with the result and hopefully we will in the future see the prototype being used as an example of a great touch screen ODP design.

Chapter 11

Acknowledgements We could not have performed this Master Thesis without the help from others. The first person we would like to thank is our supervisor at Ericsson Monika Hanson. You have helped us during this thesis and always been accessible. Another person who has contributed a lot is Markus Nyberg, all input and meetings have given us a lot of help. Thanks to David Furendel, Reza Assahreh, and Martin Kurtsson for good inspiration and many nice lunches. We would also like to say thank you to Markus Nilsson, Lars Lengberg, Marcus Stj¨ arn˚ as, Daniel Freeman, Mats Fröling, and Ola Dahlqvist for all support during the work. And of course Staffan Ljung and Karin Wahlström for being such great office neighbors. Special thanks to H˚ akan Gulliksson for five great years in Ume˚ a! Thanks to family, Glenn, Alice and our girlfriends for the support. In case we have missed someone, thank you too!

91

92

Chapter 11. Acknowledgements

References [1] Christoffer Andersson, Staffan Ljung, Daniel Freeman, Andy Johnston, and Ian James. Mobile Media and Applications, From Concept to Cash: Successful Service Creation and Launch. John Wiley & Sons, 2006. [2] Apple. Apple - iphone, 2008. iPhone.

Accessed 2008-10-24, http://www.apple.com/

[3] Leena Arhippainen and Marika Tähti. Empirical evaluation of user experience in two adaptive mobile application prototypes. In International Conference on Mobile and Ubiquitous Multimedia, 2003, 2003. [4] AshConsulting. Iso 13407: Human centered design process for interactive systems. Accessed 2008-07-09, http://www.ash-consulting.com/ISO13407.pdf. [5] Usability Professionals’ Association. Glossary - user experience:. Accessed 200810-27, http://www.usabilitybok.org/glossary. [6] Hrvoje Benko, Andrew D. Wilson, and Patrick Baudisch. Precise selection techniques for multi-touch screens. In CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems, pages 1263–1272, New York, NY, USA, 2006. ACM. [7] George Buchanan, Sarah Farrant, Matt Jones, Harold Thimbleby, Gary Marsden, and Michael Pazzani. Improving mobile internet usability. In WWW ’01: Proceedings of the 10th international conference on World Wide Web, pages 673–680, New York, NY, USA, 2001. ACM. [8] William Buxton. A three-state model of graphical input. In INTERACT ’90: Proceedings of the IFIP TC13 Third Interational Conference on Human-Computer Interaction, pages 449–456, Amsterdam, The Netherlands, The Netherlands, 1990. North-Holland Publishing Co. [9] Tina Calibra. Step two designs - an introduction to personas and how to create them, 2005. Accesses 2008-09-15, www.steptwo.com.au/papers/kmc_personas. [10] Cellular-news. Touchscreen: equipped mobile handset shipments to exceed 230 million by 2012, 2008. Accessed 2008-10-30, http://www.cellular-news.com/ story/32653.php. [11] A. Cockburn, J. Looser, and J. Savage. Around the world in seconds with speeddependent automatic zooming. In Proceedings of UIST’03 Symposium on User Interface Software and Technology, pages 35–36, 2003. 93

94

REFERENCES

[12] Andy Cockburn, Joshua Savage, and Andrew Wallace. Tuning and testing scrolling interfaces that automatically zoom. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 71–80, New York, NY, USA, 2005. ACM. [13] Andreas Constantinou and Matt Lewis. On-device portals: The next step beyond wap in data service monetisation. Technical report, ARCchart, London, UK, 2006. [14] Tony Cripps, Jessica Figueras, and Elsa Lion. Mobile user experience: your future depends on it. Report, Ovum, April 2007. [15] D. Dearman, B. MacKay, KM Inkpen, and C. Watters. Touch-n-go: Supporting screen navigation on handheld computers. Technical report, Faculty of Computer Science, Dalhousie University, 2005. [16] Densitron Corporation. Introduction to touch solutions. Technical report, Densitron Corporation, Santa Fe Springs, CA, USA, 2007. [17] Ericsson. Corporate information. Accessed 2008-10-30, http://www.ericsson. com/ericsson/corpinfo/index.shtml. [18] Ericsson. Evaluation of ericsson odp example client. Ericsson Internal. [19] Ericsson Consumer Lab. On-device portals: content analysis. Ericsson internal. [20] Clifton Forlines, Daniel Wigdor, Chia Shen, and Ravin Balakrishnan. Direct-touch vs. mouse input for tabletop displays. In CHI ’07: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 647–656, New York, NY, USA, 2007. ACM. [21] Jun Gong and Peter Tarasewich. Guidelenes for handheld device interface design. In Proceedings of the DSI 2004 Annual Meeting, 2004. [22] J. Grudin and J. Pruitt. Personas, participatory design and product development: An infrastructure for engagement. In Proc. PDC, pages 144–161, 2002. [23] J. Gulliksen, A. Lantz, and I. Boivie. User centered design-problems and possibilities. ACM SIGCHI Bulletin, 31(2):25–35, 1999. [24] Jefferson Y. Han. Low-cost multi-touch sensing through frustrated total internal reflection. In UIST ’05: Proceedings of the 18th annual ACM symposium on User interface software and technology, pages 115–118, New York, NY, USA, 2005. ACM. [25] Human-Computer Interaction Lab Department of Computer Science University of Canterbury Christchurch, New Zealand. Comparing Speed-Dependent Automatic Zooming with Traditional Scroll, Pan and Zoom Methods, 2003. [26] IBM. How the use of models facilitates designing for ease of use. Accessed 2008-07-09, https://www-306.ibm.com/software/ucd/designconcepts/ threemodels/introduction.html. [27] Takeo Igarashi and Ken Hinckley. Speed-dependent automatic zooming for browsing large documents. In UIST ’00: Proceedings of the 13th annual ACM symposium on User interface software and technology, pages 139–148, New York, NY, USA, 2000. ACM.

REFERENCES

95

[28] International Organization for Standardization. Iso 9241-11: Guidance on usability, 1998. [29] Irontech. Touch screen technologies. Accessed 2008-07-29, http://www.irontech. com/LCD/touch-screen.html. [30] Minna Isomursu, Kari Kuutti, and Soili Väinämö. Experience clip: method for user participation and evaluation of mobile concepts. In PDC 04: Proceedings of the eighth conference on Participatory design, pages 83–92, New York, NY, USA, 2004. ACM. [31] Jeff A. Johnson. A comparison of user interfaces for panning on a touch-controlled display. In CHI ’95: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 218–225, New York, NY, USA, 1995. ACM Press/Addison-Wesley Publishing Co. [32] A.K. Karlson and B.B. Bederson. Direct versus indirect input methods for onehanded touchscreen mobile computing. Technical report, Human-Computer Interaction lab, Computer Science Department, University of Maryland, 2007. [33] Amy Kathleen Karlson. Interface and Interaction Design for One-Handed Mobile Computing. PhD thesis, University of Maryland, College Park, 2007. [34] Jesper Kjeldskov, Connor Graham, Sonja Pedell, Frank Vetere, Steve Howard, Sandrine Balbo, and Jessica Davies. Evaluating the usability of a mobile guide: the influence of location, participants and resources. Behaviour & Information Technology, Volume 24, Issue 1 January 2005:51 – 65, 2005. [35] T. Kurata, N. Sakata, T. Oyabu, M. Korogi, and H. Kuzuoka. Tangible tabletop interface for an expert to collaborate with remote field workers. Joho Shori Gakkai Shinpojiumu Ronbunshu, 2005:DS–20, 2005. [36] Little Springs Design. Mobile usability testing on a budget. Accessed 2008-06-24, http://www.littlespringsdesign.com/analysis/utest/. [37] Sascha Mahlke. Lecture Notes in Computer Science, chapter Studying User Experience with Digital Audio Players, pages 358–361. Springer Berlin / Heidelberg, 2006. [38] Microsoft. Microsoft surface, 2008. Accessed 2008-10-24, http://www.microsoft. com/surface. [39] Andrew Murray. Touch screen, the right touch for high growth? Technical report, iSuppli Corporation, 2007. [40] Anjoo Navalkar. Usability engineering - quality approach (iso 13407). Accessed 2008-07-09, http://www.humanfactors.com/downloads/documents/ UsabilityISO.pdf. [41] Jakob Nielsen. Ten usability heuristics. Accessed 2008-10-27, http://www.useit. com/papers/heuristic/heuristic_list.html. [42] Jakob Nielsen. Iterative user-interface design. Computer, 26(11):32–41, 1993.

96

REFERENCES

[43] Jakob Nielsen. Why you only need to test with 5 users, March 2000. Accessed 2008-10-27, http://www.useit.com/alertbox/20000319.html. [44] Jakob Nielsen. Usability 101: Introduction to usability, August 2003. Accessed 2008-07-09, http://www.useit.com/alertbox/20030825.html. [45] Nokia Forum. Why usability & user experience. Accessed 2008-07-09, http://www.forum.nokia.com/main/resources/user_experience/usability/ why_usability.html. [46] Alex Olwal, Steven Feiner, and Susanna Heyman. Rubbing and tapping for precise and rapid selection on touch-screen displays. In CHI ’08: Proceeding of the twentysixth annual SIGCHI conference on Human factors in computing systems, pages 295–304, New York, NY, USA, 2008. ACM. [47] Pekka Parhi, Amy K. Karlson, and Benjamin B. Bederson. Target size study for onehanded thumb use on small touchscreen devices. In MobileHCI ’06: Proceedings of the 8th conference on Human-computer interaction with mobile devices and services, pages 203–210, New York, NY, USA, 2006. ACM. [48] Perspective Sciences Corporation. Personas: Useful design tool or the latest fad? Accessed 2008-10-30, www.perceptivesciences.com/insights/white_ papers/Personas.pdf. [49] Antti Pirhonen, Stephen Brewster, and Christopher Holguin. Gestural and audio metaphors as a means of control for mobile devices. In CHI ’02: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 291–298, New York, NY, USA, 2002. ACM. [50] Virpi Roto, Pekka Ketola, and Susan Huotari. User experience evaluation in nokia. In CHI 2008, 2008. [51] G. M. Smith and M. C. Schraefel. The radial scroll tool: scrolling support for stylus- or touch-based document navigation. In UIST ’04: Proceedings of the 17th annual ACM symposium on User interface software and technology, pages 53–56, New York, NY, USA, 2004. ACM. [52] Spencer. Ways to interact with a touch screen, 2007. [53] Synaptics Incorporated. New touch screens improve handheld human interface. Technical report, Synaptics Incorporated, 2001. [54] Bruce Tognazzini. The iphone user experience: A first look, 2007. Accesses 200808-12, http://www.asktog.com/columns/070iPhoneFirstLook.html. [55] UPA. What is user-centered design?, 2008. Accessed 2008-07-09, http://www. upassoc.org/usability_resources/about_usability/what_is_ucd.html. [56] Usability.gov. What is usability? Accessed 2008-07-09, http://www.usability. gov/basics/whatusa.html. [57] Daniel Vogel and Patrick Baudisch. Shift: a technique for operating pen-based interfaces using touch. In CHI ’07: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 657–666, New York, NY, USA, 2007. ACM.

REFERENCES

97

[58] Gerd Waloszek. Interaction design guide for touchscreen applications, 2000. Accessed 2008-07-29, http://www.sapdesignguild.org/resources/TSDesignGL/ INDEX.HTM. [59] Charlotte Wiberg. A Measure of Fun. Extending the scope of web usability. PhD thesis, Ume˚ a University, 2003. [60] Wikipedia. Ericsson.

Ericsson.

Accessed 2008-10-30, http://en.wikipedia.org/wiki/

98

REFERENCES

Appendix A

Usability test A.1

Tasks and Observations

Task #4 is excluded from the results because of bad formulation. 1. On the ”Home screen” there is a widget showing current Stock index. Whats the index of the stock in Stockholm? P1 Did not a first notice that she already was on the ”Home screen” and were looking for it. After realizing the location she solved the task fast mentioning that she remembered the widget from the 5 minute try. P2 Does only find the weather widgets. Quote:”I can not get the word Widget”. P3 Goes to ”Search”, did miss the word Widget in the question. P4 Had seen how to do in the 5 minute try. 2. You want CNN news to be easy to access since you often read them. Start ”News” and add ”CNN” from ”Top 25” to your Favorites. P1 Did not notice that she was on ”Favorites” in ”News” and that she first had to press top 25. Quote:”It is unclear what ”Favorites” and ”Top 25” are.” There were not two separate list for the categories at this point, this caused likely the problems. P2 Does first not see that the location is Top 25 P4 Checks in Options. Then does not notice Top25 at first. Quote:”Whose Top 25/Favorites?” 3. Since you often play ”Tetris”, you want it be easy to access. Add ”Tetris” to your ”Home screen.” P1 Looks first for ”Tetris” in ”Stuff” and want to move it from there. Looks secondly in ”Options” and then she founds it on the ”Home screen” P2 Back/Exit/Quit is hard to understand/separate. Should point to Home/Stuff instead. P3 Quote: ”Where is back to home.” Believe there is one step much to reach Exit. 99

100

Chapter A. Usability test

4. Excluded! You want a CNN application in your ODP. How many hits that are applications do you get when searching for ”CNN”? P1 Navigates to ”Stuff”, ”This is were I find applications”, wonders if she will find it in market or by search directly, goes to search, press search and then the ”Market tab” quickly. P2 Wants to go out on the web to search. Connects Search in to prototype to be a local search within the phone. P3 Not clear the market is applications. Quote:“sn’t all three of them applications.” P4 Some problem understanding what to look for. 5. You are tired of the ”Napster” application and does not want it on your ”Home screen” any more. Remove it from the ”Home screen”. P2 Wants to ”right click” at first. Then to drag ”Napster” to a trash bin. P4 Did press ”Stuff” by mistake causing the fail. 6. You are interested in the latest wordwide news. Read the latest news from ”CNN”. P1 First checks the ”Home” widgets, ”These are the most lately”. Then ”News” P2 Had seen how to do in the 5 minute try. Not problem to remember how to do it again. P3 ”Latest” not a good word. Otherwise no problem. 7. You want to organize your widgets. Move the ”Weahter widget” to the right of the ”Stocks widget”: P1 Tries first to drag and move up the weahter-widget directly. Then find move in options. P2 Wanted to first Add+ a new widget to the right and then remove the current weahter widget. This can be a alternative solution. Does not looking two or more ways to do the same thing. Does not like douple-tap. P3 Does not first look in Options. 8. You want a new game in your ODP. Among the latest games in the ”Market” is ”Tennis”, buy it. P1 Did not react on the transition to ”Confirm buy”. Did not react on the loading screen but was at the time in discussion with the researchers. 9. You want to change the look of your ODP. Change the background to ”White three”. P1 Wants to start from ”Home”, looks in ”Options”. Then remembers personalize from earlier and find the solution. Quote: ”Why is options in ”Stuff”, ”Stuff is not options for me. P2 Does first look in Home because ”it is not related to the other applications”. Looks inside Options in Home. P3 Add 100 sec. Wants to start in Home, checks in Options. Looks for Settings. Needs Assist to find Personalize P4 Looks in Options at first. Then find personalize.

A.2. Following questions and answers

101

10. You want to try the ”Tennis games” you bought earlier, start it. P3 Did forget about the other page in ”Stuff”. 11. You want to clean up among your favorites in News. Remove SvD from favorites. P1 Quote: “Why are these texts here?” P2 Did not find ”Options” at first. P3 Wants to ”select” SvD then ”Options”. After establishing that the first alternative is not possible Remove in Options was found. P4 Finds Remove to be illogical. 12. You want to organize to make some applications easier to access. Move the applicaton TV-guide to page 2 in ”Stuff” P3 Did start TV-guide first. The no problem finding Move in Options. P4 Good exept that she presses the ”help texts.” 13. You wonder if the news have been updated since last time you read them. Which news sources are updated since you were in ”News” last time? P1 Quote: “Orange and Gray are bad colors” P2 Had seen how to do in the 5 minute try. Not problem to remember how to do it again. P3 Goes to ”Search” in News, then Top 25 P4 Did look at the time of the News, did not see the gray and orange icons. 14. Remove your CitiBank applications, you do have another bank. P1 ”Remove” not higlighted when its chosen and that feels weird. P2 Taps on the ”help text” in Options. P3 Want to start from ”Home.” Starts CitiBank, then remember about Options 15. You want a new widget showing the latest news from CNN. Add a new widget in your ODP. P3 Checks in Options first, then no problem. P4 Checks in Options, then for DN in News, finally she remembers how to Add a widget from the 5 minute try. 16. Your are now finished using your ODP for this time, close the application. P3 No problem, had learned how to do from earlier.

A.2

Following questions and answers

1. Do you think the icons in the ODP were simple to understand? If not, which ones were hard to understand? P1: Options hard to understand. Remove icon = traffic sign for one-way street. Exit/Quit is easily mixed, “Place to the top right or something”. P2: Options is hard to understand.

102


P3: Read and click on the text in Options. Remove should be placed beside Add. P4: Options is boring and messy. Otherwise OK. 2. Do you think it was easy to understand the different options in the menus? P1: Stuff is hard to understand. Personalize is not placed on a logical place, why is it among applications? P2: Options was unclear. Edit or Manage is a better word. Search is also hard to understand, search what? P3: I will learn. Would prefer a list with icons instead of the menu/help text in Options. Stuff = file explorer or menu? P4: Quote: “Why is it not possible to add in options, when you can remove there?” Miss a constant back button. 3. Did you get enough feedback from the ODP when using it? Did you feel that anything happened suddenly or without your permission? P1: Good feedback. Nothing happened sudden. P2: The page indicator in Stuff is a little bit unclear. Make larger and clearer. P3: Latest/Top 25 unclear. P4: Yes, you can see animations and highlights. 4. Do you find the layout and colors in the ODP attractive? P1: The background is ”photographic” and the icons ”animated”. P2: Yes, the grayish theme is nice. Would like to change names and skin and is ready to pay for it. P3: Shortcuts in a widget, would like to see the whole background. Finger touch is nice. P4: Clear colors, attractive, and good looking. 5. Do you think the animations and transitions had a smooth flow? P1: Did not think or notice them in particular but thinks it is ”flashier” with them. P2: Yes, with a slight lag. Fade the different screens instead..? P3: Quote: “It is like going with a train, you see where you going” P4: Yes, they are smooth 6. Do you get the feeling that you can suit the ODP according to your interests and taste? P1: Quote: “Yes, isn’t that what it is supposed to do” P2: Quote: “Yes, like my computer” P3: Would like to change skins if possible. P4: Yes, both in Home and Stuff. Home is more like your favorite content.

A.2. Following questions and answers

103

7. Did you find the ODP fun to use? If not, what do you think about it? P1: Good pastime. Quote:“It compresses all content, from computers and internet so that it fits in the mobile phone”. P2: It is fun, if it does not cost me a lot of money. P3: Yes, if it is free. It is a lot about cost. More entertainment than business. P4: Yes, simpler than internet in my mobile phone. 8. Do you find the content in the ODP organized in a logical way? P1: Personalize is not were it should be. Tetris to Options should be the flow not the opposite direction as it is now. P2: The favorite shortcuts on the Home screen should be places in a widget. The search function should be targeted on the web only. P3: Search what? P4: Favorite/shortcuts are unnecessary 9. What do you feel about the design overall, describe with three words or more. P1: Adaptable, fun, well-filled, original, intelligent and rich of content P2: Elegant, cool, and function vs. design. Does not like the word ”Stuff”, Program instead..? P3: Classy, complete, and modern P4: Simple, good looking, clean, fast. More user friendly than my mobile phone.

104


Appendix B

Fulfilled requirements #4 The system should be easy to learn - After 30 minutes of use the user shall be able to complete common tasks and navigation Motivation: The TAM scale used in the usability test shows that the Ease of use mean is 5,2 of 7 indicating that the product is easy to use. Also when asking attendees after the test they felt confident to operate the ODP after learning how. #5 The GUI actions and elements should be consistent in main and sub menus - The same GUI elements shall be used in the entire application Motivation: The same GUI elements is used for the same functionality. See screenshots. #7 Undo functionality should be available for most actions - A clearly marked undo functionality shall be available Motivation: All actions that make a change in the application can be undone. #8 Actions which cannot be undone should ask for confirmation - Confirmation shall use natural language and the user shall be able the cancel the confirmation Motivation: When the user buys something in Market, there is a confirm buy button and a back button. #9 The system shall give consistent and direct feedback - Feedback shall be clearly visible and if the feedback consists of text; natural language shall be used Motivation: The test users said: “Yes, you can see animations and highlights” and “Good feedback, nothing happened sudden.” #10 The response on interaction shall be direct - Response time shall not be more than 12 second Motivation: The response time is not measured but is never longer than 105

1 2

second.

106

Chapter B. Fulfilled requirements

#11 Interaction shall be possible with one finger at all time - No multi-touch functionality shall be used Motivation: No multitouch are implemented and all features can be operated with a finger (no stylus is needed). #13 Information about location in space shall always be given - Scrollbars or other similar marking shall be available Motivation: These information are given in all implemented locations in the prototype. #14 The screen layout and color should be attracting for the target group 80% of the target group shall find the layout and colors attracting Motivation: All test attendees found the layout and color attracting, some quotes are: “Yes, the grayish theme is nice.” and “Clear colors, attractive, and good looking.” #15 The flow in animations / transitions and change of views shall be smooth and not lag - The flow shall be perceived as smooth by the users Motivation: When asking test attendees question 5 one of them said: “It is like going with a train, you see where you going.” This clearly indicates that the trasitions are smooth and not sudden. #16 When possible should a search feature be accessible by one click - Search functionality shall be available and easy to access Motivation: The search functionality is always one click away in the main parts of the ODP prototype. #18 The ODP shall be configured the first time for the user to map interest with content - A tutorial with choices for personal interests shall be available Motivation: The conceptual idea is implemented and clearly shown in the prototype. A functional wizard are not implemented because of the offline limitation and lack of time. #20 Easy access to desired content; It should be easy to find and zoom in on information - Provide shortcuts to favorite content Motivation: The design allows the user to customize the Home screen shortcuts and widgets as well as move the applications in their own order in Stuff. #21 Good looking - It should be seductive but not to much - 80% of the user shall find the application good looking Motivation: When asking usability tests attendess this they answered with positive feedback not mentioning that it was to much for their taste, see Appendix A.2 question 4.

107

#23 Good overview - what is hot right now? - The application shall provide a good overview of the content Motivation: New and popular content are shown in Market and News. The widgets provide updated ”online”/”live” information directly on the Home screen. #24 “I want it to be like buying and own my nice car, style/specify it and then drive where I want, fast and good looking” - Give the user a feeling that the application belongs to oneself Motivation: When asking test attendees Appendix A.2 question 6 “Do you get the feeling that you can suit the ODP according to your interests and taste?” they answered: “Yes, isn’t it that it is supposed to do”, “Yes, like my computer”, “Would like to change skins if possible”, “Yes, both in Home and Stuff. Home is more like your favorite content.” #25 The best selection of content: Tell me what’s hot - Show the user what is popular and what is the latest content Motivation: See motivation for requirement #23 above. #26 I want to read local news - Give the user access to news Motivation: This is made through the News application and it is possible to add a news widget on the Home screen. #27 I want to check local weather for the barbeque tonight - Give the user access to weather data Motivation: This is made through the weather widget on the Home screen. #29 I don’t know it, but a mail notification in the ODP could release me from having to start my computer every once in a while just to check my mail - Give the user access to e-mail Motivation: Notification can be made directly on the icons/shortcuts of applications. See screenshots and look for the Gmail icon. #30 “I want it to be all fun in one place, so I can stay updated, fulfill my big social needs, all in my phone” - The application shall be fun to use Motivation: When asking test attendees question 7 from Appendix A.2, “Did you find the ODP fun to use? If not, what do you think about it?” they answered: “It compresses all content, from computers and internet so that it fits in the mobile phone”, “It is fun, if it does not cost me a lot of money”, “Yes, simpler than internet in my mobile phone”. The money issue are up to the provider to solve in a good way inform about it. #31 I want to be able to share content - Give the user ability to share content Motivation: News articles can be shared. Otherwise sharing is limited but the functionality can easily be added in the design (probably with more technological issues).

108

Chapter B. Fulfilled requirements

#32 I want the latest fashion news - Give the user access to news Motivation: Solved by the News applications and search functionlity where one can search for fashion news. #33 I want to check local traffic time-tables - Give the user access to timetables Motivation: Can be solved by applications/widgets and web search functionlity. #34 I want to check my mail - Give the user access to e-mail Motivation: Can be made in applications/widgets and web browser. #35 I want to be instant messaging and have a status - Give the user access to instant messaging clients Motivation: IM clients can be installed/downloaded. #36 I want to keep track of my communities, e.g., Facebook - Give the user access to web communities Motivation: Can be made in applications/widgets and web browser. #37 I want to check local news - Give the user access to news Motivation: Can be made in applications/widgets and web browser/search or, of course the News application. #38 The prototype shall be fun to use - 80% of the user shall find the application fun to use Motivation: See motivation for requirement #30. #39 Phone bill etc. shall be an application - Give the user access to operator based information Motivation: Solved through a Operator application which is also among the applications if Stuff in the prototype. #40 Help should be found on the same place in the entire ODP - The application shall have a help function available, and it shall be easy to access Motivation: Help is always accesible as an application. Maby not the best solution in all cases but fulfills the requirement. #41 Feeds/News are one-way communication - Feeds shall only be readable, can include web links though Motivation: News are one-way except web-links and a recommende share feature. The news cannot be changed in any way.

Touchscreen GUI Design and Evaluation of an On-Device Portal

Touchscreen GUI Design and Evaluation of an On-Device Portal

Suggest Documents