Online Formulieren: Inline Validation

Retro Desktop ComputerEen tijdje terug zat ik ‘The Elements of User Experience‘ te lezen van Jesse James Garrett. Daarin sprak hij over de methodiek ‘Prevention -> Correction -> Recovery’ met betrekking tot het omgaan met bezoekers die tegen problemen aanlopen bij het gebruik van je site. Mijn gedachten dwaalde af naar online formulieren en hoe ik deze methodiek hierop zou kunnen toepassen. Form Validation was de term waarop ik mijn volgende blog artikel, deze dus, zou baseren.

Waar zijn we ooit begonnen met formulier validatie en waar zijn we nu? Laat ik bij het begin beginnen. Er was eens…. nee geen sprookje, maar als ik eerlijk ben, was mijn eerste ervaring met online formulier validatie met Server Side Validation. Als ik denk aan ‘server-side’ validatie, dan krijg ik flashbacks naar Nightrider, The A-Team en Jake and the Fatman. Ik denk persoonlijk terug aan een periode die ver achter ons ligt waar we nog naïef omgingen met bezoeker interactie op onze websites. Uiteraard was techniek leidend, maar ook de technici die de sites in elkaar sleutelden. Er werd nimmer gedacht aan de effecten van formulier validatie. Was je invoer fout, nou, dan wist je het wel. Met andere woorden, server side validatie is voor mij erg retro.

Van ‘server-side’ naar ‘client-side’

Network ServersHoe voorkom je onnodige calls naar de server? Hoe voorkom je het herladen van een pagina waarvan de inhoud kan bestaan uit foutmeldingen? Iets wat de bezoeker alleen maar kan irriteren. Met javascript validaties maakte de techniek een flinke vooruitgang. Door javascript validaties toe te voegen aan formulieren was het mogelijk om op het moment dat een bezoeker op het knopje ‘Verzend’ klikte (of andere events; zie: Webmonkey ) een validatie uit te voeren. Zo is de stap gemaakt van server-side validatie naar client-side.

Client-side betekent niks anders dan ‘op de computer van de website bezoeker’. Een nadeel van deze methode is, is dat alle gegevens voor de controle in een javascript meegestuurd moet worden met de pagina zelf. Voor formulieren geldt dus dat de controle verloopt via een bestand dat synchroon met de pagina zelf geladen wordt. Het controleren op het reeds bestaand gebruikersnaam, geregistreerde e-mail adres of verzilverde coupon is dus niet mogelijk, laat staan tijdens de invoer hiervan.

AJAX maakt zijn entree

AJAX (Asynchronous JavaScript and XML) is een techniek wat al eigenlijk sinds de jaren ’90 bestaat. Op Wikipedia wordt AJAX omschreven als:

AJAX is een term voor het ontwerp van interactieve webpagina’s waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Daardoor hoeven dergelijke pagina’s niet in hun geheel ververst te worden. De term is op 18 februari 2005 door Jesse James Garrett gelanceerd en werd door grote bedrijven als Google en Amazon overgenomen.

Validatie in combinatie met AJAX is voor formulieren dan eigenlijk te definiëren als validatie op steroids. Door het asynchroon opvragen van gegevens kunnen deze in het geval van formulieren gecontroleerd worden tijdens de invoer. Leuke voorbeelden hiervan zijn:

