T-404-LOKA, Final Project
Tempo Mobile
Árni Fannar ÞráinssonGunnar Smári Agnarsson
Sindri SigurjónssonTheodór Tómas Theodórsson
Spring 2015B.Sc Computer Science
Instructor: Hlynur SigurþórssonExaminer: Jökull Jóhannsson
Dedicated to our families.
Abstract
In this report we discuss the B.Sc project titled “Tempo Mobile”. The project wasconducted at Reykjavík University in the spring 2015 in collaboration with Tempo.In the project we created a mobile application for Tempo based on their Timesheetplug-in in Atlassian JIRA.
Review
In the beginning of 2015 we had a vision of how we could help our users have betteraccessibility to our products through mobile devices. We were very fortunate tohave a team of talented students execute this vision over the last months with greatsuccess. Our hopes were that we would have a proof of concept for one mobileoperating system but the team has exceeded our expectations and we are alreadyusing the mobile clients here in the office both on Android and iOS smartphones.The team has been very organised and periodically demonstrated their progress bothto stakeholders and the entire company working iteratively to improve the softwarewith feedback from us and through user testing sessions to refine the design, inspiringother teams to follow their lead. We are looking forward to put the software on themarket and to continue the development of the software, bringing it to even moredevices integrating with the rest of our product line.
Viðar SvanssonProduct OwnerTempo
Contents
1 Introduction 1
2 Tempo Mobile 22.1 JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Ionic Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.2 Start a tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4.3 Log work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.4 View timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Project Management 83.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3 Continues Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Usability Testing 124.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Usability Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Usability Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 BETA Testing 19
6 Future Works 20
7 Conclusion 21
Tempo Mobile
1 Introduction
Tempo1 is a company that creates plug-ins for the Atlassian JIRA2 project management system.The most popular product from Tempo is their Timesheet plug-in. Tempo Timesheet enablesusers to easily track and report their work hours in JIRA.
Over the last couple of years one of the most requested feature that Tempo received fromcustomers was the ability to use Tempo products effectively with mobile devices. In this reportwe introduce Tempo Mobile, a mobile application for both Android and iOS that gives users theability to access features from Tempo products through a mobile application.
Tempo mobile exposes the core functionalities provided in Tempo Timesheets, such as track-ing and managing work hours and retrieval of time sheets. Over the course of this project theteam and Tempo employees thought of additional features that could be added to the application.
Tempo emphasized on the usability of the application and that all actions are simple, intuitiveand take minimal time for the user. With that in mind it was decided that the best way to fulfillthat requirement was to conduct two identical usability tests, with two different groups of people,where users would perform predefined tasks. The goal of the first usability test was to gatherfeedback from users along with measurable data. In the second usability test the goal was toconfirm if the changes made to the application between tests were based on correct interpretationof the data gathered from the first test.
After the first usability test we got constructive feedback from the users on what they wantedto see in the application. Too many users encountered problems while solving tasks and neededassistance. With all the information gathered we tried to improve the application and empha-sized on trying to reduce the number of users that needed assistance. After the second usabilitytest the results showed that almost all measurable data had improved between tests and mostimportantly the number of users that needed assistance was drastically reduced.
This report is structured as follows, in section 2 we discuss the project management systemJIRA, Ionic the framework used to build the mobile application, the architecture of the productand core functionalities. In section 3, we discuss the project management where informationregarding our work plan for the project, what methodology was used during the developmentand high level development tools used. This section is concluded with results on how well wefollowed our work plan and a general discussion about tools and methodologies used. In sec-tion 4 we discuss both usability test executions and their results. The section is concluded witha discussion on the tests. In section 5 we discuss BETA testing conducted on the applicationand its results. In section 6 we discuss what the future of Tempo Mobile looks like and whatfeatures we would have liked to implement given more time. Finally, the report is then concludedin section 7 with a general conclusion of the project.
1https://www.tempoplugin.com2https://www.atlassian.com/software/jira
1
Tempo Mobile
2 Tempo Mobile
Tempo Mobile is an application that allows users to perform the core functionalities available inthe Tempo Timesheets plug-in in Atlassian JIRA through a mobile device. The application isdeployed on both Android and iOS devices using the Ionic framework3.
In section 2.1 we give a brief overview of JIRA. In section 2.2 we talk about the framework wechose to use. In section 2.3 we discuss the architecture of JIRA and Tempo and the project ar-chitecture. The section is concluded with an overview of the core functionality of the applicationin section 2.4.
2.1 JIRA
JIRA is a powerful and flexible project management software that gives managers, employeesand customers overview over incomplete projects and tasks. JIRA runs in the browser and givescompanies the flexibility to customize JIRA to their needs, methodology and business processes.Tempo creates plug-ins for JIRA and their Timesheets plug-in has long been one of the mostsought after plug-in in JIRA. Tempo Timesheets is a time tracking and reporting plug-in in JIRAwhere users can track time i.e. for billing and salary calculations.
2.2 Ionic Framework
Tempo’s initial idea was that we would build a native iOS or Android application. The teamsuggested to Tempo the use of a hybrid framework called Ionic which was accepted by Tempo.A hybrid framework, such as Ionic, allows developers to deploy the application on both Androidand iOS from one code base whereas the native approach is to write the same application twice,in Java for Android and Objective-C for iOS. Ionic is a relatively new hybrid front-end frameworkwas still BETA during development. The application is written using web technology, HTML5,CSS3 and SASS4 in an AngularJS5 project. Ionic then takes the web application and builds itinto a native Android or iOS application. Ionic offers support for ngCordova6 a platform thatoffers multiple plug-ins to access native components of the phone, for example its local storageand keyboard.
3http://ionicframework.com/4http://www.sass-lang.com/5https://angularjs.org/6http://ngcordova.com/
2
Tempo Mobile
2.3 Architecture
Figure 1 depicts the architecture of Tempo Mobile. The core of the project is the Ionic framework.Firstly, the module of the application is the AngularJS framework. The architecture of AngularJSis structured so every view has a controller. Controllers can communicate with services and theview can communicate with directives that can manipulate the DOM. The Tempo applicationuses REST API calls through services in AngularJS to communicate with JIRA and Tempoplug-ins.
Secondly, Ionic uses the ngCordova library which is a collection of AngularJS plug-ins builton top the Cordova7 API. These plug-ins give access to native features of a phone.
Thirdly, Sass is a CSS extension that allows developers to have greater control over theirstyle sheet and then compiles it to standard CSS.
Fourthly, CLI is a command line utility that makes it easy to build, run and emulate Ionicapplications by using the Gulp8 task runner.
Figure 1: Tempo Mobile architecture
7https://cordova.apache.org/8http://gulpjs.com/
3
Tempo Mobile
2.4 Functionality
We now describe four scenarios, representing the core features in Tempo Mobile. How to loginwith JIRA, how to start a tracker, how to log work and how to view your time sheet.
2.4.1 Login
The home page of the application is the “Tracker” view and the user needs to navigate to theside menu, figure 2a, to access the login screen. When a user logs into the application, figure 2b,he does so with the same user name and password he uses for the desktop version. The onlydifference is that he also has to provide the company JIRA URL. After the user has typed in allthe information needed, he presses the “Login” button.
(a) Side menu (b) Login screen
Figure 2: Navigate to login screen
4
Tempo Mobile
2.4.2 Start a tracker
When starting a new tracker the user navigates to the “Tracker” view, figure 3a, and presses the“Plus” button in the upper right hand corner. When the button is pressed a new menu animatesdown, figure 3b, giving the user information about the current tracker and a menu of actionshe can take such as seeing additional information. To log the tracked time the user presses thebutton with the "Clipboard" icon and with that he navigates to the “Log Work” view.
(a) Initial tracker view (b) Tracker view with active tracker
Figure 3: Create a tracker
5
Tempo Mobile
2.4.3 Log work
The user needs to attach a JIRA issue to the tracker and fill out the required fields beforesubmitting the work log, figure 4a. After filling out the form the user can press the “Done”button in the upper right corner. After the button is pressed the user receives feedback from theapplication if the work log was posted successfully or if there was some sort of error, figure 4b.
(a) Log work view (b) Confirmation of success
Figure 4: Log work
6
Tempo Mobile
2.4.4 View timesheet
The user navigates to the “Timesheet” view via the side menu. There a calendar view appearsshowing all the days in the current period, figure 5a. The current day is highlighted in red and isopen when the user opens the view so he can instantly see today’s work logs. In the header theuser can see additional information such as the current period and how much of his work dutyfor the period has been fulfilled. In the upper right corner there are two buttons, the “Clipboard”button to log work same as in the “Tracker” view. Additionally there is a “Calendar” button toswitch to the “Agenda” view, figure 5b. There the user can see all his work logs in the period ina different view.
(a) Calendar view (b) Agenda view
Figure 5: Timesheet views
7
Tempo Mobile
3 Project Management
In the beginning of the project we put forth a detailed plan. There we set forth the allocatedwork hours that every team member was supposed to fulfill. For the first twelve weeks of thesemester each one of us was to commit a minimum of 16 hours a week, then after the finalexams it was expected that every team member would work for 8 hours per weekday and onweekends if needed. All in all every team member was required to work around 325 hours onthe project. For support in meeting these goals we used these methodologies and tools coveredin the following sections. We used the scrum methodology where each sprint was two weeks andin total there were 8 sprints excluding the preparation phase, sprint 0. After a few weeks ofwork we estimated, based on the progress of the project, that we would be able to finish all "A"priority functionalities in the beginning of sprint 7.
3.1 Methodology
The methodology used in this project was scrum. The reason for this choice was threefold.First, because it is the preferred methodology at Tempo. Second, it fits well with the project, forexample after each sprint there was a potentially shippable product which could then be usedto implement usability tests early and get feedback from the product owner frequently. Third,scrum is a flexible methodology and is open for unclear requirements.
User stories were put in the product backlog and divided into sections (A-C) and within thebacklog they were prioritized by their importance. Story points where allocated to each storyaccording to how difficult the team perceived implementation of them to be, where the averagestory was 13 story points. Each sprint was two weeks. At the beginning of each sprint a meetingwas held where stories were put into the sprint backlog and then broken down into tasks andgiven time estimates. Each team member chose tasks from the sprint backlog to work on. Everymorning daily scrum meetings were held where each team member described his progress fromthe day before, what he was planning to work on that day and if any problems had arisen whichallowed other team members to contribute some input on his progress and/or problems. At theend of each sprint a retrospective meeting was held and tasks that weren’t finished were put intothe sprint backlog of the next sprint.
We used an on-line service called waffle.io9 as our scrum board. We connected Waffle.io toour version control which created tasks on a board for every issue created. The whole sprintbacklog was put into one column. From that column we moved tasks that were not dependanton implementation of other functionality to the “Ready” column. Then team members eitherchose or were assigned tasks from that column. Once work on an issue commenced it was movedto the “In progress” column and then the “Done” column once finished.
9https://waffle.io/
8
Tempo Mobile
3.2 Development
In section 3.2.1 we discuss the version control system used in the project. In section 3.2.2 we talkabout what frameworks were used to write unit tests. In section 3.2.3 we discuss our continuousintegration process and finally in section 3.2.4 we discuss how we documented during the project.
3.2.1 Version Control
Github10 was the version control system used during development. There the code was hostedon a private repository. All stories and tasks were also stored on Github as issues. The reasonwe decided to use Github was so that the code would be easily accessible and safely stored.
3.2.2 Unit Testing
We used a testing framework called Jasmine11 to test the JavaScript code, we then used a testrunner called Karma12 to run the tests. Karma also generated coverage reports so we could seethe test coverage for each function.
Team members were responsible for testing code locally before pushing to the shared reposi-tory on Github.
3.2.3 Continues Integration
We used an on-line continuous integration tool called Codeship13 while developing. Codeshipmonitored the Github repository and after each push to the master branch the repository wascloned by Codeship and deployed to a clean virtual machine that ran every unit test. If anytests failed we got a notification from Codeship so we could respond to broken tests as soon aspossible.
3.2.4 Documentation
Every document was saved on Google Drive14, which made documents available to all teammembers and allowed them to work on the documents simultaneously. Every document handedin was restructured in LATEX15 and hosted on a private repository on Github. Documents werethen made available to Tempo employees. Every member of the team was responsible for loggingtheir work hours in a document on Google Drive.
10http://wwww.github.com11http://jasmine.github.io/12http://karma-runner.github.io/0.12/index.html13https://codeship.com/14https://drive.google.com/drive15http://www.latex-project.org/
9
Tempo Mobile
3.3 Results
The overall code coverage of the project was 70%. Figure 6 shows the overall burndown of "A"priority stories in the project. As we estimated earlier in the project we were able to finish "A"stories in the beginning of sprint 7. Table 1 lists the estimated time for each team member andhow much he actually worked. Table 2 lists the estimated work time and actual work time foreach sprint.
Figure 6: Project burndown for "A" priority stories
Name Estimated work time Actual work time %
Árni 325 360 111%Gunnar 325 371 114%Sindri 325 370 114%
Theodór 325 383 118%
Total 1300 1484 114%
Table 1: Time summary for team members
10
Tempo Mobile
Sprint Estimated work time Actual work time %
Preperation 0 170 100%Snow White 128 172 134%
Doc 130 171 132%Dopey 146 178 122%Bashful 115 156 136%Grumpy 110 138 125%Sneezy 140 81 58%Sleepy 265 234 88%Happy 266 184 69%
Total 1300 1484 114%
Table 2: Sprint overview
3.4 Discussion
Scrum was very helpful regarding structuring the project and having a plan set up for each ofthe eight sprints. Although scrum has a lot of positives, there was one wearing thing and thatwas the daily standup meetings, they got old very fast. We had experience using all the othertools stated previously and they all met our expectations. Waffle.io is extremly easy to use anda good place for all members to get information on what’s on the agenda and what other teammembers are working on. The only downside regarding waffle.io is that you can’t estimate theremaining time of each task so you need to keep that seperatly. The standout product wasprobably Codeship mostly because of the fast build process they have. With the help of all thesetools we were able to follow the plan we set forth in the beginning of the project.
11
Tempo Mobile
4 Usability Testing
Tempo placed emphasis on usability of the application and that all actions should be simple,intuitive and take minimal time to be performed. It was decided that the best way to measureusability was to apply user testing throughout the development. Two identical usability testswere conducted on the tracker interface and the goal was to see how Tempo users would use theapplication and try to improve the product between tests.
“After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore.You know toomuch. The only way to find out if it really works is to test it."
— Steve Krug, Don’t Make Me Think!, Second Edition, 2006
As Steve Krug explains, developers become blind on the usability of the product that theyare making in a relatively short time so it becomes important to test the application with usersand get their perspective. Even though we had read chapters in Steve’s book we still managedto fall into the trap of assuming that everything would be as clear to the users as it was to theteam of developers.
4.1 Methodology
The method chosen was to get users to solve predefined tasks in the application. The average agein the tests was 33 years, 5 female and 11 male participants. All the participants were employeesat Tempo and had experience using the products that Tempo makes and the majority of thethem had a university degree. Tempo wanted to keep user testing internal to the company sothat false hope would not be created with Tempo customers that a mobile application was inthe pipeline.
Each individual session lasted approximately 20 minutes. The users were given a phone to usein the test. During the session, the test administrator explained the test session to the users andbefore the first task was given he asked the user a few background questions. The participantswere then given one task at a time and asked to try to solve the task using the application,while another member of the team observed and recorded the time for each task. When theuser had finished all the tasks we asked the user a few questions regarding the application andtried to get a sense of what the user liked and disliked. The session was then concluded with ashort questionnaire regarding the application. Table 3 lists the tasks performed by users in bothusability tests.
12
Tempo Mobile
# Task1 Open the app and start a tracker without logging in.2 Login to the app.3 Start another tracker and rename it "user testing".4 Delete the tracker named “user test”.5 Start a tracker and attach the issue WIKK-14 to the tracker.6 Log work on a tracker with issue WIKK-14 attached to it.
Put 2 in worked and 3 in remaining and type User testing incomment.
7 Find issue AKA-15 and start tracking it.8 Rename tracker AKA-15 to “User testing”.9 Go into the Log work view on issue WDP-7 from the assigned
issues list without starting a tracker.10 Go back out of the log work view and logout of the app.
Table 3: Tasks
4.2 Usability Test 1
The first usability test was conducted on the 27th of February 2015 in a meeting room atTempo’s offices at a predefined time that had been setup with each user. Table 4 lists the usersthat participated in the test.
Gender Age Job title
Male 35 Web DesignerMale 38 Software DeveloperMale 25 Customer AdvocateFemale 23 Software EngineerFemale 33 Software TesterMale 48 CTOMale 46 Senior Software DeveloperMale 32 Product Manager
Table 4: Participants in Usability test 1
13
Tempo Mobile
4.2.1 Results
In table 5 the average time for each task is listed along with the number of users that finishedeach task and users that need assistance.
Task Average Time Finished Task Needed Assistance
1 20.7 seconds 3 users 5 users2 62.0 seconds 2 users 6 users3 28.5 seconds 6 users 2 users4 17.8 seconds 8 users 0 users5 17.8 seconds 8 users 0 users6 68.8 seconds 2 users 6 users7 12.1 seconds 7 users 1 user8 18.2 seconds 8 users 0 users9 25.6 seconds 8 users 0 users10 5.6 seconds 8 users 0 users
Table 5: Results from Usability test 1
In figure 7, figure 8, figure 9 results from questionnaires are listed with the question in eachcaption.
0%0%0%12.5%
87.5%
Strongly disagreeDisagreeNeither Agree or DisagreeAgreeStrongly Agree
Figure 7: Overall, the app was easy to navigate through.
0%0%0%75%
25%
Very badBadNeither Bad or GoodGoodVery Good
Figure 8: How was your experience using the app?
14
Tempo Mobile
0%0%
25%
50%
25%
Very badBadNeither Bad or GoodGoodVery Good
Figure 9: How did you like the overall look of the tracker interface?
4.3 Usability Test 2
On the 26th of March 2015 the second usability test was conducted in a meeting room atTempo’s offices at a predefined time that had been setup with each user. Table 6 lists the usersthat participated in the test.
Gender Age Job title
Male 33 Software DeveloperMale 27 Software DeveloperMale 23 Software DeveloperMale 26 MarketingFemale 43 Agile CoachMale 24 Software DeveloperFemale 39 Channels ManagerFemale 30 Marketing
Table 6: Participants in Usability test 2
15
Tempo Mobile
4.3.1 Results
In table 7 the average time for each task is listed along with the number of users that finishedeach task and number of users that need assistance.
Task Average Time Finished Task Needed Assistance
1 10.0 seconds 8 users 0 users2 22.4 seconds 7 users 1 user3 22.8 seconds 8 users 0 users4 12.3 seconds 8 users 0 users5 17.8 seconds 7 users 1 user6 48.0 seconds 8 users 0 users7 16.9 seconds 8 users 0 users8 17.4 seconds 7 users 1 user9 22.3 seconds 8 users 0 users10 7.8 seconds 8 users 0 users
Table 7: Results from Usability test 2
In figure 10, figure 11, figure 12 contain results from questionnaires are listed with the questionin each caption.
0%0%0%
37.5%
62.5%
Strongly disagreeDisagreeNeither Agree or DisagreeAgreeStrongly Agree
Figure 10: Overall, the app was easy to navigate through.
0%0%0%62.5%
37.5%
Very badBadNeither Bad or GoodGoodVery Good
Figure 11: How was your experience using the app?
16
Tempo Mobile
0%0%0%
37.5%
62.5%
Very badBadNeither Bad or GoodGoodVery Good
Figure 12: How did you like the overall look of the tracker interface?
4.4 Discussion
When we summarized these results we can see a lot of improvements even though we only had asmall sample group of Tempo users where a single user can easily impact the measurable results.Firstly, there is a vast difference in the number of users that needed assistance between usabilitytest one and two, figure 13. When analyzing the results from usability test one it’s clear thattoo many users encountered problems with certain tasks, especially tasks one, two and six. Ineach of these three tasks there were actions that the users needed to perform to finish the task,that we did not anticipate the users having trouble figuring out. This was a good example ofhow relevant the quote by Steve Krug really is. After the first usability test we tried to removeall unclear actions and make it easier for users to use the application. After making changes tothe application and performing the second usability test we managed to reduce the number ofusers that needed assistance and that is exactly what we aimed for.
Secondly, there is time improvement in almost all tasks in usability test two compared tousability test one, figure 14. That indicates that the improvements makes the application easierto use. Possible reason for no time improvement in some tasks might be because we added anextra action to complete a task, which was done to make the action more clear to users.
Thirdly and last, there is improvement in two of three, of the user experience questionnaires.After usability test one the most noticeable results was the overall look of the tracker interfacedid not get a high score with the users, figure 9. When analyzing the results we quickly agreedthat this needed to be improved before the next usability test. After the second usability test itis clear that we accomplished our goal of improving the tracker interface.
From the results of usability test two we draw the conclusion that we did improve the product.We agree that we analysed the results from usability tests one correctly and we spent good dealof time to design the improvements which we conclude went great. The knowledge gained fromthese two usability tests was then utilized to design and develop the rest of the application.
17
Tempo Mobile
Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 100
1
2
3
4
5
6
Users
Usability test one Usability test two
Figure 13: Users that need assistance in usability test one and two
Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 100
20
40
60
Second
s
Usability test one Usability test two
Figure 14: Time comparison between usability test one and two
18
Tempo Mobile
5 BETA Testing
Creating hybrid applications for Android and iOS can be complex, dealing with multiple versionsof operating systems, screen sizes and resolutions. With all these variables in mind it was decidedto perform BETA testing within Tempo to try the application on as many different devices andoperating systems as possible to try to find out if there were any bugs in the application.
An email was sent to all employees at Tempo where they were asked if they wanted toparticipate in the testing. Two applications were used to distribute the application during BETAtesting, TestFlight16 for iOS and TestFairy17 for Android. Initially the testing was done withinthe company, later Tempo allowed two customers to participate in the BETA testing. Userscould then report bugs through TestFlight and TestFairy.
Table 8 and table 9 list all devices and their operating systems involved in the BETA testing.It is worth noting that multiple users had the same device and operating system but are onlylisted once.
Device OS
iPhone 6+ iOS 8.3iPhone 6 iOS 8.3iPhone 5S iOS 8.3iPhone 5 iOS 8.3iPhone 4S iOS 8.3
Table 8: iOS devices in BETA testing
Device OS
Motorola - XT021 Android 4.4.4Motorola - Nexus 6 Android 5.1LGE - LG-D855 Android 5.0LG - G2(LG-D802) Android 4.4.2Samsung Galaxy S5 Android 5.0Samsung Galaxy S3 Android 4.3OnePlus - A0001 Android 4.4.4HTC - HTC One Android 5.0.2
Table 9: Android devices in BETA testing
During the time that the application was in BETA testing we updated the application severaltimes to fix minor bugs found by users and the team. The only operating system that had anyissue was Android 4.3 and every version below that. The issue is that the old Android operatingsystems are running on an old stock Android browser which does not support new units ofmeasurements in CSS. We decided, at least for now, that the application will not support Android4.3 and below. In hybrid development it is extremely important to perform BETA testing as thereare so many different devices and operating systems that you would like to try the applicationon. Without this testing phase some bugs would have gone unnoticed, for example if no profilepicture had been uploaded to JIRA the name and the objects in the side menu shifted out ofplace. To conclude, we highly recommend to anyone who is thinking about developing hybridapplications to perform BETA testing on every major release.
16https://developer.apple.com/testflight/17https://www.testfairy.com/
19
Tempo Mobile
6 Future Works
This project entails a fully functioning mobile app ready for deployment for Tempo. Duringdevelopment, many enhancement ideas came up and were discussed. A select few were imple-mented as lower priority requirements and others were left as topics of discussion for this chapterdue to time constraints. The following are all features we see as valuable and would’ve liked tohave implemented, given more time to work on the project.
First of all we would have liked to have the functionality of requesting approval for the user’stime sheet. Since there wasn’t a REST API for that functionality, and we didn’t have the timeto spare to write it ourselves, we were unable to implement this feature. Then to add on topof this approval functionality, is the use of an admin or team leader who could then view andaccept timesheets from users. This would be a great addition to the product.
Second is the ability to work offline. What that means is allowing the user to queue postedworklogs so when he finally connects to the internet this queue of worklogs would be pushed tothe server.
Third is a push notification functionality. This would work to remind users of, for example, atracker that they have had running for some extended time; trackers that have not been logged;and that the user is running out of time to request an approval for their timesheet.
Fourth is to implement specific interfaces for tablets. As of now the app is not optimized fortablets and that would be ideal to better the usability of the app on tablets.
Fifth is something that would be very interesting, not only for the app but also the desktopversion, and that is a tracker that would use Rest API to save tracker information. That wayusers could sync their trackers between the app and the desktop. This would make it easier forthe user to keep track of all his trackers.
Sixth and last is to add Android Wear and Apple Watch support.
20
Tempo Mobile
7 Conclusion
In this report we have introduced the mobile application Tempo. We gave insight into the collab-orating company Tempo, and the JIRA application they develop plug-ins for, and the motivationbehind the creation of a mobile application for Tempo. We then discussed the Ionic frameworkand the reasons behind that choice before we went into the core functionalities in mobile applica-tion Tempo described in scenarios. Next we discussed our approach to the project managementand how successful we were on following the plan. Then we delve into the usability testing per-formed and their results. Finally we discussed our BETA testing and potential enhancementsfor Tempo that might be interesting to add to the project in the future.
In the beginning of the project we chose to develop the application in the Ionic frameworkeven though the framework was still in BETA at the time of development. We saw Ionic as thebest possible way to develop for both Android and iOS devices at the same time. Overall we didnot encounter any major obstacles regarding the framework that we could not overcome. Themain reason being the quality of the documentation that Ionic offers. The main predicamentwas the amount of different screen sizes we had to account for. Despite these predicaments theIonic framework proved ready and turned out to be a prosperous tool for development.
Even though over the course of the project we had other school assignments we never neglectedthe project and always found time to fulfill our work duties. Overall the teamwork throughoutthe project was great and we are very proud of the final product.
We would like to thank Tempo for their collaboration on this project. Tempo provided uswith top facilities and a great working environment. Furthermore we would like to thank theemployees of Tempo for their endless help in testing the product and input during development.We also want to thank Reykjavík University for this great opportunity to work with a greatsoftware company.
Finally we want to thank our instructor Hlynur Sigurþórsson, Jökull Jóhannsson our examinerand the product owner Viðar Svansson, for their advice and support throughout the project.
21
14 May, 2015
Árni Fannar Þráinsson030189-2219
Gunnar Smári Agnarsson290792-3479
Sindri Sigurjónsson040289-2409
Theodór Tómas Theodórsson170186-2149
School of Computer ScienceReykjavík UniversityMenntavegi 1101 Reykjavík, IcelandTel. +354 599 6200Fax +354 599 6201www.reykjavikuniversity.is
