Anders Markstedt and Mikael Olofsson · 2007. 1. 29. · Anders Markstedt and Mikael Olofsson...

Cpay a complete designprocess of a payment

application

Anders Markstedt and Mikael Olofsson

January 29, 2007Master’s Thesis in Computing Science, 2*20 credits

Supervisor at CS-UmU: Jan Erik MostromExaminer: Per Lindstrom

Umea UniversityDepartment of Computing Science

SE-901 87 UMEASWEDEN

Abstract

A common mistake during software development is to focus to much on the technicalaspects and not enough on the ones who are actually paying your salary - the cus-tomers (users). This thesis follows a user centred design process from an idea to a fullyfunctional application, covering the essential steps. Formal methods and models arepresented and discussed along with user observations, questionnaires and interviews.The work includes a pre-study where similar applications where evaluated and targetgroups requirements was identified. The pre-study was followed by several prototypesthat were evaluated iteratively before the final application was implemented. The resultis a fully functional payment application that is easy to use. The application supports:monetary transactions, exporting transactions to different formats (e.g. XML, PDF,XLS), searches and the printing of receipts. The result of this master thesis is a fullyfunctional application which according to the evaluation is appealing and easy to use.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Problem Description 32.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Technical Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 Java Web Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Work Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 The Design Process 73.1 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Data Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Get To Know The Target Group . . . . . . . . . . . . . . . . . . 83.1.3 Alternative Design . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Life Cycle Models In Iterative Design . . . . . . . . . . . . . . . . . . . . 93.2.1 The Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 The Preece Model . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.3 The Spiral Lifecycle Model . . . . . . . . . . . . . . . . . . . . . 103.2.4 The Star lifecycle model . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 User Centred Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Conceptional Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5.1 Low-fidelity Prototypes . . . . . . . . . . . . . . . . . . . . . . . 133.5.2 High-fidelity Prototypes . . . . . . . . . . . . . . . . . . . . . . . 133.5.3 Prototype Comparison . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 Usability Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7 Making Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.8 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii

iv CONTENTS

3.8.1 CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.9 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Evaluation methods 17

4.1 Involving Users in the Design Process . . . . . . . . . . . . . . . . . . . 17

4.2 Observing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Asking Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Interviewing users . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Asking experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5 Cognitive walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6.1 Nielsens ten usability heuristics . . . . . . . . . . . . . . . . . . . 22

5 Accomplishment 25

5.1 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 Identifying the target group . . . . . . . . . . . . . . . . . . . . . 26

5.1.2 Identifying needs and requirements . . . . . . . . . . . . . . . . . 26

5.2 Conceptional design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Low-fidelity prototype 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27


5.5 High-fidelity prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.6 Elaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.6.1 XML Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.6.2 PDF - JFreeReport . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.6.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.7 System design with the use of CRC cards . . . . . . . . . . . . . . . . . 29

6 Results 31

6.1 Identifying needs and requirements . . . . . . . . . . . . . . . . . . . . . 31


6.2.1 List of usability problems . . . . . . . . . . . . . . . . . . . . . . 32


6.3.1 List of usability problems . . . . . . . . . . . . . . . . . . . . . . 34

6.4 High-fidelity prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.4.1 List of usability problems and design proposals . . . . . . . . . . 34

6.5 Presenting large amount of data . . . . . . . . . . . . . . . . . . . . . . 35

6.5.1 A solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.6 technical description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.7 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.7.1 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CONTENTS v

7 Conclusions 417.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8 Acknowledgements 43

References 45

A Requirements specification 47A.1 Technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 Features and User Experience . . . . . . . . . . . . . . . . . . . . . . . 48A.3 API and code reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

B Questionnaire 51

C Evaluation of the digital prototype 53

D Paper prototype 1 55

E Paper prototype 2 59

F UML 61

vi CONTENTS

List of Figures

2.1 Screenshot from Paypal . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Screenshot from Swedbank . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 The Waterfall model, adapted from [18, p.187] . . . . . . . . . . . . . . 103.2 The Preece Model, adapted from[18, p.186] . . . . . . . . . . . . . . . . 103.3 The spiral model, seen in [5] . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 The Starmodel, adapted from [18, p.193] . . . . . . . . . . . . . . . . . . 12

5.1 Work flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Early sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Evaulation of paper prototype . . . . . . . . . . . . . . . . . . . . . . . . 275.4 CRC cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 System description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Overview mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3 Advanced search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.4 Confirm payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.5 Print preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

D.1 Login view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.2 The main view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55D.3 Overview view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.4 Payment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.5 Confirm dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.6 Import view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57D.7 Settings view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

E.1 Login view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59E.2 Overview view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59E.3 Payment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.4 Confirm Payment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

vii

viii LIST OF FIGURES

F.1 Package: CPay.gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61F.2 Package: CPay.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62F.3 Package: sibpub.tip.CPay . . . . . . . . . . . . . . . . . . . . . . . . . . 62

List of Tables

3.1 Relative effectiviness of low- vs. high-fidelity prototype . . . . . . . . . . 14

4.1 Evaluation techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ix

x LIST OF TABLES

Chapter 1

Introduction

This master thesis will follow the development process of a payment application. Themain focus of this report is on user interface design and specifically the design process,the work flow, used to achieve an easy to use graphical user interface (GUI). Here followsa short description of each chapter:

– Chapter 2, Problem description, here is the problem presented with limitationsand goals.

– Chapter 3, The design process. This chapter discusses the design process anddifferent lifecycle models.

– Chapter 4, Evaluation methods. This chapter presents several evaluation methods.

– Chapter 5, Accomplishment. Describes how the work was done.

– Chapter 6, Results. This chapter presents the result from this master thesis.

– Chapter 7, Conclusions.

1.1 Background

Svenska Internetbetalningar AB (SIB) is developing a general system for monetary trans-actions. With this system it will be possible to use a cell phone to pay in stores, vendingmachines and anywhere else where credits cards or money can be used. SIB’s targetgroup is companies that want to provide their customers with many payment optionsand individuals who performs many transactions per month. Since credit card compa-nies and SMS payments have large fees and SIB has very low fees, businesses with manytransactions can make big profits from this system. An Example: A premium SMS(SMS that is used for payments) that debits the customer 10 SEK will only generatean income of 5 SEK for the vendor since the service providers fee is about 50 percent.Since the benefit of a low fee system like this is great for small businesses, there is abig market for SIB. The target group demands high reliability, functionality and highsecurity. This report follows the development of an Internet bank-like system that offersmore functionality than SIB’s website.

1

2 Chapter 1. Introduction

Chapter 2

Problem Description

The goal with this master thesis is to develop a stand alone application that can handleup to one million transactions a month. This application has the project name CPay.

CPay must be able to perform single and mass payments and support conversion oftransactions between different representations (e.g. PDF and XML). To decrease theservers workload, users should perform searches and create PDF’s at the client side. Allcommunication with the server must be done by using SIB’s open programmatic interfaceTIP (Text Interface for Payments), through https (an encrypted http connection).

2.1 Goals

The primary goal with CPay is that it should be easy to use while still letting the useraccess advanced functions. CPay will support different languages to aid non-Englishspeaking users. Users should be able to print or create PDF and XML files of theirtransaction history. The application should work on all systems that support Java WebStart technology (at least OS X, Windows XP and Linux. Microsoft Vista was notavailable to the development team during testing). The purpose is to make it easier forthe users to access their SIB-account, pay bills and print receipts.

2.2 Technical Requirements

2.2.1 Java

A requirement from SIB was that Java 1.4 should be used. SIB motivated this with thefacts that Java 1.4 is the bundled version with many Linux distributions and that otherparts of the SIB system is written in Java 1.4. During the development it became obviousthat Java 1.5 was a better choice for CPay. 1.5 has better string handling, better supportfor xml parsing and more functions when it comes to graphics and window handling.When Java became open source a switch to Java 1.5 was permitted by the involvedpersons at SIB. The decision to use Java also permitted the use of Java Web Starttechnology which is explained in the following section.

3

4 Chapter 2. Problem Description

2.2.2 Java Web Start

Java web start is a technology for launching Java applications from a website. The mainbenefit with this technology is that the users are always running the latest version of thesoftware no matter if the application is started from the website, the start menu or froma shortcut on the desktop. The main differences between ordinary Java applications andweb start applications are:

– resources (images, sounds and other files) must be loaded with ClassLoader.getResource()or an equivalent method.

– All jar files must be signed with a certificate before deployment.

The application is started via a JNLP file. This file can be linked to directly fromany website. The JNLP file contains a list of resources that the application requires(e.g. external jar files), start up arguments for the Java virtual machine and a referenceto the file containing the main function (the function that is called when starting theapplication).

