Posts in "User Experience"

Tips om een goede offerte te maken

Als je een technische product of dienst verkocht wil krijgen is het kunst om je aanbod op een verstaanbare manier uit te leggen. Een offerte lezen zou leuk moeten zijn, maar het is vaak anders.

Het kiezen van een softwareleverancier, webbouwer of appdeveloper die past bij jouw noden is een vak op zich geworden. Ik begeleid vaak organisaties bij het conceptualiseren van ideeën en het beschrijven van de gewenste oplossing. Deze voorstudie resulteert in een functionele analyse en een bestek of offertevraag voor een nieuw te ontwikkelen product en dat is de eerste stap naar een goede offerte of prijsvraag.

Een duidelijke offertevraag
Een voorstudie is belangrijk omdat een realistisch prijsvoorstel afhangt van hoe goed je als klant kan uitleggen wat je nodig hebt. Het zorgt dat potentiële ontwikkelaars beter weten wat van hen verwacht wordt zodat je een realistische inschatting van de oplossing en de prijs krijgt waardoor je de verschillende voorstellen correct kunt vergelijken.

Is het bestek of de offertevraag onduidelijk dan riskeer je in de situatie te komen dat ontwikkelaars jouw idee gaan vormgeven op een manier dat het voor hen goed uitkomt. Bevat het bestek te veel details dan mis je mogelijk het innovatiepotentieel en de creatieve inbreng van de ontwikkelaars. Het ‘waarom’ van een productvraag is daarom minstens even belangrijk als het ‘wat’.

Kiezen op basis van offertes

Na het uitsturen van een offertevraag komt een volgende fase die evident lijkt: de offertes komen binnen, je leest ze en kiest op basis van een aantal criteria (aanpak, prijs, planning, technologie, referenties) het beste voorstel. In de praktijk blijkt dat echter niet altijd evident. Eén van de oorzaken is het feit dat er vaak standaardoffertes uitgestuurd worden. Standaardteksten, hoe goed ze ook mogen zijn, geven een slechte indruk. Het komt over alsof je geen tijd wil nemen, je niet geïnteresseerd bent in de klant of dat je met zo weinig mogelijk inspanning zoveel mogelijk wil verkopen. Standaardoffertes herken je meteen, ze tonen weinig respect voor de potentiële klant. Het tonen dat je een offertevraag, een klant of een sector begrijpt is de basis van een goed prijsvoorstel. Een softwarebouwer is geen bakker die dezelfde broodjes aan veel verschillende soorten klanten kan verkopen.

Hoe maak je een offerte die graag gelezen wordt?
Omdat ik veel offertes lees, heb ik een aantal tips waarvan ik hoop dat ze gevolgd worden. Het zal mijn werk (en zeker ook dat van anderen) nog aangenamer maken.

inhoudelijk

  • toon aan dat je de vraag goed gelezen en begrepen hebt
  • start met het belangrijkste deel van de oplossing
  • gebruik zo weinig mogelijk vakterminologie
  • zorg voor tekst op maat
  • zeg waarom je graag zou samenwerken

vormelijk

  • zorg voor genummerde pagina’s (ja, lange offertes worden soms afgedrukt)
  • zorg voor een leesvriendelijke opmaak
  • zet algemene informatie in bijlage (niets zo vervelend als de essentie te moeten zoeken)

Wat de lezer in één oogopslag terug wil vinden

  • De totaalprijs
  • De prijs per fase of onderdeel
  • Het onderscheid tussen éénmalige en terugkerende kosten
  • De dagprijs voor verschillende expertises (indien relevant)
  • Inschatting van de doorlooptijd
  • Een planningsvoorstel (incl. migratie indien van toepassing)
  • Verwachte input van de klant
  • Garanties, eigendomsrechten en informatie over service level agreements (indien van toepassing)
  • Referenties

Een offerte maken kost tijd

Zelf maak ik vaak offertes en ik doe dat graag. Het geeft me de kans om een aanpak te motiveren waar ik achter sta, om me in te graven in de vraag of het probleem en om de best mogelijk aanpak te beschrijven. Dat wil zeggen dat je al een deel van het werk doet vooraleer je weet of je hiervoor betaald zult worden. Al van bij de offerte start het proces om iets wat complex is te vereenvoudigen, en dat kost tijd.

Inlevingsvermogen

Usability is niet enkel een zaak van websites. Als je kiest voor klantvriendelijkheid is dat een manier van leven en werken. In elk document, elke e-mail, elk stukje tekst en elk gesprek krijg je de kans om te tonen dat je begrijpt hoe de ontvanger redeneert. Ik geef toe, dat is niet altijd gemakkelijk.

Wat is het verschil tussen een native app en een web app?

Een jaar na de eerste iPhone werd in 2008 de App Store (en daarmee ook het woord app) geïntroduceerd. Het begrip app store stond toen voor de online winkel met software voor smartphones van Apple. Ondertussen zijn er veel meer mobiele toestellen dan enkel de iPhone, zijn er meerdere app stores dan enkel die van Apple, is het woord app niet langer gereserveerd voor mobiele apps en is het verschil tussen een website en een app kleiner geworden.

Sta je op het punt om in de ontwikkeling van een app te investeren? Dan is het goed om het verschil tussen een native app en een web app te kennen.

Wat is een native app?

