Konventionen für die Erkennung von Wireframe-Objekten durchsetzen

Viele großartige Ideen entstehen auf einem Blatt Papier oder an einer Tafel. Warum? Weil das Zeichnen von Hand nach wie vor die natürlichste, intuitivste und effizienteste Art ist, abstrakte oder visuelle Gedanken zu strukturieren. Trotz aller Bemühungen, sich an die digitale Welt anzupassen, arbeiten Menschen in analogen Situationen oft immer noch besser.

Ausgehend von dieser Beobachtung haben wir uns auf einen konkreten Anwendungsfall konzentriert: die automatische Generierung produktionsreifen Codes aus handgezeichneten Wireframes. Wir sind überzeugt, dass ein digitaler Proof of Concept, der direkt aus einer Gesellschafterversammlung hervorgeht, inzwischen keine ferne Zukunftsvision mehr ist.

Wie in diesem früheren Artikel erläutert, möchten wir künstliche Intelligenz (KI) und maschinelles Lernen (ML) an verschiedenen Stellen unserer Plattform einsetzen. Wir wissen jedoch, dass ML zumindest derzeit nicht jedes Problem lösen kann. Unsere Vision-API ist Teil eines größeren Ökosystems und kümmert sich „nur“ um die Erkennung von Begrenzungsrahmen. Diese Rohdaten müssen anschließend in eine Darstellung in der User Interface Definition Language (UIDL) umgewandelt werden. Danach übernehmen unsere Codegeneratoren und einige proprietäre Entscheidungsebenen die Codegenerierung.

Screenshot und Wireframe von Stackoverflow.com

Datenbedarf#

Auf den ersten Blick wirkt das Problem für Datenwissenschaftler ganz einfach: Wir haben Bilder oder Scans von Wireframes, die annotiert sind, sodass wir wissen, wo sich Elemente wie Bilder, Schaltflächen und Texte befinden. Klingt unkompliziert – suchen wir also einfach online nach Bildern und annotieren sie später.

Einige Wireframes, die wir im Internet gefunden haben

Zu Beginn beschlossen wir, kostenlose Daten aus dem Internet zu sammeln. Das reichte aus, um einen groben Eindruck von der Art der Daten zu bekommen, mit denen wir arbeiten würden. Gleichzeitig wurde uns aber klar, dass diese Quelle nicht genügend Bilder liefern konnte, um ein Modell für maschinelles Lernen zu trainieren. Dann stießen wir auf ein zweites Problem: Niemand verwendete beim Zeichnen von Wireframes dieselben Konventionen … Tatsächlich lernten wir später beim Sammeln der Daten, dass es in jeder Organisation oft eigene Richtlinien gibt.

Um diese ersten Probleme zu lösen, legten wir eigene Richtlinien fest und begannen, selbst Wireframes zu zeichnen. Nachdem alle Teammitglieder ihren Beitrag geleistet hatten, beschlossen wir, unsere Daten im Freundeskreis zu sammeln, und baten unsere (großartigen!) Freunde, ebenfalls Wireframes für uns zu zeichnen. Bei größeren Datenmengen ist das sicher keine praktikable Strategie, denn die Zahl der Freunde ist begrenzt. So erhielten wir jedoch zunächst eine einheitliche Sammlung handgezeichneter Wireframes.

Unsere aktuellen Richtlinien zum Zeichnen von Wireframes

Wir hatten das X, aber das Y fehlte noch#

Die einfachste Vorstellung von maschinellem Lernen ist, dass der Computer selbst eine Funktion erlernt, mit der er anhand einer großen Zahl von Beispielen Y aus X vorhersagt. Zu diesem Zeitpunkt hatten wir bereits einige Hundert Bilder gesammelt – das X war also vorhanden. Wir wussten, dass dies für einen Machbarkeitsnachweis ausreichen würde, und machten uns an den nächsten Schritt: die Annotationen, um das Y zu erhalten.

Wir begannen, jedes gezeichnete Wireframe von Hand zu annotieren, um genau zu markieren, wo sich Bilder, Schaltflächen und Texte befanden. Es versteht sich von selbst, dass diese Aufgabe nicht gerade der angenehmste Teil des Vorhabens war. Doch im Leben gibt es nichts umsonst, also bissen wir die Zähne zusammen und legten los.

