Project Overview

Project Vision

Based on the needs of our sponsor, here are the three main themes we focused on as we worked on this project...

Defining the Project Space

Establishing a Foundation with PMMC

In our initial meeting with PMMC, we were introduced to 3 members of the staff that we'd be closely working with for the duration of the project:

• Kirsten Donald, Director of Education

• Wendy Leeds, Animal Care Coordinator

• Dr. Alissa Deming, Vice President of Conservation Medicine and Science

We established an hour-long weekly meeting time during which we reported to PMMC on our progress, answered their questions, and requested more information and resources if needed. Before each meeting, we wrote agendas detailing the deliverables we were to present and the questions we needed answered, leaving space for our sponsors to ask their own questions as well.

They informed us that there was already a version of Seal Spotter on the App Store, made by a team they previously worked with. This version unfortunately was difficult to work with for PMMC's researchers as it required downloading an enormous .zip file each time they wanted to access the reports. The user interface was also unpolished and unprofessional. With these issues in mind, we set about building a new version of Seal Spotter. We received access to the GitHub for the previous app, but found that the lack of communication with the previous team, the poor usability of the first version, and our time constraints made it in our better interests to completely build the new Seal Spotter app from scratch using Ionic and Firebase.

Developing a Plan

To speed up development for both iOS and Android, we chose to build our app in Ionic as it adapts code to suit both operating systems. We chose Figma as our drafting tool as we made low and high fidelity wireframes to flesh out our ideas and present to our sponsor.

In order to stay within a reasonable scope and deliver a fully functional app for iOS and Android by the end of 20 weeks, we set about outlining Seal Spotter's functional and nonfunctional requirements and the user stories that accompany them.

These user stories framed the specific tasks we planned to carry out in order to meet all of these requirements. These tasks were split into two sections: the majority of the functions of Seal Spotter in the first 10 weeks and the report forms and database view in the last 10 weeks.

Functional Requirements

Non-Functional Requirements

Adapting to the Agile Framework

Agile was a new framework that our team had to adapt to working with. We maintained a 2-week sprint structure and tracked our progress using Trello, with the lists Product Backlog, Sprint Planning, Current Sprint, In Progress, and Done acting as organizers for the tasks we had to fulfill.

We created tasks framed by user stories and assigned each task a value based on the amount of time and effort we predicted it would take to complete. These tasks were organized into the Product Backlog and moved to Current Sprint in sections at the start of each sprint.

We assigned specific team members to each task before moving them to In Progress in order to maintain accountability. Some of our members' strengths laid more in design while others' were in development.

We met at least twice a week as a full team to define weekly tasks and get on the same page as the sponsors, getting user feedback from them before moving on with designs and development. As we got further into development, we began splitting tasks between teams more often and working concurrently, translating approved wireframes into code while creating new wireframes for other functions at the same time. These smaller teams would find time amongst themselves to work on their assigned tasks together.

Designing Seal Spotter

Sketches and Brainstorming

Seal Spotter Branding

User Feedback and Evaluation

Between each design iteration, we would always check in with our sponsors and receive feedback on our design to ensure that they were able to have input in our design process. Often, we would create multiple frames so that they could choose which design they preferred most. Otherwise, we would present our designs during our weekly meetings and discuss with the sponsors whether they had any thoughts on our design, and made sure that the sponsors were on board with them before proceeding with development.

Usability Testing

After consolidating the majority of our design, we performed user testing sessions using Maze and simultaneously had the participant perform a think-aloud as they walked through our prototype.

There were a few usability concerns within our prototype that were brought to our attention:

• • Subjects found the wording of the “Animal Emergency Information” button unclear; they were unsure of what tapping on this button would entail.

    • Our Change: We renamed the button to “Animal Rescue Information” to better reflect the button’s purpose.

  • A participant found the photo upload page confusing. The page was lacking a progress bar and question label, appearing inconsistent with the following report pages. This made it seem like it had less importance than the proceeding questions.

    • Our Change: We updated the page's design to include the same progress bar and question label as the rest of the report pages. This way, it would be more apparent that the upload page was part of the report and essential to the reporting process.

A/B Testing

