Working Draft

Wöchentlicher Podcast für Webdesigner:innen und -entwickler:innen

Unterstützung

Wir optimieren unser Audio mit Auphonic, wo ihr uns Processing-Time kaufen könnt! Alternativ findet Ihr uns auch auf Patreon:

Become a Patron!

Werben bei Working Draft!

Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft der etablierteste Podcast für Webentwickler im deutschsprachigen Raum. Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler anbietet, schreibt uns unter sponsoring@workingdraft.de.

Revision 609: Farbsehschwäche und Farbblindheit

19. März 2024 | Keine Kommentare

Gast Markus Stahmann klärt in dieser Revision über Farbsehschwäche und Farbblindheit auf. Markus ist 1. Vorsitzender des Interessenverbands der Farbsehschwachen und Farbenblinden (der die hervorragende Webseite farbsehschwaeche.de betreibt) und außerdem Webentwickler bei New Data Services, was ihn zu einem einmaligen Kompetenzknäul für uns macht!

Schaunotizen

[00:02:21] Farbsehschwäche und Farbblindheit
Wie beginnen mit den Grundlagen (Definition, Entstehung und Häufigkeit der Farbfehlsichtigkeiten) und steigen danach sogleich in Alltagsbeispiele ein. Bananen stellen sich als ein größeres Problem als der Straßenverkehr heraus, Luft- und Wasserstraßen bleiben für die Farbefehlsichtigen durch den Lanterntest gleich ganz gesperrt. Best und Worst Practices in Web und Webentwicklung kommen natürlich auch nicht zu kurz; wer die drei Regeln einhält, ist meist schon ganz gut aufgestellt. In Hinblick auf das Big Picture kauen wir mögliche Effekte des European Accessibility Act durch und überlegen wie wir in ganz alltäglichen Web-Projekten Farbsehschwächen-Kompatibilität erhöhen können.
Transkript

Revision 608: Nuxt & UnJS

12. März 2024 | Keine Kommentare

Diese Revision wollten wir uns mit Nuxt und UnJS befassen und haben uns als Gesprächspartner Alexander Lichter (LinkedIn / Mastodon / Twitter) eingeladen, der sich nicht nur als Web-Engineering-Consultant, Trainer und VideoStreamer betätigt, sondern auch Mitglied der Nuxt- und UnJS-Teams ist.

[00:02:18] Nuxt
Nach einem kurzen Vorgeplänkel zu Vue.js wechseln wir sogleich zu Nuxt, das wie Next.js ein sogenanntes „Meta-Framework“ darstellt, nur dass es eben Vue nutzt, anstelle von React. Neben Nuxt gibt es noch Quasar, das ebenfalls auf Vue setzt.

Allen Meta-Frameworks ist gemein, dass sie eines der clientseitigen Templating-Systeme nehmen und sie um serverseitige Funktionen ergänzen. Die wichtigste davon: Das Routing-System.

Darüberhinaus ermöglichen Meta-Frameworks wie Nuxt es, statische Seiten zu erzeugen, die im Client ganz ohne JavaScript auskommen. Da unterscheiden sie sich von Konzepten wie den Server-Components von React, die es ledigleich ermöglichen, einzelne Komponenten vom Server rendern und refreshen zu lassen, das Frontend aber weiterhin im Browser orchestrieren.

Wir reden über die aktuellste Version von Nuxt und wie diese bei ihrem Release von der Community aufgenommen wurde. Und wir blicken nach vorne auf die kommende Version 4, die demnächst erscheinen soll. Anders als nach Version 3 ist hier nicht mit großen Breaking Changes zu rechnen. Für einen Vorgeschmack auf die Änderungen können aber jetzt schon in Nuxt 3 entsprechende „Future Flags“ aktiviert werden. Und für eine reibungslose Migration auf Version 4 gibt es dann noch sogenannte Codemods, die bestehenden Code für das neue Framework automagisch umschreiben.

[01:06:18] UnJS
An dieser Stelle schwenken wir um auf das Thema UnJS, welches eine Sammlung von kleinen und großen JavaScript-Helferlein ist. Zum ersten Mal hörten wir von UnJS von Joe Ray Gregory Anfang 2023, lernen aber erst jetzt, dass dies ebenfalls ein Projekt aus dem Vue-Kosmos ist.

