My name is Scott Pritchard, and I’m a Javascript developer in my late 20’s based in the north of England. I’ve been coding since around 2006 in my own time, creating projects that range from setting up and adapting a CMS and forum, building a desktop hardware monitor for Windows, building a live chat platform for a major outsourcing company and working on sportsbooks for some big names in the industry.

Today, I’m going to tell you how I built my own commuting app and API to optimize my daily commute to and from work. First I’ll cover how I discovered Expo, my inspiration for the project and my first attempt at the project. Then, I’ll cover some key lessons I learned about user behaviour and UX.

The project I’ll be discussing today is called Panther Commute (available on the Google Play Store for Android, and the Apple App Store for iOS).(At the time of writing, the app only supports mainland UK train stations and times)

Discovering Expo

Day to day, I work as a full stack developer but primarily focus on front-end projects including websites, web apps, and mobile development. It was June 2018 when I first heard about Expo.

I’d mentioned to one of my colleagues that I’d been trying to get started with React Native for my own projects but had trouble setting up react-native-maps due to the native parts of it. It was at this point that he mentioned Expo, briefly explaining some key facts about it. That evening, I had my task — learn more about Expo.

Why Expo?

In addition to the native parts of adding libraries, I discovered that Expo had more to it than just libraries. Sure, the libraries were a big part of it, but the workflow it allowed made things easier. I didn’t need to compile the app on my system, I just had to write JS, let expo handle the bundle and compilation.

On top of this, I didn’t need any native libraries that weren’t included with Expo. It gave me all the libraries I felt I needed. Even to this day, I’ve not found any native library that I absolutely need that’s not included with Expo. Your mileage may vary, but I’m a strong advocate for the platform because it simplifies the development process allowing me to focus on the key part — developing my projects.

I’d worked with mobile a little in the past through the Delphi Firemonkey framework. However, now that I work in the world of Javascript, that was no longer an option, and the costs for Delphi are exorbitant. If you think buying Apple hardware and maintaining developer licenses is expensive, that pales in comparison to the cost of even a single year Delphi architect license at over £4000 GBP (even their lowest level professional license costs in excess of £1200). In addition to this, the community around it has receded into near-hiding, and is even more disliked and dreaded than PHP.

Inspiration now arriving at Platform 1!

Inspiration isn’t endless. Unlike this train. Probably running on time too.

The project I’d been wanting to work on was a train times app. The options that were out there didn’t quite offer things in the way I wanted them. I wanted information quickly, with minimal navigation needed.

It was also a perfect project for learning React Native — lots of data, doing my own styling, navigation, all the goodies. Commuting apps do exist of course, but I found that there was always something that took more steps than it needed or were less than optimal for 1-handed usage.

My end intention was to provide users with the ability to view nearby train stations, view departures and arrivals at stations, bookmark stations and services, plan journeys, and view where a service was in as few taps as possible and without having to hand-juggle their device.

I had more than a few reasons for doing this. Firstly, I commute using a high powered electric scooter for the ‘last mile’ parts of my journey (a minimum of 3.6 miles per day, but often in excess of 9 miles) and take this on the train for the bulk of the journey. I need to know which platform to be at to ensure I can get a spot on the train and to prevent me from having to go in and out of lifts more than necessary. It weighs almost 30KG so stairs aren’t an option.

Secondly, knowing if my train is delayed and the reason why lets me prepare for the rest of the evening, and even to let relevant parties know if I’m going to be late. After all, “I’m going to be late” looks bad, moreso if you can’t provide a reason.

Finally, it allows me to know if I can stay in bed a few minutes more in the morning. If my train is going to be late, no sense leaving the house early and sitting in the cold for 20 minutes more than needed.

Now that I had a project, plenty of reasons, and a framework to build with, I could begin. To cut a long story short, within 6 weeks, I’d released my first React Native app, called ‘Panther’, to the Play store. It made use of TransportAPI as it’s data source. I’ve glossed over this part — this is because it was the first version of the app, and that’s not the primary focus of this article.

The goggles - they do nothing!

Considering Panther was my first project, I thought I’d made a good impression. I was amazed that I’d produced something that run on mobile without workarounds or wrapping a webapp in a webview. Looking at it now, it’s amazing to me that I like this UI and thought it was easy to use.

Everybody loves gradients!

Believe me, the bottom navbar was meant to be blue like the header. Before you ask, you are seeing double navigation of tab navigator with tabs inside. I think at one point in development, I had another level of tabs inside one of the screens.

Remember, this was after 6 weeks of learning a framework where I had only a little bit of previous experience (due to a project I’d been assigned) and having only learned React ~3 months prior. I didn’t even use maps in this version of the project in the end so Expo might not have been needed.

With my hand on my heart, I can say without a doubt that the UI is a retina-searing mess of almost-neon.

