Verbeteren zoekresultaten

hannekevanderhorst commented 2 years ago

Dit was: Als KCM wil ik mijn eerdere zoekopdrachten terugzien

Toelichting

Als klantcontactmedewerker wil ik mijn eerdere zoekopdrachten terugzien en opnieuw kunnen uitvoeren, zodat ik bij terugkerende vragen snel de juiste informatie vind.

Omdat uit de gebruikersgroep volgde dat er niet veel behoefte lijkt te zijn voor dit issue, gaan we indeze in eerste instantie de kwaliteit van de resultaten verbeteren. Dus verbeteren (inzicht in) ondersteuning vanf:

synoniemen,
- typfouten en
- relevantie kunnen aangeven bij specifieke velden.

LET OP

LET OP LET OP LET OP LET OP LET OP LET OP LET OP LET OP LET OP LET OP eerst uitzoeken in hoeverre dit ondersteund wordt door elastic search en wat de impact is:

synoniemen,
- typfouten en
- relevantie kunnen aangeven bij specifieke velden. daarna overleggen over wat de gewenste oplossing is voor deze story. dus nog niets implementeren

Functionele teststappen

Taken Conduction

[x] SearchHistory object uitwerken (modeleren)
[x] SerachHistory object beschickbaar stellen in gateway

Taken ICATT

[x] bestuderen mogelijkheden precision en relevance tuning (zie ook comment)
[x] bestuderen inregeling voor de crawler (zie ook comment)
[x] testen met Relevance tuning (bij voorkeur met wat meer kennisartikelen erin)
[x] Crawling verbeteren met behulp van de LOGS: om dit te kunnen doen moeten we de Crawllogs instellen sytske afstemmen met pascal
[x] De Engine moet opnieuw opgezet worden, maar nu met de Taalinstelling NEDERLANDS. Die moeten we opnieuw vullen met de Elastic api-object-documenten (Smoelenboek en Kennisartikelen), en met een crawl van deventer.nl
[x] https://www.elastic.co/guide/en/elasticsearch/reference/8.4/analysis.html bestuderen

Taken DIMPACT

[ ] ...
[ ] ...

Tijdinschatting

Conduction
ICATT

Discussie

[ ] type hekje om te linken

Elastick search bevragingen lopen op dit moment via de gateway op een proxy. We kunnen hier een subscriber op zetten om bij iedere zoekopdracht een "search history" object aan te maken voor die gebruiker.

rubenvdlinde commented 2 years ago

Willen we deze in de bl opslaan of is in de sessie goed genoeg?

hannekevanderhorst commented 2 years ago

vragen aan gebruikersgroep

