[Allegro] Anwenderbeitrag: Erfahrungsbericht OPAC-Bau

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Liste,

Als ich letzten Freitag beim allegro-Treffen in Braunschweig oeffentlich
ins Erzaehlen geriet, waren einige Teilnehmer schon abgereist, Pech fuer
den Rest, denn das Produkt aus Vortragszeit und Zuhoererzahl muss ja
konstant bleiben... Weil ich keine Folien hatte, die ich jetzt leicht
veroeffentlichen kann, sei hier eine Ausarbeitung nachgereicht, die ich
mir im wesentlichen selbst erzaehlt habe (und auch hier war dann das
Produkt aus ... konstant). Voila [und in eckigen Klammern das letzte Woche
ungesagte]:

Die erste Viertelstunde war ein eher spontaner Einschub, der einiges vom Tag
vorher aufgriff und auch eine von der BBF gemurmelte Frage zur Pflegbarkeit, es
war eine Art Erfahrungsbericht:

Die (in den 199ern, mit Populo 1.0x begonnene) Entscheidung, Funktionalitaet
und Layout durch Nutzung von "Templates" staerker zu trennen, ist fuer sich
gesehen immer noch nicht verkehrt [spaeter entstand dann ja PHP und Content-
Management-Systeme nach demselben Prinzip, als Populo programmiert wurde, gab
es in dem Berich nur das Microsoft-spezifische ASP]. Dieser Ansatz gab Anwendern
die Moeglichkeit, eine Kataloganbindung einfacher an die lokalen Gegebenheiten
anzupassen [und bei Wechsel der lokalen Gegebenheiten, z.B. den beliebten
"Relaunches" des Internetauftritts, umzuarbeiten]. Der Ansatz war auch insoweit
erfolgreich, dass Inkompatibilitaeten spaeterer Avanti-Versionen durch Austausch
der grundlegenden, fuer alle konkreten Kataloge identischen eigentlichen
populo-Bibliothek behoben werden konnten.

Zu kurz gedacht war der Ansatz jedoch in anderen Bereichen:
* Die Kataloganbindungen von 1997ff waren aus spaeterer Sicht nicht endgueltig,
  d.h. es gab im Laufe der Zeit viele punktuelle Verbesserungen (ich schilderte
  die diffizilen Ueberlegungen hinter der "trunkierten" Suche nach Personen-
  Namen und auch die bereits zwischen Deutschland und Oesterreich [genauer:
  alemannischem Sprachraum] bestehenden kulturellen Unterschiede bei der
  Eingabe von Namen), die jeweils unabhaengig von der Bibliothek waren, aber
  doch spezfisch fuer die "Klasse" der Kataloge (A-Schema, HANS, ...). Dem
  wurde durch erneutes Abspalten der anwenderspezifischen Anpassungen in eine
  separate "Konfigurationsdatei" begegnet

* Mehrsprachige Oberflaechen wurden damals bewusst durch Vorhalten paralleler
  Interfaces realisiert, dies koehaerent zu halten ist aufwendig [nicht
  gezeigt: < http://www.litdok.de/cgi-bin/litdok > hat tendenziell 10 Sprachen,
  Herr Janus war leider bereits abgereist, sonst haette ich das Beispiel
  einbezogen, ausgehend von den Anforderungen dieses 2005 von mir realisierten
  Katalogs (es gab einen aelteren selbstgemachten) ist viel des von mir hier
  geschilderten entstanden]. In den letzten Jahren bin ich daher zu einer
  "kleineren" Loesung uebergegangen, die in "generische" Templates die
  Textfragmente der Sprache des Benutzerinterfaces live einsetzt. Und weil durch
  denselben Mechanismus dann auch standardisierte einleitende Wendungen der
  eigentlichen, durch die Parameterdatei der Exportsprache gesteuerten Ausgabe
  wie "frueherer Titel:" und Floskeln wie "[Hrsg.]" uebersetzt werden koennen,
  entsteht sogar ein Mehrwert.

