Exide Mobile App
Car Battery Measurements
Number of countries where the app works
Lines of code: frontend & backend
Number of calls with the client
Number of months worked
- COUNTRY USA
- INDUSTRY Automotive
- PEOPLE INVOLVED 4
The client came with an initial idea for the application.
In the provided materials we had drawn preliminary assumptions, several possible scenarios, “flow” for the user from the moment of registration to sending the last message with acceptance of battery replacement. The client indicated that this is some kind of proposal and is open to suggestions and changes.
What is important from the beginning was clearly stated that it is to be a PWA application, completely new, the only PWA application of this kind.
To put it another way – the client had a clear idea of what his goal was: to encourage the client to replace the battery in as few clicks as possible. We spent some time discussing what would be the most effective and considered various options.
When it comes to technical challenges, virtually all the data needed for the application to run is taken from an external API. This causes several challenges like documentation style that doesn’t match what the API returns, incomplete answers from API, need to use endpoints in an undocumented way.
How it works
The application works with the new EBTP battery tester and is designed to help mechanics select batteries and send a battery test report to the customer who can decide whether or not to replace the battery. The report includes test details, battery proposals, and driving style (number and length of journeys per day) of the car owner.
Once the driving style is measured, it determines when the battery test should be repeated. The customer receives an SMS/EMAIL notification after an appropriate time that it is time to test the battery again.
The main idea of the application is to help the mechanics to select the batteries for their customer’s vehicle. The application works best if we have access to EBTP Tester but it can be used without it. The user has the possibility to test the battery. By completing the client’s data he goes to the stages where he can scan the result of the battery test if he has the EBTP of the tester or enters manually when the accumulator was tested with another tool. In the next step, we have the possibility to take a picture to read the license plate instead of entering it manually. Based on them, in some countries, we can get information on exactly what car model it is in order to select the right battery. The TecDoc API helps us to select a battery, just as we do with license plate information downloading, by providing the appropriate batteries for the vehicle. The mechanic can select up to 3 batteries from the TecDoc API proposal or browse the catalog if you need to select it manually. A detailed report is then sent to the vehicle owner with information on driving style, battery status, and new battery proposals with prices. The vehicle owner selects the battery and accepts or rejects the proposal.
Design & UX
In the beginning, there was only a client’s idea; he pushed his company to invest in this application and create it. Then he came to the workshop in our office and brought with him some professional tools for testing car batteries.
The application was tested and designed by us for use on mobile phones and had to be simple and quick to use. We had several usability tests with mechanics from different European countries, this helped us to have a global idea of how workers could interact with our app. When it comes to design elements that make UX better for the user, we prefer to design as simple, minimal, and transparent as possible. The important thing was to show only basic needs and no dirty or overloaded screens.
So when it comes to the advantages registration screen is clear and well readable, presented information and available options are well understood. The process of scanning the QR code and registration number doesn’t cause any problems. Also, it is elementary for users to understand what happens after sending a query to the client and what should be his next steps (waiting for the client’s response). Furthermore, we designed a useful feature – proposition of battery for the clients to find one which would fit the car’s requirements. It was also important for us that the client could easily log in and out of the application.
In the application, we must have QR recognition of codes and registration numbers based on photos, which means that we must have access to the components of the end device, in this particular case – the camera. The PWA application does not provide “native” access, we were limited by the fact that the whole thing works in a web browser.
Originally the photos were supposed to be taken inside the application (without opening a separate camera application), but unfortunately here, due to the limitations of the browser (canvas element) the quality of the photo was very low and this caused difficulties with QR reading of codes and tables.
Because in PWA application we can’t actually run any additional processes on the device.
QR code recognition was originally done on the backend side (in the final version it was done on the device side). License plate recognition is still carried out on the backend.
Laravel was used to create an API for a frontal application. The choice was made for this framework, because of very good support from developers and ease of work with this framework. The application is available as a PWA. It’s easy to work with. It also offers very good performance and PWA implementation using this framework is very simple. When it comes to the advantages for business: it’s quick and cheap. ZXing QR Code scanner was used as Libraries for reading QR codes from the EBTP tester. A detailed list of battery test parameters is provided to the application in the form of a QR code. This speeds up the transition through the application and minimizes the risk of an error being put to zero. Openalpr is a Python library for vehicle license plate scanning. Its purpose is to speed up the process of entering data on the application. Twilio was a service enabling sending SMS. Through Twilio the application sends information about the status of the battery test to customers. The customer receives a link where he can decide which battery (from those proposed by the mechanic) he wants to replace the current one if it turns out to be faulty. The same notifications are also sent by e-mail as standard.