Test de nieuwe beta-Forumsearch!

[ACM]

Na de introductie van nieuwe zoektechnologie voor artikelen, userreviews en V&A-advertenties - met Tweakers 7 - zijn we doorgegaan om ook de zoekmachine achter het forum met vergelijkbare techniek te vernieuwen.

Er is daarmee een compleet nieuwe zoekmachine voor het forum ontwikkeld. Daar zitten een aantal belangrijke vernieuwingen in.

Het zoeken gebeurt nu op reactie-basis, voorheen was dat op topic-basis. Dat is vooral voor de hele lange topics zinvol, vroeger zorgde dit er namelijk voor dat ze bij erg veel zoekopdrachten naar voren kwamen omdat de termen verspreid over de losse reacties samen gezien werden. Daarnaast zorgt het er voor dat het aantal reacties op een topic niet meer uit maakt voor de zogenaamde "term frequency", een van de elementen die gebruikt wordt om de score van een resultaat te bepalen.

De zoekmachine wordt "near realtime" bijgewerkt. Oftewel, zodra een topic wordt aangepast wordt geprobeerd dat direct bij te werken. Er zal altijd wel een zekere vertraging in zitten, maar het zou geen twee uur meer moeten duren voor je een nieuw topic of nieuwe reactie ziet terugkomen.

De relevantie bestaat uit meerdere elementen nu, naast de normale tekstuele relevantie wordt het geboost door:

• de leeftijd van de reacties, ouder is minder relevant. FAQ, Sticky en Stucky zijn uitgesloten van deze tijdsgewogen degradatie van de score. Gesloten topics die heel snel gesloten waren dalen daarentegen veel harder.
• de populariteit van het topic als geheel, meer populair weegt een beetje extra
• het type topic: FAQ, Sticky en Stucky worden ietsje geboost t.o.v. een normaal open topic en een gesloten topic ietsje lager.

Een boost betekent overigens dat het topic wel reacties moest hebben die matchten, bij een hele lage tekstuele relevantie maakt het dus nog steeds weinig uit of het topic oud of nieuw is en of het een FAQ of Open topic is.

Het zoekformulier is wat vereenvoudigd. Door de krachtigere relevantie zijn het onhandige jaar-filter en de mogelijkheid om de "snel gesloten topics" uit te sluiten verwijderd. Je kan uiteraard nog steeds op type en leeftijd filteren.

Bij de zoekresultaten zie je een paar van de best aansluitende reacties met een contextuele snippet. Oftewel, je krijgt niet een stukje van de topicstart te zien, maar de reacties die de beste match opleverden en daarvan dan weer de beste snippet.

De zoekresultaten zijn vereenvoudigd. Voorheen stond er per resultaat een hele waslijst aan linkjes die je kon gebruiken om allerlei varianten op het zoeken te krijgen. Nu zijn dat er minder: de topiclink, de directe link naar de losse reacties en een link om binnen dat topic de zoekopdracht te herhalen topic.

Het zoeken in de topics is ook gelijk vervangen. Je kan er dus dezelfde query-taal gebruiken als in de normale zoekmachine. Voorheen werd dat gedaan met een simpele LIKE-query in SQL.

---

Er zijn nog diverse zaken niet helemaal perfect en door alle uiteenlopende wensen zal het ook nooit lukken om het helemaal perfect te maken

Maar we gaan natuurlijk wel een poging wagen. We zijn zelf onder andere nog niet helemaal tevreden met de weergave van de zoekresultaten en er moet ook vast nog wel wat gesleuteld worden aan de manier van sorteren, relevantie, etc.

Je kan e.e.a. hier testen. Let er op dat je met live data test. Dat zorgt er voor dat je resultaten goed kan vergelijken met de huidige zoekmachine, maar zorgt er ook voor je niet zomaar een willekeurige testreactie moet gaan plaatsen. Er gelden tenslotte de normale forumregels op

We willen graag feedback op:

• De werking van de zoekmachine in algemene zin
• De relevantie van de zoekresultaten ten op zichte van je zoekopdracht
• De kwaliteit van de snippets t.o.v. je zoekopdracht
• De werking van de zoekmachine binnen topics

Maar als er andere aandachtspunten zijn, dan horen we dat natuurlijk ook graag

Overigens is de verwachting dat het nog wel een paar iteraties duurt voor we dit helemaal in productie opzetten. Sowieso zijn er veel vakanties de komende tijd en we moeten het design van de resultaten nog beter uitwerken

[CodeCaster]

Ziet er op het eerste gezicht goed uit! Waar wil je de bugs hebben? Hier of in een nieuw topic?

De highlighting werkt namelijk niet goed, als ik bijvoorbeeld zoek op "HP N40L" krijg ik <strong>N</strong><strong>40</strong><strong>L</strong> (oid) te zien in de zoekresultaten.

Maar nu is 'ie helemaal stuk, ik krijg een 301 naar http://gathering.tweakers.net/forum/find/.

[ Voor 5% gewijzigd door CodeCaster op 11-12-2012 11:40 ]

[DennusB]

CodeCaster schreef op dinsdag 11 december 2012 @ 11:38:
Ziet er op het eerste gezicht goed uit! Waar wil je de bugs hebben? Hier of in een nieuw topic?

De highlighting werkt namelijk niet goed, als ik bijvoorbeeld zoek op "HP N40L" krijg ik <strong>N</strong><strong>40</strong><strong>L</strong> (oid) te zien in de zoekresultaten.

Maar nu is 'ie helemaal stuk, ik krijg een 301 naar http://gathering.tweakers.net/forum/find/.

Ik krijg geen 301 hoor?

[CodeCaster]

Kijk eens goed naar je adresbalk dan, als je op de link klikt? Dit gebeurt bij mij, na de eerste drie requests die het wel deden:

code:

GET http://beta.gathering.tweakers.net/forum/find/ HTTP/1.1

code:

HTTP/1.1 301 Moved Permanently
X-Tweakers-Server: searchtest
Location: http://gathering.tweakers.net/forum/find/

[ Voor 8% gewijzigd door CodeCaster op 11-12-2012 11:48 ]

[DennusB]

CodeCaster schreef op dinsdag 11 december 2012 @ 11:44:
Kijk eens goed naar je adresbalk dan? Dit gebeurt bij mij, na de eerste drie requests die het wel deden:

code:

GET http://beta.gathering.tweakers.net/forum/find/ HTTP/1.1

code:

HTTP/1.1 301 Moved Permanently
Location: http://gathering.tweakers.net/forum/find/

Doet het prima hier.

[AtleX]

Ik krijg ook de 301 van CodeCaster.

[ACM]

Oeps, nu niet meer

[Cyphax]

Ik heb net eens gekeken of ie nou een letterlijke topictitel snapt: "Elektrisch rijden, is het er klaar voor?"

Geen resultaat. Tenminste, niet dat topic. Niet met de huidige search, niet met de nieuwe search. Het is het 5e laatst geüpdate topic binnen VV. De enige resultaten zijn 6 topics uit de reeks van "grote spoorwegen"-topics.

Ik vind dat de searchengine dat topic als eerste resultaat zou moeten teruggeven in principe, of hij moet het in andere topics nog relevanter vinden, maar niet helemaal niet.

[ Voor 23% gewijzigd door Cyphax op 11-12-2012 12:21 ]

[CodeCaster]

ACM schreef op dinsdag 11 december 2012 @ 12:10:
Oeps, nu niet meer

Mooi, nu is mijn bug ook weg.

[GlowMouse]

Als ik zoek op "hier testen" (met quotes) heb ik drie bugs:
- Hij lijkt niks met de quotes te doen, dit lijkt met stopwoorden te maken te hebben.
- "hier" wordt nooit gehighlight in de zoekresultatenlijst, ook dit lijkt met stopwoorden te maken te hebben.
- Sommige topics komen tevoorschijn zonder dat er excerpts van posts bijstaan

Nog een bug: Onbekende fout opgetreden tijdens de pageview

Het filter op datum laatste reactie wordt genegeneerd (krijg ook oude resultaten): klik

[ Voor 22% gewijzigd door GlowMouse op 11-12-2012 12:41 ]

[ACM]

Cyphax schreef op dinsdag 11 december 2012 @ 12:19:
Ik heb net eens gekeken of ie nou een letterlijke topictitel snapt: "Elektrisch rijden, is het er klaar voor?"

Ik krijg 'm wel?

[ACM]

GlowMouse schreef op dinsdag 11 december 2012 @ 12:36:
Als ik zoek op "hier testen" (met quotes) heb ik drie bugs:
- Hij lijkt niks met de quotes te doen, dit lijkt met stopwoorden te maken te hebben.
- "hier" wordt nooit gehighlight in de zoekresultatenlijst, ook dit lijkt met stopwoorden te maken te hebben.

Dat is inderdaad gedrag van Lucene. Stopwoorden zijn altijd waardeloos, zowel ze laten staan als ze verwijderen werkt averechts

