[Search] extra automatische sortering?

[Snowwie]

Zou het misschien mogelijk zijn om in de search gelijk een automatische sortering op datum te laten plaatsvinden?

Als je de search gewoon gebruikt, dus aanklikken en zoeken maar, dan zoekt de search eerst op relevantie, dus krijg je regelmatig topics uit 2000 of 2001.

Om de search toch gewoon handig beschikbaar te houden zou een automatische topicdatum sortering niet handig zijn? Ik wil gewoon op die search klikken en zonder allerlei poespas gelijk resultaat zien.

want:
- je voorkomt dat users gaan reageren in oude topics
- users kunnen wat sneller actuelere gegevens vinden en zullen minder snel een nieuw topic openen

[Verwijderd]

Maak er dan meteen een pref van, ik kan me zo voorstellen dat relevantie meer gewenst is dan datum topicstart.

[Remy]

Geen Lieve Adjes dit, op naar BUG ermee \o/

[F_J_K]

Ik zou het inderdaad ook handig vinden als pref (ik zou het zelf aanzetten nu de DB al een paar jaar bestaat). Niet dat topics uit 2001 niet relevant zijn, maar vaak toch net niet voor het probleem dat ik zelf heb (of de zoektermen die ik gebruik).

_{Dit maakt het dan wel een topic voor in React Bugs en Featurerequests}

edit:

/me schopt Remy

[ Voor 5% gewijzigd door F_J_K op 25-10-2004 13:06 ]

[Osiris]

Zoeken op relevantie geeft je denk ik meer kans op een correct antwoord, dus lijkt me het logisch dat die standaard is

Een pref zou voor diegene die dat willen natuurlijk wel handig kunnen zijn.

[crisp]

* crisp gebruikt regelmatig de "zoek in tijdsperiode" optie. Die is juist bedoelt voor als je alleen geinteresseerd bent in bijvoorbeeld recente topics...

[Snowwie]

Relevantie zou ook de 1e optie blijven, maar topicdatum als tweede (automatisch ingebakken) functie, waarbij de meest recentste topic bovenaan staat.

[Osiris]

Hoe bedoel je in vredesnaam én relevantie (als 1e optie) én topicdatum? Als je eenmaal op het ene sorteert kun je toch niet meer op 't andere sorteren?

[Verwijderd]

Osiris schreef op 25 oktober 2004 @ 13:20:
Hoe bedoel je in vredesnaam én relevantie (als 1e optie) én topicdatum? Als je eenmaal op het ene sorteert kun je toch niet meer op 't andere sorteren?

Dat wordt ook helemaal niet beweerd.

[Osiris]

Verwijderd schreef op 25 oktober 2004 @ 13:22:
[...]

Dat wordt ook helemaal niet beweerd.

Weet jij wat ie wél beweert dan? Ik kan er dan namelijk geen wijs uit maken, aangezien hij het heeft over een automatisch ingebakken functie

[Snowwie]

Osiris schreef op 25 oktober 2004 @ 13:20:
Hoe bedoel je in vredesnaam én relevantie (als 1e optie) én topicdatum? Als je eenmaal op het ene sorteert kun je toch niet meer op 't andere sorteren?

Waarom zou zoiets niet kunnen?

[ACM]

Omdat ze met elkaar in tegenspraak zijn. Relevantie is een glijdende schaal, waardoor er geen "stapjes" zijn waarbinnen je weer anders kan sorteren.

Ik geloof dat het mogelijk is om binnen omega "sortbands" te gebruiken, maar daar heb ik nog nooit naar gekeken. Dus ik weet niet hoe die precies werken:

SORTBANDS

reorder results by the specified sort key within this many equal width bands of percentage relevance. So if this is 5, the bands are 100-80, 80-60, 60-40, 40-20, and 20-0.

Maar dat is verder de enige mogelijkheid om "meerdere sorteringen te hebben".

[ Voor 9% gewijzigd door ACM op 25-10-2004 13:41 ]

[Osiris]

Snowwie schreef op 25 oktober 2004 @ 13:32:
[...]

Waarom zou zoiets niet kunnen?

Voorbeeldje: Stel ik heb ACDEBHGF en die sorteer ik eerst op alfabetisch van A-Z en daarna van Z-A.. Dan krijg ik dus eerst ABCDEFGH en vervolgens sorteer ik ze weer van Z naar A en dan krijg ik HGFEDCBA.. Huh? Waar is nu mn van A naar Z sortering gebleven? Ja, die's weg uiteraard

[Snowwie]

Osiris schreef op 25 oktober 2004 @ 14:31:
[...]