2.2.3 XML

Generating and parsing XML documents was another requirement. Extensible MarkupLanguage (XML) is a simple, very flexible text format, designed to meet the challengesof large-scale electronic publishing. XML-documents are easy to parse programmaticallyand are playing an important role in the exchange of a wide variety of data on the Web[28]. The huge amount of data that the application must handle demands an efficientXML Parser.

2.3 Work Procedure

With the goals and requirements in mind, the work procedure was set, as listed below.

– Evaluation of existing systems

– Design sketching + selection

– Paper prototyping

– Expert evaluation (iterative process, results in a new paper prototype)

– Elaboration phase, testing suitable solutions.

– Using CRC-cards to layout the code structure.

– Creating a digital prototype (alpha version)

– User and expert evaluation.

– Refining the solution

– Beta release.

2.4. Existing Systems 5

2.4 Existing Systems

Similar systems like PayPal and SwedBank were evaluated. These systems are webbased and not Java applications but their purposes are the same. PayPal supportstransactions in many different currencies and lets users set up their own shops. PayPalis among the most widely used payment systems on the web, with credit cards excepted.PayPal uses a Tab-like interface (as seen in 2.1) but it is actually just links to otherpages.

SwedBank has fairly clean design (as seen in 2.2) but the drop down menus are notlogical and the terminology used is not the same as the terminology of the users.

Providers of credit card payments for Internet stores do not provide their customerswith a graphical user interface (GUI) of any kind and it is up to the web-shop ownersto make a GUI for the credit card service.

A common hassle for businesses that use payment systems is the integration withtheir web shops and accounting systems. Depending on the depth of the integrationthe workload either ends up on the technical staff, who tries to integrate the differentsystems or on the bookkeeping personnel who manually must verify that the accountsmatch up.

Figure 2.1: Screenshot from Paypal

6 Chapter 2. Problem Description

Figure 2.2: Screenshot from Swedbank

Chapter 3

The Design Process

A huge challenge that interaction designers are facing is to design applications for alarge number of different users. The one-size-fits-all approach worked for designers acouple of years back when the functionality of the software was simple and the user’sgoals were limited. But today when the software is much more complex, the presentdesigners need to design the systems to support many different users with different goalsand knowledge levels. Many technological innovations rely upon user interface design toelevate their technical complexity to a usable product. Technology alone may not winuser acceptance. A good user interface design can be the difference between productacceptance or rejection in the marketplace. To develop successful products designersneed to listen to what people want and getting them involved in the design.

This chapter will explain how to develop a successful product beginning with thepre-study explained in section 3.1 and ending with the evaluation described in section3.9. This chapter will also discuss how the lifecycle models can facilitate the workfor the interaction designers, the importance of involving the users, conceptual design,prototyping, usability goals, how to make design decisions and system design. Thedesign process is an iterative framework, where evaluating and redesigning is performedat every stage in the design process.

3.1 Pre-study

A well prepared pre-study is a crucial step for the success of software developmentand a lot of money and time spent in the development can be saved. The goal withthe project must be established and all vague system requirements must be clarified.Alternative design proposals must be considered and with help of a number of datagathering techniques the appropriate target group with their needs and requirementscan be defined.

3.1.1 Data Gathering

The purpose of the data gathering is to collect sufficient, relevant and appropriate dataso that the target group with their needs and requirements can be established. Thereare several data gathering techniques, among others interviews (4.3.1), studying doc-umentation, questionnaires, workshops and observations (4.2) etc. Each of the listedtechniques yields different kind of data and are appropriate in different circumstances.

7

8 Chapter 3. The Design Process

These techniques are flexible and can be combined in many different ways to increasethe understanding of the users and their variety of requirements. The kind of data thatis required will depend on where in the design process the product is [18, p.210-211].

3.1.2 Get To Know The Target Group

When developing an application, identifying and understanding the target group is im-portant. A good method for that purpose is to analyze similar applications in relatedareas and look at which target group they are aimed for. Those applications mightgive an insight into the needs and requirements of the proposed target group. Anotherimportant issue that needs to be considered is how the product will affect the user indifferent environments and the constraints the users might deal with. It is also impor-tant to determine when it is time to test the prototypes and to find people that fit theappropriate target group to get valuable feedback [1].

Develop your product with people and their capabilities - not computers andtheir capabilities - in mind [1].

It is important for the development team to be aware of that they do not use the sameterminology as the target group. The development team has a better knowledge aboutthe applications than the customers are likely to have. A designer must remember thathe/she does not design the program for him/herself but for the users, it is the designer’sresponsibility to choose the best representation of the information and design for thetarget groups usage patterns and needs [1].

Identifying Needs And Establishing Requirements

Whatever the initial situation and whatever the aim for the project is, user needs andrequirements must be addressed, clarified and discussed in an early stage the designprocess. The requirements can be among others the user and their capabilities, theircurrent task and goal, the condition and surrounding environment where the productwill be used and a variety of constraints on the product performance. In softwareengineering two different kinds of requirements are traditionally identified, functionalrequirements that specify what the system should do and non-functional requirementswhich describe which constraints there are on the system [18, p.201 205]. An articlepublished in January 2000 [21] investigates IT projects and the cause of their failure.The article admits that there is no single cause of IT project’s failure but requirementsissues figured highly in the findings. If the requirements are wrong the users might notbe interested in the product.

When identifying the users needs the aim is to understand as much about the usersas possible so that the system can be developed to support the users to achieve theirgoals without any frustration or irritation. With information about the users and theirneeds, establishing requirements becomes much easier. To get the requirements right, thefirst step is to gather data, then analyze and interpret it and then capture the findingsin a form that can be expressed as requirements. Identifying needs and establishingrequirements are an interactive activity that iterates to constantly revise and refine therequirements [18, p.201-203].

3.2. Life Cycle Models In Iterative Design 9

3.1.3 Alternative Design

Considering alternative designs is a crucial step in the design process. A common humantendency is to stick with something that works without considering alternative solutions.Designers probably know that better solutions exist but it is very easy to accept the firstsolution, because it works. The final product may not be as desirable and interesting asit could be, since alternative design solutions never have been considered. Alternativedesigns are often inspired from different applications, through use and observation fromsimilar products. Studies of suitable sources to get inspiration and ideas from, is animportant step in any design process, such as competitor’s products, early versions ofsimilar systems or something completely different. Choosing among alternative designsis about making design decisions, with the users and their goals and technical limitationsin mind [18, p.174-175].

3.2 Life Cycle Models In Iterative Design

A lifecycle model is a model that captures a set of activities and facilitates the work forthe developers. The model can be described as a plan or a framework that allows devel-opers to get an overall view of the development process and the management structure.Guidelines for user interface design can be very useful for many designers. Guidelinescan help the designers to develop a first version of the prototype that is closer to thefinal version of the application than if they were not used. Existing models have avariety of complexity, systems involving many developers and users may need a morecomplex model that describes each phase in more detail to provide a usable product [18,p.182-184].

Below are four lifecycle models described and discussed.

3.2.1 The Waterfall Model

The waterfall model was the first lifecycle model in software engineering and it formsthe basis of many life cycle models in use today. The waterfall model is a linear modelin which each phase must be completed before next phase can be started. The waterfallmodel starts with the analysis phase follow by the design phase, through the codingand implementation and finally the testing phase and maintenance. Each phase of thedevelopment proceeds in strict order, without any overlapping or iterative steps. Thedisadvantage of the waterfall model is that it does not allow for much reflection orrevision. To address this problem, modifications of the waterfall model have been madeand some level of iteration is now incorporated in most versions of the waterfall model[18, p.187-188]. The Waterfall model is shown in figure 3.1.


Figure 3.1: The Waterfall model, adapted from [18, p.187]

3.2.2 The Preece Model

This model is an iterative model that encourages user focus. The Preece model in-cludes identifying needs and requirements, design and the development of an interactiveprototype and finally evaluation. Based on feedback from the evaluation, new needsand requirements may be established and redesign is needed. The development endswith a final evaluation to ensure that the products meet the users requirements and theusability criteria [18, p.186]. The Preese model is shown in figure 3.2.

Figure 3.2: The Preece Model, adapted from[18, p.186]

3.2.3 The Spiral Lifecycle Model

The spiral model proposed by Barry Boehm in 1986 follows nor bottom-up nor top-downprocedures. Analysis and design follow an incremental and iterative design frameworkthat allows ideas and the progress to be repeatedly checked and evaluated [22]. The spiralmodel focuses on risk analysis and prototype developing rather than on the functionalityand user involvement, which has, contributed to new versions of the spiral model withmore user focus. The spiral model explicitly encourages alternative solutions to beconsidered unlike the waterfall model [18, p.188-189].

