As today’s devices and their respective user interfaces become more advanced, so does the creation and production of today’s user interfaces as well. Creating a UI for a modern-day device is often complicated enough as it is. However, when you want to make the UI for a specific custom embedded device, it can be a totally different beast to tame.
We often see developers fall into various problem buckets, coming across the usual suspects of mistakes. In this short series, we dive into these problem areas and reveal the most common mistakes developers make when creating cross-platform UIs, starting in this article with 6 mistakes related to the application and solution architecture.
Area 1: Application and Solution Architecture
Mistake #1: Misunderstanding memory consumption and memory use
When a developer loads into graphical memory, some things to consider are what items to cache, in what order to load elements and how to build out the overall UX. Performance issues (often the case in smaller devices) differentiate between actual and perceived performance. For example, for actions that take a lot of time (actual performance), developers can throw a preloaded image on the screen to make the user think that things are happening faster (perceived performance). Qt, for one, has very good tools in solving and understanding that. It requires technical competence and tools in place to address those issues.
Take, for example, an embedded Linux stack. Unpolished off the shelf, the underlying operating system alone can easily take 10 seconds to boot, and a vanilla Qt on top of it would take roughly a second (see Figure 1). Factoring in your application itself on top of that, and total bootup time sums up to ~15 seconds. With proper skills, tools and optimization, the bootup should only take a second or two.
Figure 1: Time duration of bootup sequences differs greatly between unoptimized and optimized software stacks (Source: The Qt Company).
When optimizing, developers need to slice down performance lags and understand where the real bottlenecks and time consumers are. This needs understanding and competence on how the memory is being used, in what order, and how to optimize that. If the solutions take a lot of time to boot, optimization hasn’t been done properly. It then shows businesses don’t value performance, which, I guess in the end is OK, since the customer bought it anyway?
Mistake #2: Developing on PC before deploying to target hardware.
This is the most common cardinal sin of embedded development. Designers and engineering teams spend way too long developing embedded solutions on PC only. They then deploy to target hardware too late in the project. This issue is often exacerbated further by the fact that the target hardware is typically new and not available for the teams in the early stages of the project.
The later the design flaws, performance bottlenecks, errors or issues are discovered in a project, the more exponentially costly they are to fix. When comparing a PC to an embedded device, there is almost an unlimited amount of resources, memory and power in use, among other underlying factors. You may not realize the features you add impact performance, if they run just fine on PC. This results in major issues of rearchitecting and redoing large areas of software. What runs perfectly on PC desktop does not always run nor manage properly on embedded devices. Neglecting this impacts time-to-market, cost of ownership and engineering and maintenance cost.
Is there a magic bullet? Yes, start deploying on target device from Day 1. Invest in tools that make this possible. Make sure the whole team, including designers, has access to the target hardware. If you don’t have the target device available, take something which is close to that and start with that from Day 1. Today, there is a good selection of off-the-shelf reference hardware that should get you close enough. If you must develop on PC only, then develop on PC, but plan for the consequences of rewriting and delays.
Mistake #3: Squeezing fully rendered design into embedded devices.
To show cool three-dimensional elements on a screen, a 3D design comes from a designer. Designers will often create fully rendered images, amounting to countless polygons (“Hey, it was working on the designer PC just fine. ”). It is left to the developer to try to squeeze the humongous 3D objects into a small device (See Figure 2). It either makes everything really laggy, or adds additional hours of work for the developer, or both.
Figure 2: Fully-rendered images from designers lead to overly complex elements for developers (Source: The Qt Company).
Also on 2D UIs, developers and designers sometimes use overly complex elements on the UI. The challenge is how to optimize that down, shaving and slimming images, elements and polygons to fit a small screen, while keeping the UX the same. Performance and/or time-to-market are often casualties along the way.
Mistake #4: Using one coding language as a one size fits all.
Designing the software architecture from the get-go is important. Put on the UI layer first. Then put on C++ and lower layers (binary execution, native binary execution, possible GPU and CPU power used on those layers). When designing software architecture picking the right parts is important.
A well performing Qt application has two major parts: The application logic and heavy lifting is written in C++, and UI and user interaction is written using a higher-level language, such as QML.
Mistake #5: Treating updates and security as features.
Say you’re working on a project, and you’re about two thirds of the way complete. Your customer then wants to add over-the-air software updates and security features. This is a mistake. Updates and security are NOT features. They are design mindsets and core parts of the overall software architecture.
Way too often customers approach updates and security as something that you implement somewhere along the line among other features. They’re not that. Developers must plan and think ahead. What kind of security requirements are there? What parts of the software need regular updates? How do you enact this? How do you verify? It requires a mindset from Day 1. For example, if developers write something on the firmware layer critical for the UI, it may not be possible to update firmware in the same mechanism they can use to update the application layer and the UI.
Mistake #6: Neglecting to optimize your “workspace” in your operating system
We already discussed above about the optimization of the boot-up-performance (mistake #1), but there is more to it.
Reference images for software engineering typically come with a lot of tools and features enabled. They are designed for developers to get an easy start on implementation in their projects. These tools all run simultaneously, but you either use them or you don’t. Start stripping away what you don’t need. Optimize. When this is not done, systems use their limited resources on embedded device to run useless processes in the background. Get rid of those.
Many of the embedded projects work on Yocto-based images that are created with Yocto recipes. Unfortunately, those recipes are also notoriously difficult to use, as the level of documentation varies (see Figure 3). There are many vendors, and one needs to understand intimately the workings of hardware drivers, kernel and other parts of the system. This is an area where money spent on professional consultancy services typically pays back in time-to-market and improved performance.
click for larger image
Figure 3: Many embedded projects work on Yocto-based images created with intricate Yocto recipes are notoriously difficult to use (Source: The Qt Company).
Part 2 of this short series on UI design will look at six more common UI development mistakes related to technology selection, user experience, and more.
Santtu Ahonen works in The Qt Company as product manager of the Qt for Device Creation. Santtu has over 20 years of experience in product management on various high technology products including Nokia Maemo as Head of Developer Offering Product Management where Qt was essential part of the plan. Santtu joined back in to Qt technology and The Qt Company in spring 2017.