Joyage

Attending the Le Wagon Bootcamp in Tel Aviv, we got together as a group of four building Joyage as our final project bringing together all the skills and languages we learned the last 7 weeks.

Joyage is a platform for groups of friends who are spread all over the world but want to meet for a trip. After deciding on a destination, each one will start looking for flights and - as we all know - there will be at least one person who needs to spend a lot more money for the flights than the other ones. With Joyage, one is able to insert the different origins from each one, the date range, a maximum budget as well as a category and is provided with the cheapest destinations for everyone.

Setup

Before starting to code, we created a prototype by building UX personas and a UI kit in Figma. With the UX personas we structured the user journey and translated it into a flowchart using Whimsical. Together with the UI kit we were able to build the prototype showing all pages and features we wanted to have.

Based on this prototype we were able to structure our project efficiently on the first day of coding. We wrote down all the pages and from that we brainstormed on which routes we would need to create, which information we want to present and how we would extract them from the API. As a next step we created a Trello board presenting all the tasks and steps that need to be done and distributed the tasks. Before we started coding, we created a new Github repository and pushed to deployment on Heroku. Starting coding, two of us worked on the back-end while the other two started with the front-end adapting the design we already created in the Figma prototype. For the next two weeks we developed a schedule for every day consisting of a meeting in the morning and the evening to update each other on the tasks for everyone and the progress at the end of the day. Throughout the coding we followed the rule to code every new feature in a new branch in Git. So, during the day we merged several times with the master and at the end of every day we pushed the new status to Heroku.

Challenges

The main purpose of the website is to allow users to interact with the Amadeus API in a way they understand. Therefore we needed to transform the user’s input to data we can send to the API and make a specific amount of calls with. Then we took each of those calls and made them presentable to the user.

Our initial goal was to receive the users’ origin countries and budget they are willing to spend, search for all destinations they could go to, and then present them by price in ascending order. However, after understanding how the API works, we realized that searching for every possible destination given each origin by the user would take a lot of time and would require a large amount of calls. Given this situation, we had two options to narrow down the API calls: Initial we thought of finding the average location between all origins, assuming that the cheapest flights would go to the area around the average radius. This solution would have required too much effort and wouldn’t have given us accurate enough information for our purpose, which is why we negated this option. Instead, we chose to limit the amount of destinations to one that could run on Heroku: eight API calls. As this implied only eight combinations of origin and destination, we chose to have two origins and four destinations.

To make this possible, we created a database with all possible origins and destinations, each having only the information we need for the website. We created in total 20 destinations, and, in order to make the search more precise, we divided them into the following categories, beach, city, ski resorts and nature with each having four destinations containing the following information:

dap_name: "John F Kennedy International Airport" (destination airport name) d_city: "New York" (destination airport location:city) d_country: "United States" (destination airport location:country) dap_code: "JFK" (destination airport IATA code) d_latitude: 40.63980103 (destination airport location:latitude) d_longitude: -73.77890015 (destination airport location:longitude) category: 2 (each destination received a category, 2 being “City Life”) photo: 'http://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/e7d8fb70-51b3-422a-b8b6-6598d76cd1f0/Imagee620904e40065de136fafe993c24b176/TimesSquare.jpg' (a photo to present with the city’s name)

With this list, we were able to create a range of options while maintaining a limited amount of API searches.

Having been confronted with the above-mentioned challenges, we recognized the great importance of communicating with each other, speaking about problems and difficulties as well as giving regular updates. Also, the precise preparation of our user stories and the prototype helped us not only to be on the same page regarding the design but also to know how to approach the code in terms of information we wanted to present.

Built With

• amadeus
• bootstrap
• css
• devise
• figma
• flatpickr
• heroku
• html5
• javascript
• mapbox
• ruby-on-rails
• select2