UBR (Unified Butterfly Recorder) Server Final Report

SE 492 - Senior Design Group DEC15-06

Branden Lange, Nicole Lockard, Zach Miller, and Tyler Uhlenkamp

Advisor: Dr. Diane Rover Client: Nathan Brockman

Team Website: http://dec1506.sd.ece.iastate.edu/

Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 ­ 7 Module Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ­ 8 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 ­ 14 Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ­ 16 Testing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ­ 17 Limitations and Future Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ­ 18 Appendix 1: Operation Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 ­ 24 Appendix 2: Rationale for Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 ­ 34

Figures and Tables Figure 1: Module Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Figure 2: Agile Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 3: Push Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 4: Pull Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1

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 Dec13­08) 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 large­scale 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.

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.

2

The first UBR team, Dec13­08, 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 Dec14­16 designed and created a comparable iOS application for the Apple App Store. The iOS app provides similar functionality to the Android app, but with a native iOS app look and feel. At the time of this writing, the iOS app has not been released in the App Store and is no longer under active development by Senior Design Team Dec14­16. However, a new senior design team has been created to begin development on the iOS application again.

Objective The mobile applications were the first step toward achieving the UBR vision. However, in their current state, survey data is stored only on the phone and can only be exported as CSV files. Data cannot be easily sent to butterfly tracking organizations nor can it be effectively analyzed.

Our goal was to complete the UBR vision by creating a central server to which butterfly surveys can be sent for both storage and distribution to the databases of other organizations. We were also to build a data analysis platform for the survey data if possible.

Results Our team achieved our goal of creating a central server which handles storing and sharing surveys with butterfly organizations. Our server also manages user accounts and facilitates the creation and management of new organizations to which users can submit their survey data. We also created an API which organizations can use to export surveys submitted to them for use in external databases. Lastly, we created a website through which users can create accounts and log in, view surveys they have created, join and manage organizations, share surveys with organizations, view surveys shared with organizations they are a member of, and export surveys in JSON format.

3

Features and Screenshots The following features have been successfully implemented into “MyUBR”.

Security Register a new account Login with an existing account Verify an account with an email Retrieve your password

Survey Data View your surveys and detailed information about each one View surveys and sightings from organizations which give you read access View sightings on a map

Sightings color coded by butterfly species View breadcrumb data (the path traveled during the survey)

Submit surveys to organizations which give you have submit access Select and export surveys to CSV files, KML files, and Shapefiles Request bulk survey data in JSON format through an HTTP API endpoint

Sighting Data View your sightings for each survey and detailed information about each one View a single sighting location on a map

Organizations Create an organization View a list of organizations you are a member of

View permissions you have with an organization Leave an organization Manage an organization if you have admin permissions

Request membership to public organizations View a list of pending membership requests

Remove a pending membership request View list of pending membership invites

Accept or deny a pending membership invite Manage Organizations

Only accessible if logged in user is organization admin Update organization description and visibility View a list of users that are members of the organization

4

Edit user permissions Remove user from organization

Invite a user to join the organization View a list of pending membership invites

Remove a pending membership invite View list of pending membership requests

Accept or deny a pending membership request

Screenshots

Log­in Page

Surveys List Page

5

Survey Details Page

Survey Map Page

6

Manage Organization Page

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 contains the HTML and JavaScript code that is rendered in the browser of UBR users. As such, this module is responsible for presenting the data stored within the database to users in a meaningful way. Data within the Parse database is stored, modified, and retrieved by calling the Cloud Code API (developed by our team) and the Parse database API (provided by Parse). Within the User Interface module, there are several other modules

7

such as the renderable React components, routing, and API connection modules. More details about the user interface implementation can be found in the “Implementation Details” section.

Cloud Code API

The Cloud Code API is split into three modules: the user module, the organization module, and the survey module.

The user module is responsible for collecting, validating, and storing information about users of UBR. As user data such as names, email addresses, and passwords, are sensitive, this module is also responsible for enforcing security measures that prevent unauthorized entities from accessing the data of each user.

The organization module provides users with the functionality required to create and manage organizations. In doing so, the Organization module creates a complex framework which allows users to join and leave organizations created by other users, view and manage data shared with the organizations they are a member of, and even manage the organizations they are a member of (if given administrator privileges within the organization).

The survey module protects the survey data collected by users, ensuring that only authorized entities are allowed to view each survey. This module also provides users with the ability to share surveys with specific organizations, thus making the survey data available to the selected organizations.

Parse Database

