Imagine you are an established software company that has been successfully servicing public and municipal utilities for over 20 years. Throughout this time, you have been working together with your customers to design a suite of products and services to better help them improve operational efficiency, integrate with various services, and run a better business.
Now, companies are expecting to access the same features they have used for 20 years through new smart devices like laptops, tablets and smartphones. So how do you take a proven platform and open it up securely so that it can be used across multiple platforms and devices?
Making a better Mobile Work Order Management Platform
When we first met with Cayenta, they described a vision of upgrading most of their add-on services to provide a better user experience across multiple platforms.
To begin with, they described to us their work order and service order management services. The platform allows for utility companies to receive new work requests, dispatch them and complete them. During our first meeting, they showed us their current platform as well as their latest attempt in creating a mobile friendly version for their customer’s field workers. They had gone through a couple of iterations of this mobile software, but they weren’t very happy with it.
After a few meetings, Cayenta decided to bring us in to help them out carry out their vision. They had a very aggressive timeline, so we began work right away.
Although we had plenty of experience dealing with the process of work orders across multiple industries, we had never worked with a Utility company before. With Cayenta, we needed to understand their customers entire workflow to a high degree of detail. Before even starting to do any work, we set out to capture all the day-to-day activities required by Cayenta’s clients.
Initially, we gathered high level details from the small team within Cayenta in charge of liaising with us to ensure the project is kept on track. As we learned more about the workflow, we dove into details through demos of their current implementations. This allowed us to explore ideas and determine how they worked. Once we had a good general grasp of the workflow, we started getting more details and insights from their executive team and implementation consultants. They were able to help us better understand how things were being done, why they were being done this way and what is ultimate reason they were being done. Obtaining all this information allowed us to create user stories (requirements) and helps us better put ourselves into Cayenta’s customers shoes.
Now, equipped with this knowledge we started creating the initial framework. Looking back at Cayenta’s old attempts, we had realized they were putting too much information on the screen. Our main goal to start with, was to keep the system as simple as possible. Make it dead simple for anyone to use and accomplish a task quickly.
Our approach was to create rough sketches and prototypes to flush out all the details of the workflow and uncover any missing information and flaws in our understanding of the workflow. We quickly started with sketches and moved into interactive prototypes. We used our meetings with Cayenta executives and consultants to deeply examine each screen and workflow to determine we were all on the same page.
When we originally discussed our approach to Cayenta, we discussed transitioning the solution over to their engineering team once completed. Our goal throughout the design stages was to create a library of objects/patterns on how to solve certain problems and workflows. The point was to have consistency across all the screens and make it easy for their team to determine which object to use in certain circumstances.
Therefore, as we designed our prototypes, we created a reference on how certain workflows should be handled depending on screen size, device and problem.
To make everything work, we had to make use of their API. Their API turned out to be much larger and complicated than expected and we quickly realized that to make our new system work it was going to be a lot more work than we originally intended. Because of the way their API was built, we encountered a lot of limitations. Furthermore, just navigating their documentation and testing their end points was cumbersome.
In order to easily accessed and test their API points, we decided to create a simple API explorer. This system although took a few days to build allowed us to quickly find the APIs needed and test them. This new nifty system allowed us to regain our composure and get our minds around how their API worked.
Also, as we realized their API was not going to provide us we everything we needed, we starting working on a solution. We designed a middleware server to connect to their API, serve our apps, manage extra features and cache data for performance.
While we were putting the finishing touches on our server, we began using our prototype to create the new system. We decided to use AngularJS for its modularity. Going forward, modularity will be essential to help Cayenta maintain the project. The goal of the project was to make the system work across multiple platforms. To do that, we made use of the Ionic Framework. It gave us the tools we needed to create flexible, mobile first interfaces.
To make the apps use native components and have the app be a native one, we wrapped our codebase in Apache’s Cordova. The beauty of creating a hybrid app was that we can now support only one codebase and push updates without having to submit a new version of the app. Both web and mobile users would get notify within the app that a new version of the app was available. A simple refresh would load the new version. Super easy!
One of the toughest paradigms we had to deal with was the offline workflow. Initially, we had agreed to offer only a partial offline feature where users could only get limited access to information and editing was limited. As we developed the app and customers started getting excited about this new project, concerns were raised about the lack of offline functionality.
Both Cayenta and us agreed we didn’t want to have a fully featured offline app. The main issues with offline mode was how to handle the large amounts of dynamic data and validation that are served by the Cayenta application. So we came up with a compromise on how to deliver the required functionality within the app. As users interact with the app, they will be notified when they go offline and have the option to enter offline edit mode. Once back online, they can sync their entered information and the system can then validate properly. Furthermore, we cache important information so the app is still usable.
Once we were ready to ship, we needed to figure out how to have a simple deployment process. One of our requirements was to deploy our client server within the client’s premise. This meant having to install our client server application in unknown environments. Enter a tool called docker: an open platform for distributed applications. The beauty of docker is that it allowed us to separate our application from the server it resides on. We used this tool to package all required dependencies and virtualization so that all our deployments were running on the same server configuration. This greatly helped reduce the number of issues when installing or upgrading our client server application.
As I write this, there is a great excitement from Cayenta and its clients to start fully utilizing the new application. This new application be a competitive advantage and a core offering going forward for Cayenta. This new version of these apps will increase offerings and expand service offerings across multiple platforms.