Die Edition in 3,5 Sekunden

Von Lena-Luise Stahn

Frühling über dem Bergischen Land, strahlender Sonnenschein, um die 20 Grad – höchste Zeit für die alljährliche – inzwischen schon als traditionsreich zu bezeichnende – Winterschule des Instituts für Dokumentologie und Editorik[1] in Kooperation mit dem Team DH@BUW und dem Graduiertenkolleg 2196 „Dokument – Text – Edition“[2].

Denn wie sollte es anders sein: Diese einwöchige Lehrveranstaltung, dazu gedacht, mit ihren Themen rund um Digitale Editionen und DH-Themen aller Art die sich ewig hinziehende Zeit der Spätwintertage zu verkürzen, wartet mit wunderbarem Frühlingswetter auf, das als laues Lüftchen durch die Corona-bedingt weit geöffneten Fenster hereinweht.

Denn eine Neuerung gibt es dieses Jahr: Es wird in Präsenz geschult! Rund 25 Auserwählte haben das Glück, nach fast zwei kompletten Zoom-Jahren diese als eine der ersten Präsenzveranstaltungen zu besuchen – lediglich mit der Autorin dieses Textes erlaubt sich das Schicksal einen “Spaß” und lässt ihren Covid-Test auch nach mehr als zwei Wochen weiterhin zwei Striche im Sichtfensterchen anzeigen. Also weiter Zoom. Aber trotzdem: Besser noch ein wenig länger in den Rechner gucken als gar nicht teilnehmen.

Und es hat sich gelohnt! Das diesjährige Thema “Digitale Editionen – Interface Design” hat nicht nur Interessierte aus allen Ecken der DH-Landschaft angezogen, sondern auch ein internationales Team an Dozierenden zusammenfinden lassen, jede*r für sich mit umfassender Expertise ausgestattet. So entstand ein Wochenprogramm, das an Abwechslungsreichtum und Kreativität seinesgleichen sucht: Von der Theorie und Konzeption digitaler Oberflächen über Mockup- und Prototypphase bis hin zum Expert*innenbericht aus der Praxis war alles dabei. Und die “Studis” waren trotz des mehr als vollen Programms immer äußerst engagiert bei der Sache.

Als Thema sollte diesmal nicht die Editionsarbeit oder der zu edierende Text im Fokus stehen, sondern das, womit sich jede Digitale Edition im Web präsentiert: das Interface. Denn obwohl es als das Aushängeschild gelten kann, fällt seine Entwicklung meist als “Nebenprodukt” der Editionsarbeit ab.

Wout Dillens hat 2018 die zentrale Bedeutung des Interfaces auf den Punkt gebracht:

“This is what makes (web) design such an important aspect of the digital scholarly editing process: the interface is the first thing the user will notice, and it will determine the way in which she will read the rest of the edition – if indeed at all.”[3]

Oft ist das Interface von einer der (zu) wenigen DH-Stellen im Projekt “auch noch” zu entwickeln: Neben der Zuständigkeit für Datenmodell, Transkriptions- und Datenmanagementworkflows und der Software-Infrastruktur insgesamt steht sie vor der Herausforderung, mit viel zu wenig Zeit für kreative Muße eine Oberfläche, eine Schnittstelle zu schaffen, über die die durchaus unterschiedlich interessierte Öffentlichkeit Zugang zum edierten Material bekommt.

Denn darum geht es: Das Interface als aktiven Teil der Edition zu begreifen, der für sich als Aussage zu einem Text steht. Als Aussage, die die kulturelle Bedeutung des Materials hervorhebt, ein Verständnis des Materials unterstützt und dazu ermutigt und vor allem Lust macht, sich kritisch damit auseinanderzusetzen.

Die “Interface Literacy”[4] des Publikums spielt dabei eine große Rolle: Die Edition kann nur verstanden werden, indem sie in Bezug gesetzt wird zum kulturellen Kontext, in dem sie entstanden ist. Diesen Bezug möglichst lesbar zu gestalten steht als Aufgabe hinter jedem Interface.

