Ist beabsichtigt, dass sich die beiden Suchfelder unterschiedlich verhalten?

[matthias-ronge]

Nachdem ich beim Praxistreffen die Frage gestellt hatte, wie es möglich sei, nach METS-Dateiinhalten zu suchen. Man kann diese nicht finden, wenn man im Vorgangs-Filterschlitz sucht. @oliver-stoehr hat weiter festgestellt, dass man jedoch danach suchen kann, wenn man im Suchfeld oben auf der Seite (im blauen Bereich) sucht.

Suche nach einem String aus den Metadaten im Filter: (kein Treffer)

Suche nach einem String aus den Metadaten im oberen Suchschlitz: (1 Treffer)

Ich habe mir das etwas weiter angesehen und festgestellt, dass sich der Suchschlitz auch sonst etwas anders verhält. Wenn man nach einer ID sucht, funktioniert es dort, während es im Filter-Schlitz nur funktioniert, wenn man explizit das Präfix „id:“ davor stellt. Wenn man das Präfix „id:“ in den oberen Suchschlitz eingibt, bekommt man hingegen einen Stacktrace.

Suche nach „7517“ im Filter: (kein Treffer)

Suche nach „id:7517“ im Filter: (1 Treffer)

Suche nach „7517“ im oberen Suchschlitz: (1 Treffer)

Suche nach „id:7517“ im oberen Suchschlitz: (stürzt ab)

Auf den zweiten Blick fallen auch Unterschiede in der Seite auf, je nachdem, über welches Suchfeld man sucht. Am Auffälligsten sind:

• die etwas aus dem Layout gefallenen weiteren Filtermöglichkeiten am unteren Ende der Seite (nur über oberen Suchschlitz verfügbar)
• dass abgeschlossene Vorgänge einmal standardmäßig gefunden werden, einmal nicht
• der Filter-Suchschlitz penetrant ein Speichern des Filters aufdrängt, der obere Suchschlitz bietet die Möglichkeit hingegen gar nicht an

Filter:

Oberer Suchschlitz:

Meine Frage, auch an das @kitodo/kitodo-community-board, ist: Ist dieses Verhalten 2023 so noch gewollt? Meine persönliche Erwartungshaltung wäre:

• Beide Suchschlitze verhalten sich gleich. (Wird der obere Suchschlitz auf einer anderen Seite als der Vorgangsliste benutzt, sollte die Ansicht zur Vorgangsliste wechseln.)
• Die Suche nach einer ID ist ohne den Prefix „id:“ möglich
• Die Suche nach Metadatenwerten ist möglich
• Die Suche mit dem Prefix „id:“ stürzt nicht ab
• Nach Benutzung des oberen Suchschlitzes wird die Suche im Filter-Suchschlitz angezeigt und kann dort gespeichert werden
• Das Speichern könnte dezenter angeboten werden (z.B. Speichern-Symbol neben dem Suchschlitz, aber nicht das Pop-Up.)
• Die zusätzlichen Suchmöglichkeiten sind grundsätzlich verfügbar
• Gleiches Verhalten hinsichtlich der Anzeige abgeschlossener Vorgänge
• Trefferzahl besser positionieren

Zum Beispiel so:

[oliver-stoehr]

Vielen Dank @matthias-ronge für die ausführliche Recherche und Beschreibung!

Ich habe dazu noch folgende Ergänzungen:

