Transports schedules

SAPO Transportes is a web application optimized for mobile devices. It allows consulting Lisbon’s public transportation schedules; explore the city through the journey planner and save favorite stops and routes.

It was a 2014 SAPO Mobile project, in a development team of 2. I was the UI Developer, with Software Engineer Alexandre Carvalho (@alexandreacarvalho).

Context

Initially it was intended as a native app and for that was well planned and designed by the very talented UX/UI Designer Luis Alves (@luisalves).

At some point in the process, with all UI ready to be coded in Android, something changed in the project and the dead line wasn't a few months but a few weeks away. This made it impossible to achieve building the app natively.

By that time, we had up and running a kick-ass HTML5 mobile framework that started as a proof of concept by Bruno Carreira (@hellc0re) and Luis Carmona (@lpccarmona). The goal was to serve a mobile version for websites that weren't responsive yet, from SAPO and partners. In the couple of years I was responsible for the framework UI code, the number of websites it served reached 198. It was an amazing tool that included all major news publishers, corporative landing pages and, the most relevant for this app, SAPO Mapas mobile.

It was decided to build the transports app within this HTML5 framework, to use the journey planner from SAPO Mapas and build the schedules using custom lists. In the end, the web app would be feeded to a webview in a native implementation, so to be available in Google Play.

Challenges

Native app users are very demanding on performance. This is why they prefer native apps in first place. Providing a barely hybrid app as native was very risky.

The database for the transports schedules were in a third party server, not being confirmed the possibility to store it for offline use and to speed up search results.

The user flow to access and search transports would have to fit within the HTML5 framework, therefore using only lists.

Process

First we identified all key elements and I quicky drew the schedules flow. This exercise was fundamental to see the whole picture.

These flows and notes aren't the originals. They were retrieved from hand drawn messy pages, using draw.io.

Flow homepage Flow schedules

At this point we had everything covered, except for the database. Negotiations were happening so we hopped for the best.

As the UI Design depended on the platform structure and the color scheme was pre-established, I jumped into coding the custom lists for schedules flows and other custom bits.

After iterating a few times to get all elements properly structured, as in an html wireframe, the task was theme customization for system items and UI Design for the others, all directly on code due to time to market.

Final product

Native app

This screens were in Google Play. It shows the first color scheme the app was launched with.

The problems identified earlier couldn't be solved due to heavy legal issues around the usage of the database. As expected, the app was slow and the database errors were such the user sometimes had error messages on top of each other.

The native app users, as the identified risk indicated, were very disappointed. But even disappointed, the users were so nice as saying "Thank you for the effort on building a transports app in portuguese, but it doesn's work properly" or "I like everything in this app, except for being a web app instead of native".

We may still look at what users said  about the native app back then, thanks to Wayback Machine (Link may be slow to open).