We're keeping the scope small, right?

Building an Android app for Trimble Navigation

Android Native | Google Play




Quite out of the blue, we were approached about doing an app for a phone. Given my experience with native Android, I suggested I would be able to deliver the project. The app was ideally to consume the same XML as another website, and another device, and provide the configuration for a given box. Saving time and brain capacity for the people working in warehousing.

This was the first time that the Marketing Communications department had been tasked with creating an actual android application, rather than a once and done marketing website, or externally contracting to external event agencies. 

With the aid of the design lead from the department, I engaged with various stakeholders to identify the key workflow, who this was for, and how they would use it. The intent of the app was to save the workers in the warehouse time for going and checking the state of a configured package.

With the UI design, I knew I wanted to make it as seamless as possible. I cut away any unneeded interaction, deciding to launch the main workflow immediately as the app started. This reduced cognitive overhead, and saved time on each use. After a small amount of time, some instructional text would appear in case someone was confused with what to do.

unnamed (1).png

An exercise in responsive iconography; letting go of control

I was stoked when I reached this concept, the shading helps indicate scanning, rather than a passive barcode process.

The White/Yellow circle (Filtered for visibility) was a stark contrast to many other apps, and easily stood out on a variety of backgrounds. And fit in with the branding at the time. 

There were screens in the app. The "Scan" screen and the "Results" screen.

The scan screen needed to be fast, be flexible, and be intuitive. I did the following to achieve this;

  • The app was quite laggy when a user was typing in a barcode manually, so I used a neat trick of stopping the camera when the keyboard is visible, then blurring it to ensure the user focuses on the text entry task. 
  • Used threads to blur the background, and retrieve the document, so to not block the user interface. And allow users to start again if they notice a mistake. 
  • Used non-blocking alerts and notifications to update the user on the state of the app. This "Snackbar" approach is now in the material design specifications! 

The Results screen was quite simple. Showing a list of values. We went through a few design iterations for how this should look, with care taken to present the RX/TX icons in an understandable way. I was aided by the support from the hardware team and management for getting some pretty diverse codes to test on.

Post Mortem

It's been a few years since this project, and aside from having to point them to where they had it on their version control, I've not had any panicked calls! Someone updated it in 2016, and it is still on the app store today.

I'm really happy with how the project went overall, the discovery and UI flourishes still stand up today, and I wouldn't do too much differently. Aside from templating the display on the second screen in HTML rather than the native layout. I was a little naive on the time required, but approached development in an agile way, so the business was aware of the time needed and spent ongoing. 

Stuart Kent