BLA Site Manager

BLA Site Manager is a React Native application I built in my spare time whilst working in my previous role as an Acoustic Engineer. The focus was to help streamline regular site visits for engineers in the company, whilst also using it as an opportunity to learn mobile development and experience a large project from start to finish. Some of the key technologies I used throughout the project were:

Expo
React Navigation
Firebase
Jest
React Native Paper (UI Library)
Figma

Project Goals

My role as Acoustic Engineer consisted of working in a small team maintaining Public Address and Voice Alarm (PA/VA) systems in various locations. Many of these sites required navigating secure areas with the help of certain keys or access codes. Over the years, I stored this information on my phone in the form of a messy list, whilst other engineers did the same. Feeling frustrated, I took it upon myself to develop an application that would keep this information organised on a single shared database.

Initial plans were to develop a prototype app for Android and go from there. However it was a relief to learn that cross-platform development existed as we were a mix of Android and iPhone users in the company. React Native's growing popularity, JSX syntax and reusable components excited me and seemed the logical choice for developing the app.

The App

Over the course of development I built several features into the app:

Create, Read, Update, Delete information such as phone contacts and access codes for each work site
Start a navigation route in Google Maps or Apple Maps to a saved address
Log engineer visit and travel times and export them to a CSV file for timesheet submission
User authentication
Light/Dark Theme

Wanting my app to look professional, I found React Native Paper to be the best looking beginner-friendly UI library. For the backend, Google's Firebase was the most attractive option as it allowed me to quickly configure an initial database and user authentication, whilst also giving me room to develop advanced configurations if needed (e.g. authentication roles and permissions).

Spotlight: Timesheet

Development of the timesheet feature began around a year into making the app. Here again was a process in my company that was just asking for a digital implementation; I was keeping messy notes of site visits and travel times on my phone, only to have to write it all out again on paper at the end of the month.

I spent quite a bit of time overhauling the timesheet feature as I wasn't entirely happy with my initial implementations. I struggled with how to best represent the data and provide a decent user experience. Here's a list of the acceptance criteria that I first created that best followed our working environment and supported a typical timesheet submission each month:

Engineers can log start/finish times for multiple site visits within a day
Log time spent travelling and any hours at the office
Provide optional comments about work taking place
Log absences such as sick, annual leave and days in lieu
Provide dates of 'On Call' assignments for weekends and public holidays
Monthly timesheets can be exported to a CSV file which allows for typical spreadsheet submissions to office staff

Hi-fidelity wireframe design of timesheet main screen

In my first approach to revamping the feature, I used Figma to come up with a hi-fidelity wireframe that envisioned a stylish swipeable interface. However, once I got deeper into development I started to realise how complex it was getting. On the one hand, third party libraries offered a ready made swipeable list, but I would come to find myself hitting barriers if I wanted to introduce functionality outside of their design. Alternatively building my own gesture based navigation from scratch would give me the freedom I needed but didn't fit within the time constraints I'd given myself for completing the feature.

I therefore decided to go back to the drawing board and design a simpler interface (Keep It Simple Stupid!). This would help me achieve a minimum viable product quickly , knowing I could always experiment with a more complicated implementation in future. I also searched the market for similar apps to see how other engineers had decided to approach this kind of problem.

Screens showing final implementation of timesheet feature

The final design resulted in a FlatList of date objects providing a small preview of site information and styling to help distinguish 'On Call' assignments. There is also a Floating Action Button for quickly creating a particular entry for the current day, as well as assigning weekend and public holiday dates for 'On Call' entries. On press, the screen changes to a view of each site visit or absence for that day. Jeremy Barbet's Modalize provides a slick yet simple way of gaining further information and access to action buttons. Other libraries that were vital in utilising the timesheet data include Day.js and date-holidays.

When exporting a timesheet period to CSV format, a modal component appears describing the process about to take place. The calculation of constructing each entry into CSV format is actually a lot quicker than the UI indicates; this was intentional on my part as I felt it was a better user experience to observe a loading bar for 1 second, achieved with a simple setTimeout callback. Plus I can speed this up in future and claim I've made optimisations! (joking, of course!)

Lessons learnt

Development of the app was far from straight-forward. I only had a small amount of experience with JavaScript prior to this so the learning curve for React Native felt very steep at times. I definitely underestimated how large the codebase in this project would become, so refactoring code to keep it tidy and easier to maintain was an important process throughout.

In the beginning I noted down plans for the app on a simple text file. In hindsight this probably caused me to feel overwhelmed with ideas, jumping from one aspect of development to the next instead of focusing on a single feature. It wasn't until I started developing the timesheet feature that I began using my Trello board and immediately noticed it's benefits. Taking a Udemy course on Agile development also inspired me to create user stories in order to think about certain functionality and acceptance criteria.

Towards the end of my time with the company, I sought to gain feedback from the other engineers as they trialed it on Apple's TestFlight. I developed the app on a Windows machine with most of the testing carried out on my personal Android phone, so their feedback as iPhone users was invaluable. One of the engineers often joked his memory was too good for him to need the app, so hearing him speak of using it to store new access codes felt like a mini achievement for me.

I also ventured into the world of TypeScript around this time, using my time refactoring code and fixing bugs to help me learn. Looking back to the earlier stages of development, I can see how a lot of problems could've been avoided with a typed language. I'm now fully committed to writing any future code in TypeScript, and I'm enjoying every second of it!