High-End Graphics on Small Devices
Speeding Time to Market for GUI Designs
Delays in getting an embedded UI to market are costly in terms of development resources as well as competitive advantage. The process is often lengthy and tedious, setting back launch dates and driving up development expenses. This can be improved using some best-practice approaches to speeding time-to-market.
BRIAN EDMOND, CRANK SOFTWARE
Page 1 of 1
In traditional GUI design, a user experience (UX) or user interface (UI) team creates a prototype on desktop software such as Adobe Photoshop, Illustrator, HTML or Flash, submits it for approval, and then transfers it—for most of the remainder of the development process—to the engineering team. This design process presents the first major obstacle in time-to-market and is also what often results in a less-than-desirable UI. Once that critical UI design hand-off occurs, embedded system developers proceed to re-implement the prototype for the embedded system. The result is that the original prototype, in essence, becomes a throwaway, since the performance observed in the desktop application bears no resemblance to the performance of the target platform. As embedded system developers go about the process of re-implementing the prototype—and attempting to replicate the UI—they inevitably make changes and sacrifice features in order to fulfill their mandate, which is to make it run on the target.
It is important to note another factor that delays time-to-market: UI designers and embedded system developers typically do not work in tandem at any point in the process. In fact the opposite is true. Once the design is handed off, UI designers often do not see it again until the alpha or beta phase of product testing. This siloed approach, in which there is a complete loss of design control, creates lag time late in development as the designer attempts to retrofit features into a nearly completed product. As a result, another obstacle to market release is a back-and-forth process between the UI designers and embedded system developers to develop a product that both reflects the original design and is fully functional (Figure 1).
A very rich and complex user interface can be designed using Windows-based tools like Photoshop or Adobe Illustrator and others. Translating that design to run under the RTOS on an embedded design can be filled with complications and compromises.
The disconnect between the two teams runs even deeper than that. UI designers, as mentioned before, typically use desktop applications that were never intended to run on the target platform. In other cases, the prototype itself is comprised with fake content and imagery and does not even contain real data. This adds to the embedded system developers’ timeline, as massive re-coding is required to make the translation from these desktop applications to an entirely different hardware and/or software platform.
As every UI development team knows, the result is that development time has been so delayed that in fact there is no time left in the schedule to adequately address UX issues. These delays also mean that testing occurs late in the development cycle, since no portion of the UX can be tested independently while the engineering team is still writing back-end code. Ironically, it is the UX that is the true differentiator for any embedded UI, and the intended UX—one that ties customers to a specific brand with rich features and intuitive functions—often never gets released. In the end, the prototype and the end product have diverged due to design misinterpretation and performance implications to an extent that the end product does not reflect the original design.
Best Practices for Speeding Time-to-Market
To get GUI designs to market more quickly, a better approach is to allow UI designers and embedded system developers to work independently, but concurrently, on UI development—doing what each does best. In a workflow where there is no product hand-off, each team remains involved and able to provide continuous feedback. If UI designers are allowed to own the design throughout the development process, it not only compresses the development schedule, it also requires fewer embedded system developers on the development team. The reason is that they are no longer forced to write code in order to implement design features at the same time they are working toward functionality on the target platform. When embedded system developers are forced to change the design, two things result. First, they make mistakes because that is not their area of expertise. This then results in a multitude of trial-and-error efforts to rectify the mistakes. Secondly, it also takes exponentially longer for them to make said design changes.
When creating a UI, development teams can expedite the release date by creating a thorough design up front, by fully defining the UI features, the hardware platform and the system integration points. In other words, each team should have an equal amount of information about what the product will look like and what it will do, from the beginning. This is important because UI designers need to know what data the UI will be able to retrieve from the system, and embedded system developers need to know what demands the system must be able to accommodate. Armed with information on the various required entry points, embedded system developers can test these independently, and much earlier in the process than is typical today.
Another time-to-market boon is the prototype-as-product approach, which means implementing designs on a true prototype immediately. The typical processes are to prototype the design and then re-implement it for the embedded platform. However, if the design is implemented on the prototype from the outset, with the intended design fully functional on the intended platform, then any design flaws, feature or hardware compatibility issues, etc. can be rectified early, rather than in the testing phase. If the prototype is the product, then the embedded system developers can begin writing the back-end code immediately as well. Working from a functional prototype that runs as well on the desktop as it does on the target, such as a tablet, can help condense development time from months to weeks.
Often the hand-off process for the design team involves exporting the design information and images into a format usable by the development team—a time-consuming task that again delays deployment. The reason: UI designers’ applications do not speak to embedded system developers’ software development tools. A better solution is to allow UI designers to use a set of tools they are comfortable with and that can be easily integrated by embedded system developers—and then transmitted back to UI designers when changes are required. This eliminates the need to re-write code for every UI change, which introduces bugs into the functionality, requires more testing time and delays the UI release. The more expeditious approach is to allow the designer to make changes to data files, such as XML or HTML, that can be used as a UI description language.
A common “fix” for development process issues is to deploy third-party software to bridge the gap between the UI designers’ toolsets and the embedded system developers’ toolsets. Yet all too often, the third-party application does not integrate well with either. Needless to say, incompatibility issues lengthen the development process, and third-party software that is not compatible with the software currently in place will exacerbate the issue. It is essential that the development support software can integrate with what both teams are currently using—with Adobe Illustrator or Adobe Photoshop for UI designers, and with tools like Eclipse or native desktop tools for Linux for embedded system developers.
Development software that separates the UI from the back end can speed development and deployment. Using a model-view-controller pattern can shorten the design process and help teams work together with clear objectives. If they can be run independently, then each team can continue to work on the product without making disastrous changes while still maintaining clear integration points. This allows each team to focus on their core competencies: design or embedded system development.
Development software that does not flexibly support multiple platforms like Macintosh and Linux can also add time constraints. Every member of the development team should be able to work in the environment in which they are the most efficient. The developer should also be able to simulate and test features on their respective platforms to limit the need for external hardware platforms.
Development teams also must have the ability to run a functional prototype on multiple platforms to compare performance early in the product cycle. Teams that are able to evaluate hardware platforms, and various configurations on those platforms, can test performance early in the process and make educated decisions about whether or not the platform will perform as expected with the design. Many time delays in development are centered around resolving those issues—or worse, settling for a less robust UI due to hardware constraints.
For teams looking to speed time-to-market, the key is unquestionably to have flexibility. When choosing development support software, beware of anything that limits either the operating system or the target hardware platform. To maintain efficiency and competitiveness, companies should have the freedom to move from one platform to another based on development budget, customer expectations and similar factors. The converse scenario forces companies to purchase different UI tools for different product levels.
It is also important to resist the temptation to overlay frameworks. To address all of these development roadblocks, many companies resort to implementing a framework over the development process. The result is that not only is the company employing a team to build, test and maintain a UI, it is also employing a separate team to build, test and maintain a framework. This added layer serves to complicate and delay the development process. Similar circumstances occur when someone in the company builds custom tools to solve these internal issues. The builder then becomes an internal product provider.
Companies using Crank Software (Figure 2) have been able to speed time-to-market by implementing these best practices. For instance, QNX Software Systems used Crank Software to implement a 17-inch, curved, 1080p center console display embedded in a Bentley concept car. The unique digital light projection HMI, which debuted at the Consumer Electronics Show in 2013, featured content that was originally created in Adobe Photoshop and was fully implemented on the target in only eight weeks.
The Crank Storyboard Suite was designed for engineers by engineers. It allows UI designers with no programming experience to drag-and-drop their UI designs in parallel with, yet independently from, the engineers who are working on the coding. Storyboard simplifies the design process, saves valuable time and leverages the core skills of each valued member of the team.
Another company, Auto Meter, used Crank Software to successfully develop its new LCD Competition Dash—a user-customizable display with precise data acquisition—in less than six months for their customer, NASCAR. The display was launched in time to debut at the 2012 SEMA Show for automotive specialty products.
Much exists in current UI development scenarios that extends the development timeline, drives up costs and sacrifices UI quality in order to meet a targeted release date. Creating an environment in which UI designers and embedded system developers can work collaboratively, but independently, enables each to stay focused on what they do best, to maintain ownership of the UI from concept to implementation, and to speed time-to-market—a critical requirement in a landscape where companies can succeed or fail based on their next UI.