Wer sucht soll auch was finden:
Suche auf der interaktiven CD-ROM

Natürlich: Die Suchfunktion gehört zur CD-ROM wie Google ins Internet. Und ebenso wie für viele die Google Suchmaske als Einstieg ins Web üblich ist, kann in einem Lieferkatalog die Suchfunktion der beste und schnellste Zugang zum Angebot sein. Hier gibt es aber ein paar Fallstricke zu umgehen.

Eine häufige Fehleinschätzung ist der Umfang des Datenbestandes: "Wir haben eine breite Palette an Produkten, für jeden möglichen Fall das Richtige! Man findet es sofort." Um die Dimensionen etwas zurecht zu rücken: Google kennt 8.058.044.651 Web-Seiten. Das ist eine ziemliche Menge. Noch dazu enthält eine durchschnittliche Webseite etwa 500 Wörter. Trotzdem kommt es immer wieder vor, dass nur sehr wenige Ergebnisse gezeigt werden.
Kaum jemand liefert mehr als 10000 Produkte und die Datenmenge pro Produkt, also Preise, Bestellnummern, Beschreibung usw zusammen machen selten mehr als 50 Wörter aus. Diese Datenmenge ist also ein winziger Teil verglichen mit dem Google-Bestand und in Relation sind "nur sehr wenige Ergebnisse" gleich Null.

Nun wird niemand auf die Idee kommen, in einem Lieferkatalog nach "Britney Spears angezogen" zu suchen. Trotzdem: Die Leute sind Google gewohnt und wer 10x hintereinander nichts findet, schmeißt die CD raus und sucht lieber im Web.

Vergessen Sie also die "einfache Suche": ein Eingabefeld + Suche-Schalter. Ich habe schon oft genug gesehen, wie Beta-Tester ratlos davor sitzen und nicht wissen, wonach sie jetzt suchen sollen und wenn, dann nichts finden. Dem Auftraggeber und dem Mediadesigner fällt das natürlich gar nicht auf, die Suchfunktion wird immer mit den gleichen Begriffen getestet. Eine typische Falle: Vorher sehen, was da ist und sich dann freuen, dass es gefunden wird. Funktioniert, super.

Der Benutzer der Suche muss geführt werden. Das erreicht man dadurch, dass man nur mögliche Abfragen anbietet und sofort mögliche Ergebnisse zeigt. Ganz wichtig ist das Anbieten von alternativen Ergebnissen, etwa ähnlichen Produkten, geringfügig abweichenden oder assoziierten Begriffen bzw. Produkten.

Benutzereingaben

Bewährt haben sich Auswahlfelder, wenn sie nicht zu viele Zeilen enthalten. Falls doch, sollte durch die Eingabe von einem oder mehreren Buchstaben die Auswahl auf ein übersichtliches Maß beschränkt werden. Schieberegler und Schalter sind nützlich, wenn Zahlen oder logische Werte (Ja/Nein) einzugeben sind. Allerdings sollte die Art der Eingabe nicht willkürlich gemischt werden: Der Benutzer sollte nicht ständig zwischen Maus und Tastatur wechseln müssen. Die Verwendung der TAB-Taste ist vielen, aber weit nicht allen geläufig, gleichwertig sollte immer auch Return/Enter und die Pfeiltasten Wirkung zeigen.
Konflikte können durch gleichzeitige Maus und Tastaturbedienung entstehen. Ein "Flag" - also eine Variable "WasIstVorrangig" schafft Abhilfe: Bei jeden Tastendruck wird sie auf "tastatur" gesetzt, bei jeder Mausbewegung auf "maus". Im Konfliktfall können so unerwünschte Effekte vermieden werden.

Es ist kein Fehler, sich zunächst einmal über eine sinnvolle Suchmaske Gedanken zu machen. Noch weniger Fehler ist es aber, sie nachträglich zu überdenken und ggf. anzupassen. Die wichtigste Frage ist: Welches Ziel verfolgt der Benutzer und wie führe ich ihn dort hin.

Die interne Datenstruktur, Indexer

Für Director gibt es einige Xtras, die für die Einbindung und schnelle Abfrage von Datenbanken sorgen. In der Praxis sind diese aber meistens überflüssig, weil wir es eben nicht mit einer möglichst schnellen, sondern mit einer möglichst spezifischen Abfrage zu tun haben. Bei weniger als 10000 Datensätzen dauert die Suche mit normalen mehrdimensionalen Listen nur Millisekunden. Wichtig ist vielmehr die Indizierung der Daten schon beim Authoring. Das kann ruhig einige Sekunden dauern - auf der CD selbst liegen die Daten dann schon griffbereit.