The Parse database stores all application data. All interactions with the database are executed with an API provided by Parse. Please see the “Implementation Details” section for more information.

External API

The external API allows organizations to request bulk survey data shared with the organization in JSON format.

8

Implementation Details The following section describes the implementation of the front­end and back­end of “MyUBR”.

Front-End

Overview

The front­end of the “MyUBR” application is a single­page web application composed of several API modules and a set of ReactJS view components arranged in a hierarchy to render the website. Each component is responsible for rendering a portion of the website, handling any user interaction associated with it (usually by calling a Cloud Code API function), and then communicating the results of the Cloud Code function to the user.

API Modules

The front­end contains JavaScript wrappers for both the Cloud Code API and the Parse Database API. View components can use these JavaScript wrappers to communicate with both the server and the database. These functions initiate AJAX requests to the Parse database and return JavaScript promises to the caller. Each promise can be used to execute callbacks when the operation succeeds or fails.

View Components

The front­end application is structured as a React single page web application. Upon initial page load, all static assets ­ including the images, HTML, JavaScript, and CSS files ­ are loaded and sent to the client. After the page is loaded, React­Router (an open source library) inspects the current URL and loads the proper view components for rendering the current page. When the user clicks a link or otherwise initiates navigation, React and React­Router instantly swap out the the current components for the one associated with the new page without requesting a new page from the server. If the new view components need to load data from one of the API’s, the page will be rendered while those calls are running in the background. This makes the website extremely fast and responsive and removes the need for most server­side rendering and processing.

Each individual view component accepts some parameters and (optionally) has some internal state. View components also contain a render function which returns HTML and/or other React components. An important aspect of this architecture is how it manages the flow of data through the component hierarchy. Namely, data flows down the hierarchy while changes and events propagate up the hierarchy via callbacks provided to child components. This makes the

9

application very easy to analyze and prevents many bugs which result from the complex state handling present in many modern web applications. In fact, we had only two or three instances of logical error in our front end application throughout our four primary months of development.

Features

Single page web application with very fast page loads Runs well and looks great on all modern desktop and mobile web browsers Component architecture resulted in flexible and maintainable code across the codebase Follows all modern web standards, including the use of ES6, the next version of

JavaScript

Back-end Our team chose to host our database and backend logic using Parse, a popular Platform­as­a­Service framework.

Features Provided By Parse

Reliable Data Storage and Uptime

Parse, which is powered by Facebook, handles all aspects of database management and hosting. By choosing to use Parse, our team was free to focus on designing and implementing the UBR platform.

NoSQL Database

Parse utilizes MongoDB, an open­source document database, to implement its data storage capabilities. This made it very easy to experiment with the database design, as tables and rows can be added and removed easily without concerns of having to rebuild the database each time a small change is made.

User Authentication

Parse handles all aspects of user authentication, thereby eliminating the need for developers to implement tricky authentication code themselves.

Access Control

Every object in the Parse database is protected by an Access Control List (ACL). Only users and roles (groups of users) which are specified in an object’s ACL are allowed to perform operations on that object. Furthermore, operations (e.g. read, write, delete) can be limited to

10

specific users and roles within each ACL. By properly utilizing ACLs, developers can easily secure their application to help ensure that user data is not vulnerable to unauthorized parties.

Cloud Code

Another useful feature of Parse is that it allows developers to upload sensitive code to the Parse Cloud. Once uploaded, Cloud Code is executed by Parse servers. This functionality is essential as it allows all security checks to be performed in a secure environment rather than on client devices, which cannot be trusted to behave as intended.

When writing Cloud Code, developers create Cloud Code functions which are callable by client applications. We refer to this set of functions as the “Cloud Code API”.

Features Provided By UBR Cloud Code API

Listed below are the descriptions of the Cloud Code functions that UBR clients can call.

createOrganization

Creates a new organization within the UBR system. The calling user is given administrator privileges within the organization.

setVisibility

Sets the visibility of an organization to be publicly searchable or hidden. The calling user must be an administrator of the organization.

setDescription

Sets the description of an organization. The calling user must be an administrator of the organization.

sendMembershipInvite

Invites a UBR user to an organization. The calling user must be an administrator of the organization.

getSentMembershipInvites

Retrieves a list of UBR users who have been invited to an organization. The calling user must be an administrator of the organization.

11

getMembershipRequests

Retrieves a list of UBR users who have requested to join an organization. The calling user must be an administrator of the organization.

approveMembershipRequest

Approves a membership request that a user has made to join an organization. The calling user must be an administrator of the organization.

