StateofEnterpriseSearch.nl presenteert: Webinar

Afgelopen week heb ik een webinar bijgewoond getiteld: “The State of Enterprise Search“.

Dit webinar is georganiseerd door BA insight.

In een soort “round table” setting werd door zeer bekende personen in het vakgebied “Enterprise Search” gediscussieerd over onderwerpen die door de moderator werden ingebracht. De deelnemers waren:

  • Martin White
  • Sue Feldman
  • Jeff Fried

De webinar is opgenomen en kan worden teruggeluisterd op: http://vimeo.com/78551770.

BA insight heeft de afgelopen weken ook twee rapporten opgeleverd: State of Search in the Enterprise: Part 1 & Part 2

Veel luister en leesplezier!

De huidige populaire zoekmachines op internet doen goed werk voor het zoeken en vinden van populaire informatie. We maken er met zijn honderden miljoenen dagelijks gebruik om “feitjes” en oplossingen te vinden. We weten echter ook dat deze zoekmachines drijven op advertenties én dat de ranking van resultaten na het zoeken sterk worden beïnvloed door het leveren van zoveel mogelijk “clicks”.

Het objectieve algoritme van een zoekmachine zou gebaseerd moeten zijn op de principes van “precision”/”precisie” en “recall”/”vangst” om objectief betrouwbaar te zijn:

  • Precision
    Precisie is de verhouding tussen het aantal relevante resultaten (documenten, treffers), en het totaal aantal resultaten dat door het systeem is teruggeven.

  • Recall
    Vangst is de verhouding tussen het aantal relevante gevonden documenten, en het totaal aantal relevante documenten dat er mogelijk zijn. Dit laatste is een van tevoren opgesteld ‘wensenlijstje’, vaak ‘ground truth’ of ‘gouden standaard’ genoemd.

Ter zijde:
Op het internet gelden commerciële drivers, maar er kan ook gebruik worden gemaakt van “polulariteitsindicatoren” en “linkdichtheid” om de meeste relevante antwoorden te bepalen.
Binnen de bedrijfsmuren zijn deze drivers en indicatoren veel minder of zelfs niet aanwezig.
Een “enterprise search” oplossing moet derhalve veel sterker leunen op de informatie-statistische algoritmes die ten grondslag liggen aan de information retrieval principes van precision and recall.

Maar wat nu als je op zoek bent naar inzichten in relaties of achtergrondinformatie die een Google, Bing of Yahoo niet kan leveren?

In dit artikel wil ik jullie wijzen op het bestaan van Cluuz.com. Zoek eens op Google en daarna op Cluuz.com naar Edward Snowden. Hoewel Google goede resultaten boekt met zijn “knowledge graph” levert Cluuz een “relation ship” diagram. Daarnaast identificeert Cluuz entiteiten die een relatie hebben met Snowden. 

Daarnaast is Cluuz een “meta-zoekmachine” die meerdere openbare zoekmachines raadpleegt voor relevante resultaten. Dit levert een meer objectief beeld op.

Als we kijken naar de “Top linked entities” dan zien we namen die binnen het zoekresultaat van Google totaal niet voorkomen, zoals “Glenn Greenwald”. Een persoon die ook gerelateerd is aan het openbaar maken van geclassificeerde informatie. Cluuz.com is één van de uitdagers van de populaire zoekmachines zoals Google.

De strekking van dit artikel?
Verlaat je niet alleen op “one size fitss all” zoekmachines op internet als je op zoek bent naar achtergrondinformatie. Blijf speuren naar nieuwe en uitdagende oplossingen zoals Cluuz.com.

De evolutie van “Search” deel 3

In de vorige artikelen over de “Evolutie van ‘search’” heb ik een beeld geschetst van de veranderingen op het gebied van zoektoepassingen en interfaces.

De wereld van “(enterprise) search” is de afgelopen jaren echter aan het veranderen door zoektechnologie meer geïntegreerd in te zetten. Voor veel toepassingen is het niet eens meer duidelijk dat je aan het zoeken bent. De gebruiker krijgt overzichten en grafieken op zijn beeldscherm te zien met de mogelijkheid om door de informatie te navigeren, intuïtief te filteren, in te zoomen en te selecteren, zonder dat er een “zoekbox” aan te pas komt.

