Mit einem neuen KI-Feature zur Bildklassifikation, das ab Donnerstag Nacht bereit stehen wird, versuchen wir aus unseren Fehlern zu lernen. Bevor dieses vorgestellt wird aber seien die damaligen Fehler besprochen.

Bildklassifikation, Versuch 1

Im ursprünglichen Anlauf zur Bildklassifikation wurden alle Abbildungen zu allen Objekten entweder beim Upload oder über eine gezielt dazu eingerichtete Seite klassifiziert.

Die Abbildungen wurden dabei an ein KI-Modell übergeben, und seine (englischen) Ausgaben mit dem Schlagwort-Katalog von museum-digital abgeglichen. Die gefundenen Schlagworte wurden dann als Schlagwort-Vorschläge angeboten.

KI braucht passende Hardware

KI-Tools arbeiten am besten auf Grafikkarten. Das, was ein herkömmlicher Webserver nicht hat, ist eine Grafikkarte. Also entschieden wir uns für den offensichtlich klugen Weg: Mithilfe von Tensorflow.js wurden die Berechnungen auf die Geräte der gerade eingebenenden User ausgelagert.

Gut: Die Berechnungen liefen nicht mehr auf der ungeeigneten Server-Hardware. Schlecht: Wer einen durchschnittlichen PC in einem kommunalen Museum kennt, sollte wissen, dass er vielleicht eine Grafikkarte haben mag – aber dann höchstwahrscheinlich auch nur eine Office-Grafikkarte aus dem untersten Preissegment. Und vor allem 2021 waren die meisten Laptops nicht besser für KI-Anwendungen geeignet, als die Server-Hardware von museum-digital. Ergo: Die Berechnungen zur Bildklassifikation dauerte lange(!).

Workflows

Schlimmer noch: Die Berechnungen zur Bildklassifikation waren blockierend. D.h., dass man in dem Browserfenster, in dem die Berechnungen ausgeführt wurden, nicht weiter arbeiten konnte. Dadurch, dass die Bildklassifikation in den Objekt-Ersterfassungs-Workflow eingebaut war, verlangsamte sie diesen deutlich.

In der Reflexion lässt sich feststellen, dass, solange keine wirklich gute Hardware zur Verfügung steht, KI-Anwendungen zu Anfang oder zu Ende des Erschließungsprozesses und von diesem getrennt / im Hintergrund eingesetzt werden sollten. Zu Anfang der Erschließung, wenn nur die Inventarnummer und hoffentlich ein Bild vorliegen, kann z.B. Bilderkennung nützlich sein, um Eingabehilfen und Vorschläge zu generieren. Die erratische Natur von KI – meistens richtig, mal falsch, und bei jedem Durchlauf unterschiedlich – spielt somit keine Rolle, weil es sich nur um später von Menschen nachbearbeitete, akzeptierte oder abgelehnte Vorschläge handelt.

Zu Ende des Erschließungsprozesses kann KI sinnvoll eingesetzt werden, um einerseits auf Basis der vorliegenden Daten zusätzliche Datenfelder zu befüllen (KI-generierte Objektbeschreibungen mit Zwischenspeicherung) oder zusätzliche Funktionen, die naturgemäß schwammigen Kategorien folgen anzubieten (Sortierung nach Ästhetik von Thumbnails).

Der Einsatz von KI-Tools in Echtzeit, wie er im ursprünglichen Bildklassifikations-Tool erwartet wurde, kann mit entsprechend guter Hardware sinnvoll sein. Die im Juni vorgestellte, in Zusammenarbeit mit dem Zuse-Institut und digiS testweise bereitgestellte, Erstellung von Objektbeschreibung auf Basis bestehender Metadaten ist ein gutes Beispiel. Im Zuse-Institut kommt hierzu eine Nvidia GH-200 zum Einsatz. Der Preis der Hardware alleine übersteigt das Jahresbudget vieler Museen.

Die Wahl des Modells sei weise getroffen

Weil eben die Hardware unzureichend war und wir eine Bildklassifikation in Echtzeit ermöglichen wollten, waren wir bei der ursprünglichen Bildklassifikation auf kleine, sehr effiziente Modelle angewiesen. Nach einigem Suchen endeten wir bei MobileNet.

