Embedded UI development teams often struggle with communication barriers, lack of visibility, and siloed workflows throughout the development process. This typically results in extended development timelines and overstretched budgets. However, UI development support software can help teams overcome these hurdles.
No matter how refined the development process, every embedded UI development team has faced the challenge of overcoming communication barriers. What would seemingly be an essential and beneficial part of the development process, the back-and-forth exchange of ideas and information between UI designers and embedded system developers, is fraught with obstacles in these key areas:
- Siloed workflows: Designers and developers often work in silos and in a linear fashion. Once the design is completed, designers often move on to another project and adjustments to the UI design then fall into the hands of embedded system developers.
- Unskilled task performance: When embedded developers are forced to make design changes, they are no longer “doing what they do best” – which is building the back end of the product.
- Lack of visibility: Developers often select hardware and operating systems without a full understanding of UI functionality requirements.
- Unclear parameters: Designers, working with no up-front parameters, often conceptualize features that far exceed the capabilities of the systems on which the UI will run. Creating UIs that are difficult or impossible to implement can dramatically drive up development costs.
Whether the development team is creating an interface for an automobile, a dishwasher or a thermometer, it is exceedingly difficult for UI designers to communicate the intent of a dynamic and active UI from the creative vision through its engineering implementation. This communications challenge not only results in friction between the design team and the implementation team, it also threatens the integrity of the end product. The reason: Design changes are an inevitable part of the process. As the team strives to match the original design intent with available technology capabilities (or limitations), the probability of errors increases with each incremental change.
This communication barrier also drives up development time, putting release schedules in limbo and in many cases forcing companies to launch a less-than- desirable UI long after the intended date. The costs of scrapping the UI and starting over are usually untenable. Moreover, for companies that may release a UI once per year (the typical lead time for an embedded UI in the automotive industry is 1.5 years), pushing out the release date can mean the difference between competitive edge and obsolescence.
Simulation is another universal challenge. In many development environments, simulations are created using HTML or flash and run on a desktop rather than on the target hardware. This creates an obvious lack of visibility into functionality issues that will certainly appear when the UI is running on the embedded hardware. The outcome: Everyone on the team is working toward partial specifications and making assumptions. This method of simulation always results in massive coding required to make the interface function in the embedded hardware environment. In short, simulations typically do not match the functionality and behavior of the embedded environment that will ultimately host the UI.
In most cases today, the final UI is the result of a series of compromises because of a siloed development process, resulting in a lower-quality user experience. The process typically goes as follows. The design team delivers the initial design, and then the engineering team, in the course of implementing what they perceive to be the design, makes changes and adjustments. Sometimes the changes are consciously executed based on hardware/software limitations; other times the changes are not intentional, but are made as developers fill in gaps in the specification of how the UI is “supposed” to perform in all situations. Further complicating the matter is that the original designer (who might be an external resource brought in to help with the UI conception) might no longer be on the project. That resource, effectively, has disappeared.
But it is important to choose the right UI development support software for the job. Accordingly, the sidebar lists the 10 most important questions to consider in this paradigm.
Establishing a common software environment
A better approach to UI design and implementation is to establish a common software environment that spans the entire development team, and their tools, and enables everyone to participate in a discussion around the UI in a consistent manner. In this way, designers and developers can maintain communication from start to finish about the design itself, and manage changes and constraints as they logically appear throughout the process. When designers maintain ownership of the user interface from start to finish, software developers can focus on refining core product functionality, rather than “shifting pixels” to accommodate a changing UI. With full visibility into the design and near-immediate feedback about the embedded implementation, designers can make informed decisions about functionality as it evolves. With a working user interface that is developed under simulation, developers can use a real-world UI to make informed decisions when selecting the hardware and OS. All together, everyone is better able to ensure a consistency of vision when UI adjustments must be made.
Teams that can work collaboratively and simultaneously – with designers maintaining responsibility for the user interface and the system developers retaining ownership of the underlying system interface logic and behavior – can also bring the design to a deployment simulation (reflecting the functionality on the actual hardware and OS) much more quickly. Early simulations deliver a number of advantages. Developers can test the application on various hardware platforms, before committing to the technology. This is critical for today’s highly interactive UIs. A touch screen will naturally function much differently from standard “mouse-and-keyboard” desktop inputs and can be modeled very effectively using a tablet OS. Early simulation also forces constraints on designers, which helps bring the UI to fruition more efficiently – as unrealistic features are abandoned much earlier in the process.
Early simulations and improved communication can dramatically condense development schedules. This ultimately helps to increase the quality of the end product, as it opens the door for user experience testing and product refinement based on customer feedback. Moreover, this refinement occurs with the designer, rather than the costly and time-consuming recoding required by a software developer. All of these things enable companies to mitigate handoff costs between designers and software developers.
Getting products to market more quickly
An effective way to ensure that the UI development process is not hindered by the aforementioned obstacles is to use UI development support software. Companies using such software have been able to put this collaborative development environment into action, speeding time to deployment. An example is QNX Software Systems’ usage of Crank Software’s Storyboard Suite UI development support software to implement a 17", curved, 1080p center console display that was embedded in a Bentley concept car. The digital light projection HMI debuted at the 2013 Consumer Electronics Show and featured content that was originally created in Adobe Photoshop and fully implemented in only eight weeks as opposed to the four to six months of back and forth between developers and designers that a project of this magnitude would normally entail. Auto Meter also used the same UI development software to develop the LCD Competition Dash for NASCAR in less than six months (Figure 1).
What allows this type of rapid development of products is forceful decoupling of the user interface from the implementation details of the system. The Model-View-Controller (MVC) paradigm is strictly enforced by channeling all user interface changes through an event and messaging system.
The messaging interface allows the UI to be constructed as a contract to future data bindings that will be provided as input/output events. During the initial user interface development, any required inputs can be simulated using synthetic events without any requirement for a functioning embedded hardware system in place.
System development also progresses more quickly because of the clear definition required input and output events. Verifying their inputs and outputs against a definition rather than to a UI presentation more easily validates system components.
Final product assembly and integration are greatly facilitated by such a structured set of event interfaces. Remove the simulated inputs and outputs and replace them with the system components that have been already validated against an event specification.
Delivering a high-quality UI experience
In the highly competitive world of embedded UIs, companies are judged based on their ability to deliver state-of-the-art technology that exceeds consumer expectations. Faster and more cost-effective UI development is critical. Even more important is to produce the highest-quality UI that technology can enable – with each subsequent product generation having to surpass the last. UI development support software can address all of these needs by ensuring full visibility and collaboration between designers and developers during the development process and enabling software simulation functioning similarly to a runtime engine, enabling software test ahead of time on the embedded hardware. Vendors such as Crank Software with its Storyboard Suite UI development support software are aiming to fill these needs and hasten the development process.
Crank Software www.cranksoftware.com