In unserem Fall war der Prozess recht lang. Er begann mit einigen eher zufälligen Arbeiten an Chatbots und dialogorientierten Benutzeroberflächen. Damals, im Jahr 2015, arbeiteten die meisten von uns noch in der JavaScript-Abteilung bei Evozon. Die Arbeit ging nie in Produktion, doch wir blieben alle begeistert: Sie eröffnete viele neue Perspektiven dafür, wie wir neue Benutzererlebnisse gestalten könnten. Der positive Aspekt war, dass alle Teammitglieder den wahren Wert sauberer und strukturierter Daten voll zu schätzen lernten – einer äußerst knappen Ressource, die bei den meisten Data-Science-Projekten einen Engpass darstellt.

Der Bedarf an einheitlichen Daten#

Nachdem wir sowohl X als auch Y hatten, konnten wir endlich mit dem spannenden Teil beginnen: dem Training des Modells. Das dauerte viel kürzer als die Datensammlung, und das Ergebnis war natürlich, dass wir mehr Daten brauchten!

Dennoch erhielten wir damit einen Machbarkeitsnachweis und eine sehr gute Ausgangsbasis für weitere Verbesserungen. Die Genauigkeit des Modells lag bei 55 % auf unserem Testsatz. Das bedeutet, dass 55 % der Elemente korrekt erkannt wurden.

Abgesehen von der geringen Anzahl an Datenpunkten wurde uns dabei klar, dass wir uns einer neuen Herausforderung stellen mussten: Bei der Annotation gab es zahlreiche Überschneidungen. Einige Annotationen waren sogar für Menschen mehrdeutig:

• Ist es ein Bild oder eine Schaltfläche?
• Ist es eine Überschrift oder ein Absatz?
• Ist es ein Texteingabefeld oder eine Schaltfläche?

In manchen Fällen, etwa bei Überschriften und Absätzen, konnte die Grundstruktur des Wireframes bei der Entscheidung helfen. In vielen anderen Fällen ließ sich der Unterschied jedoch nicht erkennen. Somit gab es auch keine Möglichkeit, das Modell korrekt zu trainieren.

Links ein von einem Nutzer hochgeladenes Wireframe, rechts ein Wireframe aus unserem Trainingsdatensatz

Notwendigkeit klarerer Richtlinien#

Wie bei vielen technischen Herausforderungen besteht der schwierigste Teil darin, zunächst eine solide Grundlage zu schaffen, auf der man aufbauen kann. Beim maschinellen Lernen ist das nicht anders. In unserem Fall bedeutete eine solide Grundlage, klare Einschränkungen dafür festzulegen, was und wie das Modell die Absicht des Nutzers erkennen kann. Auch wenn wir unsere Fähigkeiten später hinsichtlich der Vielfalt der Elemente und der zeichnerischen Freiheit erweitern möchten, beschränken wir uns vorerst auf die folgenden Konventionen, von denen viele von Markdown inspiriert sind:

• Überschrift: Da sie mit einem Absatz verwechselt werden kann, schlagen wir vor, ihr ein Rautenzeichen voranzustellen.
• Texteingabefeld: Da es mit dem Schaltflächenelement verwechselt werden kann, schlagen wir vor, nur ein leeres Texteingabefeld zu verwenden.
• Link: Wir setzen ihn in eckige Klammern
• Beschriftungen: werden nur dann als solche erkannt, wenn sie einem Eingabefeld zugeordnet sind
• Absatz: Ist der Text weder eine Beschriftung noch eine Überschrift oder ein Link, handelt es sich um einen Absatz
• Bild: darf nur ein Rechteck oder ein Kreis mit einem Kreuz darin sein

Unsere zukünftigen Richtlinien für das Zeichnen von Wireframes

Es war keine leichte Entscheidung, aber wir sind überzeugt, dass die von uns eingeführten Einschränkungen wichtige Vorteile mit sich bringen, die die Nachteile aufwiegen, zum Beispiel:

• Ist es ein Texteingabefeld oder eine Schaltfläche?
• Ist es ein Bild oder eine Schaltfläche?
• Die Anmerkung unmissverständlich formulieren

Fazit#

Unsere Vision-API folgt vorerst noch den alten Richtlinien, aber in unserer nächsten Version (die in Kürze erscheint) werden wir die neuen verwenden. Wie immer möchten wir unsere Leser daran erinnern, dass es sich um laufende Arbeit handelt und noch lange nicht alles perfekt ist. Wir freuen uns jedoch über jedes Feedback und jede Idee, wie wir unsere Vision-API verbessern können. Schreiben Sie uns jederzeit über unseren Twitter-Account und folgen Sie uns, um über unsere nächsten Updates auf dem Laufenden zu bleiben.