skip to content

Archiv

Die Suche nach der besseren Suche

Wie die Suchfunktion etwas verbessert werden könnte

Die WebsiteBaker eigene Suchfunktion fristet ein unentdecktes Dasein. Sie funktioniert zwar nicht schlechter, aber auch nicht besser als die von anderen CMS: gerade mal so.

Mit Windows 7 kommt die „Lust auf Suche“ auch auf den lokalen PC und setzt dort den Trend fort, der sich im Internet schon lange durchgesetzt hat: Die klassischen Strukturbäume (Menü, Auflistungen, Verzeichnisse) werden immer mehr von schnellen und vor allem: guten Suchfunktionen abgelöst. Sobald Strukturen zu groß werden oder Dinge nicht mehr eindeutig zugeordnet werden können, muss „künstliche Intelligenz“ Ordnung ins Chaos bringen – der Benutzer will sich nicht mehr durch Menübäume klicken, er will bedient werden – wie er es immer mehr gewohnt ist.

Suche im Internet wird mit Google gleichgesetzt. Und auch wenn jedem irgendwie klar ist, dass man das so nicht vergleichen kann: Von einer Suchfunktion erwartet man gute Ergebnisse. So ungefähr der Gedanke: Google sucht große Sachen (das Internet), eine Site-Search sucht kleine Sachen (die eigene Site). Aber bitte in gleicher Qualität.

Was aber ist Qualität von Suchergebnissen?

Googles Suchgebnisse können prinzipiell nie aktuell sein: Ein Spider (=ein automatischer Browser) kommt alle Zeiten vorbei, lädt die Seite in den Indexer und der beschließt, ob und wo die Seite bei welchem Begriff gelistet wird. Wie oft er kommt? Das hängt von mehreren Faktoren (Häufigkeit der Änderungen, Wichtigkeit usw) ab; Stunden, Tage, Wochen.

Die Websitebaker Suche tickt ganz anders: Bei der Suche wird tatsächlich die gesamte Datenbank durchsucht – genauso, wie sie in diesem Moment ist. Die Suchfunktion geht alle Module, alle Abschnitte einzeln durch und schaut, ob der Suchbegriff vorkommt.

Das ist ein ganz wesentlicher Unterschied!

Chaotische Lagerhaltung
gab es schon lange vor dem Internet: Man stellt eine Ware nicht dort ins Regal, wo sie "hingehört", sondern dorthin, wo Platz ist und notiert, wo was ist. Braucht man die Ware, benutzt man die Suche.
Ein Prinzip, ohne das Websites wie Wikipedia oder Facebook nicht funktionieren würden. Man stelle sich einmal das "Menü" von Wikipedia vor...

Man stelle sich einen Webmaster vor, der seine Site genau kennt und die Suche benutzt: Natürlich will er die Ergebnisse genauso sehen, wie er sie kennt. Und natürlich weiß er genau, auf welcher Seite welche Begriffe vorkommen und erwartet, dass diese alle gefunden werden (Wehe!).
Genau deshalb funktioniert die WB-Suche, WIE sie funktioniert: Um den Webmaster zu befriedigen. Was aber ist mit den Besuchern?

Der Haken bei der Suche

Seit WB2.7 ist die Suche zum Teil in die Module ausgelagert. Das ist an sich eine schlaue Sache: Nur ein Modul selbst kann wissen, wo was wie in der Datenbank steht.
Das bringt aber auch ein paar Probleme mit sich: Da jede Seite mehrere Abschnitte mit mehreren Modulen haben kann, führt das mitunter zu doppelten Ergebnissen. Und weil die Abschnitte einzeln durchgegangen werden, kann das Ergebnis auch nicht nach Relevanz geordnet sein.
 
Tatsächlich sind die Suchergebnisse von WebsiteBaker wenig sinnvoll: Kraut und Rüben durcheinander, tendenziell neuere Seiten weiter hinten. Ganz schlimm wird es, wenn nach 2 oder gar 3 Worten gesucht wird: Alles oder nichts.

Es gibt es auch in mySQL Suchfunktionen, die Ergebnisse nach Relevanz ordnen. Das geht aber prinzipiell nicht, wenn die Suchfunktion die Module einzeln abgrasen muss – sondern nur, wenn alle Seiten gesamtheitlich gesehen werden. Einfach gesagt: Wenn nicht direkt in der Datenbank gesucht wird, sondern in einem Abbild der Seiteninhalte. Nur: Wo soll das herkommen – in Echtzeit, um auch den ungeduldigen Webmaster zu befriedigen?

Ein möglicher Ansatz

