LiU-ITN-TEK-G-13/007-SE
Användarcentrerad
framtagning av protoyper
-Visualisering av statistik
från XMS Penvision på iPhone
Gustaf Byström
2013-03-13
LiU-ITN-TEK-G-13/007-SE
Användarcentrerad
framtagning av protoyper
-Visualisering av statistik
från XMS Penvision på iPhone
Examensarbete utfört i Tekniska Informationssystem
vid Tekniska högskolan vid
Linköpings universitet
Gustaf Byström
Examinator Ivan Rankin
Norrköping 2013-03-13
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/Abstract XMS Penvision provides a platform to its customers for the creation of paper forms with the special technique this demands and management of their digital pens. The platform spans multiple operating systems but has not yet taken the step over to the iPhone. The ambition of XMS Penvision is to implement this and want to begin by showing statistical administrative information regarding their platform. The purpose of this thesis is to highlight the needs and wishes of XMS Penvision customers with the help of user‐centered methods and to create a prototype of an administrative interface for the iPhone. Usability goals, prototyping, heuristic evaluation and user tests are some of the methods applied during the work and the report describes these methods in theory but also through a discussion around their execution. The end result is a prototype implemented on the iPhone. The prototype uses data taken directly from XMS Penvision systems and users' views are documented. Sammanfattning XMS Penvision tillhandahåller idag en plattform till sina kunder för skapande av pappersformulär med den speciella teknik som detta kräver och hanteringen av tillhörande digitala pennor. Plattformen sträcker sig över flera olika operativsystem men har ännu inte tagit steget över till iPhone. XMS Penvisions ambition är att genomföra detta och vill då börja med att visa statistisk administrativ information gällande deras plattform. Syftet med detta examensarbete är att lyfta fram behov och önskemål från XMS Penvisions kunder med hjälp av användarcentrerade metoder och skapa en prototyp över ett administrativt gränssnitt för iPhone. Användbarhetsmål, prototyping, heuristisk utvärdering och användningstest är några av de metoder som under arbetet tillämpades och rapporten beskriver dessa metoder, dels genom teori men också genom diskussion kring tillämpandet Slutresultatet är en prototyp implementerad på iPhone. Prototypen använder sig av data direkt hämtad från XMS Penvsions system och användarnas åsikter finns dokumenterade.
Acknowledgements
We would like to thank the people at XMS Penvision for their open and supportive attitude. The help they provided on technical issues and the information we were able to gather by allowing us to attend their meetings have been invaluable. We would also like to thank our users, without their participation this thesis would not have been possible. Also, big thanks to Ivan Rankin, our examiner who helped us with administrative parts, the report and just bearing with us. Finally Björn Lemieszewski has to be acknowledged. He was in this project to the very end, but a tragic accident in his family changed his priority in life changed. He should have had his name on this report as well.Table of Contents
1 Introduction ... 1 1.1 Background ... 1 1.1.1 Formidable platform ... 1 1.1.2 iPhone ... 3 1.1.3 Prototype ... 3 1.2 Aim ... 3 1.3 Delimitations ... 3 1.4 Structure of the report ... 4 2 Theory ... 4 2.1 User Centered Design ... 4 2.1.1 The ISO definition ... 4 2.2 Usability ... 6 2.2.1 Usability ... 6 2.2.2 Jakob Nielsen's definition of Usability ... 7 3 Method Theory ... 8 3.1 User group analysis ... 8 3.1.1 Interviews ... 9 3.1.2 Questionnaires ... 9 3.2 Usability goals ... 10 3.3 Scenarios ... 11 3.4 Prototyping ... 11 3.4.1 Prototype ‐ fidelity ... 12 3.4.2 Parallel design ... 13 3.5 Usability testing ... 13 3.5.1 Prioritizing Usability Activities ... 14 3.6 Heuristics evaluation ... 15 4 Considerations when developing towards the iPhone ... 16 4.1 Programming for iPhone ... 16 5 Execution ... 17 5.1 Execution ‐ Iteration 1 ... 17 5.1.1 Background analysis ... 17 5.1.2 User group analysis ... 17 5.1.3 Usability goals ... 18 5.2 Execution ‐ Iteration 2 ... 19 5.2.1 Prototype 1 ... 19 5.2.2 Prototype 1 – heuristic evaluation ... 19 5.3 Execution ‐ Iteration 3 ... 20 5.3.1 Prototype 2 ... 20 5.3.2 Prototype 2 – usability tests ... 20 5.4 Execution ‐ Iteration 4 ... 21 5.4.1 Prototype 3 ‐ Implementation ... 21 5.4.2 Prototype 3 – usability tests ... 21 6 Results ... 22 6.1 Results ‐ Iteration 1 ... 22 6.1.1 Background analysis ... 22 6.1.2 User group analysis ... 22 6.1.3 Usability goals ... 25 6.2 Results ‐ Iteration 2 ... 27
6.2.2 Prototype 1 – Heuristic evaluation ... 29 6.3 Results ‐ Iteration 3 ... 32 6.3.1 Prototype 2 ... 32 6.3.2 Prototype 2 – usability test ... 33 6.4 Results ‐ Iteration 4 ... 39 6.4.1 Prototype 3 ‐ Implementation ... 39 6.4.2 Prototype 3 – usability test ... 42 7 Discussion ... 48 7.1 Discussion ‐ Iteration 1 ... 48 7.1.1 Background analysis ... 48 7.1.2 User group analysis ... 48 7.1.3 Usability goals ... 49 7.2 Discussion ‐ Iteration 2 ... 49 7.2.1 Prototype 1 – design decisions ... 49 7.2.2 Prototype 1 – heuristic evaluation ... 52 7.3 Discussion ‐ Iteration 3 ... 55 7.3.1 Prototype 2 – design decisions ... 55 7.3.2 Prototype 2 – usability tests ... 57 7.4 Discussion ‐ Iteration 4 ... 64 7.4.1 Prototype 3 – Implementation ‐ design decisions ... 64 7.4.2 Prototype 3 – usability tests ... 67 8 Conclusions ... 73
1 Introduction
Between October 2009 and February 2010 a user centered prototyping was conducted for a future development of iPhone software. This is a software to be used with XMS Penvisions current software Formidable. A series of methods was used including: • Questionnaires • Heuristics evaluation • Iteration based development • Usability goals • Usability testing This report outlines the findings from each of these methods.1.1 Background
XMS Penvision have from the beginning of 2001 delivered a system that is mainly a platform but also a framework handling digital pens and questionnaires for their customers. Their system is shaped by the demands of the customers and the visions of the company and now they want to expand their system to a new platform, the iPhone. The task is to find out what information the users find important and how they want it represented using user centered and interaction design methods.1.1.1 Formidable platform
Formidable is the name of the XMS Penvision platform. It is a software used with Anotos digital pens. Paper and pen: The pen registers text written on a paper through a special technique developed and patent‐protected by the Anoto company. A dot pattern that is almost invisible for the human eye is added before printout and the pattern on each paper has a unique identity and indicates the exact positions of the digital pen. When the digital pen equipped with a small camera is used on the paper digital snapshots are taken to determine the position of the pen and what it writes or draws. The pen also keeps track of the time when a stroke was made and what kind of paper form it was written on. The pen can store up to 50 full A4/Letter size pages. (Digital Pen and Paper, http://www.anoto.com/digital‐pen‐ paper.aspx, Retrieved November 20th 2009) (Digital Pen and Paper, http://www.opcom.se/1/1.0.1.0/50/1/, Retrieved November 22th 2009)When the users of a pen want to finish writing or drawing they can transfer data either wirelessly through Bluetooth or via a docking station connected to a computer’s USB port. In the Bluetooth case the pen can be connected either to a computer or a handheld device such as a mobile phone and then the user ticks a special box on the paper, this is interpreted as a "send" command by the pen. (http://www.anoto.com/digital‐pen‐paper.aspx, retrieved February 17th, 2010) (http://www.opcom.se/1/1.0.1.0/50/1/, retrieved February 17th, 2010) Formidable: The computer or the handheld device passes on the data through Internet to a server running the Formidable system. Here the data gets viewed, analyzed and managed depending on the objectives of the data collection. This is where it all starts. To be able to printout a questionnaire or any other type of paper to be used with the system you have to start by creating it in Formidable and thus adding the pattern. Apart from this you have an administrative view that lets administrators manage applications, pens and users in the system. (http://www.anoto.com/digital‐pen‐paper.aspx, retrieved February 17th, 2010) (http://www.opcom.se/1/1.0.1.0/50/1/, retrieved February 17th, 2010) Figure 1 Figure 2
1.1.2 iPhone
The iPhone is a cellular phone that was first introduced in the middle of 2007. It is designed and distributed by Apple Inc and today it has reached its sixth generation, the iPhone 5. The iPhone 3GS was the latest iPhone when this project was conducted. Compared with a classic cellular phone the iPhone provides the user with numerous extra functions such as Internet connectivity, a camera, navigation aid GPS, the possibility to install and run programs or games and much more. Cellular phones providing these kinds of functions are often referred to as Smartphone’s. One thing that makes the iPhone differ from almost any regular cellular phone and even most Smartphone’s is the absence of a physical keypad or keyboard. Instead the iPhone is equipped with a touch screen covering the larger part of the phone where the user interacts with an onscreen virtual keypad or keyboard. (Introducing iPhone 3GS, http://www.apple.com/iphone/iphone‐3gs/ Retrieved February 17th 2010)1.1.3 Prototype
Through usability and interaction design methods a prototype of an administrative graphical user interface has been developed, showing Formidable statistics on the iPhone. The prototype will give the developers at XMS Penvision support and feedback in their further development towards the iPhone.1.2 Aim
The aim of this thesis is to give the reader an insight on how to utilize user centered and interaction design methods in a practical way when developing a prototype. Mixing theory with actual practice will hopefully help the readers to better understand the different methods and how to apply them. An underlying aim of the thesis is also to give feedback to the developers at XMS Penvision regarding their users’ needs and the finished prototype.1.3 Delimitations
The methods presented and used in this thesis are just a few of the numerous methods that can be used to heighten the level of usability. The thesis is written from a usability perspective and little is said about programming towards the iPhone. Figure 31.4 Structure of the report
Chapter two, Theory, gives the reader a theoretical background of User Centered Design and Usability concepts in general. Chapter three, Method theory, explains the different methods used during this thesis. Chapter four, Considerations when developing towards the iPhone, will give the reader short background information regarding development for the iPhone. Chapter five, Execution, describes how the different methods have been used and how they were adapted during the thesis.Chapter six, Results, this chapter presents the results of the different methods used.
Chapter seven, Discussion, is a discussion around the methods used and their execution as well as an explanation on the design decisions made.
I the last chapter, Conclusions, we string everything together.
2 Theory
This chapter discusses the concept of User Centered Design and Usability.
2.1 User Centered Design
The main theme during User‐centered design (UCD) is to understand the context in which the product will be used. What kind of needs, demands or limitations do the users have and how this should affect the final product. Involving the users in an early stage and letting them participate during the development enable a more accurate analysis. Different products, users and goals result in an infinite number of approaches concerning the planning and implementation of the processes. Therefore there is no definitive definition of User Centered Design but experts on the subject provide a number of interpretations. This report will focus on two definitions, the ISO and Gulliksen & Göransson's.
2.1.1 The ISO definition
The ISO 13407 incorporates user centered design activities and helps developers achieve quality in interactive computer‐based systems throughout a systems life cycle. It covers knowledge and techniques regarding the improvement of effectiveness, productivity, ergonomics, safety, health and performance. Through an iterative approach the process repeats the activities until the objectives are satisfied.
The ISO determines four activities that need to start at the early stages of a project. • Understand and specify the context of use • Specify the user and organizational requirements • Produce design solutions • Evaluate designs against requirements (Human centered design processes for interactive systems, http://www.usabilitynet.org/tools/13407stds.htm , Retrieved 1st of December 2009) Figure 4 Gulliksen & Göransson's definition Jan Gulliksen and Bengt Göransson define and describe User Centered Design and point out that it's important to understand that the ISO 13407 doesn't provide a finished development process by itself. The ISO is merely a concept that can be turned into a process or implemented in an already defined system development process. (Gulliksen & Göransson, 2002, p. 106)
The user is an individual that will interact with the system and by doing so performs tasks in his work or in some other context, in other words the real users, not the customer or client for the system. There is no substitute for the real users and even if the client or customer thinks they know how the users work and react, this is rarely the case. The ISO 9241 defines the user as a "Person/individual who interacts with the product/system" (ISO 9241‐11, 1998). Centered: The users should be put in center of the process and not solely give input on finished solutions but be given the possibility to influence the process at an early stage by becoming an active part of the process. Design: User centered design is a process that builds on a philosophy or attitude with key principles that brings focus on usability throughout the system development process. (Gulliksen & Göransson, 2002, p. 104)
2.2 Usability
2.2.1 Usability
The ISO definition Usability is a central concept in user centered design and it's important to have an understanding of the concept. The International Organization for Standardization ISO has defined the different terms under the usability concept. The definitions are as follows: Usability “Usability: the extent to which a system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” • Effectiveness: “Accuracy and completeness with which specified users can achieve specified goals in particular environments” • Efficiency: “Resources expended in relation to the accuracy and completeness of goals achieved” • Satisfaction: “The comfort and acceptability of the work system to its users and other people affected by its use”Context of use:
“Users, task, equipment (hardware, software and materials), and the physical and social environment in which the product is used”
(Gulliksen & Göransson, 2002, p. 61)
2.2.2 Jakob Nielsen's definition of Usability
Jakob Nielsen is a User Advocate and principal of the Nielsen Norman Group, which he co‐founded with Donald A. Norman. Before starting NNG in 1998 he was a Sun Microsystems Distinguished Engineer. Nielsen founded the "discount usability engineering" movement for fast and cheap improvements of user interfaces and has invented several usability methods, including heuristic evaluation, which is described in section 3.6. (Jakob Nielsen Biography, Usable information, http://www.useit.com/jakob, retrieved 12th of January 2010)
Definition of usability by Nielsen: "Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease‐of‐use during the design process." (Introduction to Usability, http://www.useit.com/alertbox/20030825.html, retrieved 13th of January 2010) It is important to realize that usability is not a single, one‐dimensional property of a user interface. Usability has multiple components and is traditionally associated with these five usability attributes: • Learnability The system should be easy to learn so that the user can rapidly start getting some work done with the system. • Efficiency: The system should be efficient to use, so that once the user has learned the system, a high level of productivity is possible. • Memorability: The system should be easy to remember, so that the casual user is able to return to the system after some period of not having used it, without having to learn everything all over again. • Errors: The system should have a low error rate, so that users make few errors during the use of the system, and so that if they do make errors they can easily recover from them. Further, catastrophic errors must not occur. • Satisfaction: The system should be pleasant to use, so that users are subjectively satisfied when using it. (Nielsen, 1993, p. 26)
"Where utility is the question of whether the functionality of the system in principle can do what is needed, and usability is the question of how well the users can use that functionality." (Nielsen, 1993, p. 25)
3 Method Theory
This chapter presents the theory behind the usability methods used in the thesis.3.1 User group analysis
A user group implies on a number of users sharing a common ground regarding the purposes and expectations of a developed system. It is important to identify the goals and requirements of the users and this is why a user group analysis should be performed. The user group analysis supports the developers when they make decisions regarding the design and testing of the system. "The two most important issues for usability are the users' task and their individual characteristics and differences." (Nielsen, 1993, p. 43) There are numerous methods through which a developer can obtain information when performing an analysis. Observations, interviews and questionnaires are examples of these methods and it is important to point out that these methods often must be adapted depending on what kind of systems are developed. Crucial information should be discovered in an early state of the development; hence a user group analysis should be performed as early as possible. Questions that should be answered during an analysis: • What is the purpose of the system and what will the user group achieve while using it? • In what kind of environment will the system be used and how will it affect the system? • What tasks is the system required to perform? • Are there any differences in age, gender, language etc. of the people who will use the system? • Are there any similar systems or tools available and how do the users' experiences of that system differ? (Ottersten & Berndtsson, 2002, pp. 65‐67) Because of the analysis developers can avoid developing unnecessary functions and focus on key functionality that will contribute to a successful system. Frequently used functions become easier to find and are simpler to use. Finally the users themselves give information regarding what they want or don't want and therefore the need for discussing this among the developers disappears. (Ottersten & Berndtsson, 2002, pp. 63‐67)
3.1.1 Interviews
During an interview the interviewer can adjust the questions depending on the situation and this makes this method well suited for exploratory studies where you don't always know what you are looking for. The interviewer is able to evaluate the questions and if the user would misunderstand them they can easily be rephrased. The questions are typically open‐ended which allows and encourages the users to explain themselves in depth and this often leads to colorful quotes and aid during design decisions. It is important that the interviewer stays neutral during the interview to ensure unbiased responses from the users. Phrasing questions in an open and neutral way, not agreeing or disagreeing with either the users’ statements nor explaining system behavior even if the user complains about it achieves this. (Nielsen, 1993, p. 211)3.1.2 Questionnaires
A questionnaire studies users opinions about an interface and not the user interface itself. They are usually a bit overrated and it is sometimes difficult to get the answers you are looking for, because they usually have a low answer rate and questions might be wrongly interpreted. The positive side of questionnaires is that they are cheap and don't require much effort when collecting quantitative data. (Gulliksen & Göransson, 2002, pp. 256‐262) The questions can be open‐ended or close‐ended. Close‐ended questions have a set format to answer, for example "1‐5" for the user to rate or "yes" or "no". Open‐ended questions require the user to form their own answers. When using close‐ended questions you force the user to answer what you want, open‐ended questions enable the users to say what they want, but if the user misinterprets the question you might not have any use for it. (Nielsen, 1993, pp. 209‐214) Questionnaire for Super Admins concerning information layout in Formidable and some complementing questions Company name (optional): Please rate how important the information is to you concerning Applications. (1‐10, 1 being the most important)ID: Organization: Form Balance:
Application Name: Send Method: Total:
Description: Pages: Date Modified: Version: Suggestions/remarks:
3.2 Usability goals
There are two types of usability goals, qualitative and quantitive, and they are used by the developers to measure the usability of the system. Qualitative goals: Properties of a system in the context of use e.g. helping the users to perform their tasks when it is needed. Quantitative goals: Goals that are measurable from usability issues, the most important being effectiveness, efficiency or satisfaction. Effectiveness: Percentage of fulfillment of a goal, percentage of correctly performed tasks or percentage of relevant functions usage. Efficiency: Time to complete a task or number of serious errors. Satisfaction: Assessment of satisfaction using the Likert scale, a scale between 1‐5 or 1‐7. (http://en.wikipedia.org/wiki/Likert_scale, retrieved 22nd January 2010) An example of a measurable usability goal in the satisfaction category could be for example on a scale of 1‐7 where the usability goal is fulfilled if the average rate is above 5: How satisfying do you think the system was to use? The following information is required for enabling usability measurements: • A description of the users’ goals and intentions • A description of the context of use including: the users, the tasks, the equipment and the environment. • Qualitative goals or measurable values for effectiveness, efficiency and satisfaction in the context of use. With this information the developers then specify the usability goals of the system. Measurable goals allow the developers to get input on how good the usability of their system really is and make it possible to track the changes in usability from one iteration to another allowing an adaptive development. The usability goals also compel developers to take their users' needs into consideration during the development. (Gulliksen & Göransson, 2002, p. 72) (Institutionen för teknik och naturvetenskap, Linköpings Universitet, http://webstaff.itn.liu.se/~marka/TNMK31/Material/usability.pdf, retrieved 22th. of January 2010)3.3 Scenarios
Scenarios are used to simulate a user interface and by using simple paper mock‐ ups it is possible to reduce the cost compared to other alternatives such as software solutions. Scenarios can only simulate a user interface as long as the test user follows a previously planned path. This reduces both the level of functionality and the number of features. This gives the possibility to make the scenarios small, resulting in easier and cheaper changes. It is a way of getting quick frequent feedback from the users. (Gulliksen & Göransson, 2002, p. 259) (Nielsen, 1993, p. 18)3.4 Prototyping
Prototypes should be used early and all the way through the development process to visualize and evaluate ideas with users. Start on a low level with for example paper prototypes before any implementation of code is performed. Preferably work with users in their own environment. Start with getting a good conceptual design and leave details to later. (Gulliksen & Göransson, 2002, p. 34) Methods of prototyping: • Requirements animation: different possibilities are demonstrated. • Rapid prototyping: "throw‐it‐away", analyze, evaluate and throw away. • Incremental prototyping: the system is built incrementally. • Evolutionary prototyping: a combination of a prototype and a product, a system is developed and refined during the process. (Gulliksen & Göransson, 2002, pp. 243‐244) Requirements animation and rapid prototyping are more of an exploring process and incremental and evolutionary prototyping are more of an iterative development process. Characteristic for the exploring processes: • "Throw‐it‐away" ‐ is thrown away after use. • Has to be cheap because it is thrown away. • Different tools are used: Paper and pen, computer software e.g. Photoshop or sketch software. • Good for: Getting information of system limits, testing solutions and seeing if solutions are plausible. • Is used to evaluate solutions before one is selected. You can afford to test multiple solutions.• A combination of "real prototyping" and prototyping. • Building the system in steps until the system is finished. • Trying to build from prototype to a finished system. • It is important to work in a development environment used to finish a product. • It is hard to be objective when it is something you built yourself, easier to fix things than to evaluate alternative solutions. (Gulliksen & Göransson, 2002, p. 244)
3.4.1 Prototype - fidelity
A prototype can have different levels of detail during a process and developers often divide them into low‐fidelity and high fidelity prototypes. Low fidelity prototypes are often cheap to use and different kinds of system functionality and user interaction can quickly be tested because of a low detail level. The low‐fidelity prototype can consist of a paper mock‐up or even more simplified sketches and the developers should keep it simple for easy modifications e.g. often nothing more than some paper, pens, post‐it and tape should be required. High fidelity prototypes have a higher level of detail and have a lot more functionality. They can consist of images of the system made on a computer or simplified versions of the actual product. Developers are able to test it and even if it is merely a shell showing high‐level functionality the users can give their opinion regarding the end product. (Institutionen för teknik och naturvetenskap, Linköpings Universitet, http://staffwww.itn.liu.se/~marka/TNMK31/material/prototyping.pdf , last visited 21st of January 2010) Figure 53.4.2 Parallel design
During a design process it is possible to test different approaches by using the parallel design method. In this method the designers independently work out their own design not influencing each other and by doing so alternative solutions and new approaches might come to life. The different designs should be kept on a low detail level and the designer finishes by merging their work into one mutual system design. The low level detail is required because in most cases a low‐fidelity prototype is the end result. (Nielsen, 1993, pp. 86‐88)3.5 Usability testing
According to Nielsen, only five users are required to discover 85% of the occurring usability problems in a system and the test should be performed over three iterations. To find 100% of the usability issues fifteen users need to participate. It is a better idea to divide that number on three tests, five users in each test. A smaller number of users allows you to run multiple tests easier and this is good because the real goal of usability is not to document weaknesses but to track improvements in the design. Multiple tests enable developers to fix the problems through redesign and to get quick feedback on their changes. Figure 6Figure 7 "As you add more and more users, you learn less and less because you will keep seeing the same things again and again." (Why you only need to test with 5 users, http://www.useit.com/alertbox/20000319.html, last visited 27th of January 2010) One of the methods that can be used during usability testing is thinking aloud, the users verbalizes their thoughts while they test the system enabling developers to see the users view of the system. (Nielsen, 1993, pp. 195‐200)
3.5.1 Prioritizing Usability Activities
When working with usability it not always possible to perform all the activities recommended, constraints such as time, budget, location etc. might affect the possibilities during a project. It is then important to "optimize" the usability process by choosing methods with the highest usability payback. Top methods according to rated impact on usability: 1‐2. Iterative design and task analysis of the user's current task. 3. Empirical tests with real users. 4. Participatory design. 5‐6. Find out how the system actually is used by performing field studies and visits to customer locations before design takes place. (Nielsen, 1993, p. 112)
3.6 Heuristics evaluation
Jakob Nielsen has developed 10 general principles for interface design. He calls them "heuristics" because he says; "they are more in the nature of rules of thumb than specific usability guidelines”. Visibility of system status The system should always keep users informed about what is happening, through good feedback within reasonable time. Match between system and the real world The system should speak the users language, with concepts familiar to the user, rather than technical terms. Follow real‐world parables, making information appear in a logical order. User control and freedom Users often choose functions by mistake and will need a simple way to undo the error, to leave the state and get back on track. Consistency and standards Different parts across the system should look and work the same. Error prevention Even better than good error messages is a design that does not cause errors. Where errors easily happen, ask the user for a confirmation. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember everything from one part of the system to another. Instructions for use of the system should be visible or easily accessible. Flexibility and efficiency of use Shortcuts unseen by the novice user could help the interaction for the expert user so that the system can be useful to both inexperienced and experienced users. Aesthetic and minimalist design Dialogues should not contain information, which is irrelevant or hard to understand. Extra information in a dialogue competes with the relevant information and makes it hard to understand. Help users recognize, diagnose, and recover from errors Error messages should be displayed in easy language (no codes), indicate the problem, and suggest a solution. Help and documentation It may be necessary to provide help and documentation, though it is even better if the system can be used without documentation. Information should be easy to search and read. (10 Heuristics for User Interface Design: Article by Jakob Nielsen, http://www.nngroup.com/articles/ten‐usability‐heuristics/, retrieved February 19 2013)4 Considerations when developing
towards the iPhone
There are some important differences a developer should have in mind when it comes to development on the iPhone. In the development of ordinary desktop applications the computer often has the possibility to run several applications at the same time. The iPhone only permits one running application at a time. The application won't be able to do anything in the background, this is possible only when the user is running the application, thus giving it focus. Only one application at a time means only one window for user interaction and showing data and the window is always fixed to the size of the iPhone screen. When it comes to accessing data on the iPhone to be used with your application the access is restricted. Reading and writing files belonging to the application can only be done in a special area on the iPhone's file system. This area is created when the application is installed. Another restriction is to the network access of the application. There are a number of books available that help developers to fully understand the limitations. The size of the iPhone is important like with any handheld device that users should take with them easily. The size sets limitations on the screen size and you have a lot less space to work on than any ordinary computer. Showing large quantities of information on a small screen is always a challenge. Compared to similar smartphones the iPhone system resources are as high or higher than average but the resources are an important part to take in to consideration because of resource consuming content such as movies or high‐resolution pictures. When developing towards a handheld device there are always limitations but this is something that makes even more interesting.
4.1 Programming for iPhone
The programming language for iPhone is Objective‐c with its framework Cocoa Touch. Cocoa Touch is very much similar to Cocoa, which is used for developing for Mac OS X, but with several differences. Objective‐c is an object oriented language just as C++, Java and C‐sharp. The names reveal that they are all based on C. (Beginning iPhone 3 Development p 5‐6) Programming for Mac OS X and iPhone is usually done in Xcode with its partner Interface Builder. Xcode is an elaborated IDE (integrated development environment), which is made for just this. It includes tools for writing, debugging and compiling source code. Interface Builder is a graphical designer, which works hand in hand with Xcode. (Beginning iPhone 3 Development p 4)
5 Execution
This chapter describes how the project was executed and it is divided into the different iterations performed.5.1 Execution - Iteration 1
This chapter will describe the execution of iteration 1.5.1.1 Background analysis
The first part of the background analysis consisted of meetings with the people at XMS Penvision giving us the history of their products and the platform of today, Formidable. Discussions and brainstorming regarding an iPhone application were also performed with focus on specifying functionality. Through XMS Penvision we also gained access to a development and testing installation of Formidable allowing us to test and evaluate the system at its current version. Results of this can be seen in section 6.1.1.5.1.2 User group analysis
During the discussions with XMS Penvision a definition of the intended user group started to form and they were able to provide us with key information that we had to consider which lead to changes of our plan for user participation. Changes had to be made because of the fact that one conclusion were that the user group had prior Formidable and iPhone experience and the background analysis showed that it would not be possible to interview users of Formidable. See results in section 6.1.2. Our solution was to use surrogate users and five students at the University of Linköping was contacted and selected by iPhone experience through e‐mail and scheduled for usability testing.
5.1.2.1 Questionnaires We weren’t able to physically meet the real users, instead a questionnaire was sent by e‐mail to a group of Formidable users in different parts of the world selected for us by XMS Penvision. The aim of the questionnaire was to better understand what kind of functionality the users find important in the Formidable system. They were also given the opportunity to make comments regarding each question. Here is an example of one of the questions: Please rate how important the information is to you concerning Applications. (1‐10, 1 being the most important)
ID: Organization: Form Balance:
Application Name: Send Method: Total:
Description: Pages: Date Modified: Version: Suggestions/remarks: See appendix for complete questionnaire. See section 6.1.2.1 for results.
5.1.3 Usability goals
We encountered numerous problems regarding our usability because of the earlier mentioned user group complexity. The background analysis together with the user group analysis and the questionnaire gave us a base from which we formed both qualitative and quantitative usability goals. The qualitative goals were mainly based on the questionnaire and input from the meetings with XMS Penvision. “Context of use” and “User priorities” is examples of this. Quantitative goals were based on Nielsen’s ten heuristics and grouped according to Nielsen’s five usability attributes. Results can be seen in section 6.1.35.2 Execution - Iteration 2
This chapter will describe the execution of iteration 2.5.2.1 Prototype 1
After evaluating iteration 1 several discussions regarding the functionality and usability of the program lead to two individual designs. They were simple sketches made by use of pen and paper showing us our different thoughts regarding the design. Further discussions and analysis regarding each design gave us our first prototype. Figure 8 Here is a picture from the first prototype. The complete prototype can be found in section 6.2.1.5.2.2 Prototype 1 – heuristic evaluation
When the prototype was finished a heuristic evaluation was made by following Jakob Nielsen’s guideline principles. Individually we went through the 10 principles and wrote down the issues we could find. The individual results were then put together to single list showing the issues of the prototype. Suggestions on how to improve the prototype were discussed and documented. Results can be found in section 6.2.2
5.3 Execution - Iteration 3
This chapter will describe the execution of iteration 3.5.3.1 Prototype 2
After evaluating iteration 2 another low fidelity prototype was made out of paper. The heuristic evaluation lead to a few changes. Figure 9 This is one of the views. The complete prototype can be found in section 6.3.15.3.2 Prototype 2 – usability tests
We tested the prototype interaction with five users, all students at the university with previous iPhone experience. The users followed a scenario and answered a number of usability questions. ‐‐‐‐‐‐‐‐‐‐‐‐ Scenario You are to test a paper prototype of an administrative program. You navigate through the prototype by using your fingers. It is a touchscreen. Log in view ‐‐‐‐ What kind of information do you think is needed to be able to use this program? Where would you go to change settings in this view? ‐‐‐‐‐‐‐‐‐‐‐‐ The complete results of this can be found in section 6.3.2.
5.4 Execution - Iteration 4
This chapter will describe the execution of iteration 4.5.4.1 Prototype 3 - Implementation
The third prototype is an implemented prototype with the same functionality as the second prototype. Implemented prototype in this case means a functioning demo in objective‐c on the iPhone. Figure 105.4.2 Prototype 3 – usability tests
A usability test was performed and in this iteration the users followed the same scenario as in iteration 3 but on a real iPhone.
6 Results
This chapter describes the results during the project and it is divided into the iterations performed.6.1 Results - Iteration 1
6.1.1 Background analysis
During the background analysis we got a general overview of XMS Penvision and their product Formidable. We also got their view on how we could help them with an application showing Formidable statistics on the iPhone. Functionality identified together with XMS Penvision: • Be able to login to the system • Show an application overview • Be able to graphically visualize Formidable statistics6.1.2 User group analysis
The user group of the iPhone application is the same as for the Formidable platform of today. It can be any women or man between the ages of 18‐65 years old. The user is an administrator of the Formidable platform, therefore the user has prior knowledge of the different parts of the Formidable platform as well as earlier iPhone or smartphone experience. As an administrator it is important that information regarding system status and performance is easily accessible anytime and anywhere. The system will be mobile which leads to many different contexts of use. Examples of use might be during business travels, if the administrator is on call or just as an additional administrative tool. The real users of the Formidable system could not be involved because of geographical reasons. (see figure 11) They are located all around the world and for obvious reasons our budget and time doesn't allow traveling. Our solution was to contact distributers of the Formidable system in different countries for system specific information and to use local surrogate users when testing the interaction.
Figure 11 Geographical representation of XMS Penvision partners. 6.1.2.1 Questionnaire The sent questionnaire had a reply rate of four out of twenty. Numbers indicates the answer of user 1, 2 etc. and * indicates that they haven't replied to this. Please rate how important the information is to you concerning Applications. (1‐10, 1 being the most important)
ID: 1, 10, 8, 9 Organization: 2, 3, *, 3 Form Balance: *, 1, 4, 2
Application Name: 3, 1, *, 1
Send Method: *, 4, 3, 8 Total: *, 10, *, 10
Description: *, 10, 3, 7 Pages: *, 5, 3, 4 Date Modified: *, 10, 8, 6
Version: *, 10, 4, 5 Suggestions/remarks: Please rate how important the information is to you concerning Users. (1‐6, 1 being the most important)
User name: 1, 1, 6, 1 Pens: 2, 1, 4, 2 Roles: *, 3, 1, 6
Enabled: 5, 2, 2, 4 Printer: 6, 1, 2, 5 Organization
memberships: *, 4, 1, 4
Suggestions/remarks:
Please rate how important the information is to you concerning Pens. (1‐5, 1 being the most important)
Pen ID: 1, 3, 5, 1 Last submit: 3, 1, 5, 2 Locked: 5, 1, *, 5
Phone: 2, 1, 5, 4 Submits: 4, 5, 5, 3 Suggestions/remarks: Please rate how important the information is to you concerning Pen info. (1‐6, 1 being the most important) Pen ID: 1, 3, 5, 1 Penpusher version: 5, 1, 3, 6 Hardware ID: 2, 1, 3, 4
Last app: 4, 2, 2, 2 Client hardware: 6, 1, 4, 3 Last Penpusher User: 3, 3, 4, 5 Suggestions/remarks: Please rate how important the information is to you concerning the Pending tab. (1‐7, 1 being the most important)
Application: 2, 1, *, 1 Phone: 5, 1, *, 4 Comment: 6, 3, *, 7
Organization: 3, 1, *, 3 Pen: 1, 3, *, 2 E‐mail: 4, 1, *, 6
Date: 7, 3, *, 5 Suggestions/remarks: Please rate how important the information is to you concerning the About tab. (1‐6, 1 being the most important)
Type: 1, 6, 2, 6 Identity: 6, 6, 3, 3 Last registration: 4, 6, 4, 2
Host: 2, 1, 5, 5 Version: 3, 6, 3, 1 Created: 5, 6, 3, 4
Suggestions/remarks: Do you have any other suggestions or remarks on how to improve the presentation of information in Formidable?
User 1:* User 2: No User 3: YES . If i could see the users transactions in graphical mode per day and per application. Also if a pen is used from more than one person i would like to know the history of users that have used it. User 4: Flexible configurable warnings for example for when paper licenses run out or apps are being used a certain percentage above or below normal use. Have you ever used an iPhone? User 1: * User 2: No User 3: Yes User 4: Almost never Do you own an iPhone? If not, which is your current mobile device? User 1: * User 2: No. But most of my colleagues do. User 3: Nokia E72 User 4: Sony Ericsson Xperia1 Other suggestions/remarks? User 1: * User 2: * User 3: * User 4: Java dashboard app, or even better a dashboard webpage targeted for mobile use. Thank you for answering our questions, we value your contribution!
6.1.3 Usability goals
The usability goals are based on an analysis of the questionnaire, input from the meetings with XMS Penvision, heuristics and recommended usability goals. 6.1.3.1 Qualitative goals The users have experience of iPhone and Smartphone’s and therefore the interface shall behave accordingly to similar iPhone applications and the user shall find the interface familiar and easy to learn. The application should also be fast, efficient and easy to use.6.1.3.2 Quantitative goals Learnability Description: The users shall find the application easy to use. Goal: The users shall rate the application at least 5 on a scale of 1‐7 Efficiency Description: The users shall find the application efficient to use. Goal: The users shall rate the application at least 5 on a scale of 1‐7 Description: The users shall find the application effective to use. Goal: The users shall rate the application at least 5 on a scale of 1‐7 Memorability Description: The users shall be able to answer questions regarding specific parts of the application. Goal: The users shall answer 100% correctly on memorability questions. Error Description: The users shall make few errors while using the application Goal: During the given scenario the users should only make 1 error. Satisfaction Description: The users shall find the feedback of the application satisfying. Goal: The users shall rate the application at least 5 on a scale of 1‐7 Description: The users shall find use of the application overall satisfying. Goal: The users shall rate the application at least 5 on a scale of 1‐7
6.2 Results - Iteration 2
6.2.1 Prototype 1
The outcome of the work performed during iteration 1 was a prototype. Four different views sketched on paper. Figure 12 A simple login screen that includes the things that is needed to login.Figure 13 A menu view for users to choose what they want to do. Figure 14 This is how the view over all the applications in the software could look like.
Figure 15
This is how some of the statistics could be presented.
6.2.2 Prototype 1 – Heuristic evaluation
The individually performed heuristic evaluation was summarized into the following table.
The column rule number refers to one of Nielsen's 10 guidelines for interaction design and the severeness indicates usability issue.
Rule number: Note: Severeness: (0‐4, 4
being most critical) Action Package: 1 The user doesn't get any feedback if something needs to be reloaded in the application. 3 Animator? 1 There is no feedback on connection status. 2 Action pop up? 1 It is unclear what slice belonging to what in the piechart. 3
1 two menu options actually mean. 3 (2 and 4) 1 Unclear to the user that you can scroll to get more info about an application. 1 1 It is unclear what information the user must use at connection settings. 1 Help button? 2 From the perspective in which the user previously used the iPhone, we follow no fixed iPhone proposed standard on buttons and design. 3 Look up and download from the iPhone Dev, Bjorn The solution as I see it is to quickly read through the material to get an idea of how to use it and then check the program at a later stage. No big stuff to keep track of. 3 This part is slightly different on iPhone because it’s always the user who ends their applications by pressing a button. The only input the user does is connection info and wherever the user is The application lets the user to fall back to previous view. 0 4 The tab in the different views need to be highlighted in some 2 You can probably solve just by putting the button in the mode
way so it becomes clearer to the user which view they are in selected 5 "Thick" fingers may cause problems when the user selects one of the very small print details in parts of the program. 1 6 Has no help function at present, we have been talking about a demo mode. 0 7 Not applicable to customize the program at this time. 0 8 At the start screen, we have connection settings, actually just important the first time you login. 3 Save removal of logins 9 Not yet implemented but will be needed when users login. 2 10 Not relevant to this program at this time. 0
6.3 Results - Iteration 3
6.3.1 Prototype 2
After further analysis during iteration 2 with the heuristic evaluation another prototype were sketched on paper resulting in four new views. Figure 16 Figure 17Figure 18 Figure 19
6.3.2 Prototype 2 – usability test
Results of the usability test performed during iteration 3. Name: 1 User 1 2 User 2 3 User 3 4 User 4 5 User 5 Date:
2 2009‐12‐09 3 2009‐12‐10 4 2009‐12‐11 5 2009‐12‐11 Background: 1 IPod touch gaming and surfing 2 Owner of iPod Touch 3 Owner of iPod Touch 4 Have an iPhone 5 Have tried a friends iPhone Give the user the background of the project. Scenario You are to test a paper prototype of an administrative program. You navigate through the prototype by using your fingers. It is a touchscreen. Log in view ‐‐‐‐ ‐‐‐‐ What kind of information do you think is needed to be able to use this program? 1 User, Password. Save password. 2 Registered previous username and password. 3 User name and passwords. 4 User name and passwords. 5 Login information Where would you go to change settings in this view? 1 Down in the right corner, settings. 2, press settings.
3 Press settings. 4 Press the settings. 5 Settings Because of this being prototype you can login without username and password, Click log in ‐‐‐‐ ‐‐‐‐ Application view How do you think you can see more of the shown table? 1 Drag to one side. Should show that you can pull to one side with a scroll or similar. 2 Press the name? The user would try to click around a bit. More obvious if it would be real ... Arrow to show that it is possible to scroll. 3 Touch them. Scroll sideways. 4 Scroll sideways. 5 Press them Is this a good way to solve the problem? 1 It is a good thing. Recognizes the solution, you would not know where you were after a while though. 2 3 It will work well if you can see that you can scroll further. 4 Yes it is good to see more details. 5 Yes it seems to work. Do you have suggestions on how you could do it differently? 1 Show that it is scrollable. 2 Show that it is scrollable. 3 Possible that you can put the program down.
5 What functions do you think the program gives you if you focus on the top of the view? 1 Start will return to the login screen. Hesitating but applications is the view we are in now. Strengthen the feeling where you are at certain time. Other keys to the same table. Visualize, would visualize one of the applications? 2 User / pens provides information about users. Visualize gives graphs of the information. 3 Applications, where you are now. Users, list of users. Visualization of some information. 4 Start would be either go back, or maybe test run an application? Applications this view. User is the user. Visualize is a graphical view of something. 5 The user chooses what he wants to see information about. What functions do you think the program gives you if you focus on the bottom of the view? 1 Search, many applications so you can filter them. Sort columns by clicking on the column header. 2 Search for applications. 3 Arrangement set various options on how it should be sorted. Look at different applications. 4 Search to find applications. Arrange is to sort by something. 5 Finding applications Go to the part of the programs that visualize the information. ‐‐‐‐ ‐‐‐‐ Visualize view How can you change the information shown in the piechart? 1 The arrows in different directions. A bit difficult to know when there is no information, but colors are always good to separate. Pie graphs easily become hard to read if there are many, bars could then be easier.
2 You click and drag on the graph, swirl it in 3d. Shows various things related to the applications. Other options perhaps for last week or estimation of the next. 3 Change week, changing what the graph will show the transactions. 4 Press the to move sideways. 5 Appear to be able to configure it by clicking at arrows. Is this a good way to solve the problem? 1 2 Can’t really think of any other way. 3 Easy to understand. Maybe it would be good to be able to choose different graphs yourself. 4 Yes I think so. List in the column might also work, but it can be good with charts. 5 Depends on what kind of information to be displayed. Where would you click to go to the welcome screen of the program? 1 Start button would send you back to the login screen. It is close to the other buttons and might be easy to press by mistake. 2 Start button. Should be changed to "back" though, that's the way it usually is. 3 Start button. 4 Start button. 5 Start button. Ending questions: Do you have any other suggestions on how to improve the program? 1 Should be simple, not add too much. 2 3 Not really, it is easy to understand. 4 Settings would be good to reach from inside the program if you could make settings for the program itself. 5
Do you have any other suggestions on how to visualize data? 1 2 3 4 5 Easy to remember Where in the program did you change between different views? 1 Tab bar at the top. 2 I pressed the button that I thought I was pressing. At the top. 3 Visualize, at the top right corner. 4 Up in the tab bar switches between views. 5 In the top menu. How could you change what was shown on the piechart? 1 Scroller changes information and time span. 2 Press scroller at the bottom 3 The menu above the weekly selection. 4 Use sideway scrolls. 5 You could change it by clicking at the bottom of the page Errors 1 2 3 4 5
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐ Usability measurement: On a scale from 1 to 7 (for all) 1.How easy do you think the program was to use? 2.How effective do you think the program was to use? (Effectiveness, how well the program uses the time or energy?) 3.How efficient do you think the program was to use? (How effective was the program to perform various tasks?) 4.How satisfying was the software to use? 5.How was the feedback from the program? ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐ Usability
question: User 1: User 2: User 3: User 4: User 5: Average:
1 5 6 5 6 5 5.4 2 4 7 5 6 4 5.2 3 5 3 5 6 3 4.4 4 7 3 6 4 4 4.8 5 6 6 3 6 3 4.8
6.4 Results - Iteration 4
6.4.1 Prototype 3 - Implementation
The prototype in iteration 4 is an iPhone implemented version based on the mainly based on the prototype from iteration 3.Figure 20 The implemented version of the login screen. Figure 21 The first thing the user sees of the applications view.
Figure 22 The way the information of the applications scroll. Figure 23 Here is a pie chart drawn.
Figure 24
One way the user could change the information shown.
6.4.2 Prototype 3 – usability test
Here are the results of the second usability test we did with our users. Name: 1 User 1 2 User 2 3 User 3 4 User 4 5 User 5 Date: 1 2010‐01‐22
2 2010‐01‐22 3 2010‐01‐22 4 2010‐01‐22 5 2010‐01‐22 Background: 1 IPod touch gaming and surfing 2 Owner of iPod Touch 3 Owner of iPod Touch 4 Have an iPhone 5 Have tried a friends iPhone Give the user the background of the project. Scenario You are to test a prototype of an administrative program. You navigate through the prototype by using your fingers. Log in view ‐‐‐‐ ‐‐‐‐ What kind of information do you think is needed to be Able to use this program? 1 User, Password 2 Username, Password 3 User Name, Password 4 Username, Password 5 Username, Password Where would you go to change settings in this view? 1 Settings 2 Settings 3 Settings 4 Settings
