Prototyping mit ProtoPie: Echtzeit-Datenfunktionalität zur Realisierung eines Automobilprototypen

Anfang des Jahres wandte sich das Start-up-Unternehmen Elexir mit einer einzigartigen Vision eines nachhaltigeren Autos an uns. Sie haben ein hochgradig anpassbares und erweiterbares Shared-Car entwickelt, mit dem Ziel, dass gleiche Erlebnis zu bieten wie ein eigenes personalisiertes Auto. Um dies zu erreichen, haben sie eine vollkommen neue Software-Architektur entwickelt. Durch die Verwendung eines Open-Source-Softwarekonzepts ermöglichen sie es jedem, zu ihrem System beizutragen und geben den Kunden die Möglichkeit, Hardwareelemente zu ersetzen, hinzuzufügen und von weiteren Softwareverbesserungen zu profitieren.

Kick Off

Ich war von der Idee sofort begeistert. Als wir uns dem Projekt anschlossen, hatte Elexir seine Software-Architektur bereits etabliert. Ein neues Auto-HMI von Grund auf zu entwickeln, ist eines der coolsten Projekte, das ich mir vorstellen kann. Außerdem waren sie mit ihrer Entwicklung bereits so fortgeschritten, dass sie die volle Kontrolle über jedes Hardwareelement im Auto hatten! Das Einzige, was noch fehlte, war eine visuelle Darstellung, um Stakeholder von Ihrer Idee zu überzeugen.

Warum Protopie?

Mit dem Schwerpunkt auf Hardware-Integration und Personalisierung wussten wir, dass wir eine fortschrittliche Design-Software benötigten, die weit über die Grenzen statischer Bildschirme hinausgeht. Wir wollten einen Prototypen erstellen, der den Benutzern einen guten Eindruck von unseren Ideen vermittelt, es uns ermöglicht, schnell zu iterieren und in einem extrem kurzen Zeitraum eine Lösung zu finden. Da wir schon früher mit ProtoPie gearbeitet haben und dadurch wussten, was die Software kann, kamen wir direkt zu dem Entschluss, dass dies das beste Tool ist, um diese Aufgabe zu bewältigen. Es war genau das richtige Projekt, um die Möglichkeiten von ProtoPie in Bezug auf Echtzeit-Datenanbindung, mehrere Hardware-Geräte und Bildschirme voll auszuschöpfen. Um unseren Zeitplan einzuhalten, mussten wir auch die Möglichkeit haben, gleichzeitig zusammenzuarbeiten. Durch die Nutzung der fortschrittlichen Komponentenfunktionen und einer separaten Bibliothek konnten wir einzelne Elemente weiterentwickeln und sie anschließend zusammenzufügen.

Design

„Wir wollen das Rad nicht neu erfinden“ (ich denke, in diesem Zusammenhang kann ich dieses kitschige Wortspiel verwenden). Wir haben versucht, den Benutzer nicht zu überfordern, indem wir vertraute Interaktionsmechanismen verwenden und nur die für jeden Anwendungsfall notwendigen Informationen anzeigen, um ein schlankes, minimalistisches Gefühl zu erzeugen. Andererseits wollten wir die Benutzerführung durch dreidimensionale Visualisierungen und direktes Feedback verbessern. Die Idee, visuelle Darstellungen von realen Objekten zu verwenden, um eine breite Palette von Funktionen zu steuern, hat uns fasziniert und die Dinge wirklich in Bewegung gebracht.

Workflow

Selbst bei größerer Skalierung, die im Falle moderner Autos zwangsläufig eintritt, haben wir versucht, schlank zu bleiben. Wir verfolgten einen kontinuierlichen und additiven Ansatz bei der Einführung neuer Komponenten in unsere Bibliothek und versuchten, sie erweiterbar und wiederverwendbar zu machen, damit sie für ein breiteres Spektrum von Anwendungen eingesetzt werden können. Um dies zu erreichen, verfolgten wir den „atomic design“ Ansatz, d. h. wir bauten kleine Komponenten, die schließlich in größeren Organismen verschachtelt wurden.

