Davis Triceratops

2022–2023 Yearlong Spark Project

CodeLab UC Davis
12 min readJul 3, 2023

Introduction

Davis Triceratops is a UC Davis community built around daily scavenger hunts for crochet triceratops in Davis, CA. With a dedicated team with 35 members, their active Discord server boasts over 5,300 members. In addition to their scavenger hunts, they host social events, giveaways, design and art contests, and much more for their dedicated members.

Using Discord as the source of communication makes it difficult to keep track of the drops and miss notifications of the drops.

The Team

Vincent Barletta (Project Manager)

Abhay Thacker (Project Mentor)

Vibha Raju (Developer)

Alec Liang (Developer)

Jamie Wu (Developer)

Abhimanyu Warrier (Developer)

Jennifer Kim (Designer)

Camille Nikaido (Designer)

Sanjana Pethe (Designer)

Timeframe

Oct 2022 — Jun 2023 | 21 weeks

Designer Timeline:

  • User research (Week 1–2)
  • Ideation & synthesis + user flow (Week 2)
  • Low fidelity wireframes (Week 3)
  • Design system & mid fidelity wireframes (Week 4–5)
  • Presentation (Week 6)
  • Mid-fi wireframing & basic prototyping (Week 7–8)
  • Mid-fi user testing (Week 9)
  • High-fi wireframes, prototyping, & user tests (Week 10–15)
  • Minor adjustments and finalizations (Week 16–19)
  • Case Study (Week 19–21)
  • Presentation Work (Week 22)

Developer Timeline:

  • Complete the development of the backend components and API requests (Week 1–4)
    — Make the login page with google authentication
    — Setup MongoDB database and develop backend schemas
  • Upload and display images with AWS S3 Bucket (Week 4–6)
    — Upload and retrieve images from the AWS database
  • Skeleton user interface pages (Week 5–6)
  • Google Maps API Integration (Week 8–12)
  • Backend reconfiguration and integration (Week 8–12)
  • Navigation Bar (Week 12)
  • Home page finalized with real-time updating in drop list (Week 13–15)
  • Revamping screens to hi-fi designs (Week 13–20)
    — Reconfigured Mod Drop Form with new Dinosaur dictionary objects and multiple selectable photos
    — Profile calculates stats and allows for notification settings
    — Login Page redeveloped
    — FAQ page implemented
    — Conditional rendering for each user type
    — Full stack-navigation established throughout app
  • Notification system (Week 17)
  • Dinosaur verification system created (Week 19)
  • Report a problem with drop screen created (Week 19)
  • Moderator permissions list created (Week 19–20)
  • Bug fixing and polishing app (Week 20–21)

Tools

Figma: wireframes and prototyping

MongoDB: a NoSQL database to store user and cow data

Amazon S3: store all photos for dinosaur locations

Express: our web server

Expo Go: iOS mobile emulator

Android Studio: Android mobile emulator

JavaScript: our primary programming language

React Native: mobile development

Node.js: backend development

The Project

Design

With Davis Triceratops current system of using Discord as the source of communication, it is difficult for users to keep track of the drops and they often miss notifications of the drops. In order to guide all future design, we asked ourselves:

How might we create a system that effectively organizes all drops, and deliver clear notifications for all drops?

Research

Our target user base is the current Davis Triceratops Discord users and other active UC Davis students that want to get involved with the game. Through user surveys, we deduced some typical Davis Triceratops user personas:

  • Users are animal lovers and busy students that often use the scavenger hunts as a quick and relaxing activity to blow off stress
  • In addition, current users like using Discord as a platform to socialize and share their own art.

The central question that we aimed to ask when approaching a solution

Using Discord as the source of communication makes it difficult to keep track of the drops and miss notifications of the drops.

Feature Prioritization

After polling both over 400 users and moderators for their most request features for the app, the designers accumulated a very large list of potential features to include in the app to improve user experience.

The overwhelming response provided a lot feedback to incorporate in our design. The largest takeaways from current Triceratops Hunters was:

  • More clear notifications of the drops
  • Easy access to hints and location of drops

For moderators that currently crochet and hide the dinosaurs, they requested:

  • Easy organization
  • A convenient method to drop dinos and verify found dinos

Beyond these central ideas, we received many, many more miscellaneous suggestions for various extra features in the app to improve user experience. From this exhaustive list, we determined that some of the highest priority extra features were:

  • Google Maps API Integration
  • Total Dinos Hidden UI Indicator
  • Customizable Notifications
  • Tutorial Page
  • Achievement System / Hunting Statistics

After finishing competitive analysis, user research, feature ideation, and synthesis, our designers began fleshing out an early design for the app’s rudimentary appearance.