Viele dieser Helferlein sind nämlich Spin-Offs von Projekten aus der Vue-Welt, von denen man aber annahm, dass sie auch für andere Projekte hilfreich sein könnten. Ein Beispiel ist der Webserver Nitro, der so etwas wie ein modernes Express + Connect darstelle und der nicht nur in Nuxt Verwendung findet, sondern auch in Analog.js, dem Meta-Framework für Angular.

Ein weiteres spannendes Paket ist Unplugin, das eine Art universelles Bindeglied zu allen existierenden Bundlern darstellt und einem so ermöglicht, ein Plugin leicht in jede Build-Chain zu integrieren.

Magic-Regexp ermöglicht es wiederum, Reguläre Ausdrücke in menschlicherer Sprache zu formulieren.

Dann gäbe es da noch ufo, das allerlei Tooling rund um das Verarbeiten von URLs bietet.

Und schließlich fontaine, mit dem sich aufeinander abgestimmte Schriften-Stacks erstellen lassen.

Zum Abschluss geht nochmal zurück zu Nuxt und Alex gibt uns gute Tipps für den Einstieg und nennt ein paar Stolperfallen, die man bei der Arbeit mit Nuxt besser vermeidet. Und wir behandeln auch die Frage, wo man sein Nuxt-Projekt am besten hostet. Neben Digital Ocean lautet Alex‘ Tipp hier: fly.io

Transkript

Revision 607: Design-Systeme im Jahr 2024

5. März 2024 | Keine Kommentare

Nach rund anderthalb Jahren, in denen wir uns mit dem Thema nicht mehr dediziert befasst haben, haben wir uns erneut Jonas Ulrich (Twitter / LinkedIn) und Daniel Ley (Twitter / LinkedIn) von kickstartDS in die Sendung eingeladen, um mit ihnen über den Stand der Dinge in Sachen Design-Systeme zu sprechen.

Schaunotizen

[00:01:31] Design-Systeme im Jahr 2024
Was wir in unserem Gespräch zunächst einmal feststellen, ist dass die Bedeutung von Design-Systemen stetig zuzunehmen scheint. Gefühlt ist das Ganze vor 10 Jahren langsam bei den ersten großen Playern losgegangen, und mittlerweile gibt es sie überall. Wir vermuten, das hat ganz stark mit Tools wie React und Figma zu tun, die Design-System-freundliche Ansätze verfolgen.

Es liegt aber auch daran, dass Design-Systeme mit vielen Vorteilen locken: Sie unterstützen bei der Zusammenarbeit zwischen Entwicklung und Design, weil sie ein gemeinsames Verständnis der Sprache des anderen etablieren helfen. Dem Management wiederum bieten sie Vorteile in Form von Skalierung einerseits und Kostenersparnis andererseits. Auch schneiden wir das Thema ROI eines Designsystems an und sprechen darüber wie die Einführung in einer Organisation erleichtert werden kann, um eine bessere Adaption zu erzielen. Wir sind uns aber darin einig, dass ein wesentlicher Teil des Erfolgs nicht von technischen Aspekten, sondern auch von Stakeholder-Management und Kommunikation abhängt.

Apropos Technik: natürlich diskutieren wir über Vor- und Nachteile verschiedener Frontend-Stacks wie React und Web-Komponenten, welches Framework für die Zukunft relevant sein wird und wie der Transfer von Code zwischen verschiedenen Frameworks erleichtert werden könnte. Weiterhin erörtern wir, wer in einem Unternehmen oder Team für das Design-System verantwortlich sein sollte und wie Entscheidungen in diesem Zusammenhang getroffen werden können. Und schließlich weisen wir darauf hin, dass Design-Systeme am Ende immer nur so gut sind wie die sie Nutzenden ein Verständnis der darunter liegenden Konzepte haben.

Das zeigen auch Jonas‘ und Daniels Erfahrungen beim Einsatz ihres Open-Source Design-System-Frameworks kickstartDS bei Kunden: So mächtig das Framework auch ist, so unklar ist vielen unerfahrenen Neu-Design-System-Nutzenden, wie sie zu einem großen ganzen zusammenfügen und es an Ihre bestehenden Systeme anbinden können. Deshalb stand das letzte Jahr bei kickstartDS ganz im Zeichen der Weiterentwicklung hin zu einem nunmehr schlüsselfertigen Frontend, mit typischen UI-Komponenten, Adaptern für Storyblok, Eleventy & Co. und einem anschaulichen Showcase obendrauf.

