Embed Size (px)
Citation preview
UBR (Unified Butterfly Recorder) iOS Final Report
SE 492 Senior Design Group MAY1614
Matt McKillip, Mason Berhenke, DJ Todd, Kyle Long, Blake Burns, Eric Soland, Yujin Kok
Advisor: Dr. Diane Rover
Client: Nathan Brockman
Team Website: http://may1614.sd.ece.iastate.edu/
Table of Contents Introduction
Project Summary and Objective
Objective
Results
Features and Screenshots
Module Decomposition
Module Diagram
Standards Section
Ethics Standards
Quality Standards
Coding Style Standards
Implementation Details
Programming Languages and Environments
User Interface
API Modules
Backend
Development Process
Agile Methodology
Tools
Testing Process and Results
Beta Testing
1
Verification
Code Quality
Continuous Integration
Limitations and Future Plans
Limitations
Unimplemented Features
Future Plans
Appendix 1: Operation Manual
Using the UBR iOS App
Creating a Survey
Performing a Survey
Viewing Sightings on Map
Editing a Survey
Incidental Survey (Special Use Case)
Appendix 2: Alternative or Other Initial Versions of the Design
User Interface Changes
UBR3 Backend
Keyboard Handler
Appendix 3: Other Considerations
Wearables
Bad Elf
Android Update
2
Introduction Project Summary and Objective Butterflies are commonly used as an indicator species. From monitoring climate change to measuring the progress of habitat restoration efforts, butterflies are used often to help answer scientific questions. However, across the nation and around the world, there is a lack of information on native butterfly species, their annual dispersal, and numbers. To help with this task, the scientific community has begun relying on citizen scientists to go out into the field and collect surveys, or records about butterflies they encounter.
The type and format of the records collected by these citizen scientists varies widely. A multitude of organizations recruit citizen scientists to track butterflies and each organization asks for a different set of data points in a different format.
In January 2013, Team Butterfly (Senior Design Team Dec1308) took on the task of creating the Unified Butterfly Recorder (UBR) mobile application on Android. In their project plan, they stated the problem they were working toward solving:
“There is no national or global standard for the type of data collected, how it is recorded, or the methods of collection. Data collected using one protocol can be similar to that of another protocol, but different enough to not be useful. Current methods for collecting this data are often done on paper and not catalogued uniformly. There is no central warehouse for butterfly survey data, making largescale research and conservation efforts challenging.”
This problem statement spawned what has become the UBR vision:
A suite of mobile applications which streamline the process of data collection, standardize the data that is collected, and facilitate central storage and access of all data collected with the apps. The data collected might include GPS location, weather information, butterfly sightings and behaviors, and even photos of surveyed areas and butterflies.
A central server which allows users to export their data to any (or all) of the butterfly tracking organizations.
3
A data analysis platform through which individual users as well as database owners can view the survey data in a variety of formats conducive to drawing meaningful conclusions. This might include mapping, graphing, and other visuals for presentation.
The first UBR team, Dec1308, worked to address the first part of the UBR vision. Throughout 2013, with the collaboration of the Reiman Gardens Entomology staff, UBR was designed, developed, and released on the Google Play store. The release of the UBR Android app in the conservation community produced a lot of excitement about the ease of data collection, ability to standardize survey results despite variable collection methods, and the capability to manipulate analysis to benefit research and enhance conservation efforts.
In January 2014, Senior Design Team Dec1416 designed and created a comparable iOS application for the Apple App Store. Unfortunately, this venture proved fruitless and the application was never released; however the UBR vision continued on with the next group, UBR3, whose purpose was to create a central server to move data from one standard to another for organizations. As of now, this server is not released and may have to be redone due to Parse, a backend as a service company, deciding to close operations.
Today, our group is currently making an iOS application that will have the same functions as the Android application, but will have an iOS look and feel. Hopefully we will have a server to interface with, but as of now this is not in the project plan.
Objective The Android application was the first step toward achieving the UBR vision. The Android version was very innovative for the time, but the problem arose that groups with iOS users did not want to use the application because it would either A) require their members to switch or B) alienate half of the members who couldn’t use the application.
Our objective is to complete the UBR vision by finishing the other half of the mobile application suite, officially allowing organizations to fully switch over to UBR. This app would require a look and feel of iOS applications as well as interface well the UBR server. The app would also have to be approved for the iOS App Store.
Results Our team has achieved our goal of creating an application with the same functions as UBR, but with an iOS feel. We’ve also increased functionality allowing for even easier sightings than
4
Android. We have gone through many hoops (legal, technical, and more) for getting the app on the app store, and we still have yet to submit to the app store.
Features and Screenshots The following features have been successfully implemented.
Google Login
The user is presented with a Google login page. Google handles the security of a username and password for our application. This natively supports logging in with an iastate.edu username.
Viewing, Resuming, and Deleting Surveys
The home page of the app is the survey's list. The table gives a quick view of their current and past surveys. Users can tap on a running survey to resume the survey, or tap on a completed survey to review their past survey. We also allow the user to delete a survey they no longer need by swiping the survey left.
Quick Incidental Surveys
Incidental surveys must be under 15 seconds to complete. We have implemented a search bar that will autocomplete the user's search query. This allows an incidental to take under 5 seconds for almost all use cases.
Additional Information when Creating a new Survey
When creating a new survey, the user may want to enter in specific information in addition to naming the survey. We show a popover that allows the user to enter in all of the survey information if they would like.
5
Add Sightings
To add a sighting the user can simply tap on the butterfly name. We allow the user to filter only their favorites to provide a quicker way to find their common butterflies. The user can also use the search bar to filter the list of butterflies further. Instead of scrolling through thousands of butterflies, the search and favorites features drastically decreases the time to find a butterfly.
View and Edit Sighting Records
The user can review the sightings for their current survey in the “Records” tab. The user can sort the list by either name or time. If the user wants to delete or edit a sighting they can swipe left. If the user selects to edit a sighting, they can enter in more information such as wing length and sex.
Review Survey Map
The user is able to view their current survey on a map. The map plots their path as a line and each sighting as a dot, which is colored based on the butterfly. The user can select between three different map types. The user can also select a sighting and view more information about the sighting.
Custom Settings
There are many different use cases for our app so we allow the user to customize many aspects of the app. The user can set the defaults for new survey fields, whether they prefer common or scientific naming, and if they prefer temperature in celsius or fahrenheit.
6
Import Custom Species List
Since this app will be used across the globe, different parts of the world have different species in their local area. We allow users to import their own species list. When the user has imported their custom list, the species they see in the “Sighting” table will be updated.
Module Decomposition There are four main components that make up the UBR server: the user interface, the Cloud Code API, the Parse database, and the external API.
Module Diagram
Figure 1: module diagram
User Interface
The user interface module has Swift code and XIB files for layout of the interface. This module is responsible for showing the data stored in the app to users in a simple and intuitive way. The UI is updated with current weather and Google Drive data. UI elements are also updated based on what is in the Realm database, whether you are in an active survey, or looking through the list of butterflies.
7
Realms
Realms is split into 3 modules: Surveys, Sightings, and Butterflies.
Butterflies has the list of all butterflies the user has imported from Google Drive into the app. These models have information about the butterfly, as well as utilities to modify the butterfly data.
Surveys is responsible for storing and keeping track of all surveys the user has done. This includes storing information in Realm and retrieving the data to display on the UI. Sighting hold individual sightings of butterflies. These sightings are then stored within the Survey model.
Weather API
The UBR app utilizes a free weather API to retrieve weather information while doing a survey. This information is stored when a butterfly is sighted.
Standards Section
Ethics Standards Many professional scientists will use this UBR app. That requires this app to be written in a professional manner with appropriate and professional language. Due to the nature of this app, most of the language is used as butterfly names and headers for tabs and views. This team easily managed to keep the trivial amount of language appropriate and professional.
The UBR app will be used primarily for academic and scientific endeavors. In order to promote those endeavors, this app should be offered for free without cost to any user. This standard is easy to obtain by either informal or formal distributions that allow this app to be installed for free.
Currently in rare situations, the android UBR app is being used while the user is driving. If a dedicated user spots a butterfly while driving, they are strongly tempted to do a quick incidental survey. Clearly, using a smartphone while driving has serious legal and physical risks. In order to mitigate these risks, a user on the iOS UBR app can perform an incidental survey much faster than they could with the android UBR app. Since the iOS UBR app is faster at incidental surveys than both the android app and recording by paper, the driving risk has been mitigated as much as possible on the developer end.
8
Quality Standards This UBR app will be used in professional, academic and scientific settings, so this app must have sufficient quality to be presented in those settings. In relation to the users and clients, all major bugs and as many minor bugs as possible should be removed from the app. The app should have a standard layout so different views are easy to navigate. This app should use the required surveys and display them in an intuitive way. This team developed the app to surpass these requirements from the user perspective.
Then for future developers, this app should be written in a logical way so another team or developer can extend it with relative ease. This team wrote the code for this project with many comments for maintenance developers.
Coding Style Standards In order for maintenance developers to efficiently extend the UBR app, the code in the app must be easily and intuitively understandable. One of the coding style standards that is in this project is that the views and supporting files are organized by groups, or folders. Another coding style standard that is in this project are flags that mark where the actions, properties and helper methods are within the viewcontroller classes. These standards demonstrate the effort to make the code base maintainable.
Implementation Details
Programming Languages and Environments In order to program for iOS devices, a developer is required to learn swift or objective c. They also must have xcode which can only compile iOS apps on mac computers. Many of the team members on this project did not originally have a mac or an iOS device. Also many members did not have previous swift or objectivec experience. This team overcame the unique challenges of being introduced to new programming languages and developed the iOS UBR app.
User Interface
iOS Design
Beginning with the individual screen views from the UBR Android app, the first thing we did was reoder and arrange the transitions to better separate between being “in” a survey, and creating
9
a new one or managing old surveys. After finalizing the new screen flow we mocked up screen layouts using JustInMind. It was during this that we focused on improving usability, and added in features such as the Incident button that would shorten the time users took to fill out certain survey types. The next step was to transfer these rough layouts to the XCode project so that we could begin implementing basic app features. Once clients and beta tester approved usability of the layouts we began finalizing color schemes, and gave focus to the app aesthetics. For more on the design choices that were made in comparison to the original Android app please see Appendix 2.
IQ Keyboard Manager
Unlike Android, iOS has no built in mechanism to handle keyboards. This causes the keyboard to cover up the text entry field the user is editing. The IQKeyboardManager allows you to prevent the issue of the keyboard covering up the text entry field without any code from the developer.
TTG Snackbar
Snackbar isn’t native to iOS. In order to utilize it in iOS, an external library was used. The snackbar simplify the flow of the app without constantly creating a new view, making it faster.
API Modules
Open Weather Map
In order to provide accurate weather data for our users, our application calls the OpenWeatherMap API on the start of each survey. Based on the user’s current latitude and longitude, OpenWeatherMap returns JSONformatted weather data for temperature, humidity, wind speed and cloud cover. One of the advantages of using this API is that it offers free service for up to 60 calls a minute (once per second), which let us test it out during development before committing to a paid service. One of the challenges presented from this API is that if the call takes too long to respond or times out, we have to wait to populate the data during or after the survey takes place.
Apple Maps
Our application allows the user to view their survey locations and sighting locations during their survey. Apple maps provides an easy builtin interface to open a map, place locations, and draw a path. We chose to use Apple Maps API over Google Maps API because Google lacks support for iOS while Apple is highly integrated.
10
Google Drive
iOS lacks the ability for apps to use the local file storage. The UBR app needed to be able to allow the user to give the app their own .CSV file to import a custom list of butterflies into the app. To get around this, Google Drive was used. All the user must do is put their .CSV file into their Google Drive folder online, then the app can detect the file and download it.
Google Sign‐In
Google has allowed developers to use their OAuth 2.0 login system for use in developer systems. This can make development time much quicker, as instead of having to create a login system people can just use their Google login in the same application. We picked this because of the UBR server being built, which was switching from Parse to Google Cloud Platform. It is implemented now to where people can login with any Google email and password and the app will recognize it. The server implementation may come into play later.
Octokit
Octokit is an API that wraps around the GitHub API allowing simple access for developers. We are using Octokit to allow users to enter in feedback for the developers, then Octokit will open a new issue on our GitHub repository. This allows a simple communication between the users and the developers.
Backend
Realms
Realm is a local database solution. Realm is not built on top of SQLite, however, is its own persistence engine. Realm focuses on speed and its ease of use. When using Realm in code, it uses an object oriented approach. This makes the code readable to others and easy to follow.
A major reason for using Realm instead of SQLite is its crossplatform usability. Realm works on OSX, iOS, and Android. So working to create a new app on the two largest mobile OS’s gives Realm a good advantage. The Realm files can be used between the platforms. The usage is similar, so code can be structured in a similar manner between languages.
Realm is used in our app to store all of the user’s local data. This includes surveys and sightings. All butterflies are also stored in Realm as well when they are imported. Since Realm uses an object oriented approach, other developers who may not be familiar with Realm can still easily create queries and manipulate the data without the creation of a helper class.
11
Realm has allowed the UBR team to focus less on managing the local database, and focus more on the functionality of the code itself.
Development Process
Agile Methodology To help our team develop as efficiently as possible, we instituted an agile/Scrum workflow. Out development cycle was divided into twoweek sprints. At the beginning of each sprint, we selected and created the user stories each of us intended to finish over the next two weeks. When we completed a user story, it was submitted to the GitHub repository as a pull request, then verified by another team member to ensure the user story had been implemented correctly. Once the pull request was verified, it was merged into our dev branch.
We held weekly standup meetings through Google Hangouts. Every two weeks we would conduct a end of sprint meeting. In this meeting we would discuss the user stories that have been completed during the sprint. We would also discuss user stories that did not get completed and figure out why, so in the future we could work more efficiently. On the opposite weeks we would have a short status meeting. During this meeting each member would answer three questions: What you did last week? What you are going to do this week? What are you blocked on? These three questions allow the group to know what everyone is working on, and potentially help members resolve what is blocking them.
In addition to standup meetings, we also held biweekly meetings with our advisor and clients. We used these meetings to discuss what we accomplished and what we were planning on implementing. This allowed our clients to give us immediate feedback and verification on our app.
Tools To allow use to develop as efficiently as possible, we utilized many different development tools. Over the course of the semester the following tools were used:
GitHub Repository hosting Trello Task management Slack Team communication Bitrise Continuous integration platform Google Hangouts Remote video meetings
12
TeamViewer Remote desktop software
Testing Process and Results
Beta Testing The two most popular options for private beta testing iOS apps are TestFlight and Fabric. TestFlight is owned and maintained by Apple and is accessible for free by any registered iOS Developer group. TestFlight does allow developers to track some statistics and minor crash reporting, but does not give full stack traces, and only works with iOS. In contrast, Fabric alongside with Crashlytics allow for full stack trace on crashes, and the ability to log custom events for statistic tracking. With both of them being owned and maintained by Twitter, the beta platform allows for iOS and Android apps to be added under the same platform and gives cross platform statistical comparisons. Given that our clients had expressed interest in updating their Android project soon, we felt that Fabric was a clear choice for beta testing.
During the course of the semester we were able to build up a base of 30+ approved beta testers that got builds sent to their phone. Thanks to a small network of users most feedback was able to be sent back to us directly through emails so that changes could be made for the following build. In addition to the other advantages of Fabric over TestFlight, we also were given a desktop client that hooked directly into the XCode IDE and allowed us to send out new builds to specific clients and devices without needing to upload app archives to Apple’s Developer account saving us a lot of time and energy.
Even with all of the advantages of Fabric, there were still some problems with code signing and archiving that have given the team some trouble. Most of which dealing with legal logistics for the developer profile, and and the need to register every device that we wish to send builds to.
Verification Coding the application requires verification to ensure no breaking changes occur in our dev branch, the branch that all of our tasks get branched from. The process is as follows:
Branch from dev > Code feature > Programmer tests and ensure it works > A Pull Request is created > Another developer verifies the feature > Branch is merged and deleted
Very rarely is this process every broken, the only cases would be if a change to gitattributes, gitignore, or the realms database occurs. If a developer accidentally commits directly to dev, the
13
change is reverted and the developer is required to go through the actual process. Below is an image of a pull request from one developer, the verification steps provided, and another developer verifying and merging the feature.
Code Quality A problem with many projects, regardless of platform or language, has code quality issues. To resolve this, we’ve implemented an automatic linting tool (a tool that parses the code to check for quality errors) to disallow poor coding and to warn about other issues. An example of this would be a function declaration:
function testFunction()
… //function body
14
If you notice, the function’s parentheses do not have a space afterwards. The note for the function body also doesn’t have a space after the double slash. It should look like so:
function testFunction() //Notice the space after the
… // function body
While these might seem like small, “nitpicky” problems, the small details like this allows for the code to look uniform and professional if someone else comes on to maintain the code.
Continuous Integration Our project is setup for continuous integration through Bitrise. Every time a developer commits code to GitHub Bitrise will execute a build and run our tests. Then during our pull requests, GitHub will display whether the build passed or failed. Having immediate results ensures that the code we are pushing is high quality, letting us see the bugs immediately.
Limitations and Future Plans
Limitations We had many technical and nontechnical limitations during our development process. Our nontechnical limitations were group size and access to Apple devices. Having seven group members meant there were not many times all team members could meet together. To
15
overcome this limitation, we held all of our weekly standup meetings through Google Hangouts and kept a constant stream of communication using Slack.
We also had limitations accessing Apple devices. Not all member of our group had an Apple computer. Apple requires XCode to develop iOS applications, and XCode is only available on Mac. To overcome this limitation we requested a Mac desktop for the Senior Design Lab. We installed a remote desktop application called TeamViewer. This allowed the members without a Mac to remote into the Senior Design Lab and develop without having to go to campus.
We had several technical challenges throughout the course of the semester, but our main challenge was Google API, Parse stopping service, and supporting devices without GPS. Since Apple does not allow users to access the file system of their device, we had to come up with a way for users to download and import their custom species list. We decided to go with Google Drive since it is the most common online file storage platform. The challenge with the Google Drive API is that Google does not actively support iOS. So to call Google Drive API’s we needed to customize outdated code to fit our need. Eventually we achieved file import through Google Drive API.
Our next challenge was Parse stopping service. UBR3 created a backend which we were intending to use for user sign in and survey exporting. But soon after we started the project Parse announced they were going out of business and stopping service in the near future. So we had to change to a different implementation. Since we had decided to use Google Drive API as the importing library, we decided it would be best to use it for exporting and signin. We also took into consideration that UBR3 was planning on converting their server to Google App Engine. So having all platforms use Google will hopefully help integration.
Finally, our last main technical problem was supporting devices without GPS. Apple has only recently started including GPS chips in their phones, and still does not include GPS in iPods or iPads. Since we wanted to include all users on iOS, we needed to find an alternative. We decided to officially recommend the Garmin GLO, which will connect to the device through bluetooth and allow the native iOS location to work as normal.
16
Unimplemented Features
iWatch application
We have discussed with the client about an iWatch application to allow simple one tap incidental surveys. We decided not to implement this feature due to the learning curve needed to start developing for iWatch.
Tracking butterfly flight direction and speed
Our client requested a feature allowing users to draw the path of the butterfly. Then our application would use the gyrometer and phone direction to save the data. We decided to put this feature on the backlog due to the complexity.
Importing custom species images
We want the users to have the option to upload their own images for each butterfly species. We did not include this due to the overwhelming positive reaction from the colored butterfly we implementing in the “Sightings” tab.
Supporting multiple languages
We want users around the globe to be able to use our application. To accomplish this we want to support as many languages as possible. We researched the mechanism to accomplish this feature, but were unable to implement due to time constraints.
Future Plans As of writing this document we are in the process of working with Iowa State’s legal department to apply for the App Store. Once the process is complete, we will submit our app for review by Apple, and hopefully get our app onto the App Store in early Summer.
Our main plan for the future is to maintain the application. This includes fixing bugs logged by users. We have set up a way for users to submit feedback in our app, which will allow users to log bugs they have experienced using the application.
In addition to app maintenance, we would also like to continue developing our unimplemented features. We will also look to implement new features if our client or users have come up with more features they would like to make the app higher quality.
17
18
Appendix 1: Operation Manual
Using the UBR iOS App When you first open the UBR app, you will be asked to allow the app access to your location. The app will need your location in order to create the map and call the weather API, so select “Allow”. Your next step will be to login using the Google login process. The app will import/export custom lists and survey data using your personal Google Drive, so login with an existing Google account or create a new one.
Creating a Survey After you have logged into your Google account, you will be taken to the Home page of the UBR app. This page will show all of your completed/running surveys, including the name of the survey, type of survey and date. The “running man” icon indicates a currently running survey that you have paused and can resume at any time. Push the “Create New Survey” button at the bottom of the screen in order to move to the New Survey page. On the New Survey page, you will be able to select a survey type using the scrolling picker, and then enter survey information in the fields below it. If desired, you may enter more information about the survey by clicking the “More” button at the bottom of the New Survey page. Once you are done entering information about the survey, you will push the “Start” button at the top right to begin the survey.
19
Performing a Survey Now that you have started the survey, you will be shown the Sighting page, which shows a list of butterflies you may see on your survey. Selecting a butterfly from the list will add a sighting to the Records page, and increment the counter on the right side of the list. Since the list of butterflies can be quite long, you can create a Favorites list on the fly by swiping left on a butterfly and pushing “+ Favorite”. You can then freely choose between the All list or Favorites list when performing sightings. Additionally, you can change your All list on the Lists page, which allows you to import custom list for different butterfly regions, or even different animals/plants altogether.
Viewing Sightings on Map At any time during the survey, you can click on the “Map” tab on the bottom of the screen to see the path you’ve taken during the survey, and which butterflies you’ve seen. The color of the dots on the map correspond to the colors of the butterfly icons on the Sighting page list, so you can distinguish between different butterflies more easily. The Map page also allows three different views, Map, Hybrid, and Satellite, which each allow a different type of view depending on what you prefer. Clicking on any of the sighting dots on the Map page will bring up the name and type of the butterfly. When you are done with the survey, press the “Complete” button in the top right, which will bring you back to the Home page. Alternatively, you can pause the survey at any time by pressing the “Pause” button in the top left.
20
Editing a Survey Back at the Home page, if you want to edit any of the sightings you can click on the survey and be taken to the Records page. Clicking on a sighting from the list will bring up the “edit sighting” popover, allowing you to add additional information about the butterfly sighting. The Map tab is also here so that you can take an overall look at the path taken and butterflies seen during the survey.
Incidental Survey (Special Use Case) At the top of the Home page you may have noticed a search bar and button marked “Incidental”. The Incidental is a special survey type in our app, which allows you to record a single, incidental butterfly sighting without having to follow the multiple steps normally needed when creating a survey. The search bar will help narrow down your selection and speed up incidental surveys. Clicking on the “Incidental” button will complete the survey and record the map and weather data for you. If you’d like, you can click on the newly completed survey in the Home page list to edit or add additional data and view the map.
21
Appendix 2: Alternative or Other Initial Versions of the Design
User Interface Changes Although the Andorid version of the app works very well, and has done allot to improve the survey process, our clients put a heavy emphasis on their need for a clean UI that would be useable and understandable for scientists, and nonscientist alike. It is for that reason we chose to follow the Flat UI design standards, as laid out by Apple, as closely as possible. Then for additional design aspects we looked to popular award winning apps such as Evernote, as a reference to current trends in the AppStore. For branding, we wanted something vibrant and noticeable. After trying the pink color in an initial layout and icon during a presentation, we received positive reviews from both clients and their future users, and thus decised to incorporate it in the rest of the app. The solid strong color helps separate sections of the app, and directs the user to actionable items continuing to streamline the surveying process.
UBR3 Backend Initially, our app was supposed to connect to UBR3 server, in order to have equal access throughout both iOS and Android application. The server will be used to store login data, and survey data. It was implemented using Parse, however due to Parse being closed down next year, UBR3 backend server need to be fully revamped, and not able to be used by our current app.
Keyboard Handler Before finding the IQKeyboardManager we had implemented a workaround to handle the user keyboard. Our implementation was to move the bottom of the screen to the height of the keyboard. The implementation worked for most cases, but was very prone to visual glitches and application crashing. Once we found the IQKeyboardManager it was an easy decision to scrap our initial keyboard implementation for a much simpler and more polished keyboard manager.
22
Appendix 3: Other Considerations
Wearables We have discussed with the client about an iWatch application to allow simple one tap incidental surveys. We decided not to implement this feature due to the learning curve needed to start developing for iWatch.
Bad Elf Bad Elf GPS provides location data to devices without GPS. We decided to go with the Garmin GLO since it required no extra coding. The Bad Elf GPS provided extra data, but also needed additional code to access the data. We discussed with the client, and they did not require any of the additional information, so we decided to implement the simplest solution.
Android Update Our application is modeled after the current Android UBR app, but the Android UBR app is several years old. So the user interface is very outdated compared to most Android apps on the Google Play Store. We initially planned to let some members of the team work on a user interface overhaul to implement Google’s Material Design standard, but we decided it was best to focus on polishing our own iOS app.
23