* Nicht alle Funktionalitaetserweiterungen sind rein "intern" wie das obige
  Beispiel der intuitiveren Personensuche. Meistens betreffen Verbesserungen
  und Weiterentwicklungen auch die Ausgabetemplates der Datenbank (besseres
  Layout, zusaetzliche Buttons, ...), und an dieser Stelle ("naechstes Release
  des OPACs") waren Anwender dann dem Konflikt ausgesetzt, nicht upgraden zu
  koennen bzw. ihre lokalen Anpassungen [nicht erwaehnt: intern schlecht
  dokumentiert, ohne Archivierung einer Referenzversion, von der die lokalen
  Anpassungen ihren Ausgang nahmen] von Null an erneut vornehmen zu muessen.
  Ich zeigte als Beispiel den HANS-Katalog der SUB-Hamburg, der auf Hamburger
  Anpassungen sehr alter Muensteraner Anpassungen eines noch aelteren
  "Standard-HANS"-Interfaces beruht [das soll jetzt kein Anwender-Bashing sein,
  aus einer Zwickmuehle kommt man halt nicht ungeschoren heraus und x Jahre
  abzuwarten, bis alles "ausgereift" ist, ist auch nicht fuer jeden die beste
  Empfehlung].
  Meine Antwort hierauf ist 199x nicht moeglich gewesen, sie besteht in der
  Produktion vom moeglichst sauberem (X)HTML mit extensiven Klassenbenennungen
  und die "Anpassung" durch die Benutzer sollte gar nicht in den Templates
  erfolgen sondern moeglichst mittels "Styling" durch CSS (was aber zunaechst
  eine so neue Version erfordert, dass die exzessiven Klassenbenennungen bereits
  realisiert sind). [Keine Loesung also fuer die Betreiber alter Kataloge beim
  Upgrade der Software, nur Trost und Versprechen, dass es in Zukunft leichter
  sein wird]. Insbesondere die Importfunktionen und die "Kaskade" von CSS bieten
  gute Moeglichkeiten, verschiedene, unabhaengige Schichten und Layout-
  vorstellungen simultan zu laden und beobachtete Konflikte etc. durch einen
  kleinen Satz "staerkerer" Regeln abschliessend aufzuloesen. Auch das spaetere
  Abaendern des eigenen Layouts wird durch diesen Ansatz stark erleichtert (s.a.
  den naechsten Punkt).

* [Frueher war man froh, ueberhaupt einen Katalog "im Internet" zu haben, und
  wenn der dann noch so aussah, wie die anderen eigenen Seiten, war es das
  Paradies] Kataloge sind nur eine Komponente der Internetpraesenz einer
  Institution, eine "Einbindung" erfordert nicht nur eine Anpassung des
  konkreten Layouts, sondern ein Einpassen in die konkreten Navigations-
  strukturen des Gesamtauftritts. Dieser ist ueber mehr oder weniger
  selbstgemachtes realisiert, zunehmend aber auch ueber diverse verschiedene,
  "marktgaengige" CMS-Systeme. Hier ist dann oft noch eine "Internetagentur"
  involviert, die sich zuerst laut wundert, warum es keine Kataloganbindung
  in ihrer CMS-Sprache (PHP, Python, Typo3, ...) gibt, dann vorschlagen, diese
  Anbindung mal eben schnell mit ihren Werkzeugen nachzuprogrammieren, sich
  aber zum Schluss meist davon ueberzeugen lassen, dass ein Katalog als eine
  selbstaendige "Web-Anwendung" nicht mit CMS-Mitteln nachzuprogammieren ist
  [das Budget "steht" ja meist bereits und ist weitgehend aufgebraucht, wenn
  sich irgendjemand an den Bibliothekskatalog als "auch mitzunehmen" erinnert],
  sondern eben "integriert" werden muss. Technisch sind die Wege je nach
  Ausgangslage sehr unterschiedlich, mal sind es Frames, mal Iframes, mal
  HTML-Tabellen (immer noch), mal DIV's mit CSS. In den letzteren beiden
  Faellen gibt es die Moeglichkeit, dass das CMS serverseitig einen HTTP-Request
  auf den Katalog ausloest, und das Resultat in seine eigene HTML-Ausgabe
  einsetzt [hier hilft es dann, wenn sich die HTML-Templates stark reduzieren
  lassen, so dass nur der HTML-Code mit der eigentlichen Funktionalitaet
  uebrig bleibt, im naechsten Satz "Das innere" genannt]. Ich persoenlich
  bevorzuge die Variante, dass der Katalog Aussehen und ggfls. auch
  Funktionalitaet des CMS emuliert. D.h. eine dem CMS entnommene "Blindseite"
  enthaelt Navigation und Aussehen des "Drumrum", in diese werden dann die
  generischen Templates als "Inneres" hineingesetzt, das Resultat sind dann die
  Templates, mit denen der Katalog in echt betrieben wird und die sich dann im
  Idealfall nahtlos einpassen. Aendert sich Struktur oder Aussehen es "Drumrum",
  werden die Templates einmalig neu generiert und CMS und Katalog sind wieder
  einheitlich.

Als Beispiele zeigte ich zwei Kataloge, naemlich das Dombauarchiv in Koeln <
http://www.dombau-koeln.de/index.php?id=46 > und das Deutsche Forum fuer
Kunstgeschichte in Paris < http://opac.dfkg.org/cgi-bin/dfkg.pl > (hier
sehen die Seiten bewusst anders aus als die im CMS, die "Blindseiten" sind
statische Entwuerfe der Webdesigner gewesen) [Das weiter oben benannte litdok.de
ist ein Beispiel, wo m.W. allein durch Austausch der "Blindseite" erfolgreich
ein Relaunch des Gesamtauftritts im Katalog nachvollzogen wurde]