3.2. Life Cycle Models In Iterative Design 11

Figure 3.3: The spiral model, seen in [5]

3.2.4 The Star lifecycle model

The Star lifecycle model is a model that supports the design of interfaces. The modelemerged from some empirical studies of interface design proposed by Hartson and Hix1989 [10]. The Star model supports iterative refinement and rapid prototyping with theevaluation activity in the centre. The Star lifecycle model does not specify any orderingof the activities. The activities are interconnected, which means that the designerscan move focus from any activity to any other, assumed that the evaluation activityis completed. Hence whenever any activity is completed, the result must be evaluated.The star lifecycle model has not been used widely and successfully in big projects whichmight depend on that the model is very flexible. With a flexible model it is difficultto get an overall view of the development so that the progress can be tracked and thedeliverables specified etc. without essential changes in the model [18, p.192-193]. Thestar model is shown in figure 3.4.


Figure 3.4: The Starmodel, adapted from [18, p.193]

3.3 User Centred Design

User Centred Design (UCD) is a design methodology that focuses on user involvement.UCD involves users in all stages of the design process. UCD is especially effectiveon projects where the product technology is new or if the proposed target group andtheir behaviour are not well defined [14].The total user experience is the driving forcebehind all the design and not just the technology. Gould and Lewis [7] recommendthree principles of design that they believe can be used to attain systems that are easyto learn, ease to use and that contains the functionalities that people need in their work.

1. Early focus on users: Designers must understand who the users will be by directlystudying their cognitive, behavioural and attitudinal characteristics by observingthe user in their everyday work.

2. Empirical Measurement: Intended users should early in the development processbe observed and analyzed when using scenarios and manuals and when testingsimulations and prototypes of the proposed system.

3. Iterative design: When problems are found in user testing the problems must befixed and then more tests need to be carried out at the redesigned version to se ifthe changes improved the usability and the technically aspects. This means thatdesign must be iterative, tests and redesign must be repeated as often as necessary.

3.4 Conceptional Design

The most important thing to design is the user’s conceptual model. Every-thing else should be subordinated to making that model clear, obvious andsubstantial that is almost exactly the opposite of how must software is de-signed (David Liddle, 1996, p .17) seen in [18, p.39].

Conceptional design is to transform the users needs and requirements into a conceptualmodel. A conceptual model is a mental model that describes the proposed system in

3.5. Prototypes 13

terms of ideas and concepts, the system functionality and how the system is organizedand operates [18, p.249-250]. A conceptual model is often described as a design tool fordesigners, before they actually start working on placing out components at the interfaceof the system [12]. The users already have a mental model that describes the taskand their expectations about the components of the task, the organization of thosecomponents, and the overall workflow in the system. This mental model arises fromusers experience from the real world, experience from other software applications andwith computers in general. For example users have experience from paying the billswith the use of Internet banks. When creating a conceptual model the designers shouldreflect the user’s mental model and try to picture the users experience when using thenew product [1]. During the conceptual design phase, designers mental model are movedfrom the designers consciousness to sketches, scenarios and prototypes [18, p.249- 250].

3.5 Prototypes

Studies emphasize that using prototypes in the design process helps to generate designideas and stimulate discussions around the product. The prototypes are used to getfeedback from the users and colleagues and others that are involved in the product cycle.Prototypes answer questions and support designers in choosing between alternatives [18,p.240-242]. Prototypes can also be used as an early demonstration to the proposed clientsas a marketing aim [23]. Prototypes are often divided in two categories, low-fidelityprototypes and high-fidelity prototypes. Prototypes that have less similarity with thereal product classifies as low-fidelity prototypes while high-fidelity are interactive modelsthat are similarly to the real product [18, p.240-242]. In the following section low-fidelityand high-fidelity prototypes are described and compared.

3.5.1 Low-fidelity Prototypes

Paper prototypes are used in usability testing for software applications in an early stageof the design process. Paper prototypes are low-tech, low cost, both in terms of timeand materials required to create the prototype. The prototypes are also effective whenit comes to finding design problems [8]. Boling and Frick [6] contend that ”Paper proto-types seem inherently less finished or real than electronic prototypes”. They also claimthat paper prototypes allow users to feel comfortable to criticize the system because thedesign is obviously very rough. Users also feel that there still is time to incorporate thefeedback and make changes, since the designers have invested minimal time and effortinto creating the paper prototype [8].

A problem with using paper prototypes is that there are particular aspects of thedesign and functions that are difficult to simulate and users or usability experts wouldrisk missing some design problems [23].

3.5.2 High-fidelity Prototypes

Low-fidelity prototypes are often used as input to develop high-fidelity prototypes. High-fidelity prototypes are fully interactive. The prototypes do not need to function exactlyas the real product but it needs to give the user a good picture of the functionalityand the structure of the system. High-fidelity prototypes are effective to test technicalissues and for selling ideas. High-fidelity prototypes are not as quick and easy to create


as low-fidelity prototypes but they faithfully represent the interface of the real productand give the users the opportunity to navigate and explore the system [18, p.245-246].

The functionality in a high-fidelity prototype can either be developed vertical orhorizontal. Vertical high-fidelity prototypes are often developed in cases when time islimited and offer deep functionality but only a subset of the available functions while ahorizontal offer many functions but few details [19].

3.5.3 Prototype Comparison

Nielsen [15] compared the effectiveness of using paper prototypes and computer mock-ups in a heuristic evaluation. Nielsen found that when using a computer mock-up userswere more likely to find the major problem than users evaluating the paper prototypes.Nielsen also points out that problems that users associated with functions or design thatwere missing are easier to find in running applications, but the study was difficult toanalyze because Nielsen provides few practical details about the evaluation [23].

Another study between paper prototypes and computer mock-ups shows almost thesame quantity and quality of user statements. The study shows that users prefer com-puter prototype because these make the user feel free to explore the system and theuser feel less observed when performing the usability test. Textbooks claim that paperprototypes enhance the communications between the users and the designers which thestudy did not prove [20].

A more detailed description with advantage and disadvantage between respectiveprototypes are present in the table below, Quoted from [18].

Table 3.1: Relative effectiviness of low- vs. high-fidelity prototypeType Advantages Disadvantages

Low-Fidelity • Lower development cost • Limited error checkingprototype • Evaluate multiple design • Poor detailed specification

• Useful communication device to code to• Address screen layout issues • Facilitator-driven• Useful for identifying market • Limited utility afterrequirements requirements established• Proof-of-concept • Limited usefulness for

usability tests• Navigational and flow limitations

High-Fidelity • Complete functionality • More expensive to developprototype • Prototype fully interactive • Time-consuming to create

• User-driven gathering• Clearly defines navigational • Not effective for requirementsscheme• Use for exploration and test

• Look and feel of final product• Serves as a living specification• Marketing and sales tool

3.6. Usability Goals 15

3.6 Usability Goals

To develop efficient system that support user’s needs and allow the users to be highlyproductive in their work, Preece’s [18, p.14-18] usability goals can be used as support.These usability goals are concerned with meeting specific usability criteria and are de-scribed below.

– Effectiveness: It is determined by looking at how well the user’s goals were metand whether all work is correct.

– Efficiency: Described as the time it takes for users to complete a specific task andthe way the system support the user in performing their tasks.

– Safety: The system must be safe to use, which means that the system must protectthe users from dangerous conditions and undesirable situations and preventing theuser from making serious errors.

– Utility: Refers to the functionality of the system. The system must be imple-mented with right kind of functions that support the user to achieve their goals inan efficient way.

– Learnability: Refers to how ease the system is to learn to use.

– Memorability: Refers to how easy a system is to remember how to use, oncelearned. This is especially important in systems that are used infrequently.

3.7 Making Design Decisions

When making design decisions regarding features in the application it is important totake the costs and the potential benefits in consideration. When adding new features itcan lead to a slow and a complex interface which is difficult to use. The best applicationsare not the products with most features, the best applications are those with the mostusable features. Designers should try to stick with the original intent of the applicationand just add features that are relevant to the applications and the features that supportthe users to achieve their goals [1]. Apple [1] believes that every time the applicationhas been built out (e.g. added new features), the following things can happen:

– Your application gets larger.

– Your application gets slower.

– You spend time developing new features rather than refining existingfeatures.

– Your application’s documentation and help become more extensive.

– You run the risk of introducing changes that could adversely affectexisting features.

– You increase the time required to validate the behaviours of your ap-plication.


3.8 System Design

