enhancing the user experience for a mobile signup · application to their imap or microsoft...

Enhancing the User Experiencefor a Mobile Signup

Max Hellstrand and Arvid Kandell

January 20, 2013

Master’s Thesis in Computing Science, 30 credits

Supervisor at CS-UmU: Frank DrewesExaminer: Anders Broberg

Umea UniversityDepartment of Computing Science

SE-901 87 UMEASWEDEN

Abstract

The last couple of years email has stretched beyond the desktop computer andinto the mobile devices. Visiarc, a company in Linkoping, developed an appli-cation called Mobile Documents to cater for this new market. With the use ofCloud Computing techniques, the application lets the user access large attach-ments sent to them to view them in the device without having to downloadany file to the device itself.

The main focus of this thesis is the signup for Mobile Documents on the Androidplatform, utilizing methods and techniques from the field Human-Computer In-teraction to develop a new design for the signup process with high regard tothe common user, and integrate it into the existing architecture of the service.The thesis covers theoretical aspects that were taken into account regardingusability guidelines and heuristics when developing for the end consumer soft-ware market. The developed signup covered in this thesis was integrated intothe new release of Mobile Documents for Android in February 2011.

In addition to featuring the work at Visiarc the thesis contains two chaptersdiscussing particular aspects of mobile technology, “Utilization of Cloud Com-puting in Mobile Applications” and “Designing for Small Screens”. The formerdiscusses the recent development of Cloud Computing and how that can be ap-plied to also include mobile applications. The latter presents guidelines whendeveloping the GUI for small screen devices.

Contents

1 Introduction 1

1.1 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Visiarc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Mobile Documents . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Distribution of work . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 6

2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Push Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Existing Applications . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5.1 Email protocols . . . . . . . . . . . . . . . . . . . . . . . 9

3 Problem Description 11

3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Integrating FAQ into the signup process . . . . . . . . . 12

3.1.2 Developing a GUI with an aesthetic appeal and an ap-

propriate look and feel . . . . . . . . . . . . . . . . . . . 12

3.1.3 Developing a prototype in Android . . . . . . . . . . . . 12

3.1.4 Implementing a prototype that was to be integrated into

the application . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Challenges of email account setup . . . . . . . . . . . . . . . . . 13

3.3 Email account setup . . . . . . . . . . . . . . . . . . . . . . . . 14

iii

iv CONTENTS

4 Method 16

4.1 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 HTA (Hierarchical Task Analysis) . . . . . . . . . . . . 16

4.1.2 Iterative design process . . . . . . . . . . . . . . . . . . 17

4.1.3 Agile Software Development . . . . . . . . . . . . . . . . 18

4.1.4 Technical tools . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.5 Creative tools . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Utilization of Cloud Computing in Mobile Applications 20

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.1 Origin of Cloud Computing . . . . . . . . . . . . . . . . 21

5.2.2 Understanding Cloud Computing . . . . . . . . . . . . . 21

5.2.3 Components in Cloud Computing . . . . . . . . . . . . 23

5.2.4 Utilization of Cloud Computing today . . . . . . . . . . 25

5.3 The usefulness of Cloud Computing in mobile applications . . . 28

5.3.1 The Advantages of using Cloud Computing in mobile ap-

plications . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.2 The Disadvantages of using Cloud Computing in mobile

applications . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4 Discussion and Conclusion . . . . . . . . . . . . . . . . . . . . . 30

6 Designing for small screens 32

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3.2 Know the target group . . . . . . . . . . . . . . . . . . . 35

6.3.3 Prioritize the content . . . . . . . . . . . . . . . . . . . 35

6.3.4 Fulfill the users expectations . . . . . . . . . . . . . . . 35

6.3.5 Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.6 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.7 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.8 User input . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

CONTENTS v

7 Design 39

7.1 Theoretical foundation . . . . . . . . . . . . . . . . . . . . . . . 39

7.2 Schneidermans Eight Golden Rules . . . . . . . . . . . . . . . . 40

7.3 The Interface Guidelines Applied to Developing for Mobile Devices 41

7.3.1 Enable frequent users to use shortcuts . . . . . . . . . . 41

7.3.2 Offer informative feedback . . . . . . . . . . . . . . . . . 41

7.3.3 Design dialogs to yield closure . . . . . . . . . . . . . . 42

7.3.4 Support internal locus of control . . . . . . . . . . . . . 42

7.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.5 Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.6 Progress bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.7 Folder list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Results 48

8.1 Android signup . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.1.1 The navigation area . . . . . . . . . . . . . . . . . . . . 49

8.1.2 The header . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.1.3 Start page . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.1.4 Name page . . . . . . . . . . . . . . . . . . . . . . . . . 54

8.1.5 Existing template page . . . . . . . . . . . . . . . . . . . 56

8.1.6 IMAP/Exchange page . . . . . . . . . . . . . . . . . . . 57

8.1.7 Exchange settings page . . . . . . . . . . . . . . . . . . 59

8.1.8 IMAP settings page . . . . . . . . . . . . . . . . . . . . 62

8.1.9 Folder selection page . . . . . . . . . . . . . . . . . . . . 66

8.1.10 Confirm folder page . . . . . . . . . . . . . . . . . . . . 71

8.1.11 Delete/sent mail folder page . . . . . . . . . . . . . . . . 72

8.1.12 Signature page . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.13 Pin page . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1.14 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.1.15 Google docs and Captcha . . . . . . . . . . . . . . . . . 79

8.1.16 Sign-up completed . . . . . . . . . . . . . . . . . . . . . 81

8.1.17 Desktop signup . . . . . . . . . . . . . . . . . . . . . . . 81

9 Conclusions & discussion 88

9.1 Restrictions and Limitations . . . . . . . . . . . . . . . . . . . . 89

vi CONTENTS

10 Acknowledgements 91

References 92

A Hierarchical Task Analysis 95

Chapter 1

Introduction

Email has for the last couple of years stretched beyond the desktop computerand into our mobile devices. Enabling continuous access to their email inboxis vital for many professions today and being able to give a quick response toclients may be what separates success from failure. This development createsa few changes though, mainly due to the restriction in mobile device perfor-mance with regard to hardware and network. Email in the mobile devices isan expanding market with many new areas to conquer and the first companieswith a service that meets the requirements and appeals to the public will havea good head start.

Visiarc is a company in Linkoping that develops a product called Mobile Docu-ments. This is a software-plus-service application that strives to abbreviate therestrictions mentioned above to a point where a user accessing email througha mobile device comes close to being as seamless as if the user were sitting bya desktop computer. This vision is also described with their motto:

“OUR FOCUS IS FIVEFOLDmobility, security, usability, usability & usability.” 1

With the use of Cloud Computing techniques, the application will let the useraccess large attachments sent to them to share with others or view them inthe device without having to download any file to the device itself. The userachieves this by installing the software on their smartphone and then sync theapplication to their IMAP or Microsoft Exchange email account.

This thesis covers the work of Max Hellstrand and Arvid Kandell with Mo-bile Documents during the fall/winter of 2010-2011. The work focused mainly

1Visiarc, http://www.visiarc.com, retrieved: 2011-03-30

1

2 Chapter 1. Introduction

on the signup for Mobile Documents on the Android platform, developing anew design for the signup process with high regard to the common user andintegrating it into the existing architecture of the service.

1.1 Thesis outline

This thesis is divided into the following chapters:

1. Introduction

Chapter 1 contains an introduction to the thesis. The thesis is presentedalong with the client, Visiarc, and a description on how the work withthe thesis was distributed.

2. Background

Chapter 2 contains background information and a short overview of var-ious techniques relevant to the thesis.

3. Problem description

Chapter 3 covers the main task of the master thesis and the goals thatwere set. Different challenges with the thesis are also presented in thischapter.

4. Method

Chapter 4 describes how the work on the thesis was carried out withvarious processes.

5. Utilization of Cloud Computing in Mobile Applications

Chapter 5 contains an article about Cloud computing, written by MaxHellstrand.

6. Designing for small screens

Chapter 6 contains an article about designing for small screens, writtenby Arvid Kandell.

7. Design

Chapter 7 describes the design process and the different design proposalsthat were created both for the Android application and the desktop webclient.

8. Results

Chapter 8 covers the results of the thesis, the finished signup for theAndroid platform and the mockup of the desktop version.

1.2. Visiarc 3

9. Conclusions and discussion

Chapter 9 covers the conclusions made from the thesis along with a dis-cussion.

10. Acknowledgements

Chapter 10 contains acknowledgements to the people that have giventheir support during the work with the thesis.

1.2 Visiarc

Visiarc is a Swedish company that was founded during the fall of 2002 andhad shortly after its incorporation created the world’s first mobile enterprisesolution for on-demand OTA (Over-The-Air)2 access and visualization of tech-nical information. Visiarc is an independent software vendor, ISV, which is abusiness term for companies specializing in making or selling software3. Theydevelop leading mobile technology with focus on security and usability andsince the start they have been pioneers in the enterprise mobility space.

Today Visiarc have widened their scope to a generic platform in the Software-Plus-Service4 space by creating Mobile Documents, an email application forsmartphones with Google’s Android or Nokia’s Symbian operating systems.According to Visiarc themselves, Mobile Documents is the first service releasedin the next generation of mail, Email 2.0, with Push Mail.

1.3 Mobile Documents

Mobile Documents5 is the new email application developed by Visiarc. It is,at the moment of writing this thesis, available for mobile devices running theAndroid or Symbian operating systems. Visiarc have been developing MobileDocuments since 2007 and a Beta version is available at Android Market6 andOvi store7.

The main idea behind Mobile Documents was to create an email applicationthat could handle email attachments in more ways than the common mobile

2Gemalto, http://www.gemalto.com/techno/ota/, retrieved: 2011-08-013ISV,http://searchitchannel.techtarget.com/definition/ISV,retrieved: 2012-04-154Microsoft, http://msdn.microsoft.com/en-us/architecture/aa699384.aspx,retrieved: 2012-02-135MobileDocuments, https://mobiledocuments.com/, retrieved: 2011-03-316AndroidMarket, https://market.android.com/, retrieved: 2011-03-317OviStore, http://store.ovi.com/, retrieved: 2011-03-31

4 Chapter 1. Introduction

email applications. Integrating features for handling different types of files asstreamed content.

As a technology email was initially developed for computers. As the perfor-mance of the computers has increased throughout the years, the email clientshave evolved and become more advanced with new features.

Now when the cell phones have come into play as email reading and compilingdevices there is a need to look over some of these features and see to what degreethe email features can be integrated and applied on a mobile device. Accordingto Visiarc8 the handling of email attachments is one of these features.

A cell phone has limitations compared to a computer with regards to screen size,memory, user interface and network speed9. Normally, to open an attachment,a user has to download the complete attachment before viewing it. This isa process that can be very time consuming if the connection is poor or theattachment is very large. To cope with this problem Mobile Documents iscloud-boosted and opens the attachments server-side which gives the user thepossibility to look at the attachment without a complete download10. Thisfeature in Mobile Documents provides the user with the possibility to openthe attachment instantly regardless of its size. By using Mobile Documents, itis possible for the user to save both time and memory storage on the device.The computer traffic is also kept to a minimum which significantly minimizespotential roaming costs.

In addition Mobile Documents provides the user with several tools and optionsfor handling the attachments, such as view, read, info, copy, download anddownload as PDF using integrated readers.

Another feature of Mobile Documents is the possibility to connect several dif-ferent email accounts in one single Mobile Documents account. This featurewill let the user read and send emails from different email accounts using oneapplication, and make use of Mobile Documents features on more than oneemail account. At this moment, Mobile Documents support all email accountsthat are based on the IMAP and Exchange email protocols.

The Mobile Documents application has been rewarded with several awardsand recognitions. The latest, at the time of the writing of this thesis, was theOvi/Nokia Store “Must have app of the year 2010 award Business/Productivitycategory” which they won in the fall/winter of 201011.

8Visiarc, http://www.visiarc.com/press/#gamechanger, retrieved: 2011-03-319Technology Time, http://www.strangefuture.com/?p=37, retrieved: 2011-08-28

10MobileDocuments, https://mobiledocuments.com/, retrieved: 2011-03-3111Must-Have App of the Year Awards,

http://blog.ovi.com/dailyapp/global/2011/01/meet-the-winners-of-ovi-daily-apps-must-have-app-of-the-year-award,retrieved: 2011-03-31

1.4. Distribution of work 5

1.4 Distribution of work

In the initial phase of the project all work was executed collaboratively by us,Arvid K. and Max H. We needed to find a common ground to start from, bothbetween ourselves and with the client Visiarc. Discussing and planning to mapthe upcoming work was a task that we found only could be completed as acombined effort to avoid any possible confusion between the parties.

After the pre-study we entered the design and implementation phase. Theplanning had given us a representation of the upcoming work and with thecollection of tasks we had formulated we could divide the upcoming work.

In the initial design phase, where we produced mockups and design proposalsfor the signup, we worked partially individually to finally combine our effortsinto the design proposals we were to deliver.

A common scenario could be that we would design a tree structure or a signupform. Initially we had a discussion about what in general would be expected ofthe view, which I/O information that was essential at the moment etc. Afterthe discussion we each designed mockups for a possible solution individually.The mockups were later presented and we discussed our proposals, iteratingdesign choices and reviewing what was done by the authors.

After the proposals had been reviewed we could exclude the design choices thatwere not up to par and include the design choices that would suite the solution.The final design choice was developed collaboratively, and in case we differedin opinion on a certain design choice we would present proposals that coveredboth variations.

At the start of the implementation phase we both set up an individual Java-project in which we started to develop some basic Android applications. Noneof us had any prior experience in developing for Android and by building afew simple applications we got an understanding in how to utilize the Androidframework and build our application.

During the implementation of the signup the work was more or less dividedinto two different parts, one part that included the code behind handling logicand server communication and one part that handled the GUI. Arvid K. wasresponsible for the logic and Max H. was responsible for the GUI. We collabo-rated and helped each other on different parts but the main focus was on ourrespective parts of responsibility. A revision control system, TortoiseSVN12,enabled us to work with the same solution on separate work stations.

This thesis has been written by both of us, Arvid K. and Max H, using GoogleDocs as a collaborative word editor whilst communicating over Skype or phone.However, chapter 5 is written entirely by Max H. and chapter 6 by Arvid K.

12TortoiseSVN, http://tortoisesvn.net/, retrieved: 2012-02-13

Chapter 2

Background

The background section will discuss the techniques and context of the MobileDocuments application. It will present the techniques that are of a particularimportance for making the Mobile Documents client and its back-end work.

2.1 Cloud Computing

A definite and final definition of what is meant by Cloud Computing is hard tofind. An obscurity between developers, journalists, users and other stakeholdersis not uncommon for new techniques, and cloud computing is no exception. Oneof the more popular definitions is:

“Cloud computing is a model for enabling convenient,on-demand network access to a shared pool of configurable com-puting resources (e.g., networks, servers, storage, applications, andservices) that can be rapidly provisioned and released with minimalmanagement effort or service provider interaction.” [25]