[00:00:00] Keine Schaunotizen

Jonas‘ Artikel zum Thema JSON-Schema
Part 1: https://www.kickstartds.com/blog/unlocking-the-frontend-pt1/
Part 2: https://www.kickstartds.com/blog/unlocking-the-frontend-pt2/
Ruhmesmeile
Jonas‘ und Daniels Web-Agentur aus Bonn
Transkript

Revision 606: Dev, Business, Design & Marketing effektiv vereint

1. März 2024 | Keine Kommentare

In heldenhafter Manier setzte sich Martin Dilger einem durch Vanessa und Peter veranstaltetem Kreuzverhör aus, um die frohe Kunde der Einheit von Dev, Business, Design und Marketing zu verkünden. Martin war zuletzt in Revision 594 (Vom Chaos zum Code) zu Gast.

Schaunotizen

[00:02:12] Requirement Engineering mit Event Modelling
Martin identifiziert das Ermitteln und Kommunizieren von Requirements als das größte Problem im Software-Engineering und stellt seinen Event-Modelling-Ansatz als Lösungsvorschlag vor. Mit uns spielt er einen entsprechenden Workshop durch, der alle Stakeholder an einen Tisch holt und die umzusetzende Software als eventgetriebenes System planen lässt. Von der Philosophie des Ansatzes über Parallelen zu Domain Driven Design (siehe Revision 556) bis hin zur Weiterentwicklung des Modells über die Zeit wird keine Plaungsphase außer acht gelassen.
Transkript

Revision 605: Mental Health

20. Februar 2024 | Keine Kommentare

⚠️ Content-Warnung: In dieser Episode sprechen wir über Depressionen. Bitte beachtet, dass einige Inhalte möglicherweise belastend sein könnten. Wenn ihr Unterstützung benötigt, wendet euch bitte an professionelle Hilfsangebote, wie beispielsweise die Stiftung Deutscher Depressionshilfe.

Diesmal sind Pepo (Pascal Szewczyk) und Pia Hofmeier mit dabei. Wir sprechen über mentale Gesundheit.

Schaunotizen

[00:02:04] Mentale Gesundheit
Das Thema mentale Gesundheit am Arbeitsplatz ist für uns sehr wichtig. Wir sind deshalb froh, dass wir Pepo und Pia für die Sendung gewinnen konnten. Peter schildert seine Erfahrungen mit Depression als Betroffener und zeigt anhand einiger Beispiele, welchen Einfluss und Auswirkungen die Depression auf seine Arbeit und das Leben allgemein hat. Pia hilft uns dies allgemein einzuordnen und wir sprechen darüber, wie man mit Menschen mit Depression umgehen und diesen helfen kann.

Wir hoffen, dass wir mit dieser Sendung mehr Sensibilität für das Thema schaffen können und Betroffenen sowie Helfenden, das Gespräch darüber erleichtern können.

Transkript

Revision 604: UX auf der Kommandozeile

13. Februar 2024 | Keine Kommentare

In dieser Episode tauchen wir, zusammen mit unserem Gast Martin Helmich, in die faszinierende Welt der Kommandozeilenprogramme und deren Bedeutung für die Developer Experience ein. Martin, Experte in Software- und Cloud-Architektur sowie Developer Relations bei Mittwald, teilt seine umfassenden Einblicke und Erfahrungen mit uns. Wir entdecken eine spannende Wetteranwendung für das Terminal und diskutieren, wie die Effizienz und Vorteile der Kommandozeile für Power-User nicht nur die alltägliche Arbeit erleichtern, sondern auch eine besondere Form der User Experience darstellen.

Schaunotizen

[00:01:42] UX auf der Kommandozeile
In unserem Gespräch erkunden wir die Vielfalt der „Command Line Interface“- aka CLI-Tools und deren Einsatzmöglichkeiten in unterschiedlichen Szenarien. Von der einfachen Verwendung für Git-Operationen, über Brew bis hin zu spezialisierten Anwendungen für Cloud-Dienste und Content-Management-Systeme, die Kommandozeile ist ein mächtiges Werkzeug in der Entwicklerwelt.