- Sommige topics komen tevoorschijn zonder dat er excerpts van posts bijstaan

Dat is niet per se een bug. Als de term alleen in de titel, gerelateerde producten/tags/etc staan, dan is er geen message-body met een highlight te genereren. Had jij een situatie waar er onder die voorwaarden wel een message-body met highlight had moeten zijn?

Nog een bug: Onbekende fout opgetreden tijdens de pageview

Het filter op datum laatste reactie wordt genegeneerd (krijg ook oude resultaten): klik

Hier ga ik beide even naar kijken

[Cyphax]

ACM schreef op dinsdag 11 december 2012 @ 13:52:
[...]

Ik krijg 'm wel?

Ik had 'm zonder quotes ingevoerd. (Ik had het misschien hier ook niet met quotes moeten neerzetten natuurlijk ) Met quotes, zoals je hier doet, is het het eerste resultaat.

Maar 't kan zijn dat je een nuance als een vraagteken negeert... of twee woorden omdraait. Het is zo makkelijk om een topictitel niet 100% goed maar 90% goed te hebben. Dan zou het fijn zijn als ie de titel tenminste vindt, zelfs als dat niet het eerste resultaat is.

[ Voor 4% gewijzigd door Cyphax op 11-12-2012 14:43 ]

[ACM]

Cyphax schreef op dinsdag 11 december 2012 @ 14:42:
Ik had 'm zonder quotes ingevoerd. (Ik had het misschien hier ook niet met quotes moeten neerzetten natuurlijk ) Met quotes, zoals je hier doet, is het het eerste resultaat.

Maar 't kan zijn dat je een nuance als een vraagteken negeert... of twee woorden omdraait. Het is zo makkelijk om een topictitel niet 100% goed maar 90% goed te hebben. Dan zou het fijn zijn als ie de titel tenminste vindt, zelfs als dat niet het eerste resultaat is.

Als je alle leestekens - maar vooral het vraagteken - weglaat krijg je 'm wel weer bovenaan. Ik vermoed dat Lucene's queryparser die 'voor?' niet zo leuk vindt. Normaliter worden leestekens weggelaten, tenzij ze dus een speciale betekenis hebben voor de querytaal.

[ACM]

GlowMouse schreef op dinsdag 11 december 2012 @ 12:36:
Nog een bug: Onbekende fout opgetreden tijdens de pageview

Ah, lucene vindt het niet leuk als je een veld zonder positionele data gebruikt met een phrase-query... Es kijken hoe we dat netjes uit kunnen sluiten.

Het filter op datum laatste reactie wordt genegeneerd (krijg ook oude resultaten): klik

Het helpt als je die datum ook daadwerkelijk doorgeeft, fixed

[GlowMouse]

ACM schreef op dinsdag 11 december 2012 @ 13:58:
[...]

Dat is niet per se een bug. Als de term alleen in de titel, gerelateerde producten/tags/etc staan, dan is er geen message-body met een highlight te genereren. Had jij een situatie waar er onder die voorwaarden wel een message-body met highlight had moeten zijn?

Nee, maar er is wel wat raars. Hier wordt http://beta.gathering.twe...rum/list_messages/1516116 gevonden. Als hij op 'speedtest.net' matcht, zou je ook verwachten dat post 1 getoond wordt.


test / testen ziet hij als hetzelfde woord, maar getest niet

[ACM]

GlowMouse schreef op dinsdag 11 december 2012 @ 16:17:
Nee, maar er is wel wat raars. Hier wordt http://beta.gathering.twe...rum/list_messages/1516116 gevonden. Als hij op 'speedtest.net' matcht, zou je ook verwachten dat post 1 getoond wordt.

Ah, hij matched op de SpeedTest.net uit de titel. Of eigenlijk op een deel van de in stukken gehakte term 'speed', 'test' en 'net'. Niet op "*test" oid.

test / testen ziet hij als hetzelfde woord, maar getest niet

Hmm, blijkbaar is de stemming nog niet helemaal briljant.
Ook al zo'n concept dat altijd voor en tegen je werkt.

[GlowMouse]

ACM schreef op dinsdag 11 december 2012 @ 19:47:
[...]

Ah, hij matched op de SpeedTest.net uit de titel. Of eigenlijk op een deel van de in stukken gehakte term 'speed', 'test' en 'net'. Niet op "*test" oid.

Dan zou hij toch ook de openingspost moeten tonen met speedtest gehighlight?

Even een test van gewijzigde berichten ( uniekwoord ).

[ Voor 6% gewijzigd door GlowMouse op 12-12-2012 11:08 ]

[ACM]

GlowMouse schreef op dinsdag 11 december 2012 @ 23:36:
Dan zou hij toch ook de openingspost moeten tonen met speedtest gehighlight?

SpeedTest.net uit de titel wordt - door de hoofdletters en de punt - geindexeerd als 'speedtestnet', 'speedtest', 'speed', 'test' en 'net'. En hij matched dus op die 'test'.
Maar de speedtest.net uit de tekst wordt - door de punt - alleen geindexeerd als 'speedtestnet', 'speedtest' en 'net'. Dus daar matched ie ook domweg niet op met de term 'test'.

Het zit 'm in die hoofdletterovergang. In de message-body zelf heeft ie dus helemaal geen match en dus ook niks om te highlighten. Ik snap dat dat wellicht wat onterecht lijkt, want speedtest.net staat ook daar in... maar het is dus niet hetzelfde als met stemming dat ie speedtest en test als hetzelfde woord ziet. Lucene weet helemaal niet dat ie eigenlijk op speedtest matchte, alleen maar dat ie op test matchte (die bovendien op op een andere positie staat dan de speedtest uit de reactie).

[GlowMouse]

Gebruiken jullie een standaard tokenizer en stemmer? Dan helpt het misschien om die te noemen.

Als ik op uniekwoord zoek dan zie ik deze thread terugkomen, maar niet mijn vorige post. Deze post komt wel terug (en vrijwel realtime). Worden gewijzigde posts misschien anders behandeld?

Indexeer je nu alle posts in een thread opnieuw als er één post bijkomt (omdat je properties zoals het tijdstip van de laatste reactie moet bijwerken)? Hoe groot is de index ongeveer? Moet je af en toe de zoekindex opnieuw opbouwen omdat hij nu inefficiënt hard groeit? Misschien voer voor de volgende .plan.

[ Voor 42% gewijzigd door GlowMouse op 12-12-2012 11:14 ]

[_David_]

Nu:
Zoekresultaat: 96.126 topics gevonden

Beta:
Zoekresultaat: 1.340.530 topics gevonden

Waarom trouwens die "Je kunt deze query ook op Google uitproberen." optie? geen vertrouwen in je eigen nieuwe forumsearch?

[ Voor 35% gewijzigd door _David_ op 13-12-2012 18:24 ]

[ACM]

GlowMouse schreef op woensdag 12 december 2012 @ 11:10:
Gebruiken jullie een standaard tokenizer en stemmer? Dan helpt het misschien om die te noemen.

We gebruiken een eigen analyzer die de WordDelimiterFilter, LowerCaseFilter, StopFilter (met default stopwoorden van DutchAnalyzer) en SnowballFilter (met DutchStemmer) in de genoemde volgorde combineert.

Worden gewijzigde posts misschien anders behandeld?

Gewijzigde posts zouden niet anders behandeld moeten worden, maarja... het idee van bugtesting is natuurlijk dat je probeert te achterhalen dat dat soort statements ook inderdaad kloppen

Indexeer je nu alle posts in een thread opnieuw als er één post bijkomt (omdat je properties zoals het tijdstip van de laatste reactie moet bijwerken)?

Ja. Maar niet alle metadata-wijzigingen leveren een reindex op. Sommige worden in de in-memoryelementen verwerkt, waardoor het niet nodig is de index bij te werken als ze veranderen.

Ik wil nog bekijken of het met minder grote wijzigingen kan, het is technisch niet nodig dat alle reacties opnieuw gedaan worden als er eentje wijzigt of bij komt. Maar vooralsnog lijkt ie het allemaal vrij goed bij te houden.

Hoe groot is de index ongeveer?

5.9GB, maar ook hier geldt dat niet alle metadata in de index verwerkt zit dus het is bijna de minimaal mogelijke afmeting qua inhoud. De bodies van reacties wordt bijvoorbeeld on-demand uit de database gehaald (nouja, via een ram-cache) en dan verwerkt voor highlighting. In plaats van helemaal via de Lucene-index gedaan.
Met andere "Codecs" en PostingFormats kan er vast nog wat af, maar aangezien die allemaal nog een beetje experimenteel zijn in Lucene 4.0 vind ik het voorlopig wel best zo

Moet je af en toe de zoekindex opnieuw opbouwen omdat hij nu inefficiënt hard groeit?