Um die Wartbarkeit zu gewährleisten, verwendeten wir mehrere Dateien für verschiedene Teile und Ausgabegeräte der Software. Alle Komponenten sind in einer Bibliothek hinterlegt und in den Dateien verlinkt. Anstatt tagelang statische Screendesigns zu entwerfen, definierten wir zusammen mit Elexir eine visuelle Sprache, richteten ein paar Basiskomponenten ein, um sie zu testen und gingen direkt zu ProtoPie über. Unser Workflow war von diesem Zeitpunkt an in drei Entwicklungsphasen unterteilt:

1. Visuelles Design
2. Ankopplung mit Echtzeitdaten durch den OBD port
3. Integration in das reale Produkt zum weiteren Testen und iterieren

Prototyping war schon immer ein wichtiger Teil meines Workflows, denn es hilft mir, Ideen schnell zu visualisieren, zu testen und zu iterieren, ohne dabei zu viel Zeit zu verschwenden. Im Laufe der Jahre habe ich eine Vielzahl von Tools getestet und verwendet, was oft zu Frustration aufgrund von technischen Einschränkungen oder mangelnder Funktionalität führte. Die fortschrittlichen Komponentenfunktionen von ProtoPie ermöglichen es mir, weit über den bloßen Übergang zwischen mehr oder weniger statischen Bildschirmen hinauszugehen. Eine dedizierte Komponentenbibliothek als „single source of truth“ zu haben und UI-Komponenten isoliert zu erstellen und dennoch zwischen ihnen kommunizieren zu können, gibt mir die Flexibilität, die ich bisher nirgendwo anders gefunden habe. Darüber hinaus war die Möglichkeit, alles direkt auf dem Endprodukt mit echter Hardware zu testen, ein absoluter „gamechanger“ für uns!

Fazit und Quick Tips

Unser Ziel war eine dreidimensionale Darstellung des Autos und seiner Komponenten sowohl für das Navigationssystem als auch für die Einstellungen. Die Verwendung von Videos oder statischen Bildern wäre nicht ausreichend gewesen, da wir viel mehr Flexibilität benötigten, um unsere Anforderungen zu erfüllen. Es gibt zwar noch keine Möglichkeit, dreidimensionale Daten in ProtoPie zu integrieren, aber mit seinen Features wie Variablen und Funktionen gibt es fast nichts, wofür man nicht eine Lösung finden könnte. Eine große Hilfe ist auch immer die ProtoPie-Community. Mit einer schnellen Recherche habe ich andere gefunden, die vor dem gleichen Problem standen und bereits Lösungen dafür gefunden haben.

Ich mag das Trigger- und Response System von ProtoPie sehr. Mit Funktionen wie chains, if-conditions, send/response-Funktionen und der Integration von Lottie gibt es nichts, was ich mir mehr wünschen könnte. Aber es kann auch sehr schnell unübersichtlich werden. Ich empfehle jedem, seine Layer zu benennen und das Design weiter zu strukturieren, indem man die Assets in Komponenten aufteilt. Vor allem bei größeren Projekten wie in diesem Fall wäre ich ohne dies völlig verloren gewesen.

Die Leistung ist normalerweise kein großes Problem in ProtoPie. Es scheint mit allem, was ich ihm zuwerfe, gut zurechtzukommen. Zumindest, wenn ein paar einfache Regeln befolgt werden:

• Bilder nicht in einer größeren Auflösung integrieren, als sie ausgegeben werden sollen.
• SVGs anstatt Pixel-Grafiken verwenden, sowie Lottie-Dateien anstelle von Videos.

Abgesehen von der Verwendung von Variablen zum Speichern und Übermitteln von Daten, können Variablen auch bei der Fehlersuche nützlich sein. Oft weiß ich nicht, was genau passiert. Um ein besseres Verständnis zu bekommen, erstelle ich eine Variable und binde den entsprechenden Wert, den ich auslesen möchte, daran.