This is the German version of the page: Conceptual gap in two disjunctive APIs for availability and user action

Abstrakt

Von FOLIO werden für Benutzeroberflächen derzeit zwei disjunkte Schnittstellen angeboten:

• edge_rtac: für die exemplarbezogene Verfügbarkeit (eine funktionale Untermenge von DAIA)
• edge_patron: Für die Bestellung von Exemplaren (eine funktionale Untermenge von PAIA)

Die Grundgedanken dabei sind:

1. Die Verfügbarkeit ist eine binäre Eigenschaft, die sich ausschließlich aus  aus den Eigenschaften des Mediums ableiten lässt.
2. Nutzerfunktionen neben der Verfügbarkeit keine zusätzlichen Informationen benötigen. Wenn doch dann wird erwartet, dass die Suchoberfläche diese ergänzt.

In den Treffen der unter SIG 'discovery' und Gesprächen in den Arbeitsgruppen bei hebis wurde schnell offensichtlich, dass die Axiome von oben nicht ausreichen. Nicht berücksichtigt wurde ist, dass es Anwendungsfälle gibt, bei denen die Verfügbarkeit nicht nur von den Eigenschaften des Mediums abhängt sondern auch von Eigenschaften der Nutzer*in eingeschränkt werden kann.

Diese Lücke wird in diesem Dokument anhand eines Beispiels dokumentiert und es werden verschiedene Lösungsvorschläge besprochen.

Passende FOLIO Tickets

UXPROD-2422 (Discovery Integrations - Expose Circulation Rules Regarding Requests)
UXPROD-2758 (Discovery Integrations - Expose Circulation Rules Regarding Renewal Options)
UXPROD-1630 (Pre-Check Request Policy When Requests are Created and/or Moved)

Exemplarisches Beispiel

Rahmenbedingungen

1. Eine kleine Bibliothek hat zwei Typen von Leser*innen und alle Medien stehen in einem geschlossenen Magazin.
2. Einige der Medien dürfen an alle Leser*innen, einige nur an Gruppe 'A' und andere nur an Gruppe 'B'.
3. Die Bibliothek hat eine Suchoberfläche, die für die Recherche keine Anmeldung vorschreibt.

Herausforderung

Die Suchoberfläche soll in zwei Betriebsmodi möglichst aussagekräftige Navigationselemente (Buttons) anbieten.

1. Ohne vorherige Anmeldung (Leser*in ist unbekannt) gibt es vier Möglichkeiten der Anzeige:
   1. Das Exemplar ist grundsätzlich nicht verfügbar. (Infotext zum Grund z.B. bestellt, verloren, ...)
   2. Das Exemplar ist verfügbar und darf von allen Leser*innen ausgeliehen werden. (Button: "Bitte Anmelden und Bestellen")
   3. Das Exemplar ist verfügbar aber ausgeliehen. (Button: "Bitte Anmelden, Vormerken eventuell möglich")
   4. Das Exemplar ist verfügbar darf aber nur von einer Gruppe ausgeliehen werden. (Button: "Bitte Anmelden, Bestellen eventuell möglich")
2. Mit vorheriger Anmeldung (Leser*in ist bekannt) gibt es wieder mehrere Möglichkeiten:
   1. Das Exemplar ist grundsätzlich nicht verfügbar. (Infotext zum Grund z.B. bestellt, verloren, ...)
   2. Das Exemplar ist verfügbar und 
      1. die Gruppe der Leser*innen  hat die Befugnis zur Ausleihe. (Button: "Bestellen")
      2. die Gruppe der Leser*innen  hat keine Befugnis zur Ausleihe. (Infotext:)
   3. Das Exemplar ist verfügbar aber ausgeliehen und 
      1. die Gruppe der Leser*innen  hat die Befugnis zur Ausleihe. (Button: "Vormerken")
      2. die Gruppe der Leser*innen  hat keine Befugnis zur Ausleihe. (Infotext:)

Problem

Für den ersten Fall des Beispiels sollte ein erweitertes¹ edge_rtac ausreichen.
   ¹) Derzeit fehlt die Information zur Einschränkung, dass ein Exemplar nicht für alle Leser*innen verfügbar ist.

Beim zweiten Fall ist es aber erforderlich, dass Eigenschaften der Leser*in über die Ausleihregeln in die Aussage zur Verfügbarkeit eingehen müssen.
Weder edge_rtac noch edge_patron sind in ihrem derzeitigen Entwurf in der Lage diese Anforderung zu erfüllen.

Lösungsansätze

Beim Entwurf von edge_rtac und edge_patron wurde versucht Überschneidungen zwischen den Schnittstellen zu vermeiden. Wie im Beispiel oben belegt lässt sich dies nicht durchhalten.
In diesem Absatz wird diskutiert wo/wie sich der fehlende Zusammenhang von Eigenschaften der Nutzer*in und denen des Medium abgebildet werden kann.

