Ein Außenblick auf die Kitodo-Entwicklung zum Release von Kitodo.Production 3.0
Aus der Entwickler-Werkstatt von Kitodo habe ich kürzlich die Geschichte von einer Bibliothekarin erzählt bekommen, deren Ärger über die Unzulänglichkeiten des Metadateneditors der alten Version offenbar einen geradezu legendären Status bekommen hatte: Immer wieder versuchte sie gewissenhaft, Informationen zu Besitzstempeln in Digitalisaten zu erfassen, und immer wieder schien alles zu funktionieren, aber die eingegebenen Informationen wurden immer wieder verschluckt – ihr fast liebevoller Kommentar, Kitodo sei halt ein kleiner „Stempelfresser“, scheint jedenfalls nachdrücklichen Eindruck gemacht zu haben.
Tatsächlich ist es gut, wenn Anwenderinnen einer Software deren Unzulänglichkeiten bemerken und sie diese auch aktiv anmerken – viel zu oft entwickeln sich aufgrund dieser Unzulänglichkeiten auch Workarounds. Bibliothekar*innen sind offenbar in gewisser Hinsicht tatsächlich ein genügsames Völkchen, wie der Aufsatz „Wie Bibliotheken digitalisieren – Bericht einer umfassenden Nutzungsevaluation“ suggeriert. Das kann allerdings dazu führen, dass sich zur Überwindung von Unzulänglichkeiten Trampelpfade entwickeln, die bei anstehenden Systemwechseln nicht hinterfragt werden – ich halte es zum Beispiel es nicht für ausgeschlossen, dass so mancher Wunsch an Folio als neues ILS im Kern auf einem Workaround um eine ursprüngliche Unzulänglichkeit beruht.
Aber zurück zu Kitodo: Dieser Tage wurde die Version 3.0 des Werkzeugkastens für Digitalisierungsprojekte releast, und das für meine Kollegen aus dem Kitodo-Entwicklungsteam natürlich ein wichtiger Meilenstein. Was den aktuellen Entwicklungsprozess aus meiner Außensicht auszeichnet, ist die Einbeziehung von Ergebnissen aus Usability-Tests mit echten Nutzer*innen, in diesem Fall Bibliothekar*innen. Diese wurden für die Vorbereitung auf die neue Version an 14 Standorten durchgeführt und bezogen auch andere Digitalisierungslösungen als Kitodo ein. Dabei wurden naturgemäß viele Ideen für neue Funktionalitäten entwickelt, die längst nicht alle in die neue Version einfließen konnten. Das gehört leider zu den Risiken und Nebenwirkungen von Usability-Tests: Ein Haufen Verbesserungsideen, den sich nur schwer vollständig in einen bestehenden Projektplan integrieren lassen – insbesondere bei kooperativen und/oder durch Drittmittel geförderten Projekten gibt es in der Regel schon zur Antragstellung eine relativ fest umrissene Vorstellung von dem fertigen Produkt, das idealerweise alle alten plus x neue Funktionalitäten aufzuweisen hat.
Die Einbeziehung von Nutzenden hilft aber dabei, die Vision von einem besseren Produkt lebendig zu halten: Kitodo soll Kulturgut sichtbar im Web sichtbar machen, und diese neuen Manifestationen von gedrucktem Material sollen so qualitätvoll wie möglich erschlossen sein. Daraus ergibt sich die z.B. Anforderung an die Software, die Schritte zur Qualitätsüberprüfung (in manchen Häusern offenbar bis zu vier an der Zahl!) bestmöglich zu unterstützen. Bibliothekar*innen müssen lernen, diese Anforderungen zu formulieren („Stempelfresser“ sendet eine klare Botschaft!) und im Dialog mit Entwicklungspartnern zu erläutern – und nötigenfalls auch entweder zu verteidigen oder (natürlich nur zugunsten eines größeren Ideals) aufzugeben. Das ist etwas, was die Kitodo-Community seit ihrer Gründung in 2012 sehr erfolgreich eingeübt hat und worüber sie gekonnt und authentisch zu berichten weiß (siehe hier oder hier) – was auch für die Entwicklungscommunities anderer Projekte wie VuFind oder Folio interessant ist zu verfolgen.
