[bug,PW-search] "meer resultaten"-link werkt niet goed.

[Raven]

Als ik in de zoekbalk van de PW een deel van een typenr invul dat meerdere resultaten oplevert, tl-wr70 bijvoorbeeld, dan zie ik een popupje verschijnen dat verschillende producten met dat (al dan niet complete) typenummer laat zien:
[/img]

Klik ik op "meer resultaten", wordt http://tweakers.net/pricewatch/zoeken/?keyword=tl-wr70 geopend en dit bericht verschijnt: "Helaas, geen resultaten gevonden."

Waarom gaat dat mis?

[ACM]

Dat komt doordat er in werkelijkheid geen resultaten zijn voor tl-wr70... Wel voor tl-wr706 en 702, maar dat had je nog niet getypt. De quicksearch maakt echter wel gebruik van de 'type ahead find'-mogelijkheid (en zoekt dus effectief op tl-wr70*)

[ Voor 32% gewijzigd door ACM op 06-04-2013 20:53 ]

[Raven]

Na het klikken op die link verwacht ik de resultaten uit dat popupje te zien en evt meer mogelijkheden. Niet een pagina die helemaal niets weergeeft terwijl er meerdere producten zijn met dat (gedeeltelijke) typenummer.

edit nav jouw edit: Waarom doet de gewone search dat niet dan? Als ik zoek op producten uit de tl-wr70* reeks, dan verwacht ik die ook te zien als resultaat, maar blijkbaar moet er een compleet typenummer opgegeven worden om 1 specifiek resultaat te krijgen, wat ik dus niet wil

[ Voor 40% gewijzigd door Raven op 06-04-2013 21:04 ]

[ACM]

Ik ben met je eens dat het duidelijker kan. Maar het is helaas een lastige om op te lossen.

Als we in die popup alleen zoeken op volledige teksten (dus zonder * er automagisch achter), krijg je steeds wel en niet resultaten naarmate je verder typt en bepaalde delen van termen geen of hele andere resultaten geven.
Maar bij de volledige resultatenpagina altijd maar een partiele zoekopdracht uitvoeren (dus daar de * toevoegen) is ook niet heel erg ideaal, dan kan je sommige zoekopdrachten effectief niet uitvoeren (omdat de partiele opdracht dan te veel ruis geeft).
En de manier van Google (auto-aanvulling van zoekopdrachten en dan voor de bovenste aangevulde zoekopdracht resultaten geven) is helaas nogal veel werk om goed uit te werken.

Misschien moeten we maar gewoon het linkje weghalen en bovenin de popup iets als 'gedeeltelijke resultaten' tonen. Een alternatief zou natuurlijk zijn om onder de meer-resultatenlink dan wel de asterix toe te voegen. Maar dan is dat weer inconsistent met wat er gebeurt als je op enter drukt...

't Feit dat op enter drukken ook andere resultaten kan geven geeft natuurlijk hetzelfde probleem...

Of wellicht moeten we eerst de gehele opdracht uitvoeren zonder partiele resultaten en dan neerzetten 'geen resultaten voor tl-wr70, wel de volgende partiele resultaten:'
Maar ook dat is weer raar als er soms wel en soms niet partiele resultaten zijn (vooral als er een tl-wr70 zou bestaan dat iets heel anders is dan de tl-wr702 en tl-wr706).

Helaas het proberen te helpen van een gebruiker iets dat altijd wel ergens weer roet in het eten gooit. Zeker bij dit soort zoekmachine-technieken

[edit]

Waarom doet de gewone search dat niet dan?

Er zijn altijd weer voorbeelden te vinden waarbij het automatisch erachter plakken van een * niet de gewenste resultaten geeft. Ik heb het afgelopen jaar tientallen functies in de zoekmachine ingebouwd en voor iedere functie ook weer een of meer bugreport gezien dat er 'iets' stuk of anders of raar of slechter of onduidelijk of ... etc werd
En die functies waren dan vaak gemaakt om andere bugs of feature requests op te lossen.

Als ik zoek op producten uit de tl-wr70* reeks, dan verwacht ik die ook te zien als resultaat, maar blijkbaar moet er een compleet typenummer opgegeven worden om 1 specifiek resultaat te krijgen, wat ik dus niet wil

Eigenlijk moet je dan expliciet tl-wr70* opgeven (nouja, tl-wr 70*, anders raakt de queryparser weer in de war)

[ Voor 20% gewijzigd door ACM op 06-04-2013 21:10 ]

[Raven]

"omdat de partiele opdracht dan te veel ruis geeft"
En wat als je de resultaten sorteert op relevantie? Exacte match (de * dan even wegdenken) bovenaan en de "ruis" door de * daar onder?

[ACM]

Raven schreef op zaterdag 06 april 2013 @ 21:07:
"omdat de partiele opdracht dan te veel ruis geeft"
En wat als je de resultaten sorteert op relevantie? Exacte match (de * dan even wegdenken) bovenaan en de "ruis" door de * daar onder?

Oh, dat zal in de praktijk ook wel gebeuren, tenzij de tegelijkertijd ook gebruikte populariteitsweging weer de boel in de war schopt...
Zie toevoeging in mijn vorige reactie over functies die altijd wel weer ergens in de war geschopt worden

[Raven]

Dus long story short: if it ain't broke, don't (try to) fix it?

Maar ehm, waarom werkt tl-wr70* niet en tl-wr 70* wel? Wat snapt de zoekmachine daar niet van?

[ Voor 16% gewijzigd door Raven op 06-04-2013 21:16 ]

[ACM]

Raven schreef op zaterdag 06 april 2013 @ 21:14:
Dus long story short: if it ain't broke, don't (try to) fix it?

Nouja, is het niet broken? Volgens mij vind jij van wel

Maar ehm, waarom werkt "tl-wr70*" niet en "tl-wr 70*" wel?

Mja, dat komt weer door de manier waarop Lucene omgaat met tl-wr70, dat wordt uiteindelijk "tl AND wr AND 70" (met als extra eis dat ze ook pal achter elkaar moesten staan in de tekst).
Het voordeel is dat als je als gebruiker niet wist of het nou "tl-wr" of "tl wr" was of "tl-wr70" of "tl-wr 70" dat je dan dezelfde resultaten krijgt.

Maar zoals elke functie, deze heeft ook nadelen;
Bij een wildcard (die * ), vindt Lucene ineens dat het anders behandeld moet worden, dan maakt ie er "tl-wr70*" van intern... dus zonder het opsplitsen in losse woorddelen. En die zitten dan uiteraard niet op die manier in de zoekdatabase, en dus krijg je geen resultaten.

In onze quicksearch-code, die gebruikt wordt voor de pop-up, lossen we dat al op door domweg het woord op te hakken en de * er slimmer achter te plakken. Maar als gebruiker weet je natuurlijk niet dat je daar dan een spatie tussen had moeten zetten (zelfs het aantal gebruikers dat weet dat je er een * achter had kunnen zetten zal wel niet erg groot zijn).

Ik heb dit al op de todo staan om beter uit te zoeken, maar het is helaas nogal lastig op te lossen. Vooral als je probeert de andere delen weer redelijk heel te houden

[ Voor 20% gewijzigd door ACM op 06-04-2013 21:23 ]

[Raven]

Mjah, ik vind van wel idd , eigenlijk had het "if it ain't seriously broke(n)" moeten zijn

Pffffff, nooit geweten dat zoekmachines zo complex en eigenwijs zijn