SKATTEKORT

Sven Magne Bakken, svenmb@ifi.uio.noKristin Skeide Fuglerud, kristins@nr.no

Øivind Hagen, oivindha@ifi.uio.noHani Murad, hanim@ifi.uio.no

Ole Halvor Smylingsås, ohsmyl@gmail.com

SLUTTRAPPORT – INF5261Vår 2007

1

1 INTRODUCTION.....................................................................................................31.1 Goals for this project............................................................................................................................ 3

1.1.1 Questions to be addressed................................................................................................................... 31.1.2 Limitations......................................................................................................................................... 3

2 BACKGROUND......................................................................................................43 THE TAX CARD PROTOTYPE FOR MOBILE PHONES.......................................44 LITERATURE OVERVIEW.....................................................................................64.1 The impulse to design........................................................................................................................... 74.2 User “Understanding” – Establishing requirements...........................................................................7

4.2.1 What sort of knowledge the designer needs?.......................................................................................74.2.2 What makes good design?.................................................................................................................. 8

4.3 Is there a typical user?.......................................................................................................................... 84.4 Borderline issues................................................................................................................................... 8

5 METHOD.................................................................................................................95.1 Heuristic evaluation.............................................................................................................................. 9

5.1.1 Heuristics........................................................................................................................................... 95.1.2 Description of the evaluation process................................................................................................10

5.2 Interview and user test........................................................................................................................ 105.2.1 How will we conduct the interview?.................................................................................................105.2.2 Who will we interview?.................................................................................................................... 115.2.3 What equipment will we use?........................................................................................................... 11

6 RESULTS..............................................................................................................126.1 Results from the heuristic evaluation.................................................................................................126.2 Results from the user interview and user test....................................................................................12

6.2.1 The drop-down menu........................................................................................................................ 126.2.2 Help functionality............................................................................................................................. 136.2.3 Text, icons........................................................................................................................................ 136.2.4 The menu button and its functions....................................................................................................136.2.5 Input fields....................................................................................................................................... 146.2.6 Test of mobile vs. test of application................................................................................................146.2.7 Attitudes towards using the application.............................................................................................146.2.8 Other issues...................................................................................................................................... 14

6.3 Additional aspects to be considered...................................................................................................146.3.1 Mobile vs. Stationary........................................................................................................................ 146.3.2 Security............................................................................................................................................ 15

7 CONCLUSION AND LIMITATIONS.....................................................................168 ACKNOWLEDGMENTS.......................................................................................169 REFERENCES......................................................................................................1710 APPENDIX.........................................................................................................20Appendix A - Heuristics.................................................................................................................................. 20Appendix B – Results from heuristic evaluation............................................................................................21Appendix C – Form related to interview guide..............................................................................................29Appendix D - Interviewguide.......................................................................................................................... 30

2

1 IntroductionAs part of the strategy of producing better services for citizens, many central and local governments are beginning to offer services via a variety of service delivery channels. It is a strategic goal for the Norwegian Tax Authorities (SKD) to develop and improve the information and electronic services provided to taxpayers. By introduction of new, alternative and better public services it will be easier for taxpayers to comply with the rules that the SKD administer (Skatteetaten 2006).

In order to study and learn about different aspects of services based on mobile technology a prototype for changing tax card information has been developed. When developing the cell-phone based prototype the main focus has been on the technical solution. The users’ needs and context needs to be studied and considered in order to inform the further development of this service.

Usually, the reason for using the “Change of tax card service” is that there are changes in one or some of the information that the tax authorities have stored about a person. In the existing Internet application for changing tax cards, it is possible to make changes to a large number of entries in each taxpayer’s information base. The service has a certain workflow; including checking several numbers, changing or filling out numbers, and in addition, some data validation must be performed before the information can be sent to SKD’s information system for calculations and production of a new tax card. The calculations are done with basis in the Norwegian tax rules.

Because of the small screen size and mobile context, mobile devices are commonly not seen as suitable for presenting more than simple lists of choices, or very brief information (Buchanan et al. 2001; Massey, Khatri & Ramesh 2005). But the change of tax card service is a compound service. One central question is therefore, to what extent can carefully considered design contribute to overcome these challenges?

1.1 Goals for this projectThe goal main goal of this project is to evaluate the “Changing of tax card on mobile” prototype with regard to user interaction, and with basis in this evaluation, to come up with proposals for improvements and further work.

1.1.1 Questions to be addresseda) What are the possible advantages and disadvantages of offering this service through the mobile

channel?

b) Will the users understand the interaction techniques used in the prototype? What is good and not so good?

1.1.2 LimitationsIn the beginning of this project we got acquainted with the prototype application through a cell phone emulator on the computer. This prototype was developed by Tellu as, and they were working hard to transfer the prototype from the PC-emulator environment to function on a real mobile. The prototype was under development, but the main focus was on technical issues, such as optimalization of the communication between the mobile and server. We started out with a lot of questions, and soon found out that we had to make some delimitation, and decided to focus on the user interaction. The mobile prototype was expected to be functioning by the end of February, but it this took until the middle of April before we had a version that we could use.

The PC emulator version of the prototype was based on Sony Ericsson phones (w800i, w900), and the mobile prototype mainly worked for the newest models of Sony Ericsson mobiles. The mobile prototype was extended to function on some Nokia phones. During the project we got access to a Nokia N73 mobile phone. Therefore our results are mainly related to these two models.

3

2 BackgroundIn the western world there is a general trend towards e-Government (Wauters & Durme 2005), which is use of information and communication technology (ICT) to exchange information and services with citizens, businesses, and other arms of the government. The most important anticipated benefits of e-government include improved efficiency, convenience, and better accessibility of public services (Wikipedia 2007). The development and implementation of e-government involves consideration of its effects such as environmental, social, cultural, educational, and consumer issues. In addition it has become an important policy issue internationally to integrate as many users as possible into the Information Society, i.e. older people, people with disabilities and also people placed in “impaired environments.

64 percent of Norwegian households had access to Internet at home in 2005, while 94% of the Norwegian households had a mobile phone (SSB 2005) (Hansen-Møllerud et al. 2006). By offering electronic services for mobile phones in addition PC, these services may become accessible for more people, and for people that do not have easily access to a PC.

3 The tax card prototype for mobile phonesBased on information in a tax deduction card (hereafter called tax card), employers in Norway are obliged to deduct and withhold tax from the salary of each employee before payment of wages. The local tax assessment office issues tax cards on the basis of information regarding expected net income and net wealth. Normally, the tax card is automatically produced by the computer system of the Tax Administration and sent by mail to all potential tax payers once a year (in December).

It is then the responsibility of each individual to validate the information in the tax card. If the information is not correct, new and correct information should be reported to the local tax office, and the employee must apply for a new tax card. This can be done through several channels, by visiting the local tax office, by filling in and send a paper form, or by using the Internet service for changing tax card. Changes in the level of income, higher or lower loans, changes in family situation etc, are common reasons for appliance for a new tax card.

The employee must deliver the tax card to the employer who then updates the salary system. If he employer has not received the tax card 50 percent tax will be withheld from the salary. In the existing Internet application for changing tax cards, it is possible to make changes to a large number of entries in each taxpayer’s information base.

There are many events that may lead to changes in an individual’s tax card. Often there are several changes at the same time, and sometimes it is necessary to find and submit documentation. The web application for changing tax card has 42 possible input fields. In the tax card prototype for mobile phones a few and relatively straight forward cases that commonly lead to a change in the tax calculations were selected. The prototype runs using IP protocol over the GSM/GPRS mobile network. The application has two parts, one running as a service at a central server, and one part running on the mobile phone. Information and help messages are stored as audio (MP3), and are played by the phone’s built in MP3 player. Currently the audio files are included in the application, but there are plans to use streaming audio in future versions. In addition to reducing the size of the client application this will ease the use of several languages (Bokmål, Nynorsk, Sami and foreign) and make it easier to change the help and information of the application. As tax rules may change slightly each year it may be possible to change the information without having to change the whole application.

