Prototyping im Browser

Das Prototyping von Animationen und Interaktionen ist aus einer Reihe von Gründen entscheidend: Es kann Ihre Benutzeroberfläche trügerisch schnell erscheinen lassen, es kann dem Benutzer helfen, sich auf eine bestimmte Aufgabe zu konzentrieren, und es kann ein besseres Gefühl für den aktuellen Zustand Ihrer Anwendung vermitteln. Werden Daten geladen? Ist etwas jetzt unklickbar? Wie lange müssen sie warten, bis sie eine Aktion ausführen können?

Bei Gusto habe ich in letzter Zeit aus genau diesen Gründen an vielen kleinen Interaktionsdetails und Prototypen gearbeitet – leider kann ich Ihnen im Detail noch nicht viel zeigen. Aber ich denke, der *Prozess*, wie ich das mache, ist viel interessanter als das, woran ich gerade arbeite, und das werde ich hier teilen.

Das Problem, mit dem ich beim Prototyping von Animationen konfrontiert war, liegt bei den Tools, da sie sich für mich letztendlich einschränkend anfühlen. Immer wenn ich in der Vergangenheit damit experimentiert habe, hatte ich das Gefühl, dass eine Hand immer hinter meinem Rücken gefesselt war. Es mag sein, dass ich sie nicht richtig benutze, aber ich habe das Gefühl, dass keine von ihnen das Browserverhalten wirklich richtig nachahmt, und obwohl ich fasziniert war, wie Tools wie Framer, Marvel, Zeplin und Principle an Bedeutung gewinnen, glaube ich nicht, dass sie etwas für mich sind. Zumindest noch nicht.

Meiner Meinung nach ist der beste Weg, um viele Interaktionen zu prototypen, immer noch pures HTML, CSS und (Gaskraft!) ein Hauch von jQuery, wenn ich es brauche.

Wie ich heute prototypisiere

Bei meinem letzten Projekt habe ich beschlossen, ein wenig Zeit in CodePen zu investieren, um unser Designteam bei der schnellen Prototypisierung zu unterstützen. Hier ist, was ich gebaut habe

Sehen Sie den Pen Gusto Prototype: Header von Robin Rendle (@robinrendle) auf CodePen.

Nein im Ernst, das ist alles. Es ist nur ein einfacher Prototyp, der wie unsere App aussieht.

Es ist ein Pen mit dem gesamten HTML für die App-Navigation – und er enthält auch das gesamte CSS. Auf diese Weise kann ein Designer bei Gusto diesen Pen forken und mit dem Schreiben von HTML und CSS beginnen, um mit einem bestimmten Teil der UI zu experimentieren, ohne den zusätzlichen Druck, Produktionscode schreiben zu müssen. Es ist wichtig zu beachten, dass dieser Prototyp nicht dazu dient, die UX zu ermitteln, da Tools wie Figma und Sketch dies wesentlich besser tun. Prototypen wie dieser sind meist nützlich, wenn es darum geht, knifflige UI-Interaktionen wie Tabellen, Kalkulationstabellen und Dropdowns zu ermitteln – Komponenten, die schnell kompliziert werden können.

Um diesen Prototyp zu erstellen, habe ich einfach das gesamte HTML und CSS aus unserer Web-App kopiert und in einen neuen Pen eingefügt. (In Zukunft sollten wir wahrscheinlich ein System haben, bei dem wir immer mit dem aktuellsten Code aus unserer App prototypisieren, aber im Moment denke ich, dass dies ein guter Ausgangspunkt ist.) Dieser Pen enthält alle Menü- und Navigationspunkte, die wir benötigen, damit er wie die Gusto-App aussieht. Wir haben einen separaten Pen für den Footer, der alle Divs schließt, die wir im Header öffnen. Schließlich haben wir noch einen weiteren Pen, der diese beiden anderen Pens importiert, so