Welkom in de wereld van “Search Based Applications”, ook wel bekend als SBA’s of “embedded search”.

De belangrijkste functie van een SBA is het aggregeren van informatie uit verschillende verspreide informatiebronnen – gestructureerd of ongestructureerd – en deze in context te presenteren. Dit maakt het overbodig om meerdere systemen te raadplegen om een compleet beeld te vormen over een klant, een product of een specifiek onderwerp.

Search Based Applications raken of overlappen zelfs de wereld van Business Intelligence (BI) door het visueel weergeven van filters en analyse opties. Zoektechnologie heeft echter het grote voordeel om rapporten op te stellen die niet van tevoren zijn bedacht en waarvoor een bepaalde van tevoren vastgelegde datastructuur niet nodig is. Conventionele ERP en CRM applicaties zijn ontworpen rondom een van tevoren vastgelegde set van gegevens in een bepaalde relationele structuur. Daarom kost het meestal veel tijd om een nieuw rapport te maken.

SBA’s zijn ontworpen om flexibel te zijn m.b.t. de aangeleverde datasets en de mogelijke vragen die zich voordoen. De huidige zoektechnologie is in staat om informatie uit verschillende bronnen te verwerken en te gebruiken zonder een vastgesteld datamodel te hanteren. Deze oplossingen zij ook ontwerpen om “big data” aan te kunnen. Neem alleen al “elastic search“. Deze oplossing komt voort uit de “NoSQL” beweging die zich afzet tegen het keurslijf van datamodellen, tabellen en velden die zo beperkend zijn voor een flexibel gebruik van data.