getMembers

Retrieves a list of UBR users who are members of an organization. The calling user must be an administrator of the organization.

updateMemberPermissions

Updates the permissions of a member in an organization. The calling user must be an administrator of the organization.

organizationDeleteMembership

Removes a member from an organization. The calling user must be an administrator of the organization.

exportSurveys

Retrieves the surveys shared with an organization within a specified date range. The calling user must be an administrator of the organization.

getPublicOrganizations

Retrieves a list of organizations which are set to publicly searchable.

getOrganizationInformation

Retrieves the name and description of an organization.

sendMembershipRequest

Sends a membership request from the calling user to an organization.

getSentMembershipRequests

Retrieves a list of organizations that the calling user has requested to join.

12

getMembershipInvites

Retrieves a list of organizations that the calling user has been invited to.

acceptMembershipInvite

Approves a membership invite that an organization has sent the calling user.

getMemberships

Retrieves a list of organizations that the calling user is a member of.

userDeleteMembership

Removes the calling user from an organization.

shareSurvey

Shares a survey that the calling user has created with an organization that the calling user is a member of.

Database Schema

The UBR database contains many tables in order to store the data.

User

Stores all data submitted during user registration, including the user’s name, email address, and password hash.

Organization

Stores the name and description of each organization in addition to pointers to each role within the organization (see below).

Role

Maintains the relationship between UBR users and the roles within each organization. Organizations have three roles ­ readers, editors, and administrators. Readers are allowed to see surveys shared with the organization, editors are allowed to modify the surveys shared with the organization, and administrators are allowed to manage the members of the organization (in addition to reading and editing survey data).

13

Membership

Maps users to the organizations they are a member of and contains data about the relationship such as whether the membership is a request, an invite, or a full membership.

Survey

Contains the general survey data for each user submitted survey. Each object within this table has a one­to­many relationship with objects in the Sighting and Breadcrumb tables.

Sighting

Contains information about each individual butterfly sighting seen during a survey, including the butterfly species and the location in which the butterfly was seen.

Breadcrumb

Contains GPS location data corresponding to the location users visit while taking surveys.

14

Development Process Before starting development, we decided it would be best to use a flexible development process and a robust task management solution.

Agile Methodology To help our team develop as efficiently as possible, we instituted an agile/scrum workflow. The details of the workflow are thoroughly described in the contributing document in our repository. Basically, the development cycle was divided into two­week sprints. At the beginning of each sprint, we selected and documented the tasks which each of us intended to finish over the next two weeks. When we completed a task, it was submitted to the GitHub repository as a pull request, documented, and tagged with all relevant reviewers. After the tagged reviewers approved a submission, it could be merged into the master branch.

Figure 2: agile development process

We held a standup meeting at least once a week to keep the group informed over the duration of the sprint. In each standup meeting, we described the work which we had accomplished, the work which we planned to tackle next, and any holdups which we were experiencing. Our standup meetings were often held in the company of a representative from our client, Reiman Gardens, who was able to offer some validation for our efforts and to help us to prioritize our future work. At the end of each sprint we held a retrospective meeting where we also reviewed the work which had been completed and discussed any improvements which we could make as a team before beginning our next sprint.

15

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:

Git ­ Version control system GitHub ­ Repository hosting Trello ­ Task management Slack ­ Team communication Travis­CI ­ Continuous integration platform

Testing Process In an effort to develop quickly and efficiently, we took advantage of automated testing and continuous integration so that we could commit and deploy frequently.

Verification The functionality of "MyUBR" was verified through both automated testing and manual use­case testing. Automated testing consisted of running karma­mocha tests for client­side JavaScript. These tests were executed on a PhantomJS browser and took advantage of several other testing libraries including chai for assertions, sinon for mocking, and the React TestUtils for additional utilities when dealing with ReactJS components.

Manual tests were conducted semi­regularly by uploading sample data gathered from the mobile devices and by navigating the web interface in a variety of common browsers. Code Quality In addition to unit tests, linters were used to ensure that clean and consistent coding styles were used throughout the project. In particular, we used eslint to analyze our ES6 code which would execute on the client side and a combination of both jshint and jscs to analyze the ES5 code which was primarily used for the server and Cloud Code. Our eslint style configuration was based on the popular Airbnb configuration and our ES5 rules were configured to behave very similarly.

Continuous Integration To ensure code quality throughout the entire development process, we took advantage of the popular continuous integration tool Travis­CI to automatically run both our unit tests and linters

16

