The rise in the importance of the Graphical User Interface (GUI, or more generally UI) is no longer confined to the consumer market. UI design is quickly becoming a key differentiator among products across the entire embedded space. Applications where the UI was only required to be functional rather than eye-catching are evolving to embrace this trend. Industrial and medical devices are already pulling UI concepts from the consumer and mobile markets for their next-generation devices.

With this change in importance comes a shift in how UIs are developed. UI development is no longer a process controlled only by embedded engineers; it includes many stakeholders new to the embedded life cycle. Collaborative effort now includes UI designers and user experience (referred to as UX) designers along with embedded engineers.

New roles on a team

Each of these stakeholders not only brings their own expertise, but also very different development environments and processes that generally don’t align with the embedded development world. Here’s a quick review of each stakeholder’s responsibilities and development environments:

• Embedded engineer: Responsible for application logic from middleware down to the embedded system’s hardware. The embedded engineer develops with C/C++ code and uses a source code repository for collaboration and project history retention.
• UX designer: Responsible for defining product screens, UI flow, high-level application logic, and data presented to users. The UX designer uses sketches, wire frames, flowcharts, and UI prototypes in Adobe Flash, HTML, Balsamiq Mockups, and similar applications.
• UI designer: Defines graphical content along with screen transitions and animations. The UI designer usually works with tools such as Adobe Photoshop and Illustrator and other image editors.

Both the UI and UX designers have no standard method of collaboration outside of agreed-upon processes and task serialization. The UI and UX roles are occasionally combined to reduce the collaboration challenge, but this doesn’t address the lack of tools to manage the design artifacts generated during development.

With all these different skill sets and work environments, collaboration becomes a daunting task and a potential productivity killer. When engineers and graphic designers must work together, the difference of concerns and development styles can introduce significant churn. Many companies attempt to avoid this conflict by using a single resource – an embedded engineer – to manage the UI. This solution works in very simple cases but doesn’t scale with larger projects and prevents more resources from being applied to UI development if timelines aren’t met.

When a project is serialized through a single resource, UI and UX designers are often sidelined during the implementation stage. The designers contribute initial graphic content, images, and wire frames to the project and then are left out of the development process as software developers implement their designs. This often results in a mismatch between the desired user experience and what is delivered in the final product.

Concerns and tools differ

During the development and release of a UI interface, UI/UX designers have concerns that may be more important than the embedded developer’s concerns, which tend to focus on processor usage, memory footprint, code architecture, maintainability, and reuse. UI/UX designers focus more on usability, interface consistency, graphics quality, and overall user experience. These concerns are not always completely at odds with each other; however, not having a balanced approach can easily kill a product’s market appeal.

To balance these concerns, it is important to enable involvement of all stakeholders throughout the development process. This is easier said than done, not only due to the different skill sets and concerns, but also because the development environments provide little crossover and no natural integration. Several issues can quickly come to the surface:

• Using a widget library or C/C++ development GUI framework prevents anyone except experienced embedded engineers from collaborating.
• UI and UX designers along with product marketing staff require the assistance of an embedded engineer to perform even trivial changes to the UI.
• Using higher-level tools familiar to designers prevents integration with a code repository and fails to provide useful information on detailed changes or collaboration and merge abilities.
• In embedded projects all the development collaboration is done via a code repository designed to work with text files, providing minimal return for binary and proprietary formats.
• Using a code repository with C or XML files doesn’t demonstrate the context and ramifications of a small change to a UI when viewing the compare at the text level.

Many informal tools such as e-mail, instant messaging, and wikis are used to attempt to solve these issues. While these tools offer certain advantages, in the end they only assist in sharing information about the project, not the artifacts and deliverables associated with the project. These tools don’t enable sharing and collaboration at the UI design and development level, excluding important elements such as screen designs, screen transitions, script and code management, and test suites.

At the other end of the scale, source code repositories offer a formal and structured means to capture the base code represented by the project. While source code repositories are necessary for any large project to succeed and have proven to be successful for software engineering teams to collaborate, they are not sufficient to enable non-software development team members to collaborate. As an obvious example, a graphic designer gets very little value from a source code repository.

Visual collaboration surfaces

UI development is much different from standard embedded system development because monitoring the UI over time requires a visual approach rather than a source code difference view to fully comprehend changes in context. Source code changes or XML declarative languages viewed in an editor do little to help the developer fully understand the true ramification of the changes (see Figure 1). This problem is amplified when the resource examining the differences is not an embedded engineer who is intimately knowledgeable on the source base. Furthermore, many UI tool suites involve code generation or proprietary binary components for key pieces, making it extremely difficult to manage.

 

 

To solve this issue, the ideal approach is to use a tool or set of tools that not only exposes the changes of UI-specific elements in a visual manner, but also integrates with the main collaboration hub of the embedded development life cycle, the source code repository (see Figure 2). Utilizing tools that can expose each change of the UI at a level that is easily understandable to any stakeholder enables all stakeholders to work in parallel. Allowing stakeholders to fully collaborate provides many benefits, including early discovery of issues in UI behavior, shortened product development times, and a better user experience in the final product.

 

 

Crank Software’s Storyboard Suite supports visual UI development by creating an environment that can be leveraged by all stakeholders. The tool utilizes the Eclipse framework as the base for Crank Software’s Storyboard Designer, wherein embedded engineers can leverage the Eclipse C/C++ plug-ins. Storyboard also helps resolve the dilemma of context with respect to monitoring the evolution of the UI within the product. A visual difference-compare editor for the UI and support for text differences (for scripting and programming languages) allow all project participants to look at the history of a product in a context that is relevant to them. With a tool like this, UI/UX developers can quickly and collaboratively develop the UI by directly importing from their familiar tools.

 

 

Jason Clarke is the cofounder and VP of marketing at Crank Software Inc. Jason has 13 years of experience in embedded development, sales, and marketing. Prior to Crank Software, Jason was a senior field application engineer at QNX Software Systems, where he provided on-site consulting services, including system debugging and design review to OEMs developing consumer electronics, automotive infotainment devices, industrial devices, and medical instruments.

Crank Software 613-595-1999 [email protected] www.cranksoftware.com