Dat lijkt mee te vallen. Direct na de eerste index was ie ook zo'n soort maatje en met een paar dagen aan continu indexeren zit zowel de index-grootte als het aantal segmenten op een prima laag niveau. Als ik het goed zie heeft ie momenteel 23 segmenten actief.
Lucene 4.0 kan icm de "NRTDirectory" blijkbaar vrij goed tegen tegen continu updaten en mergen/optimizen.

[ACM]

davidaap123 schreef op donderdag 13 december 2012 @ 18:22:
[...]

Dat is een beetje een onhandige functie van de huidige zoektechniek. Die probeert een schatting te geven. Als je doorgaat naar de laatste pagina wordt de schatting steeds hoger, zodanig dat je uiteindelijk voor de meeste zoekopdrachten op ongeveer dezelfde totaal aantallen uit zult komen als in de nieuwe.
Maar de nieuwe toont gewoon gelijk hoeveel matches er zijn.

Waarom trouwens die "Je kunt deze query ook op Google uitproberen." optie? geen vertrouwen in je eigen nieuwe forumsearch?

Euh... dat is wel een beetje legacy inderdaad, domweg niet weggehaald
Maar sowieso zijn wij natuurlijk niet de enige site die door Google wordt geindexeerd, de zoekopdracht bij google is niet met e.o.a. domein-beperking toch?

[_David_]

ACM schreef op donderdag 13 december 2012 @ 18:51:


[...]

Euh... dat is wel een beetje legacy inderdaad, domweg niet weggehaald
Maar sowieso zijn wij natuurlijk niet de enige site die door Google wordt geindexeerd, de zoekopdracht bij google is niet met e.o.a. domein-beperking toch?

nee, gewoon https://www.google.com/search?q=<searchquery>

[F.West98]

Als ik zoek op V250, voor de trein, krijg ik ook resultaten uit EL, waar 250V in staat
Met aanhalingstekens krijg ik dingen als Het algemene kortingentopic met een post waar enkel 250 in staat.

Lijkt me niet gewenst...

[GlowMouse]

F.West98 schreef op donderdag 13 december 2012 @ 19:13:
Als ik zoek op V250, voor de trein, krijg ik ook resultaten uit EL, waar 250V in staat
Met aanhalingstekens krijg ik dingen als Het algemene kortingentopic met een post waar enkel 250 in staat.

Lijkt me niet gewenst...

Je kunt "V250" tussen quotes zetten, anders zoekt hij op "V" en op "250". Ik weet niet of die splitsing handig is, als je op HTML5 zoekt dan wil je geen HTML zien, maar als je op HTML zoekt dan wil je wel HTML5 zien.

ACM schreef op donderdag 13 december 2012 @ 18:49:
5.9GB, maar ook hier geldt dat niet alle metadata in de index verwerkt zit dus het is bijna de minimaal mogelijke afmeting qua inhoud. De bodies van reacties wordt bijvoorbeeld on-demand uit de database gehaald (nouja, via een ram-cache) en dan verwerkt voor highlighting. In plaats van helemaal via de Lucene-index gedaan.

Dat is wel compact. Wij zitten op ruim 17 GB voor 9 miljoen posts met Lucene 4, maar dat is niet met een realtime index, met elke post dubbel (twee tokenizers), en met de post-inhoud er (gecomprimeerd) bij.

[ACM]

GlowMouse schreef op donderdag 13 december 2012 @ 19:50:
Je kunt "V250" tussen quotes zetten, anders zoekt hij op "V" en op "250". Ik weet niet of die splitsing handig is, als je op HTML5 zoekt dan wil je geen HTML zien, maar als je op HTML zoekt dan wil je wel HTML5 zien.

Inderdaad. Het is zo'n functie die handig is totdat ie het niet is

Ik heb wel een versie van de WordDelimiterFilter gehad die eerst in de index opzocht of een bepaalde term "as is" voorkwam, zoja, dan ging ie bij het zoeken niet meer splitsen. Ik heb eigenlijk geen idee meer waarom ik die weggedaan heb, maar dat had vast ook ergens weer nadelen

Het zal wel niet goed samen gewerkt hebben met Stemming ofzo.

Dat is wel compact. Wij zitten op ruim 17 GB voor 9 miljoen posts met Lucene 4, maar dat is niet met een realtime index, met elke post dubbel (twee tokenizers), en met de post-inhoud er (gecomprimeerd) bij.

9 miljoen reacties of topics? Dat van ons is nu bijna 32 miljoen reacties op zo'n 1.5M topics. Dus er zijn zo'n 1.5M vrij uitgebreide documenten, 30M wat kalere (geen title of tag/merk/product-namen) en nog 1.5M "controle"-documenten (voor de laatste index-tijd van een topic) die verder geen zoekresultaten opleveren.

Realtime maakt denk ik weinig uit voor de grootte, 't is eerder een nadeel. Een stopwoordfilter scheelt natuurlijk wel verminderd de data wel aardig en worddelimiter geeft weer wat extra data.

[GlowMouse]

ACM schreef op donderdag 13 december 2012 @ 20:02:
[...]

Inderdaad. Het is zo'n functie die handig is totdat ie het niet is

Kun je, als een user zelf geen speciale zoekquery opbouwt maar gewoon wat woorden invoert, elk woord tussen quotes zetten?

[...]

9 miljoen reacties of topics? Dat van ons is nu bijna 32 miljoen reacties op zo'n 1.5M topics. Dus er zijn zo'n 1.5M vrij uitgebreide documenten, 30M wat kalere (geen title of tag/merk/product-namen) en nog 1.5M "controle"-documenten (voor de laatste index-tijd van een topic) die verder geen zoekresultaten opleveren.

Realtime maakt denk ik weinig uit voor de grootte, 't is eerder een nadeel. Een stopwoordfilter scheelt natuurlijk wel verminderd de data wel aardig en worddelimiter geeft weer wat extra data.

Dat waren alleen reacties met de poster en een lijst met userid's die eerder in het topic gepost hebben (zodat je kunt zoeken op een post waarin je genoemd wordt zonder dat je zelf al in dat topic zat), zonder title/tag.
De zoekindex met 1.9M topics is (die een veelvoud van de 9M reacties bevatten) is ongeveer 20 GB.
Stopwoorden zal de grootte ook wel flink inperken ja, die gebruik ik niet.

Je kunt nu ook een pagina maken met mentions (al moet je dan op post-tijd aflopend sorteren en niet per topic grouperen).

[Anoniem: 423265]

Disclaimer: Ik kan het niet testen want geen enkele zoekopdracht werkt bij mij momenteel. Maar ik vrees inmiddels het woord 'vereenvoudiging', wat dat gaat vaak ten koste van geavanceerde mogelijkheden. Ik kan me niet voorstellen dat iets essentiëels als het zoeken op *alleen* topictitel straks niet meer kan, maar na alle verbazing de afgelopen weken vraag ik het toch maar voor de zekerheid, blijft dat behouden? (de beta werkt hier momenteel niet)

Maar dan nog: Jullie willen alles vereenvoudigen. Waarom is er dan geen makkelijker manier om alleen op topictitel te zoeken? Nu heb je nog de knop 'Title:'. Die zie ik in de beta niet meer. Natuurlijk kan ik het ook handmatig intikken, maar waarom zo overdreven versimpelen dat basale functies er zelfs lastiger door worden?

[F.West98]

Kan je niet sorteren op:
Laatste hit?
Dus niet sorteren op laatste topicstart, laatste reactie, maar laatste reactie die matcht met jouw query.
Dus het topic van laatste bericht waar HTML in voorkomt weergeven, ipv het topic waar HTML ooit in staat waar als laatst EEN reactie is weergegeven.

Voorbeeld:
http://beta.gathering.twe...st_message_end]=#hitstart
In plaats van een topic bovenaan te zetten waar recent een post in is, maar waar ik lang geleden in gequote ben (SSD topic), het topic bovenaan zetten waarin ik als laatste ben gequote. (waarin de laatste, nieuwste hit is gevonden)
Dus in dit geval dit topic bovenaan zetten, ipv SSD topic. Bitcoin topic mag dan weer stuk omlaag (2011, kom op )

[ Voor 6% gewijzigd door F.West98 op 13-12-2012 21:07 ]

[ACM]

Anoniem: 423265 schreef op donderdag 13 december 2012 @ 20:50:
Disclaimer: Ik kan het niet testen want geen enkele zoekopdracht werkt bij mij momenteel.

Bij mij wel?

Maar ik vrees inmiddels het woord 'vereenvoudiging', wat dat gaat vaak ten koste van geavanceerde mogelijkheden.

Vereenvoudiging betekent voor de eindgebruiker inderdaad doorgaans dat geavanceerde mogelijkheden veranderen of verdwijnen. Maar ook dat keuzes en daarmee obstakels weggenomen worden of dat de begrijpelijkheid en daarmee de gebruiksvriendelijkheid toeneemt.