Een native app is specifiek voor een bepaald besturingssysteem ontwikkeld en daardoor enkel bruikbaar op toestellen met dat besturingssysteem. De meest bekende besturingssystemen voor mobiele toestellen zijn: iOS (Apple), Android (Google), Windows Phone (Microsoft) en BlackBerry (BlackBerry).

Een native app die bijvoorbeeld speciaal voor iOS ontwikkeld is, kan niet gebruikt worden op toestellen met een ander besturingssysteem. Vermits iOS vandaag nog verschilt met OS X (het besturingssysteem van Apple-computers) werkt een iOS app enkel op mobiele toestellen van Apple. Meer nog, een iOS app die ontwikkeld is voor iPhone werkt alleen echt goed op een iPhone. Om dezelfde app ook voor iPad of Apple Watch bruikbaar te maken, zijn er specifieke ingrepen nodig.

Hierdoor kan het ontwikkelen van een native app erg duur worden. Stel dat je een app wil lanceren die op alle smartphones werkt, dan is het nodig om er minstens 3 te ontwikkelen:  1 voor iOS, 1 voor Android en 1 voor Windows Phone. Wil je dat diezelfde native app ook werkt op tablets, computers en smartwatches? Dan moet er voor elk van deze combinaties bijkomend geïnvesteerd worden.

Om een app vervolgens bij het publiek bekend te maken is het nodig om die aan de verschillende app winkels door te geven: App Store (iOS en OS), Google Play (Android), Windows Phone Store (Windows phone), Windows Store (Windows), BlackBerry World (BlackBerry), Ovi Store (Nokia). Elke store heeft eigen voorwaarden en regels. Die regels zijn van technische, organisatorische, juridische en financiële aard. Concreet kan dit betekenen dat een native app voor iOS niet door de strenge procedures van Apple geraakt en je duur ontwikkelde app daardoor niet bij het bedoelde publiek geraakt.

Wat is een web app?

html5_vs_native

Met een web app wordt verwezen naar software die ontwikkeld is om in de browser te gebruiken. Dat wil zeggen dat een browser (Google Chrome, Firefox, Safari, Internet Explorer, …) en een internetverbinding volstaan om de app te gebruiken. Als de web app op een goede manier ontwikkeld is (responsive design, html5, cross-browser compatibility…) dan zal die onafhankelijk van het besturingsysteem en het type toestel werken op alle apparaten met een browser en internetverbinding. Het is niet nodig om verschillende apps te ontwikkelen, en je hoeft niemand om toestemming te vragen om de app gepubliceerd te krijgen.

Een web app is eigenlijk hetzelfde als een website. De term web app wordt vooral gebruikt voor complexere websites die functioneren zoals software (bv. berekeningen uitvoeren, dynamisch visualiseren van gegevens, …). De grens tussen een website en een web app is aan het vervagen. Je zou kunnen stellen dat elke website een web app is of elke web app een website.

We zijn van web apps beginnen spreken omdat we alsmaar meer zaken kunnen doen via de browser. Bepaalde software die vroeger op onze computer geïnstalleerd werd, wordt nu als een webbased online service (SaaS, of Software as a Service) aangeboden met de browser als client. Een project management tool zoals bv. Basecamp is volledig bruikbaar in de browser zonder dat er iets op je computer geïnstalleerd moet worden. In het geval van Basecamp kan je beslissen om toch een native app te installeren als je bijvoorbeeld met een notificatie op je smartphone verwittigd wil worden voor het afwerken van een taak.

Basecamp heeft er als bedrijf voor gekozen om een web app + native app te voorzien zodat de klant kan kiezen wat hij/zij wanneer het liefst gebruikt. Het platform geeft ook externe ontwikkelaars de mogelijkheid om te integreren met hun software. Dat wordt mogelijk gemaakt door extra investeringen in de ontwikkeling en documentatie van een interface voor developers (API). Grote bedrijven zoals Facebook, Twitter en Netflix passen dezelfde softwarestrategie toe waarbij het beste van de 2 werelden gecombineerd wordt. Vaak wordt hiervoor de techniek van een hybrid app toegepast (html5 verpakt in een native container).

Dat wil niet zeggen dat het voor iedereen en altijd nodig en haalbaar is om in te zetten op de combinatie van web en native ontwikkeling. Soms is het zelfs technisch niet mogelijk. Publiceren op Instagram kan bijvoorbeeld enkel met een native app omdat de software op zo’n manier geïntegreerd is met de camera van een mobiel toestel dat dit (nog?) niet lukt via een browser.

Vooraleer je de beslissing maakt om te investeren in een native app en/of web app is het nodig om goed te weten voor wie en voor wat de app bedoeld is en wat daarvoor nodig is. Daarna kan je een weloverwogen en financieel haalbare keuze maken.

Verschillen tussen een native app en een web app

Redenen om voor de ontwikkeling van een native app te kiezen

  • Integratiemogelijkheid met de GPS van een mobiel toestel
  • Integratiemogelijkheid met camera (foto, film, webcam)
  • Integratiemogelijkheid met microfoon (input en output)
  • Integratiemogelijkheid met notificaties
  • Integratie met andere native apps (bv. Instagram, adresboek, …)
  • Offline gebruik van de inhoud van een app (bv. e-boek lezen zonder internetverbinding, gamen zonder internetverbinding, …)
  • Beveiliging van de inhoud van een app (bv. e-boeken zijn moeilijker illegaal te downloaden als ze via een native app aangeboden worden)
  • Controle over hoe informatie en pagina’s getoond worden
  • Promotie via app-stores
  • Integratie met betaalmogelijkheden app-stores

