Software-Tools Alles andere als oberflächlich

Die Storyboard Suite ist ein Entwicklungs-Tool für Bedienoberflächen.
Die Storyboard Suite ist ein Entwicklungs-Tool für Bedienoberflächen.

Eine spezialisierte Software für die Entwicklung von Bedienoberflächen kommt den Anforderungen der Nutzer entgegen: Niemand möchte sich mehr mit Handbüchern auseinandersetzen und jede neue Produktgeneration soll besser sein als die vorherige. Und während der Entwicklung ändern sich oft noch Anforderungen oder Randbedingungen.

Teams, die an der Entwicklung von Bedienoberflächen für eingebettete Geräte arbeiten, haben es während des gesamten Entwicklungsprozesses häufig mit Kommunikations-Barrieren, mangelnder Transparenz und isolierten Arbeitsabläufen zu tun, was in der Regel zu längeren Entwicklungszeiten und Budgetüber- schreitungen führt. Entwicklungs-Software für Bedienoberflächen kann helfen, diese Hindernisse zu überwinden. Wie ausgefeilt ein Entwicklungsprozess auch sein mag – jedes Embedded-Entwicklungs-Team, das eine Bedienoberfläche (User Interface) entwickelt, wird schon einmal mit Kommunikations-Barrieren konfrontiert worden sein. Eigentlich scheint die Möglichkeit, Ideen und Informationen zwischen User-Interface-Designern und Embedded-Entwicklern hin und her zu übertragen, ein unverzichtbarer Bestandteil des Entwicklungsprozesses zu sein. In der Praxis aber stellen sich hierbei oft beträchtliche Hindernisse in den Weg:

  • Isolierte Arbeitsabläufe: Designer und Entwickler arbeiten häufig in abgegrenzten Arbeitsbereichen und auf lineare Weise. Ist ein Design fertiggestellt, müssen Designer nicht selten zu einem anderen Projekt wechseln, so dass Anpassungen der Bedienung den Embedded-System-Entwicklern überlassen bleiben.
  • Mangelnde Fachkenntnis: Wenn Embedded-Entwickler Änderungen an einem Design vornehmen sollen, verlassen sie ihren eigentlichen Kompetenzbereich, nämlich das Entwickeln des Back-End für das Produkt.
  • Mangelnde Transparenz: Häufig wählen Entwickler Hardware-Komponenten und Betriebssysteme aus, ohne die Anforderungen der Bedienoberfläche genau zu kennen.
  • Unklare Parameter: Designer, denen zu Beginn keine Parameter vorgegeben werden, erarbeiten häufig Konzepte für Features, die die Fähigkeiten des Systems, auf dem die betreffende Oberfläche laufen soll, bei weitem übersteigen. Das Erstellen von Bedienoberflächen, die sich nicht oder nur unter Schwierigkeiten implementieren lassen, kann die Entwicklungskosten jedoch dramatisch ansteigen lassen.

Unabhängig davon, ob ein Entwicklungs-Team eine Bedienoberfläche für ein Auto, eine Geschirrspülmaschine oder ein Thermometer realisieren soll, wird es für die Designer der Bedienelemente zunehmend schwieriger, die hinter einer dynamischen und aktiven Oberfläche stehende Intention vom Entwurf bis zur technischen Umsetzung zu kommunizieren. Dies erhöht nicht nur die Reibungsverluste zwischen Design- und Implementierungs-Team, sondern bedeutet auch ein Risiko für die Integrität des finalen Produkts. Schließlich sind Designänderungen ein unvermeidbarer Bestandteil des Prozesses. Während das Team daran arbeitet, die ursprüngliche Design-Intention mit den Möglichkeiten oder Restriktionen der verfügbaren Technologie umzusetzen, erhöht jede neue Änderung die Fehlerwahrscheinlichkeit.

Das Problem des „moving target“