De Telefoongids (http://www.detelefoongids.nl/) – bij het invoeren van ‘Waar’ worden er al suggesties gedaan voor plaatsnamen.

inlinevalidatie dtg

Google (http://toolbar.google.com/ geïntegreerde zoekfunctie in Firefox) – bij het invoeren van een zoekterm worden er al suggesties gedaan van meest voorkomende termen die overeenkomen met de invoer van de gebruiker

inlinevalidatie google searchbar

Twitter (http://www.twitter.com/) – bij het invoeren van een nieuwe gebruikersnaam wordt er al gecontroleerd of deze al in gebruik is of niet

inlinevalidatie twitter

Je artikel ging toch over Inline Validation?

Nu ik in het kort, ik ben namelijk geen über-techneut, heb uitgelegd wat enkele methoden zijn van valideren kan ik eindelijk beginnen aan het hoofd onderwerp “Inline Validation”. Zoals de term al duidelijk aangeeft is het een manier van validatie/controle wat tijdens het invullen van de velden van het formulier uitgevoerd wordt op invoerveld niveau door middel van AJAX (vaak in combinatie met CSS). De invoervelden van een formulier worden gecontroleerd op inhoud tijdens of na het invoeren. Het formulier wordt dus niet verstuurd naar de server.

Een leuk en simpel voorbeeld van validatie tijdens het invoeren is te vinden op Twitter. Bij het wijzigen van je gebruikersnaam wordt er tijdens het invoeren van je nieuwe gebruikersnaam gecontroleerd of deze beschikbaar is of niet. Aan de gebruiker om hem dan alsnog direct aan te passen:

Het bovenstaand voorbeeld toont op een simpele wijze de kracht van inline validatie. Tijdens het invoeren wordt er op de achtergrond, dus niet synchroon met het laden van de pagina zelf (dit heeft immers al plaatsgevonden), wordt de invoer gecontroleerd op geldigheid. Bestaat de ingevoerde gebruikersnaam al in ons database? Bij het invoeren krijg je dus meteen al te weten of de door jou gekozen gebruikersnaam gebruikt kan worden. Zo niet, dan kan je het meteen wijzigen naar een beschikbare gebruikersnaam. Je komt er snel genoeg achter welke gebruikersnaam wel beschikbaar is. Een duidelijk voorbeeld van ‘Prevention -> Correction -> Recovery’ zonder dat de pagina herladen hoeft te worden. Twitter krijgt van mij plus punten door ook aan te geven wanneer ik dezelfde gebruikersnaam in te voeren die ik al reeds gebruik. Een kleine maar positief element in de totale ervaring door een simpele ‘That’s you!’.

Een tweede voorbeeld is een voorbeeld van Inline Validation tijdens en na invoer, dus bij een blur (lost focus) javascript event, is te zien bij Picknick (http://www.picknick.com/).

In dit voorbeeld filmpje zie je volgende validatie stappen:

  1. gebruikersnaam wordt gecontroleerd op beschikbaarheid tijdens het invullen
  2. indien ingevulde gebruikersnaam reeds bezet is, geeft Picknick automatisch de optie om je wachtwoord op te vragen
  3. e-mail adres wordt wordt gecontroleerd op geldigheid tijdens het invoeren. nadat er minimaal 2 letters van de Top Level Domain ingevoerd zijn wordt de invoerveld voor het herhalen van je e-mail adres beschikbaar
  4. zodra je klaar bent met het invoeren van je e-mail adres en verder gaat naar de volgende veld via de ‘Tab’ knop of met een muis klik wordt de ingevoerde e-mail gecontroleerd tegen de database van Picknick. als het e-mail adres al voorkomt krijg je wederom de mogelijkheid om je paswoord op te vragen indien je dus al een account hebt bij Picknick

Dus, wat zijn jouw conclusies?

Conclusies zijn er niet echt. Ik ben sterk van mening dat elk formulier een eigen aanpak nodig heeft die zich specifiek richt op het doel van de formulier in combinatie met de overige elementen zoals zakelijke doelen, doelgroep etc. Wat ik wel graag zou willen geven, zijn 5 tips die hopelijk van pas kunnen komen.

Tip #1 Verwacht niet te veel van de bezoeker, regel het zelf!

Voorkom dat gebruikers zelf de validatie moeten initiëren door bijvoorbeeld te klikken op een link/button ‘controleer beschikbaarheid’. Een voorbeeld hiervan is te vinden bij YouTube (http://www.youtube.com/), echter maakt YouTube wel gebruik van een lost focus javascript event, dus ik zal ze wel een beetje ‘credit’ geven.

youtube username

Gebruik verwachte acties in de vorm van javascript events om de controles uit te voeren of gebruik de krachten van AJAX.

Tip #2 Controleer niet te vroeg!

Zelfs de groteheden onder de 2.0 websites maken wel eens een fout, zo ook Twitter bij het veranderen van de gebruikersnaam. Bij het leegmaken van de veld en de controle die op de achtergrond wordt uitgevoerd verschijnt het volgende:

Twitter Username Error

Als een invoerveld gecontroleerd wordt op de aanwezigheid van een geldig e-mail adres doe dit pas op het moment dat de bezoeker na het invoeren van een adres een volgend veld selecteert. Wil je tijdens het invoeren controleren, het echte inline validation, zorg dat je controle script pas een resultaat geeft nadat bijvoorbeeld minimaal 1 karakter is ingevoerd gevolgd door een ‘@’ teken is ingevoerd gevolgd door minimaal 2 karakters,gevolgd door een ‘.’ en gevolgd door minimaal 2 karakters. Volg je het nog? In principe moet het adres minimaal voldoen aan: a@aa.aa * Ik ben er van uitgegaan dat er geen DNS of SMTP validatie wordt uitgevoerd

Een voorbeeld van hoe het compleet mis kan gaan ben ik tegen gekomen op Remember The Milk (http://www.rememberthemilk.com/):

Tip #3 Wees coulant met invoer en formateer na afloop

Soms moet een invoer voldoen aan een bepaald formaat. Denk hier aan telefoonnummers, postcodes, maar ook bankrekeningnummers. Het voorbeeld wat ik wou tonen is er een van de Rabobank, waar ze bij het internet bankieren de invoer van het over te maken bedrag controleren nadat de bezoeker verder gaat naar de volgende invoerveld. Een bedrag wat als volgt wordt ingevuld “€31.75″ wordt gewijzigd naar “€31,75″. De punt wordt omgezet naar een komma. Rabobank doet dit zodat de verwerking naar hun toe dit vereist.

Maar pas op! Rabobank maakt een schoonheids foutje al ver voordat je in staat bent om geld over te schrijven. Bij het invoeren van je rekeningnummer hebben ze een vaste limiet ingesteld van het invoerveld van 9 karakters. Een rekening nummer zonder “.” punten. Ik ben net overgestapt van de ABN en was hett gewend met puntjes in te voeren, maar na 9 karakters in te hebben gevoerd, 4 cijfers / 1 punt / 3 cijfers / 1 punt was ik niet meer in staat de resterende 2 cijfers in te voeren.

Wees dus niet al te streng met de invoer en zorg voor veel mogelijkheden. Het formatteren van de invoer na afloop is vaak vrij simpel gedaan. Zorg er simpelweg voor dat de bezoeker, en in het geval van internet bankieren de klant, hier geen last van ondervindt.

Tip #4 Zijn er limieten of eisen aan een invoer, communiceer dit

Soms kan het voorkomen dat een invoer aan bepaalde eisen moet voldoen. Een goed voorbeeld hiervan, wat ook vaak in het voordeel is van de bezoeker, is het paswoord invoerveld. Denk terug aan het voorbeeld van Picnik. Bij het invoeren van de paswoord in het filmpje wat eerder in dit artikel verscheen zag je duidelijk hoe de paswoord minimaal 5 karakters moest hebben en dat de melding hiervan bij het invoeren van de zesde karakter verdween.

Tip #5 Wees vriendelijk en innovatief

Light Bulb - IdeaZoals je in het Picnik voorbeeld kon zien was de toon van de conversatie erg vriendelijk. Natuurlijk hangt dit af van de doelgroep waar jou dienst/product zich op richt. Naast de klantvriendelijke aard van de meldingen zijn ze toch ook erg innovatief geweest. Wat mij opviel:

  • De ‘Create Account’ knop was gedeactiveerd tot het moment dat alle velden correct waren ingevuld.
  • Bij het invullen van een bestaande gebruikersnaam, ging Picnik ervan uit dat je je gegevens vergeten bent en biedt direct aan je te helpen bij het opvragen van deze gegevens, in dit geval de paswoord.
  • Het paswoord moest minimaal 5 karakters lang zijn. Zodra er geconstateerd was dat er meer dan 5 karakters aanwezig waren verdween deze melding.
  • Het e-mail adres werd gevalideerd op echtheid (juiste structuur van een geldig e-mail adres) en of deze al stond geregistreerd. Zo ja, dan wordt er opnieuw aangeboden om je paswoord op te vragen.
  • Bij elke invoerveld die succesvol werd ingevuld verscheen er een paardenbloem in het zicht. Zelfs bij het uitvinken van de nieuwsbrief optie, maar toen werd er een paardenbloem verwijderd.

Reacties (14) Schrijf een reactie

  1. Kleine toevoeging: probeer de gegevens in het formulier zo goed mogelijk te valideren. Bij e-mail adressen kan gevalideerd worden of het opgegeven domein bestaat (let op: dit vereist werkende DNS servers) en bij Nederlandse bankrekeningnummers kan gebruik worden gemaakt van de Elf-proef. Voor heel veel vaste gegevens bestaan standaarden (creditcard nummers bijvoorbeeld).

    In het kort: probeer zoveel mogelijk te valideren, al tijdens het invullen. Het invullen van een lang nummer als een bankrekeningnummer gaat heel snel mis, als je daar gelijk al op controleert scoor je wat puntjes op je usability.

    Beantwoord

  2. [quote]
    … ik ben namelijk geen über-techneut …
    [/quote]
    Duidelijk, want wat jij client-side validatie noemt is in feite server-side validatie. Dat het gebeurd door gebruik te maken van AJAX doet het niet toe. De validatie wordt gewoon op de server gedaan. Sterker nog, client-side wordt niet eens serieus genomen door “echte” ontwikkelaars omdat simpelweg te omzeilen is door je ondersteuning voor JavaScript in je browser uit te schakelen … zwaak artikeltje …

    Beantwoord

  3. Nou nou, ik moet zeggen dat ik juist erg te spreken ben over je artikel. Al heeft poster 2 natuurlijk wel een punt. Maar om daar nou dit hele artikel op af te schieten.

    Goed en uitgebreid artikel. Die korte video fragmenten zijn trouwens een zeer welkome aanvulling.

    Beantwoord

  4. @vincent bedankt voor de toevoegingen. De Elf test zie je inderdaad vaak. Met creditcards weet ik alleen dat Visa met een 4 begint en Mastercard met een 5.

    @über-techneut je hebt gelijk. vanuit een bezoeker’s perspectief lijkt dit op client-side, zo komt het voor de niet techneut ook over *knipoog*. hoewel de validaties achter de schermen server-side verlopen, is de belevenis verre van.

    dat client-side niet eens meer serieus door ‘echte’ ontwikkelaren wordt genomen (javascript ondersteuning of niet) lijkt me erg stug. niet alle formulieren (of velden) hoeven namelijk met een server-side validatie gecontroleerd te worden en kan simpel weg nog met een client-side script uitgevoerd worden zoals e-mail (als je deze alleen op syntax controleert en niet cross-referenced met bestaande e-mailadressen) of simpel weg een controle op invoer van alle verplichte velden.

    het zijn juist dit sort uitspraken waardoor veel formulieren veel frictie bevatten. techneuten geven techniek liever voorrang, marketeers hun targets en interactie ontwerpers de gebruikerservaring. deze zouden allemaal samen moeten komen en achter een integraal oplossing gaan staan.

    maar toch bedankt voor je commentaar. ik zal het artikel aanpassen.

    @Thijs dank je. de video’s zijn gemaakt met Jing en maakt het wat makkelijker om formulier interactie te tonen.

    Beantwoord

  5. JavaScript kan aan en uit gezet worden op je browser (al weten veel gebruikers niet eens wat JavaScript is, laat staan hoe het uitgeschakeld kan worden). Als je dan vanuit gaat dat data die gevalideerd is via JavaScript, veilig is om verwerkt te worden aan de server-side (botweg 99,9% van alle web applicaties doen dat) houd je jezelf voor de gek. Er is geen enkele manier eens de data bij de server is gearriveerd om zeker te zijn dat deze data veilig is, … tenzij je het opnieuw aan de server-side valideert, wat maakt dus client-side validatie (vanuit deze perspectief dan) onbetrouwbaar en overbodig. De enige zin dat client-side validatie heeft is gebruiksvriendelijkheid, maar zelfs in dat geval moet de data worden gevalideerd aan de server-side.

    Of het om een e-mail adres gaat (je weet vast niet wat een “header injectie” inhoudt) of niet.

    Het gaat trouwens niet om een strijdje voeren tussen marketeers en techneuten. Het lijkt mij sterk dat een marketeer of een designer in de auto branche een discussie gaat voeren met een engineer over waar het beste een airbag geplaatst kan worden. De prioriteit is de veiligheid van de bestuurder, de rest komt daarna.

    Mocht je je willen verdiepen in de risico’s dat het bouwen van een web applicatie met zich meebrengt, nodig ik je uit om een kijkje te nemen op OWASP(www.owasp.org). Het is dus niet een kwestie van “voorrang geven aan de techniek” maar van een bruikbare en veilige applicatie, website, programma, whatever te kunnen (mogen) bouwen, zodat marketeers niet belemmerd worden door technische tegenvallen bij het halen van hun targets en de interactie ontwerpers zich volledig op de gebruikerservaring kunnen storten ;)

    Beantwoord

  6. Hoi Ãœber,
    Bedankt voor je uitgebreide reactie. Ik zal je eerlijk bekennen dat ik me inderdaad nooit zover heb verdiept in wat er allemaal komt kijken bij het bouwen van een applicatie op het niveau zoals jij omschrijft. Ik zal zeker gaan kijken op OWASP en zal zeker uitzoeken wat een “header injectie” is. Alle beetjes kennis helpen!
    Groeten,
    Matthew

    Beantwoord

  7. @matthew, goed artikel. Lijkt me erg vriendelijk in gebruik op deze manier. De filmpjes maken het helemaal duidelijk.

    @”uber-techneut, je zegt: “Het gaat trouwens niet om een strijdje voeren tussen marketeers en techneuten. Het lijkt mij sterk dat een marketeer of een designer in de auto branche een discussie gaat voeren met een engineer over waar het beste een airbag geplaatst kan worden. De prioriteit is de veiligheid van de bestuurder, de rest komt daarna.”

    Ik vind het erg naief dat je denkt dat veiligheid in de autobranche wordt gedreven door de techniek. Denk je echt dat er een airbag in een auto zou zitten als er geen markt voor was. Voor veiligheid willen mensen betalen en daarom wordt een airbag in een auto geplaatst en niet andersom.

    Ook vraag ik af wat je bedoeld met “zwaak artikeltje”?

    Beantwoord

  8. @jeroensijbom
    Niet alle technische toepassingen hoeven commercieël interessant zijn om geïmplementeerd te worden, en al zeker niet als het gaat om veiligheid. Als er bijvoorbeeld veiligheidsnormen vanuit de EU gedicteerd worden, dienen deze gewoon gevolgd te worden. Auto’s van Chinese makelij die in Europa verkocht worden dienen aan Europese veiligheidseisen te voldoen, bijvoorbeeld, of dat commercieël interessant is, of niet. Natuurlijk moeten ze wel uitvoerbaar zijn, maar dat is hier niet van toepassing. Server-side validatie is niet moeilijker, lastiger of kostbaarder dan client-side validatie. Het gaat dus om de veiligheid.

    Bij zwak artikeltje bedoelde ik precies dat. Het onderwerp is eigenlijk eerder een technische kwestie dan een kwestie van gebruiksvriendelijkheid. En als dat niet zo is, dan wel een kwestie van beide samen, met in mijn ogen, voorrang voor de technische kant van het verhaal.

    Ik heb me beperkt aan de veiligheid omdat ik denk dat dat al een sterke argument is waar rekening moet worden gehouden, maar er zijn nog meer technische implicaties van het “inline valideren”. Zo zou bijvoorbeeld een formulier met 15 velden, 15 verschillende requests naar de server moeten doen voordat het verzonden mag worden. Bij een drukke website, niet echt iets waar je zit op te wachten. Sterker nog, hoeveel formulieren worden deels ingevuld maar nooit verzonden? In al deze gevallen verspil je dus breedband (oftewel poen) terwijl dat niet nodig hoeft te zijn. Bij “traditionele” validatie hoef je maar een request te doen.

    AJAX is dan ook een techniek dat je dient te overwegen alvorens het blind te gaan implementeren, zoals overigens alle technieken in het algemeen. Het is geen “silver bullet” waar je opeens voor alles zou moeten gaan gebruiken.

    Beantwoord

  9. über-techneut zegt: “De enige zin dat client-side validatie heeft is gebruiksvriendelijkheid, maar zelfs in dat geval moet de data worden gevalideerd aan de server-side.”

    Gebruiksvriendelijkheid is toch een uitstekende reden om client-side te valideren? Bovendien zou ik het genereren van meer requests verkiezen boven afhakende klanten. Dat laatste kost namelijk een stuk meer.

    Verder lijkt mij dat client-side validatie server-side validatie niet uitsluit. Zoals je zelf zegt, client-side validatie verhoogt de gebruiksvriendelijkheid. En daar ging dit artikel over.

    Beantwoord

  10. @uber techneut en de rest:

    De juiste manier is gewoon als volgt:

    Valideer client side vanuit usability oogpunt en valideer na verzenden nog een keer server side. Daarbij maak ik de kanttekening dat die eerste client side validatie best server side kan gebeuren (maar wel inline is).

    Niet zo moeilijk toch?

    Beantwoord

  11. Zou toch wel een kanttekening willen zetten bij de gebruikersvriendelijkheid van het Picnik
    formulier. Uit veiligheids oogpunt lijkt het me niet altijd wenselijk dat je gebruikersgegevens
    uit je database gaat halen voor dit soort validaties.
    Als paranoide internetgebruiker zie ik dan binnenkort spambots misbruik gaan maken van dit
    soort functies om het bestaan van emailadressen te controleren.

    Beantwoord

  12. @matthew: Bedankt, mooi artikel er zitten wel degelijk nuttige tips tussen.

    Ook is het interessant hoe de validation plaatsvindt van meerdere velden. Bijvoorbeeld het ophalen van een straatnaam op basis van een postcode met huisnummer. Er is reeds een concept gestart waarin de data opgehaald wordt van een andere website, echter heb ik dit niet ingebouwd in een van mijn concepten, aangezien ik niet afhankelijk wil zijn van een derde partij.

    Heeft een van jullie eerder een dergelijke toepassing gevonden?

    Beantwoord

  13. Leuk artikel. En leuke discussie.

    Roger zei: “liever meer requests dan geen klant.” En daar bedoel je denk ik mee dat als je al die extra requests vastlegt, je kan meten waar in het formulier de bezoeker afhaakt. En dat vindt de marketingafdeling weer leuk.

    Verder denk ik ook dat veiligheid altijd op nummer 1 moet staan. Ajax kan iets doen voor de beleving van de bezoeker en de gebruiksvriendelijkheid..

    Beantwoord

Geef een reactie

Verplichte velden zijn gemarkeerd met een *.