Een goed voorbeeld van een SBA is een oplossing voor een callcenter of een customer support afdeling (http://www.attivio.com/resources/demos/623-voice-of-the-customer-demo.html).
Je wilt dat de medewerker die een klant aan de lijn heeft in één oogopslag alle relevante gegevens van die klant op zijn of haar scherm heeft. Deze relevante gegevens zitten meestal in verschillende, niet op elkaar aangesloten systemen. In het traditionele model moet de medewerker verschillende applicaties openen om informatie op te zoeken (als hij of zij die al kan vinden) over de klant, de producten en de “Knowlegde base” om de vraag van die klant te beantwoorden.

Een search based application kan alle informatie in één keer naar de gebruiker toe brengen zodat vragen veel sneller beantwoord kunnen worden.

Dit soort toepassingen gaan op dit moment al nog veel verder. Autonomy heeft met haar “Virage” product de mogelijkheid om gesproken woorden real-time om te zetten naar tekst en die weer als zoekvragen uit te voeren op de onderliggende search engine. Terwijl het gesprek met de klant vordert kan zo relevante informatie worden opgehaald om de dialoog van de customer support medewerker en de klant te voorzien van antwoorden.

Als laatste nog een leuke demo van Exalead. Zij laten zien hoe ze in 10 minuten een SBA kunnen maken op basis van hun “CloudView” product: http://blog.exalead.com/2012/06/13/a-real-demo-building-of-a-sba-in-10-minutes/

Zoeken wordt op dit moment nog gezien als een tekstveld waar iemand een aantal woorden ingeeft waarna er een lijst van 10 relevantie documenten verschijnt.

Het proces van zoeken en vinden is echter zoveel meer dan dat. De oplossingen komen steeds dichter bij de menselijke manier van informatie vergaren. Wij hebben een vage informatiebehoefte, maar door onze vragen te specificeren (in menselijke taal en niet één of twee woorden), het resultaat te beoordelen en daarna intuïtief tot een dialoog te komen met de antwoordmachines komen we steeds dichter bij de oplossing.

Zoekmachines zullen voorlopig de kracht en complexiteit van het menselijke brein niet kunnen evenaren. We kunnen echter wel beter gebruik maken van de mogelijkheden die de techniek ons nu al brengt.

De evolutie van “Search” deel 1

Iedereen is bekend met het zoeken naar informatie op het internet via Google.com. Generaliseren is meestal niet goed, maar deze stelling durf ik wel te doen (zeer jonge kinderen en zeer oude personen daargelaten).
We worden ook dagelijks geconfronteerd met zoekfuncties wanneer we aankopen willen doen op de commerciële sites zoals Amazon, Bol.com, Wehkamp.nl etc.
Zoeken zit diep in ons wezen. Iedereen zoekt iedere dag wel naar iets. Zelfs onze pre-historische voorouders zochten iedere dag… naar eten.

Er zijn verschillende redenen waarom wij zoeken. Meestal ben je op zoek naar iets specifieks en weet je dat het ergens moet liggen zoals wanneer je op zoek bent naar je autosleutels. Een andere keer ben je op zoek naar iets, maar weet je niet precies wat, zoals bij het zoeken naar een geschikt kledingstuk. Je neust dan wat door de rekken totdat je hebt gevonden wat je zocht. Een andere manier van zoeken is als je iets nog niet weet, maar waarvan je wel iets wilt weten, zoals de feiten van een historische gebeurtenis, een geboortedag van iemand of een bepaald onderwerp zoals een vakantieland. Het kan echter ook voorkomen dat we zoeken naar informatie over een bepaald onderwerp en daarbij worden gewezen op verbanden of gerelateerde onderwerpen waarvan we niet eens wisten dat er een relatie bestaat.

Zoeken naar informatie waarbij we worden ondersteund door technologische hulpmiddelen, zien we sinds het “digitale tijdperk” steeds veranderen en beter worden.
In dit artikel wil ik jullie meenemen in de evolutie van deze digitale hulpmiddelen en dan met name de gebruikersgerichte oplossingen die wij in ons dagelijks werk tegenkomen.

Fase 1a: zoeken binnen “velden”

 

Nog niet zolang geleden was dit de manier waarop je naar bestanden kon zoeken. De zoekopdracht werd beperkt tot één veld, hier de bestandsnaam, en één informatiesysteem of bron.

In andere applicaties zoals bibliotheeksystemen was deze manier van zoeken ook gemeengoed. De medewerker kon zoeken binnen één veld tegelijk, bijvoorbeeld de titel van een document of record. Sorteren of op de een of andere manier filteren van de resultaten was niet mogelijk. Je moest van tevoren weten welke woorden in de verschillende velden werden gebruikt om een document of bestand terug te vinden. Alleen specialisten of mensen die de “content” kenden waren zo in staat om informatie te vinden.

 

 

 

Fase 1b: full-text search over meerdere velden

De volgende stap voorwaarts bestond uit de mogelijkheid om “full-text” (volledige teksten worden doorzocht op het voorkomen van de termen in de zoekvraag) te zoeken. In deze oplossing werden alle velden die aan een document of bestand zijn gekoppeld (metadata) doorzocht.  Ook hier gold weer de beperking dat ieder informatiesysteem apart moest worden doorzocht.

In het voorbeeld is binnen een bepaald systeem gezocht naar de term “Brookline”. In bepaalde resultaten is deze term ook terug te zien, zoals in de titel of in de beschrijving. De gegevens van de resultaten die werden gepresenteerd stonden vast. Omdat de zoekopdracht over alle velden van de documenten ging, ontstond de situatie dat de velden die voor de zoekresultaten werden gepresenteerd deze zoektermen niet hoefden te bevatten.
Dit maakt het voor de gebruiker zeer lastig om te bepalen waarom een bepaald resultaat wordt getoond.

 

Fase 1c: full-text search over meerdere bronnen

De tijd van de grote internet zoekmachines brak aan. Altavista, Hotbot, Yahoo en… Google. Voor het eerste konden mensen met één zoekopdracht over verschillende bronnen (lees: websites) zoeken.
De Enterprise Search markt (zoeken in de informatie binnen organisaties) werd in die tijd gedomineerd door Verity, Autonomy en Endeca. Die producten konden al vanaf 1996 zoeken over verschillende bronnen in organisaties.

De resultaten van alle gevonden documenten van alle bronnen werden in één resultaatlijst gepresenteerd. Het probleem eerder probleem van het niet altijd kunnen laten zien van de overeenkomst tussen de zoekopdracht en de gevonden documenten werd opgelost door de zogenaamde “contextuele samenvatting”. De zoekmachine maakt een samenvatting van het deel van de tekst in het document dat de zoekwoorden bevat.
Deze techniek is zeer belangrijk: Het geeft de zoeker een directe terugkoppeling van de relevantie. De tekst rondom de zoekwoorden geeft een terugkoppeling en de mogelijkheid om de zoekvraag aan te passen om dat je direct kan zien in welke context je zoekwoorden voorkomen.

Een resultaatlijst zonder de mogelijkheid om “in te zoomen” op bepaalde specifieke resultaten gaat echter ook maar zover. Wat nou als je wilt zoeken op alleen afbeeldingen, of een bepaald soort website. Naar mate de hoeveelheid doorzochte informatie toenam stuitte dit al snel op beperkingen. Om te kunnen vinden wat je zoekt zijn meer mogelijkheden nodig.

PS. In een volgende post ga ik in op de specifieke eisen aan en kenmerken en verschijningsvormen van “enterprise search”.

Fase 2a: zoeken op documenteigenschappen

Dit nieuwe gebruik van informatie over informatie (metadata) luidde een zeer belangrijke nieuwe fase in de toepassing van zoektechnologie in.

De gebruikers vroegen om meer mogelijkheden en de zoekmachines gaven dit. Het werd mogelijk om de “full-text” zoekopdrachten en de gepresenteerde resultaten te “filteren” op bepaalde documenteigenschappen. Zoeken op bestandstype, datumbereik, soort informatie / website werd mogelijk.

De standaard resultaatlijst met een aantal gevonden documenten op basis van een “full-text” match werd uitgebreid met “filters”. Deze uitbreiding ging tevens gepaard met belangrijke wijzigingen in de manier waarop zoekresultaten werden gepresenteerd en hoe de gebruikers deze toevoeging ervaarden. Er moet een goede plek worden gevonden om de filters aan te bieden zodat gebruikers ook begrepen dat ze hun zoekopdracht konden verfijnen op basis van deze filters.
Eerder konden gebruikers door een site navigeren óf zoeken. Vanaf het moment dat filters hun intrede deden gingen “zoeken” en “navigeren” meer in elkaar over en lagen in elkaars verlengde.

De “filters” op documenteigenschappen waren echter “statisch”: de lijst met waardes stonden vast en hielden geen rekening met het feit of er binnen een bepaalde categorie wel resultaten waren. De initiële zoekvraag werd aangevuld met het vaste “filter” wat kon leiden tot een “no-results” pagina. Voor bezoekers van on-line winkels is dit bijna de grootste zonde die je kan begaan.

Fase 2b: zoeken op onderwerp

Toen het on-line winkelen en de hoeveelheid van de aangeboden producten toenam, zagen de de  e-commerce sites al snel dat ze bezoekers niet konden opzadelen met een lijst met producten die aan een zoekvraag voldeden.

Amazon is vanaf het begin al een dankbare bron voor onderzoek en inspiratie geweest. Amazon was de eerste on-line winkel met een grote hoeveelheid aan producten. Zij moesten het probleem oplossen van het op een gebruiksvriendelijke manier vinden van informatie in een grote hoeveelheid informatie.

Uiteraard hebben zij hiervoor gebruik gemaakt van de mogelijkheden die de aanbieders van Enterprise Search oplossingen al langer hadden: structureren (metadateren) van informatie en producten en gebruik maken van deze eigenschappen om “dynamische filters” aan te bieden.

In de zoekwereld duiden we deze techniek aan met “facetted search” of “zoeken op facetten”. Een facet is een specifiek kenmerk of  functie van iets. De informatie en producten werden van verschillende kenmerken voorzien en de informatie werd bij de informatie opgeslagen.

 

Facetten worden door de zoekmachine gegenereerd door de aanwezige metadata (soort, onderwerp) bij de doorzochte informatie of producten. Facetten worden alleen gepresenteerd als de resultaatset (= alle resultaten die aan de zoekvraag voldoen) deze waardes ook bevatten. Dit loste het probleem van de “no results” pagina op: de zoekapplicatie presenteert alleen filteropties voor die onderdelen waar ook resultaten voor zijn.

Zoeken en navigeren gaan steeds meer hand in hand en wel op zo’n manier dat de gebruikers de twee opties niet meer als “verschillend” ervaart.

 

Fase 2c: zoeken op meerdere eigenschappen en metadata

Mensen denken niet altijd in hokjes en willen vaak zoeken in meerdere “bakjes” tegelijk oftewel “iets wat hierop lijkt”.

Maar zoekmachines waren tot nu toe “zwart / wit”: iets voldoet aan de zoekvraag / filter of niet.

Het moest dus mogelijk worden om tegelijkertijd door meerdere “bakjes” van vergelijkbare informatie te zoeken.

De opties van “reeksen” (prijzen en kenmerken) en “kleuren” werden geïntroduceerd. Zo werd het mogelijk om als bezoeker niet beperkt te worden door het toepassen van één filter voor één kenmerk, maar in plaats daarvan ruimer te kijken in een steeds groter aanbod van informatie en producten.

Zoektechnologie heeft zich steeds verder ontwikkeld en was nu in staat om automatisch kleurpatronen te herkennen in afbeeldingen. Dit gaf de mogelijkheid om op kleur te sorteren of filteren. Iets waarvan in de kledingbranche dankbaar gebruik is gemaakt.

 

 

Het vervolg

In de volgende post zal ik de volgende fases in de evolutie van Search behandelen:

  • Fase 3: Zoeken op “statistische informatie”
  • Fase 4a en b: Zoeken “in context”
  • Fase 4c: Personalisatie
  • De toekomst

Wordt vervolgd….

 

 

 

 

 

 

De anatomie van een zoek- en resultaatpagina

Dit document bevat informatie over de zoekfuncties die op een SERP (Search Engine Result Page) zouden kunnen staan.
Op basis van deze informatie kan een Interactie-ontwerper of visueel vormgever bepalen welke ruime en locatie beschikbaar moet worden gemaakt om de specifieke functies een plek te geven in een uitgebalanceerd ontwerp dat integreert met de rest van een website.

Onderstaande afbeeldingen vormen samen één pagina. De onderdelen zijn geen “menu-kaart”!
ze moeten allen een uitgebalanceerde plek krijgen om de bezoeker zo goed mogelijk naar een antwoord op zijn of haar vraag te leiden.

1.    Header van de site
Meestal voorzien van hoofdnavigatie / sectie-indeling van de site.
Vaak zit hier ook al een tweede niveau in zodat een gebruiker met een minimaal aantal klikken bij de content kan komen.
De hoofd- en subnavigatie is meestal een indeling in secties en onderwerpen en wordt ook wel aangeduid met de “informatie-architectuur” van de website.
Deze informatie-architectuur (waar bepaalde content op site “hoort” of vandaan komt) moet ook in de zoekresultaten terugkomen, bijvoorbeeld als filter en als metadata bij de resultaten.

2.    Algemene Zoekbox
De alomtegenwoordige zoekbox met de knop “zoek”.
Gebruikers verwachten de zoekbox vrijwel altijd rechtsboven op alle pagina’s binnen de site.

3.    “Scoped search”
Een pull-down met de mogelijkheid voor gebruikers om direct in een deel van de site te zoeken. Uiteraard kan deze keuze ook terugkomen bij de zoekresultaten waar hij meer als “filter” of “facet” werkt.
Voordeel van een “scoped search” optie is dat een gebruiker meestal al naar een bepaalde sectie in de site is genavigeerd en dat deze selectie dus al impliciet kan worden meegenomen als “scope” voor de uit te voeren zoekvraag. De betreffende “sectie” staat dan voor-ingevuld in de pull-down.

4.    Zoekbox (na het uitvoeren van een zoekvraag in de algemene zoekbox)
De “algemene zoekbox” staat op iedere pagina van de website. Als een bezoeker daar een zoekvraag heeft uitgevoerd, verdwijnt de algemene zoekbox meestal en wordt deze vervangen door een grotere zoekbox die onderdeel is van de SERP.

5.    Autocomplete / autosuggest
Bekend van Google.com en later door veel andere sites ook overgenomen.
De zoekmachine vult de zoekvraag van de gebruiker automatisch aan terwijl hij of zij de zoekvraag nog aan het formuleren is.

6.    Zoek-“Tools”
Niet opvallende links naar aparte pagina’s met informatie over de manier waarop gezicht kan worden, door welke informatie gezocht wordt, de mogelijkheid om “uitgebreid” te zoeken enz.

7.    Feedback aan de gebruiker
De zoekomgeving voert vele functies uit waarvan een terugkoppeling aan de bezoeker moet worden gegeven. Denk hierbij aan:
– Spelsuggestie (indien de zoekmachine niets vindt vanwege een verkeerd gespeld woord: Bedoelde U)
– Gerelateerde zoekopdrachten (ik zoek op “verklaring omtrent gedrag” en de zoekfunctie geeft terug “U kunt ook zoeken op VOG”.
– Foutmeldingen en andere terugkoppeling / dialoog met de bezoeker.

8.    Terugkoppeling resultaten, filters enz.
De zoekomgeving moet de bezoeker laten weten hoeveel resultaten er (ongeveer) zijn gevonden (reden om de zoekvraag te verfijnen of juist breder te maken), welke filters actief zijn (via uitgebreid zoeken of geselecteerde facetten (links) of een datumbeperking.
Extra functies op deze plek zijn ook het kunnen instellen van een “Alert” op de zoekvraag zodat de gebruiker automatisch nieuw toegevoegde documenten via e-mail toegestuurd kan krijgen als deze aan zijn of haar zoekvraag voldoet (denk aan vergunningen etc.)

9.    Keymatches
Net als op Google.com is het soms nodig of vaak handig om bepaalde “favoriete” documenten of informatie expliciet bij de bezoeker onder de aandacht te brengen als hij of zij een bepaalde zoekvraag stelt. Het is zo mogelijk om zeer specifieke content onder de aandacht te brengen.
De volgorde van de zoekresultaten wordt hiermee niet beïnvloed. De “Keymatches” staan los van wat ook wel de “organische” zoekresultaten wordt genoemd.
Door zorgvuldige analyse van zoekrapporten (waar zoeken gebruikers op) kan worden bepaald voor welke zoekopdrachten Keymatches moet worden gedefinieerd.

10.    Zoekresultaten
De zoekresultaten zijn het gevolg van de zoekopdracht van de gebruiker en de geavanceerde algoritmes die de search engine gebruikt om te bepalen welke informatie het meest relevant is. De search engine kan hierbij ook rekening houden met het klikgedrag van de gebruiker (welke documenten worden het meest geraadpleegd), zijn of haar profiel en zoekhistorie.
Een gebruiker moet in één oogopslag kunnen zien waarom een bepaalde document in de resultaatlijst staat. Het is van belang om minimaal de volgende gegevens per resultaat te tonen:
– Duidelijke titel
– Contextuele samenvatting met terugkoppeling van de zoekvraag t.o.v. het gevonden document
– Datum om de actualiteit te kunnen bepalen
– klikbare metadata zodat de gebruiker kan zien hoe het resultaat in de informatiestructuur van de site past en het resultaat direct kan filteren
– (deel van) URL van het resultaat zodat de gebruiker de plek in de navigatiestructuur van de site kan bepalen.
– Eventuele andere “actionable” functies zoals het doorsturen van een resultaat, printen etc.

Op basis van deze contextuele gegevens kan de gebruiker besluiten om zijn zoekvraag aan te passen.

11.    Filters / facetten
Informatie op een website of in een informatiesysteem is meestal ingedeeld in secties / categorieën, onderwerpen etc. Door het aanbieden van (dynamische) filters op een resultaatlijst kan de gebruiker de zoekvraag beperken tot een deel van de content.
Het is van essentieel belang dat de indeling aansluiting heeft bij de indeling (Informatie Architectuur) van de content op de website zodat de gebruiker houvast heeft.
Facetten worden samengesteld op basis van metadata die is vastgelegd bij de documenten in de content. Omdat een facet alleen kijkt naar de waardes van documenten in de resultaatset, wordt het toepassen van een filter die 0 resultaten oplevert voorkomen.
Dit is tevens het grote voordeel van het gebruik van facetten (post-filtering) t.o.v. een formulier waar de gebruiker van te voren allerlei combinaties van velden en waardes kan specificeren (pre-selectie). In feite gaat de zoekapplicatie een dialoog aan met de bezoeker.

12.    Veel gezocht
Het gedrag van andere bezoekers op een website kan zeer behulpzaam zijn voor iemand die informatie zoekt. Bezoekers leren van elkaar om zoekvragen te formuleren.
De beheerder van de site kan door analyse van de zoekrapporten te weten komen waar  bezoekers vaak op zoeken om zo patronen te herkennen en bezoekers naar de juiste content te sturen. Het stellen van “verkeerde” vragen kan zo ook worden voorkomen.
Dit onderdeel kan automatisch worden gevuld of door de redactie van de website / beheerder van de zoekfunctie.

13.    Tag-cloud
Een Tag-Cloud is in feite een andere weergave van een lijstje met filters / facetten.
Een Tag-Cloud is het krachtigst voor een filter / indeling op basis van een inhoudelijk kenmerk (indeling op onderwerp bijv.) van content.
Door het variëren van font-grootte ziet de bezoeker in één oogopslag welke onderwerpen in de resultaten voorkomen, in relatie tot zijn eigen zoekvraag.
De onderwerpen in de tag-cloud zijn aanklikbaar waarna er in feite een filter wordt toegepast op de resultaatset.

14.    “Snel naar”
Redactioneel onderdeel dat de beheerder van de site de mogelijkheid heeft om een bezoeker altijd een goede start te bieden voor zijn zoektocht, ook als de initiële zoekvraag 0 resultaten oplevert. Denk aan:
– ABC-index / sitemap
– Pagina met contactgegevens
– Pagina met FAQ’s
– Campagnes
– etc.

 

15.    Periodeselectie
In plaats van het aanbieden van een selectie op “datum van – tot” is het voor een bezoeker veel sneller om een zoekperiode aan te geven die het meest voor de hand ligt voor de content van de website / het informatiesysteem.
Het is van belang dat alle content op de website / het informatiesysteem één unieke datum bevat. Keuzes hierbij zijn:
– publicatiedatum (meest gebruikt)
– modificatiedatum
– Indexeringsdatum
– creatiedatum

16.    Datumselectie
Voor bepaalde zoekvragen / contenttypen moet de bezoeker heel specifiek een datum van – tot aan kunnen geven.

17.    Gerelateerde zoekopdrachten
De search engine kan zoekopdrachten voorstellen met woorden die vaak in combinatie met de zoekopdracht van de bezoeker voorkomen in de documenten zelf.
Dit helpt de gebruiker bij het anders formuleren (specifieker of juist algemener) van de initiële zoekopdracht.
Het is wederom een voorbeeld van de dialoog die de zoekomgeving aan gaat met de bezoeker om hem het vertrouwen te geven dat hij of zij “op de goede weg zit”.

18.    Paginanavigatie
Vrijwel altijd zal een zoekvraag meer dan 10 resultaten opleveren.
Het is daarom noodzakelijk om de gebruiker de mogelijkheid te geven om alle resultaten te zien. Via de paginanavigatie kan de gebruiker doorbladeren naar resultaat 11 t/m 20 en verder.

19.    Zoekhistorie
Bezoekers zullen veelvuldig gebruik maken van de zoekfunctie om informatie te kunnen vinden. Daarbij zullen ze verschillende zoekvragen formuleren waarbij de zoekomgeving hen helpt om de juiste vragen te stellen.
Als een site of informatiesysteem veel verschillende soorten informatie bevat zullen de bezoekers ook veel verschillende vragen stellen.
Het is voor een bezoeker niet te doen om te onthouden waar hij of zij in één sessie of over sessies heen allemaal op heeft gezocht en welke zoekvraag de beste resultaten op heeft geleverd.
Het bijhouden en tonen van de zoekhistorie van een bezoeker stelt hem of haar in staat om terug te keren naar de resultaten van een eerdere zoekvraag.  Dit schept vertrouwen in de zoekfunctionaliteit omdat eerdere resultaten consequent gereproduceerd kunnen worden.

20.    Feedback
Een bezoeker moet de mogelijkheid hebben om makkelijk in contact te treden met de beheerder van de zoekfunctie als hij of zij iets niet kan vinden of juist wil vermelden dat de resultaten goed waren.
De zoekfunctie maakt het mogelijk om via een dialoog tot de juiste resultaten te komen. Deze dialoog kan niet zonder de mogelijkheid in contact te treden met een persoon. De feedback functie geeft deze mogelijkheid.
In het voorbeeld ontbreekt een veld voor het opgeven van het e-mailadres of het telefoonnummer van de bezoeker. Die moet uiteraard wel aanwezig zijn.

 

Het belang van informatie-architectuur in een zoekoplossing

Een zoekoplossing reflecteert altijd de structuur van informatie zoals deze uit een bronsysteem komt.

Als de structuur van die informatie niet goed is, zal ook de zoekoplossing minder goed aansluiten bij de behoefte van de gebruiker. De informatie wordt minder goed vindbaar.

Waar ik hier over praat is “Informatie Architectuur”. Informatie architectuur is gericht op het ordenen van informatie op een voor de gebruiker logische structuur. Om een goede informatie architectuur te kunnen maken zijn in ieder geval twee zaken nodig:

  1. Analyse van de aangeboden informatie zodat een beeld van de samenhang of juist diversiteit wordt verkregen, en
  2. “card sorting” sessies of vergelijkbare techniek om het beeld van de gebruiker te achterhalen m.b.t. de aangeboden informatie.

Uit die tweede kan overigens ook blijken dat de gebruiker bepaalde informatie op een bepaalde plek verwacht, terwijl die informatie helemaal geen deel uit maakt van het informatiesysteem. Een uitdaging.

Bij het ontwerpen van een zoektoepassing moet vervolgens integraal gebruik worden gemaakt van diezelfde structuur die voor de gebruiker zo bekend aan zal voelen

  • De filters (facetten) moeten gebruik maken van de indeling die men ook gebruikt om door de informatie op bijv. het intranet te navigeren.
  • De resultaten moeten context bieden zodat duidelijk is in welke structuur het betreffende document staat, welke onderwerpen hierbij beschikbaar zijn, wie de auteur is etc.

Te vaak zien wij bij onze klanten een vraag om een zoektoepassing te maken “a la Google” waarbij totaal voorbij wordt gegaan aan de grondbeginselen van een informatie-architectuur. De zoeker heeft dan geen context bij de resultaten en zal daarom niet optimaal worden ondersteund.

Het wordt helemaal moeilijk als de te ontsluiten informatiebron zelf al slecht gestructureerd is. Je kan de zoekoplossing meestal niet de problemen met de informatiestructuur op laten lossen.

Daarom hanteren wij een “holistische” benadering bij het ontwerpen en implementeren van zoekoplossingen. Dit gaat op voor alle mogelijke zoekoplossingen zoals Intranet search, Enterprise search, vertical search en search based applications (SBA’s).
Zoeken en vinden richt zich niet alleen op de SERP (Search engine result page) maar komt terug in het hele informatiesysteem (vaak een intranet / CMS oplossing) waar de gebruiker mee werkt.

Kijk daarom goed naar de wijze waarop een gebruiker toegang heeft tot de informatie voordat er resultaatpagina’s worden ontworpen en een search engine wordt geïmplementeerd.

Edwin Stauthamer
04-07-2011

Zoekapplicaties die vragen beantwoorden: hoeveel uren verlof heb ik nog?

Vandaag ben ik bij een klant weer een mooi voorbeeld van hoe zoekomgevingen kunnen voorzien in vragen van medewerkers tegengekomen.

Naast mij zat een medewerker aan wie ik eerder de vraag had gesteld “Hoe gebruik jij de zoekfunctie?”.  Zijn antwoord was even verbijsterend als logisch: “Ik gebruik de zoekfunctie nooit omdat de informatie van onze dienst toch niet in de zoekomgeving beschikbaar is”.

Later hoorde ik hem zoeken naar het aantal verlofuren dat hij nog beschikbaar had. Hij stelde hardop letterlijk de vraag “hoeveel uren verlof heb ik nog?”. Om deze vraag te beantwoorden ging hij naar het “personeelsportaal”, logde daar in en zocht via enkele menu-opties de informatie over zijn verlofuren.

Met deze vraag kon ik natuurlijk iets. Zou het niet mooi zijn als de zoekfunctie dit soort alledaagse vragen van medewerkers kan beantwoorden? Uiteraard was mijn antwoord een volmondig “ja!”.

Met het credo “make search seem psychic” in het achterhoofd is dit natuurlijk makkelijk in te vullen:

  • Verwerk de zoekopdracht in een query pipeline
  • Deze query pipeline haalt daar dit soort vragen uit; zoeken naar “verlofuren” of desnoods de hele vraag “hoeveel verlofuren heb ik nog”
  • formuleer een query naar een database die deze gegevens bevat, waarbij uiteraard de identificatie van de ingelogde medewerker nodig is
  • Toon het antwoord bovenaan de organische (= documenten uit de search engine) zoekresultaten: “Uw resterende verlofuren voor dit jaar zijn: 200″.

Het verkrijgen van antwoorden op zoekvragen gaat verder dan een lijstje documenten!

Edwin Stauthamer
15-06-2011