MobileNet kommt zwar prinzipiell aus dem richtigen Bereich (Objekterkennung), hat aber offensichtlich sehr anders gelagerte Trainingsdaten. Straßenschilder und Tiere werden auch bei der vorliegenden, mittlerweile veralteren Version recht stabil erkannt. Anderes eher nicht.

Dass ein Modell mit einen der Verschlagwortung im Museumsbereich näheren ursprünglichen Einsatzgebiet bessere Ergebnisse geben sollte, bedarf eigentlich keiner größeren Erläuterung.

Für welche Objekte eignet sich Bildklassifikation?

Die ursprüngliche Bilderkennung hat also technische und organisatorische Probleme. Aber sie hat inhaltliche: Bilderkennung erkennt eben Bilder. Objekte sind Objekte. Eine annähernd deckungsgleiche Übereinstimmung zwischen Bild und Objekt kann vorliegen, muss aber nicht. Meist lässt sich das an Objektarten festmachen: Beschreibt man den Scan einer frühen Fotografie oder eines Ölgemäldes, beschreibt man gleichzeitig das Objekt. Beschreibt man das Foto eines Schranks, hat man wahrscheinlich deutlich weniger über das Objekt selbst und dafür mehr über die Umstände des Fotografierens gesagt.

Auch eine relativ naive, nicht spezifisch auf Objektabbildungen nachtrainierte Bilderkennung kann im Museumsbereich also sinnvoll sein, ihr Nutzen ist aber Kontextabhängig.

Der zweite Anlauf: Bilderkennung für abgebildete Elemente

Ab Donnerstag wird nun eine neue Funktion zur automatisierten Bilderkennung zur Verfügung stehen, die vor dem Hintergrund der Fehler des ersten Anlaufs spezifischer agiert und (hoffentlich) sinnvoller in bestehende Workflows integrierbar ist. Ziel ist die Erkennung von Bildinhalten spezifisch für solche Objekte, bei denen Bild und Objekt annähernd deckungsgleich sind.

Da dies eben nicht alle Objekte sind, muss das Feature spezifisch aktiviert werden. Dies ist über eine neue Einstellung auf Ebene von Sammlungen möglich.

Wird ein neuer Objektdatensatz erstellt, der einer Sammlung mit aktivierter Bilderkennung zugeordnet ist, und zu dem ein Bild vorliegt, so wird dieses später automatisiert mit Vorschlägen aus der Bilderkennung angereichert.

Hierzu wird die reguläre Suchfunktion genutzt, um relevante Objekte und ihre primären Abbildungen zu identifizieren. Diese werden auf lokale Entwicklungs-Maschinen (PC mit Grafikkarte – aber aktuellen, besseren Consumer-Modellen) heruntergeladen und dort ausgewertet. Die so generierten Schlagworte werden auf den Schlagwort-Katalog gemappt und zurück zum Server geschickt.

Ist das einmal geschehen, erscheinen sie als Liste von Checkboxen in der rechten Seitenspalte des Schlagwort-Overlays.

Auswahl des Modells

Dadurch, dass homogenere und stärkere Hardware zur Verfügung steht, können auch größere Modelle eingesetzt werden. Für das neue Feature kommt dabei Joycaption zum Einsatz. Dieses stammt aus dem Umfeld der Open-Source-Bildgenerierung und wurde gezielt für das Beschreiben von Bildern erstellt. Es unterstützt dabei sowohl Prosa- als auch schlagwortartige Beschreibungen.

Ein wichtiger Vorteil des Modells ist, dass es unzensiert ist, während kommerzielle Modelle bei möglicherweise problematischen Inhalten zunehmend eingeschränkt sind. So werden zuverlässig auch z.B. Aktzeichnungen erkannt und beschrieben.

Schlagworte