Using tools have been common in object oriented software engineering when analyzingand designing programs. With the use of some methodology it can help programmersto write object oriented code that are easy to understand, reusable, upgradeable andeasy to regain. There are no guaranties that a specific method works on every kindof problem but it helps. The system designers always have the responsibility. Whendeveloping a software application the goal is to build an object oriented model of thesystem. First the designers need to make an object oriented analyze and determinewhich objects that are needed, which qualities and behaviors the objects are supposedto have and how to integrate and collaborate the objects with each others. Designersmust also determine which classes that are needed and which methods that are requiredto describe the objects behaviors. Designing an object oriented program with the use ofCRC cards is an effective methods that works well in many situations [13]. CRC cardsare described in next section.

3.8.1 CRC Cards

CRC stands for Class, Responsibility, and Collaborators, which are used to facilitateteam-based role-play. When an approach has been decided, the cards are used to recordthese three elements. The class stands for the name of the class. Responsibilities areclassified as ”things to do and things to know” and it should summarize ”what” ratherthen ”how”. The third element collaborator is often referred as ”helper” and the helperclass can be reused because it is independent. Object role-play is another importantkey element in the CRC card technique. Role-play really forces all team membersto participate and engage in the approach, which might lead to further explorationand improvements. In late 1980 CRC cards was described as a tool to learn object-oriented design. Recently the technique has been useful beyond the learning stage andis associated with how to support critical characteristics of design. CRC cards representclasses and facilities discussions of the structure of the system. CRC cards also makethe design easier, in the nature of determine the Class name, the Responsibilities, andthe Collaborators because CRC cards have a built-in heuristic guideline [4].

3.9 Evaluation

Without evaluation designers can not be sure that their software is a usable productthat supports the users in their work. The usability guidelines that designers use donot guarantee good usability. The evaluation needs to be performed at various stagesin the design process to avoid that problems are discovered after the product is shippedout to the costumers. Designers must know how to evaluate different kind of systems atdifferent stage of the development process. Bruce Tognazzini comments that:

Iterative design, with its repeating cycle of design and testing, is the onlyvalidated methodology in existence that will consistently produce successfulresults. If you do not have user-testing as an integral part of your designprocess you are going to throw buckets of money down the drain [9]

Next chapter describes different kinds of evaluation techniques.

Chapter 4

Evaluation methods

In this chapter, evaluation methods and interview techniques will be presented anddiscussed. Dennis Wixon sums up the purpose of evaluation methods:

The goals with iterative evaluation methods in a commercial world is toproduce the best possible product/design in the shortest amount of time atthe lowest possible cost with the least risk.[3]

4.1 Involving Users in the Design Process

When developing a system (like C-pay) the development team usually consists of en-gineers and programmers and their expertise is not only an asset but also a problem.The development team does not use the same terminology as the target group and sincethe development team has a deep knowledge in how the system works they don’t havethe same conceptual model as the end users will have. User testing is invaluable whenit comes to discover GUI-errors that even HCI experts won’t find, exceptions in thenetwork code that the programmer never foreseen and hardware inconsistency errorsthat should not exist [1].

Letting the end users test an early prototype will be a great addition to the develop-ment process, to observe the users lets the development team spot problems at an earlystage, where the cost and time it takes to correct them still is low. It is important toavoid interaction with users during tests because it might interfere with the test results.User instructions should be clear but only state the task they should perform - nothow they should perform it [1]. After analyzing the results of the first test designersshould construct a second prototype that addresses the problems from prototype one.When the second prototype is available, the designer should conduct a second set ofuser evaluations to check the workability of the solutions.

4.2 Observing users

Observing users leads to new types of products and helps designers evaluate prototypes.The obvious challenge for the evaluator is to observe without disturbing [18]. Whenperforming user tests it is important to remember that it is not an experiment so thequantitative data cannot be statistically analyzed, however areas where the users strug-

17

18 Chapter 4. Evaluation methods

gle can easily be identified and be used to locate problems [1]. Apple Human InterfaceGuidelines contains a useful listing for user observations and is quoted below [1]:

– Introduce yourself and describe the purpose of the observation (in verygeneral terms). Most of the time, you shouldn’t mention what you’ll beobserving. Make it clear to the participant that you are testing yourproduct, not the participant.

– Tell the participant about how long the test will take and that it’s OKto quit at any time, for any reason. The user should never feel pressuredto complete a test. Besides, quitting may indicate that the underlyingtask is too difficult or complex and should be simplified.

– A common testing methodology is to use the think-aloud protocol. Ifyou are using this protocol, explain how to do it. Ask participants tothink aloud during the observation, saying what comes to mind as theywork. By listening to participants think and plan, you’ll be able toexamine their expectations for your product as well as their intentionsand their problem-solving strategies.

– You may find that listening to users as they work will provide you withan enormous amount of useful information. In particular, you’ll discoversome of the details of the mental model the user has of the task. Youcan help users practice thinking aloud by having them describe a simpletask, like how they prepare a cup of coffee.

– Describe in general terms what the participant will be doing. Explainwhat all the materials are and the sequence in which the participant willuse them. If you are using a lab, explain the purpose of each piece ofequipment in the room (hardware, software, recording devices, and soforth) and how it will be used in the test. If you need to demonstrateyour product before the user observation begins, be sure you don’tdemonstrate something you’re trying to test.

– It is very important that you allow participants to work with yourproduct without any interference or extra help from the facilitator, theanalyzer, or anyone else. This is the best way to see how people reallyinteract with the product. For example, if you see a participant beginto have difficulty and you immediately provide an answer, you willlose the most valuable information you can gain from user observation:determining where users have trouble and how they figure out what todo.

– Note: There may be situations in which you will have to step in andprovide assistance, but you should decide what those situations will bebefore you begin testing. For example, you may decide that you willallow someone to struggle for at least 3 minutes before you provideassistance or that there is a distinct set of problems on which you willprovide help. However, if a participant becomes very frustrated, it’sbetter to intervene than have the participant give up completely.

– Conclude by explaining what you were trying to find out and answerany questions the participant may have.

– Use the results. As you observe, you will see users doing things you maynever have expected them to do. When you see participants making

4.3. Asking Users 19

mistakes, your first instinct may be to blame their inexperience or lackof intelligence. This is the wrong response to have. Remember that thepurpose of observing users is to learn what parts of your product mightbe difficult to use or ineffective because of faulty product design.

– Watch for patterns. Just because one user has a problem with some-thing, that does not mean every user will. Carefully consider why thesingle user had the problem and consider discarding that finding if itcan be easily explained, otherwise, recognize that the software may befaulty.

– Review all results with a cross-functional team comprising representa-tives of product management, marketing, engineering, human interfacedesign, documentation and quality assurance. Each of these partic-ipants will view the results through the lens of their own expertise,enabling them to provide valuable insights into various usability issueswith which the users might have struggled.

4.3 Asking Users

If the users like a program, they will buy it and recommend it to other users. Thereforethe designers should ask some questions to make their application not only a goodapplication but a great application: Does the program do what the users want? Dothey like it? Is the aesthetic design appealing? Did they have any problems while usingit? Will they use it again? Asking users is an obvious way of getting feedback. Themain techniques for asking users are interviews and questionnaires. The questions canbe either structured or unstructured and the evaluators can ask a large number of usersvia email to gain empirical data [18]. Interviews are explained in the following section.

4.3.1 Interviewing users

When interviewing a user there are three types of interviews [18], structured, semi-structured and unstructured. The types are named after how much control the inter-viewer imposes. The interviewer follows a predetermined set of questions and choosesbetween the three types according to the evaluation goals [18]. During the interview theinterviewer should avoid the following (Robson 1993, in [18]):

– Long questions because they are hard to remember

– Using jargon and language that is hard for the interviewee to understand

– Leading questions as they might influence the user’s response.

– Bias, be aware of your own bias and strive to be neutral in your questions

Always remember that the interviewees are doing the interviewer a favor so they shouldmake it as pleasant as possible for them. Always introduce yourself and try to dressappropriately (in a similar way as the interviewee or if in doubt, dress neatly and avoidstanding out) (Robson 1993, in [18]). There is a dilemma with interviews as Preecepoints out [18], Users do not always do what they say they do. People have a tendencyto answer in a way they think puts them in the best light, or they might forget whathappened or how much time they spent on a specific activity.


4.4 Asking experts

This approach is relatively quick and inexpensive compared to laboratory and field eval-uations and therefore it is popular among developers. Guided by heuristics the expertevaluators perform a walkthrough of the system, acting as users to identify problems. Abenefit from this method is that experts frequently suggest solutions to problems [18].

Table 4.1: Evaluation techniquesTechniques Evaluation paradigm

Observing Users Important for seeing how users act in a natural environment

