4 min read

Extending the Life of Your Embedded GUI

Topics:
Featured Image

extending_life_embedded_GUI

Ask any embedded GUI developer or designer about re-building your product’s user interface, and you’ll probably be met with groans. Creating user interfaces can be a long, laborious process and replacing them is usually something you want to do as infrequently as possible. This is true even considering best practices like using embedded software tools that enable simple screen design or coding practices that enforce cleanly separated business logic.

That’s because the bulk of the effort in creating embedded GUIs is:
- The heavy lifting of designing user workflows.
- The creation of attractive visual elements.
- Taking human-factors engineering into account.
- Performing usability tests.

Once your embedded GUI is built-out, your team needs to develop UI test suites to give you the confidence that things aren’t broken by bug fixes. Once that's done, there’s the downstream impacts to user documentation and product support that can mean substantial rework.

When you have your UI right the first time, it pays to keep it as long as humanly possible.

creating-embedded-GUIs


Hardware causing GUI churn.

We know that one of the biggest reasons you might be forced to redo your GUI is a hardware change – specifically, switching between different sized, different featured processors. We worked hard to address this in the design of Crank Storyboard. We saw that smaller hardware platforms didn’t always have the horsepower the UI needed. Other times, UI tools would work on the high-end and not the low-end (or vice versa), or only run on a subset of platforms. Since Storyboard is able to target high- and low-end systems, with different types of hardware accelerators – or none at all – it makes all types of hardware migrations possible, all the while keeping your UI intact.

Trouble ahead. Scaling up your embedded GUI.

A real-life example of UI portability difficulties came to us recently in a customer project. A customer had designed a product using a microcontroller. This customer wanted to create a premium-level version of the same product that included several additional product features. Those new features required migrating their product to a more powerful ARM Cortex A7 CPU in the same manufacturer’s product line. Unfortunately, their UI created using their original UI development tool didn't work on the larger MPU, making for some difficult choices. Either they would need to keep their GUI tooling intact and leave the processor-intensive features out of their new product, or they would have to migrate their GUI to an entire new tool that could run on both platforms.

Rather than sacrifice the feature set, the customer ended up getting some help from us to port their GUI to Storyboard. We made that transition as easy as possible for them by reusing most of their existing graphical assets, since they were already happy with the fundamental user workflow and the UI look and feel. But after moving to Storyboard, they were able to target devices incorporating either microcontroller or microprocessor chips without any software or design changes, letting them share one code base for both products.

UI-quote


The trouble with scaling your embedded GUI DOWN.

That particular case of software not being able to migrate to higher performance processors is a bit unusual; platform incompatibility often goes the other way since products that will work on general purpose CPUs don’t always run on lower-end microcontrollers. You often see this in prototyping work, where it’s easiest to build proof-of-concepts on boards with far more horsepower than needed for the final product. That lets the R&D team build and test software easily without saddling them with optimization worries in an already tight schedule. But the team can’t lose track of the fact that the product will eventually be right sized to a more cost-effective processor.


The multi-platform approach.

This microcontroller/microprocessor flexibility is why Storyboard and Storyboard Lite are identical for design and development, and only differ in the target executables that are output. We know that building high-performing GUIs takes a lot of craftsmanship and you shouldn’t have to duplicate that effort if you don’t have to.

Download the free full-featured Storyboard trial to build your product’s embedded user interface in minutes.

New call-to-action