Bijkomend voordeel is natuurlijk dat die - vaak complexe - functionaliteit schrappen ten gunste komt van de onderhoudbaarheid en daarmee de beschikbare ontwikkeltijd.

Ik kan me niet voorstellen dat iets essentiëels als het zoeken op *alleen* topictitel straks niet meer kan, maar na alle verbazing de afgelopen weken vraag ik het toch maar voor de zekerheid, blijft dat behouden?

Het zit er nu niet expliciet meer in. Maar waarom vind je het essentieel?

maar waarom zo overdreven versimpelen dat basale functies er zelfs lastiger door worden?

Essentieel, basaal... Je legt nogal wat gewicht op de "alleen op titel zoeken"-functie. Kan je aangeven waarom je dat doet?

We kijken bij het schrappen van knopjes en functies namelijk wel degelijk of ergens animo voor is en/of gebruik van gemaakt wordt. En met 182 zoekopdrachten van de 35977 is 'title:'-niet enorm populair. Het wordt in slechts 0.5% van de queries gebruikt. Ook dat is op zichzelf geen reden om het te schrappen natuurlijk... maar om het nou een essentiele, bassale functie te noemen gaat me dan wel wat ver.

Overigens wordt de titel nog wel los geindexeerd alleen heet het titelveld nu 'name'. Dus met 'name:test' vind je de topics met 'test' in de titel (name is weer ivm hergebruik van code van onze andere zoekmachines, tag-, merk-, serie-, categorie- en productnamen waren eerder en om die nou 'titel' te noemen was toen nog raarder).
Ik zal nog met onze productontwerpers bekijken of we dat moeten adverteren (bijv dmv een knop die zelden gebruikt wordt) en kijken of er een alias-functie bij moet komen zodat je 'titel' of 'title' kan opgeven

[F.West98]

Nou, ik wist niet dat het bestond. Ik zoek vaak topics en dan zoek ik op trefwoorden in de titel die ik me dan vaag kan herinneren.
Als er een knopje was: zoek op titel, zonder dat er name: queries ontstaan zou ik dat waarderen.

[ACM]

GlowMouse schreef op donderdag 13 december 2012 @ 20:46:
Kun je, als een user zelf geen speciale zoekquery opbouwt maar gewoon wat woorden invoert, elk woord tussen quotes zetten?

Dat is een interessante om te onderzoeken inderdaad. Of anderzins de WordDelimiter-termen als e.o.a. phrase-query zien.

F.West98 schreef op donderdag 13 december 2012 @ 21:03:
Kan je niet sorteren op:
Laatste hit?
Dus niet sorteren op laatste topicstart, laatste reactie, maar laatste reactie die matcht met jouw query.
Dus het topic van laatste bericht waar HTML in voorkomt weergeven, ipv het topic waar HTML ooit in staat waar als laatst EEN reactie is weergegeven.

De benodige informatie is inderdaad beschikbaar op het juiste moment. Dus ik heb er een intern ticket voor gemaakt om te kijken of we dat willen en hoe dat vormgegeven moet worden.

[ Voor 45% gewijzigd door ACM op 13-12-2012 21:31 ]

[Anoniem: 423265]

ACM schreef op donderdag 13 december 2012 @ 21:17:
[...]

Bij mij wel?

Bij mij niet

Vereenvoudiging betekent voor de eindgebruiker inderdaad doorgaans dat geavanceerde mogelijkheden veranderen of verdwijnen. Maar ook dat keuzes en daarmee obstakels weggenomen worden of dat de begrijpelijkheid en daarmee de gebruiksvriendelijkheid toeneemt.

Bijkomend voordeel is natuurlijk dat die - vaak complexe - functionaliteit schrappen ten gunste komt van de onderhoudbaarheid en daarmee de beschikbare ontwikkeltijd.

Ik ken de discussie uit o.a. dat andere topic, maar hoe mooi het ook is, het blijft een achteruitgang als je net die ene functie gebruikt.

[...]

Het zit er nu niet expliciet meer in. Maar waarom vind je het essentieel?

Omdat het gewoon een essentiële functie is, anders had niet vrijwel ieder forum, al van oudsher die functie erin zitten. GoT heeft 'm ook altijd al gehad.


[...]

Essentieel, basaal... Je legt nogal wat gewicht op de "alleen op titel zoeken"-functie. Kan je aangeven waarom je dat doet?

Omdat ik die functie heel vaak gebruikt heb. Vaak, als een andere methode teveel hits oplevert, zoek ik even alleen op titel, en vindt dan wél of sneller wat ik zoek. Zo doe ik het al jaren, op ieder forum (maar eigenlijk overal), als het nodig is. En meestal tot volle tevredenheid.

En eigenlijk heb ik altijd gedacht dat het een veelgebruikte functie is. Het zit zo logisch in elkaar dat ik me dat zelfs nooit eens afgevraagd heb: Je hebt een titel, en daar gaat het topic over. Dus wil je iets over dat onderwerp weten, dan zoek je op titel, want dan krijg je de meest relevante topics. En zoek je niet op titel, dan krijg je meestal meer resultaten, maar vaak uit topics die ergens anders over gaan. Twee keuzes dus, met beide verschillende eigenschappen. Ik verbaas me eerlijk gezegd dat ik dat moet uitleggen

We kijken bij het schrappen van knopjes en functies namelijk wel degelijk of ergens animo voor is en/of gebruik van gemaakt wordt. En met 182 zoekopdrachten van de 35977 is 'title:'-niet enorm populair. Het wordt in slechts 0.5% van de queries gebruikt. Ook dat is op zichzelf geen reden om het te schrappen natuurlijk... maar om het nou een essentiele, bassale functie te noemen gaat me dan wel wat ver.

Tja zie boven, het is voor het eerst dat ik verneem dat het geen essentiële/basale functie is, ikzelf weet eigenlijk niet beter, dan dat dit tot de basismogelijkheden van het zoeken behoort (zie boven). Ik ben dan ook (wederom) verbaasd, dat het hier zo weinig gebruikt wordt. Ik weet niet om welke tijdsperiode het gaat, maar ik gebruik 'm zo regelmatig, dat ik volgens mij alleen zélf al die 182 zoekopdrachten moet halen.

Overigens wordt de titel nog wel los geindexeerd alleen heet het titelveld nu 'name'. Dus met 'name:test' vind je de topics met 'test' in de titel (name is weer ivm hergebruik van code van onze andere zoekmachines, tag-, merk-, serie-, categorie- en productnamen waren eerder en om die nou 'titel' te noemen was toen nog raarder).
Ik zal nog met onze productontwerpers bekijken of we dat moeten adverteren (bijv dmv een knop die zelden gebruikt wordt) en kijken of er een alias-functie bij moet komen zodat je 'titel' of 'title' kan opgeven

Tnx. Nouja, als-ie écht zo weinig gebruikt wordt, hoeft er wat mij betreft niet zozeer meer speciaal een knop voor terug te komen, maar haal alsjeblieft de mogelijkheid niet weg

[ACM]

Anoniem: 423265 schreef op donderdag 13 december 2012 @ 22:36:
Bij mij niet

Hmm, niet?
Waar resolved beta.gathering.tweakers.net voor jou naar (zou 213.239.154.18 moeten zijn)? En probeer je het niet (onbewust) via HTTPS? Daar hebben we geen moeite voor gedaan in de testomgeving.

Ik verbaas me eerlijk gezegd dat ik dat moet uitleggen

Je hoefde niet per se uit te leggen in welke situaties je het gebruikt (maar het is alsnog nuttig dat te weten), maar ik was vooral benieuwd waarom je het essentieel vond

Ik ben dan ook (wederom) verbaasd, dat het hier zo weinig gebruikt wordt.

Mijn ervaring leert dat de meeste mensen vrij lui zijn icm zoekmachines, veel verder dan een of twee zoektermen komen de meeste niet. En zelfs hier op GoT valt dat dus eigenlijk nog wel "tegen". Maargoed, als de zoekmachine goede resultaten aanlevert bij die enkele termen, waarom zou je dan ook meer intypen

Ik weet niet om welke tijdsperiode het gaat, maar ik gebruik 'm zo regelmatig, dat ik volgens mij alleen zélf al die 182 zoekopdrachten moet halen.

Beide cijfers waren uit dezelfde tijdsperiode. Het vorige logbestand is zo te zien voor het laatst aangepast op 9 december, dus gisteravond was degene waar ik de cijfers uit haalde ruim 4 dagen oud. Op zich maakt het niet zoveel uit, die interface is al jaren technisch hetzelfde en de laatste layoutwijziging is natuurlijk ook van oktober.
Wellicht dat het nog wel uitmaakt dat je het zoekformulier tegenwoordig pas ziet nadat je een zoekopdracht hebt ingevoerd. Maar we hebben helaas geen zoekmachine-logbestanden meer uit die tijd

Tnx. Nouja, als-ie écht zo weinig gebruikt wordt, hoeft er wat mij betreft niet zozeer meer speciaal een knop voor terug te komen, maar haal alsjeblieft de mogelijkheid niet weg

