On the road to the state of the art, part 5 — the UI Framework

disclaimer: This was written in 2021, along with the rest of this series, but was published only in 2026 because it was waiting for validation from my employer. I have since changed jobs and am publishing these to finish this story. My opinions and methods have changed since then, but I am publishing these as they were redacted.

One of the targets for the project was a ticket validator, which runs on Linux (a custom Yocto build by the manufacturer).

The UI is very limited on this device, mostly because there is a small screen and no user interaction except for a maintenance use-case. But also because this is an embedded device that runs on a low-powered ARM chip. It’s still dual-core and has 1GB of RAM, so not exactly embedded software, but nowhere near a Desktop.

I was taken aback when I learned they decided to use HTML for the UI.

Not because I think HTML is not a good UI base (I do, but this in another story). Nor because it was a technology none of the developpers knew. Not because they used plain HTML and vanilla JS. Not because of the optimisation concerns one could have for this use case of Web technologies (running a whole chromium instance), and the effects it could have on critical operations, such as performing a validation.

But because the application is written in Qt. Which offer two other ways to write UIs, the time-tested and no longer evolving QWidgets, and my favorite UI framework, QML.

And while it is my favorite UI framework, it was also designed for the exact scenario we were developping for : embedded(ish) software. It uses a low-level rendering engine that is pretty well optimized, and offers easy to understand and learn syntax, since it’s a little more than JSON. (did I say I might be a little biased?)

Some team members had had a previous experience with QML which was, let’s say, imperfect. They told me QML had performance issues, and were very skittish on the details. I finally understood it came from an animation that was running slowly. As I investigated the animation in question, which was a GIF whose resolution was about double that of the screen it was shown on. See, here Qt downscaled the GIF on every frame. Remember how I described the hardware as ‘low-powered’ ? The current developper of that project had found out earlier about the size of the GIF, compressed it and the UI was a smooth afterwards. This reduced my trust in their ability to correctly diagnose issues, and made me more confident they did not understand QML correctly, and mistakenly attributed more issues to QML, that stemmed from elsewhere.

After discussing with the team, and sharing with them my feeling we should move to QML, there was no enthusiasm to follow that lead. I discussed the subject with another architect, who technically has the responsibility for all high-level decisions, but gave me free reign over the devices since it’s not his domain of predilection, and he could use the time to focus on bringing the back office to the state of the art. He told me that if I really felt this would make us move faster in the long run, I should go for it.

So I shared my decision with the team that we would move to QML as soon as would be feasible. This was met not only with a lack of enthusiasm, but with some active resistance. Some team members had a talk with the Scrum Master, who organised a meeting a few months in the future, after an important delivery we had to make, to talk about the UI framework. Because some team members felt they were not consulted on this decision.

Of course they were right to be annoyed, since I was completely ignoring their opinion, and none of these developpers were juniors.

But the following week, another straw went on the Camel’s back. We had all agreed that the current scope would be developped in HTML, as we were a bit pressed for time. A team member who was tasked with implementing a couple of (very simple) screens said he was starting on that today, and asked to the assembly if he should rework them as they were imported from the project we were pulled from, and did not follow the same guidelines as the current project. I intervened, saying we should not waste time on this, as we would throw them away as soon as we made the switch to QML.

The next morning, that same team member said he was refactoring the two screens to the guidelines of the project with the help of another developer.

This made me angry. It was going straight against my recommendations, and I was the one who was in charge of these kind of decisions. I may not have communicated this clearly enough before, but this time I decided to make it clear.

After the daily meeting, I went to work implementing these screens in QML, and integrating them into the app. A couple of hours later, once I had a good enough implementation to show, I set a meeting for the afternoon, to present my work to the team.

I started by showing that I had made these screens in less time it would have taken to even import the existing ones by the current developper’s estimation, and re-iterated on why QML was a better choice for our needs.

And then I explained that when I say “we should go this way”, we should. Because it is my responsibility to make these choices. I don’t want to be the guy that swings his dick around saying “I’m the boss”, but this was one time I felt I had to do it, to avoid more waste of time.

We ended up testing the screens on the final hardware live, which failed, because since I did not have the actual hardware, I had an issue on my machine that prevented the build from fully working. This gave some of the opponents of QML some more wind, but I asked another developer to build it on his machine, and that build worked correctly.

A bit after this meeting, one of the developers told me something along the lines of “I don’t feel it, but I’m gonna trust you on this one”. This moment was pure relief for me, as he was one of the hardest to convince, and saying he trusted me on this one really meant a lot.

The following weeks blended together as we rushed to deliver on time. I was more a fellow programmer than an architect for those weeks, fixing bugs and implementing features to get this project out in time. There was a lot riding on this project’s timely delivery. Not only the validation of my technical decisions, but some political decisions in the company as well, most notably to move to a more agile organisation of a team led by a Product Owner, and without interference of the project managers.