Pl4net.info

Bibliothekarische Stimmen. Independent, täglich.

Neuer KUG mit OpenBib 3

Zusammen mit der Umstellung auf die komplett überarbeitete OpenBib-Version 3 hat der Kölner UniversitätsGesamtkatalog KUG sein Gesicht verändert und endlich das Design-Konzept für die Corporate Identity der Universität zu Köln umgesetzt. Zentrale Voraussetzung dafür war die Umstellung der CSS-Klassen auf das YAML-Framework im neuen OpenBib 3.

Einher damit ging eine Entschlackung und Neukonzeption des Benutzer-Interfaces. Für den KUG als Rechercheportal wurde seine Kernfunktion in Form eines einheitlichen und durchgängigen Suchfeldes in den Mittelpunkt gestellt. Die alte Hauptnavigation wurde aufgelöst und zum Teil in den Suchbereich (Themengebiete, erweiterte Suche, Suchhistorie) bzw. die Toplevel-Navigation (RSS, Merkliste, Mein KUG, Anmeldung) verlagert.

Startseite des neuen KUG

Neue Startseite des KUG

Neue Startseite eines Instituts-Portals

Neue Startseite eines Instituts-Portals

Suchradius statt Katalogauswahl

Im bisherigen KUG – sowohl bezogen auf den Menu-Punkt Katalogauswahl in den Instituts-Portalen (dessen Bedienung diverse Nutzer überforderte…) als auch bezogen auf die erweiterte Suche im allg. KUG-Portal – mit der Auswahl aus einer ellenlangen Liste von Katalogen und der Profil-Auswahl  konnten wir folgendes Fazit ziehen:

Der Menu-Punkt Katalogauswahl oder die integrierte Vollauswahl verwirren bzw. überfordern die Benutzer, sorgen für Unübersichtlichkeit und sollten daher entfernt werden. Durch Ihren Wegfall war eine Neuausrichtung notwendig:

Speziell für die Instituts-Portale wurde stattdessen der neue Mechanismus Suchradius eingeführt, mit dem ein Nutzer ausgehend von der lokalen Bibliothek seine Recherche hierarchisch ausweiten kann:

  • Katalog des Instituts,
  • Kataloge der zugehörigen Fakultät,
  • alle Kataloge.

Der Suchradius kann direkt bei der Recherche angegeben werden. Ebenso kann in der Ergebnisliste nachträglich der Suchradius für die jeweilige Suchanfrage – parallel zu der Facettierung – geändert werden. Dieser Mechanismus dürfte für die Vielzahl der Institute die unkomplizierteste Lösung sein. Zusätzlich kann weiterhin natürlich jede Fakultät gezielt nach Literatur durchsucht werden.

Eine nachträgliche Eingrenzung auf einen konkreten Katalog – bei entsprechend ausgeweitetem Suchradius – kann über die Katalog-Facette erfolgen.

Alle individuellen Katalogzusammenstellungen für eine Recherche sind eben … individuell … und können weiterhin von jedem Nutzer nach Anmeldung in Mein KUG als eigene Suchprofile definiert werden und sie erscheinen dann automatisch in der Profilauswahl der Recherchemaske.

Integrierte Rechercheergebnisse

Die sicherlich augenfälligste Änderung ist die Darstellung der Rechercheergebnisse. Bisher wurden die Ergebnisse der einzelnen Kataloge blockweise nacheinander angezeigt mit jeweils eigener Seitennummerierung. Nun erscheinen sie in einer einzigen Trefferliste in der gewählten Sortierung und mit nur noch einer Seitennummerierung.

Trefferliste im KUG-Portal der Informatik

Trefferliste im KUG-Portal der Informatik

Verbesserte Navigation

Für die bessere Orientierung im KUG wurde eine neue durchgängige hierarchische Breadcrum-Navigation (Brotkrümelpfad) integriert. Diese erlaubt einen schnellen Zugriff auf die vorangegangenen Hierarchiestufen bis hin zur Startseite – die aber, wie generell üblich, auch per Klick auf das (Universitäts-)Logo erreicht werden kann.

Stehen in einer Hierarchie-Ebene mehre Informationsstränge zur Auswahl, können diese durch eine Sidebar-Navigation schnell erreicht werden.

Brotkrümel- und Seitennavigaton (orange)

Breadcrumb- und Sidebar-Navigaton (orange)

Die bisher angesprochenen Änderungen waren vor allem im Bereich Nutzerführung und Design zu finden. Dort wurden die generellen Ziele Suggestivere Bedienung, Verschlankung sowie Navigierbarkeit angestrebt. Selbstverständlich ist dies ein fortwährender Prozess.

Verglichen mit den Änderungen im Unterbau von OpenBib sind die Bereiche Nutzerführung und Design jedoch eher marginal.