Nadelen van een native app

  • Verschillende apps nodig per besturingssysteem en type toestel
  • Development expertise nodig per ontwikkelplatformen (vaak 3 verschillende developers of bedrijven)
  • Afhankelijkheid van snel evoluerende native software en hardware
  • Afhankelijkheid van de regels en mogelijkheden van een native platform: user interface, technologie, juridisch kader, financiële voorwaarden, verder bestaan van het platform
  • Hoge ontwikkel- en onderhoudskost
  • Gefragmenteerde en beperkte community van ontwikkelaars
  • Gesloten platformen, geen open source benadering
  • Een nieuwe versie van een app moet door elke gebruiker gedownload worden
  • De inhoud van een native app is niet goed zichtbaar in Google en andere zoekmachines

Redenen om voor het ontwikkelen van een web app te kiezen

  • 1 app werkt op alle toesten met een browser (onhankelijk van besturingssysteem en type toestel)
  • Grote community van ontwikkelaars
  • Open source benadering
  • Eindgebruikers hoeven niets te installeren om de app te kunnen gebruiken (mits browser en internetverbinding)
  • Iedereen gebruikt automatisch de laatste versie van de app
  • Minder dure ontwikkelkost in vergelijking met native app
  • Generieke development expertise (meer developers en bedrijven in vergelijking met ontwikkeling native apps)
  • Hogere zichtbaarheid van alle inhoud in Google en andere zoekmachines
  • Er is geen externe goedkeuring (van app-store eigenaars) nodig om de app te lanceren

Nadelen van een web app

  • Bij de ontwikkeling is kennis nodig van cross-browser compatibility (Google Chrome, Firefox, Safari, Internet Explorer, …) en recente webstandaarden (html5, responsive design, …)
  • Web apps die gebruik maken van recente technologie zijn niet altijd bruikbaar in oudere browser-versies
  • De app moet bruikbaar gemaakt worden op een enorme variatie aan schermgroottes (grote desktopscreens tot kleine smartphones), hiervoor is
  • Meer tijd nodig om een doorgedreven vereenvoudiging van te concipiëren voor eenzelfde ontwerp dat goed bruikbaar moet zijn op heel grote én heel kleine schermen
  • Minder controle over hoe eindgebruiker pagina’s en informatie te zien krijgt (bv. afhankelijkheid van schermresolutie)
  • Performantie kan een probleem zijn bij zeer complexe web applicaties zoals games
  • Geen promotie via app-stores

Deze opdeling is niet exact. Zo kan er met een browser ook al inhoud bewaard worden voor offline gebruik, kunnen er beperkte functies van hardware aangesproken worden, is het mogelijk om rekening te houden met de fysieke locatie van een gebruiker. Online betalen kan evengoed in een web app en ook notificaties al via de browser mogelijk. Maar als jouw app een combinatie van al deze specifieke functies op een betrouwbare of doorgedreven manier nodig heeft, dan is het vandaag nog aangewezen om voor een native app te kiezen.

Heb je een native app en/of een web app nodig?

Met een antwoord op deze vragen en bovenstaand overzicht kan je tot een beslissing komen:

  • Welk publiek wil je bereiken?
  • Wat wil je bereiken met de app?
  • Welke functies moet de app ondersteunen?
  • Hecht je belang aan systeem- en platform onafhankelijke oplossingen?
  • Op welke promotiekanalen wil je inzetten?
  • Wil je de investering via de app terugverdienen?
  • Wat is het budget dat aan de ontwikkeling besteed kan worden (rekening houdend met éénmalige en terugkerend kosten)?

De laatste vraag zal waarschijnlijk het best helpen om de knoop snel door te hakken. Twijfel je nog? Dan kan deze test misschien helpen.

Data als doel of middel?

Tijdens de vele jaren waarin ik als informatie architect bezig ben met het vormgeven van digitale diensten blijft eenzelfde spanningsveld terugkeren. Een spanning die het gevolg is van verschillende uitgangspunten: data en technologie als doel of als middel, verder bouwen op wat er is of opnieuw beginnen. Het komt vaak voor dat er tijdens een veranderingstraject discussie ontstaat over fundamenteel verschillende uitgangspunten.

Een situatieschets van 3 verschillende uitgangspunten:

  1. We zullen alle data die we doorheen de tijd gecreëerd hebben samenbrengen.
    Deze data zullen we verrijken met gegevens die vrij of tegen betaling beschikbaar zijn.
    Deze verrijkte dataverzameling is het uitgangspunt voor het bedenken van nieuwe vormen van dienstverlening.
  2. We bedenken een nieuwe vorm van dienstverlening en onderzoeken vervolgens welke data daarvoor nodig zijn.
    Deze data zullen we zelf creëren of afnemen van partijen die deze vrij of tegen betaling ter beschikking stellen.
  3. We onderzoeken de noden van ons publiek en gaan op basis daarvan (ver)nieuw(d)e diensten ontwikkelen.
    De data die daarvoor nodig zijn gaan we verzamelen of  zelf creëren.

Ook al lijkt het derde uitgangspunt het beste is het niet zo dat de twee andere fout zijn. Om te innoveren is het nodig om te experimenteren en daarvoor zijn de eerste twee opties soms meer voor de hand liggend. Het onderzoek dat genoemd wordt in optie 3 kan ook gebeuren door de combinatie van 1 en 2.

