Bibliothekskataloge für mobile Endgeräte

27. Januar 2010 um 18:40 27 Kommentare

Nach der Anfang November 2009 vorgestellten Delphistudie „Zukunft und Zukunftsfähigkeit der Informations- und Kommunikationstechnologien und Medien“ werden ab 2015 in Deutschland mehr Menschen das Internet regelmäßig über mobile Endgeräte als über stationäre Computer nutzen. Was das für Bibliotheken bedeutet, wird im englischsprachigen Ausland schon länger diskutiert, beispielsweise in Always on: Libraries in a world of permanent connectivity (Lorcan Dempsey, Januar 2009) und im mobile libraries blog. In Deutschland waren mobile Dienste unter Anderem auf dem BibCamp Thema und werden regelmäßig im Blog der Zukunftswerkstatt und in anderen Teilen der Biblioblogosphäre behandelt, z.B. bei Medinfo und in netbib.

Während der Bibliothekskongress 2010 schweigt, wurde auf dem ALA Midwinter Meeting von LibraryThing ein Angebot vorgestellt, dessen Preisliste nun vorliegt: für einige Hundert bis Tausend Dollar im Jahr stellt LibraryThing jeder beliebigen Bibliothek eine mobile Version ihres OPACs zur Verfügung. Wie das ganze technisch funktionieren soll, wird nicht erklärt, es ist nur von „90% aller OPACs“ die Rede und es werden Bibliotheken als Erstanwender gesucht – interessierte deutschsprachige Bibliotheken bitte vor!

Während einige Bibliotheken ihr gesamtes Angebot in Form einer iPhone-App zur Verfügung stellen (die ZB Med Köln angeblich auch – weiß jemand mehr?), geht der Trend insgesamt eher dahin, die Webseiten der Bibliothek so zu gestalten, dass sie auch (oder speziell) für mobile Endgeräte einfach zu verwenden sind. Dazu muss eine auf mobile Endgeräte angepasste Version des Katalogs erstellt werden, die automatisch durch Erkennung des User-Agent oder unter einer eigenen, URL (meist m.domain statt www.domain) erreichbar ist. Während die mobilen Katalogseiten 2008 noch eher spartanisch aussahen, ist inzwischen – zumindest bei anderen Unternehmen – eine Optik im iPhone-Stil Standard. Die im Library Success Wiki aufgeführten mobilen Katalogoberflächen sehen zwar weniger schick aus, sind aber dafür auch für Menschen mit älteren Handys nutzbar, die sich noch kein iPhone oder vergleichbares Handy für den mobilen Internetzugang leisten können.

Auffällig ist in jedem Fall, dass deutsche Bibliotheken nicht gerade Vorreiter dabei sind, ihre Kataloge auch für mobile Endgeräte anzupassen – eine diesbezügliche Anfrage von Christan Hauschke blieb weitgehend unbeantwortet. Das liegt unter Anderem daran, dass der Katalog zu oft noch als ein monolithisches System verstanden wird – die Idee der Serviceorientierten Architektur ist nicht angekommen. Anstatt auf offene Schnittstellen und Standards zu setzen, werden mit Primo, Touchpoint und diversen andere kommerziellen „Discovery-interfaces“ neue Einbahnstraßen zu IT-Systemen eingeschlagen, die am Ende niemand anpassen und warten kann und/oder will (während ich bei Primo nichts dergleichen gefunden habe, enthält die aktuelle Entwicklungsversion von VuFind dagegen übrigens eine Mobil-Oberfläche).

