Als internetgebruiker ontkom je er niet aan telkens maar weer in te loggen: Gmail; bol.com; Hyves; Facebook; Twitter; digg; WordPress; flickr; LinkedIn. Ik heb nu een mailfolder met de naam ‘sleutelhanger’ aangemaakt voor al die accountgegevens om de passwords snel te kunnen vinden en om overzicht te houden op waar ik allemaal geregistreerd sta.
Alle inlogformulieren zien er hetzelfde uit, lijkt. Twee tekstvelden en een knop; simpel en gebruiksvriendelijk. ‘Lijkt’ want veel ontwerpers raffelen het af, terwijl het juist waardevol is om het goed vorm te geven. Hoe eenvoudiger het inloggen, des te lager is de drempel om de dienst nog een keer te gebruiken.
Het inlogformulier is de deur naar de volledige functionaliteit van je website. Plaats een inlogformulier dus altijd bovenin op elke pagina, waar iedereen het vindt. Daarnaast zijn er misschien nog andere locaties om een inlogformulier te plaatsen die even zo relevant of zelfs relevanter zijn. Relevante plekken vind je bij mogelijkheden waar inloggen vereist is. Dat zijn momenten waarop je zonder account niet verder kan. Dat kan zelfs in een laat stadium zijn, bijvoorbeeld wanneer je besluit om een advertentie te plaatsen.
Laten inloggen wanneer dat nodig is klinkt logisch, maar hier gaat het erom dat je je website voor gasten (of gebruikers die niet zijn ingelogd) zo veel mogelijk eruit wilt laten zien als de versie voor ingelogde gebruikers. Door juist aan gasten alle functionaliteit te tonen, laat je ze wennen en toon je de toevoegde waarde van je website. Voor niet ingelogde gebruikers is het ook prettig, omdat ze mogelijk de website willen bezoeken maar op dat moment nog geen behoefte hebben om in te loggen. Zodra een gast beslist functionaliteit te gebruiken waarvoor een account nodig is, laat je een inlogformulier zien.
Je kunt ervoor kiezen om in een contextueel dialoog een inlogformulier te tonen zodra een bezoeker op ‘plaats advertentie’ klikt; een dialoogscherm direct naast de ‘plaats advertentie’ knop. Vorm en locatie van dit dialoogscherm maakt het verband tussen de knop en dialoogscherm duidelijk, vandaar de term: ‘contextueel’ dialoog.
Door het inlogformulier in een contextueel dialoog en niet op een aparte pagina te tonen verstoor je zo min mogelijk de verwachte ‘flow’. Gebruikers verwachten een ‘plaats advertentie’ pagina, niet een inlogpagina.
Geef in het inlog-dialoog helder aan waarom inloggen nodig is, bijvoorbeeld: Log in om je eigen advertenties te beheren.
Maak het doel voor het inloggen helder.
Wat is de beste plek om de labels ‘e-mail’ of ‘password’ te plaatsen? Zet je ze boven de invulvelden, links of zelfs er binnenin? Voor een inlogformulier is het optimaal om labels direct boven de invulvelden te zetten. Gebruikers van een formulier met labels boven de invulvelden kijken sneller (zelfs twee keer zo snel) het formulier door dan wanneer die labels direct links naast de velden staan. Het gaat om de oogbeweging; ogen hoeven nu maar in één richting te bewegen. (Luke Wroblewski, Web Form Design: Filling in the Blanks)
Het kan een bewuste keuze zijn om labels links van invulvelden te plaatsen zodra je juist wilt dat gebruikers de tijd ervoor nemen of als de beschikbare ruimte dat vereist.
Ik adviseer tevens om labels niet als placeholders in de velden te zetten, omdat een leeg invulveld juist helder naar de gebruiker communiceert dat hij het kan invullen.
Usability onderzoeker Jakob Nielsen promoot het idee om alle passwordvelden te veranderen naar tekstvelden zodat gebruikers zien wat ze typen en minder fouten maken tijdens het inloggen. Alleen zorgt dit voor problemen wanneer je bijvoorbeeld moet inloggen met je computer die is aangesloten op een projector terwijl een volle zaal meekijkt. Je mag je gebruikers nooit in verlegenheid brengen. Het advies van Jakob Nielsen is daarom onverstandig, maar het probleem van onopgemerkte typefouten in ‘*******’ blijft.
Een oplossing is om een optie te geven waarmee gebruikers zelf kunnen kiezen voor een gemaskeerd password of een password in leesbare tekst. Standaard toont het passwordveld kruisjes, maar vink je de checkbox aan dan zie je je password in leesbare tekst voordat je inlogt. Technisch gezien is zo’n switch op websites lastig in te bouwen, maar niet onmogelijk. Meer hierover kun je lezen in het artikel ‘The Problem with Passwords’ van Lyle Mullican. Hij gaat in op de technische uitwerking en geeft enkele voorbeelden.
Voorbeeld: Ik log in op mijn gmail-account om mijn vriendin iets te laten zien, ik type mijn gebruikersnaam en password in en druk op enter. He irritant, vergeet ik weer om ‘Stay signed in’ aan te vinken.
Zodra we een password invoeren, zijn onze hersenen bezig met het zich herinneren van het password en het inschatten of we überhaupt met dat password kunnen inloggen. We willen het resultaat zo snel mogelijk controleren en drukken op de entertoets. De optie ‘Stay signed in’ onder het password zien we daardoor meestal over het hoofd.
Als we het dan toch na het intypen van ons password opmerken, moeten we ook nog eens wisselen van toetsenbord naar muis. Bij formulieren is het juist de kunst om de gebruikers zo min mogelijk te laten wisselen tussen toetsenbord en muis.
Je lost het eenvoudig op door de optie ‘Stay signed in’ niet onder de invulvelden te plaatsen, maar erboven. De gebruiker navigeert sowieso met de muis naar het inlogformulier waardoor het aanvinken van ‘Stay signed in’ met de muis nauwelijks extra moeite kost. Daarna typt de gebruiker zijn loginnaam en password en logt in. Door de herplaatsing verwijder je een onnodige handeling en voorkom je veel vergissingen.
Ik zie steeds vaker op websites dat er een blauwe ‘Facebook login’ knop staat. Bezoekers kunnen daarmee direct inloggen met hun Facebook-account en hoeven niet voor elke website opnieuw een account aan te maken. Dit heet ‘Facebook connect’.
Misschien is dit voor de bezoeker handig en voor de ontwikkelaar gemakkelijk om te implementeren, maar hierdoor krijgt Facebook meer grip op jouw bezoekers. Facebook zal deze informatie zonder meer gebruiken om nog effectiever reclame aan jouw bezoekers te tonen. Houdt in het achterhoofd dat voor Facebook de reclamemakers de klanten zijn en de gebruikers de inventaris is.
Als website-eigenaar verlies je grip op je gebruikers. Reacties op jouw blog komen gemakkelijker op Facebook te staan waardoor de discussie over een onderwerp op jouw blog zich verplaatst naar Facebook. Dit kan in eerste instantie voor meer bezoekers zorgen, maar de splitsing tussen jouw website en Facebook vervaagt en je website wordt een onderdeel van Facebook.
Zodra iemand besluit te stoppen met Facebook, hoe moet hij dan nog gebruik kunnen maken van jouw website?
Dit is voor mij reden genoeg om terughoudend te zijn met Facebook connect en te adviseren om meer aandacht te besteden aan je eigen registratie- en loginformulier. Ik vind het absoluut geen probleem om voor meerdere websites een account aan te maken, als die websites maar toegevoegde waarde leveren en het zo gemakkelijk mogelijk maken om te registreren en in te loggen.
Een manier om het aanmaken van een account en inloggen aantrekkelijker te maken is door het inlogformulier en het registratieformulier samen te voegen tot één formulier. Afhankelijk van het systeem dat achter de website gegevens beheert is dit lastiger of gemakkelijker te implementeren.
De essentie van een account bestaat uit niet meer dan alleen wat nodig is om in te kunnen loggen: een gebruikersnaam en een password. Deze twee gegevens zijn dus voldoende om een account aan te maken. Andere profielgegevens kan de gebruiker altijd later toevoegen als hij of zij dat nuttig vindt. Dat is ook veel fijner voor de gebruiker als het ‘waarom’ van privé gegevens duidelijk is. Dan is de gebruiker veel bereidwilliger om informatie over zichzelf prijs te geven.
Na een simpele registratie van de gebruikersnaam en password kan de website je bezoekers direct leiden naar de functionaliteit die een website biedt. Het is na ‘inloggen & registeren in één’ alsof de nieuwe bezoeker aan het inloggen was. Het systeem stuurt de gebruiker een mailtje met de account gegevens en een link om de aanmelding binnen een bepaalde periode te verifiëren.
Beter is het dus om bij het ontwerp van een website je altijd af te vragen waarom een inlog- en registratieformulier twee verschillende formulieren zouden moeten zijn. Ter inspiratie, Leah Culver toont op haar blog een aantal goede voorbeelden van gecombineerde inlog- en registratieformulieren.
De waarde van een webdienst kan je meten aan de hoeveelheid gebruikers. Maak het hen dus zo makkelijk mogelijk om te registreren en in te loggen.
Design Lead bij Incision. M'n achtergrond: Industrieel Ontwerpen en daarna Psychologie aan de Universiteit Twente, afgestudeerd bij Philips op midair pointing voor een nieuwe generatie TV's, Apple Design Award voor CSSEdit, usability onderzoeker bij MetrixLab en blogger.