Einführung einer zusätzlichen Schnittstelle (Zum Beispiel edge_patron-rtac)

Es ist naheliegend, Funktionen die sich nicht direkt zuordnen lassen in eine eigene Schnittstelle auszulagern. Andererseits bringt jeder neue Schnittstelle neue Komplexität. So eine zusätzliche Schnittstelle hätte offensichtlich sehr viele Überschneidungen mit edge_rtac und edge_patron.
Um doppelten Code zu vermeiden, müsste auch die bestehenden Schnittstellen überarbeitet werden.

Erweiterung der Verfügbarkeitsinformation (edge_rtac)

Um Eigenschaften einer Leser*in zu berücksichtigen müsste edge_rtac die Anmeldedaten kennen. Andererseits muss edge_rtac auch ohne Anmeldung funktionieren. Es ergäben sich für edge_rtac in zwei unterschiedlichen Arbeitsmodi: "Ohne Anmeldung wage Informationen" vs. "Mit Anmeldung genaue Informationen". Der zweite Modus würde der oben verworfenen dritten Schnittstelle entsprechen, wäre aber klarer zuzuordnen.

Für eine Suchoberfläche hatte so ein Ansatz, nur den Nachteil, dass nach einer Anmeldung bestehende Verfügbarkeitsinformationen (Trefferliste) neu geladen werden müssten.

Erweiterung der Nutzer*in-Interaktion (edge_patron)

Im Gegensatz zu edge_rtac is bei edge_patron immer die ID von Exemplar und Leser*in bekannt. Entsprechend wäre ein zweistufiger Arbeitsablauf denkbar: 1. Holen der genauen Verfügbarkeitsinformation; 2. Bestellung entsprechend der gewonnenen Informationen.
Der erste Schritt würde wieder der dritten Schnittstelle (bzw. dem 2. Modus bei edge_rtac) entsprechen, wäre logisch bei edge_paron am Unpassensten zugeordnet.

Aufgeteilte Erweiterung beider Schnittstellen

Das überschneidungsfreie Design von edge_rtac und edge_patron lässt sich erhalten, wenn beide Schnittstellen in ihrem Kontext erweitert weden.

edge_rtac  liefert neben der grundsätzlichen Verfügbarkeit auch Informationen zu Einschränkungen der Verfügbarkeit, teilweise als Liste für unterschiedliche Benutzergruppen.

Für diese Erweiterung muss edge_rtac die ID der Leser*in nicht kennen. Es ist ausreichend wenn die Schnittstellen geschwätziger wird und möglichst viele ausleihrelvante Informationen ausgibt.

edge_parton bietet die Möglichkeite einer Blindbestellung. Diese validiert die individuelle Kennung und liefert Informationen zu individuellen Einschränkungen (Sperre, ...) und Optionen (Abholort, ...).

Das Konzept einer Blindbestellung kann von der prinzipiell vergleichbare Schnittstelle PAIA übernommen werden. Der Ablauf ist dabei folgender:

1. Wünscht die Leser*in ein Bestellung/Vormerkung, wird diese ohne ergänzende Angaben (Abholort, ...) angefragt. Im Bibliothekssystem löst dies eine Testbestellung aus. Diese Testbestellung führt zu keiner Änderung im Ausleihstatus. Aber es werden wie bei einer 'normalen' Bestellung alle Ausleihregeln ausgewertet und so alle und Einschränkungen/Optionen ermittelt. (eingeschränkte Liste der möglichen Abholorte, Liste möglicher Lieferoptionen, Info zu individuellen Einschränkungen, ...)
2. Mit dem Ergebnis der Anfrage generiert die Suchoberfläche ein Dialogfenster in dem:
   1. die Leser*in darüber informiert wird warum für Sie die Bestellung/Vormerkung nicht  möglich ist. (Z.B: Gesperrt wegen zu vielen offenen Gebühren)
   2. die Leser*in die Möglichkeit hat Bestellparameter auszuwählen. (Abholort, Lieferoption, Kostenübernahmen, ...)
3. Die Suchoberfläche sendet die Bestellung/Vormerkung mit ausgewählten Parametern an die Schnittstelle. Im Bibliothekssystem löst dies einen regulären Bestellversuch aus.
4. Die Suchoberfläche Informiert über den Erfolg der Bestellung.

Das derzeitige Verhalten von edge_patron ist schon ähnlich. Für eine Bestellung/Vormerkung wird derzeit mindestens der Parameter 'pickupLocationId' (Abholort) erwartet. Fehlt diese reagiert edge_patron mit einer Fehlermeldung. An dieser dieser Stelle könnte auch eine Blindbestellung ausgelöst werden, welche die Listen der möglichen Optionen zurück liefert.  (Derzeit wird so eine  Blindbestellung noch nicht unterstützt. -> Tickets)