Joycaption verschlagwortet teils spezifischer als wir das im Rahmen von museum-digital getan hätten. „Schwarzes T-Shirt“ wäre etwa bisher nicht als Schlagwort zugelassen gewesen, ist aber im Sinne der Beschreibung visueller Elemente sinnvoll zuzulassen. „Schwarzes T-Shirt mit einem Ärmel“ wäre allerdings sehr spezifisch. Um die Ausgaben des Modells mit dem Schlagwortkatalog zusammenzubringen haben wir also für ca. 20000 Objekte Beschriftungen erstellt und die daraus resultierenden ca. 6000 Schlagworte auf die bestehenden Vokabulare gemappt.

Wo es bisher keine Entsprechung gab (und der Begriff nicht grundsätzlich unerwünscht ist [„Ohne Menschen“]), wurde ein neues Schlagwort angelegt. Gerade bei Begriffen wie dem „schwarzen T-Shirt“ sind die Begriffe denkbar einfach zu definieren: Ein T-Shirt, das Schwarz gefärbt ist. Entsprechend wurden die so neu eingerichteten Schlagworte automatisiert mit durch das LLM Gemma3 generierte Beschreibungen und deutsche Übersetzungen angereichert, die derzeit gesichtet und bereinigt werden. In diesem Arbeitsschritt werden auch überspezifische Begriffe wie „Schwarzes T-Shirt mit einem Ärmel“ mit unspezifischeren Begriffen („schwarzes T-Shirt“) zusammengeführt, sodass diese unspezifischeren Begriffe stabiler erkannt werden.

Workflows

Durch die nachgelagerte Arbeitsweise – erst Bildupload, dann warten, dann Verschlagwortung- macht der Einsatz der neuen Funktion besonders Sinn, wenn man institutionell einen arbeitsteiligen Workflow hat. Werden Objekte in einem Arbeitsgang von Inventarnummer bis Publikation erfasst, bietet das Tool wahrscheinlich wenig Mehrwert.

API: Wer kann berechnen?

Alle für die Bildklassifikation genutzten Abfragen auf dem Server sind, ebenso wie die Schnittstelle zum Eintragen der Ergebnisse der Klassifikation, auch über die API von musdb verfügbar.

Derzeit werden die API-Abfragen über die administrative Kommandozeile durchgeführt – eine Übersetzung hin zu einer Durchführung mithilfe der Webschnittstelle wäre aber ein leichtes und ist in der bestehenden Implementation schon mitgedacht. Hiermit könnten einzelne Museen die Berechnungen spezifisch für ihre eigenen Objekte durchführen und zeitlich unabhängiger agieren. Bei Interesse: Einfach schreiben. Der Aufwand hielte sich wie gesagt in Grenzen.

This content is licensed under a Creative Commons Attribution 4.0 International license.

In der Praxis ist es vor allem letzterer Punkt, weshalb Objektbeschreibungen bei museum-digital verpflichtend anzugeben sind. Aber oft zeigt sich, dass die tatsächlich erfassten Beschreibungen hinter den „strukturiert“ erfassten Metadaten zurückbleiben oder beide ausbaufähig sind. Dies ist oft eine Frage der Objektgattung und des fachlichen Hintergrunds. Gerade z.B. bei Druckgrafiken findet man oft eine grandiose Verschlagwortung mit minimalen Prosa-Beschreibungen. Andererseits leidet jeder mal unter einer Schreibblockade, und der ganze Museumsbereich unter einem Mangel von Arbeitskraft und Zeit.

Sind aber die sonstigen Objektdaten gut, und fehlt die Beschreibung – wie eben oft bei Grafiken – dann sollte sich doch eigentlich eine brauchbare mithilfe moderner KI formulieren lassen. „Sprache“ steckt ja wortwörtlich schon im Namen „Large Language Model“. Und ist das Erstellen von Prosa-Beschreibungen einfacher, sollte doch eigentlich mehr Zeit und Motivation übrig sein, um die Verschlagwortung zu verbessern.

KI-generierte Beschreibungstexte

Mit diesen Gedanken startet heute ein Versuch und damit eine neue Funktion in musdb: Klickt man beim Bearbeiten eines Objektes in das Feld „Objektbeschreibung“, erscheint ein neu Marker „Automatisch formulieren“. Mit einem Klick darauf öffnet sich ein Overlay, in dem nach einer Wartezeit drei Vorschläge für Objektbeschreibungen angeboten werden, generiert auf Basis der bestehenden Objektmetadaten und mithilfe dreier verschiedener Sprachmodelle.