In the mobile tax card application, pre filled information about the tax payer is displayed. The user then has the opportunity to enter new or updated information. After the system has performed all needed checks and the user has approved that the entered information is correct, the tax calculation is initiated. Then the results are presented and the user is informed about the results and whether he/she will receive a new tax card. There are several aspects that influence the user experience and adoption of mobile services. A natural question is whether changing tax cards on a mobile phone is a good idea. In this study we will try to shed light on this question, in addition to doing an evaluation of the human computer interaction. For

4

example, due to the mobile use context and the small screen size, the way of presenting information must be considered, and also the registration process should be reconsidered in light of the input facilities of mobile devices. Below we have presented the most important interaction features of the mobile tax application.

Fig. 1. Task cards and marking of the active card.The application is organized in several task cards. The number of the active card is marked. The user navigates horizontally by using navigation buttons (arrows) or a joy stick.

Fig. 2. Elastic scroll bar showing the relative position. Within one task the information may often be more comprehensive than the size of the screen. Only vertical scrolling is possible, and the position is indicated by a scroll bar. The size of the scrollbar indicates the relative size of the visible content in contrast to the available content. Also for vertical navigation the user can apply the joystick or the navigation buttons.

Fig.3. Working area is accentuated by a frame.A focal frame shows the active area of input or output as illustrated in Figure 5. Context sensitive help, that is information related to the focal frame, is available at the bottom left soft key.

Fig. 4 Changes in the colour scheme indicate invalid input; input field containing ‘12’ and card number ‘4’.A colour scheme indicates invalid or incomplete input. The colour scheme changes (here from red to black), when the task is completed correctly. The intention is to give the user an overview of which cards are not completed, and feedback about the correctness of the input data.

5

4 Literature overview

Developing a mobile tax application offers the user an added dimension in utilizing the mobility concept. This transformation process from traditional paper- use constraint to using mostly mobile systems and applications is a reflection of modern social change.

Mobility was defined by Makimoto and Manners (1997) as being independent of geographical space. They argue that due to developments in mobile technologies, people are freed from geographical constraints. Computer Supported Cooperative Work (CSCW) shows the same social pattern of increased mobility, (Bergquist et al 1999; Fagrell et al 1999).

Makimoto and Manners also maintain that within the next decade or so, most of the facilities and tools at home and in the office will be reduced enough in size to be carried, making people” geographically independent" (Makimoto and Manners 1997). This results in mobility of technology and people as being one geographic motion, where mobile technologies are carried around with the person using it at all times.

A strong interplay is also shown between the rate of reconfigurations and interplay between old and new computing technologies, their social acceptance and the domestications of these technologies are also described by MacKenzie and Wajcman (1999), and also by Silverstone and Haddon (1996).

Being mobile doesn’t only refer to how modern people change their physical locations only but more importantly, how they interact with each other and the tasks they perform. Turkle (1995) argues that mobile system applications offer us different forms of interaction modalities and free us from contextual constraints on interaction (Silverstone and Haddon, 1996)

The various dimensions of human interaction may be described in terms of spatial, temporal and contextual mobility (Kakihara & Sorensen).

Spatial mobility (Urry, 2000) in modern society includes the mobility of objects such as walkman, ipod, mobile telephones, etc. , symbols such as network visual images and sound and then the mobility of space itself as described by the creation of “Cyber Communities” (Lury, 1997). He describes It as being a part of the required equipment of the modem 'nomad'... it expresses the high value which the culture of late-modernity places on mobility (pp. 23- 4). This leads inevitably to social abstraction from physical space (Jones, 1998) and evokes further complexity in human- human and human-machine interactions.

Bauman and Kopomaa (2000) also state that laptops, mobile phones and PDAs in particular have further energized human nomadicity in urban life, business environments and many other societal milieus (Dahlborn 2000). This gives human interactions some sort of context that relates to the actors particular cirumstances, such as the aspects of “where” and “when” do interactions take place. This was further described by Suchman (1987) as being a “coherence of situated action” that may not necessarily relate to conventional socially accepted rules or codes of behaviour thus resulting in acquired freedom from contextual constraints.

Temporal mobility on the other hand serves as a “template for organizing behaviour as well as anInterpretive framework for rendering action in the setting meaningful" (Barley 1988 p. 125). This results from rapid advances in various modern technologies and leads to acceleration of human activities and multitasking within the same framework of time (Lee and Liebenau 2000).

The mobility of electronic gadgets and information stored in such units is addressed and described by Rhodes et al (1999). They mean that “wearable systems have trouble with localised information, resource control and management between different users and multiples of users”.

For the mobile tax application it is important to be aware of privacy issues relating to stored information especially if the mobile device has many users, as in corporate sharing, or if the mobile

6

unit is lost and others get access to stored sensitive information. Contextual filtering between the wearable and the environment is one advised alternative.

4.1 The impulse to designDesigning is a creative process involving problem definition, exploration, idea generation and analysis in successive and repeated cycles where the designer utilizes his creativity for the purpose of idea selection and implementation. Design has also been described as being that area of human experience, skill and knowledge which is concerned with man’s ability to mould his environment to suit his material and spiritual needs (Archer B 1973).

Interactive design may also be described as a prescriptive process that offers us a framework to visualise how ideas develop and how the raw material can be brought together into a useable interface.

Developing a viable mobile tax application involves interactive designing of an application with the user in mind. This involves a mobile user, one who is not geographically restricted to one particular place at any one time, using a widely spread mobile device such as a mobile phone, PDA, or a small laptop.

Developing a technological design that fits into the wide array of commercially available devices offers the best of designers an astronomical challenge. especially when central issues have to be considered, like usability of the user interfaces, ergonomics and screen sizes, input menus and level of inputs and outputs, various GUI elements that reside in the handheld device. User satisfaction and different factors affecting usability are further described by Alsos and Svanæs (2006) where a strong interplay is pointed out between graphical user interface, ergonomics and screen size, personal preferences for display elements and focus shift from task at hand.

4.2 User “Understanding” – Establishing requirements

4.2.1 What sort of knowledge the designer needs?The designer needs to build a set of information sets relating to both the nature of the problem and the feasibility of a good solution. He often depends on

Knowledge derived from learning and experience as guided by his own “personal values”

The instruments and techniques available at that particular time. Limitations here are determined by the scientific information available and the philosophy associated to society and culture of the relevant time… “what is important to people”

How to combine science and philosophy to a collective technology understanding of “ how the world is “

The formal starting point for developing a new product is the “design brief” as determined by the specific client. This offers the designer problem clarifications related to finding a good solution.A design brief has to address the purpose of the design, give key details and specifications, better be accurate ( not too vague) so that the designer knows where to start, and it better not be so precise( constraining) as to limit innovation.

In interactive design, the designer usually follows four basic activities:1. Identifying needs and establishing requirements2. Developing alternative designs3. Building interactive versions of the designs4. Evaluating designs

For the mobile tax application it is essential for the interactive designers to show a good grasp and understanding of the relationship between the development of technology and the use of it. The designers often go through various stages of iterations between the physical and conceptual design following various guidelines for physical designs, such as Nielsen’s Heuristics, Styles guides: commercial and corporate, Decide “look and feel” , Widgets prescribed, e.g. screen design, balance

7

between enough information/ interaction and clarity of display icons, toolbars, menus, dialogue boxes and the use of colours.