<!-- HEADER -->
[[[http://codepen.io/robinrendle/pen/481a88853820067752e28cdb479c91f3]]]

<!-- HTML GOES HERE -->
<h1>App Prototype</h1>
<p>You can fork this pen and write all the HTML and CSS you need to prototype interactions and explore ideas right here in your browser.</p>

<!-- FOOTER -->
[[[http://codepen.io/robinrendle/pen/0dcaa93954f06f4d03b7e23e8ea54cac]]]

Sehen Sie den Pen Gusto Prototype: Full von Robin Rendle (@robinrendle) auf CodePen.

Was ist das seltsame Syntax mit den [[[ ]]]? Das ist die HTML Include Syntax für CodePen. Wenn wir die URL eines Pens zwischen diese Klammern setzen, ruft CodePen den Code aus diesem Pen ab und fügt ihn direkt in diesen neuen Pen ein. Das ist alles! Ziemlich schlau, oder?

Um das Ganze abzurunden, möchte ich ein paar Anmerkungen zu dem machen, was ich mit diesem neuen Setup gelernt habe.

Lektion 1: Prototypen sollten super einfach zu teilen sein

Idealerweise sind Prototypen einfach mit anderen Designern und Entwicklern zu teilen, extrem schnell einzurichten und erfordern keine Vorkenntnisse oder Expertise – und Codepen ist dafür perfekt. Ich mag dieses Setup aus vielen Gründen. Erstens müssen wir Designern kein CoffeeScript beibringen, wie wir es bei Framer tun müssen, und wir müssen keine React- oder Vue-Workshops veranstalten, um sie mit einer komplexen Prototyping-App zum Laufen zu bringen.

Ja, die Leute müssen lernen, wie HTML und CSS funktionieren, um solche Prototypen zu erstellen, aber ich denke, das Erlernen der absoluten Grundlagen dieser beiden Sprachen ist für einen Designer, der im Web arbeitet, sowieso unerlässlich.

Lektion 2: Schlechter Code ist in Ordnung

Hier ist noch etwas, das ich kürzlich beim Prototyping gelernt habe: **Schlechter Code ist in dieser Phase in Ordnung**. Tatsächlich *sollten* wir schrecklichen, unverzeihlichen Code schreiben, wenn wir im Browser prototypisieren. Wir sollten die Art von CSS und HTML schreiben, die Harry Roberts nachts wach halten würde, denn sauberer, wartbarer Code behindert den Designprozess, wenn der Fokus darauf liegen sollte, so schnell wie möglich zu iterieren.

Um ganz ehrlich zu sein, ist mir bei der Erstellung dieser Prototypen die Einhaltung von Frontend-Best-Practices egal – ich denke nicht an BEM, semantisches HTML oder gar Performance. Oh, und ich kümmere mich schon gar nicht um die professionellste Art, ein React-Dingens zu rendern.

Solange wir all diesen Prototyp-Code verwerfen und später von Grund auf neu beginnen, und solange es einen Schritt gibt, um das Design in Komponenten zu zerlegen und sicherzustellen, dass diese Legosteine in unserer Produktionsumgebung wartbar, gut dokumentiert und hochperformant sind, dann glaube ich, dass das Schreiben von schlechtem Code nicht nur erlaubt, sondern aktiv gefördert werden sollte.

Das führt zu meinem letzten Fazit.

Lektion 3: Designer und Entwickler sollten ihren Code immer übersetzen

Ich schätze, dass der Code, den ein Designer und/oder Frontend-Entwickler zum ersten Mal schreibt, niemals in einer Produktionsumgebung landen sollte. Der Spielraum und die Freiheit, mit dem Code in einer sicheren Umgebung verrückt zu spielen, konzentrieren Ihre Aufmerksamkeit auf das Design und dessen Kompatibilität mit den Einschränkungen eines Browsers. Danach können Sie sich überlegen, wie Sie den Code von einem heißen, dampfenden Haufen Müll zu schöner, blitzsauberer, produktionsreifer Poesie verfeinern. Die Umwandlung der statischen Mockups in einen interaktiven Prototyp ist der erste Schritt, aber es ist entscheidend, einen nächsten Schritt zu haben, um Ihre Codestandards durchzusetzen.

Verwendet Ihre App BEM? Wie sollten Sie jede dieser Komponenten in separate Dateien abstrahieren? Wie nennen Sie all diese neuen Komponenten, die Sie in das Designsystem einführen?

Ich glaube, all diese Fragen lassen sich leichter beantworten, sobald Sie diesen interaktiven Prototyp haben. Und ich kann Designern und Frontend-Entwicklern gleichermaßen nur wärmstens empfehlen, mit der Erstellung kleiner Tools wie diesem zu experimentieren. Es mag sich anfangs etwas seltsam anfühlen, aber ich verspreche, dass es auf lange Sicht zu viel besseren Ergebnissen führen wird.