Houston App: System overview

Houston, is a mobile application replacing the radio communication system previously used by the Transports Publics Fribourgeois (TPF). Houston is a system using existing data network.

The system is spread over more than 200 busses, 30 team leaders and the operation center. It covers the needs of three types of users: the operators, the bus drivers and the team leaders (Houston: a mobile app to replace a radio communication system).

The major components

So how’s Houston working? Here is an overview of the major components. Houston is a distributed system composed of:

  • Two Mobile Apps that fulfill the specific need of bus drivers and team leaders
  • A Web Client used by the operators to create any type of call
  • A Cloud Communication Platform to establish Voice over IP (VoIP) and standard phone call over the Public Switch Telephone Network (PSTN) without having to deal with the complexity of building and maintaining a communication infrastructure. The cloud platform used in this system is Twilio (more details on that later)
  • A Public API: implemented by a backend server used as a bridge between mobile apps, web clients and Twilio. It is connected to a database that stores user identities and bus planning. The database also keeps traces of all performed calls.

A deeper look inside each component of the system and how each of them interacts together will help to understand why Houston was a huge challenge.

Mobile Apps

Each of the two mobile apps provide specific features for busses and team leaders. There is no specificities in how the app is built. The apps are a set of views that allow to perform calls by communicating with the public API using standard HTTPS requests and JSON formatted messages.

The real challenges were the following:

  • How to allow drivers to use an app without losing eyesight of the road?
  • How to integrate the app with the existing busses microphone and loudspeaker?
  • How to manage and upgrade a set of more than 200 devices remotely, as they are installed in busses dispatched in different locations?

How to tackle the usability problem?

To tackle the usability problem, we organised workshops with the end-users (e.g. drivers) to find out the best way to interact with the app without having to look at the screen. The solution found, was to implement a carousel screen with voice feedback at each screen change.

The integration with the existing microphone and loudspeaker has been solved with the installation of a bluetooth amplifier. The big problematic here was to ensure that the app was automatically connected with the amplifier at any time.

Finally, we decided to use Android4Work and MobileIron to manage the 200 devices distantly.

About the importance of user testing

We started with a prototype running on a server and on real devices. It was working like a perfectly in our offices. However, we should have installed the busses applications in real busses and let final users try it in their daily business. Even though we made many workshops with end users, a sketch on paper doesn’t replace the real experience.

Deploying the prototype in the real environment would have save a lot of time! In fact, we ended up implementing some features that have not been used as much as we initially thought.

Another important lesson learned by our development team of mobile developers is that working with physical devices such as microphones and loud speakers is not trivial. We underestimated the impact of the environment on the device. Indeed, we had quite a bad surprise when we discovered after months of development that the volume in the busses was fare too low. Again, making a prototype working in a real environment would have helped.

Web Client

The web client is a single page application built using backbone JS. The challenge of the web client development was less in its technical aspects than in the definition of the features needed by the operators. In fact, it was difficult to make a system working similarly as a radio in a web browser.

To help operators understand what was happening as they created calls, we decided to display as much information about the state of the call as possible. For example, operators know – from the start of the call – which users are included in it as well as their current state.

Twilio

Twilio is a cloud communication platform offering an elegant way to perform any type of call such as a telephone conference. It offers a RESTful API that completely hides the complexity of the infrastructure behind. Thanks to Twilio, the Houston public API offers the possibility to create conferences between more than 50 users in only one request.

Twilio API offers tons of features. The most used one in Houston are the followings:

  • Getting real time information about ongoing and past calls.
  • Muting / Unmuting users
  • Adding / Removing users to an ongoing conference

But this is not all, Twilio can register calls and offers a nice administration web client allowing to retrieve all records as well as the detailed logs of all performed calls. In addition to that API, Twilio offers libraries for web clients and mobile applications. This helped us a lot to handle incoming/outgoing calls.

Heroku

The public API offers a standardised set of endpoints to serve requests from the mobile applications and from the web client. We hosted it on Heroku in order to get rid of the hosting complexity.

Heroku allowed us to easily scale when the amount of user of the system raised. With Heroku It has been a piece of cake to integrate our system with Twilio and It solved lots of security issues.

Conclusion

Lessons learned during this project are numerous. The most important to remember is that innovation requires to start with a simple feature and to make it work in the final environment. User workshops and controlled environment testing is not enough. It is essential to test prototypes in a real environment with real users.

Finally, I think that what had most impact on the success of the project is the way we worked hand in hand with the client. From the beginning, we collaborated as one team. We were able to share challenges and issues. We did not hide problems, but talked about them openly to find the best solution together.

What’s next

Hundreds of people use daily Houston. Of course there is still many improvements to bring. Today, we are still working on the project by analysing its use in order to improve it by bringing additional or improved features to make this system even easier and powerful to the end users.

Once the system will be stable enough, the door to many developments opportunities will open. Other sectors might be interested to implement similar systems. The good thing is that our team has become very experienced with these topics.

Finally, our team was delighted to be awarded 4 times in 2016 for this awesome project : 2 awards at the Best of Swiss Apps 2016 (“Silver” in Enterprise category and “Gold” in Innovation category) as well as 2 award at the Meilleur du Web 2016 (Winner in UX and in Technology Categories). These awards will just continue to fuel our appetite for more innovation and success! :)

Liip related services

It is wonderful to read about a real experience and development of a project. Great lesson! Thank you for sharing!

Leave a Reply