Both the applications delivered as a service over the Internet and the hardwareand systems software in the data centers that provide those services are whatconstitutes Cloud Computing. One of the advantages Cloud Computing hasover conventional IT architecture is the freedom of scalability since it is roughlythe same cost to run one server for a thousand hours as a thousand serversfor one hour. Meaning that as far as in service operation the same financialformula can be used for one hundred users as 100,000 users. Because of this,server capacity and count can quite easily be increased or decreased as there isa shift in demand [6].

6

2.2. Push Mail 7

2.2 Push Mail

Push Mail is a commonly used technique to deliver emails to a mobile device.It may be described as an email service with ubiquitous communications withits servers. Push Mail is using an email delivery system that has the abilityto “push” the email to the client as soon as it arrives rather than require amanual poll by the client1.

2.3 Android

In November 2007 Google announced that they were officially entering themobile phone business. They were entering the market with a new mobiledevice software platform, an operating system called Android2. Two majorfactors that made the mobile industry interested in Android were the factsthat it was an open source project and that it was built on a Linux kernel. Thefact that it was open source allowed developers to fully utilize the capabilitiesof Android and the Linux kernel-based architecture model also brought Linuxinto the mobile industry [29].

Android applications are Java-based. Since the release it has attracted morethan 180 000 developers3 and by June 2012 there were more than 600 000applications available at Android Market4. There are also more than 60 smart-phones on the market from different major manufacturers that run the Androidplatform [8].

2.4 Existing Applications

There are several existing smartphone email applications available at the mar-ket today, and many of them are developed exclusively for the Android OS.Some of the existing email applications were analysed to get an understandingof what was available on the market and what their signups looked like.

A small range of smartphones were provided by Visiarc to be investigated. Allthe smartphones came with pre-installed email clients right out of the box.Both Android and iPhone (iOS) have their own email applications. Two of the

1Push email, http://www.wisegeek.com/what-is-push-email.htm,retrieved: 2012-12-27

2Google Launches Android, http://googlesystem.blogspot.se/2007/11/google-launches-android-open-mobile.html, retrieved: 2012-04-16

3Android central, http://www.androidcentral.com/android-market-now-has-more-quarter-million-applications, retrieved: 2011-06-14

4Tech crunch, http://techcrunch.com/2012/06/27/google-play/,retrieved: 2012-11-04

8 Chapter 2. Background

most popular email applications available at Android market are the Gmailemail application5 and the K-9 email application6.

A complete install and a signup with all of the four different email applica-tions was conducted. The main focus were the signups themselves and not thefunctionality of the applications when an email account was connected. Thegoal when analyzing the applications was to obtain a couple of ideas for howto create a good signup to integrate into Mobile Documents.

The evaluation showed that the signup on all the applications were more or lessthe same, with straightforward input fields where the user had to enter specificinformation about the email account. This did not come as a surprise due tothe fact that the information is necessary for enabling a third party applicationto connect to an email account. All of the applications also tried to connectto the account with only the user name and password if the application recog-nized the email provider. However, if the email application did not recognizethe email provider, none of the signups did explain why the specific informationwas required and how the user could obtain the information. The users wereexpected to understand and know what input they were asked for in the differ-ent input fields, i.e. port numbers, security protocols and different servers forreceiving and sending emails. Another issue was that none of the applicationshad any settings for selecting specific folders to be shown in the application orsettings for notifications on specific folders. The conclusion from the testingwas that there really were no tips to get from the existing applications in themobile domain.

It was decided to see what a signup could look like on a computer and a signupwas then completed with Microsoft Outlook 2007. It appeared that the largerscreen size on a computer, compared to a smartphone, made it possible for amore informative signup, which was also the case. Outlook was much moreexplanatory about the various input that was required and had a guide thathelped the user through the signup. Aiding the user in completing the signupwas one of the key issues with the signup and the testing of Outlook gave a fewideas on what kind of information that was to be provided to the users.

2.5 Email

This section explains the technical aspects of Email (Electronic-mail) and dis-cusses a range of protocols that are of special significance for this thesis.

5Gmail Android Market, https://market.android.com/details?id=com.google.android.gm&feature=search result#?t=W251bGwsMSwxLDEsImNvbS5nb29nbGUuYW5kcm9pZC5nbSJd,retrieved: 2012-02-13

6K-9 Android Market, https://market.android.com/details?id=com.fsck.k9&feature =search result#?t=W251bGwsMSwxLDEsImNvbS5mc2NrLms5Il0,retrieved: 2012-02-13

2.5. Email 9

2.5.1 Email protocols

The type of email protocol that is used to send and receive emails specifieswhat possibilities and limitations it has. It builds up a framework of what canbe done with the email and in which ways one may interact with it.

Here follows a selection of email protocols, some of which had part in the workperformed at Visiarc:

IMAP

IMAP (Internet Message Access Protocol) is an Application Layer Internetprotocol that is used to send emails to a client from a server. It was firstdeveloped by Mark Crispin in 1986 but entered the arena first in 1988 as itsfirst publicly distributed version called IMAP27. It allows a client to accessand interact with email messages on a server. It will allow the user to interactwith their mailboxes (remote message folders) in a way that is functionallyequivalent to the interaction they get with local folders. The client usuallyoffers the feature to read emails even in offline mode.

SMTP

SMTP (Simple Mail Transfer Protocol) is a protocol used for sending an emailover the Internet8. It has its roots back to various forms of one-to-one electronicmessaging implementations back in 1970’s. However it was published as aSMTP technique first in 1982 by Jon Postel. SMTP is designed as an emailtransport and delivery protocol. The objective of the protocol is to transferemail reliably and efficiently. It is independent of the transport subsystemand can be applied to other types of data connections than TCP since it onlyrequires a reliable ordered data stream channel to operate. This allows SMTPto transport mails across multiple networks e.g. a LAN or WAN environmentutilizing a non-TCP transport-level protocol [16].

Exchange Server

This is the server side of a client-server collaborative application product devel-oped by Microsoft. Its major features consist of email, calendaring, contacts,tasks, support for mobile and web-based access to information and support fordata storage.

7IMAP, http://www.tcpipguide.com/free/t IMAPOverviewHistoryVersionsandStandards-3.htm, retrieved: 2012-04-12

8Siteground, http://www.siteground.com/tutorials/email/email clients.htm,retrieved: 2011-12-05

10 Chapter 2. Background

POP3

POP (Post Office Protocol) is an email transfer protocol developed in the mideighties that only offers the capability to read emails from a single client. Theprotocol will compel the client to download the email for viewing and in mostcases the email is deleted server side. If a user have a traditional relation totheir email and only access the emails from one source (computer) POP wouldstill work fine. But nowadays when one have the email account synced to anumber of clients (home computer, laptop, work computer, cellphone, tabletetc . . . ) it is a reality POP was never intended for [32].

Chapter 3

Problem Description

This chapter will cover the main task of the master thesis and in detail describethe goals of the assignment. It will also specify the purpose of this thesis. Inaddition, the major challenges of completing the project will also be presentedin this section.

3.1 Goals

The main focus for this project was to, in collaboration with the Visiarc staff,redesign the existing signup process of the Android version of Mobile Docu-ments. The finished product was to be implemented to a degree where it couldbe integrated in the version update release 14/02/2011. The new signup wasalso to be implemented in native Android. The existing signup was imple-mented in Google Web Toolkit (GWT).

The Mobile Documents application has at this point received many recognitionsand won several prizes for innovation1. The Visiarc staff felt that they offeredsomething unique on the market and continuous appreciation from the userbase fueled that conviction. However, for a long time they had struggled witha problem, a considerable portion of the potential users initiating the MobileDocuments signup process never finished it. Somewhere along the signup peopledecided to drop out. This was a serious problem since Visiarc missed out on afairly large amount of users due to an inadequate signup process. Designing amore intuitive and user friendly UI and a semantically understandable processfor reassuring the user was a task that the Visiarc staff did not feel that theyhad the time to realize.

1MobileDocuments, http://blog.mobiledocuments.com/, retrieved: 2011-04-28

11

12 Chapter 3. Problem Description

One of the subgoals, with lower priority, was to make a design proposal for theMobile Documents signup via web. This design proposal was to be presented asmock-ups of the web GUI with no underlying logic, in short no implementationwas to be performed in that task. The main goals were as followed:

The main goal with the project was to develop a GUI for the signup whichwould result in more users completing the signup. More users would result inmore potential customers which would generate a greater revenue. In orderto map out how this main goal could be achieved, a large set of subgoals, allleading towards the main goal, were defined. When a large set of subgoalswere defined, it was possible to set up milestones and create a timeline for theproject.

3.1.1 Integrating FAQ into the signup process

In the existing version of the signup the user had rarely, if ever, any ways ofgetting help when being faced with a problem during the signup. A user beingstuck led to one of two actions; either contacting Visiarc or a third party fortechnical advice or giving up. Many chose the latter. This problem causedVisiarc missing out a substantial amount of customers. Therefore, integratinga system for aiding the user during signup was vital. A suitable solution wasto integrate a series of HTML documents to act as an FAQ. Having a FAQaccessible to the users at all times would provide an appropriate aid to the userduring the signup. The idea was that they should be able to browse the FAQeither when they were faced with a problem or before the signup.

3.1.2 Developing a GUI with an aesthetic appeal and anappropriate look and feel

The current GUI for the signup for Android was a bland experience wherereally no work had gone into making it stand out and appeal to the user.The assignment included developing resources in the form of buttons, icons,annotations, color schemes and other features to give the GUI an appealingexpression.

3.1.3 Developing a prototype in Android

A prototype was to be developed targeting to solve the key issues of the existingprototype.

3.2. Challenges of email account setup 13

3.1.4 Implementing a prototype that was to be integratedinto the application

The final prototype presented to Visiarc was to be implemented into the appli-cation for the next release. This would involve coding in Java, XML, HTMLand CSS, and also incorporate implementing the front end interface to theMobile Documents servers.

3.2 Challenges of email account setup

One of the goals was to create a user friendly interface for setting up a MobileDocuments account. The biggest challenge was to provide the users with aneasy and understandable way to enter the correct email account information.This was a challenge due to the fact that the necessary settings consisted of asubstantial amount of information and that many of the required input settingscould be hard to understand and obtain by an inexperienced user. The signupwould have to be setup so that the users easily could understand what wasbeing asked of them, how the users could obtain the specific information andwhy this information was needed.

All email clients requires a certain amount of information to be able to connectto an email account and no application was found that solved this in an espe-cially user friendly way. The lack of existing solutions to the problem furthercomplicated the challenge. The fact that the setup was going to be shown on asmartphone with limited screen size made the challenge even harder. This dueto a limited area on which to display information plus the inability of usinghover tool-tips.

Mobile Documents is an email client that handles existing email accounts; how-ever, it does not provide the user with an email account. Therefore, a user isrequired to enter the correct information about the email account the userwants to be added to Mobile Documents. A factor that complicates the taskeven further is that the information required by Mobile Documents to be ableto connect varies between email accounts. The information differs dependingon the domain connected to the email account.

Visiarc had already implemented measurements to make the signup easier.This by creating pre-made templates with the email settings for a few of themost common email domains, e.g. Hotmail, Yahoo! and Gmail. With thetemplates they covered about 28% of their potential customer base2. Theproblem was that there was such a large amount of different email domains and

2Email marketing reports,http://www.email-marketing-reports.com/metrics/email-statistics.htm,retrieved: 2011-12-19

14 Chapter 3. Problem Description

it would not be possible to cover even half of them with prepared templates.Visiarc had thought about this problem and had implemented a feature thatautomatically generated an email template when a user completed the signupwith a previously unknown email domain. The settings from these templateswould then be automatically transferred to the signup form when a new useradded an email account with the same domain. However, a problem was thatthe settings in the auto generated templates were not necessarily correct. Thesettings in the email servers may have changed since last signup or there mayhave been some other issues with the information. In this case, the providedinformation could either give a hint to the users of of the settings that weredemanded or confuse the users due to the fact that the information providedwas faulty. The fact that the settings were automatically filled out to a usercould even cause a few problems. A user who was not sure about the settingscould just go through with the pre-set settings and then accidentally set up anemail account in Mobile Documents with incorrect settings.

3.3 Email account setup

When the user opens up Mobile Documents for the first time, they are asked toenter an email address that they want to connect to Mobile Documents. MobileDocuments then checks if the specific email address already has been added. Ifnot, the user is asked to create an account at Mobile Documents. This beginswith the user having to fill in the first and last name. Mobile Documents thenchecks if there is a template available for the specific email domain. It is fromthis point that the setup can differ between users. There are three possibleoutcomes depending on the type of email account and its domain:

– Case 1: Mobile Documents has a pre-made template and can use thesesettings.

– Case 2: Mobile Documents has knowledge of a previously successfulsignup and can automatically fill in these settings for the user.

– Case 3: Mobile Documents has no previous knowledge of the statedemail domain.

In case 1 the user is asked to provide the user name and the password for theemail account before proceeding. All additional information is already locatedin the prepared template.

In case 2 the user is redirected to the settings page of the for the email protocol,IMAP or Exchange, that was used on the last successful signup for the specificemail domain. All of the settings, except user name and password, are filled inautomatically but are still editable by the user.

3.3. Email account setup 15

In case 3 the user is redirected to a page where they have to select if the emailis using the IMAP or the Exchange protocol before proceeding to a page whereadditional settings are to be filled in.

The necessary settings differ depending on the protocol that is used by theemail account. The input required for the Exchange protocol is the email username, password, server url. There is also an optional input field for the domain.

There are two varieties of the IMAP protocol setups, an easy and an advancedsetup. The easy setup requires user name, password, IMAP server and theSMTP server. With the advanced setup, the user is able to specify securityprotocol and ports for both IMAP and SMTP. The user is also able to enter theuser name and password for the SMTP server if it should differ from the IMAPserver settings. The different security protocols are IMAP, IMAPS and IMAPwith STARTTLS for IMAP and SMTP, SMTPS and SMTP with STARTTLSfor SMTP.

Mobile Documents attempts to connect to the user’s email account when allthe necessary settings are filled in. If the connection is successful, all the foldersof the email account are shown in a tree structure in Mobile Documents. Theuser may then select which folders that are to be accessed through MobileDocuments. The user can also select if Mobile Documents should notify theuser when a certain folder receives an email.

The next step is for the user to confirm the selected folders which is representedin an additional view.

If the email account is using the IMAP protocol, the user will have to selecthow Mobile Documents should handle sent and deleted emails. The user canspecify if a copy of every sent email should be sent back to the user, if a copyof the email should be saved in a specific folder or if no action is to be takenafter the email is sent. The user is also supposed to select if an email that isdeleted should be deleted permanently or just moved to a specific folder. If theuser selects the folder option in any of these cases, a list view is shown of theavailable folders from which the user can choose.

The next step for the user is to provide a signature that will be added to all theemails sent through Mobile Documents. The signature is optional and if leftunaltered it would read “Email sent using Mobile Documents for Android”.

After the signature has been entered, the user is asked to enter a pin code. Thepin code is used as the password to log in to Mobile Documents.

Chapter 4

Method

This chapter will describe how this master thesis project was conducted. Themajority of the work was performed by the project group consisting of theauthors of this thesis. This project group acted independently of the remainingVisiarc staff with regular reconciliations with the client.

4.1 Pre-study

The pre-study involved planning of the upcoming work. Identifying the taskat hand and selecting appropriate tools for how to solve it.

4.1.1 HTA (Hierarchical Task Analysis)

When using the HTA (Hierarchical Task Analysis) technique, the main taskis divided into subtasks where each subtask, or operation, is specified by agoal. Also identifying the conditions under which the goal is activated, whichactions are required to attain the goal, and later the feedback indicating goalattainment [15]. See Figure 4.1 and Appendix A.

Using this technique, the majority of all subtasks involved could be identifiedin designing and developing the signup process. A number of tasks and depen-dencies were identified which initially, before using the HTA technique, werenot thought of. However, during the task it was discovered that the authorsdid not have a substantial in-depth understanding of the flow of the signup andall its parts which led to deeper testing of the existing product.

Another benefit is that when forming smaller subgoals in an iterative designprocess one can make the iteration cycles in the process go by faster and thereby

16

4.1. Pre-study 17

perform more iterations, which theoretically should result in a more optimalsolution.

Getting a perspective of all parts, how they correlate with each other and whichwere dependant on which, allowed us to establish a Gantt chart1

At this point there was a need to adjust and prioritize the included parts ofthe project. It was decided in collusion with our adviser Henrik to focus onthe Android application rather than the web signup process since that was ofmost interest to Visiarc.

Figure 4.1: Hierarchical Task Analysis (See appendix A for a larger version)

1Microsoft, http://msdn.microsoft.com/en-us/architecture/aa699384.aspx,retrieved: 2012-02-13

18 Chapter 4. Method

4.1.2 Iterative design process

During implementation and design a cyclic iterative design process was fol-lowed. See Figure 4.2.

The prototype was the constant target for testing, analyzing and refinement.Daily, the ongoing progress was discussed with the management of Visiarc, newdiscoveries led to tweaking the direction of the development as it was goingon. There was little documentation being done since adjustments discussed inthe morning were implemented the same afternoon, the development was agilewhich worked very well for the purpose of this project.

The iterative process consisted of these steps:

– Planning work and requirements: Based on the feedback from theprevious cycle, new requirements were formed along with planning forexecuting and implementing them.

– Analysis, design and implementation: The new requirements werebroken down to sub-tasks. A solution was designed for each task andimplemented into the product.

– Testing: After and during implementation, the new features underwentthorough testing to ensure that they met their requirements.

– Verdict: At the end of a cycle the prototype was evaluated in its currentstate by a test group where they decided whether the prototype met therequirements or not.

Figure 4.2: A model of the iterative design process

4.1.3 Agile Software Development

Agile software methods focus on simplicity and speed [31]. The goal is tohave an iterative process where the developers focus only on completing the

4.1. Pre-study 19

functionality needed first at hand. By completing the functions quickly, thedevelopers are able to receive feedback and react to the information. Theprocess caters a continuous communication flow between the developers andthe customer which benefits them all. The customer quickly gets businessvalue and a good overview of the progress, and is at the same time able toprovide continuous feedback. The developers are able to react to the feedbackand adapt to certain changes in the original plan. This reduces the risk of doingunnecessary work and/or the risk of not being able to fulfill the contract.

The fast iterations increase the adaptability if the requirements are changedand also enable the possibility of testing in an early stage. Daily face-to-facemeetings between the developers are also minimizing the need for extensivedocumentation and ensures that all are well informed of the current progress.

4.1.4 Technical tools

The following major technical tools were used:

– Eclipse Classic 3.7 - A multi-language IDE platform for implementingand compiling mainly Java code and for building projects using thirdparty plug-ins.

– Google Docs - Collaborative word editor for documenting and sharingamongst parties.

– Apache Tomcat - Servlet application for running a local virtual server.

4.1.5 Creative tools

Major creative tools used throughout the project are:

– Adobe Photoshop Creative Suite IV - Powerful graphical tool fordeveloping mockups and resources.

– Adobe Illustrator Creative Suite IV - Vector based graphical toolfor developing resources.

– Draw 9-patch tool - A graphical tool to specify a 9-patch behaviourof a image resource, meaning that it can stretch and compress withoutcompromising detail.

– SmartDraw - Tool for developing project documentation illustrations,in our case the Gantt schedule and the HTA-map.

Chapter 5

Utilization of CloudComputing in MobileApplications

5.1 Introduction

Cloud computing in the context of desktop and laptop computing has been ahot topic for the last couple of years. Perhaps the most prevalent topic has beenGoogle’s open source operating system project called Chromium OS1. With thisthey aspire to transform the concept of home computers to a system run entirelyvia the web, using Cloud Computing. The cloud OS is a development going onalongside with other promising projects in the field of Cloud Computing.

This article will discuss the nature of Cloud Computing and how it is utilized.A variety of general questions regarding Cloud Computing will be discussed.Which applications are available on the market today and which projects arein the works? Which are the advantages and possible disadvantages of incorpo-rating Cloud Computing in general, and in mobile applications in particular?And what could possibly be expected in the future for this technique?

Questions such as these will be answered to a certain degree. One thing tokeep in mind however is how broad the subject of Cloud Computing is. CloudComputing can be shed in many different lights and viewed from a number ofperspectives, and the area in which to find applications for the technique ishuge. The article will address a number of key issues found when researchingthis subject.

1Chromium OS, http://www.chromium.org/chromium-os, retrieved: 2011-05-19

20

5.2. Background 21

5.2 Background

5.2.1 Origin of Cloud Computing

The concept of a computing style that is massively scalable and provided tothe user as a service through a network is not new. The idea of providingthe services over a network rather than being stationary stored locally on theuser’s computer dates back to the 1960’s when John McCarthy envisioned thepossibility that “someday computation may be organized as a public utility” [2].Since then the concept has evolved and been realized in a number of occasions,where web 2.0 might be the most prevalent to date [2].

In 1999, Salesforce.com introduced a concept for delivering enterprise applica-tions using the Internet with a project they called Software-as-a-Service (SaaS).A technique which later led to business applications developed by pioneeringcompanies, such as Google and Yahoo!. In the year 2000, Microsoft extendedthe SaaS by developing and introducing Web Services by allowing the SaaS toconnect to other software applications using the World Wide Web [26].

5.2.2 Understanding Cloud Computing

Cloud Computing is a technique that is constantly evolving as developers findnew ways of utilizing its features. The cornerstone in the technique howeveris to distribute applications and services using the Internet in new ways. Theword “cloud” in Cloud Computing is a metaphor for the Internet, a conceptwhich also has evolved alongside with Cloud Computing [6]. As the Internetinfrastructure has grown more accessible, stable, capable and cheaper it hasalso enabled new ways of thinking when developing Cloud Computing services.Services not imaginable ten years ago have become an everyday commonalty.In a network diagram the cloud represents “all that other stuff” behind therouter that makes it all work, as depicted in Figure 5.1.

The Internet is the “cloud” of applications and services that are available foraccess by subscribing. For a service to utilize the technique of Cloud Comput-ing the service must also utilize the Internet. The two are intertwined and ifseparated the concept is lost. Abstractly put, Cloud Computing is a construc-tion that allows one to, via a client, access and run applications that reside at alocation other than on the device one interact with or other Internet connecteddevices in the surroundings. Most often the application will be located at adistant data center [35].

This means that the applications one run through Cloud Computing are neverinstalled on the computer, the work produced is not stored on the computerunless one actively choose it to be. The concept can be presented in a fictionalbut reasonable scenario. The IT department of a business has in addition

22 Chapter 5. Utilization of Cloud Computing in Mobile Applications

Figure 5.1: The cloud is a popular metaphor when picturing the Internet in anetwork diagram.

to other tasks also the assignment to make sure that the employees of thatcompany have functioning workstations. The computers should run the sameprograms with the same updates, use the same service packs and develop usingthe same version of the framework etc. This can quickly become an expensivetask since the workstations constantly must be kept up to par with one an-other. Manually moving from computer to computer with installation disks inone hand and keeping track of licences written down on a note in the other.The task is usually both expensive in time and in money. Buying a range oflicences for the Adobe Creative Suite or the Microsoft Office Pack for a largeamount of work stations will have an impact on the company’s economy. Andin many cases some of the employees do not need to use some of the applica-tions more than every other month, if at all. This will ensure the revenue of theservice providers, but for the individual business it can become an expensiveand sometimes unnecessary expense.

In a scenario as the one described the business in question could benefit agreat deal by investing in Cloud Computing alternatives when considering thecosts in time and money. The application that the employees will be using ishosted by another company. It does not take notice of which type of systemit is running on, it handles every client the same. And the updates to theapplication are handled by the company where the application is located andusers will never bother with it. This means that one run the application viathe web browser or another client, logging on to their application by eithersubscribing to it or via a “pay as you go” program. Using arrangements suchas these can be customized to suit most businesses.

5.2. Background 23

5.2.3 Components in Cloud Computing

The Cloud Computing architecture consist of a set of individual parts comingtogether and interacting to form the technique. It involves the application thatdelivers the service over the Internet and the stationary hardware and systemsoftware that provides the service.

Stakeholders and vendors have tried to divide these services into subclasses,such as Software as a Service (SaaS), Infrastructure as a Service (IaaS) andPlatform as a Service (PaaS), to try and describe or label their products. How-ever, the distinction between the low-level infrastructure and the high-levelplatform is usually hard to make, and in this chapter they will be regarded asequally leveled since they can easily be described in the same context [35].

The cloud in Cloud Computing is the data center hardware and software, form-ing the service and delivering it over the Internet. Clouds can be public cloudsthat usually are made available as a subscription to the general public. Theycan also be private clouds, which refers to internal data centers within busi-nesses or other organizations, not available to the general public but still largeenough to benefit from the advantages of Cloud Computing [18].

Clients

The concept of clients in the context of Cloud Computing is the same as for atraditional Local Area Network (LAN) regarding the hardware devices. Theyare what the users directly interact with to obtain a certain service, in a networkor in a cloud. They often come in the form of desktop computers and laptops,but can also be mobile devices such as Tablets, smartphones and PDA’s. Theclients themselves fall into three different categories:

– Thin: This type of client can either refer to a software program or anactual computer/computerized device that relies heavily on another com-puter to do most of its work. The client provides an interface for con-necting to a larger system where all the actual work is being done. In-formation presented on the client and changes made using the client areall connected to the system and nothing derives or is being changed onthe actual client2. At times, thin may be defined as simply not need-ing the software or operating system installed on the user machine. Ina sense, they can be described as interfaces for the service, a displaywith user interactive capabilities that forwards all actions to the distantservice. This allows all end users’ systems to be centrally managed andsoftware deployed on a central server location as opposed to installed on

2Thin Client, http://www.wisegeek.com/what-is-a-thin-client.htm,retrieved: 2011-05-23


each individual system3.

– Thick: A thick client is a networked computer with most resources avail-able locally, rather than distributed over a network. A thick client willprovide users with more features, graphics and choices making the ap-plications more customizable. A conventional personal computer (PC) isa thick client since it has its own hard drive, software applications anddata. It is a stand-alone system that can operate by itself3.

– Smart: Smart clients, sometimes called rich clients, are a new conceptin Cloud Computing. This solution is moving away from the traditionalclient/server architecture to a web based model. For example, a smartclient running a word processing application can interface with a remotedatabase over the Internet in order to collect data from the database tobe used in the word processing document. A step up from thin clients isthat they support offline work. The applications will work outside the webbrowser, which would not work without Internet connection, somethingthat enables them to work with data even in offline mode3.

Data Center

A data center is a collection of servers, often located in the same area, holdingthe application which the client is communicating with in a Cloud Computingsystem. The data center often holds precious information which has to be keptsafe and may not be compromised. This leads to high security and QoS in thehosting areas4.

A new trend in IT is virtualization of servers which enables an administratorof the server to invoke multiple virtual instances of the servers to be used. Thisallows for several virtual servers to run simultaneously on one physical server,which promotes a more easily scalable system [19].

Distributed Servers

A common solution for setting up servers for a Cloud Computing service is notto have all of them housed in the same physical area. Having them spread overa geographical area brings a few benefits. One of the more obvious advantageswith this setup is that it lowers the risk of damaging the service if an accidentwould occur where the servers are stored. In the event of fire, earthquake ortheft it is important to make sure that the service can be hosted at a differentlocation and is not rendered useless because of the event. The user however will

3Webpedia, http://www.webopedia.com/DidYouKnow/Hardware Software/2006/thin client applications.asp, retrieved: 2012-02-29

4Data Center, http://www.wisegeek.com/what-is-a-data-center.htm,retrieved: 2011-05-23

5.2. Background 25

not be able to make a distinction of a service based on servers standing rightnext to each other or if the servers are scattered over a large area, which turnsthis solution into a viable option since it will not have any negative impact onthe user experience.

Distributing the server system is very beneficial for the provider in terms ofsecurity but also practical when it comes to physical space. Being able to dis-tribute new servers into separate locations rather than storing them all togetherin the same safe room makes the planning for a location an easier task [35].

The distribution of servers enhance the connectivity to the users. Spreadingservers geographically will cover a wider area and thereby shortening the av-erage distance between a server and a user. Keeping the servers separate alsoenables switching to another server location if the network a server is connectedto is experiencing a lot of traffic.

5.2.4 Utilization of Cloud Computing today

The most common use of Cloud Computing today is with web-based emailproviders such as Gmail, Hotmail and Yahoo. Many additional services havederived out of these such as online virtual hard drives, calendars and collabo-rative work environments where Google so far has had a pioneer position5.

Among the applications utilizing the Cloud Computing technique today are:

– Dropbox (2007): A web based file hosting service that allows users toshare files and folders with others using file synchronization. Dropboxallows a user to create folders in the cloud that can be reached fromanywhere as long as there is access to the Internet. The service caneither be operated using a web interface by signing onto the service viathe web browser or by downloading a client to a computer/smartphonewhich creates a folder in the file browser that is a mirror of the cloudfolders6.

– Google Docs (2006/2007): This is Google’s office suite offered as anSaaS. Basically it is a text editor application operated via a web browserwhich allows users to compose documents that are in real time savedand stored in the cloud. Another feature that Google Docs has is thepossibility of collaborative writing. The owner of a Google Doc -documentcan invite other users to simultaneously write in the same document7.

5Cloud Computing, http://www.youtube.com/watch?v=gIjBrxbdSPY,retrieved: 2011-05-23

6Dropbox, https://www.dropbox.com/, retrieved: 2011-05-247Google, http://www.google.com/apps/intl/sv/business/docs.html,

retrieved: 2011-05-24