Het probleem ligt niet bij het kiezen van de juiste optie, maar wil in het feit dat er bij aanvang van een veranderingstraject vaak niet gekozen wordt omdat er een kader ontbreekt om beslissingen te nemen.

Open en linked data

De emancipatiestrijd van data en de semantische onderbouw van het web zorgden ervoor dat veel organisaties (terecht!) bezig zijn met het openstellen, hergebruiken en linken van datasets. Waarom zouden we het warm water opnieuw uitvinden, waarom data creëren en beheren waar iemand anders al mee bezig is, waarom lokaal denken als het web globaal is, waarom semantische relaties tussen data en objecten niet visualiseren? Het zijn maar enkele van de redenen om in te zetten op open en linked data.

Hackathons zijn de speelplaatsen voor data-nerds. Het is fantastisch dat er alsmaar meer speelplaatsen zijn! Tijdens de hackathons mag er gespeeld worden met (tijdelijk) vrij beschikbare data. Het is de eerste optie en het is duidelijk dat er uit dat spelen geleerd kan worden. Zowel de ontwikkelaars als de eigenaars van data steken veel op als er nieuwe producten mee gemaakt worden. Het uitpakken met technische data-hoogstandjes is de drijfveer voor de eerste twee uitgangspunten: nieuwe diensten op basis van beschikbare data. Ze resulteren vaak in virtuoze interfaces met een hoog wow-effect. Deze zijn nodig om al zoekend te innoveren. Een prototype dat losgelaten wordt op een publiek kan aantonen wat de goede en minder goede ideeën zijn.

Kiezen voor zekerheid of experiment

De eerste twee uitgangspunten impliceren dat er gekozen wordt voor experiment: hoe en welke data kunnen verrijkt worden, welke nieuwe vormen van dienstverlening zijn mogelijk? Experiment is nodig om te vernieuwen. Maar er stelt zich een probleem als de eerste twee uitgangspunten toegepast worden in een situatie waar ze niet als experiment bedoeld zijn.

Als je voor zekerheid wil kiezen dan is het nodig om te bepalen voor welk publiek je bezig bent en waar dat publiek behoefte aan heeft. Met deze kennis kan vervolgens beslist worden welke data nodig zijn om producten of diensten te ontwikkelen of verbeteren. Dat onderzoek kan in de vorm van experimenten opgezet worden. Het is jammer genoeg vaak zo dat de behoeften niet onderzocht worden en dat een ‘experiment’ opgezet wordt als hét nieuwe product voor de komende jaren. De gevolgen daarvan: hoge investeringen voor diensten waar niemand écht behoefte aan heeft of weinig gebruiksvriendelijk uitgewerkte interfaces.

Kiezen voor lange of korte termijn

De keuze om meteen voor écht te ontwikkelen heeft dikwijls te maken met een kortetermijnstrategie waarbij geredeneerd wordt dat iets nieuw bouwen op basis van wat er al is minder kost dan iets te onderzoeken met als kans dat er vanaf nul opnieuw gestart moet worden. Met kortetermijnstrategie is er op zich niets fout als er een langetermijnstrategie tegenover staat waarin de experimenten passen.

Een strategie bepalen

Alvorens in te zetten op een veranderingstraject is het van belang om een overkoepelende strategie te bepalen waarin experiment, productontwikkeling, korte en lange termijndoelen een plaats naast elkaar krijgen. Dat hoeft geen document van 100 pagina’s te zijn. Het vastleggen de design-principes of uitgangspunten voor het ontwikkelen van producten die voor jouw organisatie van belang zijn, kan volstaan als referentiekader om beslissingen te nemen.

Een website is geen project

We zijn er allemaal van overtuigd dat een goede en gebruiksvriendelijke website belangrijk is en toch kan je gemakkelijk voorbeelden vinden van websites die niet voldoen aan het verwachtingspatroon van eindgebruikers. Tijdens de vele jaren waarin ik betrokken ben bij het opzetten van digitale en online dienstverlening zie ik een aantal terugkerende oorzaken voor het feit dat het nog vaak de verkeerde richting uitgaat met de website. De meest voorkomende valkuilen zijn:

  • Niet écht weten waarvoor je klanten de website (willen) gebruiken
  • Niet weten hoe je klanten de (huidige) website gebruiken en wat ze ervan vinden
  • Beslissingen voor de bedrijfswebsite nemen op basis van persoonlijke gevoels- en smaakvoorkeuren
  • De totaaloplossing laten bepalen door de totaliteit van ideeën en wensen van mensen die niet behoren tot de doelgroep van de website (bv. interne medewerkers)
  • Het inspelen op trends of technologische vernieuwing als doel stellen van de website
  • Starten met ontwikkelwerk zonder dat er een online strategie is
  • De website niet zien als onderdeel van een totale online en offline dienstverlening
  • Starten met designwerk (stijl en kleuren) zonder dat de functionaliteiten gespecificeerd zijn en zonder dat er een informatie architectuur uitgewerkt is
  • De structuur van de website overeen laten komen met de interne/administratieve structuur van de organisatie in plaats van met echte gebruikersscenario’s of taken die eindgebruikers willen afwerken op de site (bv. het achterhalen van de openingsuren)
  • Verkeerde technologische keuzes waardoor vaak te laat blijkt dat het ontwikkelteam niet kan maken wat er écht nodig is
  • De ambitie om alle functionaliteiten van een nieuwe website op dag één live te zetten
  • Een te lange implementatietijd achter de schermen
  • Interne discussies die tijdens het ontwikkelwerk nog ‘uitgevochten’ moeten worden
  • Alle beslissingen voor de website laten nemen door technische medewerkers
  • Het onvermogen om webbouwers, ontwikkelaars, designers en andere betrokkenen goed uit te leggen wat er nodig is voor jouw klanten
  • Het opdringen van keuzes door developers of bedrijven omdat bepaalde zaken beter aansluiten op hun technologie, kennis of voorkeuren
  • Verkeerde inschattingen over budget, personeelstijd, benodigde expertises, ….
  • Het inzetten van de verkeerde competenties of een gebrek aan specifieke expertises
  • Verkeerde keuze van technologie waardoor te laat blijkt dat er niet kan ontwikkeld worden wat écht nodig is
  • Meer aandacht voor het uitzicht dan voor de functionaliteit en gebruiksvriendelijkheid
  • Geen incrementele verbeteringen doorvoeren op basis van eindgebruikersfeedback of -testen
  • Tekst op de website niet aanpassen aan hoe bezoekers zich al ‘scannend’ in plaats van ‘alles lezend’ bewegen op een website
  • Het ontbreken van een intern beleid en werkkader (digital governance) rond digitale diensten en online aanwezigheid
  • De datum waarop de website live gaat als einddatum van het ‘website-project’ zien