Ich vermute, dass LibraryThing mit ihrem Angebot auf Schnittstellen wie SRU und Z39.50 zurückgreift und so auf ein bestehendes lokales Bibliothekssystem aufbauen kann anstatt dieses zu ersetzen. Das hieße jedoch, dass aktuelle Ausleihinformationen außen vor bleiben, solange keine Schnittstelle für Verfügbarkeitsdaten etabliert ist. Falls eine Bibliothek auf die gleiche Weise selber einen mobilen Bibliothekskatalog entwickeln möchte, habe ich als Vorlage für die weitere Progammierung eine Mobilversion für PICA-Systeme erstellt. Die Suche läuft standardmäßig über die SRU-Schnittstelle des GVK und kann bei Bedarf auf einzelne Bibliotheken eingeschränkt werden. Der Quellcode (PHP, HTML, CSS) steht unter der AGPL frei, so dass Verbesserungen auch Anderen zugute kommen.

27 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Lieber Jacob,

    das Thema werden wir auf der Bibliothekskongress in Leipzig intensiv beschäftigen. Eine interessante Veranstaltung planen wir gerade, ich werde diese Woche noch die offizielle Ankündigung im Blog veröffentlichen, wird bestimmt sehr spannend sein.

    Liebe Grüße,
    Jin

    Comment by jintan — 27. Januar 2010 #

  2. Lieber Herr Voß,

    eine Lösung zu finden für die Nutzung unserer OPACs an Mobiles ist ein sehr wichtiges Thema. Da tut sich in der Tat noch zu wenig.

    Was SRU und Z39.50 betrifft bin ich skeptisch. Wo bleiben da die Suchmaschinenfunktionen (z.B. Drill-Downs) ? das kann man m.W. über SRU oder Z39.50 nicht machen.

    Was den Zugriff auf Exemplar- und Verfügbarkeitsdaten betrifft, könnte doch NCIP eine Lösung sein ?

    Schöne Grüße,

    Robert Scheuerl

    Comment by Robert Scheuerl — 28. Januar 2010 #

  3. Einer der Vorteile von SRU und Z39.50 ist, dass beide Schnittstellen in Bibliothekssystemen wenigstens einigermaßen etabliert sind, so dass andere Anwendungen darauf lose gekoppelt (d.h. ohne wesentliche Änderungen am Bibliothekssystem) aufbauen können. Das oben genannte PHP-Skript ist ein Beispiel dafür, wie einfach die Entwicklung ist, wenn erstmal standardisierte Schnittstellen verfügbar sind.

    „Suchmaschinenfunktionen“ (auch „Suchmaschinentechnologie“) ist dagegen keine Schnittstelle sondern ein Buzzwort, unter dem jeder etwas anderes verstehen kann – also das Gegenteil von einem Standard. Damit lässt sich Bibliotheken ohne Grundverständnis von zugrunde liegenden Prinzipien des Information Retrieval das Blaue vom Himmel versprechen und Software andrehen, die schon veraltet ist, bevor sie überhaupt fehlerfrei funktioniert.

    Für konkrete Funktionen wie zum Beispiel Drill-Downs (aka „Facetten“) sind konkrete Schnittstellen notwendig, für die es oft leider bisher keine Standards gibt. Es gibt zum Beispiel verschiedene Vorschläge, SRU um Facetten zu erweitern, zum Beispiel hier, hier, und hier (PDF) und der aktuelle Draft von SRU 2.0 (July 2009) enthält auch Facetten. Das hilft jedoch alles nicht viel, solange SRU 2.0 in Bibliothekssystemen nicht umgesetzt und verfügbar ist.

    Bibliotheken, die alle möglichen Suchfunktionen haben möchte, sollten lieber darüber nachdenken, ihren gesamten Katalog als Datenbankdump zum Download anzubieten (oder über Schnittstellen wie OAI-PMH), damit andere Anwendungen darüber verschiedene Suchinterfaces anbieten können. Die meisten Möglichkeiten bietet dazu Solr; hier ist beschrieben wie der Solr-Index dann wieder per SRU zugänglich gemacht werden kann.

    Was NCIP betrifft habe ich bisher keine offen zugänglichen NCIP-Schnittstellen gesehen, auf die sich aufbauen ließe. Ich propagiere ja DAIA; eine offene NCIP-Schnittstelle wäre aber auch schonmal besser als nichts.

    Comment by jakob — 28. Januar 2010 #

  4. […] Wie wichtig Funktionen wie personalisierbare Seiten sind, wurde hierzublog nun schon oft genug erwähnt. Und in Rochester kann man sich nun am praktischen Beispiel ansehen. Open Access kommt nur voran, wenn die Server den Wissenschaftlern handfesten Mehrwert bieten. Repository-Entwickler, sehr Euch IR+ bitte genau an! Das Repository selbst muss diese Funktionalitäten nicht unbedingt anbieten, aber die Schnittstellen dafür müssen geschaffen und gut dokumentiert werden. Mehr zum Thema Schnittstellen (Serviceorientierte Architektur) übrigens aktuell im Jakoblog. […]

    Pingback by Repository-Software IR+ » Infobib — 28. Januar 2010 #

  5. […] Jakob hat absolut Recht, dass das deutsche Bibliothekswesen momentan mit dem aktuellen Thema “mobile Endgeräte für Bibliotheken” zu wenig beschäftigt. Aber die Situation versuchen wir auf der Bibliothekskongress zu ändern. […]

    Pingback by Smartphone Happening auf Bibliothekskongress 2010 « Zukunftswerkstatt 2009 — 29. Januar 2010 #

  6. Mit dem Einsatz von Suchmaschinentechnik für Bibliotheks-OPACs ist ein wesentlicher Fortschritt erreicht worden. In der Kombination mit Drill-Downs und Raking-Methoden ist es nun in Biblioths-OPACs endlich guten Gewissens möglich eine einfache Suche, wie man Sie von Suchmaschinen kennt anzubieten. Bisher war der Benutzer da ziemlich alleine gelassen.
    Wenn mit SRU 2.0 solche Dinge wie Drill-Downs transportiert werden können, ist das natürlich eine feine Sache. Mal sehen, ob das dann auch von den Systemen serverseitig angeboten wird. Das wird kein einfacher Prozess. Bis dahin kann man eigentlich nur die Query-Server der Suchmaschinen mit ihren eigenen Query-Sprachen direkt angehen, was natürlich keine schöne Lösung ist.
    Natürlich könnten Bibliotheken ihre Daten auch als Dump anbieten. Dann hat man aber das Problem, die Daten aktuell zu halten. Alle möglichen Plattformen ständig mit Daten zu versorgen halte ich für keine schön Vorstellung. Der Trend geht doch eher dahin, dass man für die Recheche Suchmaschinenindexe verfügbar macht, sei es mit Lucene oder FAST.
    Bei NCIP sehe ich halt den Vorteil, dass diese eine international bekannte Schnittstelle ist. DAIA ist ja auch was propreäteres und erst mal ein Versuch. Auch hier muss man sehen, wie sich die Unterstützung durch die Hersteller entwickelt.
    Man sollte nicht vergessen, dass genauso wenig wie ein Bibliothekssystem nur aus einem OPAC besteht, ein OPAC nur aus Recherche besteht. Da gehört mehr dazu, insbesondere personalisierte Funktionen. Ich glaube nicht, dass man das so einfach machen kann.

    Comment by Robert Scheuerl — 1. Februar 2010 #

  7. Die Dump-Daten aktuell zu halten, ist eine Herausforderung, der sich die Bibliotheken stellen sollten. Wir Bibliothekare wissen nicht, was die Nutzer wollen. Geben wir Ihnen doch einfach mal die Mittel in die Hand, das selbst auszuprobieren.

    PS: DAIA ist übrigens nicht proprietär.
    PPS: Wo kann man NCIP mal ausprobieren? Ist mir noch nie begegnet.

    Comment by CH — 1. Februar 2010 #

  8. Mir ist noch kein einziger Suchmaschinenindex begegnet, der verfügbar gemacht worden wäre – da von einem Trend zu sprechen, halte ich für gewagt. Haben sie ein Beispiel wo ich mir einen Index herunterladen kann? Es handelt sich wohl eher um eine weitere Vernebelung, mit der Bibliotheken vorgegaukelt wird, sie hätten Ahnung von Information-Retrieval. Wer nicht mal – wenn er es denn wöllte – regelmäßig seine eigenen Daten als Dump anbieten kann (und/oder zum Harvesten per OAI-PMH, Atom etc.) ist offensichtlich völlig damit überfordert irgend etwas sinnvolles mit den Daten anzustellen, denn das Kopieren und Updaten ist lediglich der erste Schritt, um mehr damit zu machen (z.B. einen Suchmaschinenindex aufzubauen). Wenn „international bekannte Schnittstelle“ im Bibliotheksbereich bedeutet, dass auf die Frage nach einer brauchbaren Schnittstelle mit einem 4-Buchstaben-Kürzel wie „NCIP“ geantwortet wird, aber niemand weiß, was eigentlich dahinter steckt und wie man es benutzen kann, weil die Schnittstellen nur innerhalb eines abgeschlossenen Systems verwendet werden – dann würde ich NCIP auch so bezeichnen.

    Comment by Jakob — 2. Februar 2010 #

  9. Es macht wenig Sinn, fertige Indexe einer „Suchmaschinentechnologie“ auszutauschen. Das ist etwa so sinnvoll wie der Austausch der Dateien, in denen Datenbanksysteme wie Oracle, Sybase oder MySQL ihre Daten halten…
    So ein Index einer „Suchmaschine“ ist eine Sammlung von binären Dateien, die für einen speziellen Anwendungsfall erzeugt wurden (durch „Indexierung“). Die machen außerhalb dieses Anwendungsfall überhaupt keinen Sinn, auch wenn der Austausch bei z.B. Solr und Lucene durchaus technisch möglich ist (aber eben überhaupt nicht sinnvoll).

    Comment by till — 2. Februar 2010 #

  10. Es geht doch wirlich nicht darum Daten oder Indexe auszutauschen, das macht doch wenig Sinn. Sollen wir uns denn nur noch damit beschäftigen ständig Massen von Daten in der Landschaft hin und her zu transportieren. Das kanns doch nicht sein ?
    Wir sollten noch mal zum Ausgangspuntk zurück kommen. Es ging um die Verfügbarkeit von Bibliothekskatalogen auf mobilen Geräten. Mein Hinweis war, dass man dabei den mit dem Einsatz von Suchmaschinentechnik erreichten Fortschritt auch da nutzbar machen sollte. Das geht mit Z39.50 nicht, evtl. aber irgendwann mit SRU (mal sehen). Einstweilen könnte man also nur die proprietären Query-Schnittstellen von FAST oder Lucene (weitere sind mir im Bibliotheksumfeld nicht bekannt) nutzen.
    Hinweis: Die OPACs der bayerischen Hochschulbibliotheken basieren für die Recherche mittelerweile alle auf FAST-Indexen. Es ist also nicht so, dass es keine Suchmaschinenindexe gäbe.
    Zu NCIP: Ich habe nicht angenommen, dass ich erklären muss was NCIP (bzw. Z39.83) ist, das bekommt man aber leicht raus. Jedenfalls ist das eine Schnittstelle die alternativ zu SIP2 heute schon Verwendung findet für die Anbindung von Automaten (z.B. Selbstverbuchungsstationen oder Bezahlautomaten) an Bibliothekssysteme.
    Nun zur Frage der Verfügbarkeit der Schnittstellen: Das ist letztlich eine Entscheidung des Betreibers. Man darf dabei auch nicht vergessen (das kann man finden wie man will, muss man aber akzeptieren), dass es da auch lizenzrechtliche Fragen zu berücksichtigen gilt, wenn es sich um kommerzielle Software handelt. Mit dem vermehrten Einsatz von Open Source Software, wie z.B. Lucene, wird sich das sicher bessern.

    Comment by Robert Scheuerl — 3. Februar 2010 #

  11. […] für Hannover (Achtung: funktioniert absolut noch nicht so, wie es mal sein soll. Mehr darüber bei Jakob Voss, von dem ich das Skript auch übernahm.) stöberte ich mal wieder ein wenig in den Katalogisaten im […]

    Pingback by EKIs schon aktiv? » Infobib — 12. Februar 2010 #

  12. […] Infobib erwähnte ich gerade kurz meinen mobilen Testkatalog, für den Jakob Voss die Grundlage […]

    Pingback by Mobiler Hobsy-Katalog? « Bibliotheken in Hannover — 12. Februar 2010 #

  13. Schade dass Sie nicht zum Workshop nach Bremen zur FAG-Sitzung am 26.1. kamen. Sie hätten sicherlich so manches Vorurteil gegen Primo selbst gegenprüfen (und revidieren) können. Ãœbrigens kann Primo über mobiles gesucht werden (Die ersten Sites boten das bereits im Sommer 2009 ihren Nutzern an). Geben Sie doch einfach z.B. die Primo URL der Uni Oxford „http://solo.ouls.ox.ac.uk/“ in Ihr I-Phone oder Handy ein und starten Sie ihre Suche? Und übrigens ist alles offen gelegt in der Ex Libris Open Platform, wo z.B. Entwickler von Kunden-Sites ihre Codes, Add-ons und Gedanken austauschen, die selbständig an die offenen APIs gedockt wurden. Jeder Ex Libris Anwender hat dazu Zugang. Hey, nutzen Sie nicht beim GBV auch SFX? Dann schauen Sie mal da vorbei. 😉

    Comment by Jürgen Küssow — 22. Februar 2010 #

  14. Vielen Dank für die Hinweise. Leider kann ich ihre Aussage nicht verifizieren, da Primo anscheinend Android-Handys nicht als Mobilgeräte erkennt, können sie das bitte beheben? Lässt sich die Mobilversion auch über eine eigene URL á la http://m.solo.ouls.ox.ac.uk/ triggern? Meine Vorurteile gegenüber Primo entstammen unter anderem der eigenen Anschauung von öffentlich zugänglichen Primo-Installationen, z.B. der Mannheimer KOBV-Installation. Angesichts der vermurksten URLs und redirect-Kaskaden kann ich dort nicht erkennen, dass Primo und/oder seine Anwender das Web verstanden hätten. Was die Ex Libris Open Platform betrifft, halte ich das für einen guten Service für bestehende Ex-Libris-Anwender und für Werbe-Blabla für die übrigen, denn von „Open“ kann ja nicht die Rede sein, wenn das ganze eine geschlossene Veranstaltung bleibt und Produktdetails nicht weitergegeben werden dürfen. Bitte korrigieren sie mich, falls die Inhalte der Platform für alle online frei einsehbar sind!

    Comment by jakob — 23. Februar 2010 #

  15. Ich finde Polemik sollte nicht die Grundlage von Urteilen sein – nicht auf ‚der‘ Ebene, auf der man vorgibt sich zu bewegen. Verifizieren finde ich wie Sie sehr wichtig. Ich bin da ganz d’accord. Ich lade Sie ein, sich mit uns in Leipzig zusammen zu setzen, damit Sie Gelegenheit haben, direkt mit uns zu kommunizieren und nicht nur über Hören und Sagen Urteile zu treffen. Wir hatten bisher noch nicht die Gelegenheit, Sie persönlich kennen zu lernen, daher würde ich Sie gerne mit meinem Kollegen bekannt machen, mit dem Sie sich fachbezogen austauschen könnten. Keine Software kann es allen recht machen, umso interessanter ist es mehr über die Richtung zu erfahren, in der die Software entwickelt wird und darüber auch in einen kritischen Dialog zu treten. Ich würde mich sehr freuen, wenn Sie uns die Gelegenheit gäben, direkt mit ihnen zu diskutieren und Gedanken auszutauschen. Viele Grüße, Jürgen Küssow

    Comment by Jürgen Küssow — 23. Februar 2010 #

  16. Hallo Herr Küssow.

    Ich habe ich mal screenshots mit einem iPhone gemacht und bin ihrer Aufforderung „Geben Sie doch einfach z.B. die Primo URL der Uni Oxford “http://solo.ouls.ox.ac.uk/” in Ihr I-Phone oder Handy ein und starten Sie ihre Suche?“ gefolgt.

    So sieht die Startseite aus: http://de.tinypic.com/view.php?pic=2l8d7ww&s=6 Den Inhalt dieser Oberfläche kann man nicht lesen. Wenn man bedenkt, dass der screenshot auf einem Computer Bildschirm größer dargestellt wird als als dem iPhone screen, wird´s noch schlimmer. Gibt man eine Sucheanfrage ein, dann erhält man folgendes Bild: http://de.tinypic.com/view.php?pic=6z80m9&s=6 Und die Ergebnisse präsentieren sich so: http://de.tinypic.com/view.php?pic=wswt8i&s=6

    Wenn Sie das als mobile Version von Primo anpreisen, kann man davon ausgehen, dass Sie selbst Ihr eigenes Produkt mobil nicht nutzen (müssen). Oder habe ich das mit der Oberfläche und „mobiles“ falsch interpretiert? Wenn sie das unter mobiler Nutzung verstehen, dann scheint das für sie nur eine Spielerei zu sein, die keiner braucht.

    Comment by Gerald — 23. Februar 2010 #

  17. Meine Polemik ist nicht Grundlage eines Urteils sondern Ausdrucksform eines Urteils auf Basis dessen was öffentlich von Primo sichtbar ist. Wenn sie mir Internetquellen nennen können, aufgrund derer ich mein Urteil revidieren sollte, dann bitte her mit den Links! An nicht-zitierbaren Hinterzimmer-Hinweisen habe ich wenig Interesse, sondern bevorzuge den fachbezogenen öffentlichen Austausch, so dass jeder die Aussagen verifizieren kann. Dementsprechend nutzt auch eine nur für ExLibris-Kunden einsehbare Dokumentation nichts.

    Comment by jakob — 23. Februar 2010 #

  18. Vielen Dank für Ihre Rückmeldung. Bei meinen Mobilgeräten (iPhone und Handy) kann ich die Primo-Oberfläche in Oxford gut nutzen (inkl. FRBR, Facetten, GetIT usw.). Allerdings habe ich bei Nachfrage in Oxford erfahren, dass noch kein App erstellt wurde. Ab der neuen Version 3 im April haben wir das für die Primo Sites direkt abrufbereit. Es würde mich jedoch interessieren, wie bei Ihnen Primo der Brigham Young University http://lib.byu.edu/m/ aussieht. Hätten Sie Lust die URL zu checken? Vielen Dank und Grüße, Jürgen Küssow

    Comment by Jürgen Küssow — 23. Februar 2010 #

  19. Hallo Herr Voss, mein Angebot steht nach wie vor. Es handelt sich nicht um – wie haben Sie es genannt? – nicht zitierbare Hinterzimmerhinweise, die wir Ihnen geben wollen. Sie können alles gerne posten, was Sie mit uns in Leipzig besprechen. Es dürfte doch auch in Ihrem Interesse sein sich richtig zu informieren und danach fundiert zu argumentieren. Wir haben keine Berührungsängste. Sollten Sie auch nicht haben, daher – wie gesagt – würden wir uns freuen, wenn Sie unsere Einladung annehmen. Viele Grüße, Jürgen Küssow

    Comment by Jürgen Küssow — 23. Februar 2010 #

  20. Hallo Herr Küssow.
    Die mobil-Version (http://lib.byu.edu/m/) der Harold B. Lee Library Recherche (http://lib.byu.edu) funktioniert. Auch gelangt man, im Falle (m)eines iPhones von der „normalen“ Oberfläche automatisch auf die „mobile“, kann aber wieder auf „non-mobile“ zurückkehren. Das sieht sehr nach dem OpenSource Projekt WebKit (http://webkit.org) aus. Aber das muss ja kein Nachteil sein 😉

    Comment by Gerald — 23. Februar 2010 #

  21. Ich glaube die mobile Seite der der Harold B. Lee Library basiert auf einem anderen OpenSource Projekt und zwar iUi. Letzendlich macht es jedoch keinen großen Unterschied; die Discovery-Interfaces sind alle ähnlich aufgebaut und benutzen teilweise sogar die gleichen Softwarekomponenten. Ob Primo, TouchPoint, vuFind oder was auch immer: wer sich nicht mit den Details beschäftigen möchte, bekommt nur eine veraltete Standardversion (z.B. bei Primo bislang ohne mobile Oberfläche) und wer selber etwas macht, kann auch mehr bekommen.

    Comment by jakob — 23. Februar 2010 #

  22. Seit dem letzten Kommentar ist etwas Zeit verstrichen.

    Schaut mal hier:
    http://www.elbedev.com/EDsync/EDsync_for_iPhone.html

    Ich habe das Ding gebaut und es greift auf die Nutzerkonten im OPAC zu. Ich haette ungemein gerne eine xml-Schnittstelle zu den Nutzerkonten… leider gibt es bisher nur eine einzige xml Schnittstelle bei der Ausgabe der Suchergebnisslisten.

    Beste Grueße aus Hamburg.

    Comment by Martin Kim Dung-Pham — 26. Januar 2011 #

  23. Ja, diese XML-Schnittstelle (oder irgend etwas anderes, das besser strukturierte Daten als Antwort auf klar definierte Requests ausgibt als die HTML-Oberfläche) hätten viele gerne… 🙂

    Comment by till — 26. Januar 2011 #

  24. Ja, für die Nutzerkonten gibt es noch keine richtige Schnittstelle. Aber wir könnten ggf. mit DAIA genauere Angaben darüber liefern, ob ein Titel gerade ausgeliehen oder ausleihbar ist und, an welchem Standort sich ein Buch befindet und ob es erst bestellt werden muss. Bislang werden über DAIA allerdings nur einige Bibliotheken rudimentär abgedeckt (Hier ein Beispiel) und müssten noch einzeln konfiguriert werden.

    Comment by jakob — 26. Januar 2011 #

  25. DAIA wurde von mir von meiner Bibliotheksleiterin ebenfalls vorgeschlagen. In EDsync wurde von Anfang an der Fokus auf die Entleihungen und Verlängerungen, also alles Nutzerspezifische gelegt. Die Suche im Katalog ist sehr „schlicht“, um es gelinde auszudrücken. Ich habe inzwischen sogar eine Möglichkeit zum Ausblenden der Suche eingebaut, weil ich so unzufrieden mit ihr war. Ich werde mich mit DAIA beschäftigen, sobald die Suche verbessert wird. Diese Richtung ist für mich als Entwickler interessanter, weil für die Nutzer mehr rauszuholen ist. Wie diese an ihr Objekt der Begierde gelangen, finden sie dann schon raus 😉
    Letztlich ist es schon mein Ziel, beides auf die kleinen Schirme zu bekommen, also Nutzerdaten und Katalog inklusive Angaben zur Verfügbarkeit..

    Comment by Kim — 28. Januar 2011 #

  26. […] Suchergebnissen aus. Jakob Voss hat seine Erfahrungen mit der Thematik und schon vor längerer Zeit festgestellt: Das liegt unter Anderem daran, dass der Katalog zu oft noch als ein monolithisches System […]

    Pingback by Infobib » Mobiles Bibliothekskonto von elbedev — 18. März 2011 #

  27. […] Voss hatte bereits Anfang 2010 in einem Blog-Artikel die Entwicklungen im Bereich mobiler OPACs skizziert und eine eigene Design-Studie für […]

    Pingback by Ein mobiler Katalog mit jQuery Mobile - OpenBibBlog — 13. September 2011 #

Sorry, the comment form is closed at this time.