Its popularity amongst businesses is growing due to enhanced sharingcapabilities and accessibility8.

– Rack Space (1998): A cloud storage and backup solution, RackSpace’sservice includes cloud servers and files. For a fee, one can get unlimited,on-demand secure online storage, with access via the service’s file manageror API. One can also get Linux or Windows cloud servers set up9.

– Avyari (2009): This service has been described as Cloud Computing’sanswer to Photoshop10. This is a photo editor application that one canoperate via the web browser. It is a online vector editor that is free touse. However, the work produced in the free version is flattened whenexported it and a watermark is added. If one get the Pro version it canexport the work in layers and without the added watermark, for a fee of$24 a year11.

However, the full potential of Cloud Computing is yet to be seen. Today it ismainly focused on the idea of utility computing where companies are offeredto buy their computing needs, which usually involves computing power andstorage/backup space. In many ways it is along the lines of conventional utilityservices such as water and electricity. On the economic side of things companiesgenerally benefit greatly from these services as they are often offered as a “payas you go” IT model rather than a major capital investment up front model12.

But in excess of how the technique is utilized today it is still gaining ground.IT departments have lately been able to transform their traditional IT infras-tructure into private clouds with the recent availability of the Windows Azureplatform appliance. This platform allows the users to work in the cloud whilststill using Microsoft’s familiar Operating System, management tools and appli-cations. This would surely point towards the further mainstreaming of CloudComputing13.

The software as a service (SaaS) model is beginning to emerge as seen withapplications such as Aviary and Google Docs which are successful approachesto Cloud Computing. The applications can serve hundreds of thousands ofusers, who all only need an account for the application and a web browser,where hardware performance of the individual user’s computers are nearly in-significant [10].

8Top 5 Ways to Collaborate, http://sparxoo.com/2009/05/18/top-5-ways-to-collaborate/, retrieved: 2011-05-24

9Lakeshore Branding, http://www.lakeshorebranding.com/company/blog/best-cloud-computing-services-and-apps-for-small-business/, retrieved: 2011-05-25

10Aviary, http://www.aviary.com/, retrieved: 2011-05-2511Edugeekjournal, http://www.edugeekjournal.com/2009/09/17/

cant-afford-photoshop-look-to-cloud-computing/, retrieved: 2011-05-2512Cloud Times, http://cloudtimes.org/cloud-computing-and-smartphones/, re-

trieved: 2011-05-2513Cloud Times, http://cloudtimes.org/cloud-computing-and-smartphones/,

retrieved: 2011-05-25

5.2. Background 27

Cloud Computing in Mobile Devices Today

There are a variety of Cloud Computing applications available for mobile de-vices on the market today. And there seems to be a promising market for it.Even though mobile devices have evolved at an amazing rate the last coupleof years there are still a few drawbacks that they all so far have in common.With a portable device users are hindered by a limited amount of batterypower, screen size, hardware performance, ways to physically interact with thedevice, network bandwidth and roaming costs. Providing applications withCloud Computing capabilities is however a good way to bypass a number ofthese.

– Mobile Documents (2002): The email client for the Symbian andAndroid platforms that this thesis project deals with that users downloadand install on their device. However, every email opened and read viathe device is streamed rather than downloaded. What this means is thatthe device only needs to download what the user is currently observing,meaning that large files like images, videos and documents can be viewedinstantly without first downloading them to the device. This saves upbandwidth, storage and time14.

– jQuery Mobile (2010): A framework for developing rich web applica-tions for mobile devices. The framework is built upon the existing jQueryframework which has for a long time been a popular JavaScript libraryfor creating rich desktop web applications. In contrast to the originaljQuery it provides many features specifically designed for developing mo-bile applications. It provides a series of new custom events which utilizesthe wide range of interactive capabilities a touch screen offers, such astap, tap-and-hold, swipe and orientation change. In the spirit of CloudComputing it also uses progressive enhancement which ensures that theapp will work on practically any device web browser powered device15.

Corporations and government agencies are now just beginning to experimentwith the combination of smartphones and Cloud Computing. A good exampleof this is that the CEO of Serena Software Jeremy Burton, when he tookover the company in 2007, decided to totally revamp Serena’s computing. Hereplaced software running on the company’s computers with cloud serviceshosted by other companies. One example of this was switching from Microsoft’sOutlook email client to a cloud based service offered by Google. With anapplication from Salesforce.com running on his smartphone, he taps an icon onthe screen of his smartphone and can instantly view a dashboard showing itsfinancial performance plus up-to-the-minute reports on each of his executives’performance against goals he has set for them [1].

14Visiarc, http://www.visiarc.com, retrieved: 2011-03-3015jQuery mobile, http://www.elated.com/articles/

jquery-mobile-what-can-it-do-for-you/, retrieved: 2012-05-29


Figure 5.2: Illustration of the utilization of Cloud Computing in the businessworld.17

5.3 The usefulness of Cloud Computing in mo-bile applications

5.3.1 The Advantages of using Cloud Computing in mo-bile applications

From an economical perspective there are a number of benefits of Cloud Com-puting over conventional computing. Developing on a web-based platform is anarea that is very beneficial for vendors since it is a mainstream environment.There is an abundance of programmers and tools that can push for Cloud Com-puting development. And for the user of Cloud Computing applications thereare a variety of perks as well, such as working with applications that are con-stantly up to date via a monthly subscription rather than paying for a staticapplication that stays the way it is for its whole life span.

Using mobile cloud applications makes sharing of information and software eas-ier. The mobile device is something people always carry with them. Therefore,having cloud application based communities for the business makes keeping upwith the work flow and meeting deadlines a lot easier. And developing appli-cations in the cloud enables enhanced features and functionality that wouldnot be possible outside the cloud. This can be achieved by letting cumbersometasks and processes be distributed to be handled by more capable computersand hardware in the cloud rather than on the mobile device.

Both the development and the use of cloud applications are simplified since one

5.3. The usefulness of Cloud Computing in mobile applications 29

access the applications through a web browser rather than a mobile operatingsystem. And this would truly ease the load on the developer since having abig chunk of the market of mobile platforms today means that one need to beable to develop the application in Java, C#, Objective C, C++ among otherenvironments. Having all platforms run the application in the same versionwould save a lot of time and money.

This would also benefit the users since applications that nowadays are lockedto a single platform would with Cloud Computing be accessible by all mobileplatforms utilizing an Internet browser [4].

To summarize:

– Working in the cloud makes the sharing of information and software eas-ier. There is no longer any need for costly and complex hardware andsoftware purchases and maintenance as businesses turn to the cloud.

– Mobile applications run through the cloud can have enhanced featuresand functionality that is impossible outside the cloud.

– There is an ease of access and development since one access the applica-tions through a browser rather than a mobile operating system.

– It is cheaper for Cloud Computing vendors to build mobile cloud appli-cations because of the linear scalability in economics.

– One get a broader reach since applications in the cloud can be accessedthrough a web browser. Distributing the application to a large amountof users with different types of devices and can thereby be shared andaccessed by many smartphone users.

5.3.2 The Disadvantages of using Cloud Computing inmobile applications

Investigating the technique further does however identify some obvious flawswith using Cloud Computing in mobile applications. If the applications andfunctionality of the mobile device relies heavily on Cloud Computing then it willprove useless in areas with limited or no access to the Internet. One could arguethat if they find themselves out of reception with their mobile phone today itis in many regards worthless as well. However the majority of applications onthe mobile phone today are stored locally on the phone, such as media playersand games, which can still run without connectivity.

Another problem that presents itself is the security issue. In July 2009 therewas a security breach on Twitter. A hacker accessed a substantial amountof company data stored via the cloud on Google-Apps by hijacking a Twitteremployee’s official email account. Opinions were raised that this incident hadmore to do with weak passwords and password resets rather than a flaw in the


Google-Apps service. Nevertheless the incident drew attention to security andprivacy concerns related to Cloud Computing [4].

Indeed, an incident such as this raises questions. Does Cloud Computing, asit is offered today, provide adequate safeguards from intrusion? Where do onedraw the line of what type of information one can store in the cloud? Movingmedical and health-related records, and information on domestic and sexualassault and substance abuse to a cloud raises concerns over how such sensitivedata will be protected.

5.4 Discussion and Conclusion

Today the majority of mobile applications do most of the data storage andprocessing on the mobile devices themselves and not in the cloud. However,one may predict that in the future Cloud Computing technologies will evolveinto a mobile Cloud, with mobile specific infrastructure, cloud storage, securityand compliance and applications amongst other services. There are a numberof mobile applications in the field of Cloud Computing, such as Gmail, GoogleMaps and some other navigation apps. However, these still store a big portionof the application data on the local device themselves and not in the cloud.

One thing to consider however is that not everyone owns a smartphone. Aprognosis performed by ABI Research states that 25% of the mobile phones soldin 2013 will be classed as smartphones and the remaining 75% will be featurephones with less capabilities [17]. While it is true that the relative numberof smartphones will grow and feature phones will become more sophisticatedin time, lower end devices are not going away anytime soon. But, as featurephones are equipped with more sophisticated web browsers which potentiallycould be used to access cloud services, researchers predict that it is just theirvery existence that will help drive the cloud computing trend.

As mentioned the feature phone is more common than the smartphone. Andthere are also more web developers capable of developing mobile web applica-tions than there are developers for any other type of mobile device. It is factorslike these combined with the fact that also feature phones are becoming morecapable with smarter, faster and more versatile built-in web browsers that mostprobably will have an impact on the growth of mobile Cloud Computing.

Today many applications are tied to certain platforms. There are a number ofapplications delivered to the iPhone that Android users never get the chance touse, unless they switch platforms, and the same goes for the converse direction.The emergence of Cloud Computing applications has the potential to erase thisbarrier, and reaching a user base far larger than the total amount of smartphoneusers by also including the connectivity of feature phones.

5.4. Discussion and Conclusion 31

Another reason is the very distribution of applications. The mobile applicationsavailable today are tied to a carrier. A good example is the ordeal for developersto release their applications for iPhone on the App Store, where they now firsthave to jump through hoops to get the application approved by Apple. Eventswith applications being removed from App Store or disapproved in the firstplace would suggest that the business policies of Apple would dictate thatservices that compete with the core features of the device should be kept toa minimal. The same could be applied to Blackberry applications. But whendeveloping in Cloud Computing all credentials a potential user needs is a mobiledevice with Internet connectivity. No matter what platform it is delivered to,it can still be accessed18.

There is undoubtedly a future for mobile Cloud Computing. From the back-end developer to the end user it is a technique that is highly beneficial. Thequestion is rather to what extent the mobile Cloud could evolve. Arguing thatmobile Cloud Computing will totally dominate the application market and outrival the downloadable applications would probably not be true. Instead mobileapplications will exist in both formats. They will probably appear similarly asthey do today and the conventional user will not see much difference. However,there will be a difference, but more on the back-end of the services. Thedevelopment of applications that make a habit of storing data in the cloud andoffload processing power to be performed on a datacenter rather than on thedevice itself will produce services far more capable than what is available today.

The development has been seen rising on the corporate side with business-focused mobile applications for enhanced productivity. Improving collabora-tion, data sharing, multi tasking and scheduling, all which are key factors torun a successful business in today’s society. And when looking back this isusually how a new technique gains ground, incorporating itself, before goingout to the larger mass.

18Visage mobile, http://www.visagemobile.com/news/news/understanding-mobility-management-news/4890/smartphones-to-account-for-25-percent-of-mobile-phone-market-by-2013-says-abi-research/, retrieved: 2011-05-26

Chapter 6

Designing for small screens

6.1 Introduction

The Mobile Internet is growing rapidly and the smartphones are taking overthe cell phone market [18]. Most of the new cell phones available at the markettoday are classified as smartphones. Smartphones are more than a cell phone,they are more like small handheld computers on which people can surf the web,play games, watch videos etc. The benefits of the smartphones are great andthey can help people meet their needs with instant access to electronic infor-mation and communication. With the cell phones becoming mobile Internetdevices, problems appear regarding the smartphone user interaction. Theseproblems mainly occur due to the fact that many websites on the Internet aredesigned to be shown on computer screens, with both higher resolution andlarger screen size than a screen on the common smartphone. The intendedwebsite design and user interaction runs a risk of being lost when displayed ona smaller smartphone screen. The big question is how to design the smartphoneadapted website and show large amounts of information on small screens?

6.2 Background

A recent study has shown that there are difficulties with performing tasks andfinding information on websites when displayed on a smartphone instead of acomputer [27]. The study has been conducted twice with two years in betweenand showed the same result both times. The success rate in performing taskson a web page and extracting information from a webpage is much higher whenperformed on a computer compared to a smartphone. In the second study, 105persons were observed while performing 390 different tasks on a smartphone

32

6.3. Design 33

and a computer. The overall success rate was 62% on a smartphone and 84%on a computer. Tasks performed on a regular website, adapted for a largercomputer screen, resulted in a task success rate of 58% when displayed on asmartphone, whilst tasks performed on “mobile” sites, designed especially forbeing displayed on smaller screens, resulted in a task success rate of 64%. Tasksperformed on a mobile app had a task success rate of 76%.

In the previous study [9] the overall success rate was 59% on a smartphoneand 80% on a computer. This tells us that even though the smartphoneshave become more common and advanced, the task success ratio comparedto a computer is almost the same. It shows that it is not necessarily thesmartphones themselves causing the low success ratio, but rather the actualcontent displayed on a smartphone.

The study showed that the success rate was significantly better when the userswhere to extract information from a smartphone application rather than froma web site displayed on a smartphone. One may wonder what it is that makesa smartphone application that much better in providing information on a smallscreen.

A smartphone application is designed to be both displayed and used on asmartphone. The content is designed to be read on a small screen and theinput is generally expected to come from touch input and/or a small keypad.A website is mainly designed to be shown on a larger computer screen anda “mobile” website is often just a stripped down regular website where thedesigners have kept the overall layout.

6.3 Design

When designing for small screens, it is important to think about the completelayout and not only the content. A design that is very attractive, intuitiveand easy to use on a large computer screen can be the complete oppositewhen displayed on a small screen. However, there is a risk of the user gettingfrustrated and disoriented if the information, look, design and layout differstoo much between the regular web page and the mobile web page [24].

Limitations in the human short-term memory is one factor that can lower thesuccess rate on a small screen versus a large screen [5]. The human short-termmemory is only able to hold seven items at once [12] and on top of that theitems are only remembered for about 20 seconds. Albers and Kim [5] describean item as a coherent chunk of information. They say that the size of thechunks of information the user is able to remember is distinguishing a systemexpert from a novice. The smaller screen size results in a lower amount ofvisible information displayed at once compared to a larger screen size. A userhas to scroll the page, zoom or jump between several different pages to be

34 Chapter 6. Designing for small screens

able to receive the same amount of information as displayed on a larger screen.This results in the user having to remember the chunks of information for alonger period of time while navigating on a smaller screen. The navigationitself also takes up cognitive resources which puts extra pressure on the shortterm memory.