Martin betont, wie wichtig eine gute Developer Experience ist, um effektiv und effizient mit Kommandozeilenprogrammen arbeiten zu können. Wir sprechen über die Herausforderungen und Lösungen bei der Erstellung benutzerfreundlicher CLI-Programme, die sowohl für Einsteiger als auch für erfahrene Entwickler geeignet sind.

Wir lernen, dass wir grundsätzlich jede Programmiersprache zum Schreiben von Kommandozeilen-Werkzeugen hernehmen können, es aber deutlich angenehmer wird, wenn wir uns Hilfe von darauf spezialisierten Frameworks holen, die von Haus aus Lösungen für viele typische Anwendungsszenarien anbieten:

In OCLIF tauchen wir tiefer ein und lernen Dinge über Flags, über interaktive vs. non-interaktive CLI-Programme, dass eine Ausgabe rückwärtskompatibel, da „grep-bar“ sein sollte, und dass CLI-Werkzeuge responsive sein müssen, nämlich in der Form, dass sie automatisch bemerken, ob sie in einem ausgabefähigen Terminal („TTY“) laufen oder nicht, und sich daran anpassen.

Gegen Ende werden wir fast des Wahnsinns fette Beute, als wir nämlich hören, dass es sogar ein React-basiertes Framework zum Bauen von CLI-Tools namens Ink gibt. 🤯

Transkript

Revision 603: Nerdige Soft- und Hardware-Tipps

6. Februar 2024 | Keine Kommentare

In einer etwas speziellen Folge haben sich Peter, Vanessa und Hans zusammengesetzt und einfach drauf losgeplappert. Ein richtiges Thema gab es nicht, weswegen es zwar nicht um Gott und die Welt, aber um Bohrhämmer und UML-Diagramme ging.

Schaunotizen

[00:03:00] Werkzeuge im Meatspace
Wenn ihr schon immer mal wissen wolltet, auf welcher Seite der Hilti-vs.-Bosch-Debatte wir stehen und ob „entspinnifizieren“ mit Kabel oder Akku besser geht, klären wir das ein für allemal. Außerdem geht es kurz um Fahrräder und das Reinigen von Fahrrädern, wahlweise mit spezialisiertem Tooling oder ausgedienten Spülbürsten.
[00:18:50] Kaffee, Kaffeezubehör und Koffein-Trägersubstanzen
Hans nerdet über Espresso ab und wir debattieren über den Wert von unterschiedlichen Kaffees in unterschiedlichen Lebenslagen. Wir klären, wie viel Esspresso kommt aus dem „„„„„Esspressokocher“““““ herauskommt, überlegen ob die 9Barista Espresso Machine ihren Mondpreis wert sein könnte und debattieren die Qualitätsunterschiede von Kaffeemühlen. In qualifiziert gibt’s mehr von dem Thema auf Youtube bei James Hoffmann.
[00:46:23] Software-Empfehlungen
Wir empfehlen und diskutieren unterschiedlichste Software-Produkte aus allen möglichen Kategorien, beginnend bei den Bildschirm-Wach-Haltern Amphetamine (Mac) und Caffeine (Linux). Der Zettelwirtschaft treten wir mit Obsidian und Passwordmanagern wie 1Password entgegen, warnen aber auch davor, sich darauf zu sehr zu verlassen (1Password im speziellen hat erhöhtes Risiko für Enshittificaton und/oder Exitus). Zum reviewen und mergen von Code stellen Graphite, Git Tower und Sourcetree ernstzunehmende Alternativen füreinander dar, während die einzige Alternative zu DevUtils räudige Textareas auf shady Websites sind. Hans spricht sich für den „Pocket Coach“ Ahead aus, Vanessa für den CV-Generator Oh My CV!, aber im allgemeinen taugt auch schieres HTML/CSS als LaTeX-Ersatz für schöne Dokumente. Für visuelles empfehlen wir Mermaid (ASCII->Diagramm-Transformator) (Online-Grafiktool) (Offline-Vektorgrafikeditor) und („visueller Workspace“), für Präsentationen unter anderem Pitch und Slidev. Nachdem wir eine Lanze für selbstgeschriebene Software gebrochen haben (xkcd) beenden wir die Sendung mit den Mastodon-Clients Ivory (iOS) und Elk (Web) dem Kalender Cron, dem Task-Manager Things, dem Mail-Client Superhuman und einer Diskussion rund um Podcast-Apps wie Overcast und Spotify.
Transkript