Grundlage dafür sind zwei Aspekte: erstens sich selbst darüber bewusst werden und zweitens den Nutzer*innen sichtbar machen, welche impliziten (Un-)Absichten des Editions- und/oder Entwicklungsteams in der Anwendung stecken: Einerseits liegt eine spezifische Sicht auf die Welt zugrunde (“Was wird absichtlich nicht gesagt?”), andererseits zwingt das Medium der digitalen Webapplikation als grundsätzlich anders funktionierend, aber durchaus buch-ähnlich angewendet werden wollend, zu einer “unconscious incompetence”[5] des Editions- und Entwicklungsteams und damit möglicherweise zu einer anderen Aussage, als die, die in “traditioneller” Printform gemacht worden wäre.

Und dann darf natürlich das Ziel nicht aus den Augen verloren werden: Allgemein soll sich die Entwicklung an den bestehenden Nutzungsinteressen orientieren. Diese zu erheben stellt sich allerdings nicht selten als einigermaßen große Hürde heraus, denn häufig wird erst während der Nutzung klar, was die Anforderungen an eine solche Webapplikation eigentlich sind. Der Entwicklerin kommt also die Aufgabe zu, mögliche Anwendungen und Anforderungen im Laufe der technischen Umsetzung zu antizipieren.

Bei diesen, im Verlauf der Implementation immer wiederkehrenden, „Verhandlungen mit Stakeholdern“ kommt es auf die Überzeugungskraft der Entwicklerin an: Da sie sich früher oder später zwangsläufig als domänenfern outen muss, muss sie die ihr auferlegte Funktion im Projekt, die Anforderungen für die Domäne festzulegen und den Fachleuten zu sagen, was sie benötigen, auf diese übertragen und von ihnen fordern, dass sie selbst die requirements festlegen. Denn gerade bei der Priorisierung ist die Gefahr groß, dass es zu Fehlentwicklungen kommt, wenn der Entwicklerin als einziges Argument die Kosten-Nutzen-Rechnung bleibt und die Umsetzung von features, wenn auch unabsichtlich, quasi gegeneinander ausspielt. Die Entscheidung für und gegen Funktionalität muss letztendlich von der Fachcommunity getroffen werden.

Gleichzeitig führt die Beteiligung der fachlichen Projektseite zu erhöhter Komplexität/Delinearisierung/Hypertextualität als inhärenten Charakteristika der Digitalen Edition. Immer wieder müssen die beiden Pole in Relation gesetzt werden: auf der einen Seite die Nutzer*innen in ihrer Bewegung und Interaktion mit dem Angebot so wenig wie möglich beschränken, auf der anderen Seite so viel wie nötig vereinfachen. Die Nutzer*innen müssen den Aufforderungscharakter, die Affordanz des Interfaces spüren und dürfen weder das Interesse verlieren noch in einem Editions-Produkt mit zu hohem Anspruch „verloren gehen“.

Dieser funktionellen Bedeutung steht zumeist die, die der Entwicklung des Interfaces beigemessen wird, im krassen Gegensatz gegenüber. Nicht wenige in DH-Projekten arbeitende Entwickler*innen werden sich schon das ein oder andere Mal mit dem Dilemma konfrontiert gesehen haben, ohne eigentlich design-geschultes Auge “das beste aller Editions-Interfaces” bauen zu müssen, konzeptionell durchdacht, elegant implementiert und auf dem aktuellsten Stand, was UX und UI angeht. Nach einer spezifisch in die Design- und Webentwicklungsrichtung gehenden Ausbildung wird dabei nicht gefragt, stattdessen werden mit der “ersten” umgesetzten Edition innovative Ideen erwartet und Knowhow vorausgesetzt.