Eén van de meest voorkomende valkuilen is misschien wel het feit dat het opzetten van een website als een tijdelijk project gezien wordt. Het gevolg daarvan is dat medewerkers voor een bepaalde periode ‘vrijgemaakt’ worden om bezig te zijn met de website waardoor er geen tijd ingepland wordt om het werk inhoudelijk en functioneel up-to-date te houden vanaf de échte start: als er bezoekers op de website komen. Die live-bezoekers zijn de eerste echte testers van je website. Wat zij ervaren en doen is waardevolle informatie om de website beter te maken.

Hulp of advies nodig bij het verbeteren of vernieuwen van een website? Kijk wat iStoires Services voor jou kan betekenen.

Auto complete en auto suggest

Van gelijk welke digitale of online zoekomgeving verwachten we hetzelfde gebruiksgemak als wat we kennen van Google. De relevantiesortering en personalisering bij Google hebben ons doen geloven dat het beste antwoord bovenaan op de eerste pagina van een zoekresultaat staat.

Het gebruiksgemak bij het zoeken via Google heeft niet enkel met de sortering van de resultaten te maken. Het begint al bij het intikken van de eerste letter van je zoekterm. Door het presenteren van suggesties lijkt het alsof Google binnen de seconde al weet waarnaar je zoekt. Het is alleen nog een kwestie van die term te selecteren en hup daar staan instant de antwoorden.

Bovenop de zoektermsuggesties die er sinds 2008 zijn, is Google in 2010 gestart met met instant search. Bij instant search wordt extra feedback gegeven door de zoekresultaten bijna realtime aan te passen tijdens het intikken van een zoekvraag. De meeste mensen lezen sneller dan ze typen. Wie blind typt kan dus tijdens het zoeken de pagina met resultaten scannen (diagonaal lezen) en op basis daarvan meteen de zoekterm bijsturen. Het klikken op een knop om het zoeken te starten is niet meer nodig. Als de termsuggesties juist zijn is tikken zelfs bijna overbodig geworden.

Using Google Instant can save 2-5 seconds per search
Bron

We kunnen ons bijna niet meer voorstellen dat het ooit anders werkte op Google. Meer nog, Google heeft ervoor gezorgd dat we van gelijk welke andere zoekomgeving dezelfde ondersteuning verwachten. We gokken niet graag naar de juiste schrijfwijze van een naam. Als we niet geleid worden, worden we misleid doordat een foute schrijfwijze doet lijken alsof er niets te vinden is.

Niet elke zoekomgeving heeft evenveel data als Google en dat maakt het moeilijk om te bepalen hoe zoek-ondersteuning het best geïmplementeerd kan worden. De 2 meest gebruikte configuraties zijn:

Auto complete

Een auto complete wordt opgezet om suggesties te geven uit een (meestal gecontroleerde) lijst van termen waarvan het begin exact overeenkomt met de zoekterm.

Auto suggest

Het doel van auto suggest is om een ​​vrijwel onbegrensde lijst met gerelateerde zoekwoorden en zinnen voor te stellen die al dan niet exact overeenkomen met de zoekterm.

auto suggestauto complete

Gelijk welke implementatiemethode vereist dat er een uitweg voorzien wordt zodat je ten allen tijde ook de exacte zoekterm -zonder gebruik te maken van de suggesties- als query kunt lanceren. Bij Google worden auto suggest en auto complete gecombineerd met een gepersonaliseerde sorteerlogica. Probeer dit maar eens te evenaren. Als het niet lukt, kan je ook overwegen om je data goed te laten indexeren door Google en zo onrechtstreeks gebruik te maken van de functies en de snelheid die we daar gewoon zijn.

De UX-principes van Google

Het werkgebied van User Experience kan het best omschreven worden als het zoeken naar methodes om impact te krijgen op menselijke emoties bij het gebruik van softwareprogramma’s, websites, een webwinkel of gelijk welke online dienst.

User experience (UX) involves a person’s emotions about using a particular product, system or service.
Bron: Wikipedia