Viel von dem oben geschilderten sind Erfahrungen, Einschaetzungen, von mir
postulierte allgemeine Designprinzipien fuer die Pflegbarkeit von
Internetkatalogen, ich habe sie stellenweise mit Populo (d.h. genauer: im
Rahmen von Populo-Anwendungen) realisiert, stellenweise auch als rein
externe Zusatzskripte, die Templates umstricken bzw. Uebersetzungstabellen
pflegbar machen. Die Realisierung solcher Designprinzipien besteht meiner
Meinung nach hauptsaechlich durch Treffen von "Verabredungen mit sich
selbst", die dann letztendlich irgendwie in Markup in Dateien und dieses
beruecksichtigender Software umgesetzt sind. Insofern gibt es auch keine
"Loesungen", die man durch "Installation" von irgendetwas uebernehmen
koennte. Zusammengefasst ist also meine Antwort auf die simple Anforderung
"Einbinden eines Katalogs in eine Webpraesenz" ein ziemliches Ausmass an
Abstraktion, die dann technisch irgendwie abgebildet wird [Fuer mich ist
das auch die "einfachste moegliche" Antwort, ich gestehe aber jedem zu,
ein anderes Konzept von "einfach" zu haben]

[Von Herrn Eversberg war bemerkt worden, dass inzwischen 5[?] Sprachen
in Webanwendungen am Werk seien, HTML, CSS, JavaScript, die Programmiersprache
der Web-Anwendung als Middleware, die Flex/Job-Sprache von Avanti und
die Exportsprache der Parameterdateien. In Wirklichkeit sind es noch
einige mehr, Templatingsysteme haben ihre eigene Syntax, server- oder
browserseitiges XSLT sollte man nicht unbeachtet lassen und es tritt
auch noch folgendes Phaenomen auf: Es wird ja nicht alles aus der Datenbank
durch die Exportsprache aufbereitet und in der Form moeglichst unmodifiziert
zum Benutzer gepruegelt: Sondern man versucht, die Daten mit moeglichst
universellen Parameterdateien halbwegs neutral aufbereitet auf die Reise
zu schicken, und in spaeteren, filternden Schichten daraus dann allmaehlich
reiches und brauchbares HTML fuer den Benutzer zu machen. Die Datenbank
(zusammen mit den Exportparametern als erste Verarbeitungsstufe gedacht)
/darf/ m.E. nicht wissen, wie eine ZDB-Verlinkung heute aussieht und
sie darf auch nicht wissen, wie die Web-Applikation Hyperlinks auf
weiterfuehrende Recherchen veranstaltet. Sie muss aber wissen, was eine
ZDB-Nummer ist und welche Inhalte sich fuer weiterfuehrende Recherechen
anbieten (z.B. angesetzte Personennamen aus den entsprechenden Kategorien)
und muss das dann "neutral" an die naechste Schicht kommunizieren, damit
die dann konkrete Links draus macht (die von folgenden Schichten evtl.
wiederum umgeschrieben oder versteckt werden). Und diese Kommunikation zwischen
den verschiedenen Komponenten oder Schichten der Anwendung erfolgt dann
mittels eines fuer diesen Zweck "mit sich selbst" verabredeten Markups.]

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSwWETWITJZieluOzAQJIWgP/cBw38pP/A9RttJ/3dzVKHSDZs+JTB51t
E7hVBob4Wcku4OnMaMopAgA/H1jOvZ4DBCqbt1ehQx0iv6lCDqqvMyNHyBHbtb1f
lguh0Cd4jhTPJteq9J3Hy/ecF3QZRBznYvpqiZWvonppAV99vZuhKXCAFWddVykc
j8m2tHiB7TE=
=Jc0C
-----END PGP SIGNATURE-----