Ik wist eigenlijk niet dat er mensen zijn die het naast nuttig ook essentieel vonden. Dus ik laat de mogelijkheid in ieder geval bestaan zoals ie nu is en de interne ticket om te onderzoeken of we het nog op een andere manier verder terug willen brengen laat ik ook gewoon open.
Zoals gezegd: dat iets weinig gebruikt wordt is op zich geen reden het te verwijderen, het is vooral een ondersteuning als je nog meer redenen hebt (zoals: het werkt niet goed, het is veel werk om te onderhouden, het maakt de boel verwarrender voor gebruikers, e.a.)

[ Voor 11% gewijzigd door ACM op 14-12-2012 08:22 ]

[Gonadan]

Aan de hand van een of ander gesloten 'klaagtopic' over de search hier terecht gekomen. Tot nu toe kan ik niets anders zeggen dan kudos. Het werkt gewoon prettig en ik ben vooralsnog niet tegen problemen aan gelopen. Nu zal ik nog niet alle scenario's van vroeger geprobeerd hebben, het zoeken gaat in ieder geval weer als vanouds.

[crisp]

ACM schreef op vrijdag 14 december 2012 @ 08:16:
[...]
Ik wist eigenlijk niet dat er mensen zijn die het naast nuttig ook essentieel vonden. Dus ik laat de mogelijkheid in ieder geval bestaan zoals ie nu is en de interne ticket om te onderzoeken of we het nog op een andere manier verder terug willen brengen laat ik ook gewoon open.
Zoals gezegd: dat iets weinig gebruikt wordt is op zich geen reden het te verwijderen, het is vooral een ondersteuning als je nog meer redenen hebt (zoals: het werkt niet goed, het is veel werk om te onderhouden, het maakt de boel verwarrender voor gebruikers, e.a.)

Het is voor mij ook dé manier om bepaalde topics soms terug te zoeken; als je (een deel van) de titel nog weet kan je het zo veel sneller vinden

[Wolfboy]

Nice, werkt nu al stukken beter dan de oude search

Misschien is het overigens nog wel zinnig om accenten nog wat anders te behandelen, ik dacht... laat ik crisp z'n post eens opzoeken:

Met quotes, werkt: http://beta.gathering.twe..._message_end%5D=#hitstart
Zonder quotes, werkt maar negeert duidelijk sommige zoekwoorden: http://beta.gathering.twe..._message_end%5D=#hitstart

Zoeken op dé, 6448 resultaten: http://beta.gathering.twe..._message_end%5D=#hitstart
Zoeken op de: 0 resultaten: http://beta.gathering.twe..._message_end%5D=#hitstart

Het lijkt me dat deze laatste 2 ongeveer dezelfde resultaten zouden moeten geven.

[Anoniem: 423265]

ACM schreef op vrijdag 14 december 2012 @ 08:16:
[...]

Hmm, niet?
Waar resolved beta.gathering.tweakers.net voor jou naar (zou 213.239.154.18 moeten zijn)? En probeer je het niet (onbewust) via HTTPS? Daar hebben we geen moeite voor gedaan in de testomgeving.

Nee geen https, en hij resolved goed. Het is die 'onbekende fout'-bug waarover je al schreef in deze reactie.

Je hoefde niet per se uit te leggen in welke situaties je het gebruikt (maar het is alsnog nuttig dat te weten), maar ik was vooral benieuwd waarom je het essentieel vond

Het is gewoon een functie die, zolang ik me al kan herinneren, bestaat als de eerste optie naast het zoeken. En niet alleen in fora, maar overal waar het gebruikt kan worden (mail bv.). Als je wil zoeken naar een topic, dan is de aangewezen manier om dat te doen via de topictitel. Want die geeft nl. een omschrijving van dat topic. De reacties niet, die geven 'slechts' een aanwijzing. Natuurlijk zijn er meerdere wegen die naar Rome leiden, en je kunt van mening verschillen over de juiste. Maar voor mij is dat de topictitel. Zoeken in reacties brengt je natuurlijk ook vaak naar hetzelfde topic, maar laat ook vaak andere topics zien, waar je op dat moment verder niet in geïnteresseerd bent. En als je teveel resultaten terugkrijgt, kan het dan nog steeds moeilijk zijn om het juiste topic te vinden. Dan moet je je zoekopdracht gaan verfijnen, en dat kan in zo'n geval het beste door alleen de titel in beschouwing te nemen.

Dus in essentie: Als je een topic zoekt over een onderwerp -> Zoeken op topictitel. Zoek je informatie of reacties in het algemeen -> 'Gewone' search die alle reacties doorzoekt.

Mijn ervaring leert dat de meeste mensen vrij lui zijn icm zoekmachines, veel verder dan een of twee zoektermen komen de meeste niet.

Dan zijn die andere zoekopties dus eigenlijk ook niet nodig

En zelfs hier op GoT valt dat dus eigenlijk nog wel "tegen". Maargoed, als de zoekmachine goede resultaten aanlevert bij die enkele termen, waarom zou je dan ook meer intypen

Omdat dat nooit in beide gevallen even goed kan werken. Als ik een topic over een onderwerp zoek, dan wil ik de topictitels met m'n zoekopdracht bovenaan hebben staan. Met één universele zoekfunctie gebaseerd op relevantie gaat dat niet altijd goed. Dan komen soms topics bovenaan, waarin het woord van de zoekopdracht weliswaar vaker voorkomt, maar het topic zélf ergens anders over gaat. Soms is dat ook de bedoeling, maar in deze situatie niet. En voor die situaties is de functie 'zoeken op topictitel'.

En andersom komt ook voor: Soms wil ik juist zoveel mogelijk reacties over een onderwerp lezen, ongeacht waar het topic over gaat. In dat geval sorteer ik op relevantie of datum, maar laat uiteraard de topictitel achterwege. Die twee zoekfuncties zijn niet goed in één universele zoekopdracht te combineren zonder de mogelijkheid tot het zoeken binnen alleen de topictitels.

Beide cijfers waren uit dezelfde tijdsperiode. Het vorige logbestand is zo te zien voor het laatst aangepast op 9 december, dus gisteravond was degene waar ik de cijfers uit haalde ruim 4 dagen oud. Op zich maakt het niet zoveel uit, die interface is al jaren technisch hetzelfde en de laatste layoutwijziging is natuurlijk ook van oktober.
Wellicht dat het nog wel uitmaakt dat je het zoekformulier tegenwoordig pas ziet nadat je een zoekopdracht hebt ingevoerd. Maar we hebben helaas geen zoekmachine-logbestanden meer uit die tijd

Heb je ook de cijfers van die andere knoppen, 'AND', 'OR', '()', en 'start:', daar ben ik wel benieuwd naar

Ik wist eigenlijk niet dat er mensen zijn die het naast nuttig ook essentieel vonden. Dus ik laat de mogelijkheid in ieder geval bestaan zoals ie nu is en de interne ticket om te onderzoeken of we het nog op een andere manier verder terug willen brengen laat ik ook gewoon open.

Essentiëel is in deze situaties natuurlijk relatief. Als het moet, kan ik zonder die hele search. Als het écht moet, kan ik zonder T of GoT. En als het absoluut moet, kan ik zonder computer. Maar onder normale omstandigheden kan ik niet, of heel slecht, zonder het zoeken op titel. Zowel in fora, als in mail, news, RSS, notities, en noem maar op, overal waar de mogelijkheid is om een bondige titel in te geven. Die mogelijkheid is er om gebruikt te worden

Zoals gezegd: dat iets weinig gebruikt wordt is op zich geen reden het te verwijderen, het is vooral een ondersteuning als je nog meer redenen hebt (zoals: het werkt niet goed, het is veel werk om te onderhouden, het maakt de boel verwarrender voor gebruikers, e.a.)

Ik denk dat de reden waarom die functie *hier* zo weinig gebruikt wordt, ligt aan de onduidelijkheid van die knop. Volgens mij zal die functie (knop) veel vaker gebruikt worden, als ook duidelijker is waarvoor die knop dient. In de huidige search zie ik o.a. de knoppen 'title:' en 'start:'. Als Tweaker heb ik natuurlijk allang uitgeprobeerd wat die knoppen doen, en wanneer ze mij van pas kunnen komen. Maar de 'nieuwe' groep gebruikers waar T zich de laatste jaren steeds meer op richt, zal dat niet zo snel doen. En dan wordt die functie idd. (te) weinig gebruikt. Terwijl dat waarschijnlijk wél het geval zou zijn als die functie beter was aangegeven, want dan zouden meer gebruikers het nut meteen ervan inzien.

Ik zal een voorbeeld geven van een bekend forum waar dit wél goed is opgelost:

http://zoeken.fok.nl/zoek/?searchmode=advanced&tab=forum