for every code submission. Each GitHub pull request was accompanied by a badge which displayed the logs from building the project, the results of the tests, and any errors from the linters. This enabled us to more efficiently find mistakes and to review code as a team before merging it into the master branch.

Limitations and Future Plans While we view "MyUBR" as a success, there are still improvements which can be made.

Unimplemented Features Our current implementation is well­tested, well­polished, and provides all the basic functionality that our customer requested. However there are a few features which we planned to implement but were unable to finish given the time constraints of the semester. Namely:

Survey data analysis and visualizations The ability to edit surveys from within the "MyUBR" website

Using Parse as a Platform While using Parse as a backend allows for easy development, it does have its limitations. First, Parse Cloud Code functions can only run for 15 seconds, which means that they are not suitable for processing large amounts of data. Second, Parse queries are limited to 1,000 results per query. A large number of queries must then be made in order to retrieve all the data relevant to a particular request. Third, the structure of document­oriented databases does not easily facilitate efficient large scale data analysis, including operations such as aggregation and summarization of data. These limitations make it difficult to provide users with meaningful data analysis functionality.

Furthermore, Parse does not provide support for database transactions. It is technically possible for an operation to fail and leave the database in an invalid state. Though extremely unlikely, it is important to recognize this possibility and implement methods which periodically check the integrity of data.

17

Future Plans While the “MyUBR” platform provides most of the functionality desired by users, there are still a few features that should be implemented in the future. These features include:

The ability to filter and sort surveys By owner By species By date/time By location

The ability to filter and sort sightings By owner By species By date/time By location

The ability to view sightings without accessing them through associated surveys The ability to create graphs, maps, charts, and other visualizations based on surveys

and sightings The ability for users and organizations to edit survey and sighting data Switching the front­end to ES5 to make testing and future development easier for new

UBR teams Switching the back­end database and hosting to use Google’s App Engine, which will

avoid many of the limitations imposed by Parse (such as large scale data processing)

18

Appendix 1: Operation Manual

Login Page

Surveys Overview Page

19

Survey Details Page

Submitting Survey Modal

20

Survey Sightings Tab

Survey Map Tab

21

Organization Page

Create New Organization Modal

22

Manage Organization Page

Send Invitation Modal

23

Export Surveys

Select Surveys to Export

Pick Export Format

24

Appendix 2: Rationale for Design Decisions

Design Criteria We defined a set of criteria which our final design should satisfy to the greatest extent possible. These criteria were derived from the project objective, functional and nonfunctional requirements, and stakeholder values.

Client Usability

The final design must be easy to understand and use for the end user. Our users are citizen scientists who own smartphones, but that doesn’t imply a great degree of technical competence. Therefore, while our system doesn’t need to be simple, understanding it and creating an accurate mental model of it must be simple.

Server-Side Maintainability

We are only a temporary team working on the project. We must ensure that our solution is easy for future developers to understand and update. In particular, we should meet the following requirements:

Likely changes should be straightforward and require changes to a minimum number of modules.

Modules should be small and interact in predictable ways. Code should be well documented.

Partner Ease of Implementation

Our partner organizations’ websites are primarily maintained by volunteers with minimal time for significant changes. Interacting with our system must be simple and straightforward for these developers.

25

Client Side Ease of Implementation

The developers of the mobile applications have graduated and are working full­time jobs. They don’t have time to implement complex changes. Therefore, it must be easy to make the required changes to their apps. This means:

It should be easy to communicate with the UBR server. A system which requires frequent updates to the apps should be avoided. As little work as possible should be duplicated between the Android and iOS apps.

Server Side Ease of Implementation

It should be straightforward to implement the server. We should avoid implementing complex behavior from scratch that could be done using existing libraries, especially where security is concerned.

Flexibility and Power

The solution should be able to easily handle the features we need now and whatever UBR might require in the future. For example, the server should be able to handle heavy traffic from uses and applications. Also, we should be able to utilize third party resources as needed.

Security

Our data and users’ login information must be safe from unauthorized access. Users should only be able to submit surveys to and access surveys from their own account.

Data Replication and Safety

We need our data to be backed up in several locations and its integrity guaranteed. The data we are storing is our top priority, so it’s important we are able to keep it safe and secure.

26

Design Decisions

How should we provide organizations with survey data?

Problem Description According to the project requirements, users must be able to share their survey data with designated organizations. We needed a consistent process for accomplishing this for all organizations.