Some rudimentary initial mock-ups for potential screens for Hunters and Moderators. Notice some features that eventually were not implemented, such as messaging functionality

Low-fidelity Wireframes

From the Moderator user flow, we developed some lo-fis to reflect some of the primary screens for moderators, including the Home screen and the New Drop form.

Eventually, we decided to reduce it down to just the Drop and Profile Screens, as we deemed the Home screen created in lo-fis to be redundant.

The Dinos hiding would be displayed centrally on the Drops page itself.

Below, the updated Hunter perspective’s low-fi is shown. It has a finalized Navigation bar, along with a stylistic and interactive drop page.

Design System

For a project as fun and vibrant as Davis Triceratops is, we needed a color scheme to reflect that!

We decided to go with a light and colorful theme that reflects the fun scavenger hunt experience. Using off-white cream for the background, green for the navigation bar, purple for primary action buttons, and red for secondary actions, the app is meant to look both playful and bombastic.

Mid-Fidelity Designs

Moderator View:

The largest discernible difference between the moderator and user views is the large Purple (+) icon between the primary icons on the navigation bar. This button allows a moderator to create a new drop, prompting the Edit Drop screen (shown on the right). In addition, on the regular drop screen, they are able to edit currently posted drop’s information by clicking the small red (Edit) button.

User View:

Here, we can see that the Rules Page and # of Dinosaur indicators have been moved to the top of the screen as small, unobtrusive icons. Upon clicking on a drop, you receive hints for the location as well as the verification code section.

The User’s Profile page displays their personal information, as well as their notification settings and dinosaur’s found statistics, two popularly requested features.

High Fidelity and Finalized Designs

After doing user-testing with various Davis Triceratops moderators and users, we received feedback on small changes to implement in our future designs to make the app more user friendly. A key feature that we did not think of before was having an Admin user from the Davis Triceratops organization email that can add and remove moderators as they please.

Below is the updated profile page design, with an additional mod list for admins.

Admin Profile Page:

New Hunter Drop Screen:

While not much looks different from the previous design on the surface, it is important to note the new radii on the map! Rather than hunters being able to pinpoint exactly where the dinosaur is, they will have to look within the radius.

There is additionally a button that brings up a “Report” screen for when there is an issue with the drop. This will be showcased in the development showcase!

New Mod Drop Form:

Lastly, we completely remodeled our Mod Drop form to complement our Dinosaur backend object changes. Each dinosaur has its own specific code and photos specified in the drop down menu. When a dinosaur is found in the drop, their specific images will be deleted.

In addition, there is a second screen for moving the specific radius location, and changing the size of the radius with the drop bar.

Development

Architecture & Design

The application is built on three major parts: storage, frontend, and backend. Storage refers to where the data is saved, and varies based on the purpose of the data. The frontend refers to the screens that the user interacts with, and the backend manages communication between MongoDB and the AWS S3 bucket.

The storage refers to the data saved, which is either in local async storage, AWS S3 bucket, or the MongoDB. The local async storage is for the frontend for ensuring persisting login credentials. AWS S3 bucket is used for storing images moderators input as hints when creating or editing new Drops. MongoDB involves storing documents about users, drops, and dinos (see the Data Structure & Algorithms section for more information).

Frontend consists of the UI pages such as the Login page, Tutorial page, Mod Drop Form, Profile page, and Drops page. The Login page involves Google Authentication, such that we can verify the user through Google. We utilized an Expo library called AuthSession to handle sending authentication requests to Google and handling callbacks to get general information like the name, email and Google ID.

Backend Routing

These are the three backend objects that are central to our app. Drop is by far the most important component as it holds most of the important information for a drop’s location and other key attributes.

The User is used to store a person’s login information and their rank. Their rank is important as the user will have different things they can/can’t access depending on their level.

The dinosaur initially was going to hold more importance before we decided on using a dictionary/map to store dinosaur info in the Drop routes. The Type is simply used on the permission level as dinosaurs will be stored as “May2023” to disallow people from getting more than one dinosaur in the same month.

Each drop object contains GET, POST, and PUT routes to create, access, and update objects as needed.

Frontend Architecture

  • Google Authentication
    The app authenticates and identifies users through their Google account. Users will have to login through their gmail and a new user will be created on our database. AuthSession API was used for browser-based authentication, such that the users will be able to login through Google’s official page. In our Google Cloud project, there is a redirect URI that defines where Google will be allowed to redirect access token to.
  • Geolocation:
    — Moderators/admins will be entering the address in Mod Form and the drop should be plotted around that spot. However, Maps requires a longitude and latitude. To convert user input, we utilized Google’s Geocoding API. Note that we appended the city “Davis” to each input to ensure that address are at UC Davis.
  • Navigation
    Controls overall navigation of the app. In other words, this is how users are able to go to the next screen or back to what they were viewing previously. At the root of the app, there a navigation container that will contain a series of Stack Navigators and a Tab Navigator. There is multiple Stack Navigators such as Profile page (Main Profile -> Edit Profile), Drop panel (List of drops -> specific drop), and more. The tab navigator is the bottom bar with buttons to swap between screens.
  • AsyncStorage:
    — Used for local storage on the user’s phone, such that the user will not have to login each time when they try to access the app.