Zie je het verschil met alleen 'title:' en 'start:'? Diezelfde functies op Fok laten aan duidelijkheid niets te wensen over: Zoek in titel en/of openingspost en/of reacties d.m.v. een simpel vinkje. Ondubbelzinnig te begrijpen voor zowel de gevorderde als de beginnende gebruiker. Waar jullie er (in eerste instantie) voor gekozen hebben om het maar helemaal weg te laten, omdat het te verwarrend zou zijn, hebben ze bij Fok gekozen voor duidelijkheid, zónder dat het verwarrend wordt.

Ik krijg (mede uit dat andere topic) af en toe de indruk dat hier bij het verbeteren van de site soms te snel wordt gedacht, dat iets te verwarrend is voor gebruikers, en daarom maar geheel wordt weggelaten. Maar ik vermoed toch, dat dat bij de gebruikers die hier komen wel meevalt. Het is vast niet zo dat ze meteen gedesoriënteerd zullen zijn, bij het zien van een paar extra functies boven het absolute minimum

Ook al hoeft het voor mij niet, ik kan begrijpen dat het voor sommige groepen gebruikers duidelijker is, wanneer zaken simpel worden gehouden. Maar maak het a.u.b. niet kleuter-proof: Zó simpel hoeft het, ook voor de doorsnee gebruiker, en zeker op een tech-site als deze, nou óók weer niet, als het daardoor ten koste gaat van veel functionaliteit. Want laten we eerlijk zijn: Als dit niet verwarrend is voor Fok-gebruikers, dan is dat zéker niet het geval voor GoT-gebruikers

[ScSi]

Hier met een eenvoudige query ook goede resultaten. Query was 'tweakers 7 verbetering' (zonder enkele quotes)

In de beta is het de eerste hit, in de oude search de 8ste hit.

edit; ik zocht net naar dit topic, met de trefwoorden 'test de nieuwe search' . De highlight geeft de korte trefwoorden ook weer, wat een heel onrustig beeld geeft. Ik vermoed dat het bij de oude search ook al was, maar misschien is het een idee om lidwoorden niet te highlighten?

[ Voor 44% gewijzigd door ScSi op 16-12-2012 10:57 ]

[_David_]

Pagina nummers moeten trouwens nog wat html liefde krijgen

[ACM]

Anoniem: 423265 schreef op zaterdag 15 december 2012 @ 21:27:
Nee geen https, en hij resolved goed. Het is die 'onbekende fout'-bug waarover je al schreef in deze reactie.

Nee, het is wat anders (maar het ziet er wel hetzelfde uit voor jou)... Zo te zien is dit een bugje dat in een andere svn-branch al is opgelost en morgen ook in die voor de zoekmachine komt. Dus ik zal 'm daarna weer even updaten.

Ik zal een voorbeeld geven van een bekend forum waar dit wél goed is opgelost:

http://zoeken.fok.nl/zoek/?searchmode=advanced&tab=forum

Ik had inderdaad in het interne ticket erover zoiets genoemd, domweg een lijstje met opties van welke velden doorzocht kunnen en mogen worden (titel, reactieteksten en "onderwerpen" in ons geval).

[ Voor 9% gewijzigd door ACM op 17-12-2012 11:15 ]

[_David_]

Gaat de nieuwe forum search met de iteratie van morgen mee?

[ACM]

davidaap123 schreef op maandag 17 december 2012 @ 12:10:
Gaat de nieuwe forum search met de iteratie van morgen mee?

Uit de topicstart:

ACM schreef op dinsdag 11 december 2012 @ 10:12:
Overigens is de verwachting dat het nog wel een paar iteraties duurt voor we dit helemaal in productie opzetten. Sowieso zijn er veel vakanties de komende tijd en we moeten het design van de resultaten nog beter uitwerken

Dus nee, geen idee wanneer e.e.a. wel uitgewerkt is. Dit jaar zal dat in ieder geval niet meer gebeuren

[Anoniem: 423265]

ACM schreef op maandag 17 december 2012 @ 09:00:
[...]

Nee, het is wat anders (maar het ziet er wel hetzelfde uit voor jou)... Zo te zien is dit een bugje dat in een andere svn-branch al is opgelost en morgen ook in die voor de zoekmachine komt. Dus ik zal 'm daarna weer even updaten.

[...]

Het lag waarschijnlijk aan mij, ik had 't getest met Firefox 13.0.1. Met 17.0.1 (en IE8) doet ie 't prima.

// behalve dan dat de ''AND 'OR' en '()' knoppen niet werken (maar die mochten wat mij betreft toch al weg, juist dát gaat handmatig sneller ).


Verder ben ik zo te zien wel blij met de nieuwe search. Vooral dat het zoeken nu op reactie-basis gebeurt is een hele verbetering.


Ik begrijp verder dat je ook rechtstreeks query's kunt intikken, zoals dus 'name:' om op topictitel te zoeken. Heb je misschien ook een overzicht van de velden waarop je nu kan zoeken? Ik denk dat ik daar helemaal bij mee ga zijn

[ACM]

Anoniem: 423265 schreef op maandag 17 december 2012 @ 22:45:
Ik begrijp verder dat je ook rechtstreeks query's kunt intikken, zoals dus 'name:' om op topictitel te zoeken. Heb je misschien ook een overzicht van de velden waarop je nu kan zoeken? Ik denk dat ik daar helemaal bij mee ga zijn

Ok, dat zijn (momenteel) 'name' voor de titel, 'altname' voor "onderwerpen" (dus tag, product, merk, e.a.) en 'text' voor reactieteksten. De topicstart is ook een reactietekst en dus (nu iig) niet los beschikbaar.

[Gleighton]