WebsiteBaker ist wie Joomla ein klassisches CMS für „kleinere“ Sites: 20, 30, vielleicht 50 Seiten. Typische private oder Firmen-Präsenzen eben. Hier gibt es naturgemäß nicht viel zu suchen, und hier ist die derzeitige Suchfunktion – so sie überhaupt genutzt wird – mehr als ausreichend.
Eine bessere Suchfunktion macht erst bei mehr Seiten Sinn. Bei Sites, deren Webmaster sich näher mit WebsiteBaker befasst hat, und dabei kann man auch erwarten, dass er Änderungen zumindest im Template vornehmen kann. Hier kann man ansetzen.

Es macht jetzt keinen Sinn, die „ganzen Seiten“ – mitsamt Header, Footer und Menü abzugreifen. Das ist nicht das, was jemand sucht, das ist ohnehin offensichtlich. Tatsächlich geht es um pagecontent(). Hier muss der Webmaster wissen, was relevant ist: pagecontent(1) und/oder auch pagecontent(2). Diese Inhalte müssen – von Tags befreit, aber mit Title, Meta-Description und Keyword angereichert in eine Tabelle geschrieben werden. Damit kann man auch sinnvolle Suchstrategien verwenden.
Problem dabei: Wie kommen diese Inhalte in die Tabelle? Bei größeren Sites wird ein Script durch Laufzeitbeschränkungen nicht auf einmal durchkommen. Eine Möglichkeit wäre, die Tabelle laufend durch „Besucher“ füllen und erneuern zu lassen. Das hat aber wieder eine Haken: Der ungeduldige Webmaster würde zwangsläufig nicht immer aktuelle Suchergebnisse sehen. Und: Seiten die nie besucht werden, würden verspätet in den Suchergebnissen auftauchen. Das Modul „Members“ macht das übrigens genauso und ich kenne die Fragen im Forum zur Genüge: „Warum stehen „Members“-Abschnitte nicht in der Suche?“ (Tun sie, aber erst wenn die Seite einmal im Frontend aufgerufen wurde)

Konkret:

Ich denke daran, eine Funktion am Ende des Templates einzubauen, die bei jedem Aufruf einer Seite überprüft: Steht der Inhalt der aktuellen Seite noch nicht in der Suchtabelle? Ist er zu erneuern? Wenn ja: Abgreifen, in die Tabelle schreiben.

Die Felder:

page_id //obligatorisch

lastrefresh //time, wenn 0 oder über einer gewissen Zeit: in jedem Fall zu erneuern.

type //Von einem Modul erzeugt?: Bakery, News, Topics.. machen eigene Seiten.

id // item_id, post_id, topic_id..  Diese Seiten müssen direkt angesprungen werden können.
Weil das individuell vom Modul abhängt, ist das nicht ganz so einfach.

link //Auch ein heikles Thema

searchcontent // das, in dem gesucht wird. Möglichst reduziert.

picture //optional ein Bild neben jedem Suchergebnis.

....

 

Warum ich das noch nicht gemacht habe?

Ganz einfach: Weil ich zu blöd bin ;-) Tatsächlich hängen hier noch etliche Fallstricke dran; in jedem Fall muss der Webmaster Einstellungen vornehmen, die über das Übliche hinausgehen.
 

Back

Kommentare:

12.01.2010

Michael

Hallo!

Eine Alternative, die z.B. in Foren (phpBB) recht gut funktioniert ist folgendes:
Jedes Mal, wenn irgendwo etwas gespeichert wird läuft es durch einen Parser, der alle Worte die Sinn machen herauszieht und sie in eine eigene Datenbanktabelle schreibt. Sucht also der Benutzer jetzt nach "bäcker", sucht die Suche gar nicht mehr, sondern geht in die Datenbank (oder nennen wir es Suchcache), zieht sich die hinterlegten Ergebnisse zum Wort "Bäcker" (oder eben halt nicht, wenn niemand etwas geschrieben hat) und hat ohne großartiges Suchen sofort die richtigen Ergebnisse zur Hand.
So kann man auch gut an Hand von Modulen oder Plugin-Schnittstellen definieren, welche Module aufgenommen werden, in dem man einfach dem Parser mitteilt, er soll jetzt in diesem Fall / für diese Section / für dieses Modul generell Suchergebnisse so und so hinterlegen.
Man könnte sogar in solchen Fällen häufige Worte herausfiltern (gibt's ein Wort öfters als 0,5% -> wird es nicht angezeigt) u.ä.
Allerdings hat so eine professionelle Lösung auch ihren Preis: WebsiteBaker und viele der Module müssten neu programmiert werden, zumindestens teilweise. ;-)

17.01.2010

Chio

Naja - eine gute Suchfunktion sollte eben OHNE Eingriffe in WB-Core oder Module erfolgen.

Und ein Forum tickt ganz anders als WB. Ein Forum enthält viele - aber sehr einheitliche Datensätze. WB enthält vergleichsweise wenige - und sehr uneinheitliche Datensätze.
Ich halte deswegen generell den Zugriff direkt auf die Datenbank für problematisch.

Kommentar

Name:

E-Mail (required, not public):

Webseite:

Kommentar :

Up
K