Trailblaze is a Tinder-style mobile application created for CPEN 291 Computer Engineering Design Studio, 2021. It was designed to connect hikers with the best views offered by British Columbian trails. It combines two machine learning models to recommend hikes tailored to the user’s preferences. The first model, an embedding-based recommender system, is used to generate a list of hikes similar to the user’s previously liked hikes; the second model, an image classifier, is used to identify visual features in liked images, and recommend hikes which contain similar features. These two models are connected behind the scenes to a mobile app, so the user can find new hikes from wherever they are. The combination of powerful machine learning and the convenience of a mobile application make Trailblaze the ideal tool to help hikers on the move find their next destination.

Once opening Trailblaze, users start by filling in a short profile, including their preferred hike difficulty, trail length, and elevation gain. Next, users are able to swipe through a deck of cards, with each card showing a collection of images from a hike. Each hike and its photos have been sourced from the popular hiking website, Cards which are swiped right are marked as likes, and are added to the user’s matches screen; cards which are swiped left are marked as dislikes, and are ignored in the app. On the matches screen, the user can see more details and photos, and they can follow a link to the AllTrails website for more reviews. The user’s likes and dislikes are taken from the hike screen and sent to the backend using a RESTful API. Based on these ratings, a recommender machine learning model will find hikes similar to that of the user’s liked hikes. These hikes are then sent to an image classifier to predict if the user will like them, based on photos of past liked and disliked hikes. All hikes that are predicted as liked are sent back to the mobile application, where the new hikes can be viewed and rated by the user. The more hikes the user reviews, the more refined and accurate the recommended hikes become.

Project Overview

From the user’s perspective, the mobile application is where the action happens. Upon opening the application, users are greeted by the sign-in page where they can sign in with their email and password. If this is the user’s first time on Trailblaze, they can create an account with their name, email, and a password. This information is used to save their preferences when they are not using the app. Once signed in, the user is on the profile screen; here, they can input their preferred hike distance, elevation gain, and difficulty. Switching to the hike screen using the navigation bar, the user is shown a stack of cards, each displaying a unique hike. Users can scroll up and down to see photos from the hike, and can swipe left or right to rate the hike; swiping right likes the hike and swiping left dislikes the hike. Once the user nears the end of the card stack, an API call is made to get more hikes from the backend based on the user’s previously liked hikes. Moving on to the matches screen, all of the user’s liked hikes can be found again in a list format. Tapping on any of the hikes will bring up more details. On the unique hike page, the user can scroll vertically through the available images; the hike name, difficulty, length, elevation gain, location, and hike type are all shown below the images. Two buttons at the bottom of the screen allow the user to take more action. The first button takes the user to the AllTrails webpage in their mobile browser, where they can see more photos and reviews; the second button removes the hike from the matches page if they are not interested.

Moving behind the scenes, there are 3 API calls that connect the mobile application to the backend: posting user preferences, posting reviews, and getting hikes. In the app, when the user switches from the profile screen to any other screen, an API call is made to post their preferences to the backend. Upon making this call, the backend creates a new user if the username is not found. The new user’s profile information is stored and used to curate the next batch of hikes; any hikes that do not meet the user’s preferences will not be considered for recommendation.

On the hike screen, every time the user swipes on a hike, an API call is made to post that review to the backend. The backend receives the name of the hike and the rating, and uses this information to update the models. First, the image classifier dataset is updated; the hike name is used to identify any images in the unrated folder and move them into the liked or disliked folder, depending on the rating provided. Next, the recommender model receives the review, finds the matching hike in the database, and updates its model. When 10 reviews have been received by the backend, the image classifier trains for one epoch using its updated dataset. After it is done training, the backend prepares the next list of hikes to send to the user.

To produce a list of hikes, the recommender model starts by producing a shortlist of the 20 best hikes for the user. It does this by first filtering all the hikes in the hike database which meet the requirements for hike length, elevation gain, and difficulty specified in the user’s profile. It then compares these hikes with the user’s preferences, which are determined by the user’s previously liked hikes. The similarity between the hike and the user is calculated using cosine similarity, and the most similar hikes are selected for the shortlist. This shortlist is then sent to the image classifier, where hikes are either rejected or approved based on the mean predicted rating of the hike’s images. This final list of approved hikes is saved for the next API call from the application.

When the user nears the bottom of the stack of hike cards, a third API call is made to get more hikes from the backend. When the backend receives this call, it sends the list of approved hikes from the image classifier immediately. Shortly after the list is sent, the image classifier will retrain with its updated dataset. Although the hikes sent to the application are not based on the most recent ratings from the user, this is done to improve the user experience. The models train at the same time as the user swipes through their current hikes so that there is a list of recommended hikes ready to be sent to the application as soon as the API call is made. This slightly decreases the accuracy of the hike recommendations, but significantly reduces the wait time between reaching the end of the stack and receiving more hikes.

Built With

Share this project: