Es war irgendwie ein eigenartiges Gefühl in einer vollen U-Bahn zu stehen, die in die Station einfährt und dann gehen alle Lichter aus. Nach einer gefühlten Ewigkeit erhellten uns die Lichter und Bildschirme wieder und der Zug setzte sich in Bewegung. Friedrichsstraße angekommen latschte ich natürlich prompt in die falsche Richtung. Google Maps sei danke, 300 Meter weiter drehte ich wieder um.
Der CheckIn der Konferenz war gut organisiert. Vier Schalter denen jeweils gewissen Buchstaben zugewiesen waren. Im gesamten 1. Stock des Maritim Art Hotel sind Kühlschränke mit Getränken zur freien Entnahme verteilt, eine Kaffee Station habe ich auch schon entdeckt. Etliche Aussteller sind da, bei einem habe ich mit Fachliteratur zugeschlagen.
09:30 – How to make Loveliness: an HTML Treasure Hunt
Der erste Vortrag, nach der Einführung war auf Englisch. Ich hoffe das ich mit meinen bescheidenen Kenntnissen das ganze halbwegs richtig zusammenfassen kann. Bruce Lawson ist von Tim Berners-Lee, soweit ich das verstanden habe, überredet worden innerhalb der W3C (World Wide Web Consortium) an den HTML Spezifikationen weiterzuarbeiten. Er selbst sagt von sich, er ist ein HTMLoholic.
Bruce Lawson: https://www.brucelawson.co.uk/
Die Session an sich war sehr lustig, Lawson ist ein aktiver Vortragender, der die Themen immer wieder mit Humor und Witz auflockert.
Er hat unter anderem davon erzählt, dass die erste Webseite full responsive war. Natürlich ohne CSS. Optisch lässt sich drüber streiten.
Exkurs: Was heißt das? Es bedeutet, die Webseite gleicht sich dem Bildschirm an, ohne dass ein horizontaler Scrollbalken erscheint oder die Schrift sich verkleinert.
Wir haben diesen Umstand zunichte gemacht, indem wir Entwickler fixe Breiten, schlechten Kontrast, Schriftarten und Farben benutzen und dem Motto „Pixel Perfect Layout“ folgen. Mangelnde Zugänglichkeit mit der Tastatur, Entfernen von Fokusanzeige gehören hier genauso aufgelistet.
Die Rohmaterialen sind und bleiben JavaScript, HTML5 und CSS3.
Zitat: „They having a beer together!“
Laut Lawsons Erklärung sind die grundlegenden Kenntnisse eines full-stack JS Developer:
– ein fundamentales Verständnis über JavaScript
– Erfahrung eines Front-End Frameworks wie zum Beispiel React
– Bootstrap 4
– HTML/CSS
Mehr Zutaten braucht ein full-stack JavaScript Entwickler nicht.
Meine Meinung: Der Rest kommt von ganz allein. Ich denke jeder halbwegs gute Entwickler brennt darauf, neues auszuprobieren was zwangsläufig dazu führt, dass sich seine Kenntnisse erweitern.
Lawson beschrieb in seinem Vortrag auch rudimentäre Unterschiede zwischen HTML und JavaScript:
HTML ist deklarativ, es ist fehlertolerant und ist abwärtskompatibel.
JavaScript ist nicht deklarativ, es ist NICHT fehlertolerant….
Es kamen einige Beispiele und Ausführungen bei denen Lawson auch den einen oder anderen Lacher erntete.
10:30 – Designing with Code
Jonas Hellwig: https://kulturbanause.de/
Hellwig hat eine eigene Firma hier in Berlin. Er beschreibt sich selbst als Vortragender, Designer und Autor. Seiner Meinung nach drängen zwei Arten von Designtools auf den Markt auf die er im Verlauf seiner KeyNote noch näher eingeht. Grundsätzlich kann man zwei verschiedene Herangehensweisen in den Firmen beobachten. In der einen arbeiten Designer und Entwickler getrennt voneinander, in der anderen arbeiten sie gemeinsam an den Projekten. Er selbst ist ein Fan von Visual Coding. Soll heißen, mit visuellen Tools coden. Habe ich persönlich so auch noch nie gesehen.
Wer gestaltet Webseiten: Typografie & Visual Design werden meist nach dem Motto Pixel Perfect gestaltet, was jedoch nicht realistisch ist. Zeilenumbrüche verhalten sich in den unterschiedlichen Browser immer anders, Schriften werden unterschiedlich gerendert, usw. Als Designer muss man für ein responsive Layout immer Varianten machen für die einzelnen Displaygrößen. Das jedoch erzeugt Interpretationsspielraum beim Entwickler, da nicht ersichtlich ist, wie sich einzelne Elemente beim Umbrechen verhalten oder wie Interaktionen bei zum Beispiel Buttons angedacht sind. (zB.: ändert sich die Farbe des Buttons wenn ich mit der Mouse drüber fahre? Wenn ja, blendet es sich weich oder hart um? usw…). Designer arbeiten meist mit Lorem Ipsum Daten, die mit den echten Daten oft nicht viel gemein haben. Es sieht zwar am Designvorschlag gut aus, wenn die Schrift neben dem Bild positioniert ist, aber wehe die Schrift hat statt 150 Zeichen 300 Zeichen. Dann bricht das Layout. Somit ist hier eine Devise mit Daten, die ich selbst nicht steuern kann, arbeiten. Also layouten mit echten Daten. Ein weiterer wichtiger Punkt hier ist die Performance. Sie ist wichtig für Suchmaschinen und für die User Erfahrung. Als Designer kann man das nicht wirklich berücksichtigen. Das sind Dinge, die man erst im Browser wirklich testen kann.
Sollen Designer coden oder Developer gestalten? Berechtigte und eine grundlegende Frage. Laut Hellwig würde es schon reichen ein gegenseitiges Verständnis der verschiedenen Disziplinen die aneinander grenzen zu haben. Dann muss der Developer nicht designen und der Designer nicht coden.
Ein kulturelles Problem in der Wirtschaft ist jedoch immer noch, das Abteilungen immer noch getrennt sind. Agile Design/Dev-Workflows sind oft nur Fassaden. In der Praxis nach außen geben sie an Agil zu sein aber nach innen hin arbeiten die Abteilungen immer noch getrennt. Je weiter Designer und Entwickler voneinander getrennt sind auf kommunikativer Ebene desto schlechter funktioniert die Zusammenarbeit und somit die Entwicklung.
Durch das trennen malen Designer nur noch Bilder, viele verstehen dadurch das Produkt nicht mehr und gestalten somit nicht das finale Produkt. Hellwig erklärt, das Designer es schwierig finden etwas zu gestalten, dass auf den unterschiedlichen Devices unterschiedlich aussieht. Hier setzen verschiedenste Tools an.
Letzendlich gestalten die Developer. Sie entscheiden wie sich die Webseite verhält bei Breakpoints und welche Animation auf zum Beispiel Buttons angewendet werden.
Ab hier stellt Hellwig verschiedenste Tools vor
Tools Hand-off:
– Marvel
– Invision
– Zeplin
– Avocode
– Abstract
Tool für die Übergabe von Designer zu Developer bzw. Tools die Code Production Ready Exportieren:
– Supernova
– Anima Toolkid (Plugin Sketch Export Sketch to HTML)
– Sketch 2 React – basiert auf Bootstrap (sollte mich selbst endlich mal mit Sketch beschäftigen)
Data
– Sketch (Daten können rein gerendert werden. Daten automatisiert laden)
– Adobe XD
Workflow #2
Code ist das Herzstück des Produkts, Designer verstehen mit diesen Tools das Produkt besser und gestalten nun auch wieder das Endprodukt, Entscheidungen können im Kontext des Ziel-Mediums getroffen werden und Einschränkungen bei der Umsetzung werden verstanden
weitere Tools:
– Webflow.com
– Frontpage
Tools für Visual Coding
– Framer X (React Projekt)
– UX Pin Merge auf Basis von GitHub
– Interplay
– Modules
Mit diesen Tools generiert Code wieder die Benutzerschnittstelle und nicht die Schnittstelle den Code
react-sketchapp von Airbnb entwickelt stellt Hellwig auch noch vor: Code als „Single source of truth“
Interessanter Link für Platzhalter Elemente den ich aufgeschnappt habe ist placehold.it
Abschließend noch die Frage: Entwickeln sich die Browser zum Design Tool oder die Design Tools zum Browser
Etwas, das man sich unbedingt ansehen sollte laut Hellwig: frankchimero.com – What Screens want oder The grain of the web
11:45 – Atomic Design in responsive Design
Um zu verstehen was Atom Design ist, hier ein interessanter Artikel:
https://t3n.de/news/atomic-design-baukastensystem-721010/
Der Vortrag von Marija Zaric war wieder auf Englisch.
„We are not designing pages, we are designing systems of components.“
Die grundlegenden Elemente von Atom Design sind:
- Atome sind die kleinsten Bausteine einer Seite (HTML-Tag oder ein Font)
- Molekül: sind zum Beispiel die Navigation, das Logo mit Link, Atome sind mit Moleküle verbunden und erschaffen diese. Es sind somit Komponenten. Es ist ein Konglomerat merere Atome, die gemeinsam eine Aufgabe lösen (Bsp.: HTML Formular)
- Organismus: Moleküle erschaffen komplexe Organismen. Es sind die Module einer Webseite. Mehrere Moleküle spielen zusammene eine zielgerichtete Rolle. Beispiel auf einer Webseite wären Seitenheader oder Footer, der Bereich mit aktuellen News
- Templates: sind die Vorstufe der eigentlichen Page.
- Pages: ist die fertige Webseite
Die Devise hier ist: Think simple and forget Mockups. Designing in the Browser </>{} with HTML, CSS and Frameworks like Bootstrap.
Zaric geht davon aus, das Atomic Design die Zukunft des Web Designs ist.
Ihre Anleitung hierzu ist:
Process: Designing in the browser: HTML, CSS
Using Responsive Frameworks: great design systems (bootstrap)
Testing from Components: In devices/browsers
Sending tested Templates: as HTML demos to the clients
Finished Website: pages
Recycling: the project as the templates for the future projects
1. Listen, 2. Discover, 3. Concept
Nach diesem Vormittag ist bis 14 Uhr mal Pause. Das Mittagessen war nicht schlecht.
See ya later 😉