Dass das aber alles andere als trivial ist und ein Interface nicht einfach „nebenbei“ entsteht, sondern im Gegenteil als Kern einer erfolgreichen Web-App angesehen werden sollte, wird deutlich, wenn man sich die Konkurrenz vor Augen führt. Denn nicht nur an vergleichbaren Editionen muss sich die eigene Plattform messen, das Web insgesamt hat Nutzungsverhalten und Erwartungen geprägt und gibt die Standards und Konventionen vor, denen sich die eigene Entwicklung nicht entziehen kann. Und dabei geht es vor allem um eins: Nutzer*innen nicht durch Über-Komplexität abzuschrecken. Schnell, sleek und intuitiv muss es sein!

Die diesjährige Winterschule hat versucht, diese Vielfalt an Problematiken zu thematisieren und der oft vorherrschenden Unsicherheit und Unwissenheit in diesem Bereich zu begegnen. Welche Herausforderungen gibt es? Welche Ansprüche und Verpflichtungen stellen Material, Nutzerschaft und Design-Prinzipien? Woran können sich Entwickler*innen einer Digitalen Edition orientieren?

Das Programm[6] sah alle Stationen eines erfolgreichen Entwicklungsprozesses vor: von der theoretischen und konzeptionellen Ebene über Wireframing, Mockups und HTML-Prototypen bis hin zu Learnings aus der Praxis und abgerundet durch zwei Abendvorträge über aktuelle Entwicklungen des Fachs.

Nach einer – äußerst präsenten – Woche voll des Diskutierens, Übens und Erarbeitens eigener kleiner Entwurfsprototypen fällt es schwer, ein simples Fazit zu ziehen. Vor allem wurde deutlich: Allgemeingültige, immer funktionierende Leitlinien und Vorgehensweisen für die Entwicklung des Interfaces für Digitale Editionen gibt es nicht – dieser Erwartung steht allein schon die Vielfalt an Editionen und Material im Weg. Jede Edition bringt ihre eigenen Anforderungen und Eigenarten mit, ihr eigenes fachspezifisches Publikum. Auf all dies gilt es individuell einzugehen. Die Woche hat viele hilfreiche Werkzeuge, Informationen und Denkrichtungen aufgezeigt, das eine, passende Interface kann ein Editionsvorhaben jedoch nur für sich selbst entwerfen. Und sollte dies immer in dem Wissen tun, dass es wesentlicher Bestandteil, nicht nur Schmuck, der Edition selbst ist:

“We recognize that digital artifacts have meaning, not just utility, and may constitute original contributions to knowledge in their own right.[7]


[1] https://www.i-d-e.de/

[2] https://www.editionen.uni-wuppertal.de/de/

[3]  Dillen, W. (2018). The Editor in the Interface: Guiding the User through Texts and Images. Scholarly Digital Editions as Interfaces, 12, 35-60, S. 42.

[4] Andrews, T. L.; Van Zundert, J.J. (2018). What are you trying to say? The interface as an integral element of argument. Digital Scholarly Editions as Interfaces, 3-34, S. 28.

[5] Andrews, T. L.; Van Zundert, J.J. (2018). What are you trying to say? The interface as an integral element of argument. Digital Scholarly Editions as Interfaces, 3-34, S. 4.

[6] Für einen ausführlichen Überblick sei an dieser Stelle verwiesen auf den zum Zeitpunkt der Veröffentlichung dieses Beitrags noch nicht erschienenen Bericht von Jana Klinger und Nadine Sutor auf HSozKult.

[7] Galey, A.; Ruecker, S. (2010). How a prototype argues. Literary and Linguistic Computing, 25. Jg., Nr. 4, 405-424, S. 407.

Lehre @DH-BUW // Hello World! Webtechnologien für Geisteswissenschaftler*innen // Wintersemester 2021/2022 (hybrid)

Nadine Sutor

