Wie bist du zum Grafikdesign gekommen und wann kam das Programmieren dazu?
Katharina: Ich war schon früh daran interessiert, wie man Dinge visuell umsetzt und kommuniziert. Während meines Studiums hat mich besonders das interaktive Element fasziniert. Ich habe angefangen, Konzepte zu entwickeln, die nicht nur grafisch, sondern auch interaktiv gedacht waren. Zum Beispiel digitale Illustrationen, die sich verändern, je nachdem wie viele Personen vor dem Bildschirm stehen. Um solche Ideen umzusetzen, musste ich mich zwangsläufig auch mit der technischen Seite beschäftigen.
Vielleicht spielt da auch mit rein, dass meine Eltern Informatiker:innen sind. Ich hatte also schon früh Berührungspunkte mit Themen wie HTML und CSS. Dinge, die für viele aus meinem Jahrgang erst mit den typischen MySpace-Seiten begonnen haben, wo man ein bisschen herumexperimentiert hat. Für mich war die Hemmschwelle da einfach niedriger.
An der Uni habe ich dann angefangen, mit Processing zu arbeiten, oder mit HTML und CSS herumzuexperimentieren. Mich hat besonders interessiert, was an der Schnittstelle zwischen Grafikdesign und Web – oder allgemein gesagt: zwischen Gestaltung und Interaktion – möglich ist.
Das heißt, du hattest von vornherein gar keine große Hemmschwelle zum Programmieren, weil du dich sowieso dafür interessiert hast?
Katharina: Genau, ganz wenig. Ich finde die Frage auch deshalb interessant, weil ich selbst in der Lehre tätig bin. Da frage ich die Studierenden oft am Anfang: »Wie sind eure Gefühle gegenüber Code?« Und meistens kommt dann so etwas wie: »Es ist total spannend, aber auch ein bisschen scary.« Ich glaube, dass es da auf jeden Fall diese Hemmschwelle gibt, die man erst einmal abbauen muss.
Ich hatte vielleicht einfach das Glück, dass ich schon immer viel im Internet unterwegs war und dadurch früh mit solchen Dingen in Kontakt kam. Aber ich denke auch, dass es unglaublich wichtig ist, eine unterstützende Umgebung zu haben – sei es durch einen Unikurs oder durch Menschen im Umfeld. Ich hatte zum Beispiel einen guten Freund, der kurz vor mir Programmieren gelernt hatte und den ich immer fragen konnte. Das hilft total, weil man dann nicht allein vor dem Bildschirm sitzt und nicht weiterweiß, wenn etwas nicht funktioniert. Genau das ist, glaube ich, ein ganz zentraler Punkt.
Und was sind inhaltliche Themen, die dich als Gestalterin antreiben? Gibt es da etwas, oder geht es dir eher darum, wie du etwas darstellst? Was findest du besonders spannend?
Katharina: Das knüpft ein bisschen an mein Interesse an, visuelle Arbeiten zu schaffen, die interaktiv sind. In meiner Arbeit habe ich ein paar Schwerpunkte, einer davon ist das Thema interaktives Lesen. 2019 habe ich das &Shy-Magazine mit gegründet – zusammen mit einem kleinen Editorial Team: Sophia Roxane Rohwetter, Chris Möller und Victor Kümel. Wir haben dort Texte von Autor:innen genommen und sie ins Digitale übertragen. Dabei ging es uns nicht nur darum, die Texte online zugänglich zu machen, sondern auch zu überlegen: Wie kann Typografie im Digitalen funktionieren?
Beim gedruckten Buch denkt man ja auch über Materialität nach: Papier, Bindung, Format. Im Web stellt sich eine ähnliche Frage: Was bedeutet Materialität im digitalen Raum? Wie verändert sich das Lese-Erlebnis, wenn ich scrollen, touchen oder swipen kann? Welche neuen Möglichkeiten eröffnen sich dadurch für das Lesen im Digitalen? Das ist vielleicht einer meiner wichtigsten Schwerpunkte.
Du hast es gerade schon erwähnt: Du hast das &Shy-Magazine mitgegründet. Ist das aus dem Wunsch heraus entstanden, das Lesen im Digitalen zu erforschen? Ich nehme an, es war eine bewusste Entscheidung, das ausschließlich digital zu halten.
Katharina: Ja, genau. Ich glaube, das Interesse kam daher, dass ich sehr gerne Literatur lese. Und als Grafikdesignerin finde ich es unglaublich spannend, mit literarischen Texten typografisch zu arbeiten, weil sie so vielschichtig sind. Sie bieten unglaublich viel inhaltliches Material, aus dem sich gestalterische Konzepte entwickeln lassen.
Das war so der Ausgangspunkt. Weitergedacht kam dann die Frage auf, wie das eigentlich im Digitalen aussieht: Wie kann man eine digitale Literatur-Publikation gestalten, die ähnlich wertgeschätzt wird, wie ein Gedichtband – die aber natürlich völlig anders aussieht und auch anders funktioniert?
Wie lange dauert es, bis eine Ausgabe fertig ist?
Katharina: Das ist ganz unterschiedlich. In letzter Zeit hatten wir leider keine erfolgreichen Förderanträge mehr, aber insgesamt haben wir bislang sechs oder sieben Ausgaben veröffentlicht. Jede davon hatte ein eigenes Konzept oder entstand in Kooperation. Zum Beispiel mit Literaturfestivals oder mit Unterstützung des Deutschen Literaturfonds, mit dem wir drei Ausgaben realisiert haben.
Wir haben uns dabei jeweils bestimmte Themen gesetzt, etwa 🌐Mistaking Glass for Skin – das war das Touch Issue – oder 🌐Zusammen Lesen. Eine weitere Ausgabe, in Zusammenarbeit mit einem Literaturfestival, hatte das Thema Übersetzung.
Wie lange die Arbeit an einer Ausgabe dauert, hängt stark vom Konzept ab. Meistens haben wir pro Issue etwa fünf Texte und die Produktion zieht sich über einige Monate. Zunächst sucht das Redaktionsteam gemeinsam passende Texte. Manche davon sind aufwendiger umzusetzen, andere etwas einfacher. Das gleicht sich meist aus.
Die Umsetzung eines einzelnen Textes kann etwa zwei Wochen bis einen Monat dauern. Vieles läuft parallel, und die Arbeit entsteht immer in enger Abstimmung zwischen Autor:innen, Redaktion, Design und Development.
Julia: Ich erinnere mich, als ich das &Shy-Magazine zum ersten Mal entdeckt habe. Ich fand es total interessant, wie es die Leser:innen ein Stück weit herausfordert. Ich lese selbst gerne, aber ungern auf einem Bildschirm. Es ist oft einfach dasselbe wie ein Buch zu lesen, nur mit Licht dahinter. Aber wenn man an den richtigen Stellschrauben dreht und die Möglichkeiten des Webs mitdenkt, kann es richtig spannend werden.
Glaubst du, dass digitale Leseangebote analoge, also gedruckte Formate ergänzen können? Oder ist das zu viel gewollt?
Katharina: Ich glaube, mittlerweile gibt es ja ganz unterschiedliche Formate – interaktive PDFs, EPUBs, Webseiten oder auch Augmented-Publikationen. Ich finde dieses Nebeneinander sehr spannend.
Ein Beispiel ist ein Projekt, an dem ich gearbeitet habe: 🌐Apod.li, eine Library of Artistic Print-on-Demand. Die Webseite ist wie ein durchsuchbares und filterbares Archiv von Print-on-Demand-Publikationen. Sie hat natürlich einen anderen Fokus als die gedruckten Bücher selbst, die von jemand anderem gestaltet wurden. Während die Publikationen eher ein Nachschlagewerk sind, ist die Website interaktiv und lädt zum Erkunden ein.
Ich finde, man kann die Stärken beider Medien gezielt nutzen. Gedruckte Publikationen haben zum Beispiel einen klaren Vorteil, wenn es ums Zitieren oder Archivieren geht. Das sieht man auch beim Cyberfeminist Index von Mindy Seu. Da wurde ein Print-Format entwickelt, damit Inhalte beispielsweise in Wikipedia zitiert werden können. Print hat also weiterhin seine Berechtigung, gerade durch seine Langlebigkeit.
Im Digitalen hingegen kann man Archive auf eine völlig andere Weise erfahrbar machen: explorativer, lebendiger, dynamischer.
Hast du zu einem Zeitpunkt das Gefühl gehabt, dass du als weiblich gelesene Person in der Coding-Szene anders wahrgenommen wurdest oder auf Hürden gestoßen bist?
Katharina: Gott sei Dank eigentlich nicht so sehr. Vielleicht lag das auch an meiner Strategie: Ich habe oft einfach meine eigenen Projekte gestartet. Manchmal hatte ich eher im Grafikdesign das Gefühl, außen vor zu sein. Wenn ich gesehen habe, dass andere coole Projekte machen, und mich gefragt habe: »Warum wurde ich nicht gefragt?« Irgendwann habe ich dann gemerkt: Ich kann meine eigenen Projekte machen, dann muss ich auf niemanden warten.
Ich glaube, es ist auch ein Vorteil, als Entwicklerin in einem Designkontext zu arbeiten. Wenn man an dieser Schnittstelle unterwegs ist, also unter Designer:innen diejenige ist, die programmiert, kann man ganz anders experimentieren. Das ist etwas anderes, als im klassischen Informatik-Studium unter lauter Developer:innen zu sein. Diese Kombination hat mir auf jeden Fall geholfen.
Ich habe generell das Gefühl, dass es sehr viel mit den Räumen zu tun hat, die man sich schafft. In Software-Development-Teams sieht man ja: Sobald ein Team diverser ist, zieht das auch wieder diversere Leute an. Wenn ein Team ausschließlich aus Männern besteht, bewerben sich weniger Frauen oder FLINTA Personen. Aber sobald man eine diverse Person im Team hat, öffnet sich das Ganze automatisch.
Ich fand es immer wichtig, solche Räume aktiv zu schaffen. Orte, an denen nicht alle gleich sind, sondern wo unterschiedliche Perspektiven willkommen sind. Ich bin selbst Teil von ein paar Netzwerken, zum Beispiel den Female Freelance Developers oder früher einer kleinen Graphic Girl Gang, wie wir sie genannt haben. Ich finde, solche Zusammenschlüsse – ob FLINTA oder allgemein divers – sind enorm hilfreich. Man schafft sich eine eigene Atmosphäre, in der man sich gegenseitig stärkt und unterstützt. Das nehme ich auf jeden Fall aus meiner bisherigen Erfahrung mit.
Gab es für dich (weibliche) Vorbilder, entweder im Bereich Grafikdesign oder im Bereich feministischen Aktivismus?
Katharina: Ich glaube, es gibt viele Menschen, die ich bewundere oder die für mich Mentor:innen sind und deren Arbeit ich einfach total spannend finde. Von manchen habe ich Dinge gelernt, die mich sehr geprägt haben.
Ich weiß gar nicht, ob das bei mir so stark nach Gender aufgeteilt war. Es hängt eher mit bestimmten Themen zusammen. Es gab zum Beispiel Personen, die mich im Bereich Lehre sehr geprägt haben und andere, die mich beim coden lernen unterstützt haben.
Gerade dieser Bereich – also Unterstützung beim Programmieren lernen – war für mich sehr prägend. Ich hatte einen guten Freund, der mich ermutigt hat, eigene Projekte anzunehmen, auch wenn ich mir unsicher war. Ich wusste, dass ich, wenn kurz vor der Abgabe etwas nicht funktioniert, einfach zu gehen und fragen konnte: »Hey, kannst du mir helfen?« Dieses Gefühl, einen sicheren Raum zu haben, war sehr wichtig.
Ich versuche, das heute weiterzugeben. Bei Kolleg:innen oder Studierenden. Ich sage dann immer: »Meldet euch, wenn ihr Fragen habt.« Ich finde es wichtig, so eine Art Sicherheitsnetz zu schaffen, in dem man sich traut, Dinge auszuprobieren, ohne Angst zu haben, zu scheitern. Ich habe das Gefühl, man lernt und wächst viel mehr, wenn man weiß, dass Fehler okay sind.
Julia: Ja, ich finde, das ist das Schöne an der Open-Source-Community. Ich glaube, dass alle irgendwann mal an dem Punkt waren, an dem sie nicht wussten, wie das alles funktioniert – und dann aufgefangen wurden. Und wenn man das weiß, wie es funktioniert, gibt man das Wissen selber weiter.
Katharina: Wie war das denn bei dir? Was waren deine Erfahrungen?
Julia: Also, ich habe mich in der Schulzeit, in der Oberstufe, für Informatik interessiert, und wollte eigentlich nur coden – ein bisschen HTML und CSS lernen. Aber im Unterricht ging es dann nur um Netzwerke, das fand ich total langweilig. Deshalb habe ich damit wieder aufgehört.
Im Studium hatte ich dann Glück: In meinem dritten Semester wurde zum ersten Mal ein Kurs angeboten – von Tim Rausch und Björn Jeske. Es ging um digitale Archive. Man lernt das Programmieren anhand eines eigenen Archivs, das man selbst konzipiert und gestaltet.
Damit bin ich eingestiegen und dann habe ich mir jedes Semester eine neue Herausforderung gesucht. Irgendwann habe ich auch PHP und JavaScript gelernt. Es hat mir einfach total Spaß gemacht. Ich hatte nie ein Problem damit, mich mit Technologie auseinanderzusetzen. Aber mir ist aufgefallen, dass viele Kommiliton:innen das anders sehen. Oft habe ich gehört: »Du machst schon wieder einen Coding-Kurs? Das ist mir zu kompliziert.« Und ich dachte mir immer: Nein, ist es nicht! Es ist gar nicht so schlimm.
Katharina: Ja, ich finde es auf jeden Fall spannend zu überlegen, wie man solche Hürden abbauen kann. Ich bin der Meinung: Wenn jemand etwas – zum Beispiel Coding-Basics – nicht versteht, liegt das meist an der Person, die es erklärt. Wenn man etwas wirklich gut erklären kann, dann kann es auch jede:r lernen.
Wichtig ist, die Leute zu begeistern. Sie brauchen etwas, das sie wirklich interessiert. Deshalb versuche ich, möglichst früh zu sagen: »Denkt euch ein Projekt aus, das ihr richtig cool findet.« Meistens lernen die Studierenden dann von selbst, wie sie es umsetzen können – einfach, weil sie es unbedingt schaffen wollen. Das ist auf jeden Fall meine Strategie. Aber ich glaube, es gibt ganz unterschiedliche Herangehensweisen.
Wie gehst du als Lehrperson damit um, wenn in deinen Kursen so unterschiedliche Level an Coder:innen sitzen?
Katharina: Oft versuche ich, das Thema offen zu halten, sodass sich jede:r Studierende ein eigenes Konzept überlegt, das sie oder er dann umsetzt. Das kann ganz unterschiedliche Ausgangspunkte haben, und das finde ich auch schön. Man kann mit HTML und CSS schon sehr viel machen.
Ich habe in ein, zwei Kursen ausprobiert, dass sich die Studierenden ein bisschen selbst zusammenstellen können, welche Basics sie brauchen. Wenn ich zum Beispiel Inputs gebe, sage ich oft: »Wer das schon kann, kann in der Zeit an etwas anderem weiterarbeiten oder sich ein anderes Thema anschauen.« So müssen nicht alle bei allen Inputs dabei sein. Jede:r kann im eigenen Tempo lernen.
Sehr hilfreich ist auch, wenn sich die Studierenden gegenseitig unterstützen. Manchmal gibt es Buddy-Systeme, sodass man weiß: »Wenn ich eine JavaScript-Frage habe, kann ich Person X fragen.« Solche Strukturen funktionieren oft sehr gut.
Julia: Also Arbeitsgruppen nicht forcieren, sondern einfach die Möglichkeit in den Raum stellen.
Katharina: Genau.
Wie wichtig ist es dir, deine eigenen Tools gestalten zu können?
Katharina: Ich finde es total spannend, eigene Tools gestalten zu können. Generell ist es beim Umgang mit Technologie wichtig zu verstehen, wie etwas funktioniert. Erst dann kann man überhaupt begreifen, wie man es verändern kann.
Bei Programmen wie InDesign merkt man irgendwann, dass man sie auch skripten kann. Und jetzt, mit den ganzen KI-Tools, wird das noch relevanter. Man muss nicht unbedingt eigene Modelle trainieren, aber es ist wichtig zu wissen, wie sie funktionieren und welche Biases es gibt. Nur so kann man reflektiert damit umgehen. Gleichzeitig sollte man sich bewusst machen, was Closed-Source-Software wie Adobe bedeutet – und was Open-Source-Alternativen leisten. Es geht nicht nur darum, wer Zugriff hat, sondern auch darum, wie stark Voreinstellungen und Standards das visuelle Ergebnis prägen.
Man muss nicht immer eigene Tools entwickeln, aber ich finde es ist wichtig, sich klarzumachen, welche Defaults eigentlich wirken und warum sie so aussehen, wie sie aussehen. Wenn man dann eigene Tools baut, sollte man klein anfangen: nicht gleich ein neues Photoshop, sondern lieber ein Tool für ein bestimmtes grafisches System oder für eine spezielle Funktion. Dann merkt man schnell, dass man die eigenen Parameter selbst setzen kann. Und dass dadurch andere Variationen und Zufälle entstehen, als bei Standard-Tools.
Spannend finde ich auch den Aspekt von Open Source. Diese Tools werden von Communities entwickelt, sie sind also nie perfekt. Es gibt zum Beispiel das 🌐Feminist Server Manifesto. Darin wird das am Beispiel von Selfhosting sehr schön beschrieben – also der Idee, eigene Server zu betreiben, statt alles in der Cloud zu haben. Das bedeutet aber auch Verantwortung: Jemand muss die Server warten und damit rechnen, dass sie nicht immer online sind.
Das merkt man auch, wenn man sagt: »Nutzen wir Zoom oder Jitsi? Google Docs oder Etherpad?« Open-Source-Lösungen haben oft den Nachteil, dass sie nicht so nahtlos funktionieren. Man sieht die Technologie in dem Moment, in dem sie eben nicht funktioniert.
Ich finde, das sollte man in diesen Prozessen mitdenken – vielleicht sogar als Teil der Gestaltung begreifen. Wenn man mit experimentellen Tools oder Web-to-Print-Anwendungen arbeitet, sollte man nicht erwarten, dass der Output perfekt ist. Das gehört dazu. Ich glaube, ihr macht an der HAW ja auch öfter Web-to-Print-Projekte, oder?
Julia: Ja, ich bin daran auch schon verzweifelt.
Katharina: Genau. Und da muss man akzeptieren, dass man im Web zum Beispiel keinen Flattersatz machen kann – auch in diesen Tools nicht. Die haben Bugs und dann druckt man eben das, was rauskommt. Das muss dann auch in Ordnung sein. Man braucht vielleicht andere Standards oder Erwartungen an das Ergebnis.
Du hast von Voreinstellungen in InDesign gesprochen, die eine gewisse Ästhetik oder bestimmte Outcomes forcieren. Hast du dafür Beispiele?
Katharina: Jede Technologie hat ihre eigenen Limitationen. Im Bleisatz war zum Beispiel klar, dass Text in Blöcken gesetzt wird – daher kommt auch der Begriff. Bei InDesign ist es ähnlich: Es gibt unzählige Möglichkeiten, aber viele sind historisch gewachsen. Standardmäßig wird Text in Kästen gesetzt, in denen die Zeilen einfach laufen. Das wirkt selbstverständlich, ist aber eigentlich ein bestimmtes, vorgegebenes Lese- und Gestaltungsprinzip.
James Langston hat dazu einmal eine interessante Publikation gemacht. Er kritisiert genau das – dass Text immer in diesen Linien steht, obwohl es auch andere Möglichkeiten gäbe, ihn zu lesen oder zu setzen. Er bezog sich auf ein Projekt, bei dem der Text so gestaltet war, dass man immer drei Wörter auf einmal liest. Das waren kleine Wortgruppen, für die extra ein InDesign-Skript entwickelt wurde, um sie so anzuordnen.
Das ist ein gutes Beispiel dafür, wie man experimentell mit Typografie umgehen kann. Ähnlich wie im Bleisatz, wo man auch nicht alles beliebig setzen konnte, aber Designer wie Wolfgang Weingart trotzdem neue Wege gefunden haben, Texte anders zu strukturieren oder aufzureihen. Genau darum geht es mir: die Limitationen zu erkennen und mit ihnen zu spielen.
Julia: Das zeigt auch, dass man oft gar nicht weiß – oder sich zumindest nicht bewusst ist – dass diese Limitationen existieren. Dann stellt man sie auch nicht in Frage. Aber es ist interessant, das zu hinterfragen oder einfach einen anderen Ansatz zu finden, zum Beispiel, indem man das Web oder den Browser nutzt.
Katharina: Genau! Auch im Web ist es ja so, dass man Divs hat, in denen die Buchstaben liegen. Aber es ist spannend zu überlegen, wie man diese Strukturen anders denken könnte.
Kann Programmieren auch eine Art feministischer Akt im Gestalten sein? Wenn man eigene Tools entwickelt oder kontrollieren und beeinflussen kann. Oder ist es für dich eher eine Spielwiese – wie würdest du das beschreiben?
Katharina: Ich finde, Code kann im Design ein weiteres Werkzeug sein – und ein sehr vielseitiges dazu. Es kann so viele unterschiedliche Dinge leisten, dass man damit unglaublich gut experimentieren kann. Ob das emanzipatorisch ist, kann man sicher auch so sehen. Ich glaube, für mich ist es vor allem spannend, dass man Dinge selbst veröffentlichen kann – dieser Self-Publishing-Aspekt des Internets. Man kann einfach etwas online stellen, genauso wie man Zines druckt und verteilt. Das ist schon sehr befreiend. Und natürlich ist es auch stark, wenn man mitgestalten kann, wie etwas funktioniert, aussieht oder sich anfühlt – also die eigenen Arbeitsprozesse und Ästhetiken mitbestimmt.
Du hast dich in deinem Projekt PosterdesAIn auch mit Künstlicher Intelligenz beschäftigt. Benutzt du fürs Programmieren KI-Modelle wie ChatGPT oder nutzt du KI in irgendeiner anderen Form fürs Gestalten oder Programmieren?
Katharina: Die Entwicklung von ⌚KI ist auf jeden Fall sehr interessant. Ich habe 2018 ein Projekt zur Bildgenerierung mit KI-Modellen gemacht – also wie solche Systeme funktionieren. Wie man Modelle trainiert und was man daraus machen kann. Damals habe ich versucht, ein eigenes Netz mit den 100 besten Plakaten zu trainieren, um daraus neue Plakate zu generieren. Das hat mit dem kleinen Datensatz natürlich nicht besonders gut funktioniert.
Die Lösung war dann, diese merkwürdigen Farbflächen, die das Modell generiert hat, an Grafikdesigner:innen weiterzugeben, die sie interpretieren sollten – frei nach dem Zitat: »Computer können Daten analysieren, aber Menschen müssen sie interpretieren.« Das fand ich sehr treffend.
Heute verschwimmt das natürlich immer mehr, weil KI-Modelle stärker in unsere Werkzeuge integriert sind. Im Grafikdesign ist das extrem interessant, aber ich finde, es ist wichtig zu verstehen, wie diese Modelle funktionieren. Woher die Daten kommen und welche Verzerrungen sie haben. Nur dann kann man sie sinnvoll als Werkzeuge nutzen – nicht einfach etwas eingeben und blind das Ergebnis übernehmen.
Ich nutze KI auch beim Coden, zum Beispiel GitHub Copilot. Das ist praktisch, aber man muss lernen, damit umzugehen. Es gibt zum Beispiel eine Studie, laut der erfahrene Programmierer:innen glaubten, mit KI Tools 20% schneller zu sein. Tatsächlich waren sie aber 25% langsamer. Also: Es ist hilfreich, aber nicht automatisch effizienter. Und wenn man zu viel KI-generierten Code in einer Codebase hat, wächst sie oft unnötig an und wird schwerer zu warten.
Ich glaube nicht, dass wir als Designer:innen und Developer:innen ersetzt werden. Wir müssen nur herausfinden, wie wir solche Tools wirklich als Unterstützung nutzen – etwa für Autocomplete, für wiederkehrende Aufgaben, Regex-Schreibarbeit oder einfach, um Gedanken zu sortieren.
Julia: Es wird ja oft gefragt, ob KI uns ersetzt, aber ich sehe es auch eher so, dass man sie als Tool nutzen kann – solange man versteht, was mit den Daten passiert und wo sie herkommen.
Katharina: Total. Ich glaube, wir führen diese Debatte gerade in Echtzeit. Zum Beispiel sieht man, dass 🌐Stack Overflow seit ⌚ChatGPT deutlich weniger Traffic hat und kaum neue Antworten bekommt. Das verändert ganze Wissens-Ökosysteme. Gleichzeitig kann man die KI erzeugten Inhalte nicht einfach wieder zum Trainieren neuer Modelle verwenden, weil sie ja selbst schon von Modellen stammen.
Ich bin wirklich gespannt, wie sich das weiterentwickelt. Für Studierende ist das ein zweischneidiges Schwert: Einerseits senken KI-Tools die Einstiegshürden enorm, was toll ist. Andererseits kann es schwieriger werden, die Grundlagen wirklich zu verstehen, wenn einem alles zu einfach gemacht wird. Und genau das Verständnis ist am Ende ja entscheidend – sowohl fürs Programmieren als auch fürs Gestalten.
Julia: Ich habe das Gefühl, dass Coden mit ChatGPT mittlerweile schlechter funktioniert als in früheren Versionen. Es referenziert sich oft selbst und wenn das schon nicht ganz stimmt, dann zieht sich der Fehler natürlich durch.
Katharina: Ja, ich finde auch, dass es grundsätzlich sehr gut funktioniert, aber man bekommt am Ende oft eine Art Frankenstein-Code. Man kann zwar immer weiter nachfragen, den Code prüfen oder Fehler suchen lassen, aber richtiges <a href="https://overriding.systems/gesichter/grace-hopper" class"gesicht-hover-trigger gesicht-link" data-img="grace-hopper">Debuggen erfordert nochmal ganz andere Skills. Dafür muss man die Grundlagen kennen – um zu verstehen, warum etwas nicht funktioniert oder was man ändern muss.
Und was du sagst, stimmt natürlich auch: Diese Modelle sind ja keine logischen Systeme im klassischen Sinn, sondern sie berechnen Wahrscheinlichkeiten – also welches Wort mit welcher Wahrscheinlichkeit als Nächstes kommt. Das ist interessant, aber nicht immer verlässlich. Trotzdem ist es natürlich hilfreich – vor allem, wenn ich mit zwanzig Studierenden im Raum bin und allein für den Coding-Support zuständig bin. Dann ist es super, wenn sie selbst Dinge umsetzen können. Und ich finde, man muss auch nicht alles von Grund auf programmieren. Wenn es gute Website-Builder oder Tools gibt, die Arbeit erleichtern, dann ist das doch großartig. Nicht jede:r Grafikdesigner:in muss sich durch frustrierende Code-Probleme kämpfen. Hauptsache, man versteht die Werkzeuge, die man benutzt.
Hast du ein Lieblingsprojekt? Etwas, das du selbst gemacht hast, oder in Kooperation mit anderen? Oder etwas, das du gerne noch ausprobieren möchtest?
Katharina: Es gibt viele Projekte, die ich spannend finde und ich bin immer neugierig, was als Nächstes kommt. Vielleicht kann ich dir zwei kurz nennen:
🌐Together Online und 🌐Gesammelte Wörter. Together Online war ein Projekt zu Live-Interaktionen und gesammelte Wörter entstand in Zusammenarbeit mit der BuchBasel. Dabei haben wir eine Webseite entwickelt, die man am Ende als physisches Buch ausdrucken konnte – das fand ich auch sehr interessant.
Ich habe mir beide online angeschaut und mich gefragt, wie Together Online genau funktioniert. Muss man sich da miteinander verbinden oder einfach gleichzeitig auf der Website sein?
Katharina: Genau, das funktioniert tatsächlich, wenn mehrere Personen gleichzeitig auf der Seite sind. Das Projekt ist während der Corona-Zeit entstanden, reflektiert aber grundsätzlich, wie sich Gemeinschaft im digitalen Raum gestalten lässt. Technisch basiert es auf einer Realtime-Datenbank – also auf WebSockets. Das bedeutet, dass die Webseite eine direkte Verbindung zwischen den Nutzer:innen herstellt. Wenn also zwei Personen gleichzeitig online sind, kann man das sehen, miteinander chatten oder gemeinsam auf der Seite zeichnen.
Es gibt dort zum Beispiel einen Online-Counter, einen Chat und ein kollaboratives Zeichen-Tool. Wenn jemand klickt oder zeichnet, wird das sofort synchronisiert und bei allen anderen live angezeigt. Technisch ist das spannend, weil es zeigt, wie schnell die Systeme an ihre Grenzen kommen: Wenn zwanzig Leute gleichzeitig zeichnen, entstehen sofort riesige Datenmengen. Es gibt verschiedene Arten von Realtime-Datenbanken, oder man kann eigene WebSocket-Server aufsetzen, aber es ist faszinierend zu beobachten, wie viel Traffic dabei tatsächlich entsteht.
Hast du das Projekt mal in einem Kontext gezeigt, in dem viele Leute gleichzeitig darauf zugegriffen haben?
Katharina: Ja. Together Online war meine Masterarbeit und ich habe es in der Abschlussausstellung gezeigt. Da stellt sich ja immer die Frage, wie man eine Website überhaupt ausstellt. Am Ende habe ich einen Tête-a-Tête Stuhl gebaut, auf dem man zu zweit sitzen und die Webseite auf dem eigenen Handy anschauen kann. In Momenten, in denen ich das Projekt vorgestellt habe, haben dann oft alle gleichzeitig mitgemacht – das hat dann eigentlich ziemlich gut funktioniert. Bis dann das Datenbank-Limit erreicht wurde, da bin ich dann schnell auf etwas anderes eingegangen und habe es später neu gestartet.
Julia: Ich habe bei interaktiven Projekten häufig die Sorge: »Was ist, wenn niemand damit interagiert?« Dann bleibt es leer, es passiert nichts. Aber vielleicht muss man das einfach riskieren.
Katharina: Ja, auf jeden Fall – einfach machen ist glaube ich das Richtige. Ich hatte das auch bei meinem Projekt mit der BuchBasel. Da gab es zum Beispiel eine partizipative Übersetzung, die richtig gut funktioniert hat. Was ich da hilfreich finde ist, wenn man solche interaktiven Sachen in einen Event-Kontext einbettet. Also zum Beispiel: Du machst einen Workshop oder eine Präsentation, erzählst kurz etwas dazu und in dieser Zeit probieren die Leute dann das Projekt online aus. Dann ist man weniger davon abhängig, dass zufällig jemand die Webseite findet. Denn das ist tatsächlich gar nicht so einfach – die Aufmerksamkeit im Netz richtig zu lenken, ist ja mittlerweile eine eigene Herausforderung.
Gibt es etwas, das du jungen Programmierer:innen oder Gestalter:innen mitgeben möchtest? Vielleicht etwas, das du selbst gern früher gewusst hättest?
Katharina: Ich finde es total wichtig zu vermitteln, dass man Dinge wirklich selbst machen kann – egal ob es darum geht, den eigenen Server aufzusetzen oder die erste eigene Webseite zu gestalten. Es ist einfach cool, das selbst in die Hand zu nehmen. Man muss nicht alles wissen, sondern kann Schritt für Schritt lernen.
Ich habe mal ein schönes Kompliment von einer Studentin bekommen: Sie meinte, sie findet es toll, dass ich auch nicht immer alles weiß, sondern dass wir gemeinsam herausfinden, wie etwas funktioniert. Und genau darum geht es ja. Man kann nie alles wissen, gerade beim Programmieren, wo es immer viele Wege gibt, etwas umzusetzen. Entscheidend ist, dass man lernt, wie man Probleme löst, wie man debuggt oder sich Dinge selbst beibringt. Und auch: Sich Support-Gruppen zu suchen ist total hilfreich. Es macht einfach mehr Spaß und es macht vieles leichter.