Asking users Discussions with users and questionnaires are usedto collect user opinions.

Asking experts Provides critique of the usability and sometimessolutions to design problems.

4.5 Cognitive walkthrough

The Cognitive walkthrough method combines software walkthroughs with acognitive model of learning by exploration. [11, p. 119].

The concept of cognitive walkthrough (CW) is for the evaluators (experts) to performtypical user tasks by walking through the system looking for errors. An error, in this case,is the discrepancies between the users goals and knowledge, and the systems actions andfeedback [11]. CW is used to simulate a user’s problem solving process and to assure thatthe user is able to take the next correct action, based on the users memory and goals,while stepping through the dialog [17]. This technique is mostly used for evaluatingwalk-up-and-use systems (e.g. a teller machine) but has also shown to be effective onnon-walk-up-and-use systems [11]. The defining feature in CW is that CW focuses onhow easy it is to learn how to use the system, this is motivated by observations thatusers learn by exploration (Wharton et al, 1994 seen in [18]). The steps involved in CWare (as cited from [18])

– The characteristics of typical users are identified and documented. Sample tasksthat focus on the evaluated design aspects are developed. A prototype and a clearlist of actions needed to complete the task are produced.

– A team of designers and evaluators do the analysis together.

– While walking through the system, performing the action sequences for each task,the evaluators place each task within a scenario and tries to ask the followingquestions:

• Will the correct action be evident for the user?

• Will the user notice that the correct action is available?

4.6. Heuristic evaluation 21

• Is the feedback good enough? (Will the users know if they made a correct orincorrect action)

– During the walkthrough, concerns are noted and notes of side issues and designschanges are taken. A summary of the results are compiled.

– The design is revised to fix the problems that was discovered.

It is important to document the negative findings from the walkthrough [18], especiallyany negative answers for the questions above. The evaluators should note the severity ofthe problem, how often it (or how likely it is to occur) occurs and how serious it will befor the users [18]. The strengths of CW is that it focuses on user problems in detail yetno users need to be present while testing. A drawback with CW is that it is very timeconsuming and laborious to do[18]. Furthermore the narrow focus of the CW techniquecan be useful for some systems but not others.

An alternative to CW is Heuristic evaluation which is explained in the followingsection.

4.6 Heuristic evaluation

Heuristic Evaluation is a method for finding usability problems in a userinterface design by having a small set of evaluators examine the interface andjudge its compliance with recognized usability principles (the heuristics)[16,p. 373].

Heuristic evaluation (HE) belongs to the same category of design evaluation methodsas CW but HE is meant to be a more lightweight approach or as Jacob Nielsen callsit “discount usability engineering” [16]. Research has found HE very cost efficient [11]for finding usability problems in existing designs. HE finds more of the minor usabilityproblems than other methods [11], actually it also picks up on errors not even seenin actual user testing [16], These errors might be considered to be non-errors by somebut even small errors like inconsistent placement of fields may slow the user down by asecond. If these small errors accumulate and slow a user down by a minute a day at acompany with 60 employees, with everyone using the same software, the company willloose around 300 hours of work time a year due to small errors. HE also tends to find ahigher proportion of major (Major problems are problems that has serious potential forconfusing users or cause erroneous usage of the system) usability problems than othermethods [16]. Studies show that usability experts use the HE method more proficientlythan novice users [11] and despite that HE is the most cost efficient method, usabilityexperts can be hard to come by. The many non-severe errors found by HE makes ithard for the developers to prioritize their work and might spend hours on fixing non-errors. Baily [2] (as cited in [18]) points out that about 1/3 of the reported problemswere real usability problems and some of these were trivial. If we do the arithmetic thenumbers show that only half of the problems pointed out by heuristic evaluators aretrue problems [2].

More specifically, for every true usability problem identified, there will be alittle over one false alarm (1.2) and about one half of one missed problem(0.6). If this analysis is true, heuristic evaluators tend to identify more falsealarms and miss more problems than they have true hits [2].


4.6.1 Nielsens ten usability heuristics

Jacob Nielsen has listed ten heuristics that a designers should have in mind when design-ing applications. These heuristics is mostly used when evaluating but designers can savetime by incorporating these heuristics during an early design phase, the list is quotedfrom [16]

Visibility of system status

The system should always keep users informed about what is going on, through appro-priate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiarto the user, rather than system-oriented terms. Follow real-world conventions, makinginformation appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked ”emer-gency exit” to leave the unwanted state without having to go through an extendeddialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions meanthe same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design, which prevents a problem fromoccurring in the first place. Either eliminate error-prone conditions or check for themand present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. Theuser should not have to remember information from one part of the dialogue to an-other. Instructions for use of the system should be visible or easily retrievable wheneverappropriate.

Flexibility and efficiency of use

Accelerators – unseen by the novice user – may often speed up the interaction for theexpert user such that the system can cater to both inexperienced and experienced users.Allow users to tailor frequent actions.

4.6. Heuristic evaluation 23

Aesthetic and minimalist design

Dialogues should not contain information, which is irrelevant or rarely needed. Everyextra unit of information in a dialogue competes with the relevant units of informationand diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate theproblem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may benecessary to provide help and documentation. Any such information should be easy tosearch, focused on the user’s task, list concrete steps to be carried out, and not be toolarge.

Chapter 5

Accomplishment

In this chapter our work will be described, a schematic picture of this can be found in 5.1,starting with our pre-study. followed by an iterative prototype process, an elaborationphase and system design.

Figure 5.1: Work flow

5.1 Pre-study

The project specification that was received, consisted of a list of more or less specificfeatures and limitations and not so much of how the system would be used. Discussionswith the involved persons, the supervisor at SIB, the VP of SIB and the supervisor atUmea University lead to a more detailed specification.

During the pre-study some existing systems were evaluated for inspiration and to geta feel for some of the functions that users will expect from this kind of system. Sincemany of the payment systems available do not come with a GUI, they just come with aninterface so that the software can be integrated with web shops and other e-commercesoftware.

25

26 Chapter 5. Accomplishment

5.1.1 Identifying the target group

Through discussions with the involved persons in the project and by looking at com-petitor’s products some understanding about the appropriate target group could bedistinguished. The target group that was identified includes employees at companiesthat provide any kind of web shop to their costumers, especially those employees thathandle many small transactions during a day.

5.1.2 Identifying needs and requirements

To get a better understanding about user’s needs and requirements a questionnaire (thequestionnaire can be found in appendix B) was produced and sent to 20 companies thatprovide any kind of web shop. The aim of the questionnaire was to get informationabout the specific functions that the users required. With the requirements from SIBand the feedback from the questionnaire, a requirements specification (which can befound in appendix A) was written.

5.2 Conceptional design

With the information from the pre-study and the requirement specification (can befound in A) in mind some early GUI sketches were made to visualize possible designsdecisions. The sketches were discussed with the involved persons before a prototype wasdeveloped.

Figure 5.2: Early sketch

5.3. Low-fidelity prototype 1 27

5.3 Low-fidelity prototype 1

As stated earlier, a low-fidelity prototype is a simple but effective tool to gain early inputon designs. This early feedback prevents costly time delays later on in the project. Thefirst low-fidelity prototype (detailed images can be found in appendix D) was used forthat purpose. Five HCI-experts evaluated the system (as seen in 5.3) by performingspecific user tasks as described in sections 4.4 and 4.5. The expert findings were areminder of that it is always easy to miss obvious errors in your own system. Systemdesign is an iterative process and a second low-fidelity prototype was constructed in anattempt to eliminate the problems found in the first low-fidelity prototype.

Figure 5.3: Evaulation of paper prototype


Since paper-prototyping was the method of choice, necessary changes, made apparent bythe expert evaluation, was a rather quick operation. If a digital prototype had been thefirst prototype, hours would have been spent correcting the errors before a new prototypecould be ready for expert evaluation. During the evaluation of the second prototype(detailed images can be found in appendix E) only three experts were available, one ofthem was completely new to the CPay system (not part of the evaluation of the firstprototype)

5.5 High-fidelity prototype

After the feedback from the second low-fidelity prototype evaluation had been analyzed,the development of a high-fidelity prototype was started. The high-fidelity prototypeimplemented a fully functional user interface and was running on a temporary serverwith no real money in circulation. The high-fidelity prototype was tested on five expertusers and 10 users from the proposed target group with equal distribution between malesand females. Before the test was started the users were given the opportunity to navigatein the interface for 5-10 minutes, to get acquainted with the system. The users were


asked to perform different tasks simultaneously as they commented their experience.The user’s actions and reactions were observed using the guidelines in section 4.2 andnoted during the test. After the test the users were interviewed (see section 4.3). Theuser tasks can be found in the appendix C while the result from the test can be foundin the results chapter.

