Automotive User Interfaces and Interactive Vehicular Applications

multiple views or how the individual HMI components interact
with each other within a single view.
3. WIDGETS IN 3D-GUIs
Conventional widgets for 2D GUIs come with a pre-defined look.
This look is defined in a drawing routine that renders a widget
instance to a given canvas object while taking into account the
current state of the widget. However, this approach is not suitable
for 3D GUIs. In such GUIs the user interacts with objects in a
three dimensional space. These objects might look partly
transparent and can intersect or illuminate each other. As a
consequence, a single widget cannot draw itself independently
because its appearance is influenced by other objects. A central
renderer is needed to handle the overall rendering taking all
objects into account.
This calls for new concepts in widget implementation. A possible
solution would be to modify the widget’s drawing routine to
report the objects that reflect its present state to the central
renderer. The central renderer would then perform the rendering
of the scene after it has collected this information from all
widgets. In this approach the look of the widget is defined
programmatically just like with conventional 2D widgets. As
previously described this leads to duplication of work which
makes design changes costly and time consuming.
Having a central renderer that knows the complete structure of the
scene in the form of a scene graph is the key to implement 3D
GUIs. Moreover, it can also be useful in conventional 2D GUIs
because it also enables implementing appealing effects such as
camera movements or filters.
4. CONTROLLER-WIDGETS
In order to be able building seamlessly integrated toolchains it
makes no sense to dictate visual designers what tool they have to
use to create design drafts. GUI builders in particular offer limited
capabilities compared to professional graphic editors and
therefore hinder the creative process. Furthermore, it is more
difficult to try out different design variants using such tools
because the widgets required for each variant have to be
implemented beforehand. Instead, visual designers should be able
to use tools that offer maximum design possibilities without being
restrained by implementation details. Ideally, standard graphics
editing programs can be used such as Adobe Photoshop or
Autodesk Maya.
Analogous to the approach proposed in EDONA, the designs
created in these tools should be saved to a standard format which
then can be imported to subsequent tools and reused for the
implementation of the final HMI. However, in order to be
applicable in the development of three dimensional GUIs, too,
other image formats than SVG have to be used. In addition to the
static GUI layout the format should also include animations.
COLLADA and FBX are examples of formats that can match
these requirements.
After the GUI has been imported into the HMI development tool
it is represented as a scene graph. This scene graph can be
supplemented with technical information that are not relevant for
the graphical design but are required to implement an efficient
rendering in an embedded system. Such information cannot be
imported because they are not specified by the visual designers.
Up to this point in time the imported GUI design is still static.
Widgets can be used to make it become dynamic. In this case the
widgets serve as reusable components of HMI behavior that can
be configured using the widgets’ properties. Just like in
conventional GUI builders these properties also define the
interface between the GUI and the application logic. However, the
appearance of these widgets is not programmed. Instead of that,
the widgets are assigned to elements of the imported scene graph.
They can manipulate these elements according to their current
state. As a result, programming widgets is reduced to the
definition of this behavior as well as its properties for
parameterization and data exchange with the application. Instead
of using ESTEREL other programming languages for embedded
systems should be used that are familiar to more developers.
With regard to the popular model-view-controller pattern 5 [22] the
widget’s task is reduced to the controller-role while the view is
derived directly from the visual designer’s drafts (Figure 4).
Figure 4 – Controller-Widgets vs. Conventional Widgets
The described approach enables the adoption of new design drafts
with little effort. The static appearance of new GUI design can be
evaluated in prototypes before the necessary widgets need to be
available, since they are only required to add the dynamic
behavior and to connect the GUI to the application logic.
5. IMPLEMENTATION IN MODERN 3D-
HMI-DEVELOPMENT TOOLS
A new generation of HMI-development tools is needed to
overcome the difficulties discussed above. Such development
tools allow the direct reuse as well as the progressive refinement
of design drafts and also the definition of static and dynamic
behavior. Static behavior is created at design-time using
animations while dynamic behavior is stimulated by events at runtime.
These tools are based on the concept of the model-view-controller
pattern which masters complexity with its specialized roles in
HMI development. Separation of different development aspects is
also considered, such as ergonomic designs, run-time behavior,
and cross-divisional tasks like configuration management, quality
management and quality assurance. The complexity and specialty
of each individual aspect leads to organizational and technical
partitioning of the development process. The individual tasks are
supported by separate tools which are integrated into an end-toend
toolchain. These tools can provide deeper expertise in this
aspect compared to extensive multi-functional tools, since they
focus on a single development aspect. Ideally, the highly
specialized tools which form the toolchain can be selected
independently from each other. This requires interface and
workflow compatibility which is facilitated by supporting
established industrial standards.
5 Model-View-Controller is a concept of the Smalltalk
programming language [22] and is now often referred to as a
design pattern. It separates the user interface into 3 parts with
different roles. The model holds the state of the application and
manages its data. The view renders a model into a form suitable
for interaction with the user. The controllers mediate between
both parts and control the user interaction [23].