Revision 602: Komponentenbasierte Frontends in TYPO3

30. Januar 2024 | Keine Kommentare

In dieser Revision haben Hans und Schepp Besuch von Florian Geierstanger (Web / LinkedIn / Mastodon) und Simon Praetorius (Web / LinkedIn / Mastodon), ihres Zeichens TYPO3-Frontend-Dompteur und TYPO3-Core-Entwickler und Berater.

Schaunotizen

[00:02:20] Komponentenbasierte Frontends in TYPO3
Diese Revision interessiert uns, ob, und wie man im Content-Management-System TYPO3 ein komponentenbasiertes Frontend konstruieren kann. Bevor wir in diese Frage eintauchen, lassen wir uns von unseren Gästen den Werdegang, die Philosophie und die aktuelle Stellung von TYPO3 im Markt erklären. Nach einigen Höhen und Tiefen ist TYPO3 nun schon seit Längerem wieder in guten Fahrwassern und es sind zahlreiche gute Dinge hineingeflossen und neue in der Roadmap geplant. Was TYPO3 im Core nicht mitbringt, rüsten zahlreiche TYPO3-Extensions nach, von denen einige auch den offiziellen Segen des Core-Teams haben – was bedeutet, dass sie gut gepflegt sind. Das mächtige Template-System basiert auf XML und nennt sich Fluid. Headless lässt es sich ebenso betreiben wie mit „Head“. Und natürlich besitzt TYPO3 seine Version von Hotwire namens „Topwire„.

TYPO3 mischt im deutschsprachigen Markt als einziges Open Source System im Enterprise-Umfeld mit und hat so einen guten Ruf, dass sogar der Bund drauf setzt. In den letzten Jahrzehnten hat sich rund um TYPO3 eine große Community geformt, die sich regelmäßig Online austauscht, sich zu Meetups trifft, oder auf den jährlich stattfindenden TYPO Developer Days.

Als vom Backend her entwickeltes System, ist TYPO3 nicht „out of the Box“ auf die komponentenbasierte Entwicklung von Frontends ausgelegt. In diese Lücke stieß nun Simon und lotete aus, was sich machen ließ. Was nicht passt, wird passend gemacht und so ergibt es sich, dass man für sein Frontend letztendlich doch Komponenten-Bibliotheken/-Styleguides einsetzen kann, und/oder Bootstrap, und man alles mit Vite verdrahten kann, das einem alle Assets zusammenschnürt.

Transkript

Revision 601: WebAssembly – Vergangenheit, Gegenwart und Zukunft

22. Januar 2024 | Keine Kommentare

Mit unserer Gästin, der Entwicklerin und Trainerin Martina Kraus sprachen wir zuletzt über das Thema Revision 482: Angular im Jahr 2021. Dieses Mal sollte es nicht um Angular gehen, sondern um WebAssembly. Fasten your seatbelts!

Schaunotizen

[00:01:33] WebAssembly – Vergangenheit, Gegenwart und Zukunft
Wir beginnen mit einem kleinen Recap, was WebAssembly denn überhaupt ist: WebAssembly ist eine von JavaScript-Engines abgeleitete, plattformunabhängige Ausführungsumgebung, die es ermöglicht, Code aus anderen Programmiersprachen dafür umzuwandeln und ihn dann nahezu in Originalgeschwindigkeit auszuführen.

Die ersten Umgebungen, die WebAssembly unterstützt haben, waren die Browser. Alle aktuellen Browser, aber auch Node, Deno oder Bun unterstützen die Ausführung von WebAssembly. Mit Hilfe von wasm-bindgen kann WASM-Code mit JavaScript kommunizieren und zusammenarbeiten.

Neuerdings gibt es, dank des WASI-Standards aber auch eigenständige Ausführungsumgebungen für WebAssembly, um Code plattformunabhängig auszuführen – die bekannteste derzeit: Wasmer inklusive Packet-Registry.