Im vergangenen Wintersemester hat sich der Lehrstuhl für Digital Humanities am Standort Wuppertal dazu entschieden eine praktische Übung für interessierte Studierende aus allen geisteswissenschaftlichen Disziplinen anzubieten, die einen ersten Einblick in die drei gängigen Webtechnologien HTML, CSS und JavaScript lernen, oder diese überhaupt erst einmal verstehen erhalten wollen.

Anspruch und Ziel der Übung

Der Fokus der Veranstaltung lag auf dem Entwurf, der Entwicklung und der Gestaltung einer kleinen, aber feinen interaktiven Webanwendung. Diese drei Stufen gliederten die alle zwei Wochen abgehaltene Übung und bildeten einen Workflow ab, in dem die jeweils passende Technologie vorgestellt, erlernt, diskutiert und ausprobiert wurde. Angefangen von den Basics in HTML und CSS über JavaScript bis hin zu Design-Tools sollten die Studierenden einen Einblick in die Frontend-Webentwicklung bekommen und deren Grundfunktionen und Zusammenspiel kennenlernen. Ziel war es, ein allgemeines Grundverständnis für Sinn und Zweck sowie Bedeutung (abseits der „normalen“ Webentwicklung im Berufsfeld der IT) dieser Technologien mit Blick auf die Umsetzung primär geisteswissenschaftlicher Forschungsprojekte zu schaffen. Denn man weiß, dass jedes Interface, welches Informationen bereitstellt und mit seinen Nutzer*innen in Kontakt tritt, nicht nur funktionell und interaktiv, sondern auch „gut aussehen“ und optisch ansprechend sein sollte. Darüber hinaus muss es seinen Inhalten, dem bereits wissenschaftlich erschlossenen und digital aufbereiteten Kulturerbe, in seiner digitalen Präsentation gerecht werden.

Exkurs: Was ist ein „Backend“?

Der Fokus der Übung lag klar auf der Oberflächengestaltung der Webanwendung. Damit die Anwendung reibungslos funktioniert und erreichbar ist, muss klar sein, was „hinter den Kulissen“ passiert. Daher wurde in einem kleinen Exkurs das sogenannte Backend als technische Infrastruktur thematisiert. Stephan Makowski, Wissenschaftlicher Mitarbeiter in den Digital Humanities an der Bergischen Universität Wuppertal (BUW), erläuterte das Client-Server Prinzip am Beispiel unseres Lehrstuhl-Servers. Anschließend erklärte er, was es mit dem sogenannten OSI-Modell auf sich hat, welches einem „Schicht-Prinzip“ folgt und sowohl den Netzzugriff, die Verbindung, als auch die Kommunikation zwischen Client, z.B. einem Browser, und dem Webserver abbildet. Darüber hinaus diskutierten wir einige gängige Protokolle wie HTTP zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz und SSL, ein Netzwerkprotokoll zur sicheren Übertragung von Daten.

HTML und CSS: Basics der Frontend-Webentwicklung

Anhand der Frankfurter Postzeitung [1], eine der ersten und langlebigsten Zeitungen im Erscheinungszeitraum von 1615 bis 1866, ging es in den ersten Einheiten darum ein HTML-Grundgerüst für den Dokumentenaufbau zu entwickeln. Jede*r der Teilnehmer*innen sollte je eine der vierseitigen Ausgaben aus dem Jahrgang 1618 und 1619 auf Basis von HTML so aufbereiten, dass sich die Inhalte via CSS einfach layouten und gestalten ließen.

Interaktive Komponenten mit JavaScript