Is het trouwens een idee om topicreeksen bijeen te vouwen? Als ik bijvoorbeeld op World of tanks zoek (waarbij er zo'n 27 delen van zijn), krijg ik ze alle 27 te zien. Ook zou ik verwachten dat het laatste deel (welke niet gesloten is) boven aan zou staan, maar dat is niet het geval.

Verder, netjes en keep up the good work

[Freeaqingme]

Als ik zoek op relevantie, worden recentere resultaten dan ook een zwaardere weging gegeven?

Overigens, begrijp ik dat hier wel Lucene gebruikt is, maar geen Solr? Als dat het geval is ben ik benieuwd naar de afweging (ik wil 'm niet in twijfel trekken, ben gewoon benieuwd naar de overwegingen).

[ACM]

Freeaqingme schreef op dinsdag 18 december 2012 @ 23:07:
Als ik zoek op relevantie, worden recentere resultaten dan ook een zwaardere weging gegeven?

Ja, zie topicstart voor wat er allemaal meetelt in de relevantie.

Overigens, begrijp ik dat hier wel Lucene gebruikt is, maar geen Solr? Als dat het geval is ben ik benieuwd naar de afweging (ik wil 'm niet in twijfel trekken, ben gewoon benieuwd naar de overwegingen).

Zie dit verhaal: reviews: Tweakers 7: waarom een eigen Java-back-end?

[Outerspace]

Een ander aandachtspunt:
Als je meerdere zoekresultaten hebt in een topic, dan worden er netjes 3 reacties met het trefwoord getoond. De 1e reactie staat in een 'blok' met iets teveel ruimte (hoogte), deze mag van mijn part gelijk staan met die van de 2e reactie.

De onderste horizonal reference mag er ook wel uit.

[ACM]

Outerspace schreef op woensdag 19 december 2012 @ 10:00:
Een ander aandachtspunt:
Als je meerdere zoekresultaten hebt in een topic, dan worden er netjes 3 reacties met het trefwoord getoond. De 1e reactie staat in een 'blok' met iets teveel ruimte (hoogte), deze mag van mijn part gelijk staan met die van de 2e reactie.

De onderste horizonal reference mag er ook wel uit.
[afbeelding]

Hoewel ik je input waardeer is deze test niet echt bedoeld voor de presentatie van de resultaten

[Outerspace]

ACM schreef op woensdag 19 december 2012 @ 10:03:
[...]

Hoewel ik je input waardeer is deze test niet echt bedoeld voor de presentatie van de resultaten

Maar als er andere aandachtspunten zijn, dan horen we dat natuurlijk ook graag

U vraagt, ik draai
Ik ga op bughunt voor je

[ACM]

Outerspace schreef op woensdag 19 december 2012 @ 10:14:
U vraagt, ik draai

Maar deze wist ik dan toevallig al (en als we dan toch aan het quoten zijn)

Overigens is de verwachting dat het nog wel een paar iteraties duurt ... en we moeten het design van de resultaten nog beter uitwerken

Ik ga op bughunt voor je

Ik ben benieuwd

[ Voor 9% gewijzigd door ACM op 19-12-2012 10:47 ]

[Raven]

Ik dacht, yay, een nieuwe zoekmachine. Dus gelijk even iets geprobeerd, werkt niet

Wat ik mis is de mogelijkheid om specifiek te zoeken naar berichten met plaatjes erin. Ik gebruik dan als zoekterm [img]. De [ en ] doet de zoekmachine zo te zien niks mee maar de img in [img]-tags wordt niet als resultaat gezien. Wel als [img] niet gebruikt wordt voor afbeeldingen (bijv. geen sluiten tag aanwezig) of wanneer het tussen [code]-tags staat.

[ACM]

Raven schreef op woensdag 19 december 2012 @ 13:54:
Ik dacht, yay, een nieuwe zoekmachine. Dus gelijk even iets geprobeerd, werkt niet

Wat ik mis is de mogelijkheid om specifiek te zoeken naar berichten met plaatjes erin. Ik gebruik dan als zoekterm [img]. De [ en ] doet de zoekmachine zo te zien niks mee maar de img in [img]-tags wordt niet als resultaat gezien. Wel als [img] niet gebruikt wordt voor afbeeldingen (bijv. geen sluiten tag aanwezig) of wanneer het tussen [code]-tags staat.

Opmaaktaal wordt doorgaans verwijderd voor dat tekst geindexeerd wordt... En dat geldt ook voor onze zoekmachine. 't Zal in de praktijk ook meestal tegen je werken als je het wel indexeert omdat de meesten het geen inhoud van de lopende tekst zullen vinden.

[GlowMouse]

'Sorteer op' lijkt niets te doen. Dit en dit levert bijvoorbeeld exact dezelfde sorteervolgorde op.

[ACM]

GlowMouse schreef op maandag 31 december 2012 @ 15:13:
'Sorteer op' lijkt niets te doen. Dit en dit levert bijvoorbeeld exact dezelfde sorteervolgorde op.

Het lijkt erop dat je effectief maar twee opties hebt zo ja, 'relevantie' en 'datum reactie, nieuwste eerst'... dat is niet heel zinvol met 5 verschillende keuzeopties

[Megamind]

Ik zocht het topic "Wie is de mol" 2013 versie, search staat standaard ingesteld, dus op "Datum laatste reactie" en alsnog komt 2012 bovenaan, daarna 2010, daarna 2011 en dan pas 2013.

Wie is.. de Mol? 2013
http://gathering.tweakers...q]=wie+is+de+mol#hitstart

edit: zie net dat de zoekoptie nog op Relevantie staat, eronder staat direct "datum laatste reactie", niet goed gelezen.

[ Voor 14% gewijzigd door Megamind op 04-01-2013 12:32 ]

[ACM]

Megamind schreef op vrijdag 04 januari 2013 @ 12:31:
Ik zocht het topic "Wie is de mol" 2013 versie, search staat standaard ingesteld, dus op "Datum laatste reactie" en alsnog komt 2012 bovenaan, daarna 2010, daarna 2011 en dan pas 2013.

Wie is.. de Mol? 2013
http://gathering.tweakers...q]=wie+is+de+mol#hitstart

Dit topic gaat dan ook over de nieuwe zoekmachine, niet de oude

Maar zo te zien gaat de nieuwe wel goed. Daar staat je topic uit 2013 bovenaan en daarna die van 2012. Daaronder wordt het wat warriger, maar ik vermoed dat 'wie' en 'is' als stopwoorden geschrapt worden dus dat er effectief alleen op 'mol' wordt gezocht.

[marcop23]

Ik denk eigenlijk dat is best wel een grote bug heb gevonden? Ik weet niet of hij al gepost is, want dat kan ik dus niet bekijken

Zie hier: Test de nieuwe beta-Forumsearch!



Zoals je ziet is de tekst in de form ook niet echt mooi uitgelijnd, maar dat kan ook door het layoutverpestende debugding komen, zie ik nu.

Tweede bugje, denk ik: [Ervaringen] TP-Link TL-WR1043ND
Waarom heeft dat topic geen last knop, met die zoekstring in de url? Hierdoor kwam ik dus op die andere bug

Ik ga trouwens steeds eerst naar beta.gathering.tweakers.net als ik iets wil vinden, als je op WR1043ND zoekt staat het WR1043ND topic zomaar bovenaan in plaats van ergers op de derde pagina

[ Voor 15% gewijzigd door marcop23 op 10-01-2013 17:20 ]

[ACM]

marcop23 schreef op donderdag 10 januari 2013 @ 17:13:
Ik denk eigenlijk dat is best wel een grote bug heb gevonden? Ik weet niet of hij al gepost is, want dat kan ik dus niet bekijken

't Is me niet helemaal duidelijk wat je op welke manier hebt veroorzaakt? De linkjes die je hier geeft kan ik prima aanklikken zonder enige foutmelding.

[marcop23]

Tja, ik heb eigenlijk geen idee hoe het kan dat ik het nu niet meer heb. Ik zocht gewoon op het woord last, en toen kreeg ik die error. Ik maakte een mooi screenshot, ik begon met posten en toen ik in het voorbeeldvenster op mijn linkje klikte kreeg ik hem nog een keer, dus ging ik er vanuit dat het altijd zo was. Ik heb eigenlijk ook niet de hele connection ergens opgeslagen.

Staat op deze testserver de error logging niet aan? Hebben jullie niets aan die error in het screenshot?

En dat er geen 'last' pagina is als je de zoekmachine er op af stuurt, is dat by design?

[marcop23]

Ik heb het net weer gereproduceerd:



De request is hier te vinden: http://4pb.nl/troep/tnetbug2.txt

Het enige wat ik heb gedaan, is naar een topic gaan waar volgens mij geen last in voorkomt, en dan naar last zoeken.

Ik hoop dat het nu wel lukt!

Edit: Elke zoekterm die niets oplevert, geeft hier een error: http://beta.gathering.twe...oep&data%5Bboolean%5D=AND

[ Voor 22% gewijzigd door marcop23 op 11-01-2013 16:11 ]

[Nakebod]

In hoeverre is het mogelijk om, als je zoekt op een specifiek product, de grote/ervaringentopics (/reeks) voorrang te geven in de zoekresultaten?
Danwel, hoe wenselijk zou het zijn? Als je puur naar een product zoekt, dus geen zoekopdracht zoals "probleem x met product y", kan ik mij voorstellen dat je niet geïnteresseerd bent in problemen topics, maar wel in het ervaringentopic.

Voorbeeldje: zoekopdracht naar DS213, of Synology DS213. Het laatste topics uit de topicreeks, Het grote Synology topic - deel 5 staat 10e/6e in de zoekresultaten.

[Anoniem: 423265]

'groot', 'grote' of 'ervaringen' als zoekopdracht meegeven


// en zoeken op titel

[ Voor 27% gewijzigd door Anoniem: 423265 op 11-01-2013 18:55 ]

[ACM]

Nakebod schreef op vrijdag 11 januari 2013 @ 08:23:
In hoeverre is het mogelijk om, als je zoekt op een specifiek product, de grote/ervaringentopics (/reeks) voorrang te geven in de zoekresultaten?

Ik denk niet dat dat heel erg praktisch mogelijk te maken is. Bij al dat soort voorrangs-dingen is het maar de vraag of het resultaat ook echt is wat je wilt en bij welke situaties het dan weer tegen je werkt. Er is sowieso geen kennis van of iets 'het grote topic' over iets is, of dat de term toevallig voorkomt. Ik gok dat bijvoorbeeld

Normaliter krijgen grote topics veel views en reacties, waardoor ze steeds actueel blijven en dus automatisch meer kans maken bovenaan te verschijnen. Maar zeker bij de wat meer algemenere grote topics is het helemaal niet zo ongebruikelijk dat de termen waar je op zoekt nauwelijks in het topic voorkomen, omdat alle deelnemers aan de discussie wel weten waar het over gaat... Dus technisch is het heel lastig er wat nuttigs mee te doen

[Anoniem: 423265]

Vandaar het belang van die titelsearch

Maar wat ik overigens in sommige gevallen ook wel fijn zou vinden, is als je kunt filteren of sorteren op aantal reacties. Op die manier kun je populaire topics ook vaak vinden. Zou het mogelijk zijn om die optie in te bouwen, of om dat veld ook beschikbaar te maken voor directe queries via de URL?

[ACM]

Ik heb zojuist trouwens nieuwe code deployed met o.a. een veel vergevingsgezindere queryparser (een port van 'edismax' van Solr). Dus hopelijk krijg je nu nog vaker en betere resultaten

Aan het gedrag is verder niet enorm veel verandert, dus de resultaten zullen niet heel veel anders zijn.

[Compizfox]

Misschien is het al eerder gepost, maar waar ik me sinds Tweakers 7 enorm aan erger is dat je geen quotes kan plaatsen in een query.

code:

"ik henk hem"

wordt

code:

"ik henk hem"

En alle posts met ik || henk || hem komen voorbij.

[ Voor 5% gewijzigd door Compizfox op 11-01-2013 19:38 ]

[ACM]

Waar precies? Want de forumsearch is nog niet eens verandert sinds Tweakers 7... En ik zie geen verschil tussen wat je eerst plaatst en wat het daarna zou worden. Ah zonder html-entities wordt het duidelijker idd

[ Voor 14% gewijzigd door ACM op 11-01-2013 19:42 ]

[Compizfox]

Sorry, dat ging over de in-topic search.

[ACM]

Ah, maar quotes hebben nooit gewerkt bij in-topicsearch. Dat ze html-encoded weergegeven worden in het zoekveld is wat dat betreft het enige verschil sinds Tweakers 7.

Met de hier genoemde nieuwe in-topicsearch werken quotes wel (hoewel die weergave bug er nog steeds in zit zo te zien).

[marcop23]

@ACM
Kan je die bug die ik heb gevonden nu wel reproduceren?
Ik kan hem zo tevoorschijn halen, dus als je meer details wil weten, moet je het zeggen
Of zijn jullie er al mee bezig?

[ACM]

marcop23 schreef op zaterdag 12 januari 2013 @ 09:41:
Kan je die bug die ik heb gevonden nu wel reproduceren?

Yep, ik zet 'm op de todo-lijst

[DarkShadow16]

Tijdens het zoeken gebeurt er iets vreemds met de avatar van iemand. Die wordt veel te groot weergegeven.
http://beta.gathering.twe..._message_end%5D=#hitstart

Open het eerste topic: http://beta.gathering.twe...rum/list_messages/1522370

De avatar van SoeperKees is nu veel te groot.

Ik wist niet of dat dit nu aan de nieuwe search zou liggen of aan iets anders dus heb hem hier maar gepost.

[Kees]

DarkShadow16 schreef op vrijdag 15 februari 2013 @ 14:53:
Tijdens het zoeken gebeurt er iets vreemds met de avatar van iemand. Die wordt veel te groot weergegeven.
http://beta.gathering.twe..._message_end%5D=#hitstart

Open het eerste topic: http://beta.gathering.twe...rum/list_messages/1522370

De avatar van SoeperKees is nu veel te groot.

Ik wist niet of dat dit nu aan de nieuwe search zou liggen of aan iets anders dus heb hem hier maar gepost.

Nee, dat is iets anders, maar een code update heeft dat weer gefixt

[Xesxen]

Ik zoek dus op htc one x+, krijg ik dit:

code:

Uncaught Exception: Data downloads timed out or no host configured, with reason: Unknown reason for exception

In file: /mnt/web/tweakers/inc/class/engine/AbstractRestDownloader.php:186

    #0 /mnt/web/tweakers/inc/class/content/manager/AbstractContentFilter.php(43): engine\AbstractRestDownloader->download()
    #1 /mnt/web/tweakers/forum/global/non-www/classes/search.class.inc.php(216): content\manager\AbstractContentFilter->generateItems()
    #2 /mnt/web/tweakers/forum/global/non-www/classes/engine.class.inc.php(1335): search->find(Array, Array)
    #3 /mnt/web/tweakers/forum/global/non-www/init/forum.init.php(127): engine->parse()
    #4 /mnt/web/tweakers/forum/board/www/forum.php(22): require('/mnt/web/tweake...')
    #5 {main}

Url: http://beta.gathering.twe...st_message_end]=#hitstart
Ik krijg het alleen niet gereproduceerd nu...

[Joolee]

Ik krijg een prachtige MySQL error als ik een linkje op pagina 1 van dit topic aanklik.
http://beta.gathering.twe...essage_end]=&data[page]=3

Error:

code:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND !topic.Deleted AND !forum.Deleted' at line 44

Query: SELECT topic.Name as topic_name, topic.TopicID as topic_id, topic.Viewcount as topic_viewcount, topic.Date as topic_timestamp, topic.TopicaliasID as topic_alias_id, if (topic.TopicaliasID > 0,1,0) as topic_is_alias, FROM_UNIXTIME(topic.Lastmessage,'%d-%m-%Y %H:%i') as topic_lastmessage_date, FROM_UNIXTIME(topic.Date,'%d-%m-%Y %H:%i') as topic_date, topic.Lastmessage as topic_lastmessage_timestamp, topic.LastmessageID as topic_lastmessage_id, topic.FirstmessageID as topic_firstmessage_id, topic.Lastmodified as topic_lastmodified_timestamp, topic.Status+0 as topic_status_id, topic.Status as topic_status, topic.Messagecount as topic_messagecount, topic.Messagecount-'1' as topic_replycount, topic.ForumID as topic_forum_id, CEILING((topic.Messagecount)/50) as topic_pagecount, if (topic.Status='Closed',1,0) as topic_is_closed, topic.UserID as topic_starter_id, topic.LastposterID as topic_lastposter_id, if (topic.Lastmessage > 1361284974,1,0) as topic_has_new, topic.Data as topic_data, concat('http://beta.gathering.tweakers.net/forum/list_messages/',if (topic.TopicaliasID > 0,topic.TopicaliasID,topic.TopicID)) as topic_listmessageslink, concat('http://beta.gathering.tweakers.net/forum/list_messages/',if (topic.TopicaliasID > 0,topic.TopicaliasID,topic.TopicID),'/////1361284974') as topic_listmessages_resumelink, concat('http://beta.gathering.tweakers.net/forum/list_message/',topic.LastmessageID,'#',topic.LastmessageID) as topic_lastmessage_link, if (topic.TopicaliasID > 0,'',concat('http://beta.gathering.tweakers.net/forum/insert_bookmark/',topic.TopicID)) as topic_insertbookmark_link, forum.ForumID as topic_forum_id, forum.Name as topic_forum_name, forum.Messagecount as topic_forum_messagecount, forum.Topiccount as topic_forum_topiccount, forum.CategoryID as topic_forum_category_id, forum.Days as topic_forum_days, forum.Mintopics as topic_forum_mintopics, forum.Admins as topic_forum_admins, forum.Lastmodified as topic_forum_lastmodified_timestamp, forum.Lastmessage as topic_forum_lastmessage_timestamp, if (forum.Lastmessage > 1361284974,1,0) as topic_forum_has_new, forum.SkipRights as topic_forum_skip_rights, concat('http://beta.gathering.tweakers.net/forum/list_topics/',forum.ForumID) as topic_forum_link, forum.Description as topic_forum_description, forum.DescriptionRaw as topic_forum_description_raw, forum.Version as topic_forum_version, forum.Abbr as topic_forum_abbr, forum.Data as topic_forum_data, forum.Topictypesmustappear as topic_forum_topictypesmustappear, forum.Ordertopicsdateby as topic_forum_ordertopicsdateby, forum.Ordertopicstypeby as topic_forum_ordertopicstypeby, forum.Type as topic_forum_type, user.UserID as topic_starter_id, user.Title as topic_starter_title, user.Status as topic_starter_status, user.Nickname as topic_starter_nickname, concat('http://tweakers.net/gallery/',user.UserID) as topic_starter_profilelink, concat('http://beta.gathering.tweakers.net/forum/myreact/',user.UserID) as topic_starter_myreactlink, lastPoster.UserID as topic_lastposter_id, lastPoster.Title as topic_lastposter_title, lastPoster.Status as topic_lastposter_status, lastPoster.Nickname as topic_lastposter_nickname, concat('http://tweakers.net/gallery/',lastPoster.UserID) as topic_lastposter_profilelink, concat('http://beta.gathering.tweakers.net/forum/myreact/',lastPoster.UserID) as topic_lastposter_myreactlink FROM F_Topics topic JOIN F_Forums forum ON forum.ForumID = topic.ForumID JOIN F_Users user ON user.UserID = topic.UserID LEFT JOIN F_Users AS lastPoster ON lastPoster.UserID = topic.LastposterID WHERE topic.TopicID IN () AND !topic.Deleted AND !forum.Deleted

Als ik vervolgens rechtsboven in de melding op Instellingen klik kan ik niet het meldingstype "MySQL Error" uitschakelen

Er zijn overigens wel 12 topics gevonden maar die worden niet weergegeven.

[Hooglander1]

Is de beta-search offline gehaald?

Fout 324 (net::ERR_EMPTY_RESPONSE): De server heeft de verbinding verbroken zonder gegevens te verzenden.

* Hooglander1 mist hem.

[Kees]

Hooglander1 schreef op zaterdag 23 februari 2013 @ 10:58:
Is de beta-search offline gehaald?


[...]


* Hooglander1 mist hem.

Nee, hij was uit zichzelf stuk gegaan en stond heel hard Segmentation faults te gooien. Apache even gerestart en hij doet het weer

[ACM]

Joolee schreef op dinsdag 19 februari 2013 @ 17:28:
Ik krijg een prachtige MySQL error als ik een linkje op pagina 1 van dit topic aanklik.
http://beta.gathering.twe...essage_end]=&data[page]=3

Dat zal vast komen omdat er geen derde pagina meer is bij die zoekopdracht... Maar de error is inderdaad niet enorm netjes.