Interessantes aus Hamburg

Ursula Schulz schreibt im Beluga Blog über die Ergebnisse einer Usability Evaluation des ersten Prototypen dieses Hamburger Kataloges. Lesenswert! Insbesondere auch der Abschnitt <geschichte>, auch für KollegInnen über 50. Denn er zeigt mal wieder: Die Ärgernisse von heute sind nicht neu und Lösungsmöglichkeiten existieren (schon etwas länger). Man muss sie nur mal umsetzen. OK, das ist im Detail nicht einfach. Man kann nicht einfach ein bischen „Soundex“ nehmen und das mit „Porter Stemming“ oder der modernen Snowball-Implementierung davon anrichten und schon hat man Usability Probleme gelöst. Die Probleme und Problemchen liegen zum einen in technischen Details (Porter Stemming ist z.B. sprachspezifisch, es ist aber keinesfalls immer klar, in welcher Sprache Daten vorliegen, kann man auch wieder mit recht hoher Wahrscheinlichkeit erraten, z.B. mit NGramJ, ist aber zusätzlicher technischer Aufwand…). Zum anderen muss man solche Funktionalitäten sinnvoll nutzen und geeignet an die Oberfläche bringen. Ist alles lösbar (sogar mit open source software), aber eben Arbeit. Warum machts keiner/kaum jemand in den kommerziell erhältlichen Produkten?

Der Artikel zeigt auch, warum echte Tests mit echten Benutzern wichtig sind. Und warum man früh damit beginnen sollte. Der Wunsch der Benutzer nach einer erweiterten Suche ist in der Tat überraschend (und ist ein einfaches Beispiel dafür, wie vermeintliche Experten sich bei den Wünschen von Nutzern eben irren können). Auch unser Ansatz (eben als vermeintliche Experten) war bisher: Ein Suchschlitz, in den man eintippen kann, was einem auf dem Herzen liegt. Wenn man weiß, dass man einen Artikel von S. 128 aus der Ausgabe 5045 von Nature braucht, soll man diese Angaben halt in den Suchschlitz schreiben und den ersten Treffer nehmen. Eventuell entspricht diese Vorgehensweise aber nicht dem mentalen Modell, das Benutzer von einem Bibliothekskatalog haben? Ich habe deswegen auch erstmal keine Antwort auf die erste der beiden Fragen am Ende des Artikels von Frau Schulz. Meine Antwort wäre eben bis gestern Abend gewesen: Im Idealfall gibt es keine Unterscheidung zwischen KnownItem- und offener Suche, das muss das Retrievalsystem mit einem Zugang leisten. Ist aber vielleicht doch falsch?

Die Antwort auf die zweite Frage steht übrigens im Prinzip in der RelevancyFAQ zu Solr. Da gibts aber nicht die fertige Lösung, sondern „nur“ Anregungen zur technischen Umsetzung. Machen, ausprobieren und verbessern muss man es dann immernoch. Und an der Oberfläche geeignet darstellen… Genug Arbeit also, die sich schon aus einer kleinen Frage ergibt.

Was hat das nun mit unserem Projekt zu tun? Wir haben eigentlich genau die gleichen Probleme wie die Kollegen in Hamburg und wollen sie lösen. Und wir setzen ähnliche Technik (Solr) ein. Deswegen ist ihre Arbeit sehr wertvoll für uns (Danke!), so entsteht auch Nachhaltigkeit aus Projekten. Wir werden dennoch nicht umhin kommen, selbst auch Benutzertests mit unserer „Suchkiste“ zu machen. Mich persönlich interessieren dabei weniger Aspekte wie „runde Ecken und Hintergrundfarben“ oder „wo muss die Funktion X hin?“ (wobei das natürlich ganz wichtige Dinge sind, ich bin da aber erstmal ignorant), sondern eben „Wie glücklich bist du mit den Treffern?“. Das kann man selbstverständlich nicht mit unseren gut funktionierenden Lieblingsbeispielen beantworten. Gerald schrieb ja schon, dass wir eigentlich gar nichts wissen wollen, wenn wir unsere schönen Beispielsuchen eintippen – deswegen ist es eigentlich auch egal, was da als Trefferliste rauskommt. Wir brauchen echte Fragestellungen, die sich mit unserer Suchkiste sinnvoll beantworten lassen.

2 comments.

  1. Danke, Till. Was besonders weiter hilft: zu wissen, dass wir an den gleichen Problemen arbeiten. Deshalb freue ich mich auf unser Treffen in Göttingen.

    Zu der Sache mit dem Suchschlitz, der alles kann:

    Ich denke, wir sollten bei den Tests der nächsten beluga-Version ausschließlich mit ‚echten‘ Anliegen arbeiten. Unsere ersten Tests haben die üblichen Suchgattungen abgeklopft, um im ersten Prototypen wesentliche Kinken identifizieren zu können. Die TPP suchten zunächst mit einem eigenen Anliegen, bearbeiteten danach aber nur noch vorgegebene Aufgaben: vorgegebenes Thema mit vielen Treffern, vorgegebenes Thema mit wenigen Treffern, KnownItem Buch, KnownItem Zeitschrift. Ich habe die TPP dabei laut denken lassen und Fragen nach ihren Beweggründen gestellt. Im nächsten Test möchte ich der Realität noch ein bisschen näher kommen, indem ich die TPP ungestört arbeiten lasse und erst danach das resultierende Video mit ihnen durchspreche.

    Wir gingen vermutlich alle von dem Modell Google aus und seinem Erfolg. Ich würde diese Idee auch ungern aufgeben. Es gibt bei aller Machbarkeit im Backend allerdings Gründe, über ein bisschen Komplexität im UI nachzudenken, die dann aber lustbetonter sein muss. Eine Studentin von uns hat gerade eine Bachelorarbeit zu dem Aspekt der „affektiven Ebene bei der thematischen Web-Informationssuche“ abgegeben. Ich melde mich wieder, wenn ich die Arbeit gelesen habe.

  2. […] letzte Woche im Beluga-Blog zur Geschichte der Usability-Evaluation von Online-Katalogen [via Suchkisten-Blog, wo mein Kollege Till zu recht schreibt: „Ist alles lösbar (sogar mit Open Source Software), […]