Um die Anwendung mit einigen dynamischen Komponenten auszustatten und auf diese Weise  zu erweitern, sollten gemeinsam einige leicht umsetzbare Features entwickelt werden: Die Implementierung eines Buttons für das automatisierte Highlighting bestimmter Textstellen, sowie das ein- und ausblenden des Faksimiles und/oder der Transkription. Wie beim Zusammenspiel von HTML und CSS ging es in dieser Einheit um eine ähnliche Frage: Wie beeinflusst JavaScript die Dokumentstruktur und wie lässt sich diese manipulieren? Sowohl den Theorieblock, als auch die hands-on Session leitete Lena Stahn, Wissenschaftliche Mitarbeiterin des Lehrstuhls und Teil des Akademieprojekts „Niklas-Luhmann Archiv“. Die Studierenden sollten in mehreren praktischen Einheiten lernen, wie sie das DOM, das Document Object Model, anreichern und auf diese Weise bestimmte Elemente interaktiv gestalten.

Einzelobjektdarstellung des Jahrgangs 1618, Ausgabe 9. Transkription und Digitalisat wurden mit HTML, CSS und JavaScript umgesetzt und visualisiert.

GitHub-Repository und Versionierung

Direkt zu Beginn der Übung ging es uns, abseits der praktischen Arbeit am Code, um die Vermittlung des Mehrwerts und der Notwendigkeit eines Versionskontrollprogramms. Nach Aufsetzen eines projekteigenen GitHub-Repositorys versionierten und aktualisierten die Studierenden ihre Daten nach Abschluss der produktiven Arbeit mit dem GitHub-Client. Auf diese Weise blieb jede Änderung stets nachvollziehbar. 

Mockup-Design mit Figma

Als Alternative beziehungsweise Vorstufe zur unmittelbaren produktiven Arbeit am Code haben wir uns das Design-Tool Figma angesehen. Eine detailliert getreu ausgearbeitete Vorlage, ein Entwurf, ein sogenannter Mockup, dient als Orientierung im Entwicklungsprozess der späteren Website. Die Ausarbeitung eines solchen Mockups ist ein gängiger Schritt im UI/UX-Design und soll den Entwickler*innen in Form eines vorgefertigten Prototyps als Unterstützung dienen, um von dem Ursprungsdesign nicht abzuweichen.

Mit Figma erstellter Entwurf einer Startseite für die digitale Präsentation der Frankfurter Postzeitung.

Fazit

Das eingeholte Feedback von den Studierenden fiel überwiegend positiv aus Es entstand der Eindruck, dass vor allem die JS-Komponente für viele eine neue Thematik darstellte. Denn HTML und CSS hat jede*r „irgendwo schon einmal gehört“. Für einige war der Einstieg und die anschließende Weiterentwicklung des Datenmodells schwieriger. Mit angeleiteten Übungen, der eigenständigen praktischen Arbeit am Nachmittag und einigen Wiederholungseinheiten versuchten wir, ausreichend Hilfestellung zu geben und jede*n dort abzuholen, wo er/sie feststeckte. Aufgrund der überschaubaren Teilnehmerzahl gelang uns eine gute Einzelbetreuung. Kritik wurde bezüglich des Umfangs der behandelten Technologien geäußert. Die Anzahl der Tools und Programme wirkte vereinzelt überfordert und nach Meinung einiger Teilnehmer*innen bliebt zu wenig Zeit für eine tiefergehende Einarbeitung. Eine Fortsetzung und/oder thematische Erweiterung der Übung ist vorstellbar und könnte durch ein regelmäßiges Angebot weitere interessierte Geisteswissenschaflter*innen anlocken. In Abwechslung zu den bis dato behandelten Frontend-Technologien wäre die Konzeption einer Veranstaltung denkbar, die sich ausschließlich auf das Backend beschränkt und beispielsweise die in den Digital Humanities relevanten Datenbanksysteme und Server behandelt – abhängig vom jeweiligen Forschungsinteresse.


[1] Link zu den Digitalen Sammlungen der ULB Bremen: https://brema.suub.uni-bremen.de/zeitungen17/periodical/titleinfo/934741 (03.03.2022)

Suche in OpenEdition Search

Sie werden weitergeleitet zur OpenEdition Search