Option 1: Push model Based on our research, each of the organizations currently working with Reiman Gardens allows users to submit surveys via a website. One way to send survey data to such organizations is to ask users of UBR to provide their login credentials to the organization websites, and then programmatically log into the website and submit the data for the user.

Pros Organization Ease of Implementation ­ Requires almost no effort on the part of

organizations. We are simply using their website like a regular user.

Cons Server­Side Maintainability ­ Any changes to the forms or authentication will break the

process and will likely require frequent maintenance on UBR's side. Server Side Ease of Implementation (Authentication) ­ PollardBase is built on

Drupal/PHP, which means the site is not designed to be used by robots. Authenticating and navigating the site programmatically may be difficult.

Server Side Ease of Implementation (Validation) ­ If there is an error in the user’s submission, retrieving that error from the organization’s website and forwarding it back to the user will be extremely difficult.

27

The push model might be represented graphically as shown in figure 1 below.

Figure 3: push model

Option 2: Pull model We could allow organizations to request data via an HTTP request to our server. Periodically, the organization’s database could request any surveys which have been shared with them since their last request.

Pros Server­Side Maintainability ­ Our API can remain the same forever, no matter what

changes organizations make to their own systems.

Cons Organization Ease of Implementation ­ Organizations will have to create a system which

can query our database and integrate the results in their own database. Client Usability ­ A user’ data is not immediately visible on the Pollard website. This

could become a usability concern. Users might export a survey to Pollard, then log in to see if it's there. When they see it's not present, they could lose trust in our app and imagine that their survey was lost or our system is broken.

28

Server Side Ease of Implementation (Validation) ­ This is still an issue. Now, if Pollard's validation routine finds an error, it is cumbersome for them to notify our server and, subsequently, for our server to notify the user.

The pull model can be represented graphically as shown in figure 2 below:

Figure 4: pull model

Decision After discussing these options, we chose the pull model. Although the pull model comes with its share of problems, the solution is significantly more maintainable and scalable. Furthermore, the organizations we are working with agreed this option wouldn’t be prohibitively difficult to implement. The client usability concern can be mitigated if we increase the frequency of polling requests and implement a simple system which shares the status of an export with the user.

29

How do we link UBR accounts to the accounts within an Organization’s database?

Problem Description When an organization queries our database, they need a way to discern which of their users submitted each survey.

Option 1: Organizations maintain account mapping Each user could have a unique token long enough and random enough that it cannot be guessed. Users could share that token with organizations and ask that surveys submitted with the token be associated with their account on the organization’s website. When organizations request survey data, that data could have a user token attached to it so that it could be mapped to the associated account with the organization.

Pros Server and Client­Side Maintainability ­ We do not need to know any information about

how an organization’s website and database are implemented. As such, we do not risk the account mapping being broken by a user changing account information on an organization’s website.

Cons Organization Ease of Implementation ­ Organizations will have to create a system which

can map UBR user tokens to user accounts on their own system. Client Usability ­ This system is unlike other system users are accustomed to using. The

process of associating with each account is unintuitive and hard to teach and learn. Users may simply not use this feature because of its complexity.

Option 2: UBR maintains account mapping We could maintain an account mapping on the UBR server. Users could provide some form of identification for their organization account, which we would attach to their exported survey data.

Pros Organization Ease of Implementation ­ There is almost no extra work for the

organizations. They would only need to implement functionality for reading the identification information attached to each survey.

Cons Security ­ We must store and transmit sensitive user data. This is difficult to do safely

and securely and is best if avoided.

30

Maintainability ­ The identification information must be final and consistent for each organization. We have no way of validating the correctness of this information.

Client Usability and Server Side Implementation ­ If the user changes their account password and authentication fails on the organization’s server, we have no way of knowing this and the user has no way of knowing why their surveys aren’t being submitted. It may also not be clear to the user which form of identification is used for each organization.

Decision In the interests of user security, it was decided that organizations should maintain the mapping of UBR users to their accounts on the organization’s website. In this way, the UBR platform does not store any user information pertaining to accounts outside of the UBR platform. Though this decision makes it somewhat harder for organizations to implement account linking, it should not prohibit this functionality. Furthermore, our team is willing to work with organizations to provide a solution that meets their needs.

How is data synchronized between the apps and the website?

Problem Description When users create survey data on the mobile applications, that data must be accessible on the “MyUBR” website.

Option 1: Unidirectional data flow We could use the mobile device as a data collection tool. Users could collect all their data, then submit it to the UBR website. After submitting, they could view their surveys on the “MyUBR” website for analysis purposes only. They could not change the surveys from the website after submission.

