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.

Ontvreden over uw zoekoplossing? Bezig met vervanging?

Enkele jaren geleden heeft u geïnvesteerd in een (enterprise) search oplossing. De verwachtingen van deze zoekoplossing waren hooggespannen en gedurende de eerste maanden en zelfs het eerst jaar waren uw medewerkers blij dat ze eindelijk in staat waren om documenten en informatie te vinden.

De afgelopen tijd is de waardering voor de zoekoplossing echter gedaald. Medewerkers kunnen de voor hun belangrijke documenten en informatie niet meer vinden.

Daarom is besloten om op zoek te gaan naar een vervanging van de huidige search engine. Er moet immers een betere oplossing zijn dan de huidige. Er wordt een langdurig en kostbaar traject gestart, compleet met het opstellen van een Programma van Eisen (PvE), wellicht een Request for Information (RFI) en daarna een Request for Proposal (RFP).

STOP!!!!
De reden dat de bestaande zoekoplossing niet aan de wensen van de gebruikers voldoet ligt waarschijnlijk niet aan de mogelijkheden van het de search engine of het product zelf. Wat is er de afgelopen jaren gedaan aan het beheer en de doorontwikkeling van de zoekoplossing?
Meestal wordt een zoekoplossing geïmplementeerd en daarna niet meer aangepast aan de veranderende omgeving of de wensen en eisen van de gebruiker.

De verschillen tussen de producten van search vendors zijn in principe niet zo heel erg groot. Uiteraard kan de ene oplossing iets anders of meer of minder dan de andere oplossing, maar een groot deel van het succes van een zoekoplossing zit hem in een goede implementatie en een team dat er voor zorgt dat de zoekoplossing ook goed blijft werken.

– Wordt het gebruik van de zoekmachine wel gemonitored?
– Wordt er regelmatig gesproken met medewerkers om erachter te komen wat zijn willen en hoe zij de zoekoplossing gebruiken?
– Bevat de huidige search index wel de informatie uit de bronnen die belangrijk zijn voor de gebruikers?
– Zijn er wel bronnen toegevoegd aan de zoekomgeving?
– Zijn er wel verbeteringen doorgevoerd aan de zoekervaring?

Gooi uw oude schoenen dus niet zomaar weg. Ga eerst eens op zoek naar een schoenmaker die kan beoordelen of uw schoenen nog gerepareerd kunnen worden.

Oftewel… schakel een organisatie in die u kan helpen bij het beoordelen van uw huidige zoekoplossing. Dit kan wel eens veel goedkoper zijn dan het aanschaffen en implementeren van een andere search engine die zonder goed beheer na een aantal jaren weer tot ontevreden gebruikers leidt.

InfoKnowlegde is zo’n organisatie. Zij hebben de kennis en ervaring om het beste uit uw zoekoplossing te halen.

 

Zie ook: http://www.enterprisesearchblog.com/2012/07/whats-the-least-expensive-enterprise-search-platform.html

Search Vendors updated

Op de pagina “Search Vendors” (aanbieders van zoekproducten) zijn drie bedrijven / producten toegevoegd:

  • IntraFind
    Een Duits bedrijf dat zich de afgelopen 12 jaar heeft ontwikkeld tot een expert op het gebied van Enterprise Search, ondersteund door een eigen oplossing iFind.
  • PolySpot
    Een Frans bedrijf dat zich met name probeert te richten op de “Big data” markt. Ze zeggen zelf dat ze de meeste connectoren hebben om met alle denkbare content systemen te koppelen.
  • SearchBlox
    SearchBlox positioneert zich als het alternatief voor de Google Mini. Dat zegt genoeg over de functionaliteit.

De evolutie van “Search” deel 2

In de evolutie van “Search” deel 1 heb ik jullie meegenomen in de reis door de evolutie van Search. In dit deel ga ik verder met dit reisverslag.

Zoeken heeft zich de afgelopen jaren sterk ontwikkeld en het wordt voor ons gebruikers steeds makkelijker om informatie te vinden, ook al neemt de hoeveelheid informatie nog steeds toe.
Zoektechnologie én de gebruikerservaring wordt steeds beter. Ontwikkelaars van zoektechnologie en ontwerpers van zoekinterfaces begrijpen ons “zoekers” steeds beter. Uitdagende en baanbrekende oplossingen zijn het resultaat.

In deel twee van dit artikel neem ik jullie mee in de “state of search” anno nu én werp ik een blik in de toekomst.

Fase 3: zoeken op “statistische informatie”

Daar waar eerder alleen gekeken werd naar documenten of artikelen die rechtstreeks aan de zoekvraag voldoen, wordt nu meer en meer gekeken naar het gedrag van de zoeker.

De zoekmachine maakt gebruik van zoekvragen die door bezoekers zijn uitgevoerd om andere bezoekers op een bepaald spoor te zetten. Wanneer ik begin met het intypen van een zoekvraag, komt de zoekomgeving met suggesties om mijn zoekvraag af te maken. Dit mechanisme staat ook wel bekend als “autocomplete”. De zoekvragen zijn niet verzonnen, maar hergebruikt vanuit de statistische log informatie. Google maakt hier ook denkbaar gebruik van.
Door de toepassing van de autocomplete maken mensen minder typefouten en ze leren van elkaar.