5.6 Elaborations

After the specifications had been analysed and the features more or less had been de-cided an elaboration process was initiated. The purpose of the elaboration processwas to investigate if it was possible to implement the functions that were listed in therequirements specification and how to implement them effectively.

5.6.1 XML Parsers

There are two commonly used programming models for XML document processing;Document Object Model (DOM) and Simple API for XML (SAX).

The DOM parser builds an abstract DOM tree and saves the objects in the mainmemory [27]. DOM provides access to the data through a set of interfaces that allowsan application to traverse the DOM tree beginning from the document root. SAX onthe other hand handles xml information as a single stream of data. The SAX parser isimplemented as an event-driven model which causes a series of events (such as start andend of elements) directly to the application through callbacks, as it reads the documentfrom beginning to end. [26].

DOM normally put a great strain on system resources, especially if the documentis large because the entire document tree needs to be loaded into the memory. SAXprovides simpler and lower-level access to the XML document and parses larger docu-ment faster and require less memory [26]. The two models were tested and compared,the time for parsing and generating a large xml document was considerably shorter forSAX and therefore SAX was our parser of choice.

5.6.2 PDF - JFreeReport

Different methods to generate PDF output were tested. JFreeReport was the bestsuitable choice because its simplicity to design the report layout. JFreeReport is afree Java reporting library for embedded solution with many features included. WithJFreeReport various export formats can be printed, e.g. PDF, HTML, excel and plaintext. It supports print preview features, xml based definitions, servlets and the completesource code is included. The transactions in CPay is obtained via Swings TableModelwhich makes it easy to convert the data directly in to PDF format. [25]

5.6.3 Database

SIB predicts that some users will have up to a million transactions every month. Thehuge amount of data that the application must handle made a search function necessaryand the use of a database was required. Hypersonic (HSQLDB) was chosen because it hasa powerful engine that supports data up to 8GB, has good SQL capabilities and becauseit is stable and fast. Hypersonic is an open source relational database engine written inJava with a JDBC (Java DataBase Connectivity) driver and offers both memory tables

5.7. System design with the use of CRC cards 29

and disk-based tables and supports embedded and server mode [24]. In Java 6 SE anall-Java JDBC database, Java DB (based on Apache Derby) will be included. WhenJava 6 becomes available, a migration to Java 6 and Java DB should be considered.

5.7 System design with the use of CRC cards

When the functionality of the program and the design of the interface was decidedupon, the next step was to focus on the structure of the program (which classes andmethods that should be included and their relations). The CRC technique (explainedin section 3.8.1) was used for this approach and turned out to be a great method. Thecards combined with the paper prototype was a good combination. Each frame with itsfunctionality and its components in the prototype was discussed and at the same timea card for every single class with its methods and instances was made. The cards wereplaced on a table which made it easy to make up the structure and get an overview ofhow the system should work (as shown in 5.4). It also made it easy to remove cards andmake new ones if so was necessary.

Figure 5.4: CRC cards

Chapter 6

Results

In this chapter the results from the evaluations will be presented and discussed. Solutionsto design problems, technical description and screenshots can also be found in thischapter.

6.1 Identifying needs and requirements

The process of identifying the user’s needs and requirements is crucial for creating greatapplications. If the designers do not have a clue of what the users actually want theproduct will not sell. Seven companies answered the questionnaire (which can be foundin B) with similar requirements. The result from the questionnaire can be found below.

– The most common pay systems the companies are using are PayPal and/or PayRead.Most companies also provide solution for invoice payments, Bankgiro paymentsand Plusgiro payments.

– Companies get informed when the order is paid by email, by messages from Bank-giro or Plusgiro or when they have received money at their accounts, the same dayor the same week.

– Almost every company requested a system where the payment solution and thebookkeeping were integrated which means that the companies not have to dodouble work.

– One half of the companies that answered the questionnaire required that the trans-action history must at least be saved six month back. The other half required thatthe transaction history must be saved at least one year back. Almost every com-pany required an opportunity to get the transaction history even longer back thanone year if so was necessarily, for example if there exists errors in the bookkeeping.

– Every company thought it was most interesting to see transactions in the order ofdaily, weekly, monthly to yearly. Several companies wanted the possibility to sorttransactions after the chosen time period.

– Scandinavian PC Systems (SPCS) was the most common bookkeeping program.

– Incomes and balance are the two most frequently checked posts.

31

32 Chapter 6. Results

– No company had a system where the payment solution and the bookkeeping wereintegrated.


The findings from the evaluation of the first low-fidelity prototype were a wakeup calland a reminder of how easy it is to miss obvious usability problems and how effectivea simple prototype (detailed images can be found in appendix D) like this can be. Theusability problems are listed in the following section.

6.2.1 List of usability problems

Here follows the findings from the expert evaluation of the first low-fidelity prototype

The Confirmation pop-up

– The difference between the del and clear button was confusing (three experts)

– One expert believed that ”del”, ”clear” and ”cancel” all had the same function. Anexpert suggestion was to remove the ”clear” button and make the ”zero” buttonlarger (to use the keypad metaphor).

– The placement of the ”send” and ”cancel” buttons is usually interchanged.

– The keypad and the pin field should be grouped separately from the other fields.

– Phone-layout vs. calculator-layout on the keypad seems to be a matter of opinion.

– The length of the PIN field should reflect the number of digits the PIN consistsof.

– The distinction between password, pin and read only pin is hard to grasp.

The Login Pop-up

– Show an example on the phone number format.

The Transaction tab

– One expert had a hard time to distinguish between ”send” and ”save” and thought”add” was sufficient. This might be a language issue since the prototype was inEnglish only.

– The ”save” button function is unclear, where and what does it save. Suggestion:Save to pay later as button caption.

– One expert wondered if the sent payments would show directly in the overviewtab.

– One expert tried to use the import button to view the history.

– Change ”add payment” text to: ”Add payment to” to help distinguish your ac-count from the recipients account, also change ”account” to recipient.

– Group Save and import buttons since their actions are related.

6.3. Low-fidelity prototype 2 33

The Settings Tab

– The language on the Language buttons should be in their respective language (e.g.English, Svenska).

The overview tab

– Sorting functions is requested by all users, also a possibility for selection by date.

– Option to select which transactions to print out / save to PDF.

– Unclear if the history disappears when the program is exited without saving. (Thismight be clear to the user in a digital prototype since the history is received atstart-up)

– The overview tab should look more like the transaction tab with information aboutthe user in the upper area.

– A possibility to save order by operations to a list (One expert).

– Show that sorting is possible with icons.

– Preview before printing.

– Checkboxes, does operation only affect selected items?

General

– It is hard to navigate through a paper prototype system; users feel like they areharassing the test leader since they are making him switch views for them.

– Show the account balance

– Is auto completion an option?

– Icons for know operations i.e.sorting and logotypes for file formats.

– Color-coded tabs.

– All of the experts criticized the use of three passwords (Password, PIN and RO-PIN); they are too much of a hassle for the user.


The results from the evaluation of the second low-fidelity prototype (detailed images canbe found in appendix E) were satisfying and the most of the critical usability problemshad been found, the development of a digital prototype could be initiated. The list ofusability problems for prototype 2 was notably shorter than the corresponding list forprototype 1 and can be found in the following section.


6.3.1 List of usability problems

– The passwords are still strongly disliked by all experts.

– Since tool-tips are not available in the paper prototype, this was requested as afeature.

– One expert requested more feedback when changing language.

– Saving receipts of transactions is still a problem, users confuse it with the ”save asXML” option in the payment tab. (Note: this could be related to a discrepancybetween the prototype and the use-case instruction).

– The use of a keypad to enter the 4 digit pin irritated all experts even though theyunderstood that it was used to prevent key logging.

The passwords are still a point of concern, the users do not like the password system,they get irritated but the problem is not a GUI problem. The use of the keypad forentering the pin only is an inconsistency error; the phone number and the password areentered using the keyboard but the pin must be entered using the keypad. This is aGUI related problem but the system specification demands it and it was not negotiableand neither was the password/pin/read-only PIN (RO-PIN) issue.

6.4 High-fidelity prototype

The high-fidelity prototype test gave valuable feedback and the result from the evalua-tion is listed in next section.

6.4.1 List of usability problems and design proposals

– The search function does not handle upper case letters.

– Several people did not want that the text field in the advanced search should beerased if no match was found when a search was performed.

– Not any support for quick commands.

– The data format in the advanced search should be different for English andSwedish. If the user has chosen English as language the format should be: Month,Day, Year and if the users have chosen Swedish as language the language formatshould be Day, Month, Year.