Mit einem ersten Klick auf einen der Vorschläge wird dieser in Gänze sichtbar. Mit einem zweiten Klick öffnet sich der Text in einer Bearbeitungsansicht. Ist er fertig bearbeitet, kann er mit einem Klick in die Datenbank übernommen werden.

Um überhaupt Vorschläge generieren zu können muss der Datensatz angelegt sein und mindestens ein Ereignis und ein Schlagwort haben, wobei die Ergebnisse mit mehr und besseren Metadaten entsprechend besser und zuverlässiger werden. Aufgrund der Abfragemethode sollte man zudem darauf achten, die Objektart als Schlagwort zu erfassen und entsprechend auszuzeichnen.

Gedanken

Drei Vorschläge

Eine gewichtige Befürchtung am Anfang der Überlegungen war, dass die Möglichkeit, Objektbeschreibungen maschinell generieren zu lassen mittelfristig zu Nachlässigkeit und dem Akzeptieren falsch generierter Beschreibungen führen könnte. Dabei ist KI zwangsläufig – bauartbedingt – unzuverlässig, und ihre Ergebnisse sollten immer (!) noch einmal gegengeprüft werden, bevor man sie veröffentlicht.

Um dieser Befürchtung zu begegnen, werden nun eben drei alternative Vorschläge generiert. Um den passendsten zu finden, muss man erst einmal lesen. Das heißt, man muss sich mit den Vorschlägen auseinandersetzen, sodass eine Korrektur eventuell falscher oder verkürzter Stellen deutlich näher liegt.

Das Generieren dauert lange!

Gerade, wenn man viele Objekte eingibt, dauert das Generieren der Vorschläge derzeit noch zu lange. Im Schnitt braucht die Generierung zwischen 10 und 11 Sekunden. Was bei einem Objekt akzeptabel sein mag, wird bei 50 eine echte Arbeitserschwernis. Andererseits sind die derzeit ausgewählten Modelle (Gemma 2, Gemma 3, Phi4) ein guter Kompromiss zwischen Geschwindigkeit und guten Vorschlägen. Kleinere, schnellere Modelle haben bei unsern Versuchen keine vergleichbar guten Resultate erzielt.

Um das Tool trotzdem auch bei vielen Objekten effektiv nutzen zu können, kann man die Vorschläge „vorgenerieren“. Dazu geht man in die Objektübersicht, klickt auf eine Objekt-Kachel, hält die Maustaste gedrückt und zieht den Mauszeiger zur Seite. Damit öffnet sich die Stapelverarbeitung per Auswahl. Hier gibt es nun eine neue Funktion, eben um Vorschläge zu generieren und zwischenzuspeichern.

Ein guter Workflow wäre also etwa, die Objekte des Tages erst einmal in ihren Metadaten gut zu erfassen, und dann in der Mittagspause die Vorschläge generieren zu lassen. Nach der Mittagspause können diese dann abgearbeitet werden.

Kooperation: Hardware & Auswertung

Wie eingangs erwähnt handelt sich beim neuen Tool erst einmal um einen Versuch, der in Kooperation von digiS, dem Zuse-Institut Berlin und museum-digital entsteht. Durch diese Kooperation können die Beschreibungen auf der Hardware vertrauenswürdiger Partner (nicht OpenAI, sondern dem Zuse-Institut!) generiert werden.

Um die Potentiale und Nutzung des Einsatzes von KI in der Museumsdokumentation – und spezifisch des vorliegenden Tools – besser zu verstehen und das Tool weiterzuentwickeln, werden die Anfragen, die Vorschläge und die final abgeschickten Objektbeschreibungen gesammelt und in den nächsten Monaten systematisch ausgewertet (dabei werden Benutzerkennungen pseudonymisiert). Wir berichten!

This content is licensed under a Creative Commons Attribution 4.0 International license.

Versionierung

Ein zentrales und lange schmerzlich vermisstes Feature in musdb war bis vor wenigen Tagen eine detaillierte Versionsgeschichte der Datensätze, um beispielsweise nach fälschlichen Stapelverarbeitungen oder Flüchigkeitsfehlern beim Löschen von Feldinhalten diese nachvollziehen und wiederherstellen zu können.

