Page 40

EETE MAY 2013

HAPTICS & USER INTERFACES Time for a new UI programming paradigm By Jason Clarke With the ubiquitous usage of smartphones, tablets, and other mainstream screens, traditional products that once had analog displays are now being modernized with digital user interfaces (UI). From thermometers to air conditioning control panels to car dashboards, even the simplest and smallest embedded devices often feature graphical user interfaces (GUIs). Therefore, manufacturers are focused on delivering quality electronic products with intuitive, easy-to-operate UIs – all without slowing down the development process. Fast time-to-market means that the design, prototyping, and testing phases must go quickly and smoothly. In general, good project planning and efficient working processes can help with this goal, but what does that specifically look like for UI development? Let’s take a look at the typical development paradigm and identify the sticking points. The problems with traditional UI design The conventional development cycle for embedded GUI products is typically as follows. In the planning stage, the hardware and software features for the product are defined. The user experience (UX) or UI design team creates a mockup of the GUI using desktop digital graphics tools, such as Adobe Photoshop or Illustrator. Then the engineering team recreates the design file or image in their programming environments, such as Eclipse or native Linux desktop toolsets, to make it work with the embedded Using the Crank Storyboard Suite integrated GUI development platform shortened UI design and programming for the 2013 QNX Bentley concept car to only eight weeks. hardware system. The programmers can then re-engage the designers during the alpha or beta phase of product testing to give feedback on the UX based on what they’ve already created. At first glance, this process may seem straightforward and simple enough. However, upon closer examination, there are several time wasters and flawed development techniques that can be spotted: • Serial, linear workflow • Minimal collaboration and communication between teams • Inaccu rate UI prototyping • Inefficient development toolsets Some people may claim that these obstacles are simply “the nature of beast” when it comes to embedded UI design. However, in an ideal world, what would an alternative to these hindrances look like? Is there a different method of GUI software development that could overcome these challenges and speed up time-to-market? Introducing a new UI programming paradigm Perhaps what needs to happen is the establishment of a completely fresh and original UI programming model. By addressing each of these inefficiencies with an unconventional approach, a new process for designing, prototyping, and developing embedded UI products begins to appear. Improvement #1: Speed up development with concurrent workflows UI design and embedded UI programming are typically worked on one at a time in a serial fashion. On the surface, this makes sense – how can the code be developed if the programmers don’t know what the GUI looks like? However, this difficulty can be mitigated during the planning stage by creating a very detailed requirements document that defines all the software features and hardware parameters. The designers need to know exactly what data the UI can retrieve from the system, and the engineers need to understand what demands and UI performance requirements the system must accommodate. Armed from the beginning with comprehensive information about the product’s appearance and functionality, the two teams can work independently yet simultaneously. If UI designers have a way of actively revising the design throughout the development cycle without extra coding effort, then embedded systems developers would no longer need to write code every time a design change is required, and can concentrate on implementing functionality on the target platform. Much time is saved if both teams are working concurrently in their own areas of expertise – with designers not programming and programmers not designing. Improvement #2: simplify and streamline collaboration between teams Designers and programmers developing in parallel may seem like a magic time saver, but each team will be making changes based on a different set of care-abouts. The graphic designer wants to promote usability, interface consistency, and graphics quality, while the embedded developer is focused on processor usage, memory footprint, code architecture, maintainability and scalability. How can optimizations for user experience versus system resources be easily consolidated? Clearly, communication and integration methods must be in place to help, not hinder, the process. Using a back-and-forth review process between parties may seem logical, but additional lag time is introduced for each interaction. It would be much more efficient if the embedded GUI development tools could automatically display changes, merge edits, and resolve conflicts. Another useful function would be the ability to highlight UI design decisions that may take significant resources to run so By Jason Clarke is Vice President of Sales & Marketing at Crank Software - www.cranksoftware.com 40 Electronic Engineering Times Europe May 2013 www.electronics-eetimes.com


EETE MAY 2013
To see the actual publication please follow the link above