Målet med gode søkefunksjonalitet er at brukeren enkelt skal finne det hen leter etter - noe som er lettere sagt enn gjort. Variasjonen i hva brukerne vil finne og hvordan de går fram for å finne det, gjør det vanskelig å dekke alle scenarier. Dette gjør det utfordrende å bygge et godt søk, og det er ikke gjort på en dag. Max Irwin underbygger dette i bloggposten «Falsehoods Programmers Believe About Search», hvor han tar for seg 106 feilaktige påstander som humoristisk forklarer kompleksiteten til et godt søk. Som Data Engineer nerder jeg mye på søkefunksjonalitet i mine prosjekter, og jeg kjenner meg igjen i mange av Irwins påstander. Jeg har derfor drodlet videre på temaet.
Påstand 1: Søkemodul er enkelt å legge til
Særlig! Et godt søk krever innsats over tid, og det er ikke noe en utvikler kan implementere ved siden av andre oppgaver og features. Det er ikke bare å slenge på en widget. I tillegg til selve søkefunksjonaliteten, må det også tas høyde for at datasettet kommer til å endres over tid. Man vet ikke hvordan sluttbrukeren kommer til å bruke søket, og vi må derfor observere bruksmønsteret og tilpasse deretter. Noen bruker søk som en snarvei-funksjon. Da bør de viktigste landingssidene kommer først fordi sluttbrukeren søker på tittelen eller deler av tittelen for siden de leter etter. Andre kan bruke søket for å lete etter artikler skrevet av en bestemt forfatter, skrive hele setninger eller stille spørsmål. Noen kan også finne på å lime inn et helt dokument i søkefeltet og likevel forvente å få resultater. Som utviklere kan vi ikke bare bruke tid på å utvikle funksjonen, for løsningen må også tilpasses bruksmønsteret og vedlikeholdes etter lansering.
Påstand 2: Feilstaving er ikke noe problem
Feilstaving kan skape hodebry. Det er ikke slik at vi kan lage en liste med feilstavende versjoner av et ord, og deretter lete i denne listen om noen skriver feil. Den vanligste fremgangsmåten er at man tillater et visst antall feilstavinger basert på hvor langt ordet er, og viser resultater fra disse. I tillegg vises resultater for det ordet man søker på hvis det også gir treff.
Dette kan gi noen interessante resultater, men som igjen gir mening når man vet hvordan disse feilstavelsene er bygget opp. For eksempel kan et søk etter “kidney” hos Oda (tidligere Kolonial), gi treff på kidneybønner, men også på Kinderegg. I dette tilfellet er det gitt rom for to feilstavelser. Vent nå litt, sier du, det er jo faktisk tre feilstavelser mellom “kidney” og “kinder”. Grunnen til at dette likevel gir treff er fordi algoritmen som brukes teller bokstaver som har byttet plass kun som én feilstavelse.
En annen utfordring er når det feilstavede ordet er identisk med et ord som er stavet riktig. Da vil søketreffene i utgangspunktet være helt riktige og presise, men man kan likevel sitte igjen med en småfrustrert og forvirret bruker.
Påstand 3: Synonymer er «easy peasy»
Og det er det når du skal skrive en stil og slår opp i synonymordboka. Men i en søkefunksjon, not so much. Lister over synonymer er noe som må vedlikeholdes gjennom hele levetiden til søket, og hvilke synonymer man skal bruke varierer også fra domene til domene. Da er det lurt å benytte seg av en ekspert innenfor domenet, slik at man får oversikt over alle forkortelser som brukes innenfor bransjen. Forkortelser kan bety flere ting avhengig av hvilket domene man er i. Fortkortelsen “TV” kan for eksempel bety tillitsvalgt. Men vi tipper du bruker det når du snakker om det gode, gamle fjernsynet. Og hvis du søker etter anbefalinger når du skal kjøpe ny TV, hadde det vel vært veldig frustrende hvis de fleste søkeresultatene viser treff som handler om “nye tillitsvalgte”?
Påstand 4: Vi kan gjøre som Google
Google-søk er både en velsignelse og forbannelse. De har bygget et søk som er så godt at man antar svaret ikke finnes hvis man må gå til side 2 i søkeresultatene. “Å google” har blitt et verb som er synonymt med “å søke”.
«Bare gjør slik som Google gjør» er et sitat som direkte eller indirekte brukes når kunder vil ha et nytt søk. Utfordringen med dette er at det det er tusenvis av utviklere i Google som jobber med søkemotoren, og de har brukt flere tiår med prøving og feiling for å få det til. Det har selvfølgelig ikke kunden satt av tid eller ressurser til. I tillegg har Google et ekstremt stort datasett å jobbe med. Da er det dessverre en utfordrende oppgave for en enkelt søkeutvikler å replisere Google.
Men det er fullt mulig å hente inspirasjon fra dem, og prøve å implementere enkelte features Google bruker. Det er også viktig å fokusere på hva søket man bygger skal løse for brukerne. Google har for eksempel ikke en filtreringsfunksjon på søkeresultatene sine, noe som en nettbutikk vil ha behov for.
Påstand 5: Et godt søk trumfer rotete data
Som mange andre steder: ordtaket “shit in, shit out” gjelder også for søk. En ting er å justere på et søk, men til syvende og sist må dataen man søker i være av god kvalitet.
Data kan komme i mange forskjellige formater og det er alt for få som jobber med innhold, CRM-systemer, bildedatabaser og andre potensielle datakilder som tenker at dette skal være lett søkbart. Et eksempel er tekstekstrahering fra PDF’er. Problemet med dette er PDF’er sin fleksibilitet som fører til at ingen dokumenter er strukturert på samme måte. Måten teksten lagres i PDF-formatet fører også til at mye av strukturen forsvinner og alt blir bare et sammensurium av tegn med koordinater på hvor i dokumentet tegnet skal være. Derfor blir det vanskelig å lage en generell måte å hente ut tekst fra PDF’en på, og resultatet blir deretter. Dette og andre problemer med tekstekstrahering fra PDFer forklares godt av Bogdan i denne bloggposten.
Selv om mange av påstandene i Irwins artikkel «Falsehoods Programmers Believe About Search» er satt på spissen, så er det et snev av sannhet i dem. Det kan være lett å tenke at søk som oppleves som enkle for brukeren også er enkle å implementere, men slik er det ikke. Gode søk er gjennomtenkte og komplekse, og krever kraftige verktøy og spesialisert kompetanse. Og de må vedlikeholdes over tid.