Das sorgt einerseits für schnellen Zugriff, andererseits hat das den Vorteil, dass die Daten nicht mehr so leicht rekonstruierbar sind; sprich: Die Konkurrenz kann sie nicht mehr herauslesen.
Das ist kein unwichtiger Aspekt. Ich merke immer wieder, dass hier gewisse Ängste vorhanden sind, etwa dass die Konkurrenz die Daten verwenden könnte. Natürlich kann man alles, was auf einem Bildschirm dargestellt wird kopieren, genauso wie man auch gedruckte Kataloge abschreiben kann.
Tatsächlich kann man Director Daten soweit entschlüsseln, dass einfache Texte unversehrt wieder zum Vorschein kommen. Da aber vorab indizierte Daten nicht in dieser Form auf der CD sind, ist eine Wiederherstellung nahezu unmöglich, zumindest weit schwieriger als die Daten einfach vom Bildschirm abzutippen.

Textsuche

Nehmen wir an, wir haben ein fachspezifisches Glossar mit zB 1000 Textblöcken. Es sollen nicht nur die Titel durchsucht werden, sondern der gesamte Text. Es soll natürlich auch keine Schalter "Nur im Titel suchen" geben und die Reihenfolge der Ergebnisse soll nach Relevanz geordnet sein.
Als Eingabeform ist ein einfaches Textfeld hinreichend. Nach jedem Tastendruck sollen bereits Vorschläge gemacht werden, außerdem sollte sofort die Anzahl der Ergebnisse angezeigt werden. Um auch in relativ kleinen Datenbeständen hinreichend Treffer zu haben ist "Stemming" sehr wichtig. Das bedeutet, dass bei der Suche verschiedene Formen eines Begriffes als gleichwertig erkannt werden; "Netzwerk", "Netzwerks" und "Netzwerke" sind das gleiche, obwohl die Zeichenketten verschieden sind. Allerdings: "Netzwerkkabel" ist etwas anderes - es reicht also nicht, einfach nur " if a contains b" abzufragen.

Die Lösung findet sich in Form einer einfachen Liste aller möglichen Suchbegriffe:
Suchbegriffe = ["aaa", "aab", "aac" usw ]
GefundenIn = [[13, 23, 98, 1], [24, 10], [2], [139, 28, 38, 96]]

Die Liste Suchbegriffe ist sortiert, dadurch lassen sich in kürzester Zeit nach jedem KeyUp Vorschläge heraussuchen und darstellen. Ein weiterer Vorteil ist, dass diese Liste bereits "entmüllt" ist, also Allerweltswörter wie "der" nicht vorkommen und - der besondere Clou - bereits gestemmte Wörter enthält; Ich stelle das gerne durch ~ am Ende dar.
Die zweite Liste "GefundenIn" enthält die Nummern der Textblöcke in der Reihenfolge, wie sie beim Indizieren für relevant befunden wurden. Der erste Eintrag wäre etwa der Textblock, der den Begriff bereit als Titel hat, der zweite der, wo er zumindest im Titel enthalten ist, der letzte derjenige, wo der Begriff nur einmal ganz am Ende des Textes vorkommt.
Verbunden sind beide Listen einfach durch die Position der Einträge. Achtung Stolperstein: Die Liste "Suchbegriffe" muss sortiert sein um schnell darauf zugreifen zu können. Durch eine Sortierung würden aber die Positionen relativ zur 2. Liste verändert werden. Der Trick: Beim Indizieren werden beide Listen gemeinsam sortiert und dann erst getrennt. Durch ein erneutes Sortieren von "Suchbegriffe" wird die Reihenfolge nicht mehr verändert, aber das Flag "sortiert" gesetzt.

Der Indexer ist der Programmteil, der diese beiden Listen erstellt, er wird nur während des Authoring verwendet. Er arbeitet so:
Zuerst werden alle Textblöcke Wort für Wort durchgearbeitet und dabei gleich die Allerweltswörter der-die-das usw ausgelassen. Jedes Vorkommen im Block bekommt abhängig von seiner Position Punkte, pro Block werden alle Punkte zusammengezählt.
Am Ende haben wir eine Liste in der Form: ["daswort":[[Punkte1, blockNr1], [Punkte2, blockNr2]], usw]

Die Wörter werden alphabetisch sortiert, danach werden von vorne weg auf jedes Wort einige Regeln der Grammatik angewendet und überprüft, ob dadurch Wörter entstehen, die bereits vorhanden sind. Letztere werden dann einfach zurechnet, mitsamt den Punkten und Vorkommen. Je nach Art der Daten kann es sinnvoll sein, einige manuelle Ergänzungen zu machen, etwa Synonyme.