Eine solche Ansicht aller Arbeitsstände eines Objektdatensatzes seit Beginn der Aufzeichnung (Mai 2024) kann jetzt über den Reiter „Datensatz“ beim Ansehen und Bearbeiten eines Objektes in musdb abgerufen werden. Hier erscheint gleich oben ein neuer Button „Versionierung öffnen“.

Mit einem Klick darauf öffnet sich ein Overlay, in dem die verschiedenen Arbeitsstände tabellarisch aufgelistet werden. Die verschiedenen Aspekte des Objektdatensatzes sind dabei in verschiedene Reiter und damit verschiedene Tabellen gegliedert, z.B. für die Basisangaben, Verwaltungsangaben, Verknüpfungen zu Sammlungen, Schlagworten, etc.

„Feldweise transferieren“

Ein zweites oft gewünschtes Feature – besonders nach dem Importieren – ist das stapelweise Transferieren von Inhalten aus einem Datenfeld von Objekten in ein anderes. Sollen z.B. die bisher im nicht veröffentlichbaren Feld „Objektgeschichte“ geführten Informationen in Zukunft im Feld „Detaillierte Beschreibung“ geführt und darüber veröffentlicht werden, so kann der Übertrag aus dem einen in das andere Feld jetzt mit ein paar Mausklicks auch für hunderte Objekte durchgeführt werden.

Wie alle anderen Optionen des „Globalen Änderns“ bezieht sich das Feldweise transferieren von Feldinhalten dabei immer auf die Treffermenge einer Objektsuche. Die Funktion ist über die Seitenspalte der Objektübersicht verfügbar, sobald ein Suchkriterium eingestellt ist.

Die neue Funktion zum „Feldweisen transferieren“ ist auch über die API von musdb über den neuen Endpunkt /object/transfer_by_search/{mode} verfügbar.

In musdb, unserem Inventarisierungs- und Verwaltungstool, war und ist die Situation schwieriger. Einerseits ist musdb bezüglich seines Funktionsumfangs schlicht ungleich größer. Andererseits verunmöglichen die Reiter-basierte Struktur der Benutzeroberfläche und die bisher an vielen Stellen leider noch zu enge Kopplung zwischen Benutzeroberfläche und zugrundeliegender Abfragelogik ein API-Design wie in der Ausgabe, wo sich die API durch das einfache Anfügen von &output=json (bzw. ?output=json) aufrufen lässt. An vielen Stellen lässt sich zwar genau das tun, aber die Ergebnisse sind zwangsläufig unvollständig und von der Benutzeroberfläche gefärbt.

Andererseits ist eine API gerade für musdb interessant. Wenn Museen ihr lokales Inventarisierungsprogramm der Wahl verwenden könnten, und die Updates sofort auch in musdb und den öffentlichen Seiten gespiegelt würden, wäre das ein großer Fortschritt. Bisher bräuchte es dafür die Importfunktion, dass heißt, dass selbst bei einer vollen Automatisierung des Synchronisationsablaufs immer eine Verzögerung im Updatefluss bliebe.

Ein Anfang: Objekte per API updaten

Ein erster Schritt in Richtung einer dedizierten API für musdb, die unabhängig von der Benutzeroberfläche benutzt werden kann, ist nun getan. Zumindest Objektinformationen sind nun über eine gezielt dafür eingerichtete API auslesbar und bearbeitbar. Weitere Funktionen kommen sobald ein Bedarf besteht.

Und wenn man einmal damit anfängt, macht man es natürlich am besten gleich sauber. Mit der neuen API wurde ein Umformulieren und Neusortieren von vielen grundlegenden Funktionen auf technischer Ebene notwendig, die uns eine gute Gelegenheit gegebenen hat, gleich automatische Tests für alle in der API benutzten Funktionen zu schreiben. Ihre jetzt bestehenden Funktionen bleiben also sicher stabil.

Andererseits lag es nahe, die API beim Bauen gleich mithilfe eines Standards wie OpenAPI maschinenlesbar zu beschreiben. Gesagt, getan. Eine in JSON gefasste OpenAPI-Beschreibung der API von musdb findet sich in jeder regionalen Instanz unter /musdb/api, also etwa unter https://hessen.museum-digital.de/musdb/api.