Een andere vorm van het gebruik van statistische informatie in zoekomgevingen zijn de zogenoemde “Recommendation engines”. Hierbij worden suggesties voor artikelen of documenten gedaan die een relatie hebben met waar jij op dat moment mee bezig bent. Vergelijk dit met de verkoopmedewerker die zegt “weet u wat hier leuk bij staat?”
In het voorbeeld links gaat het om de artikelen die vaak door mensen worden bekeken in relatie tot het artikel dat jij nu aan het bekijken bent.
Amazon maakt hier ook gebruik van door te laten zien welke boeken vaak in combinatie worden gekocht met het boek dat jij nu bekijkt of koopt.

Deze fase is in volle bloei en e-commerce / webshops maken hier dankbaar gebruik van door mensen te inspireren op hun zoektocht naar het juiste artikel.

Het grote nadeel van “recommendation” engines is dat het de diversiteit beperkt. Je krijgt alleen te zien wat veel wordt gezocht of gekeken. Hierdoor zul je dus minder verrast worden. Alles wordt “mainstream” omdat je gebruik maakt van de “knowledge of the crowd” en unieke zoekvragen of combinaties komen te weinig voor om opgemerkt te worden.

Fase 4a: Zoeken in “context” door bronnen

Eerder werd de mogelijkheid geboden om informatie te filteren nadat de zoekvraag was gesteld. Je begint in feit met de hele berg informatie of producten en navigeert / filtert je een weg naar de juiste verzameling.

Wat we echter steeds meer zien, is dat de zoekvraag van de gebruiker in “context” wordt uitgevoerd, of dat je in ieder geval de mogelijkheid hebt om een “context” aan te geven.

In eerste instantie werd de houvast geboden om te kiezen welke “bron” van informatie je wilt doorzoeken. Naast de inperking van de zoekvraag vanaf het eerste begin, geeft dit de bezoeker of gebruiker ook gelijk zicht op de aanwezige verzamelingen of indeling van informatie.

 

 

Fase 4b: Zoeken in “context” door categorieën

Zeer nauw gelieerd aan het bieden van context door de “bron” aan te geven, is het contextueel zoeken binnen categorieën. In essentie is dit mechanisme gelijk als het aanbieden van context of bron, het vergt echter meer aandacht voor de indeling en het kost meer tijd om deze structuur toe te passen.

Uit welke bron iets komt is meestal makkelijk te bepalen. Tot welke categorie iets behoort moet worden beoordeeld en daarna toegewezen.

Deze structuren komen vrijwel altijd overeen met de algemene indeling van de website (generieke informatie-architectuur). Wanneer je naar de sectie “Gift cards” bent genavigeerd, en je gaat daar zoeken, dan kan de contextuele zoekopdracht dit gegeven meenemen in de zoekvraag. Je doorzoekt dan dus niet weer de hele website, maar alleen het deel waar je geïnteresseerd in bent.

 

 

Fase 4c: Zoeken in “context” via personalisatie

De “holy grail” van zoeken en vinden is ervoor zorgen dat je informatie automatisch krijgt aangereikt op het moment dat je er behoefte aan hebt.
Die behoefte kan expliciet zijn (je zit in een bepaald proces of activiteit), maar zeker ook impliciet (“heeft u hieraan gedacht?”).

Wanneer we spreken over personaliseren, dan gaat het om de volgende gegevens:

– Locatie
– Zoekhistorie
– Klikgedrag (zoals zoekresultaten, maar ook aankopen)
– Persoonlijke omstandigheden (leeftijd, geslacht, taal)

Een goede zoekoplossing houdt rekening met deze personalisatiekenmerken en probeert hier op een slimme manier gebruik van te maken.

In het voorbeeld links staan twee kaartjes. Op het moment dat Google mijn locatie niet kent en ik zoek op een bepaalde plaatsnaam, dan zal de applicatie mij de kaart van de meest (voor Google) logische of populaire plaats op de wereld laten zien.
Wanneer mijn huidige locatie echter bekend is, dan zal dat gegeven worden betrokken in de zoekopdracht naar de plaats die ik heb opgegeven en zal Google mij de kaart van de plaats laten zien die geografisch het dichtst bij ligt.

Een ander voorbeeld betreft reclame-uitingen op websites. Om effectief te zijn moeten deze zeer specifiek worden afgestemd op een doelgroep. In de afbeelding zijn drie reclame-uitingen te zien die allemaal van dezelfde website komen en die in basis dezelfde content bevatten. De manier waarop de boodschap wordt verpakt is echter zeer verschillend. Als je naar de site gaat als je in America bent, dan krijg je de eerste intro te zien.
Ben je in Japan, dan verschijnt er een totaal verschillende boodschap. “Retail” in america wordt geassocieerd met het verkopen van fruit en kleding. Voor Japan wordt een “high-tech” plaatje gebruikt.

Als laatste het voorbeeld van de reclame’s die je te zien krijgt wanneer je gebruik maakt van GMail. Deze reclames zijn niet alleen gebaseerd op de inhoud van de e-mail die je aan het lezen bent. Google maakt zeer slim gebruik van je zoek- en klikgedrag op Google.com om deze reclames te tonen.

Het grote nadeel van “personalisatie” op basis van wat je in het verleden hebt gedaan,  is dat het de diversiteit en verrassingen beperkt. Soms wil je geïnspireerd worden door iets nieuws of je bent gewoon niet meer die persoon van een aantal jaren geleden omdat je bijvoorbeeld van baan bent gewisseld. Een machine kijkt naar wie je was en niet naar wie je wilt worden!

Fase 5: Embedded Search

In een volgend artikel sluit ik deze serie af met een beschrijving van de “next big thing” in search, nl. de Search Based Applications oftwel “Embedded Search”.

 

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….