What if your next trip could lead you somewhere you never dreamed you'd end up, doing things you'd never imagined doing? When you plan a trip with a destination in mind, you're limited by the bounds of your own experience and, often, the places you've already travelled. The essence of this application is discovery: to learn we could explore a destination we might otherwise have never known about or considered. We wanted to know: given a certain budget, what might our next adventure look like?
What it does
adventureMe takes a budget, vacation length, search start date, and takeoff point, and finds out just how far you can go. adventureMe calculates not only what deals exist today to make your dollar fly you further, but what events and attractions you can visit when you get there; adventureMe takes the "wishful" out of your thinking--this is about what you really can do with what you have.
How we built it
To get data, we used the expedia APIs of Things to Do and Unreal Deals APIs. To get more time-sensitive event data, we used the Eventbrite public API for ticketed local events. With this data, we had a collection of flight/hotel packages and activities which were reachable from the user's starting point. This back-end was built using node, express, socket.io, mongoDB, as well as a few NPM libraries.
Our driving concept, impacting logic and user experience, was discovery: how can we help users discover what is possible for them? Every time we came to a crossroads, we used this concept to help drive our development choices.
Challenges we ran into
It's not possible to search the Expedia APIs without a destination! We used the Flight Search API's array of searchable airports to limit our choices and run a search against the user's stated starting point--if there was a deal to get there, we checked it out.
With so many airports, we wanted to avoid slamming APIs with thousands of query hits, as well as prioritize speed as much as possible. At the suggestion of an Expedia volunteer, we limited the airport options to 34 of the world's busiest airports. Speaking of speed, we wanted to cache the package data to make the user's queries faster. However, due to the variance in the customers' lengths of stay, we were unable to cache that data, so we always have to query the API live. As with most queries, we now have a rather long loading time to return the data to the user. We took this challenge as an opportunity to provide the user with an entertaining load-time film (which also happens to be an opportunity to bring in advertising revenue).
Our Things to Do and Eventbright data was a bit easier to predict, so we built our own Mongo database to cache the information--rather than make thousands of calls to external APIs, we have all the information at our fingertips. This database is updated every couple of days to keep data fresh.
A common consideration for us was navigating the tension between trying to provide the user with an automated service, and having to predict their needs and desires. This was a regular source of discussion, as cultivating an experience that was both simple and actually useful to a user was our highest priority.
Accomplishments that we're proud of
Handling data from multiple APIs--especially APIs that aren't meant to talk to each other--is a real challenge, but we managed to make the data do what we needed it to.
Our solution for creating the discovery experience, given the APIs we had. Not only did we get APIs to speak to each other, but we used our own logic, and those APIs, to create a fresh experience that they weren't originally intended to provide.
Our UX is fun and reflects a brand we think is pretty cool! Our focus on the concept of discovery helped us narrow and refine our product.
In an industry that is flush with frameworks, we made a robust SPA from simple jQuery and native JS/CSS/HTML.
What we learned
We learned that the Expedia API can take a lot of queries--apparently, 40,000 isn't really that many!
We learned a great deal about what the different APIs provide, and kept discovering more--it took us some time to understand things like how searching for a travel package/deal is conceptually different from searching for a vacation.
As is always a challenge with Node, navigating asynchronous timing was a difficulty. We all learned more techniques for managing that well.
Manipulating the data to present what we think is most important--the location's attractions and spirit, as well as just how much adventure is available within the user's budget--was a tricky but very satisfying endeavor. To emphasize the "discovery" experience of our app, we had to massage the APIs' data to suit our needs. It was worth it.
What's next for adventureMe
One-click booking: take it away, Expedia!
Creative handling of query lag time--how can we provide the user with a great experience during that time?
Pre-load options using geolocation of user upon site entry to give them an idea of the kinds of adventures they could take (could potentially include featured deals from Expedia).
A road trip option. Limiting our prototype to flights gave us a neat data set to work with--a road trip opens up even more possibilities.
More detail! I'd love for our algorithm to include more travel aspects--cost of food/gas and car rental, for example.
Pay-ahead and custom notifications. Users can pay a small amount toward a vacation at requested intervals and be notified about adventures their growing budget can buy--or simply log a budget amount with us and be notified on what adventures open up.
"Send them Packing" feature: crowd-source a vacation for someone, then vote on where they go (the more you've contributed, the more votes you get!)