An overload of the short-term memory may result in the user forgetting in-formation which has to be looked up again. Possible user frustration is alsousing up the user’s cognitive resources and a cognitive overload is increasingthe amount of errors on the user’s side [5].

6.3.1 Layout

One major guideline when designing for small screens is to reduce the amountof information, only show what is necessary and keep the information focused[18, 22]. When designing a mobile web page out of a regular web page, oneshould really reconsider every item/piece of information on the page and be ableto motivate why it should be shown on the mobile web page. This approachwill keep both the amount of required scrolling/navigation and amount of datato download at a minimum.

Keep the design as minimalistic as possible [18]. A design should be kept simple,have a lot of white space to distinguish and separate the information, andimages should be avoided. Images should only be included if they contributeto the content [9]. They often require a relatively large amount of space on thescreen to be visible and meaningful. In addition, images increase the amountof data that must be downloaded to the device.

Another thing to keep in mind is that the users could use devices with dif-ferent screen size, resolution and physical buttons [18]. The design should bethoroughly tested to guarantee that it is usable on all kinds of screens.

By keeping the design attractive and easy to understand it will contribute toits usability [22]. Users tend to be more forgiving and have better patiencewith a design they find attractive.

Web pages displayed on a smartphone are often automatically zoomed out to fitthe width of the screen. If the content is very wide compared to the screen, thiscreates a great risk that the web page is unreadable at first sight which forcesthe user to zoom in. Zooming requires extra user input and also forces the userto scroll horizontally as well as vertically to get a full view of the content [22].The designer should aim for a single column layout with the content expandingvertically which minimizes the need of zooming and horizontal scrolling.

6.3. Design 35

6.3.2 Know the target group

A very important task when designing for small screens is to get to know thetarget group [18]. The designers should ask themselves a few questions, e.g.what are the needs of the users, why are they looking at the small screen andunder which circumstances? By answering questions like these, it is easier todecide about how to make the design, e.g. if the buttons and/or text shouldbe extra large even though this decreases the amount of visible information.

6.3.3 Prioritize the content

Due to the limited screen size it is important to prioritize and categorize thecontent and features that are going to be displayed. The developers should askthemselves why the specific content should be displayed and how important itis to the user. The content that ends up in the highest priority group shouldhave the main focus and be displayed high in the page hierarchy [22, 21]. Thecontent with the lowest priority should be seriously considered to be removed.

It is important to keep focus on one type of content on a single page to avoidthe user from getting overwhelmed by too much information. The categoriescould be helpful in deciding on how to divide the content between pages. Eventhough there are several types of information, it is important to focus on asingle type of content on a page instead of having all of the highest prioritizedcontent displayed. It could be better to have several different pages with dif-ferent categories on every page rather than keeping all of the categories mixedon a few pages. Keeping information in categories will minimize the risk of theuser forgetting important information while comparing different pieces of infor-mation. If users need to perform high amounts of navigation between differentpieces of information that is to be compared, e.g. two different products, thereis a great risk of the user forgetting the information along the way [5].

6.3.4 Fulfill the users expectations

Users have their own expectations and knowledge when interpreting informa-tion [5]. They have an active mental model through which they will inter-pret the presented information. Therefore it is crucial to make sure that themental model corresponds to the information/design. The mental model isestablished at the very start, when the user is initially presented with the in-formation/design and it is at that point that the user’s expectations must bemet. E.g., a bad first impression could cause the user to interpret informationas unserious and untrustworthy, even though it is not. This is why the firstappearance is crucial and it is important to have a design that corresponds tothe information that is presented.


6.3.5 Colors

Color-coded objects are very useful when tying together differently positionedobjects [36]. Colored objects on a monochrome background are noticed quicklyand easily by the user and a connection is likely created between objects withthe same color. However, colors should be used carefully. Irrelevant colors cancause distraction and more than five to six different colors present in a singledisplay can cause misinterpretation. It is also important to not fully rely oncolor coding. Users can be colorblind and/or have different associations withthe colors which can negate the designer’s intention with a specific color.

6.3.6 Text

Sanchez and Goolsbee [34] conducted a study where they explored how differenttext characteristics affected the readers ability to remember a text. They foundout that the one thing that had the largest negative impact on the readers waswhen they had to scroll to be able to read the full text. A text should be visibleon a single screen if possible and one should strive to avoid long contiguouspieces of text. Texts should be informative and preferably written in shortsentences or at least divided into shorter sections [9, 5].

6.3.7 Navigation

Small screens require good navigation possibilities. The limited screen sizedecreases the amount of information that can be displayed on a single screen.Therefore, the user must be able to navigate the information in an easy andintuitive way, without getting lost [18]. There should be some kind of visualindicator of the user’s current location/progress in the navigation structure.

There are several ways to navigate on a graphical user interface (GUI), e.g.using buttons, scrolling, hyperlinks and zooming.

One general guideline is to make the navigation as easily recognizable as pos-sible [18]. The navigation should be consistent in functionality, layout andpositioning. E.g. one kind of swiping gesture should not result in differentactions depending on the area or page [9], and a navigation area should alwaysbe found in the same location in the layout. If it is possible and if the contentis taking up more space than the height of the screen, a navigation area shouldbe placed both at the top and at the end of the page. A fixed navigation areathat follows the content, a so called “sticky header”, could be a good solutionbut is at the same time constantly taking up valuable screen real estate. It isalso very important that the navigation is working correctly. Poor navigationpossibilities, e.g. broken hyperlinks, may frustrate the user [22]. The limitedscreen size results in more scrolling and clicks [5] compared to that of a larger

6.3. Design 37

screen. The high amount of clicks make users more reluctant to press a button,hence it is important that the users know about the resulting action of clickinga certain button. An explanatory text on a button is one way to provide thiskind of information. The navigation is extremely important on a small screendevice and its performance strongly affects the user experience.

Another important thing to keep in mind is that a touch screen has no hoverfunctionality or a pointer. This further increases the difficulty in performingprecise navigation actions.

Scrolling and zooming

Scrolling is a common and well-known function when browsing through infor-mation. However, the user should only need to scroll in a vertical direction[9, 22]. The width of the layout should not exceed the width of the screenand the size on the layout should be large enough for the user to acquire in-formation and navigate without zooming. When a user zooms in on a page,horizontal scrolling is added. Therefore, zooming should not be required, butrather an option. Horizontal scrolling adds another dimension to a page andincreases the risk of the user getting lost and/or having difficulties in locatingthe desired information.

There should also be some kind of indication of the current scrolling positionto provide the user with an overview of the amount of content on the page.

Buttons

A small screen makes it hard for a user to perform high precision clicks. Toreduce the risk of a user pressing the wrong button or accidentally pressing abutton, a click surface should be at least 1cm2 and have a generous amount ofspace surrounding it [9]. The button design in a layout should depend on theimportance of the buttons and the circumstances under which a user is pressingthe buttons. Buttons with high importance and greater consequences shouldbe displayed in a position and size that prevents the user from accidentallyclicking them or accidentally not clicking them. If a user is expected to bee.g. walking outdoors whilst pressing the buttons, high precision clicks becomeeven more difficult. Thus, in this case the buttons should be made even largerto avoid accidental clicks.

6.3.8 User input

Typing can be a time consuming and challenging task on a touch screen ora smartphone with a reduced keyboard. It can be hard to hit the correctkey on the relatively small keyboard and some characters can only be entered


by pressing keys several times [9, 22]. Required text entry should be keptto a minimum and when input fields are necessary, default values should beprovided [18]. The default values can often be computed from prior text inputand reduce the total amount of required input. However, default values shouldonly be presented if it is possible to automatically calculate them. Otherwisethere is a great risk that the user will have to clear the text field before beingable to enter the correct information.

If an error occurs with the entered input, it is important to provide informationabout what went wrong. The information about the error should be easy tounderstand and the error should be easy to locate. The concerned field(s)should be clearly marked and focused to make it easy for the user to correctthe error [9].

6.4 Conclusion

When designing for small screens it is very important to have a well thoughtthrough design. The user’s ability to receive large amounts of informationand enter input is greatly reduced compared to a large screen with a full sizekeyboard. The design should be easy to understand and navigate, and the usershould be able to read and interact with the content without having to zoom. Itis also important to fulfill the users’ expectations and provide the informationand functions that they expect. To be able to fulfill the expectations, thedesigner should be aware of why the users are using the application and underwhich circumstances.

A small screen increases the need for good navigation possibilities. It plays animportant role on how an application is perceived and has a crucial impact onthe user’s ability to receive and remember the information in the application.

If an existing web page is to be converted into a mobile web page, it is betterto design the mobile web page completely as a new web page adapted forsmartphones, and not only adapt the regular page to fit a smaller screen. Thegathered information has shown that it is important to make the users perceivethat the mobile web page is a standalone page and not just a dumbed downcopy. By doing this, developers can minimize the risk of disappointing theusers when the design and functionality on the page is not the same as on theregular page. If the users perceive the mobile web page as a dumbed downversion of the regular page, in functionality, design and information, there is agreat risk of disappointing them.

Chapter 7

Design

This chapter will describe the design process and the different design propos-als that were created both for the Android application and the desktop webclient. The chapter will also cover theoretical aspects that were taken intoaccount regarding usability guidelines and heuristics when developing for theend consumer software market. The guidelines and heuristics are discussed inthe context of mobile application development.

7.1 Theoretical foundation

Due to limited experience with developing GUIs for mobile devices a thoroughresearch of the subject was necessary, obtaining guidelines and best practicesfor developing user interfaces in this field. There were issues regarding struc-ture, feedback, look and feel, constraints and metaphors for the entire signupworkflow which also needed to be addressed.

As a designer one want to work with projects which have a well formulatedspecification with clear goals and design limitations rather than a task withno boundaries where all decisions have to be made by the designer. However,focusing too much on the limitations and the specification may have a badinfluence on the overall creativity and the final product. Following up ideasthat at first seem far fetched may turn out to be a groundbreaking feature forthe product that is designed1. Balancing these two factors is a key issue for asuccessful design process.

1Al-Ruh, http://www.al-ruh.org/page2.html, retrieved: 2011-08-11

39

40 Chapter 7. Design

7.2 Schneidermans Eight Golden Rules

In 1987 Ben Schneiderman released the work Design the User Interface fromwhich eight rules or principles regarding user interface design were formed. Therules are derived from experience of his research of human-computer interactionand are applicable after being properly refined, extended and interpreted forthe task at hand. The rules he stated are as follows [7]:

– Strive for consistency. The designer should strive for handling userinteraction consistently throughout the system. In situations similar toeach other the same sequence of actions should be expected. Identicalterminology and consistent commands should be used in menus, prompts,notifications and help screens all throughout the interface.

– Enable frequent users to use shortcuts. With frequent use and asthe user familiarizes with the system, the desire to reduce the numberof input actions and increase the pace of interaction and efficiency be-comes more important. Adding hotkeys, shortcuts, the ability to disableprompts and notifications, hidden commands and macro facilities willgreatly improve the interactive capabilities for the expert user.

– Offer informative feedback. The system should provide feedback tothe user for each operator action performed. The significance of theoperation should be taken into account when displaying the feedback,letting minor actions give modest feedback while infrequent or substantialactions should provide more noticeable feedback.

– Design dialog to yield closure. To encourage the user whilst operatingthe system all sequences of actions should be organized into groups witha clear beginning, middle and end. Giving clear feedback to the userwhen a set of actions has been completed gives the sense of satisfactionand accomplishment. This improves the overall feel of the product plusit allows the user to operate more efficiently since it encourages to dropalready performed tasks and focus on upcoming planned tasks.

– Offer simple error handling. To the farthest extent possible try anddevelop the system so that the user cannot make a serious error. If anerror is made, the system should have exceptions prepared to handle thesituation and thereby avoid a system crash. Using rollback technologiesand transaction handlers to avoid corrupt and incompatible data in thedatabase.

– Permit easy reversal of actions. If the users feel that they easilymay ruin their work while using an application, it may be because theapplication has no usable feature for reversal of actions. This will hinderthe users when interacting with the application since they will be tooanxious to explore the features of the application in fear of ruining their

7.3. The Interface Guidelines Applied to Developing for Mobile Devices 41

work. The reversibility may be limited to a single action but should offerthe possibility to reverse a series of actions. However this will increasethe complexity of the implementation.

– Support internal locus of control. All users of the application hasa strong desire to feel as they are in control of the system and that itimmediately responds to their actions. The system should be designedto make the users feel like they are the initiators of actions rather thanreceivers.

– Reduce short-term memory load. Keeping displays simple, multi-ple page displays consolidated, window-motion frequency reduced, andsufficient training time allotted for codes, mnemonics and sequences ofactions are ways of avoiding this. Keeping this rule in mind will also helpwith adjusting the application to the limitations of human informationprocessing in their short-term memory.

7.3 The Interface Guidelines Applied to Devel-oping for Mobile Devices

As the rules are phrased in a desktop or terminal context, some of them maybe a bit hard to translate for use in a mobile context. However, half of themcan be applied as design guidelines without explicit change when developingfor mobile devices.

– 7.3.1 Enable frequent users to use shortcuts

Time is more often than not a critical factor to the user when operatinga mobile device [30]. The user may be on the subway, waiting in lineor in between classes, and reducing the number of operations needed toperform regular tasks is a key factor in the ease of use of mobile devices.If an application requires extensive amounts of time invested from theuser to complete simple tasks then the user most likely will avoid usingthe application, this applies to the mobile domain especially.

– 7.3.2 Offer informative feedback

The feedback provided from the system to the user should be informativeand not hidden behind an incomprehensive error message. For examplethe “HTTP404 ERROR” and the “THE PAGE CAN NOT BE FOUND”messages may be equivalent, but having an informative message such asthe latter one will most likely be of more benefit to most users.


– 7.3.3 Design dialogs to yield closure

Providing feedback of progress is a good thing when developing for bothdesktop and mobile devices. This in order to give the users the sat-isfaction of accomplishment when an action or operation is completed.However, the dialogs and notifications should overall be subtle and keptin periphery rather than occupying all attention from the user, e.g. as adialog which requires user interaction.

– 7.3.4 Support internal locus of control

As with the previous rule this is also applicable to mobile devices as theuser wants to be the initiator of actions rather than responding to actionsfrom the system.

The remaining four guidelines need some adjusting to be applicable to mobiledevice development. Concerning the consistency one may have to broaden thatstatement when it comes to mobile devices. For instance a user may want to beable to sync the mobile device with their laptop or desktop computer frequently.One scenario is that they may be working with documents on their computer,transfer the documents to a mobile device to revise them while on the subwayand then call to ask colleagues about the work later. In a situation as this, theconsistency must be maintained between the computer and the mobile device.To maintain a high consistency in mobile device and desktop syncing one needstable I/O environments that are device independent.

The golden rules also state the benefits of having a feature for reversal of ac-tions. However with many mobile devices, especially with feature phones, thereis a lack of available resources and computing power [23]. The memory to storethe states of previous events is minimal and would become impossible for richerapplications. Having the application offload the information to more powerfulstationary computers will only work when within the range of a wireless ormobile network and even then the application would be vulnerable to wirelessconnectivity loss and thereby losing the tracking of past events.