User Interface

Login Page

The Login page is the first page all users visit. Users will be able to login through the “Login in with Google” button. This will then redirect the user the user to the official Google sign-in page, and after logging in Google with provide us with an access token that is used to access information. No

FAQ page:

The FAQ page is geared towards hunters, and is accessible by clicking the “?” button on the rightmost side of the header bar on the Drops page. Once clicked, the hunter will see a three-panel react-native-swiper component. The three pages are:

  1. FAQ page: foundational information about Davis Triceratops and what a standard drop may look like
  2. Rules page: rules to ensure a safe and fun experience for everyone, such as following the UCD code of conduct
  3. Limits page: restrictions on how many of each dino type can be found to ensure everyone gets a fair chance to adopt a dino

New User/Tutorial page:

When a user logs in, they see a three-panel react-native-swiper component that reminds them to uphold the basic values of Davis Triceratops: “Be civil, Respect the environment, and Have fun.”

Drops page:

The drops page contains components: “Map” and “Drop Panel.”

“Map” just consists of an interactive Google Map with all the available drops placed as transparent circles. We utilized react-native-maps library to build out the map and drops on it. The library contains <MapView /> which generates the map, <Circle /> the drop radius, and <Marker /> for draggable pin on map.

“Drop Panel” is a sliding panel, which allows the users to see available drops in a list. The list will inform the user the location name, number of drops remaining, and the time when the drop was posted in form of minutes or hours.

Profile:

The profile functionality consists of two components, “Main Profile” and “Edit Profile.”

“Main Profile” displays the user’s account information, including their name, email, and Discord ID. Users can also see a “Dino Stats” box that summarizes the number of dinos and Aggieceratops they have found. In addition there is a “Notifications” drop down that allows a user to change their notification settings.

“Edit Profile” allows the user to modify their name, discord ID, and pronouns via text input.

Mod Form:

The “Mod Drop Form” is a key functionality of the app that allows moderators or admin to release new dino drops.

On the frontend, the “Mod Drop Form” includes text input for the drop location. The hints category is optional, and the moderator is able to add new hints using the purple “Add Hint” button or remove hints using the red “-” button. Next the moderator can toggle the Aggieceratops button on/off to indicate the drop type.

The primary segment of the “Mod Drop Form” is the “add a dino” button which creates a new dino object. Each dino object is a react-native-collapsible component, and expands to allow the moderator to generate an unique 6-digit verification_code and select dino hint images from their device’s default image library. Moderators are also able to delete any images or dino objects that are no longer needed.

On the backend, each dino in a drop is stored in a dictionary indexed by its unique verification_code to decrease the number of API calls necessary to update the isFound status of a dino.

Takeaways & Challenges

Designer Challenges:

  1. Designing with ambiguity — we were trying to design some features while they were still not clearly decided on (e.g. — maps of how the radius will be shown)
  2. Articulating client demands into actionable insights

Designer Takeaways:

  1. Designing with the developers in mind definitely changed many approaches of how we designed some features; we would try to simplify our ideas as much as we can in order to make our ideas more realistic and approachable for the developers.
  2. Learned about the feasibility of different types of features based on development time.

Developer Challenges:

  1. Lack of documentation/resources — a lot of the onboarding resources were centered around React, rather than React Native.
  2. Smaller team than anticipated — unfortunately, we had a developer drop from the team, so we were not able to polish/finish as much as we desired
  3. Defined development standard — because this was many of our developer’s first major project, people worked very differently than others. This resulted in a more jumbled codebase that had be redefined later.

Developer Takeaways:

  • Mapping out the desired data flow between technologies is incredibly important to fully understand the behaviors and desired interactions between multiple technologies.
  • Ask lots of questions!
  • Cross-team collaboration is very helpful for building on others experiences. We don’t need to reinvent the wheel every step along the way.

Conclusion

Thank you CodeLab and Davis Triceratops for giving us such a fantastic opportunity to built out a fully fledged app! It is not very often that developers and designers are able to work with each other on a large scaled project in typical academic settings, so everyone learned a lot from the overall experience.

--

--

CodeLab UC Davis

CodeLab is a student-run software development and UX design agency at UC Davis.