– Most users want to have a name column in the transaction history.

– One person wanted some clarification that the amount was in SEK.

– One user wanted the same date format in the transactions history table as in thecalendar in the advanced search.

– Another colour or typeface in the table headers was desired.

– It should be possible to search for a specific amount in the advanced search.

– When a user adds a payment some feedback should explain that user must sendthe payment to complete the transaction.

6.5. Presenting large amount of data 35

6.5 Presenting large amount of data

CPay must be able to handle huge amounts of data (This was a non negotiable require-ment from SIB); a worst case (by speculation) is a million transactions per month. Eventhough most companies will perform less than a million transactions, probably even lessthen 100k transactions per month, the sheer amount is a problem in many ways

– There is a memory issue, if we limit the amount of transactions handled at anygiven time to a maximum of one million transactions and the user is aware of therequirements (at least 1 GB of free ram), problems might be avoided. How canyou represent this amount of data on a computer screen? Since every transactioncan be unique categorizing is impossible except for timeframe categorizing. But ifa company has 1M transactions/month they still have more than 10k transactionsa day and how should you display this to the user?

– To make database operations more efficient, a portion of the database (e.g. amonth) is read into a more manageable temporary table. On a temporary table likethis, searches, sorting and maximum value queries can be executed in a reasonableamount of time.

– Paging is a popular option for huge search results (e.g. Google) but with 10k pagesit does not help the users if the results are not ranked in some way.

– JTables are slow when it comes to inserting and removing data. A vector with100k objects will take 10-15 seconds to insert and remove

6.5.1 A solution

To handle the memory issue and the speed issue we have limited the size of result setsreturned from the database to 5001 objects, and if the vector inserted into the JTableare larger than 5000 objects the user is made aware of this and is recommended to trythe advanced search.

The original idea of making the database more efficient with the use of a smallertemporary table turned out to be a bad idea. The memory usage doubled in the worstcase scenario and actually slowed the searches down in every case since the temporarytable first got filled with a result set that contained all objects between two time stampsand then the results were filtered out from the temporary table before they were insertedinto the table model. A better solution is to fill the result set directly with objectsmatching both the time stamp criteria and the search parameters, and then insert theresult set in the table model.

Paging was not implemented; a good search function eliminates the need for a pagingfunction.

To compensate for JTables slow insert/remove operations the iTunes style searchfilter (search results are updated for each letter typed) is replaced with a single searchwhen the enter key (or the search button) is pressed. iTunes style search filtering shouldbe implemented with the used of glazed lists in a later release of CPay.

6.6 technical description

The CPay system communicates with SIB’s servers through a protocol called TIP (TextInterface for Payments). TIP uses a secure http connection when communicating with


the servers. CPay retrieves all new transactions from the server at start-up and storesthese in the database. A simple system overview can be found in figure 6.1

Figure 6.1: System description

6.7 Interface

6.7.1 Screenshots

Overview view

When the users log in to the application the overview will appear. Information aboutthe user‘s balance, account number and the user’s transaction history is presented. Theuser can choose to show the transactions during the present day, the present week, thepresent month or all of the transactions. The users have also the option to sort in aspecific column. Note that a maximum of 5000 transactions are shown in the table. Theusers have the option to search for a specific transaction either in the quick search fieldor in the advanced search. The users can save the transaction history in PDF or XMLformat or print it directly. The overview is shown in figure 6.2

Advanced search view

If the user chose to make an advanced search, a search panel will appear and the userhave the option to search after a specific account, a specific message, a specific amountor/and withdrawals or deposits between two specific dates or any combination of these.The advanced search view is shown i figure 6.3

Confirm payments view

In the payment tab the users can send single payments or multiple payments. The usersadd the payment by enter the receivers account number, the amount of the paymentand a message that will appear in both the users account and the receivers account.To send the added payment or the added payments the users press the ”send” button.A new frame will appear where the users account number is pre entered and the user

6.7. Interface 37

must continue by entering his/her password and PIN code to confirm the payments.The password is entered with use of the keyboard and the pin code with use of thegraphical keypad. Before the transaction is completed the user’s credentials and thereceivers account are verified with the server. If the Authorization is successful thetransaction is completed at present time, otherwise an error message will appear. Theconfirm payments view is shown in figure 6.4

Print preview view

If the users choose to print the transaction history in PDF, the print prewiew wiew willappear as shown in figure 6.5.

Figure 6.2: Overview mode


Figure 6.3: Advanced search

Figure 6.4: Confirm payment

6.7. Interface 39

Figure 6.5: Print preview

Chapter 7

Conclusions

During the development process we have learned a lot. We already knew that paperprototypes were useful but the combination of paper prototypes and CRC cards was anew discovery for us. By stepping through the prototype and writing a new card foreach object needed, the program structure practically wrote itself. Due to alterationsin the project requirements during the process, the structure of the application hasbeen somewhat altered. While performing interviews we learned from our mistakes aswe went but one thing should be pointed out: some users are particularly sensitive toleading questions. When constructing instructions for test subjects we noticed that youhave to be very clear on what they should to, if they can misinterpret the task - theywill. With all this in mind, performing a pilot study with experienced test persons andtesting your interview technique and your user tasks is a good idea. The applicationfulfils the requirements (which can be found in appendix A) but what really matters tous is that the users seem to find CPay appealing and easy to use.

7.1 Constraints

Some functions in CPay have been restricted for the users, in HCI-terms this is calledconstraints. To prevent users from accidentally crashing their local database all textfields have what we call a ”char limiter”. It is a simple extension of the SimpleDocumentclass in Java that checks the contents of the text field for illegal characters and removesthem.

7.2 Future work

– Creation of a plug-in for the major bookkeeping programs (e.g. SPCS) to reducethe workload for the customers accounting personnel.

– Show the balance for the selected period of time (or search result) in the overviewtab.

– Show the balance before and after transactions are made in the payment tab.

– Users should be able to select the form of transaction e.g. Transfer money to abank account. Other types of transactions like Plusgiro and Bankgiro should alsobe an option.

41

42 Chapter 7. Conclusions

– The account owner’s name should be displayed in the history table because namesmean more to the users than account numbers.

– The ”quick search” does not include the time column in searches. A controlfunction that checks if the entered characters can be converted into TimeStampformat needs to be added.

– Since program design is an iterative process the application should be evaluatedfurther after the issues in this list have been addressed.

Chapter 8

Acknowledgements

We would like to thank the following persons (in no particular order): The staff atSIB: Frans Lundberg, Anton Lundberg, Erik Winter (our supervisor at SIB), Jan ErikMostrom (our supervisor at the department of computer science at Umea University)and of course all the experts and users who helped out with the evaluation of ourprototypes.

43

44 Chapter 8. Acknowledgements

References

[1] Inc Apple Computer. Apple human interface guidelines, 2006.

[2] R. W. Bailey. Insights from human factors international.http://www.humanfactors.com/download/jan01.asp, January 2001.

[3] Carol Barnum, Nigel Bevan, Gilbert Cockton, Jacob Nielsen, Jared Spool, andDennis Wixon. The magic number 5: is it enough for web testing. Chi 2003: newhorizons, page 698.

[4] Robert Biddle, James Noble, and Ewan Tempero. Reflections on crc cards and oodesign. ACM International Conference Proceeding Series Vol. 21, pages 201–205,2002.

[5] Barry W. Boehm. The spiral model of software development and enhancement.Computer, 21(5):61–72, May 1988.

[6] E. Boling and T. Frick. Holistic rapid prototyping for web design: Early usabilitytesting is essential. B. Khan (ed.) Web-Based Instruction. Englewood Cliffs, pages319–328, 1997.

[7] Gould, John D., and Lewis, Clayton. Designing for usability: Key principles andwhat designers think, 1985.

[8] Helen Grady. Web site design: A case study in usability testing using paper proto-types. pages 39–46, 2000.

[9] Nielsen Norman Group. Interaction design solutions for the real world, accessed on2006-12-05, 2000.

[10] Hartson, H. Rex, and Hix, Deborah. Toward empirically derived methodologies andtools for human-computer interface development. International Journal of Man-Machine Studies, 31(4):477–494, 1989.

[11] Robin Jeffries, Miller, James R., Cathleen Wharton, Uyeda, and Kathy M. Userinterface evaluation in the real world: A comparison of four techniques. In Pro-ceedings of ACM CHI’91 Conference on Human Factors in Computing Systems,Practical Design Methods, pages 119–124, 1991.

[12] Johnson, Jeff and Henderson, Austin. Conceptual models: begin by designing whatto design. interactions, 9(1):25–32, 2002.

