{"id":1185,"date":"2012-12-28T18:54:31","date_gmt":"2012-12-28T17:54:31","guid":{"rendered":"http:\/\/blog.gambio.de\/?p=1185"},"modified":"2013-02-07T16:27:59","modified_gmt":"2013-02-07T15:27:59","slug":"projektbeschreibung-filterverlinkungen-ab-der-gambio-shopsoftware-version-2-1","status":"publish","type":"post","link":"https:\/\/www.gambio.de\/blog\/projektbeschreibung-filterverlinkungen-ab-der-gambio-shopsoftware-version-2-1\/","title":{"rendered":"Projektbeschreibung \u201cFilterverlinkungen ab der Gambio Shopsoftware Version 2.1\u201d"},"content":{"rendered":"

1. Grundlage<\/strong><\/p>\n

Ab der Gambio Shopsoftware Version 2.0 ist standardm\u00e4\u00dfig ein Produkt-Filter im Shopsystem implementiert. Das Filtersystem gibt dem Kunden die M\u00f6glichkeit, beliebige Filterwerte zur Einschr\u00e4nkung der Suchergebnisse zu w\u00e4hlen, um irrelevante Ergebnisse auszuschlie\u00dfen. Dabei werden alle Filterwerte, die einem Produkt zugewiesen sind, gepr\u00fcft und im Falle eines Treffers in den Suchergebnissen angezeigt. Dabei werden dem Benutzer alle m\u00f6glichen Kombinationen von Filterwerten zur Auswahl gegeben, was zur Folge hat, dass es auch zu Suchergebnissen ohne einen Treffer kommen kann.<\/p>\n

Filterwerte, die einem Produkt zugewiesen sind, werden alle miteinander verkn\u00fcpft. W\u00e4hlt man beispielsweise die Filterwerte \u201cVW\u201d, \u201cPolo\u201d, \u201cAudi\u201d und \u201cA1\u201d f\u00fcr einen Autoblinker, der bei diesen beiden Automodellen passt, so werden unter anderem auch die Werte \u201cAudi\u201d und \u201cPolo\u201d miteinander verkn\u00fcpft, obwohl sie keine sinnvolle Einheit bilden. Der Shopbetreiber hat keine M\u00f6glichkeit, die Verkn\u00fcpfungen seiner Filterwerte separat zu definieren.<\/p>\n

2. Projektziel<\/strong><\/p>\n

Durch ein neues Modul soll es m\u00f6glich sein, eine Verbindung zwischen einzelnen Filterwerten herzustellen, wonach im Shop gefiltert werden kann. Durch die weiteren Verkn\u00fcpfungen und dadurch entstehende Filterung soll dem Kunden bei jeder Auswahl ein g\u00fcltiges Ergebnis, mit mindestens einem Produkt, angezeigt werden.<\/p>\n

3. L\u00f6sungswege<\/strong><\/p>\n

3.1 Globale Paarverkn\u00fcpfungen zwischen Filterwerten<\/strong><\/p>\n

Der erste L\u00f6sungsansatz nutzt Verkn\u00fcpfungen zwischen den einzelnen Filterwerten. Dabei wird zu einem Filterwert ein weiterer zugeh\u00f6riger Filterwert gespeichert. Durch diese Technik entstehen direkte Verbindungen zwischen zwei Filterwerten, die direkt miteinander verkn\u00fcpft sind. Filterwerte, die sich gegenseitig ausschlie\u00dfen, werden bei diesem L\u00f6sungsansatz nicht miteinander verkn\u00fcpft. Der Vorteil dieser Technik liegt in der globalen Einstellung dieser Verkn\u00fcpfungen.<\/p>\n

3.2 Zuweisungen zwischen Filterwerten und Produkten in Gruppen (Sets)<\/strong><\/p>\n

Der zweite L\u00f6sungsansatz nutzt Gruppen, um die passenden Filterwerte nicht alle zusammen dem Produkt zuzuweisen. Diese Gruppen (so genannte Sets) befinden sich zwischen Produkt und Filterwerten und dienen als Schnittstelle. Dadurch werden zuk\u00fcnftig die Filterwerte nicht mehr dem Produkt direkt, sondern einer Gruppe zugewiesen. Diese Gruppen werden wiederum den Produkten zugewiesen. Durch die Aufteilung in Gruppen ist es nun m\u00f6glich, nicht zusammengeh\u00f6rende Filterwerte zu trennen, wodurch eine korrekte Anzeige im Shop m\u00f6glich ist.<\/p>\n

3.3 Entscheidungsfindung<\/strong><\/p>\n

Beide L\u00f6sungsans\u00e4tze haben Vor- und Nachteile. Beim ersten L\u00f6sungsansatz m\u00fcssen die Verkn\u00fcpfungen zwischen den Filterwerten nur einmal global im Shop eingerichtet werden. Beispielweise m\u00fcssen die Werte \u201cVW\u201d & \u201cGolf\u201d nur einmal miteinander verkn\u00fcpft werden, egal, wie viele Produkte diese Verkn\u00fcpfungen ben\u00f6tigen. Darin liegt wiederum ein Nachteil, denn eine globale Verkn\u00fcpfung zwischen zwei Filterwerten kann f\u00fcr einzelne Produkte nicht gel\u00f6scht werden. Somit besteht keine M\u00f6glichkeit, Ausnahmen von solchen Verkn\u00fcpfungen zu definieren.<\/p>\n

Die zweite Variante verkn\u00fcpft Filterwerte nicht global, sondern auf Produktebene. Aufgrund dessen ist die Verkn\u00fcpfung zwischen Werten sehr genau und f\u00fchrt dadurch nicht zu Fehlern. Nachteil wiederum ist, dass der Shopbetreiber zum Teil mehrere Filterwerte doppelt zuweisen muss, da manche Werte zu mehrere Sets geh\u00f6ren. Wie viel Mehrarbeit dadurch entsteht, ist abh\u00e4ngig von der Produktart und kommt darauf an, wie viele Filterwerte sich gegenseitig ausschlie\u00dfen. Je mehr Filterwerte sich ausschlie\u00dfen, desto mehr Filtersets m\u00fcssen f\u00fcr dasselbe Produkt erstellt werden.<\/p>\n

Letztendlich wurde der zweite L\u00f6sungsansatz gew\u00e4hlt, da bei dieser Technik ein sehr genaues Ergebnis geliefert wird (keine leeren Suchergebnisseiten im Shop), wodurch der Mehraufwand gerechtfertigt wird.<\/p>\n

4. Umsetzung<\/strong><\/p>\n

4.1 \u00c4nderung der Tabellenstruktur in der MySQL-Datenbank<\/strong><\/p>\n

In den bisherigen Versionen wurden die Produkte mit den Filterwerten direkt verkn\u00fcpft, wodurch lediglich eine Tabelle ben\u00f6tigt wurde. Aufgrund der Performance wurde eine weitere Tabelle erstellt, welche als Index-Tabelle dient. Durch die Einf\u00fchrung der Sets musste die Tabellenstruktur angepasst werden, damit alle n\u00f6tigen Informationen abgebildet werden k\u00f6nnen. Insgesamt wurden mehrere Tabellen hinzugef\u00fcgt, damit Sets und dazugeh\u00f6rige Set-Werte gespeichert werden k\u00f6nnen. Anhand der neuen Tabellen wird auch in Zukunft die Index-Tabelle gef\u00fcllt, damit das sp\u00e4tere Auswerten der Filterkriterien zu einem schnelleren Ergebnis f\u00fchrt.<\/p>\n

4.2 Erstellung einer Bearbeitungsmaske<\/strong><\/p>\n

In der Produktbearbeitung im Administrationsbereich ist ein neuer Bereich mit dem Namen \u201cFilterauswahl\u201d entstanden. Hier hat der Shopbetreiber die M\u00f6glichkeit, Filtersets f\u00fcr das Produkt anzulegen, zu bearbeiten und zu l\u00f6schen. In den meisten F\u00e4llen wird die Definition eines einzelnen Sets reichen, m\u00f6chte man jedoch eine Kombination aus Filterwerten von anderen zugewiesenen Filterwerten separieren, so muss diese in einem zus\u00e4tzlichen Set definiert werden.<\/p>\n

Zur Verwaltung der Sets wird die neu entwickelte Lightbox verwendet, die die angezeigten Daten per AJAX erh\u00e4lt. Dadurch werden \u00c4nderungen direkt \u00fcbernommen, ohne dass ein Neuladen der Seite n\u00f6tig ist. Ein weiteres Feature ist das Hinzuf\u00fcgen kategoriefremder Filter in der Eingabemaske der Filtersets. So kann der Shopbetreiber, wenn er bei der Definition eines Sets bemerkt, dass ein weiterer Filter f\u00fcr diesen Artikel relevant ist, diesen direkt dem Set hinzuf\u00fcgen, ohne den Filter vorher der Kategorie zuordnen zu m\u00fcssen. Dadurch muss er seine Arbeit nicht unterbrechen und kann den Filter nach dem Bearbeiten der Kategorie zuweisen. Das Verhalten der einzelnen Filterboxen unterscheidet sich, entgegen der optischen Darstellung, von gew\u00f6hnlichen Multiselectboxen, um dem Shopbetreiber eine intuitive Auswahl der einzelnen Filterwerte zu erm\u00f6glichen. Anders als bei einer Selectbox, ist es f\u00fcr die Mehrfachauswahl nicht n\u00f6tig, die \u201cStrg\u201d-Taste gedr\u00fcckt zu halten.<\/p>\n

F\u00fcr die Umsetzung wurden zwei Templates f\u00fcr die Anzeige der Sets und der einzelnen Filterboxen angelegt. Eine Controller-Klasse zur Steuerung des Programmflusses sowie eine Logikklasse, in der die Verarbeitung der Daten stattfindet, wurden w\u00e4hrend der Entwicklung ebenfalls implementiert. In vier separaten Javascript-Dateien wird das Verhalten der Bearbeitungsmaske, wie auch das Anzeigeverhalten der Filter, im Frontend gesteuert. F\u00fcr die Verarbeitung und anzuzeigenden Ergebnisse der AJAX-Requests wurden zwei AJAX-Handler (einer f\u00fcr den Administrationsbereich und einer f\u00fcr den Shop) sowie eine ContentView-Klasse entwickelt. Im Rahmen der Entwicklung wurden zudem einige strukturelle \u00c4nderungen vorgenommen, um den Anforderungen an die Performance zu entsprechen. Unter anderem wurde dabei eine ContentView-Klasse f\u00fcr die Lightbox entwickelt.<\/p>\n

4.3 Umsetzung der Anzeigelogik<\/strong><\/p>\n

Kernbereich des neuen Moduls ist die Filterung der Filterwerte anhand bereits ausgew\u00e4hlter Werte. Durch die implementierte Logik werden nicht mehr passende Filterwerte ausgeblendet. Die Anzeige einer leeren Suchergebnisseite ist so nicht mehr m\u00f6glich. Die Filterung der noch verf\u00fcgbaren Werte geschieht mittels AJAX. Nach jedem Klick wird durch einen Request die bereits get\u00e4tigte Auswahl an einen AJAX-Handler \u00fcbermittelt. Dieser leitet die \u00fcbermittelten Daten an eine Logik-Klasse weiter, welche die Pr\u00fcfung und Ermittlung der noch verf\u00fcgbaren Filterwerte \u00fcbernimmt. Als R\u00fcckgabewert wird eine Liste der noch verf\u00fcgbaren Filterwerte erwartet. Nachdem eine g\u00fcltige Liste zur\u00fcckgegeben wurde, wird \u00fcber alle Filterwerte iteriert und gepr\u00fcft, ob der jeweilige Filterwert weiterhin angezeigt werden darf. Dabei werden verschiedene Anzeige-Modi verwendet. Der Shopbetreiber kann ausw\u00e4hlen, ob alle Filter gleichzeitig oder stufenweise nach jeder Auswahl angezeigt werden sollen. Auch die Anzeige der auszublenden Filterwerte kann der Shopbetreiber ausw\u00e4hlen. Das Ausblenden sowie das Deaktivieren eines Filterwertes sind im Shop m\u00f6glich.
\nBei der Ermittlung der noch verf\u00fcgbaren Filterwerte gehen wir von Kombinationen aus. Dabei werden alle Sets als eine eigene Kombination angesehen, die wir mit der Kombination der bisher ausgew\u00e4hlten Filterwerte vergleichen. Aufgrund dieser Ausgangslage k\u00f6nnen wir die noch verf\u00fcgbaren Filterwerte ermitteln. Durch einen weiteren Klick eines Kunden wird die Auswahl der noch verf\u00fcgbaren Kombinationen eingeschr\u00e4nkt, bis nur noch ein Set verf\u00fcgbar ist, oder alle Filter vom Kunden ausgew\u00e4hlt wurden. In diesen F\u00e4llen findet des System aufgrund der ausgew\u00e4hlten Filterwerte mindestens ein Set, welches wiederum einem Produkt zugeordnet ist, das nun als Suchergebnis angezeigt wird. Sollten mehrere Sets verf\u00fcgbar sein, werden alle dazu passenden Produkte angezeigt.
\nUm zu gew\u00e4hrleisten, dass der Kunde ausschlie\u00dflich Suchergebnisse mit mindestens einem Treffer erh\u00e4lt, werden die verf\u00fcgbaren Filterwerte nach jeder Filterauswahl neu ermittelt. Dies geschieht mit Hilfe von AJAX, weshalb auch kein Neuladen der Seite n\u00f6tig ist.<\/p>\n

Die verf\u00fcgbaren Werte werden als Response an den Browser zur\u00fcckgegeben, wodurch das Javascript die nicht mehr verf\u00fcgbaren Werte aus- und die verf\u00fcgbaren Werte einblendet.<\/p>\n

5. Schwierigkeiten bei der Umsetzung<\/strong><\/p>\n

5.1 Verschiedene Verkn\u00fcpfungsarten einzelner Filter<\/strong><\/p>\n

Durch die M\u00f6glichkeit, den einzelnen Kategoriefiltern verschiedene Verkn\u00fcpfungsarten, also UND- oder ODER-Verkn\u00fcpfungen, zuzuweisen, ist es erforderlich, eine Filterlogik zu verwenden, die die Verwendung beider Arten gleichzeitig zul\u00e4sst. Es ist gelungen, eine solche zu entwickeln und sowohl dem Shopbetreiber, als auch dem Kunden eine komfortable Nutzung und Konfiguration zu bieten. F\u00fcr eine reibungslose und intuitive Nutzbarkeit ist dem Shopbetreiber empfohlen, innerhalb einer Kategorie nur dann verschiedene Verkn\u00fcpfungsarten f\u00fcr die einzelnen Filter zu vergeben, wenn dies ein in dem entsprechenden Kontext erwartetes Verhalten ist. Beispielsweise w\u00e4re es sinnvoll, die verschiedenen Filter, wie \u201cMarke\u201d, „Modell“ und „Farbe“ einer Kategorie \u201cAutos\u201d mit einer ODER-Verkn\u00fcpfung zu versehen. Bei einem weiteren Filter \u201cExtras\u201d w\u00e4re zu erwarten, dass dieser UND-verkn\u00fcpft ist. Wenn der Kunde n\u00e4mlich nach einem Auto mit Navigationsger\u00e4t und Klimaanlage sucht, in der Ergebnismenge jedoch auch Autos angezeigt werden, die nur einen dieser Komfortextras besitzt, ist dies kein relevantes Ergebnis und sollte auch nicht in der Ergebnismenge enthalten sein.<\/p>\n

5.2 Anzeige von Filterwerten, die durch eine \u00c4nderung erreichbar sind<\/strong><\/p>\n

Die Ermittlung der verf\u00fcgbaren Filterwerte erfolgt durch zwei SQL-Anfragen. Die erste sucht alle Filterwerte, die in Sets enthalten sind, die einen vollst\u00e4ndigen Treffer der gew\u00e4hlten Filter darstellt. Die zweite ist dazu da, dem Kunden mehr Spielraum in der Wahl seiner Filter zu bieten. Es sollen n\u00e4mlich zus\u00e4tzlich alle Filterwerte angezeigt werden, die mit einer weiteren Selektion erreichbar sind. So sucht die zweite SQL-Anfrage nach allen Filterwerten, die durch Ausschluss der gew\u00e4hlten Werte jeweils eines Filters, innerhalb der Filter, von denen mindestens ein Wert gew\u00e4hlt wurde, verf\u00fcgbar sind. Als Beispiel sei folgende Filterauswahl gegeben:<\/p>\n

– Automarke: VW<\/p>\n

– Modell: Golf<\/p>\n

– Farbe: Rot
\nDie zweite SQL-Anfrage w\u00fcrde in diesem Fall nach Werten in Sets suchen, die entweder VW und Golf oder VW und Rot oder Golf und Rot beinhalten. Die gefundenen Werte m\u00fcssen zudem Werte des jeweils ausgesparten Features sein. Das bedeutet f\u00fcr diesen Fall, dass Farben aus Sets, die VW und Golf enthalten, Modelle aus Sets, die VW und Rot enthalten sowie Automarken aus Sets, die Golf und Rot enthalten, gefunden werden. So wird sichergestellt, dass der Kunde die M\u00f6glichkeiten hat, seine Filterung kulanter zu gestalten, als bei einem komplett restriktiven Filtersystem.
\n5.3 Ermittlung von noch verf\u00fcgbaren Werten nach einer Deselektion (Klick-Historie)<\/strong><\/p>\n

Durch die Verwendung der ODER-Verkn\u00fcpfung ist es m\u00f6glich, dass Abh\u00e4ngigkeiten bei der Anzeige von verf\u00fcgbaren Werten entstehen, so dass einige Werte erst durch zus\u00e4tzliche Filterauswahlen zur Verf\u00fcgung stehen. Werden solche abh\u00e4ngigen Filterwerte vom Kunden ausgew\u00e4hlt und der Kunde entscheidet sich anschlie\u00dfend, einen vorherigen Filter wieder abzuw\u00e4hlen, kann es passieren, dass die ben\u00f6tigte Grundlage zum Anzeigen bereits selektierter Werte nicht mehr vorhanden ist. Das Problem ist, dass in Folge dessen Selektionen des Kunden verschwinden k\u00f6nnen, was bei einer langen Liste selektierter Filterwerte durchaus zu Unzufriedenheit bei dem Kunden f\u00fchren k\u00f6nnte. Deshalb wurde versucht, einen m\u00f6glichst gro\u00dfen Teil der Selektion zu erhalten, ohne dass die Performanz zu sehr darunter leidet. Au\u00dferdem stellte sich die Frage, welche Auswahlen des Kunden Priorit\u00e4t haben.
\nBei der Umsetzung wurde angenommen, dass der Nutzer die Werte, die f\u00fcr ihn am wichtigsten sind, zuerst ausw\u00e4hlt. Die Sortierreihenfolge, die der Shopbetreiber im Backend vorgibt, suggeriert dem Nutzer zwar eine Selektionsreihenfolge (eine logische oder subjektive Sortierung des Shopbetreibers), jedoch kann der Kunde aus dieser ausbrechen und damit seine eigene Priorit\u00e4t definieren. Wenn jemand dies tut, wurde dies als Zeichen betrachtet, dass die Reihenfolge der Selektion durch den Kunden die eigentliche Priorit\u00e4t vorgibt. W\u00e4hrend ein Shopbetreiber es z.B. als wichtiger findet, dass zuerst die Automarke gew\u00e4hlt wird, findet ein Kunde es vielleicht wichtiger, dass sein Auto rot sein soll. Um also dem Kunden eine m\u00f6glichst wunschgetreue Erhaltung der Selektion zu bieten, wird eine Klick-Historie verwendet, anhand der entschieden wird, was erhalten bleibt.
\nBei der Deselektion eines Wertes, von dem andere ausgew\u00e4hlte Werte abh\u00e4ngig sind, werden also Werte, die vor dem Deselektierten gew\u00e4hlt wurden, behalten. Auf dieser Grundlage wird eine SQL-Anfrage gesendet, die ermittelt, welche Werte, die nach dem Deselektierten gew\u00e4hlt wurden, noch immer Teil der Ergebnismenge sind. Diese Werte werden der Suchgrundlage hinzugef\u00fcgt und es wird erneut per SQL-Anfrage gepr\u00fcft, ob mit den zus\u00e4tzlichen Filterwerten weitere selektierte Werte der urspr\u00fcnglichen Auswahl gefunden werden. Dieser Vorgang wiederholt sich so lange, bis keine weiteren ausgew\u00e4hlten Werte gefunden werden.<\/p>\n

5.4 Mehrere Benutzeraktionen gleichzeitig<\/strong><\/p>\n

Durch die Verwendung von Select- und Multiselectboxen passiert es, dass der Benutzer mit einem Klick mehrere \u00c4nderungen durchf\u00fchrt. Das hat zur Folge, dass die Verwaltung der Klick-Historie und die Verarbeitung der gew\u00e4hlten Filterwerte auch f\u00fcr eine Liste von \u00c4nderungen geeignet sein muss, so dass auch die Regeln, die in Abschnitt 5.3 dieses Artikels beschrieben sind, nach wie vor greifen. Diese Problematik wurde umgangen, indem die gleiche Vorgehensweise wie bei einer Deselektion genutzt wird. Durch die Klick-Historie ist bekannt, welche Werte weiterhin angeklickt wurden. Diese Gruppe von Werten dient als Grundlage f\u00fcr die noch verf\u00fcgbaren Werte. Die neu angeklickten Werte werden danach der Gruppe hinzugef\u00fcgt und die noch verf\u00fcgbaren Werte aufgrund der neuen Gruppe herausgefiltert.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

1. Grundlage Ab der Gambio Shopsoftware Version 2.0 ist standardm\u00e4\u00dfig ein Produkt-Filter im Shopsystem implementiert. Das Filtersystem gibt dem Kunden die M\u00f6glichkeit, beliebige Filterwerte zur Einschr\u00e4nkung der Suchergebnisse zu w\u00e4hlen, um irrelevante Ergebnisse auszuschlie\u00dfen. Dabei werden alle Filterwerte, die einem Produkt zugewiesen sind, gepr\u00fcft und im Falle eines Treffers in den Suchergebnissen angezeigt. Dabei werden […]<\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,3],"tags":[],"class_list":["post-1185","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-entwicklung"],"_links":{"self":[{"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/posts\/1185","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/comments?post=1185"}],"version-history":[{"count":18,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/posts\/1185\/revisions"}],"predecessor-version":[{"id":1210,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/posts\/1185\/revisions\/1210"}],"wp:attachment":[{"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/media?parent=1185"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/categories?post=1185"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gambio.de\/blog\/wp-json\/wp\/v2\/tags?post=1185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}