[Webshop] Beste werkwijze productfilters in een webshop

[TheNephilim]

Het lijkt een beetje op de filters zoals als Tweakers ze in de Pricewatch heeft, alleen dan in een webshop. Heb het al eens vaker gebruikt, maar wil qua logica even het onderste uit de kan hebben. Een nieuw project, dus nieuwe kansen!

Een Filter bestaat uit meerdere Opties. Een voorbeeld van een filter zou 'Maat' met de opties 'S', 'M', 'L', 'XL' kunnen zijn. Stel je wil alle producten zien, dan klik je niks aan. Als je alleen de producten met de maat S wil zien, dan klik je S aan. Wil je alle producten met S óf M zien, dan klik je die aan. Vrij duidelijk lijkt me!

Nu heb ik een formulier waarin de filters opgenomen zijn door middel van checkboxes. Dit formulier is voorzien van een stukje jQuery die bij 'change' van de checkboxes de browser hash (#filter:...) aanpast. De browser hash word ook bewaakt door een stukje code die op zijn beurt weer de producten ophaalt op basis van de browser hash. De browser hash bevat het filter-formulier, geserialiseerd. De hash word met (urlsafe) base64 'versleuteld' om zo te voorkomen dat karakters problemen veroorzaken.

Uiteraard is het de bedoeling dat als er iemand een link met filter opent (vanuit email of Facebook) hij gewoon de producten krijgt te zien die erbij horen en dat het filter-formulier 'restored' word naar de state van de browser hash die in de link zit.

Stap 1: Checkbox in het formulier word aangeklikt, 'change' detected!

Stap 2: Browser hash updaten met een geserialiseerde versie van het filter-formulier.

Stap 3: Browser hash is veranderd, 'change' detected!

Stap 4: Producten ophalen op basis van de hash (AJAX).

Waarom niet meteen, bij het aanklikken van de checkbox, de producten ophalen? Dan verlies je vorige/volgende functionaliteit in de browser en is er geen mogelijkheid om de filters te delen met een ander.

En nu?

Denk ik hier logisch? Klopt mijn werkwijze tot zover, of kan ik het nog verder versimpelen?

[Nedra]

Wat voor attributen geef je aan je producten mee zodat deze kunnen worden gefilterd op basis van hashtags?

Je zou er over na kunnen denken om de history api te gebruiken om geen hashtags, maar gewoon volwaardige urls te hebben.

nb volgensmij is je werkwijze verder compleet logisch. Ik opper de history api als een eventuele mogelijkheid

[ Voor 20% gewijzigd door Nedra op 27-09-2013 10:49 ]

[TheNephilim]

Nedra schreef op vrijdag 27 september 2013 @ 10:48:
Wat voor attributen geef je aan je producten mee zodat deze kunnen worden gefilterd op basis van hashtags?

Je zou er over na kunnen denken om de history api te gebruiken om geen hashtags, maar gewoon volwaardige urls te hebben.

nb volgensmij is je werkwijze verder compleet logisch. Ik opper de history api als een eventuele mogelijkheid

De browser hash zou er zo uit kunnen zien: #filter:ZjNbXT03JmYxMFtdPTEyJmYxN1tdPTIw, dat staat weer voor f3[]=7&f10[]=12&f17[]=20. De key is hier het filter en de value de optie.

Ik heb er inderdaad al eens over nagedacht om die history API te gebruiken. Echter, de filters zoals hierboven, moet ik dan middels een slug (naam) gaan aanspreken. Dan zou het (bijv.) /assortiment/maat/s worden. Dat heb ik maar niet gedaan omdat de klanten dan op moeten letten wat ze moeten doen met de filters. Die zijn immers aanpasbaar en kunnen conflicteren als er een zelfde slug door twee opties gebruikt word. Dat zal niet snel gebeuren gezien filter en optie beide in de URL staan, maar toch.

Dan hebben we ook nog browser compatibiliteit Maar... de history API gebruiken staat wel mooier dan de # met een base64 encoded string, dat is waar

[RobIII]

Volgens mij begrijp je niet helemaal wat met "history API" bedoeld wordt

Voor cross-browser legacy support kun je eens kijken naar, bijv, iets als history.js. En neem even de eerste paar hits hiervan door voor meer in-depth info.

[ Voor 96% gewijzigd door RobIII op 27-09-2013 18:36 ]

[Ramon]

TheNephilim schreef op vrijdag 27 september 2013 @ 17:44:
[...]
Ik heb er inderdaad al eens over nagedacht om die history API te gebruiken. Echter, de filters zoals hierboven, moet ik dan middels een slug (naam) gaan aanspreken. Dan zou het (bijv.) /assortiment/maat/s worden. Dat heb ik maar niet gedaan omdat de klanten dan op moeten letten wat ze moeten doen met de filters. Die zijn immers aanpasbaar en kunnen conflicteren als er een zelfde slug door twee opties gebruikt word. Dat zal niet snel gebeuren gezien filter en optie beide in de URL staan, maar toch.

Afgezien van dat /assortiment/maat/s (dat zou je ook /assortiment/maat:s/ kunnen doen natuurlijk, dan heb je je probleem opgelost) natuurlijk veel mooier is dicteert de history API niets over het uiterlijk van je urls.

Dan hebben we ook nog browser compatibiliteit Maar... de history API gebruiken staat wel mooier dan de # met een base64 encoded string, dat is waar

Volgens mij wat hierboven al genoemd wordt is history.JS compatible met oudere browsers.

Daarnaast, ik ben veel meer geneigd om op een mooie url te klikken of om die te delen dan eentje waar random (voor mij) letters en cijfers in staan dus als je je ook bezig houdt met conversie zou ik er nog eens dubbel over nadenken wat de beste url-structuur is

[TheNephilim]

RobIII schreef op vrijdag 27 september 2013 @ 18:31:
Volgens mij begrijp je niet helemaal wat met "history API" bedoeld wordt

Voor cross-browser legacy support kun je eens kijken naar, bijv, iets als history.js. En neem even de eerste paar hits hiervan door voor meer in-depth info.

Het is inderdaad meer dan alleen een mooie URL, dat was me wel bekend, heb er alleen nooit echt wat mee gedaan. Geen projecten hier waar ik zoiets nodig had. De oplossing met # die ik nu heb, word ook opgeslagen in de next/back shizzle. Dus uiteindelijk heb ik alleen wat aan History.js als ik mooie URL's wil. Maar dat er al een mooie History.js was die alle compatibiliteit regelt, wist ik dan weer niet xd Thanks! ^^

Trouwens, dat IE pas vanaf versie 10 de standaard HTML5 History API ondersteund. Ik dacht dat het vanaf versie 9 al wel zover moest zijn.

---

Ramon schreef op vrijdag 27 september 2013 @ 18:41:
[...]
Afgezien van dat /assortiment/maat/s (dat zou je ook /assortiment/maat:s/ kunnen doen natuurlijk, dan heb je je probleem opgelost) natuurlijk veel mooier is dicteert de history API niets over het uiterlijk van je urls.
[...]
Volgens mij wat hierboven al genoemd wordt is history.JS compatible met oudere browsers.

Daarnaast, ik ben veel meer geneigd om op een mooie url te klikken of om die te delen dan eentje waar random (voor mij) letters en cijfers in staan dus als je je ook bezig houdt met conversie zou ik er nog eens dubbel over nadenken wat de beste url-structuur is

Oké ik zou er dus mooie URL's van kunnen maken, moet alleen even kijken of het URL's worden die ik ook qua link structuur kan parsen. Als een klant een bepaalde link dan opent in de browser, gaat hij dat niet meer met Ajax doen, maar moet ik dat serverside afhandelen. Met de # word hij altijd clientside afgehandeld en hoef ik niks 'extra' te doen.

Mwah, je ziet de links alleen in de browser adresbalk veranderen. Als iemand ze deelt inderdaad, dan is het niet echt een mooi gezicht. Maarja, het budget voor deze website is niet zo heel groot, wellicht deze verbetering dan uitstellen tot een nieuw project, op dezelfde basis.

[Kecin]

Misschien stomme opmerking maar heb je al eens naar Apache SOLR gekeken? Daarmee kan je mooie facetten bouwen die ook nog gecached kunnen worden enzo. Dependencies kunnen kan ook aangemaakt worden etc. Wellicht eens het kijken waard. Je kan dan ook zo'n coole autocomplete search box gebruiken enzo. Zie ook: http://lucene.apache.org/solr/

[TheNephilim]

Kecin schreef op maandag 30 september 2013 @ 14:11:
Misschien stomme opmerking maar heb je al eens naar Apache SOLR gekeken? Daarmee kan je mooie facetten bouwen die ook nog gecached kunnen worden enzo. Dependencies kunnen kan ook aangemaakt worden etc. Wellicht eens het kijken waard. Je kan dan ook zo'n coole autocomplete search box gebruiken enzo. Zie ook: http://lucene.apache.org/solr/

Dit type filters is in gebruik op een website met een kleine 3000 producten en ongeveer 120 verschillende filter opties. Niet heel extreem groot, maar wel gewoon draaiend op hosting van Mijndomein.nl. Kan sneller, maar het werkt zo eigenlijk prima. Linkje plaatsen is niet toegestaan volgens mij (?), maar de website doet het prima qua snelheid.

De webshop waar ik nu aan werk, word gelanceerd met (in eerste instantie) slechts 7 producten Hele ingewikkelde systemen die eigen (virtuele) servers vereisen zijn dus niet aan de orde. Het systeem moet echter uit te breiden zijn, dus moeten er wel filters en facetten in. Wel leuk om te zien dat er oplossingen als deze zijn trouwens, dus toch bedankt!

De facetten heb ik trouwens nog veel werk mee gehad, moest ik van scratch opbouwen Wel gelukt uiteindelijk, blij dat ik steeds een beetje betere oplossingen kan maken.

[Kecin]

TheNephilim schreef op maandag 30 september 2013 @ 14:24:
[...]


Dit type filters is in gebruik op een website met een kleine 3000 producten en ongeveer 120 verschillende filter opties. Niet heel extreem groot, maar wel gewoon draaiend op hosting van Mijndomein.nl. Kan sneller, maar het werkt zo eigenlijk prima. Linkje plaatsen is niet toegestaan volgens mij (?), maar de website doet het prima qua snelheid.

De webshop waar ik nu aan werk, word gelanceerd met (in eerste instantie) slechts 7 producten Hele ingewikkelde systemen die eigen (virtuele) servers vereisen zijn dus niet aan de orde. Het systeem moet echter uit te breiden zijn, dus moeten er wel filters en facetten in. Wel leuk om te zien dat er oplossingen als deze zijn trouwens, dus toch bedankt!

De facetten heb ik trouwens nog veel werk mee gehad, moest ik van scratch opbouwen Wel gelukt uiteindelijk, blij dat ik steeds een beetje betere oplossingen kan maken.

Leuk om te horen! Ik moet zeggen dat wij (als in op mijn werk) het steeds meer gebruiken voor reguliere content en geen webshops. Bijvoorbeeld een website van een landelijke bond met informatie over bepaalde zaken. Dan kan je "Pensioen" aantikken en krijg je relevante content met dat type enzo.

Moet wel zeggen dat ik de facetten luier opbouw door de plugins die beschikbaar zijn voor het CMS (in dit geval Drupal). Enige nadeel is dat Java zo'n geheugenvreter is om SOLR (binnen Tomcat) te laten draaien. Maargoed, wanneer je die redelijk afstelt is het nog wel te doen . Succes!

[TheNephilim]

Kecin schreef op maandag 30 september 2013 @ 14:29:
[...]

Leuk om te horen! Ik moet zeggen dat wij (als in op mijn werk) het steeds meer gebruiken voor reguliere content en geen webshops. Bijvoorbeeld een website van een landelijke bond met informatie over bepaalde zaken. Dan kan je "Pensioen" aantikken en krijg je relevante content met dat type enzo.

Moet wel zeggen dat ik de facetten luier opbouw door de plugins die beschikbaar zijn voor het CMS (in dit geval Drupal). Enige nadeel is dat Java zo'n geheugenvreter is om SOLR (binnen Tomcat) te laten draaien. Maargoed, wanneer je die redelijk afstelt is het nog wel te doen . Succes!

Haha, ja verwacht geen first class enterprise solutions, maar het werkt en is simpel en efficiënt!

Wij krijgen volgens mij binnenkort ook een klant die een heleboel informatie op z'n website heeft staan. Deze gaan we ook beter doorzoekbaar maken met filters zoals in dit topic beschreven.

Ah, nou het berekenen van de facet counts heb ik uiteindelijk toch zelf geschreven. Kon gebruik maken van enkele functies in Wordpress, maar die waren niet zo snel vergeleken met de 'direct approuch'. Java eet inderdaad veel geheugen, zo ook een comet server die we hier hebben draaien. Ging in de eerste versies ook vaak op z'n gezicht door het geheugen gebruik.

Nee voorlopig zitten we hier met deze simpele Wordpress oplossing wel goed. Uiteraard altijd opzoek naar verbeteringen. Hieronder een screenshot van de filters op de eerder genoemde webshop.

[Nedra]

Netjes, is dit voor Woocommerce? Misschien ook leuks als plugin. En heb je 't nou gedaan met de History api?

[TheNephilim]

Nedra schreef op maandag 30 september 2013 @ 15:29:
Netjes, is dit voor Woocommerce? Misschien ook leuks als plugin. En heb je 't nou gedaan met de History api?

Nope, een eigen gebouwd Wordpress thema met webshop functionaliteit. We hebben hier verschillende plugins bekeken en hoewel vooral Shopp en WooCommerce het prima doen, zit je vast enorme hoeveelheden opties die je niet gebruikt, extra plugins voor iDeal benodigd en bepaalde weergaves die wij liever op het product afstemmen.

Kortom; to much!

De History API ben ik aan het overwegen, mijn punten:

• Ik heb nu ook vorige/volgende functionaliteit
• Mooie URL's moeten ook door backend ondersteund worden. Iets wat misschien teveel tijd kost op dit moment.

Iets wat ik wellicht in een volgende iteratie eens ga proberen. Deze webshop moet eigenlijk deze week al opgeleverd worden en er is nog het een en ander te doen.

[Nedra]

Dat is erg interessant! Ik ben stiekem wel benieuwd naar hoe jullie dat in elkaar hebben gezet. Ik werk zelf redelijk vaak met Woocommerce, maar nooit met heel veel liefde, haha.

[TheNephilim]

Nedra schreef op maandag 30 september 2013 @ 15:51:
Dat is erg interessant! Ik ben stiekem wel benieuwd naar hoe jullie dat in elkaar hebben gezet. Ik werk zelf redelijk vaak met Woocommerce, maar nooit met heel veel liefde, haha.

Bedoel je op technisch, of gewoon praktisch gebied?

[Nedra]

Technisch vooral. Hebben jullie het met een slimme combinatie van plugins, custom post types en taxonomies gedaan? (ik zou zelf denken aan acf met gravity forms o.i.d.) of echt helemaal de grond af aan opgebouwd? En hoe hebben julle bijv. voorraad en bestellingsbeheer gedaan? Niet dat je al je geheimen hoeft prijs te geven, maar ik ben wel nieuwschierig naar de aanpak.

[TheNephilim]

Het bestaat uit enkele custom post types, taxonomies en onderstaande plugins.

• Advanced Custom Fields
• Google Analytics for WordPress
• W3 Total Cache
• WordPress SEO

Daarnaast natuurlijk veel zelfgeschreven code en integratie met betaaldiensten zoals Mollie/TargetPay/Buckeroo/etc. Voorraadbeheer zit in geen van de websites, dat past niet bij de kleinschaligheid, het zijn geen grootgrutters. Één van de websites bevat ook een productvariatie en productversie systeem. Waar je bij één product, meerdere versies hebt zoals; Maat: S, Kleur: Groen en Maat: S, Kleur: Rood.

Ik moet wel zeggen, onze eerste webshop was al best geslaagd, maar (vooral door tijdsgebrek) niet perfect. De 2e versie, waar de screenshot van is, was eigenlijk al perfect, maar had technisch nog wel wat verbeterpunten. Dat is met de 3e iteratie, waar ik nu mee bezig ben, hopelijk nog weer beter.

Klanten krijgen een aangepast producten en order overzicht, wel gebouwd met Wordpress functies zodat de website gewoon ge-update kan worden. Betalingen gaan, zoals in de eerste alinea vermeld, via een betaalprovider. Makkelijke integratie en je hebt zelf geen geen omkijken naar de werkelijke verwerking van betalingen. Voor die 75 cent per transactie is dat mooi geregeld, al werkt dat niet bij elk assortiment misschien.