Coding für Designer, Teil I

Warum DesignerInnen auch coden sollten

Profilbild von Christian Al-Mosawi

Christian Al-Mosawi

Ohne Grafiksoftware geht’s auch bei uns nicht, keine Frage. Und das obwohl wir sehr viel fürs Web arbeiten. Wir lieben zum Beispiel Sketch 💎 und Affinity Designer, aber manchmal muss einfach ein anderes Werkzeug her: HTML & CSS for the rescue! 🤓

N-210 STOLAND Simulation: EAI 8400 Aircraft Simulation.
Photo: NASA/Ames Research Center archive.org

Erstmal keine Panik! Das Feld der Webentwicklung ist zwar potenziell unendlich, aber ein wenig Überblick und ein paar Skills im Umgang mit HTML und CSS können dir schon neue Welten eröffnen – gerade wenn du mit WebentwicklerInnen zusammenarbeitest.

Dieser Post beleuchtet warum und wann es sinnvoll ist, sich als DesignerIn mit Webentwicklung zu beschäftigen. In späteren Beiträgen geht’s dann weiter ins Detail und ich vermittle euch ein paar Kniffe, die mir als Gestalter geholfen haben.

Wenn du nur für’s Web gestaltest, ist das hier vielleicht ein alter Hut 🎩. Für die Allround-KollegInnen zwischen analog und digital öffnet sich aber vielleicht das ein oder andere Türchen.

Warum nicht „Programmieren für Designer“?

Gute Frage, schließlich nennen sogar viele unserer Kunden, alles was wir an der Umsetzung einer Website erledigen Programmierung.

Das trifft zwar auf einen Teil der Webentwicklung zu, auf einen großen Teil aber auch nicht. Programmierung impliziert, dass hier irgendeine Logik abläuft: Wenn dieser Wert größer ist als x, erledige y.

Wenn ich als Designer Code benutze, dann verbringe ich sehr viel Zeit mit den Beschreibungssprachen HTML und CSS. Dort gibt es keine Programmlogik, der Code lautet eher Die Headline h3 lautet „x“ (HTML) und hat die Schriftgröße 24px (CSS).

Sobald wir Buttons benutzen, die etwas anderes tun als auf eine andere Seite zu verlinken braucht es wieder ein wenig Logik. Da kommt dann meistens JavaScript ins Spiel: Wenn dieser Button geklickt wird, öffne das Menü.

Auch ohne Programmierung, nur mit HTML und CSS, gibt es für DesignerInnen aber genug zu entdecken. In dieser Serie geht es daher um den Code, der das Aussehen (statisch und animiert) einer Website beschreibt.

Eine gemeinsame Sprache entwickeln 💬

Letztendlich funktioniert die Zusammenarbeit zwischen DesignerIn und WebentwicklerIn am Besten, wenn sich beide auf Augenhöhe unterhalten können. Das ist gleichzeitig auch die Kultur, die wir in unserem Büro leben und mit der wir gute Erfahrungen gemacht haben.

Ein Beispiel

Wenn der Zeilenabstand irgendwo im aktuellen Webprojekt noch nicht ganz sitzt, ist es ein leichtes mal eben in den Entwicklertools eures Browsers auszuprobieren, was am besten passt. Diese Info ist für beide Seiten viel hilfreicher als langes Pingpong per Mail.

Die Entwicklertools könnt ihr in den meisten Browsern mit ⌥⌘I (Mac) oder Ctrl⇧I (Windows) öffnen.

Die gesparte Zeit könnt ihr bestimmt an anderer Stelle besser nutzen.

Schneller Animationen ausprobieren 🚀

In Sachen Software für Screen Design hat sich in den letzten Jahren glücklicherweise recht viel getan. Und trotzdem sind die Artboards egal ob in Sketch, Figma oder XD alle recht statisch. Mit den Prototyping Features moderner Software bekommt man schon einen etwas besseren Eindruck, wie sich die finale Website oder App anfühlen könnte. Die kleinen bewegten Elemente, die ein Interface lebendig machen, kann man mit diesen Programmen aber nicht simulieren.