Tweet vom 27. März 2019 von Solomon Hyke, einem der Erfinder von Docker, der schreibt: "If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!"

Die Zukunft von WebAssembly sieht Martina in der Nutzung als „Serverless Functions“, also in Form von schnell erzeugtem „Fire and Forget“-Code, der irgendwo in der Cloud läuft.

Keine Schaunotizen

Das V8 Blog
Hier posten die V8-Ingenieure regelmäßig über die Verbesserungen an der Engine.
Debug C/C++ WebAssembly
Hier findet Ihr beschrieben, wie Ihr mit den Chrome Devtools WebAssembly-Code debuggen könnt. Ein Video-Tutorial gibt es auch.
Transkript

Revision 600: Live

10. Januar 2024 | Keine Kommentare

Willkommen zur 600ten Revision unseres Podcasts, die wir am Sonntag, den 7. Januar 2024, in Form einer live abgehaltenen Fishbowl-Diskussion mit etwas über zwanzig Gästen durchgeführt haben. Wir haben dabei über drei verschiedene Themenblöcke gesprochen, die wir per Voting bestimmt haben:

  1. Web Components
  2. Erwartungen an den Framework-Jungle 2024
  3. Design Systeme

Unsere Teilnehmerschar bestand aus ehemalige Gästen wie z.B. Marvin Hagemeister, Jens Grochtdreis oder Alexander Lichter, aber auch aus vielen neuen Gesichtern. Darüber haben wir uns sehr gefreut!

Schaunotizen

[00:10:38] Web Components
Wir starteten mit den Web Components. Zunächst ging es darum, ob Web Components überhaupt „einsatzbereit“ seien. Und wir diskutierten, wie sich Web Components mit anderen Frontend-Frameworks verbinden lassen. Zum Glück gab es bereits Artikel darüber, wie Frameworks und „Custom Components“ erfolgreich kombiniert werden können, wie z.B. der „Custom Components Everywhere„. Besonders spannend war, dass die Seite Reddit anscheinend teilweise bereits mit Web Components erstellt wurde. Dies war jedoch noch nicht für alle Benutzer verfügbar – in diesem Fall half der Inkognito-Modus und das Ausloggen -, aber dann konnten die Teilnehmer die neue Webseite mit Web Components betrachten. Wir haben natürlich über den Shadow DOM und die damit einhergehenden Probleme gesprochen. Wenn jemand noch auf der Suche nach überzeugenden Argumenten für Web Components auf Management-Ebene war, empfahlen wir das Lesen dieses Web Components Elevator Pitchs.

[00:56:54] Erwartungen an den Framework-Jungle 2024
Die Diskussion ging nahtlos zum Thema Frontend-Frameworks über. Zuerst haben wir darüber gesprochen, ob die Teilnehmer:innen zu dieser Zeit „FOMO“ (Fear of missing out) in Bezug auf die aktuellen Frontend Frameworks empfanden. Danach haben wir erörtert, wie viele verschiedene Frameworks tatsächlich in der „Realität“, also in Arbeitsprojekten, verwendet wurden. Einige Personen haben ihre Erfahrungen geteilt, wie sie Frameworks oder Bibliotheken wie NPM-Pakete komplett ausgetauscht haben. Wir haben die Vor- und Nachteile der Verwendung von Bibliotheken im Allgemeinen besprochen. Marvin hat in diesem Zusammenhang passenderweise den Link zu einem XKCD-Comic über Bibliotheken im Web geteilt.

[01:59:55] Design Systeme
Mit einer fulminannten Überleitung von Hans gelangten wir zum Thema Design Systeme. Sowohl in der Live-Diskussion als auch im Chat gingen viele Themen hin und her. Wir sprachen darüber, wer in Projekten für die Instandhaltung von Pattern Libraries verantwortlich ist. Es stellte sich auch heraus, dass es bei dem Thema viel um Kommunikation geht. Die Teilnehmenden nannten Tools wie Storybook, story.to.design, Histoire, UXPin und Ladle. Schließlich eröffnete Hannah die Diskussion darüber, wer tatsächlich mit „Design Systemen“ und nicht nur Pattern Libraries im Designbereich, beispielsweise mit Figma, arbeitete.

Transkript