Wat je bij software moet doen om van punt A naar B te geraken, hoe de tekst geschreven is die ons moet leiden, het zijn maar 2 van de vele interactie-aspecten die van belang zijn in een ontwerpproces. Als deze interactie menselijk aanvoelt dan zullen we het product of de website graag gebruiken. Google volgt enkele principes waaraan al hun producten moeten voldoen. Vanaf het begin tot vandaag proberen ze trouw te blijven aan deze filosofie. De manier waarop Google, samen met enkele andere groten de richting van het web bepaalt, is een voortdurende uiting van het extreem toepassen van hun basisfilosofie die samengevat is in deze “10 things”:

  1. Focus on the user and all else will follow
    Doe wat de eindgebruiker wil en de rest gaat vanzelf. Simpel toch? Maar hoe kan je die eindgebruiker tevreden maken, en wie is die eindgebruiker? Of, wie wil je dat die eindgebruiker is en waarmee wil je hem of haar tevreden maken? Hoe specifieker je deze vraag kunt beantwoorden, hoe beter je product zal zijn.
  2. It’s best to do one thing really, really well
    Veel websites zijn gemaakt met de ambitie om een aantal verschillende dingen te doen. Dat heeft dikwijls als gevolgd dat alles een beetje goed is, maar vooral ook dat je moeilijk in een oogopslag te weten komt wat je kunt doen en hoe alles in elkaar zit. Hoe sneller het doel van een website duidelijk is, hoe liever je bezoekers er zullen zijn. Dit principe kan je over de hele lijn doortrekken: ook een webpagina is gebaat bij één duidelijke focus. Eén boodschap per pagina brengen betekent keuzes maken over wat je weglaat. 
  3. Fast is better than slow
    Als je website traag is mag al de rest nog zo goed en mooi zijn. Als het traag werkt, zal de gebruikerservaring in zijn totaliteit als slecht beoordeeld worden.
  4. Democracy on the web works
    Google heeft het hierbij vooral over de volgorde waarin hun zoekresultaten gepresenteerd worden. Een website wordt hoog geranked als er veel anderen zijn die naar de website verwijzen. Het publiek beslist dus mee over wat het belangrijkste is.
  5. You don’t need to be at your desk to need an answer
    Het web en de toestellen waarmee we surfen zijn meer mobiel geworden. Als de dienst die je online brengt daar geen rekening mee houdt dan verlies je een (alsmaar groter wordend) deel van je potentiële publiek.
  6. You can make money without doing evil
    Google is business. Je kan adverteren tegen betaling, maar ook hier zijn principes vastgelegd die rekening houden met de basisfilosofie. Bij Google worden advertenties alleen getoond als er een verband is met de zoekvraag. De adverteerder weet dus niet op voorhand hoeveel keer zijn advertentie zal getoond worden, want de eindgebruiker blijft ook hier de hoofdrol spelen.
  7. There’s always more information out there
    Google streeft compleetheid na en is daarom voortdurend op zoek naar onontgonnen terrein. Dat ze ook boeken uit bibliotheekcollecties scannen past in deze ambitie.
  8. The need for information crosses all borders
    De volledige wereld en elke taal, dat is het werkgebied voor Google. Daarvoor hebben ze kantoren in meer dan 60 landen en onderhouden ze bijna 200 internetdomeinen in 130 verschillende talen. De  ontwikkeling van Google Translate kadert in deze ambitie.
  9. You can be serious without a suit
    De bedrijfscultuur van Google is informeel, en ook dat is deel van de basisfilosofie. Het doel? Creativiteit bevorderen en de juiste medewerkers blijven aantrekken.
  10. Great just isn’t good enough
    Een goed product is een startpunt en geen eindpunt. Als je het kunt waarmaken om een goed product voortdurend te verbeteren, dan pas kan je je onderscheiden van wat anderen doen. Nooit tevreden zijn is het motto.

Finding an answer on the web is our problem, not yours.
Ultimately, our constant dissatisfaction with the way things are becomes the driving force behind everything we do.
Bron: Ten things we know to be true

Heb jij voor wat je online doet een basisfilosofie? Als het nog niet zo is, leg het dan vast. Want eens je bezig bent geraak je snel afgeleid van je oorspronkelijke doel. Soms wil je iets snel in orde hebben of is er een technisch obstakel of kost iets teveel en voor je het weet ben je aan het afwijken van je wat je wou bereiken. En als het doel niet duidelijk is, dan zal de gebruikerservaring ook niet goed zijn.

Waarom digitaal lezen niet altijd leuk is

Het is eigen aan een tijd van veel technologische verandering dat de technologie een gespreksonderwerp is. Een bewijs daarvan zijn de duizenden artikelen en meningen over tablets en e-readers. Goed dat hierover geschreven wordt, maar uiteindelijk is die technologie ondergeschikt aan de leeservaring. Wat we denken, doen en voelen bij het gebruik van een toestel is bepalend voor echte verandering.

Oliver Reichenstein beschrijft in een artikel van 14 leesminuten hoe digitale leeservaringen verbeterd kunnen worden. Enkele van zijn bevindingen worden hieronder geciteerd.