The error prevention and simple error handling need to take the design ofmobile devices into account. Small screens and limited means of interactionmakes browsing for information when faced with an error very tedious.

When designing to reduce user short-term memory load with mobile devices,the developer need to take into account that the user potentially have to dealwith more distractions than the regular desktop user [28]. The user may beexposed to surrounding noises, abrupt shifts of focus away from the application,or a narrow time frame [13, 14, 20]. Letting the user interact with the mobile

7.4. Requirements 43

device using a voice recognition feature in the application may be very beneficial[30] but should never be the only means of interaction.

7.4 Requirements

Establishing the goals for the project was one of the initial steps in the designprocess, as described in the problem description. The goals would still have tobe met under a certain amount of requirements. There were a range of specificrules set by the client that the finished product would have to satisfy. Therules were mainly stated out of the requirement to make the signup suitablefor a wide range of Android devices.

– Range in screen size. Actual physical size, measured as the screen’sdiagonal. For simplicity, Android groups all actual screen sizes into fourapproximate sizes: small, normal, large, and extra large, see Figure 7.1for a chart of the screen sizes2. The application had to be usable from thesmallest to the largest screens, ranging from the Sony Ericsson X10 Miniwith a 2.55” screen3 to the Samsung Galaxy Tab with a 10.1” screen4.To achieve usability the layout of information had to be planned withthese differences in mind.

Figure 7.1: Chart depicting the variation in Android device screen sizes.

– Range in screen density. The quantity of pixels within a physical areaof the screen; usually referred to as dpi (dots per inch). For example,a “low” density screen has fewer pixels within a given physical area,compared to a “normal” or “high” density screen, see Figure 7.2 for achart of the screen sizes. Android groups all actual screen densities intofour generalized densities: low, medium, high, and extra high5.

This meant that every resource developed had to be available for a se-lected range of densities. In the case of the signup the resources were

2Android Developers, http://developer.android.com/guide/practices/screens support.html, retrieved: 2011-08-29

3Xperia x10 Mini, http://www.sonyericsson.com/cws/corporate/products/phoneportfolio/specification/xperiax10mini, retrieved: 2011-08-29

4Samsung, http://www.samsung.com/global/microsite/galaxytab/10.1/spec.html, retrieved: 2011-08-29

5Android Developers, http://developer.android.com/guide/practices/screens support.html, retrieved: 2011-08-29


available for a low, medium and high screen density. If this point is dis-regarded, resources in the form of images would fit badly in the range ofdevice screens. Devices with low density screens would display the imagesas large on the screen and high density screens would display the sameimage as much smaller, causing a layout inconsistency between devices.

Figure 7.2: Chart depicting the variation in Android device screen pixel density.

– Landscape. Every view of the signup had to be displayable in devicelandscape mode, which is when the user tilts the screen 90 degrees. Thehorizontal/vertical screen ratio in the landscape mode often differs fromthe default portrait mode. See Figure 7.3. Image resources would have tobe ready for this either by being in a 9-patch format or by continuouslybeing re-drawn to fill in the blank spaces.

Figure 7.3: The application had to be able to adjust whether the screen was inportrait or landscape mode.

– Native. The signup would make use of the native resources in forms of

7.5. Mockups 45

buttons and the normal Android font Droid Sans6. See Figure 7.4.

Figure 7.4: The Android Sans font.

7.5 Mockups

The early stage proposals were presented as mockups and lo-fi prototypes de-veloped in Adobe Photoshop CS4 and Adobe Illustrator CS4. They proved agood use to quickly show graphical proposals regarding the design. Because oftheir primitive nature (non-interactive PNG images) they could be developedquickly and in different variations if needed. Having a range of proposals thatcould be quickly developed to discuss amongst the group and the client helpedto reach decisions faster.

The mockups were based on the workflow of the previous signup process, ba-sically re-designing the layout of the views, how information was presented,additions of icons and other features.

6Droidfonts, http://www.droidfonts.com/droidfonts/, retrieved: 2012-04-25


7.6 Progress bar

The previous version of the signup did not give the users any feedback of wherethey were in the signup process. The users had no way of telling how farthey had gone or how many steps remained. It was concluded that this wasin violation to rule three and four (“Offer informative feedback” and “Designdialog to yield closure”) of Shneiderman’s eight golden rules [7]. In addition tothis, research has shown that with the absence of a progress bar, the perceptionof how long a process takes to complete is lengthened. This means that withoutprogress bars or some other indicators the application will feel slower to theusers [3]. In order to eliminate this flaw, a progress bar was designed for thesignup, depicted in Figure 7.5. A variety of progress bars were developed andpresented to Visiarc.

Figure 7.5: Progress bar as presented to Visiarc.

The proposal as a concept was appreciated by Visiarc, but an issue on their be-half was raised as to where a progress bar could fit into the application withoutdisturbing the layout too much. As discussed earlier, straining the layout of amobile application by adding widgets and components to the view may resultin more disturbance rather than gain in usability because of compromising thescreen view. To avoid this, a proposal was developed integrating the progressbar in the already existing header. See Figure 7.6.

Another concern with the progress bar was that the number of steps in a signupcould differ between users and their settings. To get around this issue, it wasdecided to create a dynamic progress bar that displayed the progress percentageof the current signup, rather than having one static instance of the progressbar inserted into each step of the signup.

7.7. Folder list 47

Figure 7.6: Progress bar integrated into the existing header.

7.7 Folder list

During the signup the users are presented with the option to select whichfolders in their email account they want to reach through Mobile Documents.By selecting a folder the users are able to read and edit the emails containedin that folder. The users may also choose to get a notification by MobileDocuments when they receive an email in a specific folder. One of the majordesign issues that was faced during the development of the signup was how todisplay the different folders to the users. There were several problems that hadto be solved to create an easily understandable and manageable folder list. Theproblems that was faced were:

– It was not certain how many folders were to be presented. In theory, itcould be anything from one to several thousands.

– There was no way of telling how many levels of subfolders were to bepresented. This could vary between no subfolder to one different level ofsubfolders for every parent folder.

– The name of the folder and the number of emails in every folder was tobe displayed to the user, if it was available.

– The user should be able to choose if the folder should be accessed throughMobile Documents and if the user was to be notified if the folder receivedan email. The options should be easy to toggle for each specific folder.The selected option(s) should also be clearly visible to the user.

– The user should be able to toggle the folder options for several folders atonce, which is especially important if there are a lot of folders.

– The complete folder list with its settings would be displayed on a smallscreen.

Chapter 8

Results

This section will cover the results of the project. It will cover the finished signupproduct of the Android platform and the mockup for the desktop version.

Screenshots are depicted with contextual explanation. All parts of the signupwill be presented as well as concerns regarding design choices will be discussedwhere applicable.

Since the existing signup was implemented in Google Web Toolkit (GWT) therewas not much that could be reused in the new implementation.

8.1 Android signup

As mentioned in the problem description there was an existing signup for theapplication that could handle a customer signup. The work was mostly aboutredesigning the signup and making it appeal more to the user. There is aclient part and a server part in the system where the server side manages allcommunication to the users email servers and the users manage their emailaccounts with the Visiarc servers, using the mobile client as an interface.

The main goal of the project was to enhance the usability and user experienceof the signup for the Android version of Visiarcs product Mobile Documents.An existing android version of Mobile Documents was already in place at thestart of our work but the signup was not built in native Android and hadsome issues that had to be dealt with. The major issue was the graphical userinterface and how the signup was presented to the user. The existing signupwas very basic with input fields and short lines of text that vaguely explainedto the user what kind of information that was requested. The feedback to theuser was minimal and the users were expected to find out for themselves how

48

8.1. Android signup 49

to obtain the information that was asked for. Since Visiarc had noticed thatmany users failed during the signup they wanted to increase the signup successrate.

The fact that there already existed a functioning signup in the application gaveus a head start with the development of the new signup. It was known fromthe start what kind of information Mobile Documents required from the userin order to complete a signup and connect to an email account. Most of thebackend including web services and database connections was accessible to us.This gave us the possibility to focus on the graphical user interface and how toguide the user through the signup.

8.1.1 The navigation area

It was decided to give the users an easily understandable and consistent way tonavigate the signup by creating a navigation area which was to be presented onevery page. In the previous signup the navigation area was located as the lastitem of the content of a page. This meant that the area would shift positionbetween pages depending on the size of the page content. To steer away fromthis and provide the user with a consistent placement of the navigation areait was decided to have it statically placed at the bottom of the page, notdependant on whether the content filled up the page or not. For content thatexceeded the screen height the navigation area would be located off screenbeneath the content. The navigation area was intended to provide the userswith options on how they could proceed; step forward to the next page, stepback to a previous page or cancel the entire signup, as seen in Figure 8.1.These buttons were also present on most of the pages in the old signup, thebig differences were the placement of the buttons, the new graphics and thatthey would occur on every page. The intention with the repositioning of thebuttons was to give a more intuitive feel of the buttons and their functions,with forward function to the right and backward function to the left.

Figure 8.1: The navigation area for the signup process.

The navigation area was given a background color to make it easy to recognizeand stand out from the rest of the page content. It was also decided to addsome shadows to give a feeling of that the area has been sunk down into thepage.

The background color throughout the signup was also changed from white tolight grey. This was done to reduce the contrast on the pages a bit and provide

50 Chapter 8. Results

a “softer” look of the application.

8.1.2 The header

One big issue with the signup was to find a way of providing information tothe users about the data that they were supposed to enter on the differentpages. As seen in Figure 8.2 it was decided to place an information button inthe header that was shown on every page which the users could press to getinformation about the current page and the expected input data.

Figure 8.2: The user could open the FAQ by tapping the “i” information buttonfrom anywhere in the signup process.

When the information button is pressed, a pop up window is displayed thatcontains an FAQ of the whole signup. See Figure 8.3. The FAQ contains afair amount of information and it was decided to try and minimize the need ofsearching throughout the FAQ. For this reason it was decided that the pop upwindow immediately will focus on the chapter that contains information aboutthe current page. However, the user is still able to access the complete FAQby scrolling the text and/or pressing hyperlinks.


Figure 8.3: The FAQ contained information that could aid the user who wasat a loss.

The header also contains a dynamic information window that provides infor-mation about the name of the page that is currently displayed or importantinput data such as the email address the user has entered. The bottom of theheader contains a progress bar that provides approximate information of theusers current progress in the signup.

8.1.3 Start page

Since the start page is the first thing that greets the user it is very important tohave a start page that gives a nice impression. It was decided to create a visuallyattractive start page that had good affordance and would not overwhelm theuser with information.

The start page, see Figure 8.5, contains a text field and a single button, exceptfor the information button in the header. The user is asked to enter the emailaddress that will be connected to Mobile Documents. When the user presses the“next” button, Mobile Documents checks if the email address already has beenregistered as an account in Mobile Documents. If Mobile Documents finds anexisting account the user is directed to a login page, otherwise a pop-up window,see Figure 8.6, is shown where the user is asked to confirm if the entered emailaddress is correct. The pop-up window also displays the logotype of the emailprovider if it is recognized by Mobile Documents. The user is redirected to the


first page of the signup after the entered email address has been confirmed inthe pop-up window.

There are several differences on the start page between the old and new signup,see Figures 8.4 and 8.5. One of them is that the “forgot password” button hasbeen removed. The button is instead visible on a new page if the user enters anemail address that is already connected to a Mobile Documents account andis requested to enter the password, see Figure 8.7. Another difference is theinformation button in the header which will provide information to the user ifneeded.

The pop-up window is a new feature and is used as a fail safe to avoid asituation where the user continues through the signup and later has to cancelit due to a “wrong” email address. In the previous signup there was an inlinevalidation for the input of email addresses that would trigger an error messagefor all input until a complete email address was put in. A user test with noviceusers showed that this was a very obstructive method since the interface toldthe user that they were entering a wrong email address before the address wasfully entered. It was decided to add a validation that was triggered as the userstepped forward, and at that point notified the user if the entered email addressdid not correspond to an email address format.

The actual connection between the email account and the Mobile Documentsaccount is set at the third step in the signup and if the email address is incorrectthe user will have to redo the previous steps.

Figure 8.4: The start page in the previous signup.


Figure 8.5: The start page in the new signup.

Figure 8.6: The pop-up window that is shown when an e-mail address has beenentered.


Figure 8.7: The login page in the new signup.

8.1.4 Name page

The first page when starting a new signup is a page where the user is askedto enter a first and last name. The entered name will later be connected tothe Mobile Documents account. The progress bar in the header is now alsodisplayed for the first time to give the user a hint of the amount of stepsremaining. An additional difference from the previous signup is that there isan information text added that describes what the entered names are for.

Compared to the previous signup, see Figure 8.8, the text fields in the newsignup has been redesigned both in look and feel. The input text has beenenlarged and there is a focus indicator added to the active field in the formof an orange border. As seen in Figure 8.9 the text field caption has movedinto the text field rather than on top of it, giving a more direct mapping of theinput description. The text disappears as the user enters any text into the textfield.


Figure 8.8: The “name page” in the previous signup.

Figure 8.9: The “name page” in the new signup.


8.1.5 Existing template page

If Mobile Documents recognizes the email domain and has an existing emailtemplate for the email setup, the user is redirected to a new page and asked toenter the email address and account password. Figure 8.10 shows the page fromthe previous signup and Figure 8.11 shows the remade page. A new featurewith the new signup is that mobile documents automatically recognizes theemail login from the entered email address and the user only has to enter theemail account password. An information text has been added to the top ofthe screen and the information button in the header can provide additionalinformation if needed.

Figure 8.10: The page in the previous signup where Mobile Documents recog-nizes the email domain and has an existing settings template.


Figure 8.11: The page in the new signup where Mobile Documents recognizesthe email domain and has an existing settings template.

8.1.6 IMAP/Exchange page

After the name has been entered, and if Mobile Documents is not able to recog-nize the settings for the entered email address, the user must select whether theemail server is using an Exchange protocol or IMAP/SMTP protocol. The useris redirected to a page with four buttons in addition to the ones in the naviga-tion area and the header. Two of the buttons redirect the user to the exchangesettings or IMAP/SMTP settings and each of them have an information buttonnext to it. All of the information buttons trigger a pop-up window with theFAQ. The difference between the buttons is that the button in the header linksthe user to a chapter with overall information about the page and the settings,whilst the other two information buttons takes the user to different chapterswith specific information about the Exchange and IMAP/SMTP protocols. Asseen in Figure 8.12 the previous signup did not provide any sort of informationexcept to ask the user to select one of the settings. It was realized that itcould be hard for a user to know which settings to use and decided to providea large amount of information that could help the user with the selection. Thebuttons have also been increased in size and centered on the page to providebetter usability and balance to the page. The navigation area is placed at thebottom with the “next” button disabled. The “next” button does not provideany function since the user is redirected as the “Imap” or “Exchange” buttons