[13] Umea universitet-Datavetenskap Marie Nordstrom, Jurgen Borstler. Objektorien-terad analys och design med crc-kort, 2002.

45

46 REFERENCES

[14] Jeanne Murray, David Schell, and Cari Willis. User centered design in action:Developing an intelligent agent application. In ACM 15th International Conferenceon Systems Documentation, pages 181–188, 1997.

[15] Jacob Nielsen. Paper versus computer implementation as mockup scenarios forheuristic evaluation. pages 315–320, 2000.

[16] Nielsen, Jakob. Finding usability problems through heuristic evaluation. In Pro-ceedings of ACM CHI’92 Conference on Human Factors in Computing Systems,Usability Walkthroughs, pages 373–380, 1992.

[17] Nielsen, Jakob. Usability inspection methods. In Proceedings of ACM CHI’95Conference on Human Factors in Computing Systems, volume 2 of Tutorials, pages377–378, 1995.

[18] Jennifer Preece, Yvonne Rogers, and Helen Sharp. Beyond human computer inter-action. 2002.

[19] James R. Rudd, Kenneth R. Stern, and Scott Isensee. Low vs. high-fidelity proto-typing debate. Interactions, 3(1):76–85, 1996.

[20] Reinhard Sefelin, Manfred Tscheligi, and Verena Giller. Paper prototyping – what isit good for?: a comparison of paper- and computer-based low-fidelity prototyping.In Proceedings of ACM CHI 2003 Conference on Human Factors in ComputingSystems, volume 2 of Short talks-Specialized section: issues in software development,pages 778–779, 2003.

[21] Andrew Taylor. It projects: sink or swim. The computer bulletin, pages 24–26,January 2000.

[22] Bor-Yuan Tsai, Simon Stobart, Norman Parrington, and J. Barrie Thompson. It-erative design and testing within the software development life cycle. SoftwareQuality Journal, 6(4):295–310, 1997.

[23] Virzi, Robert A., Sokolov, Jeffrey L., and Demetrios Karis. Usability problem iden-tification using both low- and high-fidelity prototype. In Proceedings of ACM CHI96 Conference on Human Factors in Computing Systems, volume 1 of PAPERS:Evaluation, pages 236–243, 1996.

[24] www.hsqldb.org. hsqldb.org homepage, accessed on 2006-11-23, 2006.

[25] www.jfree.org. Jfree.org homepage, accessed on 2006-11-23, 2006.

[26] www.saxproject.org. saxproject.org homepage, accessed on 2006-11-23, 2006.

[27] www.w3.org. w3.org homepage, accessed on 2006-11-23, 2000.

[28] www.w3.org. w3.org homepage, accessed on 2006-11-23, 2006.

Appendix A

Requirements specification

A.1 Technical requirements

1. CPay must be distributed as a signed Java Web Start application AND as a singleexecutable jar file.

2. All public classes, methods and fields must be documented with Javadoc sourcecomments.

3. Every package must have a corresponding package.html file that describes thepackage for developers.

4. CPay must run on any Java 1.5 virtual machine.

5. Follow ”Code Conventions for the Java Programming Language” from Sun. (Loosely)It comes with the JDK documentation from Sun. Absolute demands: 4 spaces forindentation. Capitalize class names but not variables, methods and members.Max 80 character on a line.

6. CPay must be tested on Windows XP.

7. CPay must be tested on Ubuntu Linux .

8. CPay must be able to download and store old transactions. Transactions previ-ously downloaded should not be downloaded again.

9. CPay must use an ANT build script for building it. No manual steps should beneeded to create a new version of the program.

10. CPay should be developed solely with Open Source tools available for both Win-dows and Linux. Eclipse is a good choice.

11. The installation jar file must not exceed 10 Mb and should be less than 2 Mb.

12. The development of CPay should (recommended) loosely follow the Extreme Pro-gramming approach (http://www.extremeprogramming.org/) when it comes tounit testing, and iterative development. Decide how long iteration should be. 2weeks is a reasonable choice. Anton Lundberg will function as the Extreme Pro-gramming ”customer”.

47

48 Chapter A. Requirements specification

13. Source code must use UTF-8 character encoding.

14. Source code must use Unix type for new lines.

15. The java packages should be named ”CPay.x” where x means arbitrary subpack-ages.

16. JUnit should be used for unit testing.

A.2 Features and User Experience

1. CPay should have a nice-looking GUI that is easy to use.

2. Installation of the program must be fast and easy.

3. An XML application for mass payments should be developed and used as input tobe able to make many payments from a single account.

4. An XML application should be developed that converts payment transactions inTIP form (as downloaded from SIB’s servers) to payment transactions in XMLform. This is used to easily be able to interface with other systems.

5. The user of the program should be able to create PDF-files with lists of transac-tions, so they can be printed or just stored as PDF-files.

6. The CPay user should be able to do single payments with the program.

7. The program must be self-contained when it comes to user documentation. Theuser should be able to use the program without any external documentation.

8. The program must be in English.

9. The program must use Java Internationalization with resource files for all uservisible Strings, so the program will be easy to translate to Swedish or any otherlanguage.

10. The program should cache already downloaded transactions to avoid redownload-ing same transactions many times. (Transaction cache).

11. The program should handle up to 1 million transactions per month for a computerwith 1 GB RAM.

A.3 API and code reuse

The part of the application that handles conversion between the binary transactionformat and XML and other parts that may be useful for other applications should bepossible to use separately from the rest of the program. This is done to enable codereuse.

A.4. Security 49

A.4 Security

1. The pin code of the user must under no circumstances be stored on the hard driveof the client computer.

2. The pin code should be entered with a graphical number pad to avoid key loggers.

3. The READONLY pin may however, if the user chooses so, be stored on the harddrive of the client computer.

4. The server certificate must be verified when an HTTPS or SSL connection is madeto the server.

5. The password of the user should not be stored on the computer’s harddrive.

50 Chapter A. Requirements specification

Appendix B

Questionnaire

(Translated from Swedish) HelloWe are two students at Umea University and we are performing a survey for our masterthesis in interaction technology and design. We are developing a concept for a ”paymentsystem” (i.e. an internet bank) and we are particularly interested in the usability of thesystem and what functions the users expect from this application. The concept aimstoward small and medium sized businesses.

We would appreciate if you could take some time to help us make this concept greatby answering some questions

1. Which payment system(s) do you currently use, are you satisfied with it?

2. How do you receive notification of that a specific order is paid for?

3. What functions do you expect/want from a computer based system were transac-tions are shown in real time?

4. How can a payment system that is integrated with your book keeping help outyour business?

5. How old transactions are of interest for you?

6. In what order do you like your transactions to be presented in: by day, by week,by month, by year?

7. What type of information do you check for regularly?

8. What type of book keeping system do you currently use?

9. Are your book keeping software integrated with your payment system?

Thank you for your time. /Anders Markstedt and Mikael Olofsson

51

52 Chapter B. Questionnaire

Appendix C

Evaluation of the digitalprototype

1. If you don’t have an account at betala, create one at www.betala.se (this is to gainsome background information that users will have)

2. Login using the following information:Account number: 46*********:Password: ******PIN: ****RO-PIN: *********Choose to save the system files on the desktop.

3. Get acquainted with the system and change language to Swedish, notify the ob-server when you are done.

4. Send a payment of Ten SEK to account 110, please check to se that it has beencompleted.

5. Show all transactions for: This week, today, this month

6. Search for the transaction with the following text: you were mugged

7. show all the incomes for the last two years

8. Show all purchases of coffee that has been made during November.

9. Create a PDF and save it on the desktop.

10. Print all payments that has been made this week

53

54 Chapter C. Evaluation of the digital prototype

Appendix D

Paper prototype 1

Figure D.1: Login view

Figure D.2: The main view

55

56 Chapter D. Paper prototype 1

Figure D.3: Overview view

Figure D.4: Payment view

57

Figure D.5: Confirm dialog

Figure D.6: Import view

58 Chapter D. Paper prototype 1

Figure D.7: Settings view

Appendix E

Paper prototype 2

Figure E.1: Login view

Figure E.2: Overview view

59

60 Chapter E. Paper prototype 2

Figure E.3: Payment view

Figure E.4: Confirm Payment view

Appendix F

UML

Figure F.1: Package: CPay.gui

61

62 Chapter F. UML

Figure F.2: Package: CPay.io

Figure F.3: Package: sibpub.tip.CPay

Anders Markstedt and Mikael Olofsson · 2007. 1. 29. · Anders Markstedt and Mikael Olofsson...

Documents

Transcript of Anders Markstedt and Mikael Olofsson · 2007. 1. 29. · Anders Markstedt and Mikael Olofsson...