Een boek openen en lezen
Een verschil tussen analoog en digitaal lezen is de complexiteit die we moeten overbruggen om een tekst te “bereiken”. Op een leestoestel moet een boek geopend worden volgens de logica van een apparaat. Op het internet moet naar tekst genavigeerd worden volgens een logica van de website-maker. Als we een digitale tekst bereiken, voeren we meer synchrone handelingen uit dan bij het vasthouden van een boek en het omdraaien van papier. We lezen onder andere daardoor nog altijd sneller op papier dan digitaal.

If you are reading online, you descend multiple levels to reach the text. How much more complexity do you need once you reach the ultimate text layer? Why is it that once we reach the text, we hardly stay there for more than a couple of minutes?

Content-architectuur
De vormgeving en organisatie van content bepaalt of we ons graag, comfortabel en geconcentreerd door een tekst bewegen. Een boek zonder lege pagina voor het echte begin is als een huis zonder inkomhal. De cover van een boek kan even bepalend zijn als het uitzicht van een gebouw om het verschil te maken of je er wel of niet binnen wilt stappen. De samenvatting op de achterflap speelt een rol bij het kopen en lezen. De inhoudstafel is een houvast voor en tijdens het lezen zoals dat ook zo is met de bewegwijzering in grote ruimten. Ooit had ik het voorrecht om een roman-manuscript te lezen die in pakketjes verspreid over de tijd in mijn mailbox kwam. Ik heb de documenten niet afgedrukt maar digitaal gelezen. Het was niet het digitale lezen wat me in de war bracht maar het ontbreken van architectuur om het boek als een totaalervaring te beleven.

In books the transitions between the different levels or frames are clearly separated with empty pages. They act like airlocks. You know when you enter a new level, and when you leave it.
Just like a digital text, a printed text is embedded in different invisible frames through which you need to cross to get to the body text. There are various ways to embed text in a book, magazine or pamphlet.

Lezen is focussen
Lezen is een vorm van luisteren. Om goed te luisteren zijn ruimte en omgeving even belangrijk als de manier waarop iets verteld wordt. De vorm is naast de inhoud van belang om te kunnen focussen.

To be able to design a better reading experience at the most basic level, we have to understand how to bring digital reading into a form of continuity. And to get there we need to find out what makes and breaks continuity.

Zoals Oliver Reichenstein beschrijft is het niet zo dat het kopiëren van analoge leesmodellen de perfecte digitale leeservaring oplevert. De extra navigatiemogelijkheden die online mogelijk zijn, hoeven niet genegeerd te worden om een gefocuste leeservaring te designen.

De basis moet goed zitten
Veel digitale content mist een goede toepassing van de basis-elementen: leestypografie, bladspiegel en focus op tekst. Het is niet nodig om een blad papier na te bootsen. Het is zelfs niet nodig om het draaien van een blad papier na te bootsen. Er is wel meer aandacht nodig voor de opmaak en presentatie van tekst. Comfortabel lezen vraagt voldoende  ruimte tussen de letters en de tekstregels. Blanco ruimte naast de tekst is belangrijk. Niet elk lettertype leest even gemakkelijk. Verwijzingen naar 101 dingen die niet relevant zijn om de tekst zelf te begrijpen leiden af. Te kleine letters zijn vermoeiend om te lezen. Een slecht kleurcontrast tussen tekst en achtergrond doet lezers afhaken, … En niet te vergeten: grammaticaal gebruik van hoofdletters is van belang. (Ja, er zijn designers die hoofdletters niet mooi vinden, maar alleen kleine letters of alleen grote letters zijn vermoeiend om te lezen. Echt waar.)
Het is geen oplossing om alle opties instelbaar te maken en het leesdesign over te laten aan eindgebruikers. Wat er mooi uitziet is niet altijd hetzelfde als wat ergonomisch interessant is.

Good typography does not look nice to please type nerds. Primarily, well set type reads well. It captivates, leads along, and doesn’t let you escape: it creates continuity.”
“In a well crafted book every single letter has its correct position in the whole of the text body to guarantee maximum readability and — through this — continuity of the reading experience

Readability to the rescue
Het is vreemd om te zien hoeveel er geïnvesteerd wordt in online content en hoe weinig deze inhoud op een volwaardige manier gepresenteerd wordt. Waarom teksten produceren om ze te publiceren op pagina’s waar de tekst met moeite vindbaar is? Waarom wordt een webpagina ingedeeld in 10 of meer publicatiezones? (Ja, bekijk maar sommige blogtemplates. En inderdaad, ook deze tekst kan beter gepresenteerd worden.)

Ik gebruik vaak Readability om een online tekst beter te kunnen lezen. Met de “Read Now” optie van de Readability-browser plugin wordt de tekst van een webpagina op een leesbare manier getoond.Het is een oplossing. Maar het is een extra stap die ik liever niet nodig zou hebben.

 

Moeder, waarom zoeken wij?

Zoeken is mijn passie en beroep. Het boeit mij om na te denken over de snelste manier om dingen te vinden. Of, hoe je tijdens een zoektocht interessante dingen kunt tegenkomen die je niet zocht. Bibliotheken waren voor mij lange tijd de speelplaats om me al zoekend-naar-antwoorden of nieuwe dingen uit te leven. Op de bibliotheekschool heb ik geleerd hoe erg er nagedacht is over ordeningssystemen om het zoeken in grote collecties te vereenvoudigen. Tijdens mijn werk voor de bibliotheeksector heb ik mee nagedacht over die systemen en ze vertaald naar zoekoplossingen voor het internet. Als informatie architect in een webbedrijf heb ik mijn speelveld verruimd naar alle sectoren die gegevens met een specifiek doel publiceren op het internet.