• Die von dir getestete Version ist nicht mehr ganz aktuell. Es sind bereits einige UI-Verbesserungen bezüglich der Filter in Version 3.6.0 enthalten, die unter Anderem das beschriebene zu aufdringliche, automatische Öffnen des Popups beheben und die Filter-Buttons von unterhalb der Tabelle in ein neues, inhaltlich passenderes Popup an den Filtern rechts oben verschieben. (Siehe Add interactive filter menu #5523)
• Eine Suche im Filterfeld ohne Präfix ist eine Suche nach dem Vorgangstitel (geht auch mit dem Präfix „process“ oder „prozess“). Daher werden dabei keine IDs gefunden. Ob das so noch sinnvoll ist oder auch IDs finden sollte, sollte hier auf jeden Fall diskutiert werden.
• Die Unterschiede in der Ergebnisliste zwischen den beiden Such-/Filterfeldern kommt daher, dass die Ergebnisse der Filter auf beiden normalen „Vorgänge“- und „Aufgaben“-Seiten angezeigt wird. Das Suchfeld oben leitet aber auf eine separate, dritte Seite. Diese ist der „Vorgänge“-Seite sehr ähnlich. Da es aber eine separate Seite ist, wurden in der Vergangenheit nicht alle Änderungen aus der Vorgangsliste auch auf diese Seite übernommen. Aus meiner Sicht wäre es sinnvoll, wenn wir – auf welchem Weg auch immer – auf die separate Seite verzichten könnten und die Funktionen des oberen Suchfeldes auf den beiden hauptsächlich genutzten anbieten könnten.

[andre-hohmann]

@matthias-ronge und @oliver-stoehr :

Vielen Dank für Eure Beiträge. Ich würde eine umfassende Beurteilung sehr begrüßen und will auf folgendes Issue hinweisen, das bestehende Fragen, Wünsche, ... bezüglich der Suche zusammenfasst:

• Search and filter improvement - Bundle #5020

Es muss auch darauf hingewiesen werden, dass Vieles funktioniert und einige Einrichtungen keine weiteren Anforderungen an die Suche stellen.

Ich will jedoch niemanden davon abhalten, sich mit diesem Thema zu beschäftigen. Ich vermute jedoch, dass allein die Untersuchung und Abstimmung über die Anpassung der Suche/Filter unter den interessierten Einrichtungen sehr viel Zeit benötigt.

[matthias-ronge]

Die zwei Seiten stören mich auch, aber was mich mehr stört ist, dass dieselbe Suchsyntax in den beiden Suchschlitzen zu unterschiedlichen Ergebnissen führt. (Verbunden mit der Frage, ob das inder Umstellung auf Hibernate Search wieder so umgesetzt werden soll, was umständlicher wäre, oder eine Lösung für beide Suchschlitze ausreichen würde. Das wäre einfacher zu implementieren, und − wie ich finde − dem Benutzer auch besser vermittelbar.)

Meine Erwartung wäre, dass eine Suche ohne ein Präfix eine „freie Suche“ ist, und z.B. mit „7517“ sowohl den Vorgang mit dieser ID findet, als auch einen Vorgang mit dem Titel LoremIpsum_7517123X, alle Vorgänge deren Elternteil der Vorgang mit der ID 7517 ist, und genauso auch einen Vorgang mit einem Film, bei dem im Metadatum „Länge [m]“ die Zahl 7517 steht …

[andre-hohmann]

@matthias-ronge : Entschuldige, ich ließ mich von den ausführlichen Beschreibungen hinreißen.

Die Frage nach einer einheitlichen Syntax lässt sich natürlich deutlich einfacher abstimmen und beantworten.
Spontan würde ich persönlich zustimmen, dass nur eine Syntax angewendet wird, wenn dies realisierbar ist.
Es wäre natürlich besser, wenn mehr Einschätzungen gegebenen werden. Ich werde das auch in das Community Board einbringen.

[andre-hohmann]

@matthias-ronge :
Wir haben die Frage im Community Board besprochen und stimmen grundsätzlich zu, dass nur eine Suchsyntax angewendet wird. Dies ist den Anwendern und Anwenderinnen deutlich besser zu vermitteln.
Allerdings sind wir unsicher, zu welchen Konsequenzen diese Entscheidung führt oder führen kann. Im Folgenden wird die Diskussion skizziert, um unsere Fragen und Unsicherheiten zu vermitteln.
Es soll vermieden werden, dass Entscheidungen auf der Grundlage falscher Vorstellungen getroffen werden.

Die Suche darf zum Beispiel nicht auf die von Dir beschriebene Funktion reduziert werden, dass immer alles gefunden wird. Die Eingrenzung mit Präfixen, wie zum Beispiel id, project, property… muss weiterhin möglich sein. Gerne auch in der Suche.

Die unterschiedliche Suchsyntax entstand unseres Wissens dadurch, weil in den Filtern und der Erweiterten Suche die Suchsyntax der Eigenschaften aus Kitodo.Production 2 übernommen wurde und im Suchfeld der ElasticSearch-Index abgefragt wird, der die Präfixe nicht "kennt".

Die Diskussion im Community Board wurde häufig auf weitere Fragen und Themen gelenkt, die in diesem Zusammenhang berücksichtigt werden sollten, wie zum Beispiel:

• Perspektive der Vorgangseigenschaften (die eigentlich entfernt werden sollten)
• Informationen darüber, was im Index enthalten ist (Metadaten METS-Datei, …)
• Informationen darüber, welche Auswirkungen Hibernate Search hat
• Erwartungen an die Suche, insbesondere spezifischere Suchen über die Metadaten der METS-Datei

Um Fortschritte zu erzielen, sollten jedoch folgende Aspekte unterscheiden werden:

1. Kurzfristig: Rasche Beantwortung Deiner Fragen, so dass Du weiterarbeiten kannst.
2. Mittelfristig: Abstimmung über das Konzept und die Ziele des Projekts, um mögliche weitere Fragen beantworten zu können.

Bezüglich 1 würden wir mit unserem derzeitigen Kenntnisstand eine einheitliche Suchsyntax befürworten. Insbesondere, wenn dies die Umsetzung vereinfacht.
Bezüglich 2 würden wir gerne ein Treffen vereinbaren, um das Konzept (besser) verstehen zu können - wenn möglich zusammen mit @solth und @oliver-stoehr. Du hast ja selber auf weitere Verbesserungsmöglichkeiten hingewiesen, wie zum Beispiel die Ergebnisliste der Suche.

@kitodo/kitodo-community-board :
Ich hoffe, dass der Verlauf/die Ergebnisse der Diskussion im Community Board korrekt beschrieben sind. Wenn nicht, bitte gerne ergänzen oder korrigieren.

[subhhwendt]

Nach einem Austausch vom @kitodo/kitodo-community-board mit @matthias-ronge, @solth und @oliver-stoehr halte ich von dieser Videokonferenz fest - bitte bei Bedarf ergänzen / kommentieren.

• Es wird eine Integration der sog. Headersuche (Suchschlitz oben links mit einer Metadatensuche im Index auf Basis eines aktuellen Standes der meta.xml) in den Filtersuchschlitz angestrebt (metadata:....).
• Aktuell lässt sich in der sog. Headersuche nur übergreifend nach Elementen aus den Metadaten suchen ohne Einschränkung auf ein bestimmtes Metadatenfeld. In einer Ausbaustufe sollte eine Umsetzung von gezielteren Suchen mit key:value-Abfragen angestrebt werden. Um bei dieser Ausbaustufe nicht mit den evtl. wenig sprechenden internen Namen aus meta.xml zu operieren wurde u.a. eine Verankerung von sprechenderen Namen im Ruleset kurz andisktutiert.
• Mit dieser Integration wird die Headersuche oben links überflüssig. Die für die Headersuche entwickelte sehr spezielle Trefferliste mit anzuwählenden Filtermöglichkeiten unter der Trefferliste wird ebenfalls aufgegeben.
• Die einmalige Aufnahme von Metadaten beim Import in die sog. properties in der DB wird ebenfalls perspektivisch aufgegeben und die damit verbundenen Abfragemöglichkeiten "property: ...".

Angerissene Fragen für evtl. Fortsetzungsrunden:

• Möglichkeiten der Suchsyntax abstecken. Nach der Sitzung hat @oliver-stoehr nachgetragen, dass die Filtersuche bereits "Nicht-" und "Oder-Verknüpfungen" erlaubt - siehe auch Dokumentation im Wiki
• Ist die Indexierung von vielen Datenbankinhalten sinnvoll? Wofür können sie genutzt werden? Bringt Hibernate Search die erhoffte Performance und Alltagstauglichkeit im Vergleich zur aktuellen Situation?
• Die aktuelle Indexierung der Metadaten ist mit seiner Verschachtelung zu komplex - siehe Ticket 4266
• UI: Verankerung einer übergreifenden Filtersuche auch jenseits der Aufgaben- und Vorgangsliste!? Wird die Filtersuche ggf. zu komplex und eine nachträgliche Facettierungsmöglichkeit wie bei der Trefferliste nach der Headersuche macht doch Sinn?