It didn’t last long

It was only around 2 weeks after releasing this that I decided to rebuild. I’ve waited for trains that have been delayed longer than that!

I’d learned enough about RN and had enough willingness to rebuild the app avoiding the mistakes I’d made the first time around. Around the same time, I moved from Android (Huawei Mate 10 Pro) to iOS (iPhone XS — which had only just been released) for day to day usage.

The project had bugs. The ‘splash screen’ was scaled incorrectly (I put that in quotes because it wasn’t technically a splash screen in the way you’re meant to make them), scaling was way off, and of course there were the notch-issues. It had buttons and icons which did things but didn’t provide user feedback. Plus, it was bright purple. It worked, but it wasn’t what I had envisioned at all. You could say it was a project of exploring what was possible.

I could have updated the project to work with iOS, but I wanted to do things differently.

We can rebuild him. We have the technology.

Thus, in the middle of September 2018, it was decided. It would be rebuilt from the ground up. I’d go with proper theming, using the brand-colours approach with primary, secondary and tertiary colours rather than “well, let’s use gradients everywhere”. I’d limit colours to ensure consistency, and make sure that my icons were all consistently styled.

Within a few days, I’d created a basic rebuild that would lead me on a 6 month journey:

2 weeks of work on the next version of the app

Black and Yellow. Not the colours I ever expected I’d put together for a UI but it turned out to work perfectly. I realized that this provided the dark UI that was much easier on the eyes and using a contrast colour which was less likely to interfere with sleep.

It had support for bus stops and train stations. It had 3 tabs, a hero unit (of sorts) to display information about a stop, and a header to allow displaying of the list icon. The layout works and it remained this way for a very long time. For the next few months, right up until December 2018, I kept this design.

Did I change it? I had to. Why did I change it? Usability and UX. The top right corner isn’t accessible, but it’s how you access a list of stations instead of the map view. The map itself is on the edge of the thumb stretch zone. There’s also information that really isn’t relevant to the user such as the stop number and geographical coordinates. Sure, they might want this information, but mostly it was just present without the majority of users caring about it.

Lesson #1 — More data in your UI is not always better.

By the end of November, more features had been added, but the UI was still similar;

Those buttons still took up lots of space so they’re touchable, but that icon in the top left was still inaccessible. The tabs had text and icons on them. It’s good, but there’s still so much more that can be done.

Day to day, I work with a truly world-class team of developers and designers, and I’d picked up a few key design tips. Slowly these were materializing, but I hadn’t realized it.

The epiphany

The christmas holidays began, and I had plenty of time to actually sit down and design something better. I realized something — I’d been assuming that the app users wouldn’t understand what an icon did.

There’s psychology behind this — people don’t naturally read first before taking an ‘automatic’ action. Take a look at the problem we have with doors and door handles. Even if a door says ‘push’, if it has a handle on the same side as the sign, people will instinctively try to pull the door open. Their reflex action is much quicker than their brain processing the action of reading a sign, understanding it, and adapting their bodies action in response.

Labels are overrated and overused. An icon can represent your intention just as well while reducing space usage. There are well established icons which represent common tasks, such as geolocation, bookmarks, information, etc. Minimizing the processing the brain has to do allows users to easily navigate through your app.

Lesson #2 — Icons and labels can both serve the same end result, but do so in vastly different levels of effectiveness.

Those huge buttons had to go. They may fit the theme, but they didn’t fit the usability criteria I had in my mind. The button in the top right was a mess on other devices, being out of alignment and even completely broken on some of them. The map needed to be the primary focus, and I should make use of the areas surrounding the notch.

The final lesson — Make the primary purpose of a screen easily evident. If it’s a full screen feature like a map, adapt your UI around that to make it as easy to use as possible.

Thus, I set about refactoring the UI, and eventually ended with what is the current design;

The selected station name is clearly presented at the top. The header area has an overlay near it so that the clock and status icons are readable. The icons in the area above the tab bar represent what they do (timetable, bookmark toggle, station information). The timetable icon could be represented with several other options, but this represents that it’s a searchable list.

The tab buttons are just icons now, which represent what they do. There was room for UX improvement even here, not just by removing the labels. For example, if you press the left-most tab icon when it’s active, it’ll scroll the map to your current position.

You’ll notice that the focused tab has a different colour and an ‘overline’. I feel that it is imperative that users with visual disabilities are able to access the app as easily as possible. If a user is colourblind, they can still identify the active tab from the overline. At one point in development, I also adjusted the size of the focused icon to make it more prominent, but decided against this as it would break the UI on some devices.

The second tab along is the list of stations. If you press that when it’s the active tab, it’ll focus the search bar that’s in that screen. This prevents the need to stretch to the top of the screen. These 2 icons also change when they’re the active tab;