Mit der Verwendung von OpenAPI eröffnen sich auch all die Tools, die allgemein für mit OpenAPI beschriebene Schnittstellen existieren. Eine vollständige menschenlesbare API-Dokumentation findet sich nun also im Handbuch (weil die API immer an die jeweilige regionale Instanz gebunden ist, funktioniert die Ausprobieren-Funktion im Handbuch nicht; eine gleich geformte API-Übersicht mit funktionierender Ausprobieren-Funktion ist in musdb in der Navigation verlinkt).

Nächste Schritte

Auch wenn sich jetzt alle Objektinformationen über die Schnittstelle bearbeiten lassen, ist die neue API von musdb noch sehr unvollständig. Ein nächster Schritt wird also definitiv die Erweiterung der API mindestens um die direkt anliegenden Funktionalitäten sein – z.B. das Auflisten der verfügbaren Sammlungen, sodass man überhaupt erst einmal die IDs zum Verlinken von Sammlungen ermitteln kann.

Auf der anderen Seite ist die API-Dokumentation mit OpenAPI ein großer Fortschritt auch gegenüber der Dokumentation der API der Ausgabe. Es bleibt zu hoffen, dass wir bald dazu kommen, auch für die API der Ausgabe eine OpenAPI-Beschreibung bereitzustellen. Geplant ist es auf jeden Fall.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Das Handbuch bei GitHub

Das Handbuch können Andere besser schreiben, als wir vom Kernteam von museum-digital. Ein gutes Handbuch für Benutzer kommt schließlich am Besten von anderen Benutzern. Deshalb ist das (deutschsprachige) Handbuch ab jetzt allgemein über GitHub bearbeitbar.

Mit der Umstellung der technischen Basis des Handbuchs auf mdbook Anfang des Jahres liegen alle Texte als Markdown-Dateien – also quasi als nur leicht formatierte Textdateien – vor, die problemlos mit einem Versionskontrollsystem verwaltet und verteilt bearbeitet werden können. Da GitHub mittlerweile wahrscheinlich die zentrale Stelle für die kollaborative Arbeit an vergleichbaren, versionierten Inhalten (von Handbüchern bis zum Hauptzweck, Programmen) ist, und die Meisten, die sich mit Versionierung auseinandergesetzt haben, wahrscheinlich schon ein GitHub-Konto haben, ist das Handbuch nun also zentral dort zu finden und wird dort gemeinsam mit allen, die mitmachen wollen, weitergeschrieben.

Auf jeder Seite des Handbuchs findet sich nun oben rechts ein Link zur äquivalenten Seite zur Bearbeitung, falls es Anmerkungen oder Ergänzungen gibt.

Seitenspezifische Hilfelinks in musdb

In der Navigation von musdb gibt es seit langer Zeit Links zum einigen Seiten des Handbuch. Bisher waren die hier verlinkten Seiten aber immer dieselben – egal, von welcher Seite aus man den Menüpunkt aufgeklappt hat.

Ab dieser Woche werden hier – soweit in der jeweiligen Sprache der Benutzer vorhanden – jeweils Links zu den passenden Seiten aus dem Handbuch zu finden sein. So finden sich die Antworten auf die Fragen, die während der Arbeit aufkommen, schneller – und musdb profitiert direkt von einem sich füllenden Handbuch.

Das neue Feld „Danksagung“

Zu guter Letzt soll hier noch eine Neuerung Erwähnung finden, die ausnahmsweise nichts mit dem Handbuch zu tun hat: Auf dem Reiter „Zusatz“ kann jetzt im neuen Feld „Danksagung“ der Dank an Mitwirkende und Fördermittelgeber ausgedrückt werden.

