Department of Science and Technology
Institutionen för teknik och naturvetenskap
LIU-ITN-TEK-A-19/051--SE
Development of a standalone
mobile application for Saab
Support Portals
August Sjögren
LIU-ITN-TEK-A-19/051--SE
Development of a standalone
mobile application for Saab
Support Portals
Examensarbete utfört i Medieteknik
vid Tekniska högskolan vid
Linköpings universitet
August Sjögren
Handledare Camilla Forsell
Examinator Matt Cooper
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/
Linköpings universitet
Linköping University | Department of Science and Technology
Master’s thesis, 30 ECTS | Media technology and engineering
202019 | LIU-ITN/LITH-EX-A--2019/001--SE
Development of a standalone
mobile application for Saab
sup-port sup-portals
Utveckling av en fristående mobilapplikation för Saabs
support-portaler
August Sjögren
Supervisor : Camilla Forsell Examiner : Matthew Cooper
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinä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. Över-fö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 till-gängligheten finns 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 än-dras 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 period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon 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
Saab is a large company providing a multitude of different products and services. This also means that Saab has to provide support and customer service for said products. Currently this is handled online in Support Portals, where customers and partners can access product information as well as an issue management system called SIRS. In the current situation the system is tailored for a desktop experience, and the workflow is therefore limited in terms of mobility. This project aims to allow the users to be more mobile by investigating the pos-sibility of developing a mobile application for usage with SIRS. During the project a proof of concept of such an application has been developed. The implementation relies largely on using currently available api:s and when necessary porting some code from server to client side. By using various UX-related methods during the development of the applica-tion it is expected that the applicaapplica-tion is user friendly and fits the target audience. When looking at the result of the work, it is indeed possible to integrate a standalone mobile ap-plication with SIRS. The apap-plication also has usability which is comparable to the current system. However, some limitations were found that required rewriting the existing system to provide necessary data to client side applications like the one developed in this project. To conclude, the application is a proof of concept that shows what can be done without modifying the current system. Some of the major things that has to be modified before tak-ing the application to production, such as stability concerns and testtak-ing, is also presented as results of the project.
Acknowledgments
I would like to thank Consid AB for allowing me to carry out my master thesis in their of-fice. They have provided great support throughout the project, whether it being technical support or just general encouragement. Special thanks goes out to my supervisor at Consid, Johan Persson, for always taking his time to figure out solutions to more or less strange prob-lems encountered and providing general support. I would also like to thank my supervisor Camilla Forsell for pointing me in the right direction regarding the questions I have had.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
1 Introduction 2 1.1 Saab . . . 2 1.2 Motivation . . . 2 1.3 Aim . . . 3 1.4 Research questions . . . 3 1.5 Delimitations . . . 4 2 Theory 5 2.1 SharePoint . . . 5 2.2 SSP . . . 6 2.3 SIRS . . . 6 2.4 Current system . . . 6 2.5 UX . . . 8
2.6 User centered system design . . . 9
2.7 Saab graphic profile . . . 12
3 Method and Implementation 13 3.1 Saab mobile app strategy . . . 13
3.2 The design process . . . 13
3.3 Implementation Approach . . . 17 3.4 Tools . . . 17 3.5 Development . . . 18 3.6 User testing . . . 20 3.7 Project management . . . 23 4 Results 24 4.1 Development . . . 24 4.2 Usability . . . 24 5 Discussion 27 5.1 Results . . . 27 5.2 Method . . . 29 6 Conclusion 31 6.1 Research questions . . . 31
6.2 Future work . . . 32
A Usability test tasks 33
A.1 Mobile app . . . 33 A.2 Mobile web . . . 33
B Post test survey 35
List of Figures
2.1 Basic structure of a SharePoint web application . . . 5
2.2 Landing page of a support portal . . . 7
2.3 A list of helpdesk issues . . . 7
2.4 Mobile version of the helpdesk list . . . 8
2.5 Illustration of user centered system design . . . 10
3.1 Persona . . . 14
3.2 First version of the prototype . . . 16
3.3 Second version of the prototype . . . 16
3.4 Mobile app taxonomy by R. Nunkesser . . . 17
3.5 Error message when a required field has no content . . . 21
4.1 Final version of the application . . . 25
4.2 Average completion times by task . . . 25
4.3 Interaction ratio per task . . . 26
Acronyms
API Application Programming Interface. CSS Cascading Style Sheets.
HTML Hypertext Markup Language. SIRS Saab Issue Reporting Service. SSP Saab Support Portal.
UCSD User Centered System Design. UI User Interface.
1
Introduction
This project was carried out as a master thesis at Linköping university at the Department of Science and Technology. This chapter will give an introduction to the project, as well as present relevant background information and motivate why the project was carried out.
1.1
Saab
Saab is a large Swedish company which manufactures and sells a large amount of different products, with their main focus being aerospace and defence technologies. These products can be for instance aircrafts, combat systems or radar equipment, which are mainly used for military purposes. However, there are some civilian uses also, mainly in the aircraft de-partment. To be able to provide service and support for this wide range of products, Saab provides Saab Support Portals to their customers and partners. These portals are accessible as web pages, with each portal belonging to a certain type or series of products. The portals provide functionality related to the product, with two main features being product docu-mentation and issue reporting. Docudocu-mentation can be provided by Saab as instructions and manuals for example, which are then accessible by the end users. This way, the users always have access to these documents as long as they have an internet connection. To handle issue reporting, a system called SIRS has been developed. SIRS is an abbreviation for Saab Issue
Reporting Service, and provides functionality for adding, viewing and editing issues through
a web browser. This system has been developed by Consid AB, which is a Swedish IT con-sulting firm. This is also where this master thesis is conducted.
1.2
Motivation
Currently, both the support portals and SIRS are designed to be used primarily on desktop devices, and as such the users are bound to using such devices or using the mobile web. When using the system through the mobile web, the information is small and it is hard to interact with buttons and other elements on the page. There is quite a lot of unused screen space which could be used to display the information in a more usable manner. Also, if the user zooms in on the page to get a clear view of the text, the content does not fit on the screen which forces the user to scroll both vertically and horizontally. Because of this, the mobile
1.3. Aim
version is rarely used which limits the possibility for users to report issues on the fly. This is a major drawback, and as such the system requires either a responsive redesign or a mobile application version to access the information from mobile devices in a feasible way.
Another issue with the existing system is that the users often are in remote locations when servicing products, and as such they do not have access to their desktop computers. Because the mobile web is not being used very widely, a current solution is for the technician to either call someone else to report the issue for them, or to wait until a computer is accessible. This process is error prone, as technicians can either forget to report issues or miss important details when calling someone else to report the issue. It is also hard for project managers to get an overview of which issues have been handled or not when the issues are not submitted and updated instantly when handled. To solve the issues presented, development of a mobile application is proposed, which would enable users to instantly manage issues without delay or workarounds.
1.3
Aim
The purpose of the project is to develop a standalone mobile application for issue manage-ment using SIRS. It should be possible to add and view issues, as well as taking pictures and attach files to said issues. The application should be user friendly and integrate as tightly as possible with the existing back end for the system without modifications. Some important goals for the project are:
• To develop a cross platform mobile application (Android and iOS) which integrates with the existing SIRS functionality.
• The application should provide the same functionality as the desktop version regarding issue management, such as viewing, adding and editing issues.
• The application should present the issues in a meaningful way without it feeling clut-tered.
1.4
Research questions
The questions to be answered during the project were as follows:
1. How can a standalone mobile application integrate with the existing SIRS/SharePoint back end without extending the current functionality of the back end?
2. Can the resulting mobile application be equally or more usable than the existing system for adding and viewing issues?
These research questions are quite broad, and as such they contain several more specific ques-tions. As an example, the second question is likely to be answered in multiple parts, such as
can users perform the same tasks as in the existing version of the system? and can users add issues equally fast or faster than using the mobile web version of the system?.
Challenges
A challenge during the project was to present the different customized support portals in the mobile application while keeping the implementation as generic as possible. The portals are heavily customizable and can contain many different features, and the application should be able to handle portals customized in different ways.
1.5. Delimitations
1.5
Delimitations
To make the project fit into the given time frame, some delimitations had to be made. The major one is that only the issue reporting functionality of the support portals is going to be implemented in the application. The portals contain a lot of different functionality, which would take much time and effort to implement in mobile form. Another delimitation is that a minimum of changes will be made to the existing system during the project. The idea will be to investigate what can be done using the system in its current form, and provide information of possible steps to be taken if one would like to expand this to a more full fledged mobile application. If some functionality is found to be missing in the current system that is critical to the implementation of the mobile application, the simplest possible solutions will be preferred to maintain focus on UX and usability throughout the project.
2
Theory
This chapter will explain and discuss some background theory for the project to make the reader familiar with the concepts discussed.
2.1
SharePoint
SharePoint is a collaborative web platform developed by Microsoft [1]. It is mainly used for document management, but it is highly customizable and can be used in many different ways. The basic structure of a SharePoint application is to have a top level site with one or more site collections, which in turn contains sub sites. This structure is illustrated in figure 2.1 [2]. The content of a SharePoint site is kept in lists, where each entry is called a list item. A list item in turn contains different columns, also known as fields, which hold the actual data. These columns can be of either inbuilt or custom types, which in the case of the latter often provides extra functionality. Some examples of built-in field types are plain text fields and date fields. In the case of this project, there is quite a lot of custom functionality utilized, especially concerning the issue management part which is described below. Many of the field values are calculated from dynamic data, resulting in more or less complex behavior.
2.2. SSP
2.2
SSP
The main way that Saab customers and partners are handling their support matters is through Saab Support Portals, abbreviated as SSP. These support portals are accessed through a web browser, and are used to provide general support and other services to users of Saab products, as well as to Saab employees. The support portals are built using SharePoint, where all the portals are unique Site Collections available from a main site from which users can choose which portal to visit. The purpose of a support portal is to be a central hub for support issues, where users can find all necessary information about products. This information can be anything from product documentation such as manuals, to contact information or product news. An example of a support portal is shown in figure 2.2. As can be seen in the figure, there are some different functionality available. Which features that are available in a portal is customizable, and will differ from portal to portal. Some of the most used features are the news feed, product documentation and issue management. When a user is registered to a portal, he or she is assigned to the company where they work, and they are also assigned a role. These roles can be for example reader, contributor or administrator, and they control what parts of the site that the user has access to, as well as to which lists they can contribute to. Although there are a lot of interesting features available, the main focus of this project will be the issue management part of the portals. This functionality is often used by service technicians to report issues and problems with products, and is therefore a central part of support handling.
2.3
SIRS
SIRS, which is short for Saab Issue Reporting Service, is the issue management system used in Saab support portals to handle support issues and other similar content. SIRS is custom made only for this purpose, and as such the system is quite unique. SIRS is used alongside a SharePoint list that contains the actual list items, which can be anything from support tickets to contact information. This list functions essentially the same as a standard SharePoint list, with the exception of some specific field types and permissions. SIRS can be used on multiple lists on a site, with each of these being referred to as a SIRS instance. Using SIRS, portal administrators can customize in great detail how the items in the list are presented to different users and who can view and edit them. There is functionality available to present certain information to specific users, often depending on which role the user has or which company they belong to. For example an administrator for a company may have access to detailed information about all items in the list, while some other role may only be able to see basic information such as the date and title of the item. SIRS can also specify which fields are visible when viewing a list item depending on the values of other fields. A fictional example is that the field customer approval may only be visible if the value of the field issue status is set to Awaiting customer approval, so that users can approve a solution to an issue only if a solution is provided.
2.4
Current system
When visiting a support portal using the current system, the user is presented with a menu bar for navigating inside the portal, and beneath is a news feed. This system is tailored to desktop devices, and uses for example menus which open when the user hovers the mouse over the element. The desktop design choices also becomes apparent when a portal is viewed from a mobile browser, see figure 2.4. Bear in mind that this will be presented on a small mo-bile screen. The UI is the same as on a desktop, which makes the site quite hard to navigate. When at normal zoom level, the text is very small and is hard to read. When zooming in, there is a lot of scrolling required both vertically and horizontally because the site is not responsive.
2.4. Current system
It is also quite hard to press the right buttons because they can be quite small compared to what mobile users are used to. The hover actions utilized are also not very easy to use on mo-bile devices, because when clicking the top level element, the user is redirected to the section clicked instead of opening the menu. However, because the site is not responsive, this also means that all the features available on the web are also available through a mobile browser which makes it fully functional.
Figure 2.2: Landing page of a support portal
2.5. UX
Figure 2.4: Mobile version of the helpdesk list
2.5
UX
UX, which is an abbreviation for User Experience, is a term commonly used in software de-velopment. It is often confused with User Interface, but these terms differ significantly. The UI of a product is only the interface itself, and not how it works or behaves. UX is a broader term which consists of many elements such as interaction design, usability and visual design. UX can be hard to define, but a definition made by M. Hassenzahl is that UX is "a momen-tary, primarily evaluative feeling (good-bad) while interacting with a product or service" [3]. When applied to software, good UX can also be thought of as how to get a user to where they want in the minimum number of clicks or using minimum effort, which ties in with usability explained below. Another aspect is that UX should be enjoyable to the end user. A user that enjoys using an application is more likely to continue using the product, as well as recommending the product to others [4].
2.6. User centered system design
Usability
A common term in the scope of UX is usability. Usability is a term which was introduced to general usage in the early 1980s, and similar terms at the time were ’user friendliness’ and
’ease-of-use’. Since then, usability has replaced these terms in most contexts, both professionally
and technically [5]. According to ISO 9241-11 usability is defined as the "extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use" [6]. This is the definition that are going to be used for the rest of this report. Effectiveness is defined as "accuracy and completeness with which users achieve specified goals" and efficiency as "resources used in relation to the results achieved". The term satisfaction is defined as the "extent to which the user’s physical, cognitive and emotional responses that result from the use of a system, product or service meet the user’s needs and expectations" [6]. When comparing usability to UX, one can think of usability as a subset of UX. Usability boils down to the user achieving specific goals when using a product, while UX is the experience of using the product which can include things like behavior of the system or design. However, an earlier definition of usability is one formed in 1981, which boils down to that it is easier to measure the difficulties that people have using a product than to measure ease of use. Therefore one can think of usability as inversely proportional to the number of difficulties a user has when using the product [5]. On the subject of difficulties, Donald Norman states that it is when problems occur that a good design is the most important. It can be quite easy to design a product if everything goes smoothly, but when something goes wrong the design is really put to the test. Developers and designers should focus on handling these situations well, to make the interaction between the user and the product feel as smooth as possible. The interface should highlight the problem to make the user understand the issue, and also solve the problem properly [7].
2.6
User centered system design
When developing software for end users, a common approach is to use User Centered System Design, UCSD [8]. User Centered System Design is an iterative development process where usability and UX is in focus. In short, the process consists of four main parts. These are
Analyze requirements and user needs, Design for usability, Evaluateand Feedback. An illustration
of this process is shown in figure 2.5 [8]. The process begins with gathering requirements and needs that the users might have, followed by a planning phase where an initial concept for the product is constructed. After this a design is created by using prototyping, which is explained later below. This design is then evaluated, often by user testing, and the feedback is analyzed and used to plan the next iteration of the process. The following sections explain the parts of this cycle more in depth.
Analyzing user needs
When working with development of products which aim to have a high usability, it is critical to know who the product is for and what their needs are. According to Mike Gualtieri, there are four key points to have in mind when getting to know your users [4]:
• Listen to their needs
• Observe them in their natural behavior • Create personas
2.6. User centered system design
Figure 2.5: Illustration of user centered system design
To analyze the users’ needs, interviews can be used as a first step. This way one can get the most prominent information by letting the users share their own thoughts. An important aspect to keep in mind when listening to the users’ needs is that the users are the people who will actually use the product, and not the stakeholders. It is therefore important to find out what these people want, and not what someone else think that they want. Because users cannot always put what they want into words, it can also be useful to just observe the users in their natural habitat.
Personas
A challenge during software development is to make sure that you are designing for the correct audience. A common technique for accomplishing this is to use personas. Personas are made up characters who should represent the users that the product is designed for. Personas are based on the results from studying the users and analyzing their needs. To make the research data into a persona one should give the persona a real name and a picture to represent them. Each persona should also have a brief description of who they are and some of their characteristics [4]. There are several types of personas, with some of them being [9]: • Focal persona • Secondary persona • Unimportant persona • Affected persona • Exclusionary persona
2.6. User centered system design
These are all different types of personas, which have some kind of connection to the product being designed. The focal persona is a primary user of the product, and it is in most cases these personas for which the design is optimized. Secondary personas are also users of the product, but they are not quite as important and the design will be made to satisfy them when possible. Unimportant personas are those who either is unauthorized or simply misuse the product. Affected personas are people who will not use the product directly, but will still be affected by it. Exclusionary personas are the people who the product should not be designed for. This can be handy to keep ideas that does not improve the product away from the project [9].
Personas have been claimed to have an evidently positive impact when incorporated in the user centered design process. Some of the main benefits are an increased audience focus and good prioritization of product requirements. This helps to bridge the gap between designers and consumers, which tend to be a problem area during user centered design [10]. It is common for developers to think that they know what the user wants, when this is often not the case.
User stories
An important step of any software project is effort prediction, which is the process of esti-mating the amount of work and the time it will take. As stated in [11], the most common form of effort prediction is subjective estimation, at least in agile projects. This method re-lies on experts’ assessment of the tasks to be implemented. The method is easy to use, but the estimates can differ quite a lot depending on who makes the estimate. An experienced developer might estimate the effort quite accurately, but for more junior developers another approach might be a better choice. To solve these subjectivity variations, a method often used is user stories. User stories is a method for representing the requirements of a customer from their own perspective, often used in agile development. Such stories follow the template "As
a <role> I want <goal> [so that <benefit>]"[12]. However, they are often used while omitting
the benefit part. Each user story is linked to a feature in the application, describing a goal that the user wants to accomplish. In the cases where the benefit part is included it is also of interest why the feature should even be implemented in the first place. User stories are then usually placed in a backlog where they are prioritized by importance.
There has been little research done investigating the effectiveness of user stories, but in a study carried out by Lucassen et al, a majority of users reported improvements in work pro-ductivity using the method. The study shows that user stories makes it easier to develop the right software for the purpose. The requirements get more clear, and the team gets a com-mon understanding of what the product should accomplish. User stories does not necessarily make the development process any faster, but will prevent faults in the product which would take time to fix instead [12].
Prototyping
When making a design for a product, a common technique used is prototyping. A prototype is a representation of a design before any final artifacts have been developed [13]. Prototypes can be of different kinds, such as simple paper sketches or interactive computer prototypes. The decision of what type of prototype to use can be affected by several factors, such as budget limitations or time constraints. This often results in the use of simpler prototypes, such as paper prototypes because they are faster to build [14]. The purpose of a prototype is to be able to test a design without actually implementing it, often resulting in the ability to make quicker changes to the design. The idea is that the prototype should either look, work or behave as the product being designed.
2.7. Saab graphic profile
Usability testing
To make sure that a product fits the target audience it is important to do usability testing. The main purpose of this is to make the product more usable. Some defining features of a usability test is that an observer is watching the participants performing the tasks handed to them using the product being tested. The broadness of the terms usability and usability testing will therefore allow for a variety of different approaches when conducting usability tests. Usability tests can be said to include a multitude of elements, which answers different questions about the product. Some of these elements are Learnability, Efficiency, Memorability,
Errors and Satisfaction[15]. Learnability is a measure of how quickly a user can get up to
speed using the product, and if they can accomplish desired tasks when using the product for the first time. Efficiency tells the tester how fast an experienced user can accomplish tasks using the product, and memorability how well users perform when returning to the product after a period of time. Errors are bound to how error prone the product is, as a measure of how many errors users tend to make and if they are critical. The last point, satisfaction, is an important one considering that if users are not satisfied with the product and do not enjoy using it, they will probably be less interested making compromises and adapt to the product. This measure is probably the hardest one to actually measure, because satisfaction is quite subjective.
When conducting usability tests there are two main approaches for gathering data, namely quantitative testing and qualitative testing. While conducting quantitative testing, data col-lected from the test should be measurable and preferably numerical. In this case, the first step is to decide what measurements that are appropriate for the test. Some central metrics that are commonly used are successful task completion rates, task completion times and sat-isfaction ratings from the users [5]. This kind of testing is usable when evaluating how well users can perform the tasks presented in the test, and how they performed compared to an optimal performance. On the other hand, qualitative research can also give valuable infor-mation about the product and how it is perceived by users. This inforinfor-mation can be gathered in different ways, such as interviewing the users or making them think aloud during the test.
2.7
Saab graphic profile
The Saab graphic profile is quite simplistic, and aims to give a serious and professional im-pression. The profile is used mainly on Saab’s external website at the moment, and primarily aims to be appealing to the users. The color palette utilizes mainly black and different shades of gray, with elements of blue and orange. For shapes, mostly squares and rectangles are used which all have sharp edges and corners. The whole UI is based on flat design, with minimal utilization of height and shadows. Grids are also commonly used throughout the interface. This gives good separation between different elements on the site. The graphic profile for the support portals however are a bit different from the external web site. They do not feel quite as flat and modern, and are more suited for maximum functionality instead of being enjoyable. Because the portals are built using SharePoint, a lot of the design is recognized from how the SharePoint layout looks.
As for this project, the goal is to unite the functionality of the support portals with the graph-ical interface of the Saab external website. A challenge will be to make the users recognize the functionality from the support portals when presented in the more modern UI.
3
Method and Implementation
The focus during the implementation part of the project was to have a working version of the application at all times. This was done to always be able to show the progress during development and to follow a user centered design process.
3.1
Saab mobile app strategy
As part of the project, a small scale study of the Saab mobile app strategy was made to in-vestigate how this application would fit into the current ecosystem. In the study, two Saab IT employees were asked to give a brief description of the current strategy. The interview concluded that as of now, the mobile strategy of Saab is not very specific. The long term goal is to provide as much internal functionality as possible in a single application, but as of now this is not the case. There are several applications used for different purposes, such as time reporting, and as such there is no major strategy to keep in mind when developing new applications.
3.2
The design process
The first main task in the project was to find out what was actually going to be developed. To figure this out, it was critical to get to know what the users’ needs were and what they would like to accomplish with this kind of application.
Listening and observing
To investigate what features should be implemented in the application, a prestudy was con-ducted early on in the project. The study consisted of an interview with a user of the current SIRS system, who was working as an administrator. The main target audience of the appli-cation is service technicians who handles and services Saab products, and this study aimed to get an overview of their working conditions and preferences. From the study it was found that the users are generally inexperienced with computers and other mobile devices, and were more comfortable with physical items and controls. This had to be taken into consider-ation when designing the app, to minimize the friction for the user to execute actions. This
3.2. The design process
also meant that users did not want to learn a completely new system, and it was a request that the application was somewhat similar to the current SIRS system. It was also found that users from the target audience were often working in remote locations, often without cell coverage. Therefore they thought that offline support was an important feature to implement in the application, so they wouldn’t have to worry about if they had an internet connection or not. Another aspect was that as the users were often working outside when servicing and investigating products, and as such the weather can also play a role in how the application should behave. For example if it is a cold and rainy day, a user would probably want to re-port the issue as fast as possible as he or she is in an unpleasant environment. An interesting aspect would have been to observe the users in their natural habitat doing their work using the current system. Unfortunately this was not possible to do in the scope of this project, because the actual users often work in remote locations.
Personas
After the initial user study, two personas were created based on the information acquired. These were used to verify the application during different stages during the development to make sure it provided the correct functionality. One of the personas were made into a
focal persona, which is a primary user of the product [9]. The purpose of focal personas is
to optimize the design for them, and as such this persona was the highest priority. In this case the focal persona was an engineer who works with reparations of radar equipment. The second persona was more of an affected persona, which is not necessarily a direct user of the product [9]. However, they will still be affected by the product in one way or another. In this specific case our affected persona is a project manager, who administrates issues using SIRS. This affected persona may notice a change in work flow because the primary persona’s behavior when reporting issues is different. The focal persona is shown in figure 3.1.
3.2. The design process
When the personas had been created it was time to empathize with them. The personas were used to make a mental walkthrough of their current workflow while using SSP and SIRS. By doing this it was possible to figure out what features were needed in the application and how to prioritize them.
User stories
Based on the personas constructed previously, user stories were formed to represent the fea-tures needed in the application to satisfy the needs of the personas. The main focus was to meet the needs of the focal persona, which is a direct user of the product. The secondary per-sona was also kept in mind, but de-prioritized due to the fact that the design of the system would not impact his or hers way of working directly. The needs of the persona were divided into smaller pieces, which in turn formed the user stories. For example, the personas wanted to view their support tickets in the portal. This task might seem simple at first glance, but was divided into smaller sub-tasks. The stories formed from this task were
• As an engineer I want to log in to my account
• As an engineer I want to choose which support portal to visit
• As an engineer I want to view my support tickets in the specified support portal
This process went on until all user needs had been divided into user stories of reasonable size.
Backlog
When the user stories had been constructed, they were used to create a backlog of features to implement. Because each user story might depend on several features being implemented, each user story was investigated and it was decided what tasks needed to be accomplished in order to satisfy the user story. The tasks were also prioritized to make sure the effort was put into the most important features. These tasks were then mapped to distinct features which should be implemented to satisfy the user story. Each week, new tasks were moved into the Doing list to show what was currently being worked on. The purpose of this list was to estimate which tasks could be done during the following week. When a task was done, it was moved to a Done list containing tasks that had been completed during the week. At the end of the week, completed tasks were archived. This process continued throughout the project.
Prototyping
To make sure that the application ended up in a way which suited the users, prototyping was used. Early on in the project, some simple sketches were made on paper to get a feeling for possible design choices. This process was used mainly to try out ideas that came to mind without having to implement them. These sketches were then translated into digital versions using the prototyping software Adobe XD [16]. XD allows for making prototypes interactive by providing navigation between different screens, which makes the prototype more similar to a real app. Different transitions such as swipes and fades can also be implemented for emphasizing UX features. Figure 3.2 illustrates the first version of the prototype made in XD, which did not have any interactive elements. It features a login screen, a home screen with an overview over the user’s support tickets and a screen for adding new tickets. The company to which the user belong is displayed at the top in the navigation bar. The main focus during the whole prototyping phase was to make the user recognize the different elements from the web version of the system, while still keeping the design mobile friendly. For example the same fonts were used and the input fields kept approximately the same look.
3.2. The design process
Figure 3.2: First version of the prototype
This version utilizes some colorful elements, such as the blue and orange button which have the purpose of getting the user’s attention. At this stage of the process no tests had been conducted yet, so this prototype is solely based on the Saab graphic profile and some func-tionality existing in the support portals. When creating the next prototype version, it was decided that a more simplistic design was more suitable. Therefore the colorful elements were made into shades of gray, with the only touch of color being the progress bar at the top.
3.3. Implementation Approach
After these interactive prototypes had been reviewed again, a basic UI was implemented in code. The code implementation was similar to the second prototype, which had received positive feedback. This was the end of the actual prototyping phase, although the UI was still evaluated continuously later on.
3.3
Implementation Approach
The first choice to be made regarding the implementation of the application was to decide if it was enough to make the current website responsive and mobile friendly. This way all the support portal functionality would already be present, which would be a large benefit. However, using this approach it would be hard to implement device specific features such as offline support and the ability to attach files, for which an actual app is a suitable choice [17]. If the app later on would have more functionality implemented, such as push notifications, it was also considered an advantage to have an app foundation ready. Therefore it was decided to develop a mobile application to be able to utilize such features, as they were requested by users as found in the user study.
3.4
Tools
When the decision had been made to develop a mobile application, the time had come to choose the tools to use. Because it was requested that the application should run on both Android and iOS, the application would be cross platform. When developing a cross platform mobile application there are several possible approaches. During this part of the project, a comparison was made to decide what tools would be suitable for the project.
Mobile app taxonomy
To be able to separate the different types of mobile applications, taxonomies have been formed providing naming for these different types. A recent taxonomy proposed by R. Nunkesser is illustrated in figure 3.4 [18], which divides mobile applications into six main categories. These are the ones surrounded with solid lines in the figure. This taxonomy will be used below to distinguish different approaches evaluated during the project.
Figure 3.4: Mobile app taxonomy by R. Nunkesser
Native development
The first and to this date most common approach is to develop the app natively for each platform that it should support, i.e an endemic app. For this, the programming languages used for the different platforms are Java/Kotlin for Android and Objective-C/Swift for iOS. Because the author’s experience was virtually none with both Objective C and Swift this approach was estimated to take a lot of time. The benefit of the native approach is that
3.5. Development
the performance of the application is very good, and the developer has access to all device specific features. A major drawback however is that the developer has to write code for the same functionality twice to support the two different platforms, which often is quite time consuming.
Web based apps
Another approach is to use web based solutions for developing the app. This can be either pure web apps, which are essentially web pages optimized for mobile phones, or it can be hybrid web apps which utilize an endemic shell [18]. There are several different frameworks for developing such apps, and examples are Adobe Phonegap and Apache Cordova. Using this technique, the application is written as a web page and utilizes common technologies such as HTML and CSS. This technique often makes for fast development, as most web de-velopers can get up to speed quickly. A drawback of this approach is that the performance of the application is often worse than if it was developed using native code. The communication between the application and the device features, such as the camera, is often very limited as well.
Foreign language app
An approach for developing to multiple platforms is to build a foreign language app. This is done by using a language which is not endemic to the mobile OS [18]. An example of this is the framework Xamarin, which uses C# to write applications [19].
React Native
In the end, the choice of tool for the project fell on React Native [20], which is classified as a
Hybrid Bridged Appin the taxonomy used. React Native is JavaScript framework for building
mobile applications for both Android and iOS. Apart from the web based frameworks, React Native is currently the most used cross platform framework, both for hobbyists and profes-sionals [21]. It differs from web based solutions by providing the tools for building native apps for both platforms while still sharing large parts of the code base. Using this approach results in good performance and easy access to device specific features, such as the camera and photo gallery. The code is written mainly in JavaScript, but developers can also write na-tive code for the different platforms to utilize specific features. The JavaScript code is written using JSX, which is a syntax for embedding XML into JavaScript. This looks very similar to standard web code such as HTML, with the main difference being that React Native is not using <div> and other containers familiar from the web development world, but instead uses its own set of components [20]. A main advantage of using React Native is that web devel-opers will recognize a lot of the techniques used, especially if they are familiar with front end frameworks such as React.js. React Native is also very flexible, as the components used can be styled using style parameters very similar to CSS.
3.5
Development
REST API
As a first step when starting the development, it was investigated which data was available to fetch from the SharePoint system to a stand alone application. For these purposes, Share-Point provide a REST-API through which a client can communicate with the ShareShare-Point back end [22]. This API is accessed through HTTP-requests and can as such be used from many different programming languages. The API has support for CRUD-operations, (Create, Read,
3.5. Development
The API is also well documented and established, making it easy to find the available end-points and how to access them. This API was used as much as possible for fetching the data needed to keep things simple. Examples of data which was possible to fetch in this manner is lists, list items and information about users. The API is using the same permissions as when a user is logged in to the site, meaning that if a user has access to a specific list on the web, the user can also fetch the same list using the API. The api can return data either in XML,
(Extensible Markup Language)or JSON, (JavaScript Object Notation) format. Because the
appli-cation in this project is written in JavaScript, JSON was chosen to minimize the effort when parsing the data. Examples of data that was fetched using this method is the lists containing the support tickets and information about which fields should be displayed when viewing or creating a ticket. When making POST requests using the api all parameters being sent were put into a JavaScript object, which became the body of the request. The client also had to provide a Request Digest. This is a token which tells SharePoint that the request is valid [23]. However, all data needed was not available using REST. When getting the data for the field type Managed Metadata a SOAP call had to be made to another SharePoint web service. SOAP is an acronym for Simple Object Access Protocol and is based on XML.
Authentication
To make it possible for the application to communicate with the API, some kind of authenti-cation had to be implemented. This proved to be quite challenging, as the SharePoint instal-lation is placed behind a load balancer provided by F5 networks [24]. When users are navi-gating to the Support Solutions Portal main page in a web browser, they are prompted with a login page where they enter their credentials. When logged in, a session cookie is stored in the browser to indicate that the user has an active session. As long as this cookie persists, the user is able to access the web site. This works fine in web browsers, however when trying to access the REST API directly from another client there is no UI to fill in credentials. In these cases it is common practice to utilize some kind of authentication directly using an API end-point, but no such endpoint is available for this system. Instead, a workaround solution was implemented using a WebView inside of the mobile application. A WebView is simply put a web browser which is displayed as a component inside of the application. This WebView opened the login page and through this the user could fill in their credentials and receive the session cookie. This cookie was stored in the application, and was then sent with each subsequent API request to authenticate the user. The user’s credentials were also stored in a secure key chain to make it possible to implement auto re-login if the current session expired.
SharePoint field types
When fetching data from the SharePoint rest API much of the data can be returned in a single request. A common request looks as follows: someurl/Lists/listname/items, which returns all items in the specified list. In most cases, the value of the item fields are returned alongside the item. But some field types require special treatment, such as Lookup fields and Managed
Metadata fields. The data for these fields are not returned as part of the query, as it is stored
somewhere else on the site. Therefore one has to find the ID for the list where they are stored and fetch the data from there in a second API request. This in turn led to a lot of API calls to get all the necessary data, but to not make the application slow and unresponsive, all these calls were made when the app first launches. This minimizes loading times when the app has already launched, keeping the performance and smoothness consistent.
To accurately make the mobile app behave as similar as possible to the desktop interface, the different SharePoint field types had to be mapped to components suitable for representation in a mobile device. SharePoint by default includes some standard field types, but users also have the option of creating custom fields which behave in a specific way. Common fields
3.6. User testing
such as plain text did not need any special treatment, as they were just represented as text input fields in the same way as on the web.
This is most notable when looking at the field type Managed Metadata which on the desktop version is built using a selection tree. This is not an element commonly seen in mobile appli-cations, and is therefore presented as a list in which the user can navigate up and down the levels while maintaining a clear overview.
Display settings
When a user is viewing or adding an item in a SIRS list there is some custom logic deciding which fields that should be visible. Administrators of the support portal can customize these settings at any time, and the list view should update accordingly. Factors that can affect what fields are shown are for example what role a user has or what company they belong to. This logic is written in C#, and is rather complex. The code is executed server side and as of now there is no easy way of getting the computed display settings through HTTP-requests. One could implement a web service to get this data, but that is out of the scope for this project. However, through the rest API one can access a string with the settings made in the support portal, which in turn is used to make the calculations. Using this data, the code handling the logic was ported from C# to JavaScript to make it possible to do the execution client side instead, as React Native applications are developed using JavaScript.
Adding items
The UI for adding items is kept as simple as possible to not make it feel cluttered. All the input fields is presented in a scrollable view to minimize the number of different screens the user has to navigate to. All required fields is marked with an asterisk (*) to indicate that they have to be filled in before submitting the item. If a required field is not filled in when the user tries to submit the item, a toast is shown telling the user that a required field is missing and which field it is. This is shown in figure 3.5. The same behavior occurs when a user is offline and tries to submit an item. He or she will then be notified and the item is saved as a draft for later submission when an internet connection is detected. This behavior should satisfy the user as an error occurred, and the user was notified of what the error is and how to solve it [7].
3.6
User testing
To further make sure that the product being developed actually satisfied the user’s needs, a user test was conducted. The main purpose was to test the usability of the mobile application and compare it to the current mobile web version of the system. The test was conducted using a high fidelity prototype of the product, so that the test persons could get a feel for the actual usability rather than using some lower fidelity version. This way the test persons would not be distracted by pretending they were using a cell phone while actually using something else. This choice also affects the results of the testing, as high fidelity prototypes tend to result in shorter completion times for the tasks presented [14]. But because all of the tests were conducted using the same fidelity prototype, this difference is insignificant. The tests were carried out in a controlled environment, more specifically an office conference room. One could argue that this would skew the results of the test, as the users would not be distracted by factors existing in their real usage environment. However, it has been claimed by Kaikkonen et al. that testing in a lab versus in the field not necessarily affects the results of the test. In their study the number of problems that occurred during the test was consistent
3.6. User testing
Figure 3.5: Error message when a required field has no content
between the two different environments, and the severity of the problems encountered was also the same [25].
Before the actual user testing was conducted, a pilot test was done. This was done to make sure that the test did not have any major flaws and that the tasks were possible to complete. After this test some smaller changes were made to make the test more fair. For example, when using the mobile website the navigation menu did not behave as would be expected in a production environment. As this menu relies on hover-functionality, a problem was discovered when using mobile phones which do not have the possibility to use such actions. When the user was clicking an item in the menu, he or she would get to a blank page instead of opening the menu. To solve this, the portal menu was adjusted to make one click take the user to the desired page.
Metrics
The user test was designed such that it would provide both quantitative and qualitative re-sults, to cover both objective usability and subjective opinions. The first step was to decide what metrics should be used, as well as what questions the test should answer.
Quantitative metrics
Because the aim of the test was to test the usability of the system, the metrics used were taken from the ISO definition of usability [6]. The main quantitative metrics for the test were as follows:
3.6. User testing
• Number of interactions to solve a specific task • Task completion time
Metric one and two here is directly related to the term effectiveness, which we previously defined as "accuracy and completeness with which users achieve specified goals" [6]. The third metric is measuring efficiency instead, which has been defined as "resources used in relation to the results achieved", with resources in this case being the time taken to complete the task at hand.
The first and arguably the most important metric is if the user is able to complete the task at hand. If not, the product is probably not very usable. This metric is straightforward, as the answer is either yes or no. The second metric is the number of interactions needed to com-plete the task. An interaction was counted as clicks, excluding text entries that the user made to make sure that the tests were consistent between sessions. Scrolling and panning were also excluded from this number. The number of interactions was compared to the optimal number of interactions needed to give a ratio of how efficiently the user was able to solve the task. This number is defined as
interaction ratio= userinteractions
optimal interactions (3.1)
and will be referred to as the interaction ratio. The closer to one the ratio is the less unnecces-sary interactions are made. The third metric is the task completion time. This is the time from when the user begins executing a task until they feel that they have completed the task.
Qualitative metrics
Regarding the qualitative metrics, the questions to answer were of more subjective nature. The qualitative questions to answer included:
• Would new users prefer the desktop interface or the mobile application? • Would existing users prefer the desktop interface or the mobile application? • Is the application compatible with the Saab graphic profile?
The usability metric most closely related to these questions was satisfaction. Both metric one and two above were measuring satisfaction, with the third not being directly related to usability.
Test execution
When the metrics for the test had been decided it was time to do the actual testing. A total of eight users participated in the test, with half of them being familiar with SIRS and SSP and the other half was not. The users were presented with a written description of the test arrangement to make sure that all users were on equal terms before the test. It was made clear that the users would be timed when executing the tasks presented, and that they should solve the tasks as efficiently as possible while still being accurate. As time was scheduled afterwards for general discussion, the users would still have room to tell their opinions. The results from the test was thought to depend quite a lot on the specific user and their back-ground. Therefore all users were asked if they were familiar with the current system or not. This would give some background info to compare the test results to.
3.7. Project management
When the users felt ready to begin the test, they were presented with the first task. They were given time to read the task and when they had done so, a timer was started. During the task execution, the test leader observed their usage of the product and counted the number of interactions the user made. No questions about the test or product were answered at this time to keep the users on equal terms. When the user felt that they had completed the task at hand they told the test leader, the timer was stopped. This process continued for all tasks until the test had been completed. After all tasks were completed the users were given another survey to answer some questions regarding the test. Along with this survey an open discussion was held where the users had the possibility to give their own opinions. The actual tasks for the test along with the survey can be found in appendices A and B.
A main goal of the test was to compare the mobile application to the mobile version of the current system. This would give valuable data on if the product being developed actually gave an advantage to what already existed. Therefore the test execution included both sys-tems, with the same tasks being given to the users for both of the systems. This means that the user first tested one of the systems, and then moving on to the other one. To minimize bias towards any of the systems, half of the test users started with the current system and the other half with the mobile application.
3.7
Project management
To keep track of what was going on during the project, the project management tool Trello was used [26]. Trello is based on boards, which in turn contain lists. Lists used in this project were Product Backlog, Doing and Done. Each list contains cards, which can be seen as tasks. Tasks that should be done were added to the backlog and categorized by the type of task, e.g. UX or Coding. This Trello board was used as a base during the weekly meetings with the supervisor at Consid, to make sure both parties had an idea of how the project was going and what tasks were being handled at the moment.
4
Results
This chapter will present the results of the project, both regarding the integration with current systems and usability of the final application.
4.1
Development
The implementation during the project resulted in a mobile application running on both iOS and Android. Using the application, users are able to log in and access their support portals and utilize the issue management functionality. It is possible to view the SIRS lists which the user has access to, as well as adding new issues. The application enables the users to have a more mobile workflow, allowing them to view and report issues without having access to a desktop computer. The application interprets the different field types for an item and pro-vides mobile friendly versions of them. Some screens from the final application is shown in figure 4.1. The first screen is the home screen, which is presented to the user after logging in. Here the user can get an overview of which company they belong to, as well as which portal and SIRS instance that is selected at the moment. The user can also select to view the items in the list and add new items. These buttons have another color to distinguish them from the rest, as well as a small arrow indicating they provide some kind of navigation feature. Pressing one of these buttons will take the user to the corresponding screen for viewing or adding tickets, also shown in figure 4.1. When viewing the list of items, there are a couple of fields that are shown without selecting the item. Which fields should be shown here can be customized in the support portal by providing a mobile view with the specified fields. If this view does not exist however, only the title of the item is shown.
The application simplifies the process of issue management using SIRS by providing a clear interface which is implemented using the Saab graphic profile.
4.2
Usability
An overall goal during the project was that the application should be highly usable and present the content in a user friendly way. The results from the usability test showed that the mobile application is comparable to the current system in terms of usability. The time
4.2. Usability
Figure 4.1: Final version of the application
taken to complete the tasks differed among the users, with some being quicker using the app and some being quicker using the web version. On average though, the users already fa-miliar with SSP/SIRS were faster in all tasks with the exception for one. This is particularly prominent when using the mobile web, where the difference in average completion time is quite clear.
All users managed to complete all the tasks, and the average completion times for the tasks are presented in figure 4.2. This includes both the mobile app and the web version, and it is simply the average times for all participants in the test per task. Here we can see that for both task two and three, the average time to complete the task is almost identical. However, in task one there is a quite significant difference.
4.2. Usability
The interaction ratio was generally higher for the mobile application, as can be seen in figure 4.3. As seen in eq 3.1, an interaction ratio closer to 1 means the user chose a more optimal path for solving the task. This means that the users made unnecessary interactions more frequently in the application than on the web.
Figure 4.3: Interaction ratio per task
Regarding the more subjective metrics, the overall rating given by the users for the mobile application is shown in figure 4.4. This indicates that the users were overall pleased with the application with some minor complaints. All users also responded that they would prefer to use the mobile application for this kind of tasks instead of the mobile web.
5
Discussion
This chapter will discuss the implementation of the project as well as the results. It will also describe challenges encountered and solutions to problems.
5.1
Results
The application developed during the project is a proof of concept of what can currently be accomplished using the existing system for SSP and SIRS without any modifications. How-ever, if one wants to use the app for production purposes there are some things that have to be fixed.
Implementation
Most of the features which were planned to be implemented made it to the final product. Features requested from the users, such as offline support and the ability to attach images were all possible to implement. However, some features had to be discarded, mainly because they would require modifications to the existing SSP and SIRS system. The most notable feature which was not possible to implement was the authentication, which was planned to be token-based using an API endpoint. But as this endpoint was not available, the WebView approach discussed earlier had to be used instead. This is one of the major things that must be fixed before the application can be considered production ready because this approach is kind of primitive in some areas, including error handling. It is not straightforward to even check if a user is currently logged in or not, requiring some custom workarounds.
Some more proper testing of the product would also be needed, as some custom field types might not be presented correctly at the moment. There was not enough time during the project to implement logic for presenting mobile versions of all field types, meaning some unpredictable behavior might occur when viewing these fields. Such details are important as this kind of application is to be used by businesses which have high expectations regarding reliability and stability of their systems.
