TDS Scanning App

React Native App for scanning passengers into bus.


Views


One of my first projects at TDS was coming up with a proper design for one of their flagship products; which was called The Driver App. The app was used by bus drivers (and boat taxi drivers as well) for scanning passengers into their vehicles. Naturally, this new app would need to support all features of the previous app as well as add some new ones.

A Few Requirements

Easy Authentication

Drivers needed an easy way to log in and scan people rapidly and without having to remember a password.

Non-Stop Scanning

Scanning passengers should be continuous unless something desperately requires the driver's attention.

Offline Mode

The app needed to be able to work without having reliable access to the network.

Authentication and Offline Mode

The first problem I set out to solve was authentication. The solution to having easy authentication was clear from the get-go. We needed to implement a secure and reliable QR code authentication. However, this requirement was indirectly related to the offline mode requirement.

After we concluded that it would be too cumbersome to switch between offline and online mode during scanning, the accepted solution was to split the user's path before they log in. Since the driver will most likely lose their connection in-between stops, rather than while scanning inside a stop. We noticed we could check for internet connection when the app first mounted and then either require the user to go into offline mode or continue scanning online.

Non-Stop Scanning

The requirement for non-stop scanning was solved by using in-app bottom sheets. This way we could use the bottom sheets for all sorts of feedback throughout the app, and we could also have more control over it, as opposed to a native alert, which for both iOS and Android cannot be programmatically ignored.

We identified two kinds of bottom sheets we needed: Feedback and Confirmation.

Feedback Bottom Sheets

These would be simple informational alerts. Depending on the alert, the bottom sheets could be blocking or not. Meaning they would make the user take some action, or not.

Confirmation Bottom Sheet

This would be how we would make the user confirm before proceeding with destructive or definitive actions.

Conclusion

I'm hoping I can share more details about this project soon after it's fully released. These were just a few requirements that had to be solved before the app was developed but I would love to go deeper into how the app came to fruition and some of the more specific decisions made during the design and development phases of this application.


Last played:

J. Cole


View Page in Github