Einige Stolpersteine dabei: In Listen wird Groß/klein-Schreibung unterschieden, es empfiehlt sich, alles in Kleinbuchstaben umzuwandeln. Dann hat Director noch Probleme mit Umlauten. Auch hier: Umwandeln Ü zu u und eine Liste der umgewandelten Wörter mitführen, um sie später bei der Darstellung einfach zurückzuwandeln.

Am Ende sollte man den ganzen Wust an Daten in ein Textfeld speichern und noch einmal ansehen: Das eine oder andere Wort braucht nun wirklich nicht im Auswahlfeld auftauchen, sicher findet man auch noch einige Tippfehler ;-) Letztlich werden aus diesem Textfeld die oben genannten Listen "Suchbegriffe" und "GefundenIn" berechnet und in das eigentliche Movie kopiert.

Wertesuche

Anders als bei der Textsuche ist die Anzahl der möglichen Werte meist sehr beschränkt. Nehmen wir als Beispiel den Lieferkatalog eines Herstellers von Kupplungsscheiben. Eine solche Scheibe besteht aus einem Material, ist irgendwie nachbehandelt, hat einen Durchmesser und einige weitere Parameter. Sicher ist: Der Durchmesser ist nicht 2 km und schon gar nicht "groß", also ein Text. Sehr wohl ist aber das Material ein Text, allerdings gibt es nur wenige verschiedene.
Sinnvoll sind also Auswahlfelder mit den möglichen Werten.

Und noch etwas ist wichtig: Wenn wir von zB 1000 verschiedenen Scheiben ausgehen, wird bereits nach 3 Auswahlen kaum mehr etwas gefunden. Schlimmer noch: Wer zB 30cm Durchmesser angibt und den Stahl X, wird nichts mehr finden, weil zB. aus Stahl X nur Scheiben bis 20cm gefertigt werden können, dafür werden aber alle kleinen Scheiben aus diesem Stahl gefertigt. Oder: Nur eine einzige Scheibe im Angebot hat den Durchmesser 35cm. Wer vorher ein bestimmtes Material gewählt hat, wird sie nicht finden. Der Datenbestand ist also nicht einheitlich; leicht passiert es dass die Suche durch einen einzigen Wert blockiert ist.

Ganz wichtig hier: Anbieten von Alternativen, auch wenn sie nicht genau der Suche entsprechen. Es hätte ja auch sein können, dass es dem Benutzer weitgehend egal ist, welcher Stahl verwendet wird, Hauptsache ist der Durchmesser. Damit sind wir bei der Ähnlichkeitserkennung.

Was ähnlich ist, entscheidet die Praxis und kein Allerweltsalgorithmus. Eine Variante ist es, sich mit den Daten und deren Beschaffenheit so weit auseinander zu setzen, dass geeignete Regeln gefunden werden können.
Der Indexer würde dann so eine Liste ablegen:
Nr:[ähnlichNr1, ähnlichNr2, usw]
Bei der Suche selbst werden zunächst alle Volltreffer gesucht, dann ggf noch die ähnlichen Produkte angehängt. Der Haken ist, dass zumindest ein Volltreffer gefunden werden muss.

Eine einfachere und schnellere* - aber ungenauere - Methode ist es, benachbarte Werte in den Auswahloptionen als ähnlich zu definieren. Hier wird der Datenbestand ganz anders abgelegt:
[Nr:[2,5,5,8,9,2]] und dazu Optionen=[["Stahl1", "Stahl2", usw], [usw]]

Das heißt: Nr ist ein Volltreffer, wenn in Auswahlfeld 1 der 2. Eintrag gewählt wurde, in Auswahlfeld 2 der 5. usw. Die 2. Liste definiert, dass Auswahlfeld 1 als 2. Eintrag "Stahl2" enthält. Bei der Suche wird für jede Datenzeile überprüft, welche Abweichungen gefunden werden und von 100% weggerechnet. Am Ende wird noch sortiert und das Ergebnis nach % Übereinstimmung angezeigt.
Diese Variante lässt sich gut steuern und ist sehr flink, weil nur Zahlen verglichen werden. Natürlich können für einzelne Felder abweichende Regeln oder KnockOut-Kriterien definiert werden.

Der ganz besondere Vorteil aber ist, dass immer Ergebnisse gefunden werden, der potentielle Kunde wird nicht einfach stehen gelassen, sondern kann selbst entscheiden, was für ihn wichtig ist. Der Benutzer kann sich über Alternativen informieren und wird sich weit mehr mit dem eigentlichen Angebot befassen.

*Schnell: Das Durchsuchen von 10000 Datensätzen nach je 6 Kriterien, die Berechnung der Abweichungen und Sortierung der Ergebnisse dauert auf einem durchschnittlichen Gerät nicht einmal 1/10 Sekunde.