A Travel Diary App
No code required. Almost.
Lots of people write blog posts about their trips around the world, where they describe the amazing places they have seen, the food they ate and the people they have met. Many travelers create photo albums on Flickr, post articles on Medium, or simply have a series of check-ins on Facebook to make their friends jealous.
Unfortunately, writing a blog post, taking the perfect photo or checking-in on Facebook is often more of a distraction than anything else. For this reason I have been thinking for a while about building a tool that would do all of this for you. You walk around, visit a place, enjoy the experience, and there will be someone else that will take care of building some sort of travel diary for you.
In a world where almost everybody has a smartphone in their pocket, and more and more people wear smart watches and smart bracelets this is actually quite easy to accomplish. It can be made super fancy and super customizable, but creating the core functionality is really not that hard.
This week I had a few spare hours in the evening and I thought it would be nice to see what I could hack together in a short period of time. The idea was to create some sort of auto-checkin functionality by leveraging as much as possible services and APIs that are publicly and freely available on the Internet and limit the amount of code as much as possible.
The final result is visible here: http://mmarcon.github.io/contentful2cards/. In about 5 hours I managed to glue together 4 different services with 281 lines of code and obtain the first proof of concept for my idea. Below are the details.
Triggers
The ideal scenario would be that when you are visiting a city, a park or any other place, every time you stop to admire something interesting (landmarks, buildings, sculptures) or to rest in a park, an event with a location attached is triggered.
This would be easy to accomplish with a simple mobile application, however for my prototype I wanted to write almost no code. Therefore I decided that even tapping a button would be fine for now, and I went with IFTTT Do.
There may be wearables that can be used together with IFTTT and trigger the same event automatically, replacing the need for the button.
IFTTT has unfortunately one big issue: it does not POST data to custom endpoints. Somebody found a way to work around this issue, but the workaround wasn’t really working for me, so I had to think of another one. The safest bet is obviously email. IFTTT can use your Gmail account to send a message to any email address, and with Do for Android the message can include the current GPS location.
Now, this email needs to get to the core component of my tool. Of course I did not want to setup a mail server that receives these emails. Luckily there are services out there that can be configured to receive emails and transform them into API calls to any endpoint. I went with Mailgun, configured a custom subdomain for it, waited a few hours for DNS propagation, configured a route, and that bit was done. I can now receive any type of event from IFTTT and send it anywhere.
The smart bit
All the pieces that constitute this tool are fairly dumb. They trigger events, forward data from one place to another, store data, and show data. However there is one component that does something more: it exposes an API endpoint that receives a location (latitude and longitude) and fetches some information about it. In this first version of my travel diary application this service uses HERE’s reverse geocoder to guess what such location may be and to assign a name to it. If a search for landmarks does not produce any results it falls back to just using the address to label the location.
With some more coding this step can be made a lot smarter and used to combine together multiple services to retrieve more precise and richer information about the detected location (photos, Wikipedia articles, tweets, etc.), but goes beyond the scope of this first prototype.
Once the place is identified, the information is posted somewhere else so it can be stored, edited later on and extracted to be displayed in a pretty web page.
This components was developed as a quick and dirty node.js application that is running on Heroku. The code is available on Github.
Storage
For storage I signed up for Contentful. Contenful define themselves as an API-first content management system for multi-device online publishing. Essentially they provide a REST API to create, manage and retrieve content along with a convenient CMS-like user interface. API-first CMSs are a very interesting approach to managing content, and it is a very good fit for my use case. In addition to that, Contentful is part of the Berlin startup scene and that is yet another reason for giving it a try.
Contentful provides open source SDKs for several platforms. I decided to call the REST API directly though, and almost everything worked at the first attempt. It took some trial and error iterations to figure out that location fields are also treated as localizable fields and therefore need to be associated with a locale when creating the payload for the API, but I guess this is taken care of by the SDKs that I deliberately decided not to use.
As shown in the screenshot above, all the data from the auto-chekins and the information that is fetched by the smart bit is safely stored in Contentful where it can be manually edited, curated and if needed, unpublished and deleted.
Front-end
The final piece is the front-end. It is a very simple, front-end only web application. It fetches the published items from my Contentful space using their Content Delivery API and display them on a very material web page.
The location field is used to render map tiles for places by using, once again, one of HERE’s APIs.
This page was built with a bit of jQuery, mustache.js and looks material because of Materialize.
This little experiment proves that this concept that I’ve had in mind for a while can actually be implemented fairly easily and quite cheaply. It also shows that there are really no reason for IFTTT to keep not implementing WebHooks. Developers will find a way to obtain the same thing. I had the chance to play with Contentful and their API, and gave me some more insights into it: who knows, I may try to use it for one of my future work projects. Last, but not least, my first web application with material design!