Zusammenfassung

Auch wenn sie grundsätzlich möglich sind, erscheinen die ersten drei Möglichkeiten inkossistent.

• Eine zusätzliche Schnittstelle würde mehr verwirren als helfen.
• Die Erweiterung nur von 'edge_rtac', würde den Ablauf im der Suchoberfläche stören
• Dei Erweiterung nur von 'edge_patron' würde die klare Trennung zu edge_rtac verwischen. 

Dagegen erfüllt die aufgeteilte Erweiterung der Schnittstellen die Anforderungen des Beispiels problemlos und ohne logische Brüche.

Anhang

Weitere Anwendungsbeispiele

Natürlich gibt es neben den Beispiel oben noch viele weitere Rahmenbedingungen die mit dem oben diskutierten Ansatz abgedeckt werden müssen.
Im Folgenden werden weitere grundlegende Beispiele skizziert und es wird geprüft, ob die oben beschriebene Lösung ausreicht.

Entfernte Standorte 1

Rahmenbedingungen

1. Eine Bibliothek hat zwei Bibliotheksstandorte.
2. Lokaler Bestand soll nicht bestellt werden können.
3. Bestand von Standort 'A' soll zu Standort 'B' bestellt werden können.
4. Bestand von Standort 'B' soll zu Standort 'A' bestellt werden können.
5. Die Bibliothek hat eine Suchoberfläche, die für die Recherche keine Anmeldung vorschreibt.

Diskussion

Dieses Beispiel hat zwei Aspekte:

1. edge_rtac
   Die Suchoberfläche benötigt die Information, dass lokale Bestellung nicht möglich sein soll.
2. edge_patron
   Bei der Blindbestellung dürfen nur Abholstandorte von anderen Orten wie dem des Exemplars ausgegeben werden. (ein Anwendungsfall von UXPROD-2689)

Entfernte Standorte 2

Rahmenbedingungen

1. Abweichend vom vorherigen Beispiel gibt es eine privilegierte Gruppe, die auch lokal bestellen darf.
2. Zusätzlich gibt es eine dritte Gruppe, die gegen eine Bearbeitungsgebühr lokal bestellen darf.

Diskussion

1. edge_rtac
   Die Einschränkung der Bestellbarkeit soll als Eigenschaft der Gruppe angegeben werden.
   Beispiel

   {"limitations": [    {"place" [       {"normalos": "nur lokal"},       {"privilegiert": ""},       {"zahler": "lokal gegen Gebühr"}    ]} ]}

2. edge_patron
   Die Abholstandorte werden anhand von Leser*in und Exemplar gefiltert. Bei der Gruppe 'zahler' kann die Oberfläche nachfragen ob gegen Gebühr lokal bestellt werden soll. Die Höhe der Gebühr wird wie die Liste der Abholstandorte von der Blindbestellung geliefert.

Lesesaal

Rahmenbedingungen

1. Eine Bibliothek hat für einen Bereich einen Sammelauftrag. Medien die dazu beschafft wurden dürfen das Haus nicht verlassen, können aber eingesehen werden.
2. Einige der Medien sind in einem geschlossenen Magazin gelagert. Zum Lesen können diese nur in spezielle Lesesäle bestellt werden. Dort können die Medien während der Ausleihfrist exklusiv genutzt werden.
3. Zusätzlich gibt es eine vertrauenswürdige Gruppe, die auch an andere Abholstandorte im Haus Bestellen darf.

Diskussion

1. edge_rtac
   Die Einschränkung der Bestellbarkeit soll als Eigenschaft der Gruppe angegeben werden.
   Beispiel

   {"limitations": [    {"place" [       {"normalos": "nur Lesesaal"},       {"privilegiert": "nur im Haus"}    ]} ]}

2. edge_patron
   Die Abholstandorte werden anhand von Leser*in und Exemplar gefiltert.

Kurzausleihe

Rahmenbedingungen

1. Für manche Medien (Leerbuchsammlung) gelten vom üblichen Standard verkürzte Ausleihzeiten

Diskussion

1. edge_rtac
   Um es der Oberfläche zu erlauben auf verkürzte Ausleihzeiten hinzuweisen. Soll die Einschränkung soll als Eigenschaft der Gruppe angegeben werden.
   Beispiel

   {"limitations": [    {"duration" [       {"normalos": "verkürtze Ausleihe, 3d"},       {"privilegiert": "verkürtze Ausleihe, 7d"}    ]} ]}

2. edge_patron
   Die Abholstandorte werden anhand von Leser*in und Exemplar gefiltert.