Besonders wichtig ist das Feld für die gerade laufenden Projekte im Rahmen der Förderlinie Neustart Kultur. Damit die Angabe des Fördergebers nach den Vorgaben der Deutschen Digitalen Bibliothek im richtigen Feld weitergegeben werden kann (in unserem Fall lido:creditLine), muss die Angabe der Förderer in das Feld Danksagung eingetragen werden. Damit das, wo nicht eh schon geschehen, einfach umgesetzt werden kann, ist das Feld für die Stapelverarbeitung mit der Funktion „Globales Ändern“ freigeschaltet.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Die Textbausteine in musdb werden auf Feld-Ebene festgelegt. Bevor die Textbaustein-Funktion benutzt werden kann, muss also erst einmal festgestellt werden, für welches Feld sie einzusetzen ist. Dafür reicht ein Klick in das gewünschte Feld – dieser führt gleichzeitig zum erscheinen eines Indikators am unteren rechten Bildschirmrand.

Dieser Indikator liefert einerseits Auskunft über Basisinformationen zum Feld und zur bisherigen Eingabe (Pflichtfeld oder nicht; Verhältnis von bisherigen Eingaben zur maximal erlaubten Anzahl von Buchstaben im Feld). Andererseits befinden sich ganz unten im Indikator Buttons für zusätzliche, Feld-spezifische Funktionen.

Ein Klick auf das Wiederholen-Symbol (im Screenshot ganz links) öffnet eine Seitenspalte für die Textbausteine. Alternativ kann man, wenn ein Feld angewählt ist, die Tastenkombination STRG+r verwenden, um die Textbaustein-Seitenspalte zu öffnen.

Die nun am rechten Bildschirmrand erscheinende Seitenspalte besteht einerseits aus einer Liste der schon eingefügten Textbausteine, andererseits aus einem Eingabefeld um neue Textbausteine anzulegen. Mit einem Klick auf einen Textbaustein aus der Liste oder das Drücken der entsprechenden Nummer auf der Tastatur (während die Seitenspalte geöffnet ist) lässt sich ein Textbaustein in das vorher angesteuerte Eingabefeld kopieren.

Beim Neu-Anlegen von Textbausteinen ist zu beachten, dass pro Feld nur 9 Textbausteine gespeichert werden können. Diese Beschränkung fungiert gleichzeitig als Lösch- und Sortierfunktion: Wird ein neuer, zehnter Textbaustein angelegt, wird der älteste Vorhandene gelöscht und die Nummerierung entsprechend angepasst.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Auswahlliste der Ereignistypen bis 28.04.2019

Die Schalter, mit denen der jeweilige Ereignistyp ausgewählt werden kann, waren als Buttons formattiert. Damit bei der wachsenden Liste genügend verschiedene Typen auf eine Seite passen, waren die Buttons allerdings schon im Vergleich zu normalen Buttons in der Höhe reduziert. Einerseits konnten wir so erreichen, dass die Auswahlfelder klar als solche markiert und von den Hilfstexten rechts abgehoben waren. Andererseits sah die Liste so weder ansprechend aus, noch ihr Design mit dem des restlichen musdb vollständig konsistent. Heute haben wir dieses Problem durch behoben.

Die neue Auswahlliste

Auswahlliste der Ereignistypen ab 28.04.2019

In der überarbeiteten Auswahlliste gibt es zuerst einmal eine Eingabe, mit dem die Liste für ein schnelleres Auswählen gefiltert werden kann. Darunter finden sich die schon bekannten Auswahlmöglichkeiten als Tabelle formatiert. Die Auswahlfelder sind statt als Buttons als linksstehende Tabellenköpfe formatiert. Durch die Hintergrundfarbe, die wir auch sonst für Buttons- und Aktionsfarben verwenden, sind die Auswahlfelder als solche markiert. Andererseits ist die Liste eine ganz neue Kategorie im Design, sodass sich das Problem der gebrochenen Konsistenz nicht stellt.

Zusätzlich zur Umformatierung zur eindeutigen Tabelle erscheinen jetzt die Ereignistyp-Symbole, die bisher schon in (Ereignis-)Zeitleisten in der Ausgabe verwendet werden, vor dem Namen des Ereignistyps. Für drei kürzlich eingefügte Ereignistypen gibt es deshalb seit heute auch entsprechende Symbole: „bemalt“ (), „illustriert“ (), und „wurde abgebildet (Ort)“ ().

This content is licensed under a Creative Commons Attribution 4.0 International license.