In my previous blog, I talked about the rise of cross-platform frameworks and their benefits. Building on our learnings, we decided to create a Dealer App as a POC (Proof of Concept).
The main purpose of this app is to sign up and service customers of a specific dealer and handle installations. The service aspect may include taking customer payments and posting to their accounts.
Dealers use various platforms: if there is a store, the app may be run on a desktop or a tablet. Smaller dealers and installers that may not have an outlet could use a tablet or a smartphone. And in developing markets particularly, the phone is prevalent.
Dealer Web
We started by creating a dealer web application using Angular. Although Flutter has state-of-the-art capability for cross-platform mobile development, the web capability has not yet matured to the point where it rivals Angular or React. When the web is the only target and there is no mobile requirement, Angular or React will be better choices.
In our case, the advantages of Angular went beyond the technology, as it allowed reuse of many components already used for a (web-based) call-center application. This made for a cost-effective and fast way to create the dealer web application. The use of existing components also made our extension model available for the dealer web without any additional effort.
Dealer App
Although the creation of a web application had many advantages, it had one major drawback: it is not optimised for the phone. The use of responsive and material design allowed the application to run in the browser, but we could not take advantage of the phone’s capabilities and inherent usability as a native app would. For example, we could not use the GPS or camera features.
We created a new app using Flutter/Dart. Leveraging many of our existing UX patterns, development frameworks and components (like GraphQL) helped reduce development time. The Flutter framework provided us a single code base for all platforms, like iOS, Android and web.
Although the application has a single code base, we gave special consideration to layout and widget types based on the platform and device size:
- Data tables instead of list views: Although list views are preferable on mobile devices, the use of list views on the web leads to large amounts of unused white space. Data tables are preferable on larger devices.
- Context menus instead of swiping: Swiping on a row in a list view is a common mobile pattern for accessing actions applicable to an item. A context menu or inline actions instead of swipe should be used when running in the web.
- The components of dashboards presented on the web may include additional information to maximise the use of available screen real estate. For example, the customer details widget may include more verbose information about the customer when running on the web.
- Functional differences between device type: For example, bulk file operations are limited to browser use, while barcode scanning requires a camera and is therefore limited to phone/tablet.
- The application is responsive and provides alternative layouts, based on device size and screen orientation.
Our mobile app uses several native phone capabilities. We implemented a bar-code scanner to register set top box serial numbers; used the GPS functionality and address lookup to automatically fill in the customer address; and used the camera to support in-app photos of documents and completed installations. All those features speed up the order-capture process and prevent manual entry errors.
App versus Web
The Dealer app is a lot more versatile than the Web version, and provides many benefits:
- Runs on all platforms (Apple iOS, Android, Web)
- Native mobile app
- Uses phone features like GPS and camera
- Cheaper to maintain – Only one code base; one team can maintain all platforms
- Quicker to roll out features on all platforms
There are a few one-time cons that can be resolved over time:
- No reuse of existing web UI components, so initial development will be a longer
- Web UI extensions built for the call center cannot be reused on the app and require recoding
Conclusion
The use of Flutter and similar frameworks allows for a single code base across various platforms. This makes it feasible to build an app and website with maintenance cost that are like a web-only approach.
Although Flutter’s web capabilities are not yet on par with the likes of Angular, we foresee a steady progression of the framework with increasing support for web. Given that many users prefer native mobile applications and the added capabilities of the phone, it makes sense to build dealer portal applications in Flutter instead of web-only.
In order to benefit even further from Flutter’s productivity benefits, one can think of a re-usable Hansen App Development SDK (similar in concept to the ICX Expansion Pack) created using Flutter and Dart’s powerful package management and modular abstraction capabilities. This was outside the scope of the POC, but we can imagine that it covers some generic elements:
- Widget Library: Common UI elements such as data tables, dynamic forms, data entry controls, charts and other visualisations that are tailored for Hansen’s typical usages and industries.
- Application Framework: An application framework shell and supporting libraries to standardise application structure, state management, error handling, security and communication with backend systems.
- Project and Widget templates: CLI tools to create new application projects and widgets easily.
- Documentation: References, guides and training material to help application developers be productive with the SDK.
The POC proved to us that the Flutter/Omni-platform solution is the route to go.
Coen van Baar
Senior Product Director,
Hansen CCB – ICX