Embedded Linux UI Technology Decision Matrix

I’ve not use decision matrices a lot, but out of curiosity I put one together for evaluating UI technologies for Embedded Linux systems.

Spreadsheet file (39.5 KB)

Note, the above is provided as an example only – very little thought is put into the numbers, so please don’t make any decisions based on the above image – delete all the input numbers and enter your own.

I have a bias toward HTML5 UIs, but was still surprised when it came out on top. I did not change any of the numbers to get the result I wanted. Everyone has different priorities and will rate things differently, so you may get different results. However, often times the best technology is one that provides the best overall benefits, but it may not be the best at any one thing. Go is a good example of this – it is not the fastest, safest, purest, etc, but does pretty well in most categories, so the aggregate tips the scale for many applications. It’s also interesting that once you consider HTML5 for the UI, this opens up Go as a good language for the core logic. Go does not have any mainstream native UI solutions – there is probably a reason for this – it’s simply not needed in many cases. HTML5 is good solution for native and remote UIs and its hard for any native UI solution to compete with the web platform.

I’m not sure how useful the absolute numbers at the end of a decision matrix are, but I think it is a useful exercise in that it forces us think through all the different aspects of a decision. As humans, we tend to make decision emotionally (I like something, it’s cool, …), or we tend to focus on one attribute that is important to us, or we tend to focus on the short term instead of the long term, and in the process ignore important aspects for the success of the product.

Do you use decisions matrices? Any tips/thoughts for making decisions like this?

I think if the UI technology is open source then community and release cadence should be a factor too.

1 Like

good point – the health, community, support, etc are critical factors.

Ironically, you can often get better community support from new/small communities like LVGL than larger established projects. However, small projects are more dependent on one or a few people, so the bus factor risk is higher. Again, all these things are hard to quantify, but you should at least think about them.