[PW] Incorrecte en inconsistente getallen bij filter-opties

[Jerrythafast]

Beste Pricewatchers,

Ik ben op een wat suf bugje gestuit in de filters in de Pricewatch. En daarna vond ik er nog een paar.

Ziehier:


Drie laptops, twee met een Azerty-toetsenbord en één waarbij het niet ingevuld is. Het schuifje van de toetsenbordindeling-filter staat op 'Geen'. Ik krijg de indruk dat de getallen achter de opties bij dit filter nu aangeven hoeveel laptops ik over zou houden als ik een bepaalde optie erbij selecteer. Dus de 1 achter 'Azerty' betekent dat als ik 'Azerty' aankruis er één laptop over blijft (verrassing: dat is die ene waarbij het niet was ingevuld).

Maar... waarom staat er dan 0 bij 'Qwertz' en 'Qwerty (Scandinavisch)'? Daar zou dan toch een 3 moeten staan, omdat alle drie de laptops geen 'Qwertz' en geen 'Qwerty (Scandinavisch)' toetsenbord hebben?


Tot zover het suffe bugje... want terwijl ik hiermee zat te spelen liep ik tegen nog meer dingen aan.

De betekenis van die getallen is namelijk ook niet consistent tussen de verschillende soorten filters. De getallen bij de merken in het merkenfilter geven namelijk gewoon aan hoeveel laptops van het betreffende merk er in de lijst staan, ongeacht of het schuifje op 'Wel' of 'Geen' staat. (Ik vind dit trouwens véél prettiger werken, omdat ik zo kan zien hoeveel laptops ik weg gooi als ik een bepaald merk uitsluit. Zou mooi zijn als je ergens kunt instellen welk getal je wilt zien.)

Bovendien veranderen bij het toetsenbordindeling-filter de getallen pas naar het "aantal laptops over"-systeem nadat je een optie hebt geselecteerd. Als je zonder opties te selecteren het schuifje tussen 'Wel' en 'Geen' wisselt verandert er niets. Als je het schuifje dus éérst op 'Geen' zet en dan pas een optie selecteert zie je de getallen bij de andere opties opeens radicaal veranderen omdat hij dan omschakelt naar het "aantal laptops over"-systeem.


Ik filter trouwens 99% van de tijd met het schuifje op 'Geen' dus ik zet graag de verdubbelaar in voor de prioriteit van deze bugreport

Vriendelijke groet,
Jerry

[ACM]

Jerrythafast schreef op dinsdag 27 oktober 2015 @ 22:44:
Drie laptops, twee met een Azerty-toetsenbord en één waarbij het niet ingevuld is. Het schuifje van de toetsenbordindeling-filter staat op 'Geen'. Ik krijg de indruk dat de getallen achter de opties bij dit filter nu aangeven hoeveel laptops ik over zou houden als ik een bepaalde optie erbij selecteer. Dus de 1 achter 'Azerty' betekent dat als ik 'Azerty' aankruis er één laptop over blijft (verrassing: dat is die ene waarbij het niet was ingevuld).

Klopt, dat is het doel

Maar... waarom staat er dan 0 bij 'Qwertz' en 'Qwerty (Scandinavisch)'? Daar zou dan toch een 3 moeten staan, omdat alle drie de laptops geen 'Qwertz' en geen 'Qwerty (Scandinavisch)' toetsenbord hebben?

Dat is helaas een gevolg van een paar keuzes die hier de combinatie ingewikkeld maken. Er zijn bij de module die bepaald welke mogelijke specificaties er zijn uberhaupt geen laptops meer met die toetsenborden... Dus uit de statistieken komt die optie niet meer naar voren. De module die e.e.a. weergeeft heeft nog wel die opties in de lijst staan en vult standaard 0 in als er geen statistieken van bekend zijn; we zouden het op kunnen lossen door die module slimmer te maken en bij een aangevinkte 'geen'-optie juist het overgebleven totaal in te vullen ipv 0.

De betekenis van die getallen is namelijk ook niet consistent tussen de verschillende soorten filters. De getallen bij de merken in het merkenfilter geven namelijk gewoon aan hoeveel laptops van het betreffende merk er in de lijst staan, ongeacht of het schuifje op 'Wel' of 'Geen' staat.

Dat is dan blijkbaar een bug bij de merken-variant.

(Ik vind dit trouwens véél prettiger werken, omdat ik zo kan zien hoeveel laptops ik weg gooi als ik een bepaald merk uitsluit. Zou mooi zijn als je ergens kunt instellen welk getal je wilt zien.)