Umfassender interner Umbau von OpenBib

Generelles Ziel von OpenBib 3 war der grundlegende Umbau der internen Architektur. Viele Aspekte werden in dem Blog-Artikel “Das Recherche-Portal ist der WebService” eingehender erläutert. Zusammengefasst:

  • Umstellung der Anwendung auf etablierte Software/Web-Frameworks.

Mit der Umstellung auf etablierte Frameworks wie CGI::Application, DBIx::Class, YAML, jquery.mobile und einen URL-Dispatcher wird OpenBib deutlich modularer und damit wart- und erweiterbarer.

  • Umsetzung zentraler Mechanismen von REST und Semantic Web.

Durch die Umstellung auf abstrakte “Cool URI’s” für die Kennzeichnung jeglicher Informationen (und Diensten) und deren Trennung von den eigentlichen konkreten Repräsentationen wird die OpenBib Plattform selbst zu einem Web-Service, über den alle Funktionen und Daten für eine externe Vernetzung bereitgestellt werden können.

Vereinheitlichung der Recherche-Backends

Die Recherche-Backends wurden auf

  • die Xapian Suchmaschine (default)
  • die ElasticSearch Suchmaschine (experimentell)
  • sowie die Suche in entfernten Katalogen via API für die Elektronische Zeitschriftenbibliothek EZB, das Datenbank-Informationssystem DBIS sowie BibSonomy

vereinheitlicht. Das bisherige SQL-Backend wird zugunsten der Suchmaschinen für die Recherche aufgegeben.

Zusammen mit korrespondierenden Katalog-Backends können nun strukturell auch beliebige andere Suchmaschinen bzw. Zugriffs-APIs integriert werden. Dazu müssen lediglich entsprechende Methoden in den neuen OpenBib::Catalog– sowie OpenBib::Search-Klassen geeignet spezialisiert werden.

Umstellung auf etablierte Frameworks

Wesentlich für die Modularisierung war die Umstellung auf das Web-Applikationsframework CGI::Application und dort vor allem das konfigurierbare URL-Dispatching via CGI::Application::Dispatch. Alle Aktionen sind nun in eigene Methoden der jeweiligen OpenBib::Handler::Apache-Klassen verteilt, auf die ausgehend vom konkret aufgerufenen URL die Anfrage entsprechend einer Dispatch-Tabelle und der Methode (GET,POST,PUT,DELETE) verteilt werden.

An die Stelle selbstoptimierter Stylesheets treten das CSS-Framework YAML. Neben jQuery und jQuery UI findet jQuery.mobile für mobile Seiten Anwendung.

Umstellung auf eine resourcenorientiere Infrastruktur und REST

Jede Resource erhält einen dedizierten URI. Zu den Resourcen korrespondierende konkrete Repräsentationen sind unter einem getrennten (aber vom Resourcen-URI abgeleiteten) URL erreichbar. Es sind dies derzeit:

  • HTML für die Zugriff durch den Endanwender
  • JSON für den Zugriff und die Einbindung in andere technische Infrastrukturen
  • RDF für die Bereitstellung der Daten im Semantic Web
  • RSS für die Bereitstellung von Informationen als Feed
  • INCLUDE für die Bereitstellung von (typischerweise HTML-)Informations-Schnipseln zur Integration in andere Anwendungen, speziell Webseiten in einem Content Management System.
  • MOBILE für den Zugriff durch den Endanwender über ein mobiles Gerät (Smartphone, Tablet)

Gibt es für einen URL andere Repräsentationen, so wird das dem Nutzer durch entsprechende Icons im rechten Bereich der Breadcrumb-Navigation angezeigt. Derzeit sind das die Repräsentationen JSON, RDF und RSS.

Für die intelligente Weiterleitung via Redirect von den Resourcen-URIs zu den entsprechenden “vollqualifizierten” Repräsentations-URLs wird Content-Negotiation sowie Language- und Browser-Detection eingesetzt.

Über die Browser-Detection werden mobile Endgeräte identifiert. Momentan arbeiten wir noch an einer Konzeption für eine mobile KUG-Variante. Speziell stellt sich die Frage, ob wir den Spagat zwischen Jeder URI hat eine mobile Repräsentation und der Vereinfachung des Nutzerinterfaces auf das Wesentliche schaffen. Denkbar wäre ein vereinfachtes Web-Interface mit der sinnvollen Reduzierung des Funktionsumfangs und der Navigation ausgehend von der Startseite, parallel aber eine mobile Repräsentation aller anderen Seiten, von denen aus man lediglich auf den mobilen Kernbereich verweist.

