uxzentrisch erörtert:
Drei Regeln für die Search-As-You-Type-Suche

Seit einiger Zeit gibt es auf der Apple Website eine »Search As You Type« (kurz auch »SAYT« oder »inkrementelle Suche«), die dem Nutzer schon während der Eingabe eines Suchbegriffs passende Suchergebnisse anzeigt. Als mir die Funktion bei apple.com auffiel, war ich begeistert von der Schnelligkeit, mit der so die Ergebnisse einer Suche erfahrbar wurden.

Kürzlich wurden mir einige knifflige Details bei dieser Art von Suchergebnis-Präsentation bewußt. Ich habe das zum Anlass genommen, ein paar allgemeine Regeln für die SAYT-Suche zur Diskussion zu stellen.

Durch einen Freund wurde ich auf ein Apple Desktop Widget aufmerksam, mit dem man Regenradar-Bilddaten darstellen kann. Nützlich, wenn man wissen will, ob es in nächster Zeit regnen könnte. Also begebe ich mich in den Download-Bereich. Da frage ich mich kurz, ob die Website-Suche oben rechts auf der Seite auch gezielt nach Widgets sucht. Ich probiere es aus und gebe »radar« in die Suche ein. Sofort erscheint ein Treffer im Dropdown-Menü: »Radar in Motion – Displays animated weather maps from NOAA and weather.com«.

Zunächst bin ich der Meinung, schon am Ziel zu sein. Die Information auf der Detail-Seite des Widgets deutet aber an, dass mit diesem Widget nur Radardaten für die USA angezeigt werden können. Nach meiner Information sollte es aber auch ein Widget für Deutschland geben.

Ich probiere eine weitere Suche, diesmal gebe ich »regen« ein. Im Dropdown-Menü erscheinen diesmal keine Treffer. Bei genauerem Hinsehen allerdings sehe ich den Text »No shortcuts found. Try a full search of apple.com«. Nun erhalte ich auf der Seite ein Suchergebnis, in dem ausschließlich iTunes-Titel wie z.B. »Regen« von den Bösen Onkelz enthalten sind.

Also noch immer keine Spur vom Regen-Radar Widget. Eigentlich bin ich hier schon der Meinung, dass es das Widget entweder nicht bei apple.com geben kann, oder dass die Suche dieses Widget nicht finden kann.

Aus irgend einem Grund probiere ich es dann doch noch ein drittes mal, diesmal mit »regenradar«. Wieder findet die Autocomplete-Suche keine »Shortcuts«. Nach Absenden mit der Enter-Taste jedoch werden tatsächlich zwei Treffer angezeigt, darunter das gesuchte Widget mit dem Namen RegenRadar.

Wie kann es sein, dass weder die Suche nach »regen«, noch die Suche nach »Radar« dieses Widget gefunden hat? Nun, es sieht ganz so aus, als käme keines der beiden Wörter einzeln in den Daten zum RegenRadar-Widget vor. Nur im Namen sind beide Begriffe enthalten, allerdings nicht als ganze Wörter, sondern in Kombination.

Da offenbaren sich zwei Schwächen der Suchlogik. Die eine: Es wird nicht nach Teil-Zeichenketten gesucht. Das ist ein durchaus häufig anzutreffendes Problem, denn es verursacht einen deutlich größeren Daten- und Rechenaufwand, bliebige Teil-Zeichenketten aus Texten zu indizieren, als wenn nur ganze Wörter indiziert werden. Das andere Problem: Die Search-as-you-type-Funktion, die schon während der Eingabe von Begriffen passende Treffer anzeigt, vermittelt dem Nutzer genau das Gegenteil. Der Nutzer erhält während der Eingabe eines Suchbegriffs den Eindruck, dass ein Treffer mit dem Wort »Radar« auch mit Begriffen »r«, »ra«, »rad« und »rada« gefunden werden kann.

Ein weiteres Problem der Suche wird erst nach genauerem Hinsehen offensichtlich. Ich teste erneut den Suchbegriff »radar«. Wir erinnern uns: Das Dropdown-Menü zeigte genau einen Treffer, nämlich das gleichnamige Desktop-Widget. In dem Dropdown-Menü befindet sich aber unterhalb des Treffers noch ein Link »View all search results«. Und siehe da. Ein Klick auf diesen Link fördert ganze 195 Treffer zu Tage.

Bei meinen ersten Versuchen wäre ich nicht darauf gekommen, dass es mehr Treffer geben könnte, als im Dropdown-Menü angezeigt werden. Erst nach sehr genauem Hinsehen stelle ich also fest, dass Apple offenbar zwischen »Shortcuts«, die im Dropdown-Menü angezeigt werden, und anderen Suchtreffern, die nur auf der Ergebnisseite zu finden sind, unterscheidet.

Das ist, mit Verlaub, grober Unfug. Viele Nutzer werden diese Unterscheidung nicht wahrnehmen und sich daher mit den wenigen (oder null) Treffern im Shortcuts-Dropdown begnügen, ohne jemals das »richtige« Suchergebniszu sehen.

Ich erlaube mir, aus diesem Dilemma Regeln für Autocomplete- bzw. Search-as-you-type-Suche abzuleiten.

  • Regel 1: Bei der Search-as-you-type-Funktion muss das unmittelbar angezeigte Suchergebnis die gesamte Ergebnismenge repräsentieren.