Is het voldoende om een lijst met eerdere zoekopdrachten te tonen?
Zoja hoe moeten die gesorteerd zijn? En hoe lang moet die zijn: alles, of alleen de laatste 10 (of 20, of 50, of …) Voor het ‘snel terugkerende vragen kunnen beantwoorden’ vroegen wij ons af of alleen een lijst met eerdere zoekopdrachten, met de meest recente bovenaan, wel voldoende is.
Wordt deze wens ook gedekt door een auto-complete op basis van eerdere zoekopdrachten? (is dat wellicht overlap met #153)

Antwoord 14/07/2022 Er lijkt weinig behoefte te zijn aan deze feature.

Als we hem wel oppakken lijkt de optie 'autocomplete obv eerdere zoekopdrachten' de meest zinvolle. Maar dat zal waarschijnlijk een feature van de searchengine zelf zijn.
Als de searchengine de volgende aspecten ondersteund, vervalt waarschijnlijk de noodzaak van deze story:
- synoniemen,
- typfouten en
- relevantie kunnen aangeven bij specifieke velden.

Uit userstories KISS gebruikersgroep 22-3-22 Als klantcontactmedewerker wil ik mijn eerdere zoekopdrachten terugzien en opnieuw kunnen uitvoeren, zodat ik bij terugkerende vragen snel de juiste informatie vind.

rubenvdlinde commented 2 years ago

Search object is toegevoegd aan #134

sytskevanhasselt commented 2 years ago

Willen we deze in de bl opslaan of is in de sessie goed genoeg?

@rubenvdlinde , wat is bl?

PascalIcatt commented 2 years ago

Dit moet persistent worden, niet in de sessie.

PascalIcatt commented 2 years ago

Graag de story verder uitwerken, hoe moeten dit implementeren? Graag design verder uitwerken

PascalIcatt commented 2 years ago

mogelijke oplossingsrichtingen:

autocomplete obv eerdere zoekopdrachten,
bookmarken van searches
zoekgeschiedenis zoals in de browser
eenvoudiger history: altijd alleen de laatste x aantal opdrachten tonen
.... of iets anders??

WilcoLouwerse commented 2 years ago

Er is een search object toegevoegd aan de gateway die er zo uit ziet: https://conduction.stoplight.io/docs/huwelijksplanner/0b6b6b6cf41e1-search

Ook terug te vinden in de Redoc van de gateway: https://redocly.github.io/redoc/?nocors&url=https://kissdevelopment-dimpact.commonground.nu/openapi.json#tag/Search/operation/Search_postId

rubenvdlinde commented 2 years ago

Bovenstaande search object vangt de scenario's van @PascalIcatt in ieder geval technisch af. Dus wat dat betreft is die afgerond voor de backend.

Wel is deze volgenmij onHold en aan een eventueele refactor onderhevig naar gelang de keuze voor een zoek oplossing

rubenvdlinde commented 2 years ago

Ik heb deze even onhold gezet omdat die mijn inziens geblokeerd wordt door de opvolging van elasticSearch

mstokericatt commented 2 years ago

@hannekevanderhorst wil je naar de prioriteit van deze kijken. zie opkermingen in de story zelf

hannekevanderhorst commented 2 years ago

Mee eens dat dit geen hoge prio heeft kan naar achteren

rubenvdlinde commented 2 years ago

Er is reeds een searchobject uitgewerkt, het enige wat er nog moet gebeuren is dat die wordt gevuld. Technische oplossing hiervoor is de Actie -> Functie event route zo als we die ook gebruiken binnen plugin structuur. Dat maakt de stappen

Actie die afgaat op GETS op het elastic search endpoint
Deze actie moet aan de hand van een FUnctie (Mag een algemene functie zijn) een nieuw search object aanmaken en de elastic response hierheen mappen

PascalIcatt commented 2 years ago

ter info: voor autosuggestie heeft elastic hier ook endpoints voor

rubenvdlinde commented 2 years ago

Ow fair, dat was waar ook. Zijn die uitgebreid genoeg voor wat we hier willen hebben aan functionaliteit? En moet het gebonden zijn aan gebruikers? @sytskevanhasselt

sytskevanhasselt commented 2 years ago

Als ik userstory lees: ja, dan moet het gekoppeld zijn aan gebruikers.

MAAR: gebruikersgroep heeft ook aangegeven: als de zoekmachine goed werkt, dat dit dan minder nodig is. Dus niet teveel tijd in stoppen. Dus laten we eerst maar uit gaan van NIET gebonden aan gebruikers (ga er even vanuit dat dat makkelijker is).

T.a.v. de vraag 'zijn die uitgebreid genoeg voor wat we hier willen hebben': dat kan ik zo niet zeggen.

sytskevanhasselt commented 2 years ago

bevindingen die openstaan uit D-07 / #120

De werking van de crawler van de website is nog niet helemaal goed. Als je zoekt op omgevinsvergunning, vind je een heleboel keer de pagina ‘Bekendmakingen’. Namelijk: de pagina /bekendmakingen, maar ook /bekendmakingen?page=2, /bekendmakingen?page=3 etc. Idealiter verschijnt deze hit maar één keer.
Zoeken staat te strak ingesteld: Ik zoek op “Omgevingsvergunning”: en ik vind NIIET collega Bert Bovenkerken, die “Omgevingsvergunningen” bij de skills en functie heeft staan.

Zie ook het document "Bevindingen_Medewerkers-Zoeken.docx"

Overige bevindingen:

De pagina 'Digitaal loket' of 'A-Z' zouden eigenlijk niet in de elastic index moeten staan

sytskevanhasselt commented 2 years ago

Enige echt openstaande punt is crawling, pakken we op een ander moment op.

Klantinteractie-Servicesysteem / KISS-frontend