Jeglicher Zugriff und die Änderung aller Resourcen ist über ein JSON-REST-API auf Grundlage der allgemeinen Resource-URIs möglich. Insbesondere können damit Systemfunktionen und Administrationseinstellungen in andere Infrastrukturen eingebettet werden. Das USB-Portal setzt beispielsweise seit August 2012 das JSON-API einer damals eingefrorenen Beta-Version von OpenBib 3 für die Recherche in den Profilen USB und Uni produktiv ein und kann seitdem auch Facetten in den Ergebnislisten anbieten.

Der für den Endnutzer wesentliche Vorteil der neuen resourcenorientierten Infrastruktur ist der Wegfall des artifiziellen Konstrukts “PermaLink”, wie es im alten KUG und diversen anderen Rechercheportalen genutzt wird. Im neuen KUG ist jeder aufgerufene URL automatisch sowie vollintegriert ein PermaLink und kann direkt im Browser gebookmarkt werden. Ein Cut-and-Paste irgendwelcher unzusammenhängend angezeigter Hilfs-URLs entfällt.

Gerade das Design eines einheitlichen und konsistenten Systems an Resource-URIs hat einige Zeit benötigt und war immer geprägt von verschiedenen Abwägungen wie

  • Welches Schema? Singular, Plural, mit ‘id’ oder ohne, Vermeidung von Mehrdeutigkeiten
  • Hackability. Ist die Struktur der URI’s unmittelbar verständlich, so dass man ohne API-Dokumentation sofort andere URIs ausprobieren kann
  • Cachability und nutzerspezifische Resourcen: Eine eigene Repräsentation für Seiten mit nutzerspezifischen Inhalten (z.B. Auswahlliste der eigenen Literaturlisten usw.) bei allgemeinen Resourcen vs. eine individualisierte Resource
  • Struktur von allgemeinen, nutzerspezifischen und administrationsspezifischen Resourcen
  • Mehrdeutigkeiten in URI-Pfaden. Sollen verschiedene Wege zum gleichen Ziel führen?
  • Funktions-URIs vs. reine Lehre
  • Integration von Resource-Finder-URIs, die bei Aufruf fallspezifisch weiterleiten
  • Tag mit eigener numerischer Id für den eigenen (Schlagwort)Namen eines spezifischen Titels in einem spezifischen Katalog vs. Verallgemeinerung eines Tags lediglich über seinen (Schlagwort)Namen als id

Erfahrungen von anderen Implementierungen zu finden, die dann auch noch auf die konkrete Situation passen war nicht einfach. Dennoch gibt es verschiedene gute Artikel, die ein Gefühl für das URI-Design vermitteln:

Ebenso nicht zu vernachlässigen waren Unzuläglichkeiten im HTML(5) Standard, die eine Übernahme der REST-Aktionen via HTTP-Methoden in eine Endnutzer Web-Anwendung erschweren. Denn PUT und DELETE sind nicht im HTML-Standard definiert (waren es anscheinend einmal kurzzeitig, sind dann aber wieder herausgeflogen) und damit müssen diese Methoden etwas suboptimal durch GET oder POST getunnelt werden.

Umstellung der Datenbanken

Mit OpenBib 3 wurde die Umstellung von MySQL auf PostgreSQL als zugrundeliegendes RDBMS vollzogen. Für den Zugriff auf die Datanbanken wird auf den Objekt-Relationalen-Mapper DBIx::Class und SQL::Abstract zurückgegriffen, für das Connection-Pooling auf die zentrale Systemdatenbank hält pgbouncer Einzug.

Clusterbetrieb

Durch die Umstellung auf eine resourcenorientierte Infrastruktur und REST sowie den Einsatz von Cookies konnte für den KUG mit OpenBib 3 der Betrieb in einem Cluster eingeführt werden. Die Konfiguration der Cluster und die Zuordnung der einzelnen Server erfolgt über die Web-Administration.  Als Webproxy-Software wird haproxy genutzt und OpenBib entsprechend um eine Kommunikationsschnittstelle zu diesem Proxy erweitert. Derzeit läuft der KUG auf zwei Clustern zu jeweils 2 Servern, wobei jeweils ein Cluster für Recherchen und das Portal aktiv ist und das andere parallel die Katalog aktualisiert.

Bei dem erfolgten Umbau zu OpenBib 3 konnten sehr viel Code-Bestandteile 1:1 in die neue Infrastruktur übernommen werden. Mit dem Standardisierungsprozess durch den Einsatz der angesprochenen Frameworks wird OpenBib sicherlich für zukünftige Entwicklungen gerüstet sein. Und verglichen mit dem jetzt alten KUG hat der Neue durch die Umstellung auf die Corporate Identity der Universität wieder ein zeitgemäßes Aussehen…

Kommentare sind geschlossen.