Het probleem is dat het dan helemaal inconsistent wordt als per knop-combinatie de betekenis van de cijfertjes verandert. Bovendien moeten we dan ook de code die dat bepaald op twee manieren laten werken; nu doet ie intern gewoon de filtering steeds opnieuw en komt daar dus domweg het aantal dat over zou blijven na dat je het vinkje aanzet.

Bovendien veranderen bij het toetsenbordindeling-filter de getallen pas naar het "aantal laptops over"-systeem nadat je een optie hebt geselecteerd. Als je zonder opties te selecteren het schuifje tussen 'Wel' en 'Geen' wisselt verandert er niets. Als je het schuifje dus éérst op 'Geen' zet en dan pas een optie selecteert zie je de getallen bij de andere opties opeens radicaal veranderen omdat hij dan omschakelt naar het "aantal laptops over"-systeem.

Het weergavedeel communiceert pas met de module die de filtering (en statistieken) bepaald zodra je minimaal 1 optie aanvinkt... Sterker nog, de statistieken worden sowieso pas anders zodra er minimaal 1 optie is aangevinkt.

Ik filter trouwens 99% van de tijd met het schuifje op 'Geen' dus ik zet graag de verdubbelaar in voor de prioriteit van deze bugreport

Ik gok dat in werkelijkheid ongeveer 99% van de bezoekers met 'Wel' filtert, dus je bent - zonder dat ik statistieken heb verzameld om dat te staven - waarschijnlijk een beetje in de minderheid

Helaas zijn de issues die je noemt best pittig om op te lossen, we willen niet dat er telkens bij het wisselen van 'we' naar 'geen' er allerlei queries op onze database moeten worden uitgevoerd; tenzij het filter daadwerkelijk actief is en dus ook de bijbehorende lijst producten mee hoort te veranderen.

Ik ga deze wel noteren, maar verwacht niet dat het hoge prioriteit krijgt.

[Jerrythafast]

Allereerst bedankt voor de vlotte en uitgebreide reactie

ACM schreef op woensdag 28 oktober 2015 @ 08:10:
[...]

Klopt, dat is het doel


[...]

Dat is helaas een gevolg van een paar keuzes die hier de combinatie ingewikkeld maken. Er zijn bij de module die bepaald welke mogelijke specificaties er zijn uberhaupt geen laptops meer met die toetsenborden... Dus uit de statistieken komt die optie niet meer naar voren. De module die e.e.a. weergeeft heeft nog wel die opties in de lijst staan en vult standaard 0 in als er geen statistieken van bekend zijn; we zouden het op kunnen lossen door die module slimmer te maken en bij een aangevinkte 'geen'-optie juist het overgebleven totaal in te vullen ipv 0.

Aha, het is dus een artefact van de implementatie Altijd weer een verrassing wat voor complex systeem er ergens achter kan zitten

ACM schreef op woensdag 28 oktober 2015 @ 08:10:
[...]

Dat is dan blijkbaar een bug bij de merken-variant.

Dan is dit bij deze een bugreport daarvoor

ACM schreef op woensdag 28 oktober 2015 @ 08:10:
[...]

Het weergavedeel communiceert pas met de module die de filtering (en statistieken) bepaald zodra je minimaal 1 optie aanvinkt... Sterker nog, de statistieken worden sowieso pas anders zodra er minimaal 1 optie is aangevinkt.

Ik kan me voorstellen dat het extra load veroorzaakt als de statistieken steeds moeten worden bepaald als het Wel/Geen schuifje wordt omgezet terwijl er niks is aangevinkt. De huidige implementatie betekent echter wel dat de weergegeven getallen niet kloppen als het schuifje op 'Geen' staat, totdat je daadwerkelijk iets selecteert.

ACM schreef op woensdag 28 oktober 2015 @ 08:10:
[...]

Ik gok dat in werkelijkheid ongeveer 99% van de bezoekers met 'Wel' filtert, dus je bent - zonder dat ik statistieken heb verzameld om dat te staven - waarschijnlijk een beetje in de minderheid

Meten is weten

ACM schreef op woensdag 28 oktober 2015 @ 08:10:
Helaas zijn de issues die je noemt best pittig om op te lossen, we willen niet dat er telkens bij het wisselen van 'we' naar 'geen' er allerlei queries op onze database moeten worden uitgevoerd; tenzij het filter daadwerkelijk actief is en dus ook de bijbehorende lijst producten mee hoort te veranderen.

Ik ga deze wel noteren, maar verwacht niet dat het hoge prioriteit krijgt.

Ik kan me goed voorstellen dat het meer werk is dan het in eerste instantie leek. In ieder geval bedankt