We performed A/B testing for the cancel button located at the top of our "Report a Sighting" pages. We wanted to know whether placing the button would be more intuitive for the users if it were to be placed on either the left side or the right. We sent out a survey asking users which placement they preferred best.

Results

The results showed that users found that having the close button on the left was the most intuitive for them. Thus, in our design, we finalized this aspect by moving this button to the left side of the page header.

Development

Before developing our application, we ran by our high-fidelity designs with our sponsors to get their insight on what should be kept or added to our current design. Once we received their approval of the design, we moved on to developing the Seal Spotter App using Ionic/Angular.

Our development process revolved around the user stories we established earlier on in the project. We addressed a select few user stories in each sprint and developed our app based on these selected user stories. At the end of the sprint, we would present what we developed to our sponsors.

Because our sponsors were non-technical, they did not have much input during our development process. Thus, if we ran into problems, we would have to refer to online resources in order to get development tasks done on time. In order to streamline our process, we delegated development tasks to each member of the team to ensure that someone was responsible for getting a feature done. We would discuss bugs or development roadblocks with each other and had Quality Assurance checks. Doing so helped alleviate any challenges that we came across during the development phases.

Database Overview

Challenges and Finding Solutions

Development

• Understanding an unfamiliar framework - both Agile and Ionic - was a difficult challenge.

  • Agile - As we advanced through the course we adapted to the agile framework and gained more experience managing our project under this framework. With advice from our instructor, we were able to adjust the way we managed our project and grew used to the framework.

  • Ionic - We grew more familiar with this framework as we worked with it throughout the two quarters. Our learning was also supplemented by the ionic documentation, which we referred to constantly during the development process.

Non-technical Sponsors

• Our sponsors were non-technical. This led to:

  • Gaps in terminology and concepts

  • Lack of feedback due to sponsor's limited understanding of development process

  • Lack of technical guidance

• Our Solutions:

  • We had consistent communication with our sponsors, frequently asking them questions and giving updates through meetings and email.

  • We created user stories based on their verbal expectations. We improved the way we presented our designs to ensure there was clarity in what we were communicating.

  • We selected a familiar framework we had experience in to alleviate challenges; we also learned to be resourceful and pooled knowledge from documentation and tutorials.

Deploying Seal Spotter

Deployment

• Developer account access Issues:

  • Since PMMC did not have any records of their developer accounts for android or apple,

• Google Play Store policy breach

  • Due to a change in Google Play Store policy that PMMC neglected to accept, the original Seal Spotter account was terminated from the Google Play Store, and PMMC was unable to establish any future developer accounts for android development.

  • However, PMMC was eventually able to establish an account using an alternative education email which was not affected by the Google Play Store ban.

Hand Off to PMMC

In order to support the long term maintenance of our application, we constructed a handful of documents that allow PMMC researchers as well as potential future developers that interact with our system. These artifacts include:

Figma Design File:

• A file that contains various wireframes, an interactive prototype, app icons and branding, and a style guide for future development on the application

• • • Provided in the form of a link that the sponsor or future developers can access at any time

Source Code

• The actual source code of Seal Spotter itself (developed using ionic with capacitor)

• The source code contains files for both iOS and android platforms as well as several external libraries such as the google firestore database and google cloud location services.

Build Instructions Document

• A file that contains instructions on how to clone the project from GitHub, and install the necessary dependencies.

• Provided in the form of a PDF file

UML Class and Sequence Diagrams

• Multiple UML sequence and class diagrams that describe the underlying classes and interactions between the ionic frontend and firebase

• Provided in the form of a PDF file as well as links to the actual documents themselves on online diagraming tool: LucidChart

Account Credentials and Functions

• • • A document which lists the accounts and services necessary for Seal Spotter's operation, such as firebase credentials, google cloud services and others.

    • Provided in the form of a PDF in the project handoff zip file.

Database Access Tutorial

• A tutorial document intended to provide PMMC researchers the knowledge on how to access the report database, sort, add and remove data and manage access to the database viewer.

• Provided in the form of a PDF file with instructions and several images for reference.

Ethics Review

• A pdf slides deck that explain various potential ethical concerns revolving around the app, as well as several solutions to these ethical concerns.

• Provided in the form of a PDF slides deck.

Find us on the app store the next time you're at a beach! :)

Project Video