Je kunt formulieren beschouwen als het belangrijkste dat op internet bestaat. Je hebt ze immers bijna altijd nodig om contact te leggen met gebruikers, of ze je producten te verkopen. Gebruikers die problemen hebben met het invullen van een formulier zijn erg kostbaar voor een organisatie. Iemand die midden in een bestelproces afhaakt betekent direct verloren omzet, terwijl er wel geld is uitgegeven om die persoon zo ver te krijgen aan het formulier te beginnen. Mocht je meer motivatie nodig hebben om je formulieren te verbeteren, lees dan De conversie ratio formule…
Daarom nu maar eens een uitgebreid overzicht van tips en checks voor de gebruiksvriendelijkheid van formulieren. Vooraf kan ik vast zeggen: de lijst is vast incompleet en soms overdreven, dus aanvullingen en reality checks zijn zeer welkom!
Laten we bij wijze van aftrap wat stellingen over formulieren in de groep gooien. Vanuit het oogpunt van de gebruiker natuurlijk…
- Formulieren zijn lang en ingewikkeld
- Formulieren zijn onduidelijk, soms is niet eens duidelijk waar ze voor dienen
- Formulieren dwingen gebruikers vragen te beantwoorden, zelfs als de gebruiker de vragen irrelevant vindt
- Formulieren verkleinen de controle die gebruikers hebben door dingen verplicht te stellen
- Formulieren worden door marketeers misbruikt om informatie te achterhalen voor direct marketing
- Websites geven gebruikers de schuld van het verkeerd invullen van formulieren
Wat kunnen we doen om het die arme gebruiker zo makkelijk mogelijk te maken? En wat kunnen we doen om het die arme website eigenaar zo makkelijk mogelijk te maken geld te verdienen met zijn formulieren?
De checks en tips zijn onderverdeeld in de volgende onderdelen:
Fundamentele kwesties
Eerst de fundamentele varkentjes wassen. Waarom moeten we formulieren gebruiken, en wat moeten we ons in ieder geval afvragen voor en bij het ontwerpen van formulieren?
- Als een marketeer een boekingsformulier wil misbruiken … stop hem dan terug in zijn kooi.
- Hou formulieren zo kort mogelijk
Over het algemeen kun je van formulieren zeggen dat ze intimiderend werken. Elk invoerveld is weer een nieuwe eis die aan de gebruiker wordt gesteld. Een gulden regel geldt altijd: hoe korter hoe beter. Als een marketeer een boekingsformulier wil misbruiken om marktinformatie te achterhalen (zie bijvoorbeeld de discussie bij Wehkamp), stop hem dan terug in zijn kooi. Hou het formulier zo kort als mogelijk is zonder de conversie onmogelijk te maken. - Verdeel lange formulieren over meerdere pagina’s
Deze tip volgt onder andere uit de vorige, met betrekking tot intimidatie. Je ziet in bestel applicaties bijna altijd dat het formulier over verschillende pagina’s wordt verdeeld. Op de eerste pagina wordt het product gekozen (dit is meestal het winkelwagentje), daarna worden persoonlijke gegevens gevraagd en als laatste worden de betaling en verzending geregeld.
Dit zorgt ervoor dat de gebruiker niet afhaakt vanwege de enorme hoeveelheid velden. Ook is het op deze manier makkelijker te maken het formulier te valideren, doordat de fout ingevulde velden altijd snel te vinden zijn.
Een extra uitdaging is om de back en forward buttons bij formulieren nog steeds te laten werken. Als een gebruiker iets invult, op “volgend” ramt en dan bedenkt dat zij een foutje eeft gemaakt, is de back button vaak een eerste reactie. Als het formulier dan een foutmelding geeft, of de data is verdwenen, kan dat een conversie kosten. 
Stel niet teveel velden verplicht
Dit sluit aan bij het zo kort mogelijk houden van je formulier. Stel alleen verplicht wat echt nodig is om de transactie te voltooien. Voor het afronden van de verkooop is het niet absoluut nodig dat iemand invult “Hoe bent u op onze site terecht gekomen?”. En vraag voor een gewoon contact formulier ook niet naar allerlei NAW gegevens, maar alleen naar het broodnodige om aan een vraag te voldoen.
Vraag in een webwinkel dus ook niet naar een geboortedatum. Wehkamp doet dat wel, wellicht met goede reden?- Gebruik formulieren waar ze voor bedoeld zijn
Soms worden formulieren misbruikt om bijvoorbeeld navigatie functies te vervullen. Dit kan verwarrend zijn, maar het grootste probleem is dat formulieren gewoon onhandig zijn om snel keuzes te maken. Probeer dit misbruik dus te beperken: als een keuze gemaakt moet worden uit een lijst, geef dan gewoon een lijst met links weer en geen dropdown menu. Dat scheelt een klik, en een kans dat de gebruiker afhaakt. - Geef aan welk invoerveld actief is
Laat de gebruiker zien welk veld hij op dit moment aan’t invullen is. Dit is handig als hij even afgeleid is, of bijvoorbeeld de tab-toets gebruikt om van veld naar veld te springen. Ook is het goed om te weten dat je raak hebt geklikt in een veld. De cursor is hiervoor niet genoeg want die is erg klein en slechts de helft van de tijd zichtbaar (want hij knippert). Dit zichtbaar maken welk veld actief is kun je doen door in CSS gebruik te maken van focus:input:focus,textarea:focus {background-color:yellow;}
Gebruik de asterisk* voor verplichte velden
De oudste regel en bekendste formulier conventie is die van de asterisk (*) om te laten zien welke velden verplicht zijn. Origineel is die natuurlijk bedoeld om naar een voetnoot (” * Deze velden zijn verplicht in te vullen”) te verwijzen. Inmiddels is het eigenlijk al genoeg om alleen een asterisk neer te zetten.
Vreemd genoeg doet Becam dit juist niet goed, terwijl de website verder een oase van usability en accessibility is.Gebruik voor verplichte velden dus geen eigen bedachte trucs zoals rood omrande velden of dikgedrukte labels. De ouderwetse asterisk voldoet prima.- Hou lettergrootte leesbaar in invoervelden
De lettergrootte is op veel websites al erg klein, maar in invulvelden wordt het vaak nog erger. Zorg dat de ingevulde formulier velden zelf ook nog leesbaar zijn door de letters een fatsoenlijke grootte mee te geven. Liefst gewoon 100% van de standaard lettergrootte van de webbrowser. 
Windows, Linux of Apple: Gebruik de standaard vormgeving
Vaak wordt door vormgevers creatief omgesprongen met de vormgeving van formulieren. Je kunt voor elke knop, elk invulveld en elk drop down menu precies bepalen hoe ze eruit zien. Door dit te doen, wordt het voor gebruikers moeilijker de functies van een formulier te herkennen. Vanuit hun operating system zijn ze een gewend hoe een button of een dropdown eruit ziet, dus waarom zou je daarvan afwijken?
Soms wordt niet eens een “echt” formulier gebruikt, maar wordt de interactie van een formulier gewoon nagebootst met andere technieken (Javascript of nog erger: Flash). Dit verlaagt de toegankelijkheid van het formulier, doordat browsers het niet kunnen herkennen. Ook ben je er niet zeker van dat het formulier op alle platforms werkt.- Zet labels boven de invoervelden i.p.v. ernaast
Uit onderzoek blijkt dat gebruikers het minst moeite hebben met labels die boven invoervelden staan, in plaats van ernaast. Dit stoort de “flow” het minst en het invullen van de velden gaat het snelst. In mijn ervaring is dit niet iets dat je conversieratio direct omhoog stuwt, maar als je echt alles perfect wilt doen is dit in veel gevallen toch het beste. - Gebruik de goede soort velden voor de invoer
Als iemand maar 1 keuze hoort te maken, geef hem dan radiobuttons (
) om te kiezen. Als er meerdere keuzes mogelijk zijn, gebruik dan checkboxes (
).Als er meerdere keuzes zijn en de lijst is erg lang, gebruik dan een option select met als extra attribuut “multiple”. Voordeel van een option lijst is dat mensen daar hun toetsenbord kunnen gebruiken om direct naar de N van Netherlands te gaan. Meer informatie over de verschillende vormen van select/ option.
Een andere veelgebruikte methode is de dubbele selectie lijst. Google gebruikt dit bijvoorbeeld in het formulier waar landen geselecteerd kunnen worden in AdWords campagnes. Dit zou in een gewone option select lijst te onoverzichtelijk worden, omdat je niet meer kunt zien welke opties al geselecteerd zijn. - Zorg voor een logische volgorde
Het gebeurt mij erg vaak dat ik in het postcode veld een plaatsnaam invoer, of mijn voornaam in een achternaam veld. Zorg dat de volgorde van je velden logisch is, zodat gebruikers niet per ongeluk verkeerde dingen invoeren. Kijk bij andere websites welke volgorde zij aanhouden, probeer zoveel mogelijk hetzelfde te doen. Consistentie is erg belangrijk in usability, zeker ook bij formulieren. - Ken je bezoeker: Vul reeds bekende velden in
Als een gebruiker al bekend is, zorg dan dat de velden in het formulier die je al weet, al ingevuld zijn. Zeker als iemand ingelogd is, is het erg irritant als je toch nog je gegevens moet invullen (zoals bijvoorbeeld bij Agis). Het weergeven van ingevulde velden heeft als voordeel dat de gebruiker als zij dat wil toch nog iets anders kan invullen. Dit geld bijvoorbeeld ook voor het ingeven van een alternatief bezorg adres bij een bestellingsformulier. - Voorkomen is beter dan genezen: Geef uitleg en voorbeelden
Als het goed is, is er bij een formulier geen uitleg nodig. Als dat wel zo is, is er waarschijnlijk iets mis met het formulier. En: hoe langer de uitleg, hoe kleiner de kans dat hij gelezen wordt.
Maar als een specifieke manier van invoeren voor een veld nodig is, geef dan een korte aanwijzing. Dit kan bijvoorbeeld onder of naast het betreffende veld weergegeven worden. Probeer hierbij voorbeelden te geven, die zijn vaak het makkelijkst te omschrijven en snel herkenbaar.
Zorg dat aanwijzingen niet pas beschikbaar worden door ergens op te klikken, dat maakt het alleen maar vermoeiender voor de gebruiker. - Geef gebruikers de ruimte voor hun invoer
Zorg dat degene die je formulier invult de ruimte heeft om dingen in te vullen. Als ze toevallig Ina Bos heet is dat prima, maar langere namen moeten ook ingevuld kunnen worden. Zorg dat voor- en achternaam allebei minstens 20 letters lang kunen zijn. Dat geldt natuurlijk ook voor textarea’s, waar gebruikers opmerkingen kunnen invullen. Zorg dat ze daar de ruimte hebben om iets te schrijven, en dat het nog leesbaar is tijdens het invullen. - Gebruik dubbele invoer wel bij wachtwoorden, niet bij e-mail
Mensen twee keer hun e-mail adres laten invoeren: is dat nou echt nodig? Het gebeurt erg veel, en ervaren computer gebruikers raken erdoor geirriteerd. Zij kopiëren en plakken het eerste veld gewoon in het tweede, zonder aandacht te besteden aan de inhoud. In mijn ogen is het twee keer vragen van het e-mail adres overbodig, maar ik beken dat ik geen gebruikersdata heb van de problemen die dit voorkomt.
Wel weet ik dat ervaren gebruikers altijd hun e-mail adres blind en snel kopiëren en plakken, in plaats van het netjes twee keer te typen. Dan heeft het eisen van dubbele invoer dus geen enkel nut.
Als het e-mail adres daadwerkelijk van levens (of conversioneel) belang is, zorg dan dat er bij de controle van het formulier nadruk op wordt gelegd. Dan kan de gebruiker zelf checken of het inderdaad goed is ingevoerd. - Zorg voor eerste hulp bij invullen (EHBI)
Een gebruiker moet altijd het gevoel hebben hulp te kunnen vragen bij het invullen van een ingewikkeld formulier. Idealiter is een formulier zo simpel dat hulp niet nodig is, maar er zullen altijd gebruikers zijn die twijfelen of ergens niet uitkomen. Zet in ieder geval een e-mail adres bij het formulier, en als dat mogelijk is, een telefoonnummer met daarbij de openingstijden. Zelfs als de gebruiker niet belt, geeft het een goed gevoel dat ze altijd op de organisatie kan rekenen.Steeds vaker worden hiervoor chat applicaties ingezet. De mogelijkheid om direct met een medewerker te Skype’en of te chatten (met live webcam in de browser!), kan ook vertrouwen wekken. Er zijn zelfs services die automatisch hulp bieden wanneer een gebruiker moeite heeft met het invullen van een formulier. Bijvoorbeeld door de tijd te meten die het kost om een veld in te vullen, of het aantal keer dat een veld opnieuw wordt ingevuld. - Verander reeds ingevulde velden niet
Als een gebruiker in een invulproces de back button gebruikt of weer terug komt bij een formulier na een validatie fout, zorg dan dat alle velden zijn ingevuld zoals de gebruiker dat heeft gedaan. Er is niks vervelender dan een “Stuur mij de 8x dagelijkse nieuwsbrief” vinkje dat opeens weer aan staat. Of een formulier dat na gebruik van de back button weer helemaal leeg is. - Wees lief en concreet bij foutmeldingen
Als iemand een fout maakt in een formulier en de fout blijkt pas na de validatie, zorg dan dat je uitlegt wat er verkeerd was. Leg de schuld niet bij de gebruiker door iets te zeggen alsJe hebt een fout in het formulier gemaakt, probeer het opnieuw
Leg gewoon uit wat er aan de hand is en vertel hoe het probleem opgelost kan worden:
De ingevulde wachtwoorden komen niet overeen. Vul nogmaals beide wachtwoorden in om verder te gaan
Laat altijd zien bij welk veld de fout is opgetreden door er bijvoorbeeld een rood vierkant omheen te zetten, natuurlijk met de foutmelding in de buurt.
Minder frictie
- Zet focus op het eerste veld om snel in te vullen
Voor webpagina’s waar het formulier het belangrijkste of enige is dat de gebruiker hoeft de gebruiken, is de focus een handig hulpmiddel. Als je naar Google gaat, kun je meteen beginnen met typen zonder eerst in het zoekveld te hoeven klikken. Hiervoor gebruik je de javascript focus functie. - Ken je gebruikers, zet veel gekozen opties bovenaan
Als 9 van de 10 gebruikers “Nederland” kiest in het veld waar zijn land hoort, zorg dan dat deze optie bovenaan staat. Eventueel kun je de optie alvast geselecteerd maken om deze 9 gebruikers nog sneller door het formulier te laten gaan.
Google heeft in zijn AdWords Client Centre een handigheid ontwikkeld voor het gebruik van de dropdown om snel naar een klant te navigeren. Je laatst gekozen 5 klanten staan altijd bovenaan in het dropdown menu. Zo hoef je nooit de hele lijst langs voor de meest gebruikte opties. - Zorg dat de “tab” toets goed werkt
Voor gebruik van de tab toets om naar het volgende formulier veld te gaan, is het belangrijk dat de velden onder elkaar staan. Als je bijvoorbeeld een tabel gebruikt om de formulier velden en labels uit te lijnen, zog dan dat de invoervelden in de HTML code nog steeds onder elkaar staan. - Voorzie je formulier van labels voor toegankelijkheid en snelheid
Wanneer een invoerveld een label heeft, is het voor de browser duidelijk welk label bij wel invoerveld hoort. Die labels kunnen bijvoorbeeld ook door screenreaders gebruikt worden om op te lezen welke invoer bij welk formulier veld nodig is.
Ook maken veel browsers (maar Apple’s Safari niet) het aanklikken van bijvoorbeeld een radio button of een vinkje makkelijker door het hele label ook klikbaar te maken. Een formulier label ziet er zo uit:<input type=”radio” id=”keuze1″ value=”selected” name=”keuzeradio”>
<label for=”keuze1″>Uw keuze:</label> - Wis de wis knop
In HTML is er een mogelijkheid ingebakken voor een knop om een formulier in een keer leeg te maken. Met als gevolg dat iedereen dat is gaan gebruiken. Maar waarom eigenlijk? Het probleem met het wissen van een formulier is dat het meestal per ongeluk gaat. Dan kun je weer van voren af aan beginnen , en die stap zal de gebruiker meestal liever overslaan…De grootste fout die je kunt maken, is de wis knop in de HTML code direct na het laatste veld te plaatsen. Een snelle gebruiker gebruikt zijn tab toets en komt in plaats van de verzend knop, bij de wis knop uit. Gebruik de wis knop alleen als het logisch is het formulier te wissen, bijvoorbeeld bij een test die vakere gedaan kan worden. - Laat gebruikers velden invoeren zoals zij willen
Het is al twee keer voorgekomen in de usability fouten en foutjes, bij Amazon en Dell nota bene. Als een gebruiker zijn telefoonnummer als 020-123 4567 invult, zorg dan dat het formulier dat accepteert en gewoon 0201234567 opslaat in de database. Datzelfde geldt natuurlijk ook voor internationaal georiënteerde sites waar een landcode als +31 of 0031 ingevuld kan worden. Dwing de gebruiker zich niet aan te passen aan je website, maar pas de website aan aan de gebruiker.
Zorg bijvoorbeeld ook dat het veld voor invullen van een postcode minstens 5 tekens lang is, zodat mensen zowel 1234 ab als 1234ab als 1234AB als 1234 AB kunnen invullen. - Scheid adressen en huisnummers niet
Een ander voorbeeld van invoer op een menselijke of gecomputeriseerde manier, zijn huisnummers en adressen. Het makkelijkst is om gebruikers gewoon te vragen naar hun adres. Het kan erg irritant zijn om eerst de straat, dan het huisnummer en dan nog eens een toevoeging bij het huisnummer toe te voegen. Laat die invuloefnening aan software over, niet aan een gebruiker.
Datzelfde geldt natuurlijk ook voor bijvoorbeeld de postcode, waar het scheiden van cijfers en letters het voor de gebruiker alleen maar vermoeiender maakt. - Voorkomen is beter dan genezen: gebruik Javascript validatie
Als iemand een e-mail adres moet invoeren en hij vult geen @ in, weet je zeker dat er iets mis is gegaan. Dit soort simpele fouten kun je direct tijdens het invullen al duidelijk maken met Javascript.
Op het moment dat iemand naar het volgende veld gaat (het ingevulde veld verliest dan focus), kan er bijvoorbeeld een foutmelding verschijnen bij het fout ingevulde veld. Doe dit liever niet met een popup of iets anders dat de “flow” van de gebruiker verstoort! - Laat het formulier door de gebruiker controleren voor verzending
Als een formulier lang en ingewikkeld is, vraag dan bevestiging voordat het formulier verzonden wordt. Dit is nog belangrijker als de informatie nodig is voor correcte afhandeling, bijvoorbeeld bij het invullen van een bankrekening. De transactie zal immers verkeerd gaan als dat verkeerd is ingevuld. Het is dan ook verstandig de velden die van levensbelang zijn extra te benadrukken en eventueel de gebruiker expliciet vragen die velden te controleren. - Geef de gebruiker continue feedback
Vooral bij formulieren voor bestellingen is het belangrijk dat de gebruiker continue de zekerheid heeft dat haar bestelling geen fouten bevat. Als een formulier uit meerdere pagina’s bestaat, geef dan de informatie die reeds is ingevoerd bijvoorbeeld aan de rechterkant weer. Als het een bestelling betreft, toon dan altijd een foto en korte beschrijving weer van het te bestellen product. En zet daar als het even kan zo snel mogelijk de complete prijs neer, inclusief verzendkosten en andere kosten. Dan komt de gebruiker niet voor verrassingen te staan, die de conversie in gevaar brengen. - Validatie: Denk mee met de gebruiker
Denk bij de validatie van een formulier in de eerste plaats aan de gebruiker, niet aan de organisatie. Als bijvoorbeeld informatie nodig is die niet iedereen paraat heeft, overweeg dan incorrecte invoer te accepteren. Probeer in zo’n geval de informatie via een andere weg te verkrijgen.
Als een gebruiker voor het aanvragen van een verzekering allerlei gegevens moet opzoeken, doe daar dan niet te moeilijk over bij het valideren. Probeer op basis van de rest van de informatie (telefoon, e-mail, naam) te achterhalen wat de correcte invoer had moeten zijn. Dat betekent een extra last voor de organisatie, maar het alternatief is misschien een verloren klant. - Keuzevrijheid: Geef de gebruiker de keuze voor verwerking
Je kunt bij een contact formulier een optioneel vinkje tonen met “Stuur mij een bevestiging van mijn aanvraag”. En als een gebruiker informatie aanvraagt is het netjes om een veld op te nemen als “Neem contact met mij op via: E-mail / Telefoon / Post”. Sommige mensen worden nu eenmaal niet graag gebeld, en anderen juist wel.
Natuurlijk moet je de validatie van een formulier hier ook op aanpassen. Als een gebruiker een bevestiging via e-mail wil, moet er wel een correct e-mail adres worden ingevuld. - Gebruik altijd een bedankt pagina ter bevestiging
Voor elk formulier dat verzonden is, moet een goede bedankt pagina beschikbaar zijn.Geef daarin niet alleen aan dat de informatie is aangekomen of de aankoop afgerond, maar leg ook uit hoe het proces verder zal gaan. “We nemen binnen 3 werkdagen contact met u op” of “U krijgt binnen een uur een e-mail met de bevestiging van uw aankoop”. - Stuur altijd een e-mail achteraf
Voor een online aankoop is dit natuurlijk van levensbelang. Zorg dat de gebruiker een e-mail krijgt met bevestiging van de aankoop en eventuele verdere instructies. Maar ook bij een simpel contact formulier is het netjes als de gebruiker een mailtje krijgt waarin wordt bevestigd welke informatie bij de organisatie is binnen gekomen. Leg dan ook meteen uit wanneer je verwacht te reageren op de aanvraag.Zorg in de e-mail bevestiging dat de gebruiker kan antwoorden op de e-mail, en dat die mail door dezelfde persoon gelezen wordt als waar het formulier in eerste instantie heen gestuurd werd. Maak het ook mogelijk op een andere manier contact op te nemen. Zet telefoon en andere contact info dus ook in de bevestigingsmail.
Vertrouwen
- Leg uit waarom velden nodig zijn
Zeker wanneer privacy gevoelige informatie wordt gevraagd is het belangrijk uitleg te geven. Als je een e-mail adres nodig hebt, zet er dan een link bij naar een kort privacy statement. Of gewoon een tekst als “We gebruiken je e-mailadres alleen voor het beantwoorden van je vraag”. Meer over dit onderwerp trouwens in De conversie ratio formule: Conversie = Energie – Frictie. - Gebruik een beveiligde verbinding (SSL)
Bij alle formulieren waar persoonlijke informatie wordt verstuurd, is een SSL verbinding nodig. Browsers benadrukken dit steeds sterker (door de adresregel anders te kleuren, zoals bij Firefox en Internet Explorer 7), en gebruikers zullen dit dus ook vaker checken. Gebruik SSL echter ook niet te vaak, voor een simpel contact formulier is het overdreven. - Benadruk de veilige verbinding (SSL)
Als het formulier over een beveiligde verbinding verstuurd wordt, geef dat dan aan. Zorg voor een Verisign logo of iets anders dat er officieel uit ziet. Dat geeft een veilig gevoel, zeker bij het invullen van persoonlijke informatie. Het is aan te raden de gebruiker al vanaf de eerste formulier pagina naar een https omgeving te sturen, zodat ze ook in haar browser ziet dat alles veilig is. - Opt-in en opt-out: wees bescheiden
In de meeste gevallen is het netter om van een gebruiker een opt-in te vragen, dan een opt-out te eisen. Een opt-in is wanneer je de gebruiker een leeg vinkje toont bij bijvoorbeeld “Schrijf mij in voor de nieuwsbrief”. Als de gebruiker het vinkje zelf uit moet zetten, kun je spreken van opt-out. Al is volgens mij de originele definitie van opt-out dat iemand automatisch wordt ingeschreven, waarna hij een aparte actie moet ondernemen om afgemeld te worden. Dit laatste is verboden in Nederland.
Apple geeft een aardig voorbeeld van hoe je het niet zou moeten doen: Grote jongens hoeven niet bescheiden te zijn
Vormgeving
Hoe kan de vormgever zijn steentje bijdragen aan de gebruiksvriendelijke formulieren? Welke visuele trucs helpen de gebruiker sneller te converteren?
Invoer
Begeleiding
Validatie
Nazorg
Bronnen & ander leesvoer
Usarchy test: ipod aanbieding
- Forms – Usability Features – The Label Element – seoconsultants.com
- Combo Box / Dropdown – hscripts.com
- Usability and HTML Forms – wdvl.internet.com
- Sensible Forms: A Form Usability Checklist – alistapart.com
- Simple Tricks for More Usable Forms – sitepoint.com
- Reset and Cancel Buttons – Jakob Nielsen
- Effective use of forms on websites – Adam Baker
- 5 Ways To Make Sure That Users Abandon Your Forms – Improving Customer Experience
- Label Placement in Forms – UXMatters.com
Wat heb ik gemist?
Hopelijk heb je hiermee een aardige lijst van dingen die je kunt checken in je formulieren. Er zijn ongetwijfeld nog talloze andere checks en tips die ik niet heb beschreven. Welke?. En welke formulieren zijn het slechtst? Voorbeelden zijn altijd meer dan welkom, wellicht zitten er nog juweeltjes bij die een eigen case verdienen? 🙂
usarchy.com 
Tsjonge… Niets te doen gehad van het weekend?
Maar zonder gekkigheid, lekker artikel en een mooie checklist aangezien ik net met een surveytool bezig ben. Het enige nadeel is dat ik er nu natuurlijk 2x zo lang over doe.
Ik mis misschien nog 2 dingen:
1. De combinatie Ajax & Forms en of daar specifieke aandachtspunten zijn behalve de bovenstaande.
2. Het overslaan van velden die naar aanleiding van een vorige vraag niet meer nodig zijn. Dat is iets wat bij mijn surveytool nu heel erg naar voren komt. Het kan wel eens voorkomen dat een veld niet meer nodig is als een vraag positief/negatief beantwoord is, dan kun je dat veld net zo goed verbergen om verwarring te voorkomen. Vind ik persoonlijk erg makkelijk.
LikeLike
Ulco, thanks 🙂 Ik ben bezig aan het volgende artikel: 962 tips en checks voor formulieren met AJAX. Wordt waarschijnlijk in boekvorm uitgegeven en op DVD.
Seriously: denk dat je daar wel veel extra over kunt schrijven, zal er zeker nog aandacht aan besteden. Iig denk ik dat ze bij Yahoo wel veel info over dat soort grappen hebben. Kijk maar eens in hun design patterns:
http://developer.yahoo.com/yui/
LikeLike
Wow, erg goed artikel Ruben!
Ik mis bij punt 2 de vermelding dat je wel goed moet aangeven hoeveel pagina’s er in totaal zijn. Iets waar ik echt een hekel aan heb zijn van die formulieren die maar door en door gaan, zonder dat ik kan inschatten wanneer ik ongeveer klaar ben. Meestal haak ik bij zulke formulieren af na 2 pagina’s.
Ook is het misschien wel goed om te vermelden dat sommige invoervelden niet nodig hoeven te zijn. Dit sluit deels aan op punt 24. Een goed voorbeeld is het vragen om alleen een postcode en huisnummer (waarmee je alle benodigde adresgegevens kan afleiden) in plaats van straatnaam, woonplaats, postcode en huisnummer.
Wat ik over het algemeen erg prettig vind bij formulieren is het gebruik van labels bij checkboxen en radio buttons (punt 22), het zo intelligent mogelijk verwerken van gegevens (punt 24) en een goede hulp functie bij eventueel verwarrende velden (punt 16).
LikeLike
Flinke lap zo…
Paar dingetjes (nummertjes corresponderen met de punten in de tekst):
4. Hoewel het niet de fraaiste manier is en zeker ongeschikt als primaire navigatie vind ik het gebruik van een select-box voor een ‘direct naar’-menuutje soms wel kunnen. Het is een extraatje en een lange lijst met links kan soms gewoon teveel ruimte en aandacht opeisen. Een select-box is immers feitelijk ook gewoon een lijst met opties net als een menu. Wel zorgen dat arme sloebers zonder JavaScript dit mini-formuliertje kunnen submitten natuurlijk.
5. Het nadeel bij checkboxen en radio buttons is dat (in IE althans) enkel van de restvorm de achtergrondkleur of border ingesteld kan worden. Bij Opera is het wel zoals je zou verwachten.
Overigens ondersteund IE6 de pseudo-class selector :focus niet.
6. Hoewel het voor de meeste mensen volkomen duidelijk zal zijn waar de asterisk (*) voor staat vind ik dat je de betekenis toch altijd moet vermelden. Niet iedereen vult regelmatig formulieren in.
7. Ik heb het je al vaker zien schrijven: “font-size bij voorkeur op 100%”, maar mijn ervaring is dat 100% (of 1.0em) groter is dan de font-size van het OS. Meestal komt 0.8em of 0.9em meer in de buurt.
8. In IE6 wordt voor de select-box nog gebruik gemaakt van Windows-element, maar voor de overige formulier-elementen geldt dat deze browser-eigen zijn (in Firefox, Opera en IE7 geldt dat ook voor de select-box). Dit heeft dus ook gevolgen voor de vormgeving van deze elementen. Op PC kun je dit vooral bij Opera goed zien.
Verder is het natuurlijk wel zo fraai als de opmaak van je formulier overeenkomt met de rest van de site. Zolang het duidelijk is om wat voor element het gaat lijkt het me geen probleem.
Zie in Firefox overigens ook nogal wat ronde hoeken bij formulier-elementen op deze pagina 😉.
10. Een multiple select-box is naar mijn mening werkelijk het meest gebruiksonvrindelijke formulier-element dat er is. Dan kun je volgens mij beter gebruik maken van een lijst met checkboxen en deze lijst in scrollbaar div’je plaatsen. Ten eerste is niet voor iedereen duidelijk hoe de mutliple select werkt, zodat je er tekst en uitleg bij moet gaan geven en ten tweede zorgt een ‘foute’ klik ervoor dat je je hele selectie kwijt bent. NIET GEBRUIKEN!!!
19. Focus op het eerste veld is soms erg fijn en soms ook erg vervelend. Heb je bijvoorbeeld Google als startpagina ingesteld, dan wil het nogal eens gebeuren dat de (halve) URL in het zoekvenster belandt in plaats van in de adresbalk. Nu zullen mensen waarschijnlijk niet zo gauw een contact- of bestelformulier als startpagina instellen, maar juist bij Google, wat je als voorbeeld geeft, levert het regelmatig irritatie op bij mij.
22. Weet niet wat voor geslacht dat is Ruben. Ik ken eigenlijk alleen man en vrouw en verder lijkt het internet op sommige plaatsen ook nog redelijk druk bevolkt met shemales, maar uw achternaam…? 😉
En bij een radio button moet je natuurlijk wel even een value opgeven, anders weet je nog niet waar de keuze op is gevallen.
26. Niks mis met JavaScript-validatie, maar server-side validatie is belangrijker. Die kun je als bezoeker namlijk niet uitzetten! Een combinatie is natuurlijk het mooist.
Hmmm… is zoch een langer lijst geworden dan in eerste instantie de bedoeling was. Maar goed, je vroeg om op en aanmerkingen. Bij deze dus…
LikeLike
Sander, thanks voor de nuttige feedback.
5. Dat focus niet werkte in IE wist ik niet. Is er geen andere methode om het actieve veld aan te geven? Bij checkbox of radiobutton is het probleem ook iets anders, misschien kun je daar de hele layer “actief” weergeven? Het gaat er immers niet om aan te geven dat die ene radiobutton actief is, maar om te signaleren in welk deel van het formulier je bezig bent.
6. Vind ik ook wel zo netjes inderdaad.
7. Oh ja, ik herinner me het ook, maar ik snap de logica van de OS
‘en of browsers dan niet. Waar is 100% of 1em dan op geijkt?!
8. Ik zeg nooit dat ik zelf doe wat ik zeg. Do as I say, not as i do! 😉
10. Mee eens, daarom het voorbeeld van Google (hoe noemen we zo’n ding?), dat volgens mij redelijk bruikbaar is voor veel selecties.
19. Klopt, tricky, ik vind het juist wel lekker maar het kan inderdaad problemen opleveren, net als windows in Windows die focus stelen.
22. Heh, fixed nu, snelle copy paste 😉
LikeLike
5. je zou iets met een JavaScript onfocus() kunnen doen, waarbij je een andere className en daarmee andere opmaak toekent aan het element. Met een onblur() maak je dat dan weer ongedaan.
Niet de fraaiste oplossing, maar dat is IE sowieso niet.
7. 100% van de standaard lettergrootte van browser lijkt me. Maar waarom deze standaard zo’n 20% groter is als die van het OS waarop deze draait is me ook niet helemaal duidelijk.
LikeLike
Meer een vraag, dan reactie.
Moet een “usibility proof” formulier zonder gebruik te maken van de muis in te vullen zijn?
LikeLike
Herman: wat mij betreft zeker! Met gebruik van tab, pijltjes en enter toetsen moet het hele formulier inn te vullen en op te sturen zijn.
Maar misschien zijn anderen het daar niet mee eens?
LikeLike
Even een opmerking over puntje 23. Wis de Wis knop.
Zoals het plaatje met het kruis al aangeeft, is de Wis knop geen Wis knop maar een Reset knop.
Reset betekent: terug naar de waarden zoals ze voor-ingevuld waren. Als je bijvoorbeeld een compleet ingevuld profiel van jezelf aan het bewerken bent, maar je halverwege bedenkt over een groot aantal wijzigingen, kun je het (voor-ingevulde) formulier met een Reset knop weer in de oorspronkelijke toestand krijgen.
Uiteraard wordt een initieel blanco formulier weer geheel blanco, maar dat is als het goed is een edge-case (zie punt 12).
LikeLike
tis leuk al die tips, maar practice what you preach en zorg dat je eigen site iig door html en css validatie heenkomt voordat je over een winkelketen als de wehkamp gaat klagen die geen verstand heeft van internet en dat uitbesteedt (open deuren intrappen)
LikeLike
Pingback: Vierde Nederlandse Blogkermis
Pingback: Enthousiasmeren
Peter: je hebt gelijk natuurlijk, al komt de lelijke maar veelgebruikte vertaling “wissen” wat mij betreft van “wis mijn invoer”. Een belangrijke tip die ik nu merk gemist te hebben, is de naamgeving van buttons, maar daar kun je sowieso boeken over volschrijven 🙂 Je voorbeeld van het bijwerken van een profiel is inderdaad een goede waar een reset knop wel hout snijdt, thanks 🙂
Idioot: Suggesties voor verbetering van de site zijn altijd welkom, maar validatie (of zelfs maar crossbrowser compatibiliteit ) hebben niet mijn prioriteit. Simpelweg doordat ik er niet goed in ben, eigenlijk…
Wat betreft practicing what you preach; op je website is te lezen:
Heel helder en betrokken vind ik je ingevulde naam en weggelaten e-mail adres niet.
LikeLike
Maar eh Ruben… idioot is hier de bezoeker en over diens betrokkenheid staat er niks in dat zinnetje. Op zijn/haar eigen site (uitgaande van de genoemde quote i.c.m. Google) staat wel degelijk een e-mailadres. Maar inderdaad geen persoonlijke naam.
LikeLike
Ik heb mezelf pas geregistreerd bij JPG Magazine en dat was een van de prettigere ervaringen daarin die ik tot nu toe heb gehad. Buitengewoon kort, gestroomlijnd en met goede feedback.
LikeLike
Mooi overzicht! Ik ga hem spiegelen aan mijn huidige en toekomstige webformulieren.
LikeLike
De :focus selector werkt niet bij IE (ook niet in IE7…) zoals al eerder gemeld.
Een oplossing is een stukje javascript (plus CSS) genaamd Suckerfish (http://www.htmldog.com/articles/suckerfish/focus/)
Zie voorbeeld van gebruik op de volgende contact pagina.
LikeLike
ctr-p in de mappen! zeker handig dit artikel. Veel dingen pas je toch wel automatisch toe, maar stonden toch nog wel een paar bij die interessant waren.
Zoals ( labels boven velden ipv naast de velden )
LikeLike
Het nadeel van de labels boven de velden plaatsen is dat je formulier als geheel veel minder overzichtelijk wordt. Staan de labels ervoor dan heb je een duidelijker beeld wat je allemaal reeds hebt ingevuld en ??f je alles al wel hebt ingevuld. Dat geldt dus wellicht niet als je nog aan het formulier moet beginnen, maar mijns inziens wel als je al bezig/klaar bent.
Ook neemt een formulier in vertikale richting minder ruimte in wanneer de labels voor de velden staan i.p.v. erboven. Dit bevordert dus ook de overzichtelijkheid, zeker wanneer het een formulier betreft met veel velden. Ook levert het vaak een rustiger beeld op, al is dat natuurlijk ook afhankelijk van de vormgeving.
Ik kan me inderdaad voorstellen dat labels duidelijker bij een bepaald veld horen wanneer ze er boven staan i.p.v. ervoor. Zeker wanneer de ruimte tussen de twee op sommige plaatsen groot is, doordat het ene label aanzienlijk korter is dan het andere, kan dit verwarring opleveren. Dit kan eventueel opgelost worden door de labels wel links van de velden te plaatsen, maar deze vervolgens rechts uit te lijnen. Op die manier is de afstand tussen het label en het bijbehorende veld altijd even groot (lees: klein).
LikeLike
Ik gebruik meestal een tabel voor een formulier waarin ik de functie van het veld in de linker kolom plaats en de invoervelden zelf rechts daarvan.
Vervolgens zorg ik vaak dat de rijen van de tabel om en om gekleurd zijn
waardoor het zeer duidelijk is velk veld bij welke toewijzing past.
Die kleuren hou ik het liefst erg licht en de lettertypes donker.
Die javascript validatie vind ik wel een erg handige tip, ik gebruikt meestal
een PHP code om de velden te controleren op hun waardes (zo ver dat kan).
Maar ik denk dat ik hier wel wat aan heb.. bedankt
LikeLike
Sander (de eerste): goede aanvulling. Als je labels boven velden plaatst heb je toch vaak het gevoel dat het er niet lekker uit ziet. Ik heb er met een klant die erg veel gebruikers op het boekingsformulier krijgt wel eens mee geexperimenteerd, maar het maakte daar voor de conversie niks uit.
Sander (de tweede): thanks 🙂
LikeLike
Ha Ruben, bedankt voor deze mooie lijst. Ik lees hem nu pas, door de link op Marketingfacts. Oftewel, ik ben ook nog nieuw op Usarchy.
Maar beter een late reactie dan nooit h?© 😉
Mijn punt als toevoeging. Het gebruik van de zogenaamde Captcha door een aantal sites. Oftewel moeilijk leesbare tekens die je over moet typen.
Dat het steeds meer opkomt is logisch, dit door automatische spamcomputers (zgn. bots), die formulieren invullen.
Sommige formulieren gebruiken echter zo’n onduidelijk leesbare Captcha, dat het voor mensen nog moeilijker wordt gemaakt dan voor computers.
Voor meer info en voorbeelden over Captcha zie http://nl.wikipedia.org/wiki/Captcha .
Om het stukje usability wat in de Wikipedia (bron) geschreven staat maar gelijk aan te halen:
— bron —
Toegankelijkheid
Captcha’s gebaseerd op het lezen van tekst ‚Äî of andere visueel herkenbare zaken ‚Äî staan visueel beperkte gebruikers het gebruik van datgene dat afgeschermd is in de weg. Captcha’s hoeven echter niet visueel te zijn. Elk ander probleem dat niet door kunstmatige intelligentie gekraakt kan worden, zoals spraakherkenning, kan als basis van een captcha gebruikt worden. Bij sommige typen captcha’s kan de gebruiker kiezen voor een audiocaptcha. De ontwikkeling van audiocaptcha’s is echter achtergebleven bij die van visuele captcha’s, hoewel deze zeker even doeltreffend zouden kunnen zijn.
Voor blinde en slechtziende gebruikers vormen visuele captcha’s een ernstig probleem. Doordat ze niet machinaal leesbaar zijn, kunnen hulpprogramma’s voor deze gebruikers, zoals schermlezers, de captcha ook niet interpreteren. Omdat captcha’s dikwijls gebruikt worden bij inschrijvingsprocessen (bijvoorbeeld bij Hotmail, eBay en Yahoo!), wordt de toegang tot deze diensten volledig belemmerd.
In het document Inaccessibility of Visually-Oriented Anti-Robot Tests (Engelstalig) schetst het W3C een aantal door captcha’s veroorzaakte toegankelijkheidsproblemen.
— einde bron —
Wat mij betreft dus nog een verbeterpunt voor een flink aantal formulieren.
Nog wat totaal anders…
De opmerking die ‘idioot’ maakt, kan ik me deels voorstellen. Alleen de manier van reageren door de persoon is wat mij betreft wat onvolwassen.
Waarom ik dit aanhaal, is dat het ook voor ‘dit’ reactie formulier opgaat. Nu snap ik wel dat het waarschijnlijk zo in WordPress gebouwd is, maar als ik een fout in dit formulier maak krijg ik bij verzenden een onduidelijke error. Ten tweede staan er Engelse (name, leave a comment) en Nederlandse teksten door elkaar heen.
Mijn mening is dat je niet met een vingertje kan gaan wijzen, als het op de eigen site ook nog niet goed gebeurd. Zonder het aanhalen van die organisaties was de omschrijving wat mij betreft ook al duidelijk.
Ik kom hier zeker vaker de blog lezen!
LikeLike
Kijkend naar punt 10, ik probeer mijn formulieren uit accessibility-oogpunt altijd zo veel mogelijk in elk geval werkbaar te houden zonder JavaScript. JS is in mijn visie een stukje toegevoegde waarde maar de basisfunctionaliteit mag hier niet van afhankelijk zijn.
Wat is jullie mening over de dubbele selectielijst? Aangezien deze wordt aangestuurd door JavaScript is het onmogelijk om hier mee te werken in een browser die dit niet ondersteunt. Of bieden we de linker dan alsnog aan als multiple select?
LikeLike
@Jurjen: mijn mening is dat Captcha ?©?©n van vele oplossingen tegen spam is.
De meeste spambots alleen zijn geprogrammeerd om HTML-formulieren te spideren en met een socketconnectie vervolgens hun spam te posten. De meesten ondersteunen geen cookies/sessies en uiteraard geen JavaScript. Hier kun je slim van profiteren door bijvoorbeeld een variabele in een cookie te stoppen bij het weergeven van het formulier en deze bij het verwerken te controleren. Ook kun je je formulier (deels) met JavaScript opbouwen, zodat de botjes deze minder gemakkelijk kunnen herkennen.
Op deze manier pak ik de spambotjes op hun eigen beperkingen. Het is niet altijd even waterdicht dus gebruik meerdere trucjes voor het beste resultaat.
Daarnaast is het gebruik van standaard e-mailformulieren en weblogsystemen een garantie voor spam.
LikeLike
@Sint
— dubbele selectielijst —
Ik zou denken dat je het overzetten van de keuzelijst naar de gekozenlijst in eerste instantie ook gewoon met een submit doet. Indien JavaScript ondersteund wordt doet deze zijn ding en blokkeert het de submit. Op dezelfde manier als popups dus:
<a href="http://www.usarchy.com" target="popup" onclick="popup(this.href,this.target);return false;">Usarchy Popup</a>popup() is hier natuurlijk een functie die een fancy popup tevoorschijn tovert
— spambots —
De manieren die je suggereert om de spambots te slim af te zijn zorgen er echter wel voor dat het formulier niet toegankelijk is voor een aantal bezoeker (zij die JavaScript en/of het gebruik van cookies uit hebben staan). En daar komen ze dan ook pas achter als ze hun zorgvuldig gekozen woorden proberen te posten. Erg vervelend.
Op de blog van Matt Cutts (om precies te zijn de pagina over de panelty die Trouw.nl onlangs van Google kreeg) kwam ik een variant tegen van captcha. In plaats van een plaatje, waarvan de cijfers/letters overgetypt moeten worden wordt er gevraagd om een simpel sommetje op te lossen. Dit is voor iederen toegankelijk! Voor de dyscalculisten kun je een variant maken waarbij twee woorden samengevoegd moeten worden.
Maar goed, je wilt natuurlijk eigenlijk helemaal niet van dat soort vragen stellen aan bezoekers (die daarmee bij voorbaat als mogelijke spambot worden aangezien). Dus toch JavaScript… wordt JavaScript namelijk ondersteund, dan kun je dit gebruiken om de som op te lossen voor de bezoeker en tevens de bewuste velden te verbergen. Arme sloebers zonder JavaScript moeten dus een simpel sommetje maken, maar krijgen daarvoor wel een toegankelijk en spamvrij gastenboek/forum en de overige bezoekers merken niet eens dat er een filter is.
Ik heb onlangs een dergelijk scriptje voor iemand geschreven. Het is inmiddels ge?Ømplementeerd en ik heb nog niet gehoord dat het niet werkt 😉.
LikeLike
Hmm, blijkbaar gaat er iets niet helemaal goed met de weergave van de HTML-code. Ik neem aan dat iedereen begrijpt wat er had moeten staan.
LikeLike
Pingback: duidelijk in vorm » Blog Archive » Formulieren 101
Pingback: Formuleren | yougo
Hoi Ruben,
Ik heb je tips eens uitgebreid doorlopen en heb er veel zinnige zaken uitgehaald.
Persoonlijk vind ik, met name bij wat complexere formulieren, dat validatie vaak een struikelblok is. Pure veld-validatie zoals jij beschrijft is prima client-side te doen. Waar het vaak misloopt (m.i.) is wanneer business-rules ook client-side opgelost dienen te worden. Dat zijn dan met name controles over meerder velden heen (dus bv: Wanneer geboortedatum voor 1-1-1980 en bruto-jaarinkomen > 50.000 euro dan mag de kleur van de auto niet groen zijn).
Kortom: mijn toevoeging bij validatie zou nog zijn:
Voer veld-validaties client-side uit en business-rules en/of interveld-validaties server-side uit.
Je tip bij vormgeving om aan te geven welk invoerveld focus heeft door de achtergrond geel te kleuren werkt helaas niet in Internet Explorer.
Tot slot: Na het lezen van je artikel heb ik “random” nog eens wat formulieren bekeken en zo te zien valt er nog veel te verbeteren. Zelfs bij usarchy 🙂
Gr.,
Jasja
LikeLike
@Jasja
Natuurlijk zijn dergelijke complexere validaties ook prima te doen in JavaScript (het wordt pas echt vervelend, maar niet onmogelijk, wanneer het formulier ook dynamisch wordt gemaakt via een CMS ofzo), maar server side validatie moet je sowieso hebben als er iets te valideren valt. Je kunt er gewoon niet van uitgaan dat iedereen JavaScript aan heeft staan.
Het focus-probleempje in IE kan ook door JavaScript opgeslost worden. De functionaliteit is er niet van afhankelijk, dus het gebruik van JS vormt geen probleem.
LikeLike
@Sander:
Om maar eens met het laatste te beginnen: helemaal mee eens dat je het “focus-probleempje” ook prima met JS kunt oplossen. Enige commentaar wat ik had is dat de voorgestelde CSS-oplossing niet werkt in IE.
Ook met je opmerking dat ook complexere validaties in JS prima te doen zijn ben ik het eens. Ik realiseer me nu wel dat ik wellicht wat teveel heb gedacht vanuit de realisatie kant van het geheel. Feit blijt m.i. dat het ontwikkelen van formulieren met business-logica aan de voorkant nodeloos ingewikkeld en tijdrovend wordt. Alleen al vanwege het feit dat je nooit kunt vertrouwen op het feit dat de bezoeker JS gebruikt betekent dat er altijd ook nog server-side validatie nodig is.
Just my 2c 🙂
LikeLike
Hallo,
Heel interessant artikel, en ik ben blij dat ik het meeste al zelf had verzonnen. Ik heb net een nieuwe formpje gemaakt voor mijn site waarmee mensen een prijsopgave aan kunnen vragen.
Uiteraard houd ik me aanbevolen voor suggesties! Maar ook voor complimenten 😉 http://www.rotterdamjazztrio.nl/prijzen/index.htm
m.v.gr,
Kars
LikeLike
Hi Joost, welkom als reageerder dan, en dank voor je compliment 🙂
LikeLike
Goeie artikel. Ik ben net zelf bezig met dit op onze website
http://www.jazzsupply.nl/contact.html
Als jullie opmerkingen hebben hoor ik het graag.
LikeLike
Pingback: Hoe (snel) antwoord je op een online contact aanvraag? - Frankwatching
Pingback: Hoe (snel) antwoord je op een online contact aanvraag? - Usarchy
Pingback: Minimaliseer uitval: “online formulieren en het menselijke geheugen” | Actual Insights
Pingback: 10e Blogkermis, over E-commerce - Usarchy
Pingback: concept en zo » Blog Archive » Online formulieren, makkelijk? Nee toch!
Pingback: Internetmarketing – avond 5 « HANdagen
???? ? ?? ?????, ??? ?????, ?? ??? ????? ???????!
LikeLike
Pingback: Online formulieren: Benodige Informatie | Share Joy | Vent Frustrations
Ik heb nu mijn formulier in twee delen gesplitst. Eens kijken of dat nog wat uitmaakt. Heb je daar nog specifieke ideeen over?
LikeLike