Alles in AfterEffects nachzubauen wäre vermutlich Overkill. Hinzu kommt, dass Objekte im Browser anders animiert werden und es mühsam wäre diese Animationen noch einmal nachzubauen. Nur Regieanweisungen für die Animation eines Buttons an die EntwicklerInnen weitergeben hilft aber auch nicht wirklich. Natürlich wird das Timing nie so sein, wie ihr es euch vorgestellt habt. Und schon sind wir wieder beim Pingpong-Spiel.

Codepen
https://codepen.io/ericadamski/pen/ZBxavq

Glücklicherweise müsst ihr nur ein bisschen CSS verstehen um eure Buttons selbst zu animieren. Und von null müsst ihr auch nicht anfangen. Auf Codepen gibt es tausende Beispiele, die ihr dazu auch noch eben schnell im Browser modifizieren könnt. Oft reicht es ja, einige Details ausprobiert zu haben um besser sagen zu können, wie man sich die Umsetzung wünscht.

Typografie im Web

Im Browser geht typografisch mittlerweile einiges, manches versteckt sich aber in den Untiefen von CSS. Natürlich gibt es auch einige Limitierungen, aber gerade deswegen ist es sinnvoll selbst rumprobieren zu können.

Für die 404-Fehlerseite dieser Website wollten wir eine kaufmännische Null mit diagonalem Strich haben. Während das in Sketch nur über einen Umweg geht, muss man im Browser nur das richtige CSS-Attribut parat haben: font-feature-settings: "zero";

Wenn der Browser keine OpenType Features unterstützt, tut es praktischerweise niemandem weh wenn die reguläre Null zu sehen ist. Ja, ich spreche mit euch, Opera Mini-Benutzer 👋. Diese Strategie heißt übrigens Progressive enhancement und sie stellt sicher, dass Nutzer älterer Browser und Geräte alle Inhalte angezeigt bekommen, aber nicht notwendigerweise in der poliertesten Variante.

Exkurs

Bei mir geht’s aber … 🤔

Welches Feature in welchem Browser funktioniert oder nicht funktioniert, könnt ihr am besten auf caniuse.com herausfinden.

Browsertests ersetzt das natürlich nicht, aber ihr bekommt einen sehr guten ersten Eindruck.

Typodetails in längeren Fließtexten gestalten

Fließtexte sind ein anderer Fall, bei dem ihr euch das Leben leichter macht, wenn ihr im Browser gestaltet.

Schon bei Kleinigkeiten wie Linkunterstreichungen wird’s in manchen Grafikprogrammen schnell kompliziert. Standardunterstreichungen gehen zwar in Sketch, das Aussehen könnt ihr aber nicht beeinflussen (Strichstärke, Farbe, Abstand zum Text). Der Workaround wäre also vielleicht eine Linie von Hand zu ziehen. Hilft leider aber nur so lange man die Typo danach nicht mehr anfasst. Sobald sich Schriftgröße, Zeilenabstand oder Spaltenbreite ändern, steht die Linie verwaist im Nirgendwo.

Weitere Absätze, Headlines oder Einschübe wie Zitate wären üblicherweise neue Textfelder. Auch diese stehen an falschen Positionen, wenn sich die Objekte darüber ändern. Einheitliche Abstände vor und nach Headlines einzuhalten wird zur Sisyphos-Aufgabe. Im Fließtext selbst ein Wort ganz anders auszeichnen? Einfach nur schmerzhaft 😬

Hier hilft euch die Arbeit im Browser enorm weiter! Wie das konkret geht, verrate ich in zukünftigen Beiträgen.

Es gibt sicher noch eine Tonne weiterer Gründe warum sich Designer mit HTML & CSS auskennen sollten. Das hier waren ganz subjektiv die Themen, die mir in meinem Design-Alltag die meisten Schmerzen ersparen.

Wenn ihr Fragen und Ergänzungen habt, schreibt uns doch einfach! 🎉 Wir freuen uns auf euer Feedback!