Pros Overall Ease of Implementation ­ This system is straightforward for app and server

developers to implement and maintain.

Cons Client Usability ­ This is a very limiting paradigm and it may be hard to understand and

for our users. Users may want to edit the survey on the website because it is more comfortable to record information with a full keyboard. Users may also want to edit already­submitted surveys, which this paradigm doesn’t allow for.

31

Option 2: Bidirectional data flow We could view the various parts of our system as a cohesive whole. That is, the surveys and their state are kept in sync in real time across all platforms. The creation or editing of a survey on a mobile device could be instantly visible on the website, and vice versa.

Pros Client Usability ­ This system is much easier for users to understand and use. It provides

intuitive features and would be very convenient for our users.

Cons Server and Client Side Implementation ­ Implementing such a system from scratch

would be very, very difficult.

Decision To provide UBR users with the most power and flexibility, it was decided to allow bidirectional data flow between the mobile applications and the database.

Which back-end platform should we use?

Problem Description A server and database system with user authentication and a well­defined API is very complex to implement. It was imperative that we choose a set of libraries or a platform which will be secure, powerful, and easy to use.

Option 1: Python Flask Server We could create a Python server using the Flask framework which has a set of HTTP endpoints for creating and editing surveys. We created a prototype Flask server to test this system.

Pros Flexibility and Power ­ Since we would be implementing from such a low level, we would

have the power to implement almost any functionality we could dream of. We would also have access to the massive library existing Python packages.

Cons Server­Side Ease of Implementation ­ This system would require a large amount of code

and work to get running. Bidirectional data binding would be very, very difficult to implement from scratch.

Security and Replication ­ We would have to implement our own login and account creation functionality, which can be tricky and dangerous. We would also need to worry

32

about how to replicate our data and ensure its safety and stability, even if our server crashes.

Option 2: Google App Engine App Engine is a platform­as­a­service (PaaS) cloud computing platform for developing and hosting web applications in Google­managed data centers. We could take advantage of this platform to host our database and website. We also created an App Engine prototype to test out the various features of App Engine.

Pros Data Replication and Safety ­ We get a safe, scalable, replicated database and API with

no extra work. Server Side Ease of Implementation ­ App Engine Uses Google’s extremely fast

distributed network and supports all Python libraries for whatever features need to be implemented in the future. It supports image uploading and storage with little extra work. User management and security is completely handled by Google auth, so we would not have to store any sensitive information.

Client­Side Implementation ­ Client implementation would be fairly simple. Apps do not need to know about data storage details; they only need to authenticate with Google and submit survey data requests to the server via REST endpoints.

Flexibility and Power ­ Server­side development allows for easy implementation of advanced features (crons, file exports, etc) and can simplify client­side development (jinja templates, asset­management, etc).

Cons Server Side Ease of Implementation ­ Some server­side code is necessary to serve

pages and validate requests. Bidirectional data binding would be very, very difficult to implement from scratch.

Server Side Maintenance ­ Changes to data require changes to the server­side code. Client Usability ­ Forces users to use Google accounts for log in.

33

Option 3: Parse Parse is another platform­as­a­service (PaaS) application. Parse could host our database and serve static web content. It also allows for some Cloud Code and custom webhooks. Parse also comes with a set of simple libraries for applications to authenticate and interact with the database. Under this paradigm, apps could interact directly with the database rather than through a UBR server API.

Pros Data Replication and Safety ­ We get a safe, scalable, replicated database and API with

no extra work. Server Side Ease of Implementation ­ We wouldn’t need to implement any server­side

code regarding authentication or serving static content. It supports image uploading and storage with little extra work. Parse also automatically syncs data across platforms efficiently and safely.

Cons Flexibility and Power ­ Parse robs us of a lot of power and flexibility since we would be at

its mercy when it comes to validation, could code, and data management options. The clients would interact directly to the database, so some functionality, such as pushing data to organizations in the future, would be impossible.

Security ­ Anecdotal evidence (from Tyler) has shown that security is very, very difficult to get right. Many apps relying on Parse have been shown to have large security vulnerabilities.

Client­Side Maintenance ­ Most application logic would reside on the mobile apps. This means the duplication of all business logic and that even small changes would require changes to the mobile apps and updating through the their respective app store.

Decision In the end, we chose to use the Parse platform thanks to its promises of easy integration with mobile applications, simple authentication services, and bi­directional data mapping. We have since discovered many limitations associated with Parse’s features which has caused many difficulties in developing the application.

34