GeoPal’s Mobile Workforce Management App – part 2

What kind of challenges have we faced when building our Mobile Workforce Management app? In part 2 of our GeoPal Mobile App series, we will speak specifically about the obstacles we’ve encountered during our development process, as well as the technological choices we made to overcome those. In case you’ve missed part 1 of the series, find it here

Mobile Workforce Software evolution: becoming modular

As GeoPal has grown, so has our average client: we have been slowly transitioning from servicing exclusively medium-sized businesses, to large businesses, or even multinational companies. At the same time, we want to keep the same standard of customer service that we had when we first started, which meant we had to up our game and come face to face with new technological requirements.

A key business reality that really influenced our technological choices is that in Mobile Workforce Management, there is no such thing as a ‘single solution that fits all’. Every one of our clients has different needs and comes to us with a different business process.

After careful observation, we were forced to recognize the need to build custom solutions and embed them in our Android App. We went through a stage when we tried adding as many categories of Job Steps as we could possibly conceive, in order to fit every possible kind of Job workflows. Eventually, we relented and introduced Scriptable Steps and Webviews to enable the ultimate customisation of a Job Workflow. Nevertheless, we found the demand for customisation to be such that the requests ultimately started falling outside the boundaries of individual jobs.

We realised there was a need to improve our customisation capabilities once again, namely, the chance of customising the homepage and to replicate all of our app’s functionalities through custom scripting. GeoPal’s Mobile Workforce Management App was built as swappable modules, with each of them implementing a small set of functionalities. Each module can be removed or added to the app as necessary, with the option of associating them to an icon on the Homepage and the Navigation Drawer. 

Customer’s choice: White-labelling App

Customisation was not the only requirement we were getting more and more frequently from our clients: white-labelling also became a frequent topic of conversation, particularly with large companies. Large clients wanted to have the option of showcasing their company’s logo, colours and layout for branding purposes. When talking about white-label, there was an order of priorities that we went through:

  • The ability to showcase our customer’s logo on the login page
  • The ability to showcase the logo as a background on the homepage
  • The ability to customise the main colour of the app
  • The ability to release a different branch of the App, with a different icon and label

The first requirement depends on the user logged in and is available only after the first login; the second requirement was implemented as a feature on the Homepage module. Finally, whenever needed, there is still the possibility of deploying a different branch of the App, with customised logos. Thanks to the modular architecture of the app, these branches will be updated, just like the main branch if the customer so wishes, without the need for additional maintenance. 

The tech behind the GeoPal Mobile App

Bearing in mind the customisation and white-labelling requirements, we chose to build the app on Apache Cordova, using ExtJS to implement the user interface. The goal here was to create a separation between the code and the underlying Cordova container, deploying different branches of the application without the need to duplicate code in the process.

As an added bonus, our modules are run by default in isolated IFRAME panels, allowing developers to use any javascript-based technology they feel comfortable with, whether it’s Angular or jQuery.

Can you get your own DIY GeoPal Mobile App?

The answer is yes, absolutely. While we were developing the app, we made a deliberate choice to use exactly the same tools that an external developer would use to implement his own customisations. The idea was that if the developer tools we work with are not good enough for us, they certainly wouldn’t be appropriate for third parties. Forcing us to use the same tools has pushed us to improve them enough to make them convenient, rather than just viable.

The result of this approach is what we called “Mobile Platform SDK”: a minimalistic toolkit comprising a small web-server running in Python, a development version of the Android APK deployed on the Play Store, extensive documentation and some examples of features.

The web-server is used to deploy a customer’s own modules on the development APK installed on their phone; the documentation will help developers learn and understand what tools and primitives are available and how to use them and the examples will help developers hit the ground running with the most requested features.

Conclusion

All the choices made when we were building the GeoPal’s Mobile Workforce Management App were driven by new needs and requirements from our own customers. It was that continuous feedback that inspired us to change our perspective and conceptualize the new app as a set of building blocks, on which UI features were built, neatly separated and fully interchangeable.

As a final product, we have an App with all of the most frequently used UI features, implemented as interchangeable blocks, built around a flexible core and made with tools designed to ease the development process as much as possible.

Curious to see what GeoPal’s Mobile Workforce Management App is capable of? Get in touch to get a sneak preview

Share This

Make the Connection!

We work with your company to implement workforce mobility solutions that transform the efficiency of your field operations. Get in touch to start developing your own solution today.