Voorbeeldje: Stel ik heb ACDEBHGF en die sorteer ik eerst op alfabetisch van A-Z en daarna van Z-A.. Dan krijg ik dus eerst ABCDEFGH en vervolgens sorteer ik ze weer van Z naar A en dan krijg ik HGFEDCBA.. Huh? Waar is nu mn van A naar Z sortering gebleven? Ja, die's weg uiteraard

Er hoeft bij relevantie ook geen 'sortering' plaats te vinden toch, alleen maar een selectie, een selectie van relevante onderwerpen binnen een bepaald tijdskader.

<if topicstart="zwarte gaten" and "if topicdate>1-1-2002"> then show..

[ Voor 9% gewijzigd door Snowwie op 25-10-2004 14:57 ]

[Osiris]

Moah, je hebt het zelf over extra sortering etc. Verder zou dat misschien wel een interessante mogelijkheid zijn "Toon alleen topics met een relevantie groter dan X" ofzo

[Harm]

Snowwie schreef op 25 oktober 2004 @ 14:56:
[...]


Er hoeft bij relevantie ook geen 'sortering' plaats te vinden toch, alleen maar een selectie, een selectie van relevante onderwerpen binnen een bepaald tijdskader.

<if topicstart="zwarte gaten" and "if topicdate>1-1-2002"> then show..

Dat kan je toch al? Je kunt met de optie 'Zoek in tijdsperiode' een tijdsperiode opgeven waarin je wil zoeken. Dan zoek je dus zowel op relevantie als binnen een tijdsperiode. Volgens mij wat jij hierboven beschrijft .

[JHS]

Wat misschien makkelijk zou zijn om een pref in te bouwen die altijd na datum x zoekt... "Men" wil oude topics niet meer in hun searchresultaten terugzien, maar om nou iedere keer de vakjes die crisp aangeeft in te vullen... ('de "zoek in tijdsperiode" optie'). Dan zou een pref om die dingen automatisch van datum x - nu in te vullen misschien wel handig zijn .

[Snowwie]

Mwah, zoiets ja

[chem]

ACM schreef op 25 oktober 2004 @ 13:40:
Omdat ze met elkaar in tegenspraak zijn. Relevantie is een glijdende schaal, waardoor er geen "stapjes" zijn waarbinnen je weer anders kan sorteren.

Ik geloof dat het mogelijk is om binnen omega "sortbands" te gebruiken, maar daar heb ik nog nooit naar gekeken. Dus ik weet niet hoe die precies werken:

SORTBANDS

reorder results by the specified sort key within this many equal width bands of percentage relevance. So if this is 5, the bands are 100-80, 80-60, 60-40, 40-20, and 20-0.

Maar dat is verder de enige mogelijkheid om "meerdere sorteringen te hebben".

Mjah, het zou nuttiger zijn als je zelf de bands mag bepalen, bv 0-80 en 80-100. Anders heeft sub-sorteren geen nut.

Anyways, technisch gezien kan het op zich wel, maar betwijfel ik of het nuttig is, en of je het duidelijk kan maken aan de gebruikers.

[ThaHandy]

* ThaHandy denkt terug*
volgens mij was dat in "ergens" 2001 wel goed.
deed je een search, vinkje aflopend dacht ik en dan boven aan de nieuwe topic's onderaan de oudere
dit is weg sins react tot de dag vandaan nog

[moto-moi]

Die search zoog, geloof me, die willen we hier niet meer hebben, want dan kun je gewoon effectief niet meer zoeken omdat alles timeout enzo
Dat is juist de reden dat we omega ( \o/ ) gebruiken sinds React, en deze heeft een andere manier van werken, zoals ACM hierboven al uitlegd

[djluc]

Een pref waarmee je standaard de instelling die crisp aanhaalde kan instellen lijkt me nuttiger:

crisp schreef op maandag 25 oktober 2004 @ 13:17:
* crisp gebruikt regelmatig de "zoek in tijdsperiode" optie. Die is juist bedoelt voor als je alleen geinteresseerd bent in bijvoorbeeld recente topics...

[ACM]

ThaHandy schreef op vrijdag 12 november 2004 @ 15:50:
* ThaHandy denkt terug*
volgens mij was dat in "ergens" 2001 wel goed.
deed je een search, vinkje aflopend dacht ik en dan boven aan de nieuwe topic's onderaan de oudere
dit is weg sins react tot de dag vandaan nog

Vreemd...
De volgende sorteermogelijkheden bestaan:

• Relevantie
• Datum topicstart
• Datum topicstart (omgekeerd)
• Datum laatste reactie
• Datum laatste reactie (omgekeerd)

Daar kan je toch echt nieuwe topics bovenaan en oudere onderaan laten zetten... Of bedoel jij wat anders dan "datum topicstart"-sortering (of "datum laatste reactie").

[ Voor 4% gewijzigd door ACM op 12-11-2004 21:29 ]

[crisp]

zit er dus al in