Wat me vandaag het meeste boeit, is het achterhalen van zoekintenties. Waarom surft iemand op het internet? Wat willen mensen doen of zoeken op een specifieke website? Hoe kan je daarop inspelen? Kan je iemand zijn intentie veranderen? Evolueert ons zoekgedrag door trends, of zijn trends het gevolg van een evoluerend gedrag? In een sector waar verandering de enige constante is, kan je leren uit het zoeken naar de constantes die schuil gaan achter die veranderingen. Alles wat we doen, doen we met een bepaalde intentie. Dat is ook zo op het internet. Enkele constantes in ons gedrag op het internet zijn:

  • Known item searches: ik weet exact wat ik zoek
    Bv. ik wil via Amazon.com de gedrukte versie van de biografie van Steve Jobs in het Engels bestellen
    ik wil via de website van de NMBS zoeken wanneer de eerstvolgende trein van Gent naar Brussel vertrekt, …
  • Semi known item searches: ik weet ongeveer wat ik zoek
    Bv. ik zoek informatie over musea in Berlijn, ik wil mijn citytrip naar Berlijn online boeken, …
  • Discovery ik ben op zoek naar inspiratie
    Bv. ik wil mijn keuken herinrichten en zoek online naar inspiratie
  • Experiences: ik ben op zoek naar afleiding, sociale interactie, ontspanning, competitie, vrienden, …

Het is interessant om te beseffen dat je met slim georganiseerde websites een intentie kunt wijzigen. Amazon is daar het schoolvoorbeeld van: ook al weet je exact wat je wilt kopen, de kans is groot dat je (nog 2 of meer) andere dingen koopt omdat er ingespeeld wordt op de interesses die je blootgeeft met je zoekhistoriek en aankoopbeslissingen. Bij het zoeken naar inspiratie om je meubels te verplaatsen, bestaat de kans dat je beslist om een volledig nieuwe keuken te kopen. Het kan nog drastischer: tijdens het boeken van een citytrip naar Berlijn kan je afgeleid worden door een vacature in de reissector en online solliciteren in plaats van een reis boeken. Misschien was je echte intentie in dit geval het zoeken naar verandering in je leven.
Sociale media spelen in op de non-search experiences. Het zijn plaatsen waar je naartoe gaat als ontspanning, op zoek naar sociale interactie, … Het zijn ook de plaatsen bij uitstek die onze gedragsintentie beïnvloeden. Wat begint als het zoeken naar afleiding kan overgaan in het online kopen van een boek waarover iemand iets zegt op Facebook, het lezen van een artikel dat aanbevolen wordt door iemand uit je professionele netwerk, …

Een goed opgebouwde informatie architectuur houdt bewust rekening met menselijke intenties. Wat je vandaag ziet is nog te dikwijls gebaseerd op het kunnen of niet kunnen van de onderliggende technische structuur en/of de makers. Evengoed zijn het ook organisaties of bedrijven die niet duidelijk weten of kunnen kiezen op welke intentie(s) ze het meest willen inspelen en zich daardoor laten leiden door de mogelijkheden van bestaande systemen. Als resultaat hiervan krijg je producten waarvan het doel niet duidelijk is. Er wordt op alle intenties een beetje ingespeeld, en op elk scherm kan alles.
Mijn pleidooi is om meer te durven spreken over de menselijke aspecten. Nu de techniek nog zo weinig grenzen heeft.

Werelddag Informatie Architectuur 2012 in Gent

Het nadeel van zelf iets te organiseren, is dat je geen tijd hebt om er op tijd over te bloggen. Bij deze nog een laat schrijfsel over de Informatie Architectuurdag op 11 februari 2012 in Gent om te zeggen dat wie er niet bij was iets gemist heeft.

Eerst was er het idee om mensen samen te brengen die bezig zijn met informatie architectuur. Daarna bleek dat die behoefte er wereldwijd is en dat er zelfs een speciale dag voor bedacht is: the World IA Day.

Een website, enkele sponsors en tweets later hadden we een evenement met 75 inschrijvingen en 25 sprekers. Jammer voor de 20 laatsten, want die kwamen door het onverwachte succes en het daarbij horende plaatsgebrek op de reservelijst.

Die zaterdag op de Voorhavenlaan was -al zeg ik het zelf- een topdag. Wat ik eruit geleerd heb is dat zo’n dag opzetten veel tijd kost, maar dat het die tijd absoluut waard is. Vele mensen zijn in evenveel verschillende omgevingen met gelijkaardige dingen bezig en hebben de behoefte om daar met elkaar over te praten. Dat merk je op sociale media en die online gesprekken geven goesting om je virtuele collega’s ook in het écht te ontmoeten. En dat er maar een paar tweets nodig zijn om zoveel mensen op een zaterdag samen te brengen om over hun werk te praten is fantastisch toch?!

De sfeer

Met dank aan LBi

De inhoud

Enkele presentaties

Meer presentaties

Wat anderen schreven

Thomas Troch, Koen Verbrugge, Sven Demeyere, Ilse Jansoone, Gino Lardon

Dankuwel!

Bedankt aan alle sprekers, het keuken- en barpersoneel, de sponsors, cameramannen, fotografen, mijn collega’s geluidsmannen, netwerkbeheerders, moderators, portiers, en de geïnteresseerde, kritische, zeer kritische en minder kritische luisteraars.