are pressed. However, it was decided to keep the “next” button so that theappearance of the navigation area was not changed. The result of the redesignof this view is depicted in Figure 8.13.

Figure 8.12: Screenshot of the previous page for selecting email server type.

Figure 8.13: The redesigned version of the page for selecting email server type.


8.1.7 Exchange settings page

There are a few changes that have been done with the Exchange settings page.As on the other pages in the setup, the graphical interface has been modified. Itwas also decided to change the input fields on the page. In the previous signupthere where three visible input fields when the page was shown as seen in Figure8.14. If the connection attempt to the exchange server failed, two additionalinput fields appeared as seen in Figure 8.15. It was decided to show all inputfields right from the start and to remove the “Path” input field, see Figure8.16. The input in the “Path” field was added to the end of the input in the“Server URL” field and a user could just as well enter it directly into that. Thereason to show the “Domain” input field from the start was to provide an inputoption to users whose “Exchange” servers has this as a required parameter. Inthe previous signup the user was required to get the connection failed messagebefore the “Domain” input field was visible. The “Domain” input field in thenew signup is an optional input field that can be left out.

The user must enter data into all of the input fields, except “Domain”, toenable the “Next” button. Information buttons have been added next to the“Server URL” and “Domain” input fields and will provide a pop-up windowwith information about the expected data input.

Due to the fact that it could be hard for a user to know whether to chooseIMAP or Exchange settings on the previous page in the signup, a new functionwas added to the signup, see Figure 8.18. If the connection attempt to theExchange server fails and the Exchange server does not respond, Mobile Docu-ments automatically tries to connect to an IMAP server with the entered data.If an IMAP server responds with a message of success or that the login failed,it gives a strong indication that the user has chosen the wrong server protocolsettings. In this case a pop-up window is shown, see Figure 8.18, where theuser is informed that Mobile Documents found an IMAP server that respondedto the entered data and the user is asked to go to the IMAP settings pageinstead. If the user choose to proceed to the IMAP settings page, all the pre-viously entered data is transferred to the respective input fields on the IMAPsettings page. This to minimize the amount of data the user has to enter.

As in the previous signup, an error message is displayed if the connectionattempt to the server fails, see Figures 8.14 and 8.15. The error message wasredesigned to highlight the area of the input fields, putting focus on the first,top-down, input field with faulty data and display an error message in blackfont color at the bottom of the highlighted area. The idea with the redesignwas to show the error in a “non-frightening” way and try to explain what wentwrong. Figure 8.17 shows the redesigned error message.


Figure 8.14: The previous exchange settings page with a login error message.

Figure 8.15: The previous exchange settings page with server connection errormessage.


Figure 8.16: The new exchange settings page.

Figure 8.17: The new exchange settings page with an connection error.


Figure 8.18: The pop-up that is displayed when the connection to the exchangeserver fails and an IMAP server is found instead.

8.1.8 IMAP settings page

The IMAP settings page has undergone some major changes compared to theprevious signup, see Figures 8.19 and 8.20. The GUI has been redesignedto follow the style in the rest of the new signup. In the Exchange settingspage, see Chapter 8.1.7, a new feature was added that checks if an Exchangeserver responds to the entered data if the IMAP connection attempt fails.Error messages have also been redesigned as in the Exchange settings page, seechapter 8.1.7.

Another big difference compared to the previous signup is that there has beena button added at the top of the page from where the user can toggle betweendisplaying easy and advanced setup settings.

As seen in Figure 8.20 the easy setup settings have the same input fields asin the previous signup. The advanced setup settings, seen in Figure 8.21, letthe user specify more detailed settings that could be preferable to the user orrequired for Mobile Documents to be able to connect to the server. In theadvanced settings the user may enter different login data to the IMAP serverand the SMTP server, see Figures 8.21, 8.22 and 8.24. As seen in Figure 8.23the user is also able to specify which ports and security protocols to use inthe server communication. To minimize the amount of input data, MobileDocuments has preset port numbers depending on the security protocols the


user selects. However, the port numbers are editable. If the authenticationinformation differs between the IMAP and SMTP servers there are user inputcomponents to handle this as well, as depicted in Figure 8.24.

Figure 8.19: Showing the IMAP settings page of the previous signup. In thisscreenshot, incorrect information has been provided showing an error message.

Figure 8.20: The redesigned version of the IMAP settings page. The newversion of the text field is applied in this view. The image also depicts thetoggle button for toggling between the “easy” and “advanced setup”.


Figure 8.21: The IMAP settings of the redesigned signup in advanced setupmode.

Figure 8.22: The SMTP settings of the redesigned signup in advanced setupmode.


Figure 8.23: A text field for entering the port number will appear next to theoption that is selected.

Figure 8.24: If the authentication information differs between the IMAP andthe SMTP servers, an additional input text fields will appear to fill in thisinformation.


8.1.9 Folder selection page

When Mobile Documents has successfully connected to the email account, theusers are redirected to a page where they are asked to select the folders in theemail account that should be mirrored in Mobile Documents, see Figures 8.27-8.29. There are several differences between the folder page in the new signupand the previous signup, see Figures 8.25 and 8.26. One major difference isthe redesign of the folder list. There are now three different levels in thelist where each level represents the hierarchical level of the folder, see Figure8.30. The sub folders are indented to the right of the parent folders as anadditional indication of that it is a sub folder. The indention is following anatural logarithmic function. The indent function provides an increase thatgets smaller the greater the sub folder level. This gives a lite visual cue of thedifference in folder levels without pushing the folders too far to the right whilstthe folder item background color remains the same. In the previous signup, eachfolder had two check boxes from which the user could toggle if the folder shouldbe visible in Mobile Documents and whether Mobile Documents should notifythe user if the specific folder received an email. It was decided to remove thecheck boxes and instead have the whole list row function as a toggle button fromwhich the user may select to have the folder as visible, visible and notificationor none. The users toggle between the settings by pressing anywhere on therow where the folder is present and different symbols will appear/disappear onthe folder. Both the previous and the new folder trees are statically expandedfrom the start and folders can not be collapsed/expanded in this view.

An additional feature is that the user may select the settings directly on asubfolder and the parent folder(s) are automatically set to be visible. In theprevious signup, the users were forced to manually make a folder visible beforethey could interact with its subfolders. If the user manually disables the vis-ibility of a folder in the new signup, all the selected settings on its subfoldersare dimmed out to show that the settings no longer are valid on the folders,see Figure 8.30.

A “long press” functionality, when a user presses and hold down for a longertime, was also added on the folders in the new signup. If a user “long press” ona folder, additional folder settings appear where the user can select whether toset visible, visible and notification or none on a folder and all of its sub folders,see Figure 8.32. Similar options are also given to the users if the physical menubutton on the phone is pressed, the difference is that the settings then willapply on all folders, see Figure 8.31. The “Application” option was only visibleduring the development and is not present on the released application.

The inbox folder is automatically identified by Mobile Documents and is set tovisible and notification by default. The function was implemented because theinbox is a default folder for incoming emails and it was believed good to haveit visible.


Figure 8.25: The top of the previous folder list with check boxes.

Figure 8.26: The bottom of the previous folder list.


Figure 8.27: The top of the new folder list.

Figure 8.28: The new folder list with a single sub level.


Figure 8.29: The bottom of the new folder list.

Figure 8.30: The new folder list with all three different levels.


Figure 8.31: The menu that is visible when the physical menu button is pressed.

Figure 8.32: The menu that becomes visible on a folder long press.


8.1.10 Confirm folder page

After the users have selected the folder settings they are redirected to a pageto confirm the settings. The page resembles the folder settings page exceptthat it only displays the folders that have been set to be visible and visiblewith notification. The graphical folder hierarchy is the same as for the folderselection, see Figure 8.34, but the user can not change the settings on thefolders. The differences from the previous signup, see Figure 8.33, are the sameas on the folder settings except that there is also an information text added atthe top of the page. A text will notify the user if there are no folders set asvisible. The point of this page was to give the users an overview of the actualfolders that they have selected and the folder settings. The previous page couldin some cases contain a very large amount of folders which could make it hardfor the users to get an overview of the selected folders.

Figure 8.33: The previous version of the folder confirmation page.


Figure 8.34: The graphical representation for folder hierarchy is used in thefolder confirmation page as well as the folder selection page.

8.1.11 Delete/sent mail folder page

If the connected email account uses an IMAP/SMTP server the users are able tomanually select what they want to do with sent and deleted emails, see Figure8.35 and 8.36. This is a new feature that was not present in the previous signup.The page consists of five different radio buttons and information texts dividedinto two groups, one for sent emails and one for deleted emails. The users arepresented three options for sent emails, one radio button for each choice. If auser selects the option “Save in folder:”, a pop-up window will appear wherethe users have to select the folder that the sent emails should be stored in, seeFigure 8.37. The same applies to “Move to folder:” in the options for deletedemails, see Figure 8.39. The folder name will appear to the right of the radiobutton text after a folder has been selected, see Figure 8.38.

Mobile Documents will automatically try to identify the folders “Sent” and“Trash” and set them as default folders for sent and deleted emails.


Figure 8.35: The top of the page where the user is able to select the settingsfor sent and deleted emails.

Figure 8.36: The bottom of the page where the user is able to select the settingsfor sent and deleted emails.


Figure 8.37: The pop-up window where the user can select the folder in whichthe sent emails should be stored.

Figure 8.38: The page where the user is able to select the settings for sent anddeleted emails after the user have selected new folders. The folder names aredisplayed to the right of the radio buttons.


Figure 8.39: The pop-up window where the user can select the folder that thedeleted emails should be moved to.

8.1.12 Signature page

On the signature page the user is asked to enter a signature that will be addedto the bottom of each email they send through Mobile Documents. MobileDocuments is not able to use any existing signature that may be connected tothe current email account. Hence, this is the only signature that will be addedto the emails. There is a default signature in the input field but it can beedited or removed if the users choose to do so. The default signature is a wayof promoting Mobile Documents. There are no functional differences with thesignature page in the new signup compared to the previous, compare Figure8.40 to Figure 8.41. An information text has been added at the top of the pageand the input text field has been redesigned.


Figure 8.40: The previous signup page for specifying an optional signature.

Figure 8.41: The redesigned version of the page for specifying an optionalsignature. The page resembles the previous version in every functional way,the difference is merely aesthetic.


8.1.13 Pin page

The pin page, as the signature page, have updated graphics and additionaltexts. See Figures 8.42 and 8.43 for the previous and new pin page. Aninformation text was added at the top of the page and the text on the checkbox was changed to a more easily understandable phrase. Everything is alsocentered on the page. Also the navigation area is different compared to theother pages in the signup and now only contains one button. The reason forthis is that the account has already been successfully set up at this point anda cancellation or step backward would not abort the signup. However, the useris able to change the account settings, e.g. the folder settings and signatureonce they have finished the signup.

Figure 8.42: The previous pin page.


Figure 8.43: The new pin page.

8.1.14 FAQ

The FAQ is displayed in a scrollable pop-up window. The FAQ focus on differ-ent chapters depending on the page that called the FAQ to open. The pop-upwindow is closed by pressing the physical back button on the phone. Due tothe large amount of text in the FAQ it was decided to keep it as minimalistic aspossible. An information icon and title tells the user that it is an informationwindow that is displayed. A screenshot of the FAQ is depicted in Figure 8.44.


Figure 8.44: The FAQ contains all information that Visiarc can provide tothe user regarding the information that is being asked for. In the screenshot adescriptive text is shown describing the IMAP server and how the user possiblycould get a hold of the information that is being asked for.

8.1.15 Google docs and Captcha

If the user connects a Google email address to Mobile Documents, a pop-upwindow is displayed when the user has completed the signature page, see Figure8.45. The user is asked if they want to connect Google Docs to the MobileDocuments account. The username and password are the same to Google Docsas to the email account, hence one only has to accept or decline.

Due to security rules set by Google a captcha is sometimes required to be re-solved when connecting to the Google account. If Mobile Documents receivesa captcha required response from Google, another pop-up window will be dis-played where the user is asked to resolve the captcha, see Figure 8.46.


Figure 8.45: The pop-up window where the user is asked if Google Docs shouldbe added to the Mobile Documents account.

Figure 8.46: A pop-up window where the user is asked to resolve a captcha.


8.1.16 Sign-up completed

When all the steps in the signup has been completed the user is redirected to theMobile Documents dashboard and a small notification is displayed confirmingthat the account has been set up, see Figure 8.47. The user is then able toaccess the connected email account through Mobile Documents.

Figure 8.47: Screenshot of the Mobile Documents dashboard and a notificationthat tells the user that the signup is completed.

8.1.17 Desktop signup

The desktop version of the signup had low priority in contrast to the Androidsignup. This was due to the fact that the Android signup was planned to golive with the next release of the application. Another reason was that Visiarcdid not want to put effort into making more people signup via the desktopclient. This was because people with incompatible phones could neverthelesscreate an account using their computer, an account that would take space inhibernation and be to no use.

Because of its low priority the desktop signup was presented to Visiarc as low-fiprototypes developed using Adobe Illustrator and Adobe Photoshop, presentinghow the layout and the design of the website could be compiled.

One of the key differences in the layout and structure of the new signup, incomparison to the previous, is how the steps of the signup are displayed to


the user. In the previous version of the signup all steps were stacked in thesame view and visible to the user at all times. However, the signup is not anasynchronous operation, meaning that certain parts of the signup containingvital user input are essential for the server to perform the latter parts, e.g. emailaccount password is ruling for the server to obtain the email account folders.This is depicted in Figure 8.48. This predicament was handled with the latterparts of the signup being greyed out and disabled until the correct informationin the previous parts had been provided. This approach was straining the3’d, 4’th and 7’th design rules provided by Schneiderman. The layout hadthe possibility of confusing the user as input components were visible but notaccessible to the user, for no apparent reason.

Figure 8.48: Screenshot showing the previous web signup. All user input wasdisplayed on one single page, causing confusion about why several input ele-ments were disabled and at the same time visible. This was a concept that wastried to be avoided when developing the redesign of the web signup.

To avoid this issue it was decided to break the signup process into individualparts in a synchronized flow. As Figure 8.49 shows, the layout of the initialpart is very similar to the original one, containing the same components withsimilar mapping. The difference is the displayable separation of the steps which


made us develop a progress indicator as a header in the upper part of the view.As every signup via web consisted of the same amount of individual steps theprogress indicator was designed in a straightforward way, simply listing thethree steps that were going to take place with highlighted text indicating theactive step.

Figure 8.49: Screenshot showing the initial step of the signup. The email hasbeen confirmed by letting the user fill in the email address in a previous form.An email is sent from Visiarc to the user containing a link which links the userto the signup process.

When signing up a new account the user was presented with the view depictedin Figure 8.48, no matter what type of email account they had. This wasno issue for the email accounts of some of the more popular domains such as“Gmail” or “Yahoo!”, as the back-end already had information about correctconnection preferences in prepared templates for these types of accounts. Allthe user had to do was to type in the password for the email account and theserver would import the folder information for the account. However, this stepwould fail if the user would sign up with an email account with a domain notpreviously encountered by the server. This is because additional information


