A customer from an investment company approached us with an idea of creating a GPS tracking application based on two popular systems:
Both systems lack intuitive and logically structured frontend, which is why our client asked us to create a better version of them and add those features that will be game-changing for its users – the owners of the Logistic and Transportation companies, fleet managers, drivers, and other clients whose aim is to track moving objects.
The client wanted to take the frontend from Wialon as a reference, upgrade it and make the application operate on the backend from Traccar. They liked the server given by Traccar and wanted Traccar customization. Besides that, more than 140 companies in the world use Traccar, so it was a decision not meant for discussion.
Both systems are past their prime as they have been on the market for more than 14 years. Many of the improvements were made as customization added to the existing systems above the existing architecture and logic. Thus, some of the features were illogical or disconnected turning user experience into a long and tiresome journey each time. For example, the reporting feature was scattered across the entire app while it could be a lot easier to gather all the tasks relevant to reporting in one place. Also, the new interface should have a modern UI & UX, but the former customers should feel like they are working with the familiar interface with the same functionality of the controls.
After analyzing the best solutions on the market, we saw opportunities for improving frontend and user experience for the future application. Therefore, it was decided to create a new frontend based on Wialon and adapt it to the Traccar backend. By developing a brand new User Interface, we could put together the best practices initially and lay down a logically improved architecture without having the need to rebuild existing systems from the ground up.
To grasp the full idea of our client and reach the outcome they expected, we worked in a close collaboration, constantly communicating and exchanging our opinions. The thorough analysis of the possibilities for frontend implementation and the Traccar backend customization helped our team to get the full picture and know what we would be working with.
To know how to successfully implement all the changes we planned on frontend and adapt them to backend, our developers and business analysts investigated the existing Traccar backend. During the development process, we had to adapt some of the Traccar features to what we wanted to implement. Thus, for example, we had to match available fields from Traccar with the Wialon fields. In some cases, missing fields were created as additional custom fields.
Working with the Traccar backend gave us valuable experience, because there were also situations when we had to request the Traccar team to make some changes on the backend:
We clearly needed an application for tracking commercial trucks and analyzing information gathered from data devices about the health, speed, and positioning of the vehicle units, the level of technical liquids, etc. One of the key challenges that we were dealing with was the fact that the Wialon application is very rich in functionality but has a very old designed and illogical frontend. As for Traccar, its frontend is built using React.js. The functionality of the future application was expected to be constantly updated and expanded, so the client was thinking about using Webix. However, together with our client, we decided to use React JS on frontend instead of rebuilding it with Webix. Thus, it would be more beneficial for both us and the client.
To improve the user interface, make it more intuitive, and add more clarity about users’ roles and available features, we implemented two modules.
This is basically the side of an app that is accessible for all users depending on their roles. After logging into the user’s application, all access rights come from the server to the frontend. Depending on these access rights and user role, only the content and functionality available for a particular user is displayed during the session.
The system for users with limited access now includes 3 tabs:
Admin and Super Admin Module
As for the administrator side of the application, it also includes more logically structured functionality now. Our customer wanted to create an administrative module within their application that would be visible to users with certain rights without the need to launch a separate application. Also, after transferring all reporting features to the Monitoring Module, it gave us more space to improve other features. As a result, the Administration side of the app got the following tabs:
Some React pattern complex components were implemented on frontend to be used across the application. Mostly in the Administrative module, we added tree-tables for grouped objects and drivers. All of the data tables and tree-tables were supplemented with the following pattern functionality:
Traссar provided a functionality to transform raw data received from sensors. But we needed to provide users with a converter that has a familiar user interface for creating conversion rules. We also developed a parsing panel to let users preview row data in HTML or in data table view and parse them into the columns of the corresponding Report data table.
During the initial stage of the project, all components and their features were pre-designed in an integral style and added into a Storybook to be used across the application. Each new component was implemented the same way.
To improve user experience and decrease the amount of struggles, we added Dynamic tables into the Reporting feature. For managing dynamic data tables for Report templates, we created a Data table wizard popup. With its help, users with manager rights are now able to create, save, and update data tables. A user is now simply able to select data from various sources, group and sort data, and specify is a diagram will be available for the chosen data table.
We have arranged the modules in a more logical and intuitive hierarchy. Messages and tracks, which are also reports with a hard-coded template, were located separately in the menu. After analyzing the system design, we created the same two templates for ourselves, but included them in the list of templates, marked as “standard report”, which cannot be edited. This helped users to work with the reports they are used to or copy them to create new templates.
The executed Reports are now displayed on the Dynamic report page that contains three blocks interacting with each other: Map, Diagram, and the scope of data tables, displayed on the dynamic horizontal tabs. User actions on one of the blocks are reflected on the others.
The new application not only repeated the functionality familiar to Wialon, but also enriched it with new ones. To make the functionality consistent, we added the ability to make format conversion templates that could be saved and set up as visible for other users to reduce work time consumption.
Multi-language approach was also implemented on the new application architecture, so all text blocks on the frontend weren’t hardcoded but taken from the file with the English version. It will allow the customer to add files to the system with any other languages they need.
Both our and customer’s teams were stunned by the outcome, because the application was successfully reworked and reanimated. The end result showed that the system can be optimized and customized to the client’s needs to bring a better and more logical user approach. The data is now clearly visualized granting users more understanding of the assigned tasks and letting them spend less time and struggles on deciphering all intricate and old-fashioned features that an application previously had.