Hey Google! When is the next bus…..
By: Anand Radhakrishnan
Tags: Dialogflow, Webhooks, GraphQL, Hsl Hrt, Google Assistant

Voice Assistants — Future of user interface!

Title describes the exact use case which motivated me to develop a google action that can guide me with two tasks:

When is the next bus to a certain destination? When does a certain bus depart for a certain destination?

In both these cases, the source location is my home in Espoo, Finland. My family members use public transport most of the time for their commutes. They have been using the official Helsinki Regional Transport application, for probing the bus timings. However, using the app (including android/ios) is an overkill when you just need to know the departure time of the next bus from a nearby stop. The transport schedules are different for weekends and they also change in spring and autumn. As an alternative, to using the apps, we have printed schedules in the kitchen which are used as reference. One day my daughter asked me if she could use the Google Assistant to check for bus timings from a nearby stop. We do have a couple of Google Minis around the house, so this did seem like a convenient way to get the bus timings. We gave it a try and disappointingly realised that Google Assistant did not fully support public transport details for Helsinki Regional Transport (yet!). As a person who believes that conversation is the undeniable future of user interface (yes, I am biased!), I felt motivated to develop a conversation based app that could help my daughter. In this article I have tried to describe the steps followed to realise this use case. It was also a learning opportunity for me to develop my first google assistant application.

Requirements & Assumptions

To start with, I discussed with my daughter and pinned down the following assumptions and requirements:

Source of the journey is always fixed (home!) There are only 3 bus stops around the house from where a journey could begin, so the app will consider only these stops. Destinations are limited to single legs. In other words, the idea is only to know the route details to the first drop on a journey. For e.g. if the journey involves bus-A from source to destination-A, followed by bus-B to final destination-B, the proposed app only needs to inform the time when bus-A departs from source.

Data source

Next step was to hunt for the source of data. Fortunately, Finland is a huge proponent of open data and it was quite easy to find what I was looking for — HSL Journey Planner API (HSL API). However I did not expect to come across GraphQL. This is a a new generation query language that solves the problem of “over-fetching” and “under-fetching” in traditional REST based interfaces. It took me some time to get my head around what GraphQL was trying to achieve. However many articles later, I decided to give it a shot instead of using the REST interface, which was also an option provided by the HSL API.

Back-end webserver

The conversational app will need some back-end support to query the HSL API, parse required information from the results and then format that to a structure that Google Assistant can speak out. I decided to write the back-end server logic using GO programming language. Idea was to host this application as a webserver in one of my spare laptops running in my home network. I was hoping to “point” Google Assistant to fetch results from this webserver using a Webhook service.

Front-end Google Action

The front-end is obviously a conversational interface. This can be achieved by implementing “Actions on Google” that will:

Convert speech to text → Extract parameters from the text → Provide these parameters to the Webhook service → Collect the response → Convert text back to speech.

Architecture

I decided to name the application “My Bus” (many other options I tried were already reserved!). The big picture looked something like this: