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]
[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. ↑