regarding email domain server settings would have to be provided by the userfor the server to access the account. If the user is unaware of this the informa-tion would be communicated first after a failed attempt to connect, promptingthe user to continue the signup in the “Manual setup”. In order to avoid this, anew feature was added to the desktop signup which checked whether the emaildomain is recognized from a previous successful signup. If the domain is notrecognized the user will be presented with the manual signup view explainingthat their email domain is new to the system. See Figure 8.50.

Figure 8.50: An explanatory text will appear if the entered email has a domainthat has not been encountered by Mobile Documents before.

In the manual setup view it was decided to reconsider the amount of user inputcomponents. In the existing version a large range of individual input fieldswas visible to the user and they were enabled or disabled depending on othersettings. As Figure 8.51 shows, three text fields are present in the same vicinityas an option group. They are enabled or disabled depending on which of theradio buttons that are selected.

Figure 8.51: In the previous signup, the input text fields for providing portnumbers were visible at all times, and would still hold possible entered dataeven if they had been de-selected.

Since the disabled text fields still contained visible port numbers the questionwas raised whether this potentially could confuse the user. However, the bestpractice for circumstances like these are not always clear. As James Crook,


GUI developer of the audio editor Audacity1 puts it when discussing a similarproblem:

“In normal circumstances:

– Enable/Disable if just a few fields affected.– Hide/Show if many fields affected.

It really helps to have the dependent fields immediately afterthe field that affects them so that the dependency is clear...either on the same line, or on the line below and indented toindicate the dependency.”2.

The existing version followed this practice and for what could appear as thebest reasons. But there are other user experience experts who would arguethe contrary: disabled fields give extra thought for the user about why it isnot available. As per Steve Krug’s “Don’t make me think” one should removeelements that make the user think and which they do not need anyway [33]. Abetter practice would instead be to give this attention to the field/setting thatwould make the disabled one available.

The latter practice stood as example when designing this section in the proto-type, as shown in Figure 8.52. The port number for the specified protocol isnow stationary at the bottom of the radio button option group. This solutionhas a flaw with mapping to the selected option, however it was concluded thatthe benefits of not having input components flicker in the view, depending onthe selected item, trumped that problem.

Figure 8.52: In the redesigned version of the signup there was one text field forthe port input, if it was applicable for the selected option. It was concluded thatthis should avoid any possible confusion that the previous approach generated.

Other instances of input components being visible even though they were dis-abled were found in the existing signup.

1Audacity, http://audacity.sourceforge.net/?lang=sv, retrieved: 2011-12-042Stack Exchange User Experience, http://ux.stackexchange.com/questions/

5727/hide-or-disable-form-options, retrieved: 2011-11-02


As shown in Figure 8.53 text fields implying user input was visible even thoughthey were disabled. In this example the user is expected to provide SMTPserver authorization data if it differs from the data provided for the IMAPserver.

Figure 8.53: The text fields for specifying possible additional authenticationinformation for the IMAP server were still present even when that option wasnot active. This could easily produce the notion with the users that they neededto put in this information again, even though that was not the case, causingan unnecessary thought process.

If the data is the same then the user is not expected to provide any moreinformation and therefore the input components should not be displayed. Thiswas handled in the redesign of the signup, as shown in Figure 8.54.

Figure 8.54: In the redesign of the signup, the text fields for specifying addi-tional authentication information are hidden if that is not the selected option.

As in the Android signup the users are expected to specify which folders theywant to access through Mobile Documents. The existing view handled thissimply by a checkbox selection tree, as shown in Figure 8.55.

Figure 8.55: The folder selection tree of the previous signup. A bland andsomewhat confusing representation in our mind.

A new design was developed for this feature incorporating the aspects consid-ered for the corresponding view in the Android version. As shown in Figure


8.56 a tree of folder icons imitating the visual layout as seen in Microsoft Win-dows file manager was used. This visual expression will be recognized by alarge portion of the users and has a better chance of communicating the folderrelation rather than its predecessor.

Figure 8.56: The folder selection tree of the redesigned signup use similar graph-ical elements and design patterns that have since long been used in conventionalfile browsing trees.

The same icons that were used in the Android signup for representing the“Visible” and “Notify” flags for a folder were also added in this solution. Theicons representing a check sign and a bell work as metaphors for their function.Using the bell as a metaphor for the Notify feature increases the chance of theuser comprehending what the feature does and represents.

The possibility of mass selection in the tree was also introduced. If the userhas a large library of folders in their email account then the ability to performmass selection will save the time otherwise being wasted on repetitive tasks3.

3Zoho, http://www.zoho.com/mail/webmail.html#alink3, retrieved: 2011-12-04

Chapter 9

Conclusions & discussion

The main purpose of the project was to redesign the existing signup processand GUI for the Mobile Documents Android application. Utilizing knowledgein interaction design to develop the most user friendly experience possible. Theframe for how the signup was to be conducted was already set by Visiarc them-selves with the existing signup, and the task was mainly how to communicatethis process to the user in the best understandable way.

Studying the existing signup, evaluating it against existing heuristics and de-sign principles for UI design gave good pointers to how the process could beimproved from a user point of view. This background study also consisted oftaking a look at existing signup processes for similar email clients. However,it was soon concluded that these processes, besides having more work done totheir aesthetics, did not offer a user experience much better than the alreadyexisting Mobile Documents signup did. Target points in the solution that wasto be addressed, such as communicating to the user why certain informationwas asked for or where the user could get hold of this information, was absentin all the existing signups evaluated. A significant range of technical terms wereused throughout the UI’s without any good explanation of what they were orwhere the user could find the correct settings. Following the principles for easyerror prevention to ease the input for the user by using FAQ’s, examples andthe automatic testing with other types of servers when one request to a serverfails, were all features we wanted to add to the redesigned version of the signup.

During the design phase a series of mockups were developed and presentedto the client for evaluation. Each presentation was evaluated for a numberof iterations with small differing tweaks to find the most suitable solution.Using an iterative design process helped with motivating design choices as awide range of differing approaches could be examined and either dismissed orincluded in the final product. Developing the mockups in Adobe Illustrator and

88

9.1. Restrictions and Limitations 89

Photoshop also proved to be useful tools since resources used for the mockupscould be directly transferred over to the implementation if desired.

The initial task of this thesis was to develop a prototype for the Android signupand a prototype for the desktop signup. However, this came to be reconsid-ered as the work went by. The client, Visiarc, found it much more valuableto have the new signup integrated into the upcoming release. This led to re-prioritization of the upcoming work. Time had to be to have transferred fromthe desktop signup over to the implementation of the Android signup. Fortu-nately this was decided quite early in the design phase where a large portionof the available time still could be allocated. Nevertheless it demonstrated theinvaluable importance of total transparency and agreement between client, endcustomer and developer.

However, total agreement between all parties will not shield one from all pos-sible complications when developing. As showed in one instance of this thesiswhen an additional feature of the signup was introduced far into the imple-mentation phase. This was the feature of declaring what should be done withemails sent or deleted by the user, which was to be displayed in a new individ-ual view. The implementation was at the brink of completion when this wasintroduced which forced us to adjust a few parts of the structure, there amongthe display and arrangement of the progress indicator. As with the initial workthis section was mocked up and evaluated before it was integrated into theexisting implementation.

The reason for this late addition to the task was merely that it was not presentin the previous version of the signup and had been forgotten and never men-tioned by the client in the initial design phase.

Besides the small issues regarding client agreement the project was completedsuccessfully. The developed signup covered in this thesis was integrated intothe new release of February 2011.

9.1 Restrictions and Limitations

A major downside of the signup is that Mobile Documents is not always ableto automatically identify the email server settings by only looking at the emailaddress. We created a few templates for the most common email domains, butsince anyone can create their own domain name to use in their email address,there is no way to create templates for every single domain. If Mobile Docu-ments does not have information about the specific email server settings, it isup to the user to provide it. The settings themselves can be hard for a user tounderstand and know how to obtain. Unfortunately, this seemed to be a com-mon problem among email applications as none of the other email applicationsthat was looked at had taken any steps to solve this issue.

90 Chapter 9. Conclusions & discussion

The fact that we did not always know the specific email server settings forced usto provide necessary input options for different kinds of email servers. Depend-ing on the email server, different settings are required. The different settingscaused us to vary the signup depending on the email server, instead of havingan identical signup for all servers. Due to the fact that we had to ask the userfor the email server settings we set our focus on letting the user understandthe settings. However, it is still up to the user to obtain the crucial settings in-formation by either contacting the email provider or searching through variousdocuments. If we somehow would be able to automatically identify the emailserver it would really simplify the signup on the users side and minimize therisk of signup errors.

A limitation of the thesis is the lack of testing on actual Mobile Documentsusers. The testing has been limited to be conducted on employees at Visiarcand a few other people in our social environment. Testing on a group of actualMobile Documents users could have provided us with statistical data of thedifference in success rate between the new and old signup. It is something thatwould be necessary if we were to further enhance the signup.

Most of the changes, compared to the old signup, and features we implementedon the new signup, where based on feedback from existing Mobile Documentsusers that had undertaken the previous signup. However, we have no statisticalresults on how the new signup have solved the issues mentioned in the usersfeedback of the previous signup.

Chapter 10

Acknowledgements

We would like to thank the staff at Visiarc for their great support. Also greatthanks to Frank Drewes at Umea Univeristy and our familys for their supportand patience during the work of this thesis.

91

References

[1] Cole A. Does hardware matter anymore? Enterprise Networking Planet,2011.

[2] Mohamed A. A history of cloud computing. Computer Weekly Magazine,4, 2009.

[3] Ronkainen J. and Warsta J. and Abrahamsson P. and Salo O. Agile soft-ware development methods, review and analysis. ISBN: 951-38-6009-4,2002.

[4] Varma P.S. and Adari V.R. and Diwakar Ch. Cloud computing with serviceoriented architecture in business applications. IJCST, 3, 2012.

[5] Kim L. and Albers M. J. User web browsing characteristics using palmhandhelds for information retrieval. Technology & Teamwork, 2000.

[6] Griffith R. and Joseph A.D. and Katz R.H. and Konwinski A. and LeeG. and Patterson D.A. and Rabkin A. and Stoica I. and Zaharia M. andArmbrust M. and Fox A. Above the Clouds: A Berkley View of CloudComputing. Electrical Engineering and Computer Sciences University ofCalifornia at Berkeley, 2009.

[7] Shneiderman B. Designing the User Interface - Strategies for EffectiveHuman-Computer Interaction. MA: Addison-Wesley Publishing Company,second edition edition, 1992.

[8] Lehman J.L. and Tuttle S. and Benjamin G. and Dean S.T. The journalof computing sciences in college. ISSN 1937-4771, 2010.

[9] Nielsen J. and Budiu R. Usability of Mobile Websites 85 Design Guidelinesfor Improving Access to Web-Based Content and Services Through MobileDevices. Nielsen Norman Group, 2009.

[10] Browne C. Cloud computing today and tomorrow - future it is in theclouds. Suite101.com, 2010.

[11] Skogby E. Mojligheter och svarigheter med mobila informationsapplika-tioner. ISSN-1653-5715, 2010.

92

REFERENCES 93

[12] Miller G.A. The magical number seven, plus or minus two some limits onour capacity for processing information. Psychological Review c© by theAmerican Psychological Association, 101, 1994.

[13] Merrick R. and Gorienko L. No wires attached: Usability challenges inthe connected mobile world. IBM System Journal, 42, 2003.

[14] Morse D.R. and Holland S. Audio gps: Spatial audio in a minimal atten-tion interface. Personal and Ubiquitous Computing, 6, 2001.

[15] Erlbaum L. and Hollnagel E. Handbook of cognitive task design. LawrenceErlbaum Associates, 2003.

[16] Klensin J. Simple Mail Transfer Protocol, 2008.

[17] Vijayan J. Twitter breach revives security issues with cloud computing.Computerworld, 2009.

[18] Verclas K. Your .org and the mobile web: Strategies to improve your .org?sonline presence and grow visibility for your organization. MobileActive.org,2009.

[19] Gruman G. and Knorr E. What cloud computing really means. InfoWorld,2008.

[20] Ljungberg F. and Kristoffersen S. Making place to make it work: Empiricalexplorations of hci for mobile cscw. ISBN:1-58113-065-1, 1999.

[21] Laarni J. and Karkkainen L. Designing for small display screens. ISBN:1-58113-616-1, 2002.

[22] Young Kim C. and Herbert S. and Lobo D. and Kaskaloglu K. Webusability guidelines for smartphones: A synergic approach. InternationalJournal of Information and Electronics Engineering, 1, 2011.

[23] Satyanarayanan M. Fundamental challenges in mobile computing. ACMSymposium on Principles of Distributed Computing, 15, 1996.

[24] Watters C. and Mackay B. The impact of migration of data to smallscreens on navigation. IT&Society, 2003.

[25] Grance T. and Mell P. The NIST Definition of Cloud Computing. NationalInstitute of Standards and Technology Gaithersburg, 2010.

[26] Malik N.A.A. Cloud computing and executive management. University ofMaryland University College, 2009.

[27] Norman D. and Nielsen J. Usability of Mobile Websites & Applications:210 Design Guidelines for Improving the User Experience of Mobile Sitesand Apps. Nielsen Norman Group, two edition, 2011.

[28] Tarasewich P. Designing mobile commerce applications. Communicationsof the ACM, 46, December 2003.

94 REFERENCES

[29] Zijlstra P. and Petters S.M. 6th international workshop onoperating systems platforms for embedded real-time applications.http://lwn.net/Articles/381177/, 2010. Retrieved:2011-04-26.

[30] Rekimoto J. and Poupyrev I. and Maruyama S. Ambient touch: Design-ing tactile interfaces for handheld devices. http://ivanpoupyrev.com/e-library/2002/uist2002 ambientouch.pdf, 2002.

[31] Morris P.W.G. The Management of Projects. Thomas Telford ServicesLtd., second edition edition, 1994.

[32] Pegoraro R. Internet providers should find their way to imap. WashingtonPost, 2004.

[33] Krug S. Don’t Make Me Think, A Common Sense Approach to Web Us-ability. New Riders Press, second edition, 2005.

[34] Goolsbee J. Z. and Sanchez C. A. Character size and reading to rememberfrom small displays. Computers & Education, 55, 2010.

[35] Velte T. J. and Robert C. and Elsenpeter R. C. and Velte T. and VelteA. T. Cloud Computing, A Practical Approach. McGraw-Hill ProfMed/Tech, 2009, first edition, 2009.

[36] Hollands J. G. and Wickens C. D. Engineering Psychology and HumanPerformance. Pearson, three edition, 1999.

Appendix A

Hierarchical Task Analysis

95

96 Chapter A. Hierarchical Task Analysis

Figure A.1: Hierarchical Task Analysis