The idea here is design to change and not design to last. This gives the product an added advantage and allows for adaptability to meet new requirements.

4.2.2 What makes good design?There is no absolute right answer in design.It is a question of being relative to what!So, assuming the product satisfies the technical specifications required , the merits of design may be relative to those involved and how do they see the product in terms of function and whether it satisfies the needs of both the producers and users or not.

Including and satisfying both criteria “it sells well” and “it works well” in the same product is often a demanding task that is difficult to achieve

4.3 Is there a typical user?In their Popular Culture: An Introductory Text, (Nachbar and Lause 1992) describe a stereotype is a standardized conception or image of a specific group of people or objects.

Developed stereotype relationships are often simpler than reality itself and they are acquired second- hand: people acquire (and absorb) stereotypes from cultural mediators rather than from their own direct experience with the groups being stereotyped.

Stereotypes are also false. Some are less false than others, since an individual is different from all other individuals by definition, stereotypes are a logical impossibility. They are also resistant to change.

Nachbar and Lause also refer to stereotypes are not merely descriptions of the way a culture views a specific group of people, but are also often prescriptions as well--thumbnail sketches of how a group of people is perceived and how members of that group perceive themselves. Stereotypes make reality easier to deal with because they simplify the complexities that make people unique, and this simplification reflects important beliefs and values as well thus encouraging people to internalize a cultural image, as their goal. Through network participation with other actors a power structure is achieved and maintained (Karasti H 2003)

4.4 Borderline issuesIn the article Borderline issues, Brown and Duguid (1994) draws attention to the importance of contextual aspects of design and use of artifacts. They argue that communities of users in different ways rely on both material and social properties of artifacts when using it. However not all properties will be important for all users. What is central for one user may be in the periphery for another user. But, when such properties are continuous and shared in a community of practice, these properties may turn into what Brown and Duguid calls border resources. Users rely on these resources for interpretation and use of the artefact. Material and social properties of an artefact may also lead the user to associate the artefact with a certain type or genre, witch in turn will contribute to their interpretation and response to that artefact. When changing from one technology or media to another, one might loose or change both material and social aspects, and thus the outcome may be unpredictable (Brown & Duguid 1994). Brown and Duguid classify their examples of borders into four headings; Engaging interpretation, Maintaining Indexicality, Transmitting Authority and Sustaining Interpretation

5 MethodThere are many different research methods, and they can be classified in various ways. The most common distinction is between qualitative and quantitative research methods (Myers 2007). The goal of our project was to evaluate the design and usability of a mobile application. It was important to

8

understand more about what important aspects of the design, and what makes the user interaction easy or difficult. We considered use of qualitative methods to be most suited for our project.

In order to shed light on possible advantages and disadvantages with offering the change of tax card service through the mobile channel, we used literature studies and interviews with some potential users. In addition to literature on guidelines and design of mobile applications, we tried to find case studies or usability evaluations of similar applications.

In order to evaluate the design and usability of the prototype, we used heuristic evaluation and user tests of the prototype application. In order to get to know the application, we did the heuristic evaluation of the prototype ourselves, before conducting the user tests. A heuristic evaluation will often lead to discovery of more local problems, and more problems totally than a user test (Molich et al. 2004), but this may depend on the experience of those conducting the evaluation (ibid.). Because of this, and because it is difficult decide the gravity of the discovered problems, the method has got some critique (Molich et al. 2004). However, usability tests with minimum 6 participants have proven to be a good and cost effective method to discover unique and significant usability problems (Dumas & Redish 1999). The two methods can therefore be seen as complementary methods (ibid.).

When doing the user test we used the “Thinking aloud” method. This is method is described in several books on usability testing (Constantine & Lockwood 2000; Dumas & Redish 1999; Nielsen 1993). The users are instructed to say out load what they are doing, thinking and feeling while they use the application. Below we explain in more detail our procedure when conducting the heuristic evaluation, interview and user test

5.1 Heuristic evaluationHeuristic evaluation is a quick, cheap and easy technique for finding usability problems in a user-interface or product. The technique is developed by Jacob Nielsen and his colleagues. By using a predefined set of rules or “heuristics”, a small set of evaluators examines and judge the product based upon these rules.

The heuristics are typically looking much like well-known high-level design principles, but often they must be adjusted to the particular application or product to be evaluated.

Heuristic evaluation can be done by a single evaluator, but as different persons tend to find different problems, this is by no means optimal. Nielsen (1994) has shown that normally will 5 persons be sufficient to find 75 % of the usability problems in an application.

The heuristic evaluation can be seen as a process of three stages. First the heuristics are made and the evaluators are told what to do. Then the evaluators independently inspect the application using the heuristics as their guideline. Normally the interface will be inspected more than once, as there are no rush or time pressure during the evaluation. When the individual evaluations are done, the participants come together to discuss their findings. The problems are listed and the group tries to come up with solutions to the problems.

5.1.1 Heuristics

Based on Nielsen’s work, Rogers, Sharp and Preece (2002) list some questions to be addressed when doing an evaluation;

H1 Visibility of system statusAre users kept informed about what is going on?Is appropriate feedback provided within reasonable time about a user’s action?

H2 Match between system and the real worldIs the language used at the interface simple?Are the words, phrases and concepts used familiar to the user?

H3 User control and freedom

9

Are there ways of allowing users to easily escape from places they unexpectedly find them self in?

H4 Consistency and standardsAre the ways of performing similar actions consistent?

H5 Help users recognize, diagnose, and recover form errorsAre errors messages helpful?Do they use plain language to describe the nature of the problem and suggest a way of solving it?

H6 Error preventionIs it easy to make errors?If this is so why?

H7 Recognition rather than recallAre objects, actions and options always visible?

H8 Flexibility and efficient of useHave accelerators been provided that allow more experienced users to carry out task more quickly?

H9 Aesthetic and minimalist designIs any unnecessary or irrelevant information provided?

H10 Help and documentationIs help information provided that can be easily searched and easily followed?

