[PW] Extra filter -> meer matches?

[Olaf van der Spek]

A: 16+ GB 1.6+ GHz DDR3
B: 16+ GB 1.6+ GHz DDR3 8+ MB modules

B zou een subset van A moeten opleveren, toch? Maar B levert juist meer producten op.
pricewatch: IBM 46W0716 is het eerste product bij B wat bij A volgens mij gewoon mist.

Zie ik iets heel simpels over het hoofd of klopt dit niet?

A: categorie: Geheugen intern

B: categorie: Geheugen intern

[ Voor 17% gewijzigd door Olaf van der Spek op 05-07-2018 21:15 ]

[foaly]

Het probleem lijkt in the geheugensnelheid slider te zitten, als ik die naar 1,33 en terug naar 1,6 slide krijg ik dit: intern geheugen optie A
In je huidige selectie bij A zijn alle modules van 1,6 GHz uitgesloten en laat hij alleen maar modules met hogere snelheden zien.

[Cerberus_tm]

Vreemd! Als ik bij Olafs koppeling A 1x op de slider voor de geheugensnelheid druk (dus zonder te slepen), krijg ik de correcte weergave: dan worden oom modules van 1,6 GHz getoond, wat niet het geval was bij zijn koppeling. Er lijkt dus iets mis te zijn met die specifieke url? Hoe is die tot stand gekomen?

[crisp]

Filter A bevat een range van 1.8 t/m 4.266 GHz, maar omdat de slider geen positie (meer) heeft voor 1.8 wordt de dichtsbijzijnde waarde geselecteerd (1.6GHz) - dit komt echter niet terug in de resultaten.

Dit is wel een beetje een edge-case. Het zou beter zijn als we er voor zouden zorgen dat een (eerder) geselecteerde waarde ook precies in de slider geselecteerd kan worden, maar dat is technisch best lastig te fixen...

[Olaf van der Spek]

@crisp Toch staat ook bovenaan de pagina "vanaf 1,6GHz t/m 4,266GHz".

Cerberus_tm schreef op woensdag 18 juli 2018 @ 03:19:
Vreemd! Als ik bij Olafs koppeling A 1x op de slider voor de geheugensnelheid druk (dus zonder te slepen), krijg ik de correcte weergave: dan worden oom modules van 1,6 GHz getoond, wat niet het geval was bij zijn koppeling. Er lijkt dus iets mis te zijn met die specifieke url? Hoe is die tot stand gekomen?

Bookmark

[ Voor 77% gewijzigd door Olaf van der Spek op 18-07-2018 09:50 ]

[Cerberus_tm]

crisp schreef op woensdag 18 juli 2018 @ 09:06:
[...] omdat de slider geen positie (meer) heeft voor 1.8 [...]

Dit begrijp ik niet helemaal, kun je het misschien toelichten? Waarom zou een slider geen positie hebben voor een waarde? En hoe is die waarde dan geselecteerd geraakt? En hoe kunnen we zoiets voor de toekomst voorkomen?

[crisp]

Olaf van der Spek schreef op woensdag 18 juli 2018 @ 09:46:
@crisp Toch staat ook bovenaan de pagina "vanaf 1,6GHz t/m 4,266GHz".


[...]

Ja, want dat is ook wat er met de slider geselecteerd is De getoonde resultaten waren echter al eerder opgehaald op basis van 1.8GHz als vanaf waarde.

Het is een lastig uit te leggen technische oorzaak (en dus ook een lastig op te lossen bug)..

[crisp]

Cerberus_tm schreef op woensdag 18 juli 2018 @ 09:52:
[...]

Dit begrijp ik niet helemaal, kun je het misschien toelichten? Waarom zou een slider geen positie hebben voor een waarde? En hoe is die waarde dan geselecteerd geraakt? En hoe kunnen we zoiets voor de toekomst voorkomen?

Met een slider kan je nu eenmaal niet een oneindige reeks waardes selecteren. Welke waardes je wel kan selecteren wordt automagisch bepaald aan de hand van de specificaties van de beschikbare producten. Dat is dus veranderlijk in de tijd.

Zo kan het zijn dat je gisteren nog 1.8GHz als vanaf-punt kon selecteren, maar vandaag alleen 1.6GHz of 2.0GHz. Als je dan een URL met een eerder ingesteld filter (gebookmarkt) gebruikt dan kan je dus een mismatch krijgen. De resultaten kunnen prima de vanaf-waarde van 1.8GHz verwerken, alleen kan die waarde in de slider niet meer geselecteerd worden. Dan wordt uiteindelijk de dichtstbijzijnde waarde geslecteerd, maar dat gebeurd pas achteraf aan de clientkant bij het initialiseren van de slider (via javascript).

[Cerberus_tm]

crisp schreef op woensdag 18 juli 2018 @ 10:02:
[...]

Met een slider kan je nu eenmaal niet een oneindige reeks waardes selecteren. Welke waardes je wel kan selecteren wordt automagisch bepaald aan de hand van de specificaties van de beschikbare producten. Dat is dus veranderlijk in de tijd.

Zo kan het zijn dat je gisteren nog 1.8GHz als vanaf-punt kon selecteren, maar vandaag alleen 1.6GHz of 2.0GHz. Als je dan een URL met een eerder ingesteld filter (gebookmarkt) gebruikt dan kan je dus een mismatch krijgen. De resultaten kunnen prima de vanaf-waarde van 1.8GHz verwerken, alleen kan die waarde in de slider niet meer geselecteerd worden. Dan wordt uiteindelijk de dichtstbijzijnde waarde geslecteerd, maar dat gebeurd pas achteraf aan de clientkant bij het initialiseren van de slider (via javascript).

Aa, nu begrijp ik het, het ging om een bookmark van een zoekopdracht. Dus als ik het begrijp had hij in zijn oude zoekopdracht waarschijnlijk 1,8 ingesteld, en zorgt de pagina er bij het lade voor dat de dichtstbijzijne waarde door de slider en het label wordt aangegeven.

Aangezien een waarde 1,866 inclusief is, dwz. ook resultaten met precies 1,866 toont, zou het dan niet beter zijn om in zo'n geval 1,866 te kiezen in plaats van 1,6? Dus een waarde die het zoekbereik kleiner maakt in plaats van groter. Dat is natuurlijk alleen een goed idee mits dit voor alle mogelijke criteria zo werkt: je wil natuurlijk niet een zoekopdracht verengen, waarbij er resultaten uitgesloten worden die oorspronkelijk wel binnen het bereik vielen.

Zou het sowieso geen goed idee zijn om een waarschuwing te geven wanneer zoiets als dit gebeurt, een rode tekst ergens op de pagina o.i.d.?

[ACM]

Helaas niet simpel te fixen