Nutzer könnten sonst glauben, ihr gewünschtes Objekt sei nicht vorhanden. Das muss nun nicht bedeuten, dass man tausende von Treffern in einem Dropdown-Menü anzeigen muss. Aber es sollte immerhin deutlich erkennbar sein, dass es noch weitere, nicht angezeigte Treffer gibt. Idealerweise sollte die Zahl der Treffer genannt werden.

  • Regel 2: Bei der Search-as-you-type-Funktion muss auch die Suche nach Teil-Zeichenketten funktionieren, zumindest in der Form »suchbegriff*«, also mit der gesuchten Teil-Zeichenkette am Beginn des Treffer-Begriffs.

Wenn das nicht der Fall ist, gibt man »reg« ein, findet womöglich keine Treffer, und schließt daraus, dass auch »regen« nicht gefunden werden kann.

  • Regel 3: Wenn eine Search-as-you-type-Funktion und eine klassische Suche kombiniert werden, müssen beide Suchfunktionen mit den selben Mechanismen arbeiten. Derselbe Suchbegriff in beiden Suchmasken eingegeben muss zum selben Suchergebnis führen.

Wenn also die eine Funktion die Suche nach Teil-Zeichenketten unterstützt, sollte die andere es auch. Wenn die eine mit phonetischer Suche arbeitet, muss die andere es auch tun. Ist das nicht der Fall, kann es leicht passieren, dass das Search-as-you-type-Suchergebnis und das Ergebnis der klassischen Suche sich unterscheiden.

Man kann vermuten, dass bei Apple die Regel Nr. 1 aus einfachen Gründen nicht beherzigt wird. Man hat sich erhofft, mit den »Shortcuts« ohne großen Suchaufwand ein nützliches Ergebnis präsentieren zu können. Wer die vollständige Suche bei Apple anstößt, durchsucht eine ganze Reihe von Datenquellen wie z.B. die Support-Datenbank, den Apple Store, den iTunes Store, Downloads und andere. Das kostet Apple schon ein paar CPU-Zyklen. Das aber ist eine Ressourcen-Argumentation, die mit User Experience nichts zu tun hat.

Regel Nr. 2 wird bei Apple eigentlich schon beherzigt. Bei der Suche nach »rada« wird das amerikanisch Radar Widget als Shortcut bereits angezeigt. Allerdings arbeitet die »vollständige« Suche nicht nach dem gleichen Prinzip, wodurch obige Regel Nr. 3 verletzt wird.

Die Suche bleibt ein spannendes Thema. Ich würde mich freuen, hier weitere Beispiele besprechen zu können. Wenn Ihr interessante Beispiele kennt, würde ich mich über Erwähnung in den Kommentaren freuen. Gleichermaßen willkommen ist natürlich Feedback zu diesen Überlegungen.

2 Kommentare

Tobias vor 7 Jahren

Hallo Marian, zum Teil stimme ich dir zu, zum Teil auch nicht.

Ich glaube, dass gerade im englischsprachigen Raum die Schnellsuche in den meisten Fällen treffende Ergebnisse findet.
Wahrscheinlich, weil es gerade da genug Daten zur Optimierung und genug Ressourcen zur Auswertung und Pflege der Schlagworte gibt.

Damit gilt aber für mich für »“Regel 1: Bei der Search-as-you-type-Funktion muss das unmittelbar angezeigte Suchergebnis die gesamte Ergebnismenge repräsentieren.”« nicht uneingeschränkt.
Warum sollte ich riesige Datenmengen oder Referenzen dahin anzeigen, wenn ich davon ausgehe, dass die gewünschten Ergebnisse schon gefunden werden…

Für mich gilt eher: Wenn die Schnellsuche (oder wie auch immer man sie nennt), weniger als X Ergebnisse anzeigt, sollte es eine zusätzliche Box geben, die genauso aussieht wie ein normales Ergebnis, aber den Hinweis auf die weiteren Treffer aus der Standardsuche enthält.
Warum? Für mich ist das zentrale Problem bei Apple, dass im Fall keiner Treffer, keine richtige Alternative angeboten wird. Der Link zur Normalsuche ist einfach zu wenig präsent und wird nicht erklärt…
Dabei gibt es, wenn kein Treffer gefunden wurde (Schnellsuche), nur noch eine mögliche Aktion neben dem AUfgeben, und das ist die Normalsuche… — genau die sollte also präsent geteasert werden. Gerne kann der auch erst nach kurzer Zeit erscheinen, die mit einem “AJAX-Wartekreis” überbrückt wird.

Regel 2:
Hier stimme ich dir völlig zu.

Regel 3:
Unter der Berücksichtigung der Anmerkungen oben, auch hier Zustimmung!

Marc (Webanhalter) vor 6 Jahren

Wenn es sich schon Apple nicht »leisten« kann (vielleicht auch ›nur‹ auf dem kleinen Markt Deutschland), welche Seiten können es dann?!
M.E. stehen solche netten Features erst am Anfang ihrer Entwicklung und solche Probleme sind nichts anderes als Kinderkrankheiten. Reichte da nicht als alleinige Regel: »Veröffentliche nur voll funktionsfähige Features!«