how we built
cinder iiot software
Next Gen measurment
Chief Software Architect, Murray Leach, breaks down the considerations taken when building Cinder IIoT Software.
Recently we launched Cinder, our industrial software interface which elevates the user experience making it even easier to optimize and modernize your process. As we detailed in our Path to IIoT article, there are a number of paths a company can take when looking to add software to their portfolio. In this article, I will dive into some of the considerations and the decision making process for how we built Cinder.
For context, Cinder is a replacement to our previous software version. Cinder was an entirely new build, meaning we started from the ground up. There were clear technical objectives to be achieved when building Cinder, for the sake of this discussion I will ignore the user experience (UX) goals. For more details on our UX considerations, Justin Kirkwood wrote a great article about our Human Centered Design Process.
Previous Interface & Framework
The UI that existed previously is C++ based. It is created using a framework called QT. This has proven useful for our developers to give easy access to the configuration of the Red Meter. The original decision to use QT was based on the following:
- Already in use in many industrial devices
- Familiar interface templates
However, QT is very limited in terms of changing aesthetic properties such as buttons, tables, menus, etc. While it might be possible to achieve an acceptable look, the lack of flexibility brought about constant compromises. One particular example was on available visualization elements such as graphs.
Another major obstacle was the inaccessibility of QT. Making seemingly minor changes to the interface was laborious and could only be conducted by a single developer in the team. In contrast every team member was fluent with the use of various web technologies, for which there are rich examples and in-depth documentation proliferating the internet.
QT is great if you have a limited set of functions and don’t want to change them often. However, this is specifically the opposite of our situation. At project inception we had a list of requirements, but customer demand expanded that list of requirements beyond the capabilities of QT as we moved forward.
When establishing the roadmap for Cinder, an expanding list of requirements meant that flexibility and modular components would be a priority in determining which technologies would comprise the new interface. As our engineering department’s product roadmap is very aggressive with future products scheduled to launch this and next year, it was imperative that the development team create software which can support current and future products. These considerations led us to web based technologies which allow us to bring in any component or technology in use today or that becomes available.
When building a user interface, being able to iterate fast is key. This makes it possible to have user feedback tightly integrated into the process. Using a set of tools that allows for these iterations and simultaneously allows the developer to make quick changes is therefore a good step in the direction of building a well functioning user interface.
We have a collection of future goals that are known and we are very aware that we intend to remain on the cutting edge, delivering new features as demanded by customers or invented as opportunities to innovate and integrate occur.
Previous Software Performance
One of the limitations of our previous software is that it was pushing the boundaries of available hardware resources. QT was very CPU intensive and memory hungry and there was little we could do to mitigate this. The question about available headroom made its way into every discussion about changing or adding any new features. Visualizations were chosen on the basis of what could be supported without risking the dreaded spinner [waiting for data] rather than those most intuitive to the user. This is a suboptimal approach to design and it was obvious this would end any serious discussion about adding a feature that may impair smooth running of the basic features.
Cinder Software Performance
One of the great benefits of web technologies is that they were built to run on lightweight hardware. Often the target device is a stripped down web browser on a sub $200 phone with little power. Predominant engines that form the core of browsers are built by well resourced and highly proficient engineers at Google, Apple, IBM,and Intel to name a few. Needless to say, the necessity of these systems in the eyes of the creators is such that no stone is left unturned in the pursuit of best possible performance. In turn, any software built to run in a browser is afforded the same first class experience. This creates the foundation for great experiences for users that have minimal impact on device performance. For our use case, this meant we would have plenty of headroom to perform complex mathematical calculations in the background upon which Red Meters systems rely. In addition, our code would work on every Red Meter system in the field no matter the generation of computer hardware it was built on.
The design language for this project was designated before we began, in large part due to the frustration our team faced trying to implement any of the intended visualizations in our first user interface using the QT framework. It was clear we needed something more robust and flexible. We did not wish to reinvent the wheel so the prospect of a lengthy design process, and corresponding user research to deliver components that in most part have been made by others before seemed redundant. Taking all of this into consideration, we chose to use Material Design.
Material is a system of guidelines and components that help create a particular user interface style that is familiar to most people. It relies on principles and best practices that have been highly researched and deployed for over a decade. Part of the benefit of following this methodology is to free developers from subjective decision making about aesthetics and to ensure there is consistency about the design and function. Material is an open source product and the creators maintain fantastic and detailed instructions and examples to make it easy to comply.
Material is a philosophy that does not prescribe which technology must be used to implement it, we considered the 3 major JS frameworks [React / Angular / Vue] to start coding on and eventually decided upon Vue.
Some of the advantages of Vue over React and Angular:
- Load times, the Vue package is smaller and initial load times are consequently faster
- Easier to work with constantly changing data – the core purpose of our product is to display live data
- Dev tools, we found much richer development tools available for Vue that would lead to easier debugging and better collaboration among the team
- Templating system allowed us to build with better consistency
- Maintenance is expected to be simpler using Vue than the other popular frameworks
Building Cinder was a fantastic opportunity to take what we learned from going blind into the creation of the interface it replaced. It’s rare to get the chance to start over and the team embraced that, I am certain the polish that was delivered on launch could not have been achieved by making changes to the existing. There was some significant technical risk in the technology choices being applied to mission critical industrial systems but we were fortunate to find detailed examples on what pitfalls to anticipate and how to overcome them. The choice to use web technologies has opened the door to very easily maintainable code that ensures conversations with end users about any future requirements will be welcome, any expansion will be painless.
Material has been a resounding success for us by taking away the choice fatigue that developers often feel, design is outside the comfort zone for many and leaving all possibilities open can feel rather daunting. Making the design elements easy to digest and objectively assessable leaves the mental load of development clearly focuses on writing efficient and error free code.
Vue in particular lends itself very well to pulling members of the design team into our development cycle for short and periodic bursts as needed without being a significant disruption to their existing workloads related to other parts of the business.
We are looking forward to addressing whatever new challenges are thrown at the next release but for now we will be building out the next exciting Red Meters software product, watch this space!