These heuristics are rather high-level design guidelines and are not tailored especially for mobile devices. Nevertheless, they represent well-known principles of good usability design and the results from the evaluation showed that the use of these heuristics was valuable as we found a lot of weaknesses in the design. There are guidelines for mobile devices, like the WC3 Mobile Web Best Practices 1.0 (http://www.w3.org/TR/mobile-bp/), but these are meant for showing web content and did not seem so relevant for our stand-alone application.

5.1.2 Description of the evaluation processBefore the evaluation started we had a meeting choosing heuristics and planning how to do the evaluation. We chose the heuristics listed by Rogers, Sharp and Preece (2002).

Having chosen the heuristics, all 5 group members did the evaluation separately using the same mobile device, a Nokia N73. None of the evaluators were familiar to this particular mobile phone before the testing started. Every usability problem according to the heuristics was written down along with an explanation on why this was considered a problem.

After the individual testing we had a meeting gathering all information in a single document. By putting all results in a diagram we could see how different evaluators found different usability problems. By looking at the number of evaluators who found a given fault, we may also say something about how “easy” it was to discover the particular fault. For every finding we discussed why this particular fault could be considered a problem according to the heuristics, we then tried to come up with a suggestion on how to improve the design.

5.2 Interview and user test

5.2.1 How will we conduct the interview?The interview will be done as part of a qualitative survey. We will also observe the participants as they walk through the application while using the “Thinking aloud method”. There will not be many participants, as the survey will take about 20 minutes pr. participant. After the survey, the participants are granted a chocolate bar and a lottery ticket as a token of our gratitude.Before the survey, the participants must sign an agreement so that we can use their answers without ending up with legal issues. The agreement states that the participation is out of free will and that the survey is anonymous. It also contains a short description of the work we are doing in this project.

10

We will follow an interview guide during the survey (See appendix D). This guide contains guidelines for the user test, questions and so on. We will do some modifications after the Heuristic evaluation. This improvement is necessary because we do not know if all the questions that we have prepared are relevant before we have access to the version of the mobile application that we will be testing. The questions we will ask are about the user’s background (personalia, education and work experience), the users experience with computers and cell phones, their knowledge about tax cards and an open “how do you feel about the tax card application” question that we will ask after the user test.

One of the big questions we want the participants to answer is if they would like to alter their tax cards on the cell phone in the future. This is central if the cell phone is going to be the new “place” to change the tax card (Aagre 2001). The altering of tax cards has changed place once before. It used to be in the tax office, now it is getting popular to do this on the web. The cell phone might just be the new place.

5.2.2 Who will we interview?The Skattekort – application which is meant to be used by everyone who owns a new mobile telephone.

We will focus on young people, preferably around 20 years old. We believe that younger people in general are more interested in new technology. At the same time, 20 year olds mostly have some experience with tax cards. They are also likely to have a newer cell phone, and thus might be familiar to more advanced interfaces.

We also think that 14-15 year olds might be even more interested in technology (and have more spare time to play around with it), but might not have experience with tax cards or the required economy to buy an advanced cell phone. Interviewing people under the age of 18 would also require the parent’s signature and acceptance. This we want to avoid because of time constraints.

We have contacted Sogn Vidregående Skole, and they have given us permission to interview some of the students. If we are unable to find enough participants there, we will try to find some more other places. We hope to find three boys and three girls in order to get several male and female perspectives.

5.2.3 What equipment will we use?We will buy a cell phone compatible with the mobile application, and also get a «tvilling-SIM» subscription. One of the two SIM cards will be put in the cell phone we buy. Then people who have cell phones that don’t support the application can use this cell phone. If the people we ask actually have a cell phone that supports the application, then they can put the other SIM card in their cell phone and download the application through this (so that they do not have to pay for downloading).

We will also use a sound recorder to record whatever the person we interview says. Other than that, we will use a notebook and a pen to write down the results.

11

6 Results

6.1 Results from the heuristic evaluationThe heuristic evaluation resulted in a listing of the different faults or weaknesses in the design, 31 all together. Some of the faults were found by all evaluators, while others were found by only one or more. The usability issues ranged from small problems to functionality making the application almost impossible to use.

The most serious problems concerned inconsistency in the navigation system, use of technical and imprecise language, and the lack of help and documentation. A complete set of results from the heuristic evaluation is listed in appendix B. The document holds a listing of the usability problems revealed, information on which evaluators who found them, and a suggested solution to the problem.

As stated previously, about 75% of the usability problems will be discovered during a heuristic evaluation with 5 participants, meaning there are still usability problems in the design not found by the heuristic evaluation. At the same time, not all problems found during a heuristic evaluation will be considered problems by the users.

A critical part of the evaluation is the choice of heuristics. As discussed earlier, the heuristics used are not tailored particularly for a mobile application but are still relevant as principles of good usability design. By using a set of heuristics less general, maybe the evaluation of the design would turn out even more effective. The quality and relevance of the heuristics obviously affects the number of problems found during the evaluation.

The heuristics are meant to assure good usability, but we can not rely on these alone. To get a more complete understanding of the usability problems in the design, we also tested the application on real users.

6.2 Results from the user interview and user testWe didn't get as many participants as we wanted for the interview. We only got three boys and two girls. The survey did however yield a great deal of feedback.

6.2.1 The drop-down menu

There were some issues about the use of drop-down menus. First of all, when the program starts, the user is supposed to select a form from a drop down list, then push the menu button, then select “Hent skjema” from this menu. All the participants spent a lot of time trying to figure this out. Most of them needed help. This is not a smooth solution. A simple button for each form would have worked. The drop down list might still be OK if there was a “Hent skjema” button on the screen (as it would have been in a web application) in stead of inside the menu.

The startup screen might also have confused the users by giving them a wrong impression of the use of drop-down menus. When they arrived at the second tab inside the “Forskudds skatt” form, they were supposed to select the reason why they wanted to change their tax card. After selecting the reason from the drop-down menu, they expected to be taken to a specific form just like when they started the application. Inconsistent use undoubtedly disrupts the learning process of the users.

12

6.2.2 Help functionality

None of the participants tried to find help functionality. When we tried to show them the audible help, one of the participants said that he didn't need it, and moved on without trying it.

All of the participants did however want more help about the input fields. The help functionality related to each field was hidden inside an icon based menu that appeared when the field was double clicked. Hidden help functionality is hard to find. Additionally, one can not get help to find it. In addition, double clicking is not something users on the cell phone are used to. This might however change in the future. The participants might have used both audible and text based help if the icons were not hidden.

Once the help functionality related to fields was found (we made them search for it and gave them some guidance), some help text was displayed. When trying to scroll down this help text, the user was simply thrown out of the help text into the next input field. The scrolling of help text didn't work.

6.2.3 Text, icons

The participants said that the size of the text was good. They instantly figured out how to scroll it, and didn't mind doing this. They were probably used to scrolling from SMS messages, which has a quite similar interface.

The icon menu (slightly described above) needs some improvement. Most users understood the erase and information icons. The other icons made no sense. One of the participants said that she would like to have text that gave a hint about the highlighted icons functionality. Another said that he would simply try them out. The icons should be a bit bigger in any case.

6.2.4 The menu button and its functionsIn order to apply for a new tax card the users have to evaluate the form, and then send it in. These two functions are separated into “Evaluer” and “Send skjema”. Fair enough, sometimes you might want to evaluate the form without sending it in. But still, when you want to send it in, you will always have to evaluate it first. The send function should contain the evaluate function as part of its procedure. And none of these functions should be placed inside the menu. They should be placed inside the “Evaluate and send” tab as buttons, just as with the “Hent skjema” function described in the drop-down menu sub chapter above.

“Evaluate” is not a good word by the way, it would be better to call it “Check form correctness” or something like this. (Yes, this would be longer and take up more space on the screen, but it is better than using less space and make no sense).

13

This is not the only bad thing about the menu. Sometimes the menu button showed the menu, but the menu wasn't active (nothing could be selected). This is clearly a bug. The menu became active if it got closed and reopened.

6.2.5 Input fieldsAs mentioned under the “Help functionality” sub chapter, the participants didn't always understand the names of the fields. In the second tab, where they are supposed to describe why they want to change their tax card, they choose «Income» from the drop-down list, and write what they think they will earn. They should in stead write why their income changes. The form doesn't make this clear.

There was also some issues about what measurements the fields used. If the user was asked how much tax he/she has payed, the user often answered in percents, not NOK. They also did not understand if fields of this type was asking for «tax so far in NOK», «tax pr. month» or «tax pr. year». The headers of the fields needs to be more descriptive.

When trying to go back and forth within an input field, the user is simply moved between the tabs. This can be very annoying.

6.2.6 Test of mobile vs. test of applicationSince our application only runs on new Sony Erickson and Nokia mobile phones, we were a bit worried because if the user does not have the right phone he or she can not try the application on their own phone. Our thought were that if the user owned a suitable phone (ie new Nokia or Ericsson phone), our SIM – card could be inserted, and the application could be used with no cost for the user. However, the application could not run on any of the participants phones; instead they had to try it out on the project phone. A potential pitfall is, as mentioned, whether it will be a test of a new mobile phone or a test of a new mobile phone application? Our focus was to test the tax card application.

One of the test users mentioned that it was a bit difficult to use a new phone, but overall it seemed not to have very much effect on the test users.

6.2.7 Attitudes towards using the applicationAlthough most of the users spent some time figuring out how to use the application, they all seemed to understand how to get around after a while. They even liked the application, and said they would prefer this way of altering their tax card. Although our survey is quite small, and might not be representative for the general public, this is good news when it comes to answering the question about changing place for altering the tax card.

Some of the users said that although the program was hard to use, they would just play around with it until they understood what was going on. Still, one might not want to play around with the program to get a real tax card. The fear of doing something wrong and get unknown consequences might send a real user to the tax office or web in order to get the help and explanation needed.

6.2.8 Other issuesWhile interviewing one of the girls, the application didn't start at all. This particular interview was done a few days after the other interviews, so the server might have been down at that particular time. But still, there should have been an error message telling us why the program didn't start.All of the users went back and forth a lot. They didn't simply go through the form from left to right in one turn. They didn't seem to think of this as a problem though. They were simply playing around to get to know the application.

The program exited when the red «Hang up» button on the phone was pressed. This does not seem to be related to the program, but rather the cell phone itself. Can the application intercept this? A yes/no box displaying “Are you sure you want to exit the application?” would remove a lot of irritation around this issue.

The users who stumbled upon errors understood the red tabs and the red squares indicating the fields with erroneous input. The navigation from tab to tab was also intuitive.

14

6.3 Additional aspects to be considered

6.3.1 Mobile vs. StationaryMany wonder whether this application is useful. Since we are moving away from the desktop computer, SKD wanted to do some research related to mobile applications. Through the “Change of tax card” prototype for mobiles, it is proven that technically it is possible to implement this application on a mobile phone.

In section 4.4 we presented some concepts from the article on Borderline issues by (Brown & Duguid 1994) because we think this will be a fruitful when analysing the tax card prototype. Can we identify any border recourses in relation to the tax card service, and if so, how could these border resources be supported in the tax card service for mobile phones?

Brown and Duguid (1994) illustrate how changing the artefacts, such as introduction of a new medium, may affect the border recourses of the artefact. Changing the tax card service from a paper based or a web-based service, to a mobile service may affect the user’s interpretation of that service. The mobile channel may represent another genre or type for the user. This may affect the perceived authority of the service. A mobile application may be interpreted as less formal than the traditional services based on paper or web, and thus affect both the users trust and willingness to use it, and possible the users earnestness if using it. Being aware of this, one may intentionally use design elements to reinforce authority clues. Such design elements may be logos, and language to try to keep or transmit some of the formality and authority of the service, and also security measures.

One argument for offering this mobile application is the efficiency aspect, in which the user might utilise any spare time, such as while waiting or travelling for doing the task. However the mobile use context may also lead to unplanned and frequent interruptions. May be the bus is coming or the user meets a friend. This means that it must be easy to continue with the task if interrupted.

A problem is that the user might need information from information sources not necessarily accessible from anywhere or from the mobile. Examples of this may be documents from the employer about salary, or documents from the bank about current fortune, loans or interests etc. or documents from the tax authorities with authorisation information (pin codes etc). Therefore the user might not be able to accomplish the task until s/he has got access to this information. On the other hand, having access to the service on the mobile means that the user might continue with the task as soon as s/he gets this information (eg when s/he comes home or at work). Thus this is also an argument for making it easy to continue with the task another time. This means that the application should remember what has been done, and possible also were the user left it.

Will the mobile tax card application be adopted? All the users were positive to use the mobile tax card application in the future. However, when asked about their use of mobile applications in general, they told us that they preferred to use a PC for more advanced tasks, like e-mail, ordering of tickets etc.

It is very difficult to anticipate the adaptation of technology. No one would think that the Amish would adopt the cellular phone and maybe today’s teenagers actually finds this application useful and prefers to change their tax card on their cellular phone instead of on their computer because they got all the information they need on their mobile.

6.3.2 SecurityIt is not implemented any security solutions in the application yet. Since this means among other things to implement check on peoples personal identification number and that would make the application very inefficient to test.

The security issue is an interesting field when it comes to the discussion mobile versus stationary. The mobile is in a way connected to its owner. Only the owner knows the mobiles PIN – code and maybe that could be use to identify you when you try to sign in to applications that require you to log in. This is of course just a thought, and walking around with personal information in your pocket is not, I suppose an ideal thing to do at least not today. The stationary solution got more security because it is

15

located back home, but when you think about it, you got all your identification numbers and access codes your shelf. Is that really secure?

7 Conclusion and limitations

Developing a viable mobile tax card application offers the best of designers and developers a huge challenge with respect to satisfying user needs and requirements, technological possibilities and limitations, ethical and security issues with respect to data flow and transfer of sensitive information and to market needs and social developments with respect to accepting and adopting new applications.

With respect to our addressed question number one, our survey points out that our test groups was positive to added mobile applications that synchronize well with their mobile life-style. This removes any geographical limitations from the possibility of using a mobile tax application, leaving them more time at their disposal for other use, such as leisure. This satisfies efficiency aspects that users might demand.

The widespread use of such an application is augmented by the fact that almost everyone has a mobile telephone available at all times, whereas not everyone has a PC.

General use of this tax application is however hampered by the lack of unified standards with respect telephone types, membership to different server suppliers, etc. The application requires that the user has a modern telephone with modern system utilities, otherwise it will not function. This would probably limit the target user group.

General interface limitations due to size of screens, information relay and output systems, etc reduce the limitless flow of information to the user.

With respect to our addressed question number two, we conclude that the there are many usability issues in this tax application that must be addressed. Some of the interaction techniques are rather cumbersome and not very intuitive at all. The language used is rather technical and the flow procedure from one level to a subsequent level is not always problem free. The system blocks often and the user must re-open the program and start from scratch due to instability and incompleteness.

Our study was limited by the choice of a limited user group, young people from 17-21 years old, and the tested group was far too few to allow for general assumptions and validations of results. This reduces the significance of our results and conclusions.

We were also limited in our testing by the fact that the prototype used was incomplete and full functionality was not available. Delays from prototype developers were difficult to accommodate at all times.

The time allocated for this project was also very limited and put some restraints on our strategy for fulfilling our originally desired test criteria.

Security issues and safety with respect to privacy have to be guaranteed such that the user will not fear spread of private information to others.

As a general conclusion, we acknowledge that the mobile tax application is an interesting application that may appeal to mobile users provided that the language used is made simpler and the user interface is made more intuitive. However, the tax return system is complex by nature and developing a mobile application that allows for ease of use requires careful study of the whole process. For example, at any one time the user might not have all available information and numbers to be altered at his or her disposal and the available application doesn’t allow the user to free access of stored tax data in the data base. We think these issues should be studied further.

16

8 AcknowledgmentsThe “Change of tax card prototype” has been developed within the project Norwegian OSIRIS, with contributions from the project “Universal design in Norwegian OSIRIS”. These projects have financial contributions from the Research Council of Norway. Norwegian OSIRIS witch is lead by IKT Norge is part of the international ITEA OSIRIS project (www.itea-osiris.org). We want to thank the participants in these projects for the access to the prototype and written material and reports related to this. Special thanks to Tellu AS (www.tellu.no) which has developed the prototype, to Karde AS for input and access to reports (www.karde.no), to NR for lending us equipment for user testing (mobile and dictaphone), and to the peer-review group Opera for a very thorough and constructive review.

9 ReferencesArcher,B (1973): “The Need for Design Education”. Royal College of Art

Aagre, Philip E. (2001): “Changing Places: Contexts of Awareness in Computing”. Human-Computer Interacion Vol. 16, pp 177-192. Copyright © Lawrence Erlbaum Associates, Inc.

Barley, S.R. (1988): “On Technology, Time, and Social Order: Technically Induced Change in the Temporal Organization of Radiological Work”. In Making Time: Ethnographies of High-Technology Organizations. F.A. Dubinskas ed. Philadelphia, PA: Temple University Press

Bauman, Z. (2000): “Liquid Modernity”. Cambridge: Polity Press

Bergquist, J., P. Dahlberg, F. Ljungberg, and S. Kristoffersen (1999): “Moving Out of the Meeting Room: Exploring Support for Mobile Meetings”. In Proceedings of The 6th European Conference on Computer Supported Cooperative Work (ECSCW '99), Copenhagen, Denmark, 12th-16th September 1999.

Brown, J. S. & Duguid, P. (1994): “Borderline Issues: Social and material aspects of design”. Human-computer interaction, Lawrence Erlbaum Associates, Inc, 9: 3-36.

Buchanan, G., Farrant, S., Jones, M., Thimbleby, H., Marsden, G. & Pazzani, M. (2001): “Improving mobile internet usability”. Proceedings of the 10th international conference on World Wide Web. Hong Kong, Hong Kong, ACM Press. 673-680 p.

Constantine, L. L. & Lockwood, L. A. D. (2000): “Software for Use: A practical Guide to the Models and Methods of Usage Centered Design”. Addison-Wesley. 579 p.

Dumas, J. S. & Redish, J. C. (1999): “A practical guide to usability testing”, Revised edition ed. Exeter, Intellect Books. 404 p.

Dahlborn, B. (2000): “Networking: From Infrastructure to Networking”. In Planet Internet. K. Braa, C. Sorensen, and B. Dahlbom eds., Lund: Studentlitteratur, pp. 217-238.

Deleuze, G. and F. Guattari (1986): “Nomadology”. New York, NY: Semiotext(e).

EC. (1995-2007a): “Design for All (DfA)”. Europe's Information Society Thematic Portal, The European Commission. Accessed April 2007 on World Wide Web: http://ec.europa.eu/information_society/policy/accessibility/deploy/dfa/index_en.htm.

EC. (1995-2007b): “Inclusion, better public services and quality of life”. Europe's Information Society Portal, The European Commision. Accessed April 2007 on World Wide Web: http://ec.europa.eu/information_society/eeurope/i2010/inclusion/index_en.htm.

EC. (2005): “i2010 - A European Information Society for growth and employment”. Communication from the Commission to the Council, the European Parliament, the European Economic and Social

17

Committee and The Committee of the Regions,, COM(2005) 229 final, Commission of the European Communities,. 12 p. Accessed 01.06.2005 on World Wide Web: http://europa.eu.int/information_society/eeurope/i2010/docs/communications/com_229_i2010_310505_fv_en.pdf.

EU. (2003): “eAccessibility - improving the access of people with disabilities to the knowledge based society”. Official Journal of the European Union COUNCIL

Fagrell, H., F. Ljungberg, and S. Kristoffersen (1999): “Exploring Support for Knowledge Management in Mobile Work”. In Proceedings of The 6th European Conference on Computer Supported Cooperative Work (ECSCW '99), Copenhagen, Denmark, 12th-16th, September 1999

Jones, S.G. (1998): “Information, Internet, and Community: Notes Towards an Understanding of Community in the Information Age”. In CyberSociety 2. O: Revisiting Computer-Mediated Communication and Community. S.G. Jones ed. Thousand Oaks, CA: Sage Publications, pp. 1-34.

Kakihara, M , Srensen, M (2002):”Mobility”. Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS'02)-Volume 5, p.131, January 07-10, 2002

Kopomaa, T. (2000): “The City in Your Pocket: Birth of the Mobile Information Society”. Helsinki: Gaudeamus.

Lee, H. and J. Liebenau (2000): “Temporal Effects of Information Systems on Business Processes: Focusing on the Dimensions of Temporality”. Accounting, ManagementAnd lnformation Technologies, vol.10, no.3, pp. 157-185.

Lovdata. (2006): ”Lov om endringer i lov 16. juli 1999 nr. 69 om offentlige anskaffelser”. Accessed 6 April 2007 on World Wide Web: http://www.lovdata.no/cgi-wift/ldles?doc=/all/nl-20060630-041.html.

Lury, C. (1997): “The Objects of Travel”. In Touring Cultures. C. Rojek and J. Urry eds., London: Routledge.

MacKenzie, D.A. and J. Wajcman eds. (1999): “The Social Shaping of Technology (2nd edition)”. Buckingham: Open University Press

Makimoto, T. and D. Manners (1997): “Digital Nomad”. Chichester: John Wiley & Sons.

Massey, A. P., Khatri, V. & Ramesh, V. (2005): “From the Web to the Wireless Web: Technology Readiness and Usability”. Proceedings of the Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS'05) - Track 1 - Volume 01, IEEE Computer Society. 32.2 p.

Molich, R., Ede, M. R., Kaasgaard, K. & Karyukin, B. (2004): “Comparative usability evaluation”. Behav. Inf. Tech., 23 (1): 65-74.

Myers, M. D. (2007): “Qualitative Research in Information Systems”. MIS Quarterly (2): 241-242. MISQ Discovery, updated version, last modified: Januray 09, 2007.Accessed 4. February 2007 on World Wide Web: http://www.qual.auckland.ac.nz/#Citation%20Information.

Nachbar Jack, Lause Kevin (1992) “Popular Culture: An Introductory Text”. 236-244 p.

Nielsen, J. (1993): “Usability Engineering”. AP Professional. 362 p.

Nielsen, J. (2005): “Heuristic Evaluation”. Accessed March 2007 on World Wide Web: http://www.useit.com/papers/heuristic/.

Nielsen J. (1994): “How to Conduct a Heuristic Evaluation”

18

RESOLUTION on 6 February 2003 Accessed April 2007 on World Wide Web: http://europa.eu.int/eur-lex/pri/en/oj/dat/2003/c_039/c_03920030218en00050007.pdf.

Rheingold (2001): “Look who's talking”. Wired magazine 7-01.http://folk.uio.no/oivindha/skattekort/artikler/rheingold.pdf

Rhodes BJ, Minar N and Weaver J (1999): “Wearable Computing Meets UbiquitousComputing: reaping the best of both worlds”. Symposium on wearablecomputing. http://ieeexplore.ieee.org/iel5/6542/17464/00806695.pdf?isnumber=&arnumber=806695

Rogers, Yvonne, Sharp, Helen and Preece, Jeniffer. (2002): “Interaction Design: beyond human-computer interaction”, 2. utgave. Wiley . ISBN: 0-470-01866-6

Silverstone, R. and L. Haddon (1996): “Design and the Domestication of Information and Communication Technologies: Technical Change and Everyday Life”. InCommunication by Design: The Politics of Information and Communication Technologies. R. Mansell and R. Silverstone eds., Oxford: Oxford University Press, pp. 44- 74

Skatteetaten. (2006): “The Norwegian Tax Administration, Annual Report for 2005”. Skatteetaten. Accessed on World Wide Web: http://www.skatteetaten.no/upload/Annual%20report%202005.pdf.

Suchman, L.A. (1987): “Plans and Situated Actions: The Problem of Human-Machine Communication.” Cambridge: Cambridge University Press.

Turkle, S. (1995): “Life on the Screen: Identity in the Age of the Internet”. New York, NY: Simon & Schuster.

Urry, J. (2000): “Sociology beyond Societies: Mobilities for the Twenty-First Century”. London: Routledge.

Wauters, P. & Durme, P. V. (2005): “Online availability of public services: How is Europe progressing?”, Prepared by: Capgemini For: European Commission Directorate General for Information Society and Media,. 67 p. Accessed 4. March 2005 on World Wide Web: http://ec.europa.eu/information_society/eeurope/2005/doc/all_about/online_5th_measurement_fv4.pdf.

19

10 Appendix

Appendix A - HeuristicsAll heuristics are listed in (Rogers, Sharp and Preece)

H1 Visibility of system status Are users kept informed about what is going on? Is appropriate feedback provided within reasonable time about a user’s action?

H2 Match between system and the real world Is the language used at the interface simple? Are the words, phrases and concepts used familiar to the user?

H3 User control and freedom Are there ways of allowing users to easily escape from places they unexpectedly find

them self in?H4 Consistency and standards

Are the ways of performing similar actions consistent?

H5 Help users recognize, diagnose, and recover form errors Are errors messages helpful? Do they use plain language to describe the nature of the problem and suggest a way

of solving it?H6 Error prevention

Is it easy to make errors? If this is so why?

H7 Recognition rather than recall Are objects, actions and options always visible?

H8 Flexibility and efficient of use Have accelerators been provided that allow more experienced users to carry out task

more quickly?H9 Aesthetic and minimalist design

Is any unnecessary or irrelevant information provided?H10 Help and documentation

Is help information provided that can be easily searched and easily followed?

20

Appendix B – Results from heuristic evaluationWhere in the application the problem occurred

Description of the problem

Evaluators and heuristics Suggested solution1 2 3 4 5

Start up It takes time to load the program, no feedback

H1 Message like “Loading, please wait”.

Sometimes the program ends without any error messages

H5 Error handling should at least inform the user.

First screen: The first screen contains severalWords or expressions that might be unfamiliar and technical for the user:

“skjema klient” (form client)

“SELECT tasten” (The SELECT button). There is no select button in the menu.

“nedtrekksliste”(Pull down menu).

H2 H2 H2 Try to make the language more non-technical. Offer more information if needed.

First screen:It is very cumbersome to select and fetch the form. You have to open the “Meny” (menu) with the LSK, and then press “Hent skjema” (fetch form) with the “Select button” on the phone.

H8 H8 H8 H8 H8 Maybe this can be done by simply pushing one out of two buttons to the service?

21

Page 1 Proper authentication is not implemented in the prototype, and therefore you get a message that you are logged on as an anonymous user.

The authentication mechanism will clearly be a critical point in such a service.

The two choices “Evaluer” (Evaluate) and “Send skjema” in the menu are only available on the last page (tab). This might be and indirect way of telling the user that the form should be evaluated and send. We are not sure that this is a good solution.

H4

Page/tab 2 The use of “nedtrekksliste” (drop down menu), marked with yellow in the picture, may be misleading. How do you press the arrow to the right? Is it obvious that you have to press the “select button” to open a list of choices?

H1 H3 This interaction form is best suited for direct manipulation such as mouse or pen. You cannot manipulate the scrollbar directly. Show buttons

Page/tab 2 “Type endring”, (type of change) makes use of a “nedtrekksliste” (drop down menu) with several choices. This is indicated by the yellow color and the little down-arrow to the right. Drop down menus are commonly used on PC’s, but how do you press the arrow to the right? Is it obvious that you have to press the “select button” to open the list of choices?

H1 H3 This interaction form is best suited for direct manipulation such as mouse or pen. You cannot manipulate the scrollbar directly. Show buttons

Under “Meny”, hard to see if it is “Hent skjema” that is highlighted or if it is “Help”

H1 More obvious highlighting?

22

Page/tab 2 One of the choices in the drop down list is “Gjenlevende partner”. (Surviving partner). This phrase was perceived as misleading.

What is BSU,? Not everybody is familiar with this terminology

Also the “Beskriv grunn”(Describe the reason) field might be misleading. The reason for what? Has it to do with changing one parameter to another, or does it reefer to the overall reason for change of tax card.

H2 H2 H2 H2

Page/tab 3 In this picture the “Brutto lønn til nå” field is active. When pressing the select button, a submenu will appear. But it is not intuitive to go from the menu to the submenu. Users will not necessarily press the “Select button” in this field, and thus they will not necessarily find the submenu.

H7 H7 Positive that you can get help for each field.When you first know about this sub-menu it is easy to use.

More investigations into icons are required.

23

Page/tab 3 – Submenu When pressing “Hjelp”

(help), you get a help text below the field, but no explanation of the icons in the submenu. It is also possible to press the menu, but it does not seem to be relevant.

It is not very easy to recognize/understand the icons in the submenu. The first green icon looks like a play button 90 degrees tilted. This is used to open and shut the submenu. The next icon, a delete icon looks like backspace, ie deletion of one single character, but it deletes all the characters in the field. The information button is OK, but information is not implemented. The last button is play sound, but there is no sound.

H7 H7 Use something similar to tool-tips.

Not possible to see which of the two red tabs that is active.

Make the active tab larger than the other tabs.

Arrow showing progression could be useful.

Make use of more colors.

24

Hjelp brukergrensesnitt

Selecting “Hjelp” in the menu, gives a new screen with help text: Hjelp bruker grensesnitt

The help text is using words like “piltaster” (arrow buttons). Not all telephones have arrow buttons. This might be confusing when the phone only has a joystick.

Also the word “Fanene” (the tabs) might be too technical or unfamiliar.

H5 H5 H5 Use a more generic language.

Page 6 / BSU Not implemented or active/relevant. However, for many users the term BSU might not be familiar.

H8

25

Page 7The text does not inform you that you have to evaluate and send. You have to go through the whole setup before you discover that it is not evaluated.

H1 H1 H1 H1 H1Change the text.Select evaluate from the menu, and then send form.

Velg evaluer skjema i menyen og deretter send skjema.

Page/tab 7 Since evaluate and send form is only used in this screen it would be better to only show this in the last screen.

H4The form should be automatically evaluated without the need for selecting this from a menu.

Users will not necessarily find this submenu. Not intuitive to go from the menu to the submenu.

H7 H7 Positive that you can get help for each field.When you first know about this sub-menu it is easy to use, but it is not obvious how to enter this menu.

More investigations into icons are required.

Need for explanation of the icons, and possible better icons. Eg. it is not easy to recognize the last icon. Green icon looks like a play button 90 degrees tilted. The delete icon looks like backspace, ie deletion of one single character, but it deletes all the characters in the field

H7 H7 H7

Use something similar to tool-tips.

26

Not possible to see which of the two red tabs that is active.

Make the active tab larger than the other tabs.

Arrow showing progression could be useful.

Make use of more colors.

BSU Not active/relevant H8The text does not inform you that you have to evaluate and send. You have to go through the whole setup before you discover that it is not evaluated.

H1 H1 H1 H1

H1

Change the text.Select evaluate from the menu, and then send form. Consider moving “Evaluer” and ”Send skjema” from the menu to simply two buttons located on the last “page”.

Page/tab 7 Since evaluate and send form is only used in this screen it would be better to only show this in the last screen.

“Hent skjema”, ”Evaluer skjema” and ”Send skjema” is located under the Menu, even though they are only to be used at one place in the program. Confusing and inconsequent.

H4 H4

The form should be automatically evaluated without the need for selecting this from a menu.

Or: Implement these features as buttons on the pages they are to be used.

Page/tab 7 There is no heading on this page.

H4 Name the page

Page/tab 7 After sending, last page.

The program is finished, but there is no way to end the program.

H3 Some way of terminating the application, confirming the user that she has changed her skattekort.

27

After sending, last page

The program is finished, but there is no way to end the program.

H3 Some way of terminating the application, confirming the user that she has changed her skattekort.

General problems When pushing the exit button on the telephone, the program is immediately terminated without asking if the user really wants to do so.

H6 H6

Some kind of message/choice to not terminate the program.

The redo-button restarts the whole application instead of the last ting changed (as expected).

H6 H3 H6

Change this feature to change only the last ting done.

Not intuitive to see that one is finished with one phase and need to move to the next

H6 Use of arrows or similar showing progression phases

The error messages are not helpful. There is no explanation of words and expressions etc.

H5 Implement more/better information

When trying to edit a text box, the use of arrow buttons results in changing to the next “page”.

H6

General problems It is not possible to move between pages/tabs when the menu is open.

H3

28

Appendix C – Form related to interview guideBrukertest av en mobil tjeneste for endring av skattekort: Informasjon og samtykkeerklæring

Beskrivelse av prosjektoppgaven

Vi er en studentgruppe ved kurset ”Mobile informasjonssystemer” ved Institutt for informatikk, Universitetet i Oslo. Prosjektgruppen består av Sven M. Bakken Kristin Skeide Fuglerud, Øivind Hagen, Hani Murad og Ole Halvor Smylingsås.

Vi studerer en foreslått tjeneste for å endre skattekortet via mobilen. Vi ønsker å finne ut hva folk synes om en slik tjeneste.

Denne tjenesten er under utvikling, og det er laget en prototype som fungerer på mobil. Vi ønsker derfor deltakere til en brukerstudie. Målsetningen vår er å gi en vurdering av tjenesten og å komme med forslag til forbedringer av prototypen. Deltakere i brukerstudien vil bli intervjuet og deretter observert mens vedkommende forsøker å bruke tjenesten. For at det ikke skal koste noe for deltakeren kan vedkommende låne mobil eller sim-kort underveis.

Frivillig deltagelse

All deltagelse er frivillig, og man kan trekke seg når som helst. Ved bruk av lyd- eller videoopptak skal dette avtales på forhånd.

Deltakeren kan når som helst avslutte intervjuet eller trekke tilbake informasjon som er gitt under intervju eller observasjon. AnonymitetIngen andre enn prosjektgruppen vil få tilgang til opptak eller annen informasjon fra intervjuer og observasjon som kan identifisere deltakerne i studien. Informasjonen vil bare bli brukt som grunnlag for hvordan tjenesten kan forbedres, og vil ikke kunne tilbakeføres til deg.

Før intervju og observasjon begynner, bes deltageren om å samtykke ved å undertegne på at man har lest og forstått informasjonen og at man ønsker å delta. Som takk for hjelpen får deltageren en Kvikklunsj og et Flax-lodd.SamtykkeJeg har lest og forstått informasjonen over og gir mitt samtykke til å delta i studien

__________ ________________________________________

Sted og dato Signatur

29

Appendix D - InterviewguideIntervjuguide Skattedemo Dato:______ ID:________

Før gjennomgang av den mobile applikasjonen, går vi gjennom litt bakgrunnsinformasjon:

Personalia Navn: (frivillig, men greit hvis vi har spørsmål i etterkant)

Kjønn:

Telefon: (frivillig, men greit hvis vi har spørsmål i etterkant)

Utdannelse- fagskole, videregående skole, høyskole, universitet- fagbrev og kurs

Har du tilgang til internett hjemme eller andre steder? Hjemme jobb/annet

Hvor ofte bruker du PC til (D: daglig, U: ukentlig, M: månedlig eller A: aldri?)

D U M A

- å lese informasjon på internett?- å lese e-post?- andre applikasjoner?

På en skala fra 1 – 5, 1 svært dårlig- svært bra 5

hvor godt vil du si at du behersker det å gjør endringer på egen datamaskin eller mobil, som for eksempel å legge til nye programmer

1 2 3 4 5

Hvor ofte bruker du mobil til (D: daglig, U: ukentlig, M: månedlig eller A: aldri?)

D U M A

- kun til å ringe- å skrive /lese SMS?- å lese informasjon på internett?- å lese e-post?Erfaring med mobile applikasjoner ?Nevn eksempler på mobile applikasjoner du har benyttet? (i jobben, finn, trafikanten, kinobillett, etc)

Holdninger til bruk av mobile applikasjoner, som for eksempel endring av skattekort?

For eksempel varsling om mulig skattesmell via SMS, med link til endring av skattekort.

Erfaring med skattekort ?- kjenner kun til papirversjon av skattekort

- har levert selvangivelsen på nett eller SMS

30

Gjennomgang av mobilapplikasjonen:Vi går gjennom bruk av mobilapplikasjonen uten å forsøke å hjelpe brukeren, og kan gir følgende informasjon: - Vi ønsker å finne ut hva som er bra og hva som er dårlig ved skatteapplikasjonen. - Fortell hva du tenker, gjør og forstår/ikke forstår underveis.- Ta den tiden du trenger! Det er en fordel hvis du gjør det så langsomt at vi ser hva som

skjer!- Det kan hende jeg stiller spørsmål eller ber deg gjenta hvis jeg ikke oppfatter eller klarer å

følge med på hva du gjør!- Notere det som skjer på skjermen (vi har kun lydopptak!)

Kort sjekkliste Lesbarhet Grafikk, forståelse og estetikk Språkbruk Organisering av data/informasjon Hjelp Navigasjon og interaksjon Output Input Feil Programstatus/ kontroll Tid, responstid Personlig tilpassing Multimodalitet

Detaljert sjekklisteLesbarhetHva synes du om lesbarheten? (observer om bruker må anstrenge seg for å lese; mysing, lene seg fram mot skjermen etc.)

o Skrifttype, store/små bokstaver, fete/ikke fete typer o Skriftstørrelseo Justering/luft/marger o Farger og kontraster

Grafikk, forståelse og estetikkSymbolbruk (ikoner) ? Peke på ikonene og spørre: ”Før vi gjør noe mer eller går videre, ser vi på ikonene/knappene øverst på siden. Hva synes du om symbolene? Og så direkte: Hva betyr denne, denne, denne osv. Om de ikke vet så spør om de kan gjette ut fra symbolet.

Bruk av grafikk for å gjøre informasjonen tydeligere (gruppering, utheving, farge etc.)?

Språkbruk

Hva synes du om overskrifter, ord og begreper som brukes – er de forståelige, beskrivende

Organisering av data/informasjon

31

Hva synes du om plasseringen av felter og menyer?

Hva synes du om mengde informasjon på hvert skjermbilde?

Hjelp Forsøker bruker å finne hjelpeinformasjon? (observer)

Navigasjon og interaksjon Hva synes bruker om skrolling av tekst ?

Bevegelser tilbake til tidligere stadier (andrer faner)? Dvs. frem og tilbake. Hvorfor?

Er brukers nåværende posisjon i skjemaet/applikasjon presentert godt nok?

Hvordan fungerer navigasjon mellom felter, forstår bruker hvilket felt som er aktivt?

ResponsFår bruker god nok respons på handlinger? (legg for eksempel merke til gjentakende tastetrykk?)

InputLegg merke til reaksjon på eller håndtering av de ulike input metodene: - nedtrekksliste, (drop down)

- inntastingsfelt

Feil Legger bruker merke til feil i felt og feil på en side?

Hvordan er mulighet for å angre/gå tilbake?

Hvordan er det å avslutte?

Reaksjon på ufrivillig avslutning?

Lyd

Hva synes bruker om å få teksten lest opp?

Bruk av handsfree?

32

33

Kommentarer til slutt (etter gjennomgang av skattedemoen)

(Hva var vanskelig? Hva var lett? Hva syntes du mangler? Hva kunne godt ha vært med? Hva burde vært annerledes? Var det noe som var uklart?)

Er du villig til å endre skattekort på mobil i framtiden?

Ideer til forbedringer?

Arbeidsflyt, påminning fra skatteetaten hvis man ligger an til å få baksmell på skatten?

34