Diese Kommunikationsbarriere verlängert außerdem die Entwicklungszeit, gefährdet die Einhaltung der Einführungszeitpläne und zwingt die Unternehmen nicht selten, lange nach dem vorgesehenen Datum mit einer suboptimalen Bedienung auf den Markt zu kommen, denn die Kosten für einen Neubeginn der Oberflächen-Entwicklung sind in der Regel nicht hinnehmbar. Für Unternehmen, die vielleicht einmal pro Jahr eine neue Oberfläche einführen (die typische Vorlaufzeit für eine eingebettete Bedienoberfläche in der Automobilindustrie beträgt eineinhalb Jahre), kann das Hinauszögern des Einführungsdatums zudem darüber entscheiden, ob das Unternehmen seinen Wettbewerbsvorsprung behält oder ins Hintertreffen gerät.

Eine Herausforderung stellt stets auch die Simulation dar. Simulationen werden in vielen Entwicklungsumgebungen mit HTML oder Flash erstellt und laufen nicht auf dem Zielsystem, sondern auf einem Desktop. Hieraus resultiert ein klarer Mangel an Einblickmöglichkeit in Funktionsaspekte, die sich aber spätestens dann manifestieren, wenn die Bedienoberfläche auf der eingebetteten Hardware läuft. Die Folge ist, dass alle Team-Mitglieder auf partielle Spezifikationen hinarbeiten und sich auf Annahmen stützen. So entsteht ein erheblicher Codierungsaufwand, um die Bedienoberfläche in der eingebetteten Hardware-Umgebung lauffähig zu machen. Kurz gesagt geben die Simulationen weder die Funktionalität noch das Verhalten der eingebetteten Umgebung, die letztendlich als Host für die Oberfläche fungieren wird, korrekt wieder.

Die finale Bedienoberfläche ist also wegen des isolierten Entwicklungsprozesses heute meist das Resultat vieler Kompromisse, und die Qualität der Nutzererfahrung leidet. Meist stellt sich der Ablauf wie folgt dar: Nachdem das Design-Team das anfängliche Design abgeliefert hat, nimmt das Entwicklungs-Team – basierend auf seinem Verständnis des Designs – Änderungen und Abstimmungen vor. Gelegentlich werden diese Modifikationen bewusst anhand der Hard- und Software-bedingten Restriktionen vorgenommen. In anderen Fällen dagegen erfolgen die Änderungen unbeabsichtigt, um Lücken in den Spezifikationen des Verhaltens der Bedienoberfläche in allen Situationen zu füllen. Zusätzlich verkompliziert wird die Lage, wenn der ursprüngliche Designer, der möglicherweise einem externen Dienstleister angehört, gar nicht mehr am Projekt beteiligt ist. Wichtig ist in jedem Fall, die richtige Software für die Entwicklung des Benutzer-Interface zu wählen. Im Kasten sind deshalb die zehn wichtigsten Fragen aufgeführt, die man sich bei diesem Thema stellen sollte.

Kasten: Software-Check

Die zehn wichtigsten Faktoren bei der Wahl der Entwicklungs-Software für eine Bedienoberfläche:

- Kann die Software von allen Team-Mitgliedern – Entwicklern und Nicht-Entwicklern – genutzt werden?
- Ermöglicht die Software die simultane Zusammenarbeit aller Team-Mitglieder?
- Kann die Software eine als Laufzeit-Engine operierende Simulation generieren, die exakt wiedergibt, was die Designer beabsichtigt haben und wie es auf der Ziel-Hardware laufen wird?
- Wie viel Zeit benötigt die Software, um statischen Content so umzuwandeln, dass er in der Basisapplikation auf der Ziel-Hardware läuft?
- Gibt es breite Unterstützung für die bevorzugte Entwicklungs-Plattform?
- Lassen sich andere Entwicklungs-Tools anbinden?
- Bietet die Software elementare Standardfunktionen wie etwa zusammengesetzte Ebenen, Transparenzeffekte, Animationen, 3D-Objekte?
- Lassen sich spezielle oder individuelle Designanforderungen durch Unterstützung für kundenspezifische Visualisierung, Rendering und Tooling berücksichtigen?
- Wie gelangen die Daten von der Anwendungsschicht zur Bedienoberfläche und umgekehrt?
- Gibt es eine Abgrenzung zwischen Anwendungsschicht/System und Bedien-Logik?