Projekt Log
Kurs: MEI-M 26.1 Projektseminar (P-(D-)36633a Praxisseminar) im M.Sc. Medieninformatik, Sommersemester 2021
Kursleitung: Prof. Dr. Christian Wolff, M.Sc. Jakob Fehle
Projektteam: Sebastian Hahn, Isabell Röhr, Marie Sautmann
Die Arbeitsgruppe „Modernisierung des Zivilprozesses“ hat "umfassend untersucht, wie neue technische Möglichkeiten im Zivilprozess sinnvoll nutzbar gemacht werden können, um Gerichtsverfahren bürgerfreundlicher, effizienter und ressourcenschonender zu gestalten" (Diskussionspapier). Der Vorschlag der Arbeitgruppe ist ein digitales "Basisdokument", das der Strukturierung des Parteivortrags dient. Ziel der Strukturierung ist es, dass die Parteien und das Gericht den entscheidungserheblichen Sachverhalt gemeinsam nach bestimmten Vorgaben erarbeiten und so den Zivilprozess insgesamt effektiver, schneller und qualitativ besser führen können (Diskussionspapier).
Im Rahmen des Praxisseminars soll ein Prototyp für das digitale "Basisdokument" erarbeitet werden. Hintergrund und Projektablauf werden im Folgenden dokumentiert und während des Projektphase laufend aktualisiert.
Dem Diskussionspapier der Arbeitsgruppe "Modernisierung des Zivilprozesses" lässt sich folgender einführender Hintergrund entnehmen:
"Ein wesentlicher Teil der richterlichen Entscheidungsfindung ist die Erarbeitung des Sachverhalts. Bisher ist diese Arbeit davon geprägt, aus den Schriftsätzen der Parteien die relevanten Tatsachen herauszufiltern und das Streitige vom Unstreitigen zu trennen. Auch wenn die Anwälte hierbei unschätzbare Vorarbeit leisten, ist nicht zu verkennen, dass diese Art der Sachverhaltsaufbereitung erhebliche Nachteile hat: Zum einen besteht die Gefahr, dass die Richterin oder der Richter relevanten Vortrag unbeachtet lässt; diese Gefahr steigt mit der Komplexität des Geschehens, der Zahl der Schriftsätze und der Wiederholungsrate beim Parteivortrag. Zum anderen ist diese Art der Sachverhaltsaufbereitung zeitaufwändig und damit ressourcenhungrig. [...]
Im Zuge der anhaltenden und vordringenden Digitalisierung des Zivilprozesses bedarf es der Überprüfung dieser zivilprozessrechtlichen Strukturen. Schriftsätze in derzeitiger Form sind digital kaum verwertbar. Eine schlichte Abbildung der Papierakte in elektronischer Form mit Einführung der elektronischen Verfahrensakte ist aber nicht wünschenswert, da sie die Möglichkeiten einer digitalen Unterstützung des Prozesses ungenutzt verstreichen lassen würde. Nur durch die Entwicklung von Standards für den Parteivortrag kann das digitale Potential genutzt werden. [...]
Der Parteivortrag im Zivilprozess sollte unter den Bedingungen elektronischer Aktenführung in einem gemeinsamen elektronischen Dokument ("Basisdokument") abgebildet werden."
Der Vorschlag zum digitalen "Basisdokument" wird folgendermaßen grob zusammengefasst:
"Das Basisdokument umfasst das vollständige Parteivorbringen in tatsächlicher und rechtlicher Hinsicht einschließlich der Sachanträge. Der Kläger- und Beklagtenvortrag zum Lebenssachverhalt wird im Sinne einer Relationstabelle nebeneinander dargestellt. Er ist nach einzelnen Lebenssachverhaltselementen – i.d.R. chronologisch – und nicht nach Anspruchsgrundlagen gegliedert. Ergänzungen des Vortrags durch die Parteien werden unter Kennzeichnung der Nachträglichkeit an der sachlich passenden Stelle eingefügt. Das Gericht überwacht die zutreffende Einordnung des Lebenssachverhalts in die Relationstabelle und gibt rechtzeitig Hinweise zur sachgerechten Strukturierung des Vortrags in Teilabschnitten; nur ausnahmsweise greift es selbst in die Struktur ein. Der im Basisdokument enthaltene wechselseitige Sachvortrag wird im Laufe des Verfahrens durch Erklärung der Parteien oder mit Schluss der mündlichen Verhandlung verbindlich. Er bildet die Entscheidungsgrundlage und übernimmt so die Funktion des Tatbestands im Urteil. An dessen Stelle kann deshalb eine knappe Zusammenfassung des wesentlichen Sachverhalts treten, die die Entscheidungsgründe verständlich macht."
Detaillierte Ausführungen sind dem Diskussionspapier zu entnehmen.
Neben der Motivation der Richter:innen der Arbeitsgruppe bestehen jedoch durchaus auch Bedenken - vor allem aus der Anwaltschaft. Diese Bedenken beziehen sich (soweit bekannt) hauptsächlich auf die Einschränkung der Vortragsmöglichkeiten und die Vorgabe der Struktur durch die Klagepartei. Diese Bedenken sind hier festgehalten.
Das Forschungsprojekt "LegalTech im Zivilprozess: Parteivortrag im Basisdokument" dient der Erprobung und Fortentwicklung des von der durch die Präsident:innen eingesetzte Arbeitsgruppe "Modernisierung des Zivilprozesses" entwickelten sogenannten Basisdokuments als Instrument zur Strukturierung von Parteivortrag im Zivilprozess. Hierzu soll ein Prototyp geschaffen werden, in dem dann anhand mehrerer Musterakten die Praxistauglichkeit eines nach Sachverhaltselementen strukturierten Parteivortrags überprüft wird.
Zur Erreichung dieses Ziels arbeiten Rechtswissenschaftler:innen der Universität Regensburg (Lehrstuhl Prof. Dr. Althammer) und des Oberlandesgerichts Nürnberg, sowie Medieninformatiker:innen der Universität Regensburg (Lehrstuhl Prof. Dr. Wolff) zusammen.
Diese Projektgruppe (Isabell Röhr, Sebastian Hahn, Marie Sautmann) beschäftigt sich dabei besonders mit der Nutzung des Basisdokuments auf richterlicher Seite.
Folgende Meilensteine sind für das Forschungsprojekt auf Seiten der Medieninformatik geplant:
- Sammlung der Anforderungen aus den Besprechungen und Dokumenten
- Fokusgruppe/User Research
- Anforderungen werden mit der jeweiligen Nutzer:innen-Gruppe erhoben (Interviews oder Fokusgruppe)
- Anforderungspräsentation
- Vorbereitung: Gesammelte Anforderungen werden konsolidiert (nach Rolle und Themen gliedern)
- Treffen: Anforderungen werden durchgesprochen und priorisiert, das weitere Vorgehen wird festgelegt
- Designphase/Prototyping
- Anforderungen werden in Sketches umgesetzt und durch Feedback verfeinert
- Präsentation erster Lösungen
- Prototypen-Sketches werden präsentiert
- Dikussion/Festlegung, was ausgearbeitet werden soll
- Präsentation des finalen Prototypen
- nach längerer Phase der Implementierung/weiteren Ausarbeitung
Zu Beginn der Projektphase stand für die beteiligten Medieninformatiker:innen die Einarbeitung in die fachfremde Thematik.
In einem KickOff-Meeting wurden Grundlagen des Zivilprozesses, insbesondere die Einführung in die Funktion des Tatbestands und die richterlichen Aufgaben bei dessen Abfassung, sowie der Vorschlag des Basisdokuments vorgestellt.
Zur weiteren Einarbeitung beschäftigten sich interdisziplinäre Kleingruppen mit jeweils einer Musterakte. So konnten die Medieninformatiker:innen einen Einblick in den Ablauf des Zivilprozess und die richterliche Arbeit innerhalb des Prozesses gewinnen.
Im Rahmen des Projekts sollte Projektmanagement-Software genutzt werden.
Wegen fehlender Erfahrung war das Projektteam darauf angewiesen, verschiedene Tools zu explorieren und eine Wahl zu treffen. Diese Wahl fiel auf das dedizierte Projektmanagement-Tool asana. In asana lassen sich Aufgaben und Meilensteine anlegen und zuweisen. Die Aufgaben werden als Liste, Board oder Zeitleiste bzw. im Kalender angezeigt. Dokumente können angehängt, aber nicht bearbeitet werden.
Schon in den ersten Wochen der Projektphase wurde klar, dass im Projektverlauf viele zusätzliche Dokumente entstehen würden. Dass asana keine Möglichkeit der Arbeit an Dokumenten bietet - schon gar nicht der kollaborativen - stellte sich als deutliches Manko heraus.
Dieses Problem führte zu einer Umstellung auf github als Projektmanagement-Tool. In github lassen sich ebenfalls Aufgaben (issues) anlegen und zuweisen. Meilensteine können erstellt und Aufgaben den Meilensteinen zugeordnet werden. Einen großen (für uns entscheidenden) Mehrwert bietet das Wiki dieses Repos. Hier können alle dokument-artigen Inhalte strukturiert gesammelt werden. Es ist dabei jederzeit nachvollziehbar, wer von uns Aufgaben erledigt oder Inhalte hinzugefügt hat. Auch für die Entwicklung des Prototypen kann eventuell das Repository genutzt werden. In github können einzelne Aufgaben nicht mit einer Frist versehen werden. Die zugeordneten Meilensteine enthalten jedoch eine Frist, sodass der Projektverlauf trotzdem klar ist. Ob und inwieweit das ein Problem für das Projektmanagement ist, bleibt abzusehen.
Zur Erhebung der Anforderungen wurden (wie im Meilensteinplan ersichtlich) verschiedene Quellen und Methoden genutzt, die im Folgenden vorgestellt werden.
In einem ersten Schritt wurden mögliche Anforderungen aus dem Diskussionspapier der Arbeitsgruppe zusammengetragen. Diese Sammlung ist hier hinterlegt.
Auch aus weiteren Quellen wurden mögliche Anforderungen gesammelt (hier festgehalten).
Aus Besprechungsnotizen (KickOff- und Musterakten-Besprechung) konnten ebenfalls einige Anforderungen gewonnen werden. Diese Anforderungen sind nicht seperat festgehalten, fließen aber in die finale Sammlung von Anforderungen ein.
Um die Arbeitsweise und Anforderungen der Richter:innen (zentrale Nutzer:innen-Gruppe) genauer zu verstehen, wurden mit drei beteiligten Richter:innen und einem außenstehenden Richter semi-strukturierte Interviews geführt.
Interviewleitfaden und -protokolle sind hier hinterlegt.
Eine Fokusgruppe wäre womöglich interaktiver und kreativer verlaufen als Interviews. Da eine Fokusgruppe online jedoch schwieriger umzusetzen und Termine mit mehreren beschäftigten Menschen schwer zu kooridnieren sind, fiel die Wahl auf Interviews.
Die Interviews erwiesen sich als enorm nützlich, um die Arbeitsweise der Richter:innen zu verstehen und nachzuvollziehen wie sie bei der Erstellung der aktuell genutzten "Relationstabellen" vorgehen. Die Richter:innen konnten außerdem unabhängig voneinander ihre Ideen und Wünsche in Bezug auf das Basisdokument äußern, was zu durchaus verschiedenen Schwerpunkten in den Interviews führte. Als besonders interessant und für die Anforderungen wichtig stellten sich die verschiedenen Positionen heraus, die die Richter:innen jeweils innehaben.
Die in den Interviews gesammelten Anforderungen der Richter:innen an das digitale Basisdokument wurden in einem digitalen Affinitätsdiagramm aufbereitet und präsentiert. Dazu wurde das Tool MURAL genutzt.
Dazu wurden die einzelnen Anforderungen in einem ersten Schritt aus den Interview-Protokollen gesammelt. Jede Anforderungen wurde auf ein Kärtchen geschrieben und per Farbe einer:m Richter:in zugeordnet. Dabei wurde markiert, ob die Anforderung aus der Arbeit mit der Tabelle, der Akte oder eigenen Notizen abgeleitet ist oder direkt für das Basisdokument geäußert wurde.
In einem zweiten Schritt wurden die Anforderungen in Kategorien sortiert und Mehrfachnennungen gruppiert. Es ergeben sich die folgenden Kategorien: Verlinkungen, Strukturierung, Anmerkungen, Versionskontrolle, Nutzungskontext, kollaboratives Arbeiten, Automatisierung.
Im letzten Schritt wurden die Mehrfachnennungen zusammengefasst und durch die farbigen Punkte als Mehrfachnennungen markiert. Diese Markierung können für eine mögliche Gewichtung oder Priorisierung der Anforderungen berücksichtigt werden. Die Anforderungen in dieser letzten Ansicht sind alle auf das Basisdokument bezogen (egal, ob sie ursprünglich aus der Arbeit mit Tabelle/Akte/Notizen abzuleiten sind).
Die so aufbereiteten Anforderungen wurden in einer Besprechung der Forschungsgruppe vorgestellt (Meilensteinmeeting am 25. Mai).
Zur Aufbereitung der gesammelten Anforderungen wurde eine Tabelle angelegt, die hier zu finden ist. Auf zwei Tabellenblättern sind dort die gesammelten Anforderungen der Richter:innen und Anwält:innen mit Angabe der jeweiligen Quelle hinterlegt.
Die Anforderungen wurden in Form von user stories aufbereitet und in Kategorien gegliedert.
Die Priorisierung der Anforderungen wurde von den drei am Projekt beteiligten Richter:innen vorgenommen.
Diese systematische Sammlung bildet das Endergebnis der Anforderungserhebung.
Neben den Anforderungen an das Basisdokument wurden auch technische Inspirationen bzw. bestehende Tools, die als Inspiration für verschiedene Aspekte des Basisdokuments dienen können, gesammelt. Diese Sammlung ist hier hinterlegt.
Basierend auf den Anforderungen und deren Priorisierung (hier hinterlegt) wurde iterativ ein Papierprototyp erstellt.
Der Fokus lag dabei auf der privaten Ansicht des Basisdokuments. Aus Sicht der Richter:innen (Schwerpunkt dieser Arbeit) ist dieser Bereich besonders relevant. Die Ansicht der öffentlichen Version ist außerdem aus der privaten ersichtlich - in unserer Vorstellung enthält sie quasi die gleichen Elemente (Parteivortrag und Hinweise), ist aber durch Richter:innen nicht veränderbar.
Dieser erste Entwurf wurde gemeinsam überarbeitet (siehe blaue Anmerkungen im Bild), sodass im nächsten Schritt ein überarbeiteter Prototyp entstand.
Dieser Entwurf wurde um eine Startseite bzw. Landing Page ergänzt:
Diese Startseite ist eher der Vollständigkeit geschuldet - tatsächlich soll sich das Basisdokument in die eAkte eingliedern und muss über diese erreichbar sein. Wenn möglich, soll das im weiteren Verlauf der Arbeit berücksichtigt und das Design dementsprechend angepasst werden.
Grundsätzlich scheint es jedoch sinnvoll, dass über eine Art von Aktenverwaltungssystem die verschiedenen Versionen des Basisdokuments und seine Anlagen zugreifbar sind und neue private Versionen erstellt werden können.
Die private Ansicht wurde überarbeitet und um zwei Reiter für Lesezeichen und angehängte Dateien ergänzt. Weitere geplante Änderungen, die im Gruppengespräch aufkamen, sind rot markiert.
Es sei darauf hingewiesen, dass der Papierprototyp mehrere Aktionen gleichzeitig darstellt (also mehrere Aktionen, die auf Klick oder Hover in verschiedenen Bereichen passieren). Die dargestellte "Funktionalität" wird im Folgenden beschrieben.
Titelleiste. Titel des Dokuments bildet das Aktenzeichen. Ein Status zeigt die Verbindlichkeit des Dokuments an. An der Version beteiligte Personen sind rechts oben aufgeführt (im Bild: "ich"). Daneben steht der Status der Version (im Bild: "privat"). Ein Dropdown-Menü bietet Optionen wie "Ausloggen", "Mein Profil" und ähnliches.
Menüleiste. Eine klassische Menüleiste bietet verschiedene Optionen; bei "Datei" zum Beispiel den Export des Dokuments, bei "Bearbeiten" zum Beispiel undo, bei "Versionierung" die Option eine bestimmte Version des Dokuments anzusehen. Der Button "Anlagen" öffnet eine Ordnerstruktur, in der die Anlagen aufgeführt sind. Eine Suche ermöglicht die Freitextsuche innerhalb der Sachverhaltselemente.
Sachverhalt. Die Darstellung des Sachverhalts ist in zwei Spalten gegliedert: links die Klagepartei, rechts die beklagte Partei. Metadaten stehen jeweils auf der obersten Karte der Spalte. Einzelne Sachverhaltselemente (SE) sind ebenfalls auf Karten dargestellt und einer mittigen Nummer zugeordnet. SE können Überschriften und müssen Textkörper haben. Sie haben außerdem immer eine klar zugeordnete Autorenschaft (im Bld z.B. "anne.muster") und ein Datum (über die farbliche Hervorhebung des Datums wird eine Veränderung des SE angezeigt). In der privaten Version sind SE einklappbar. SE können Anlagen und Verlinkungen (im Bild z.B. "#3") enthalten.
Optionen. Als Richter:in stehen in der privaten Version des Basisdokuments verschiedene Optionen zur Strukturierung des Sachverhalts zur Verfügung.
- Bei Hover über eine Nummer kann ein Paar von Sachverhaltselementen per Menü (im Bild bei Nr. 1) als klar, streitig oder mit Fragezeichen markiert werden. Außerdem kann ein Link zur Nummer erzeugt oder eine Anmerkung zur Nummer geschrieben werden.
- Bei Klick auf ein Sachverhaltselement kann per Menü (im Bild bei Nr. 2 beklagt) eine Anmerkung, ein Hinweis oder ein Lesezeichen für das SE erzeugt werden.
- Beim Markieren von Text innerhalb eines SE können per Menü (im Bild bei Nr. 3 klagt) verschiedene Optionen zur Formatierung von Text genutzt werden.
In der rechten Spalte werden im ersten Reiter die Anmerkungen und Hinweise des:der Richter:in dargestellt. Sie können bearbeitet und gelöscht werden und sind ebenfalls mit Tags für Autorenschaft und Versionierung versehen. [Die Zuordnung der Kommentare zu einem SE oder einem SE-Paar wurde in diesem Sketch noch nicht klar vorgenommen.] Unabhängig von SE können auch "freie" Kommentare erstellt werden. Der zweite Reiter enthält die erstellen Lesezeichen (nach Nummer sortiert). Der dritte Reiter enthält hochgeladene Dateien und die Option zum Hochladen von Dateien. Am unteren Rand der rechten Spalte ist ein Menü zur Werkzeugauswahl: hier kann ein Werkzeug fix ausgewählt werden. Markierungen im Text werden dann mit der ausgewählten Formatierung versehen.
Dieser Prototyp wurde mit allen am Projekt beteiligten Medieninformatiker:innen besprochen und dient als Grundlage für die Erstellung eines digitalen Prototypen. Der Forschungsgruppe wurden die Sketches zur Illustration der Arbeitsweise präsentiert.
Zur Umsetzung eines ersten digitalen Prototypen nutzen wir das Online-Tool figma.
Die kostenlose Version ist zeitlich nicht begrenzt und unterstützt ein Teamprojekt. Diese beiden Kriterien waren für uns entscheidend - besonders auch die Möglichkeit zu kollaborativer Zusammenarbeit schien uns sehr wichtig.
Grundlage für diesen ersten digitalen Prototypen bilden die oben erklärten Sketches.
Der Vollständigkeit halber haben wir die Startseite auch in figma umgesetzt - wie eine Einbindung in die eAkte aussehen könnte bzw. wie das Portal für die eAkte aussieht, war zum Zeitpunkt der Erstellung noch unklar.
Neben der privaten Version, die bei den Sketches im Vordergrund stand, haben wir in figma auch eine öffentliche Version entworfen. Diese enthält keine Optionen zur Strukturierung und im rechten Reiter nur die öffentlichen Hinweise.
Weiterhin im Fokus steht jedoch die private Version (hier eine private Version, die "ich" und "katrin.richter" teilen). Die folgenden drei Bilder enthalten Ansichten der drei Reiter (Anmerkungen, Lesezeichen, Dateien) im richterlichen Bereich. In allen Bildern ist Nr. 2 als streitig markiert und ein Sachverhaltselement mit Lesezeichen markiert. Eine Verlinkung und ein Anhang ist dargestellt. Ebenso enthalten nicht alle SE eine Überschrift und ein SE ist mit einem längeren Textabschnitt versehen.
Das folgende Bild enthält verschiedene weitere Elemente: Nr. 3 ist als "klar" und Nr. 4 als "unklar" ("?") markiert. Bei Nr. 3 ist ein engeklapptes SE dargestellt.
Im folgenden Bild ist zu sehen, was bei Hover auf Nr. 1 geschieht: die zugehörigen SE werden hervorgehoben, ebenso die zugehörige Anmerkung. Ein Menü zu Auswahl von Aktionen erscheint unter Nr. 1.
Die Optionen eines einzelnen SE sind im nächsten Bild dargestellt: ein Menü zur Erstellung von Anmerkung, Hinweis oder Lesezeichen und ein markierter Text mit Menü für Formatierungsoptionen.
Der figma-Prototy kann hier angeschaut und ausprobiert werden. Teilweise wurden Funktionen interaktiv umgesetzt, sodass bestimmte Elemente geklickt oder gehovered werden können.
Die Umsetzung von Interaktivität, die für einen Prototypen essentiell ist, gestaltet sich in Figma leider sehr schwierig. Zum einen kann pro Element nur eine Aktion ausgeführt werden (also z.B. entweder Klick oder Hover), zum anderen muss für jede Interaktion ein neuer Frame oder ein neues Layer den veränderten Zustand der Anwendung abbilden. Diese beiden Punkte werden bei komplexeren Interaktionen schnell zu konkreten Problemen - schon der simple Prototyp mit wenigen Aktionen enthält ca. 15 Frames und Layers.
Um weitere Interaktionen umsetzen zu können, haben wir beschlossen für die weitere Arbeit zu Axure zu wechseln.
Zum figma-Prototypen wurde aber auch Feedback der gesamten Gruppe eingeholt. Im Rahmen eines Meileinstein-Treffens wurde der Prototypen allen beteiligten Medieninformatiker:innen und Rechtswissenschaftler:innen vorgestellt. Da der Rahmen nur bedingt Möglichkeit für persönliches Feedback bot, wurde erneut mural genutzt. Auf einem mural-Board wurden die einzelnen Screenshots des Prototypen hinterlegt und einzelne Elemente erklärt. Alle Beteiligten konnten dort über eigene Kärtchen Feedback hinterlassen.
Außerdem wurde den beteiligten Richter:innen eine annotierte Version des Prototypen zur Verfügung gestellt (hier hinterlegt). Mit zweien der Richter haben wir diese annotierte Version in Einzelinterviews besprochen, um detaillierteres Feedback zu erhalten und weitere Probleme aufzudecken.
Das gesammelte Feedback ist hier hinterlegt.
Da im zeitlichen Rahmen des Praxisseminars nur noch eine weitere Iteration des Prototypen möglich ist, bildet dieses Feedback den letzten Input für unsere Anforderungserhebung. An dieser Stelle soll deswegen erneut auf die strukturierten Anforderungssammlung in Form von user stories hingewiesen werden, die ebenfalls im wiki hinterlegt ist (hier).
Vor der weiteren Ausarbeitung des Prototypen mit Axure wurde von Victoria Böhm ein Sketching-Workshop mit den zuständigen Gruppen für die Richter- und Anwaltsperspektive durchgeführt.
Im Workshop sollten für jede Gruppe zwei konkrete Probleme aufgearbeitet werden. Für diese wurden in Form von prototypischen Screens bzw. Funktionalitäten Lösungen erarbeitet. Dabei wurden sowohl händische Sketches, als auch digitale (u. A. über das zuvor verwendete Tool figma) erstellt. Nach einem iterativen Durchlauf von zwei Runden waren am Ende jeweils Präsentationen der Ergebnisse für die andere Gruppe vorgesehen. Bevor der Prozess für die nächste Aufgabe wiederholt wurde, fand ein gemeinsamer Austausch über die entstanden Sketches statt.
Die konkreten Problemstellungen bezogen sich dabei auf Design- und Funktionalitätsfragen, die sich aus neuen Anforderungen und Erkenntnissen zur Gestaltung des Basisdokuments ergeben haben. So wurde beispielsweise eine mögliche reduzierte Ansicht des Basisdokuments, basierend auf den verwendeten Relationstabellen der Richter:innen bei der Erarbeitung von Fällen, gestaltet und diskutiert. Die Präsentation der Ergebnisse erfolgte erneut über Mural. Die entstandenen Sketches sind über folgende links einsehbar.
Die angesprochenen Änderungen und neuen Ansätze wurden in einer letzten Iteration des Prototypen in Axure umgesetzt.
Um den Prototypen mit sinnvollen Daten zu befüllen, haben wir in Zusammenarbeit mit Mitarbeitern des Lehrstuhls Prof. Althammer ein (recht simples) Beispielverfahren aufgearbeitet, das von einem beteiligten Richter zu Verfügung gestellt wurde. Anhand dieses Beispielverfahrens wird die Gegenüberstellung einzelner Sachverhaltselemente im Parteivortrag deutlich. Das Beispielverfahren ist recht simpel und wenig umfangreich. Deswegen bildet es die Realität der Rechtsprechung wohl nicht perfekt ab, bietet unserer Meinung aber eine gute und ausreichende Grundlage, um mithilfe des Prototypen ein Verständnis des digitalen Basisdokuments zu bekommen.
Startseite
Die Startseite konnte mithilfe einer Schulungsunterlage zum "elektronischen Integrationsportal" (eIP) vom IT-Servicezentrum der bayerischen Justiz neu gestaltet werden. Die Schulungsunterlage beschreibt eIP folgendermaßen:
Das elektronische Integrationsportal (eIP) vereint die elektronische Akte, den elektronischen Rechtsverkehr, Fachverfahren und Textsystem in einer einheitlichen Benutzeroberfläche. eIP ermöglicht so das ergonomische Zusammenspiel der einzelnen Komponenten sowie eine elektronische Akten- und Vorgangsbearbeitung und bietet darüber hinaus die Integration von Webdiensten, MS-Office Anwendungen und einem Strukturierungswerkzeug.
Da das digitale Basisdokument in die eAkte eingegliedert sein soll, wurde das auf der Startseite entsprechend umgesetzt.
Zusätzlich zu Buttons zum Wechsel zur offiziellen oder internen Version, zu Anlagen und Beweismittelliste enthält die Vorschau des Basisdokuments die Überblicksdaten zum Verfahren und die Option eine neue interne Version zu erstellen.
Offizielle Version
Hier im Screenshot ist der Anfang des Parteivortrags zu sehen. Die rechte Spalte enthält einen beispielhaften Hinweis. Außer diesem Hinweis sind alle Inhalte dem aufgearbeiteten Beispielverfahren entnommen und stellen sinnvolle Daten dar.
Interne Version
Anhand der internen Version sollen erneut die zentralen Elemente und geplanten Funktionen vorgestellt werden (die folgende Beschreibung ist der ersten Beschreibung des Prototypen weiter oben sehr ähnlich, schien uns an dieser Stelle aber erneut sinnvoll).
Titelleiste. Titel des Dokuments bildet das Aktenzeichen. Ein Status zeigt die Verbindlichkeit des Dokuments an. An der Version beteiligte Personen sind rechts oben aufgeführt (im Bild: "ich, katrin.richter"). Daneben steht der Status der Version (im Bild: "intern"). Ein Dropdown-Menü soll Optionen wie "Ausloggen", "Mein Profil" und ähnliches bieten.
Menüleiste. Eine klassische Menüleiste bietet verschiedene Optionen; im Screencast (unten verlinkt) sind die einzelnen Menüs zu sehen. Eine Suche ermöglicht die Freitextsuche innerhalb der Sachverhaltselemente.
Sachverhalt. Die Darstellung des Sachverhalts ist in zwei Spalten gegliedert: links die Klagepartei, rechts die Beklagtenartei. Allgemeine Informationen zum Verfahren stehen jeweils auf den obersten Karten der Spalte. Einzelne Sachverhaltselemente (SE) sind ebenfalls auf Karten dargestellt und einer mittigen Nummer zugeordnet. SE können Überschriften und müssen Textkörper haben. Sie haben außerdem immer eine klar zugeordnete Autorenschaft (im Bild z.B. "Kurt Huber") und ein Datum. Über die farbliche Hervorhebung des Datums wird eine Veränderung des SE angezeigt (in unserer Vorstellung öffnet sich bei Klick auf ein farbiges Datum ein PopUp, das die Historie des SE darstellt). In der internen Version sind SE einklappbar. SE können Beweismittel, Anlagen und Verlinkungen enthalten.
Optionen. Als Richter:in stehen in der privaten Version des Basisdokuments verschiedene Optionen zur Strukturierung des Sachverhalts zur Verfügung.
- Bei Klick auf eine Nummer kann ein Paar von Sachverhaltselementen per Menü als klar, streitig oder mit Fragezeichen markiert werden. Außerdem kann ein Link zur Nummer erzeugt oder eine Anmerkung zur Nummer geschrieben werden.
- Bei Klick auf ein Sachverhaltselement kann per Menü eine Anmerkung, ein Hinweis oder ein Lesezeichen für das SE erzeugt werden.
- Beim Markieren von Text innerhalb eines SE können per Menü verschiedene Optionen zur Formatierung von Text genutzt werden (diese Option ist in Axure leider nicht umsetzbar, soll der Vollständigkeit halber aber hier erwähnt sein).
In der rechten Spalte werden im ersten Reiter die Anmerkungen und Hinweise des:der Richter:in dargestellt. Sie können bearbeitet und gelöscht werden und sind ebenfalls mit Tags für Autorenschaft und Versionierung versehen. Unabhängig von SE können auch "freie" Kommentare erstellt werden (per Plus-Button). Der zweite Reiter enthält die erstellen Lesezeichen (nach Nummer sortiert). Der dritte Reiter enthält hochgeladene, eigene Dateien und die Option zum Hochladen von Dateien. Am unteren Rand der rechten Spalte ist ein Menü zur Werkzeugauswahl: hier kann ein Werkzeug fix ausgewählt werden. Markierungen im Text werden dann mit der ausgewählten Formatierung versehen (auch hier: diese Option ist in Axure leider nicht umsetzbar, soll der Vollständigkeit halber aber hier erwähnt sein).
Aus dem Gespräch mit den Richter:innen zum figma-Prototyp hat sich der Wunsch ergeben, die SE nach bestimmten Arten von Markierungen filtern zu können. Vorstellbar sind Filterungen nach streitigen oder unstreitigen Punkten oder nach vorgenommenen Markierungen. Im Prototypen haben wir daher die einzelnen streitigen Punkte mit einer gelben Markierung zu sehen (im oberen Bild zu sehen). Der nächste Screenshot enthält eine nach diesen gelben Markierungen gefilterte Ansicht (erreichbar über den Menüpunkt "Ansicht" > "Gelbe Markierungen").
Der Axure-Prototyp ist über diesen Link erreichbar.
Dort kann auch durch das Dokument gescrollt und geklickt werden. Mögliche Interaktionen sind in diesem Screencast zu sehen.
Neben unserer Arbeit als Medieninformatiker:innen im Forschungsvorhaben wurde die Idee des Basisdokuments von den Jurist:innen auf verschiedenen Tagungen und in Diskussionsrunden vorgestellt.
Zur weiteren Präsentation des Projekts ist ein Imagefilm geplant, der die Idee und die entstandenen Lösungsansätze bzw. die Prototypen vorstellt.
Unser Beitrag zu diesem Film wurde mit Victoria Böhm in einem Workshop zum Erstellen von annotierten Storyboards geplant. Das entsprechende mural-Board mit den erarbeiteten Ergebnissen ist hier zu finden. Wie dem mural zu entnehmen ist, wird unser Prototyp genutzt, um die Möglichkeiten des Basisdokuments für Richter:innen zu demonstrieren.
Der oben verlinkte Screencast diente auch zur Planung des Films bzw. zur Darstellung der möglichen Interaktionen.
Schwierigkeiten und Verzögerungen
Eine typische Schwierigkeit, die teils zu Verzögerungen geführt hat, ist die effektive Zusammenarbeit in großen Gruppen. Die Treffen mit allen am Forschungsvorhaben beteiligten Personen waren zum Austausch und zur Planung des Vorgehens sehr wichtig, für detaillierte Rückmeldung zu unserer Arbeit aber oft ungeeignet. Dank des großen Engagement der beteiligten Richter:innen waren aber mehrfach Gespräch zu Anforderungen und Entwürfen möglich, sodass zu allen wichtigen Punkten Feedback eingeholt werden konnte.
Neben Verzögerungen durch Termine ergab sich die größte Verzögerung durch unseren Wechsel der Prototyping-Software von Figma zu Axure. Dieser Wechsel hat sich aus unserer Sicht aber gelohnt, weil im Axure-Prototypen einige Interaktionen umsetzbar waren, die in figma enormen Aufwand bedeutet hätten. Einige Limitierungen enthält Axure aber leider doch, sodass nicht alle geplanten Interaktionen umgesetzt sind (z.B. kann in Axure nicht auf das Markieren von Text reagiert werden).
Arbeit im Team
Zur Kommunikation im Projektteam haben wir einen Chat in Discord genutzt. Kommuniziert haben wir darüber sowohl asynchron im Chat, als auch synchron in teils wöchentlichen Treffen und kurzen Absprachen bei Bedarf. Die zeitweise sehr regelmäßigen Sprechstunden haben wir als sehr positiv empfunden, bspw. um unkompliziert Absprachen zum weiteren Vorgehen zu treffen.
Github als verwendetes Dokumentationstool hat für uns sehr gut funktioniert. Hier im Wiki lassen sich alle textbasierten Informationen (mit Bildern) strukturiert auf verschiedenen Seiten sammeln. Das Styling per Markdown im Schreibfluss ist kurz gewöhnungsbedürftig und dann ungemein komfortabel. Zur Sammlung von Dateien haben wir zusätzlich einen Drive-Ordner verwendet. Zur Abgabe ist ein Push in dieses Repo geplant, sodass alle relevanten Dateien an einem Platz sind.
Ausblick und nächste Schritte
Neben dem entstehenden Imagefilm ist für das Vorhaben eines digitalen Basisdokuments im Zivilprozess in nächster Zeit vermutlich insgesamt viel Öffentlichkeitsarbeit zu leisten, um Akzeptanz und Konzeptverständnis bei allen betroffenen Personengruppen (vor allem auch auf Seiten der Anwält:innen) zu erreichen. Zur Konzeptvermittlung stellt unser Prototyp sicher einen guten Ausgangspunkt dar.
Darüber hinaus kann unsere Methodik inklusive der entstandenen "Teilergebnisse" (z.B. User Stories bei der Anforderungsanalyse) auch zukünftig, bei weiterer Forschung am digitalen Basisdokument, als Hilfestellung dienen. Erarbeitete Dokumente könnten beispielsweise in einem breiteren Kontext (größerer Korpus / mehr befragte Personen) erweitert werden.
Wenn das Projekt weiterhin verfolgt wird, schiene uns eine Erweiterung des Prototypen jedoch notwendig:
- einige der angedachten Interaktionen sind zwar hier im Log festgehalten, aber aus Zeitmangel noch nicht umgesetzt
- der Prototyp enthält nur ein einzelnes Beispielverfahren, das nicht sehr komplex ist
- der "gesamte" Workflow von der Erstellung der Klageschrift bis zur richterlichen Arbeit am Dokument zur Verhandlungsvorbereitung kann im Prototypen nicht nachvollzogen werden (eine Zusammenführung der beiden entstandenen Prototypen scheint sinnvoll)
- Axure ist nicht geeignet, um einen Prototypen mit allen geplanten Funktionen umzusetzen, sodass dazu ein weiteres Mal die Software gewechselt werden müsste
- BEVOR jedoch eine neue Iteration des Prototypen umgesetzt wird, wäre natürlich eine ausführlichere Evaluation des bestehenden Prototypen sinnvoll