Vorige week kwam Yahoo! met haar ‘Yahoo! OpenID Usability Research’ naar buiten en dat was niet positief. Helaas moet ik ze gelijk geven, OpenID is momenteel niet gebruiksvriendelijk genoeg. En ik zal, aan de hand van dit onderzoek, ook uitleggen waarom.

Yahoo! conducted usability studies in July 2008 to understand the Yahoo! user experience while navigating the OpenID journey from the Relying Party to Yahoo! and back. The participants were all experienced Yahoo! users who were tasked with signing into to a 3rd party site using their Yahoo! IDs without having to create a new account for the site.

Aan de hand van dit onderzoek kwamen er enkele (grote) usability problemen naar voren.

‘Finding the right door’

Het eerste probleem wat gebruikers tegenkomen is dat er meerdere manieren van inloggen zijn. Er zijn weinig tot geen Relying Parties (websites die OpenID accepteren) die enkel en alleen OpenID gebruiken als inlogmethode. Kijk bijvoorbeeld bij Plaxo of Basecamp.

Basecamp login scherm, met OpenID optie

Zoals je op bovenstaand screenshot kunt zien is er een duidelijke inlogoptie voor de ‘Basecamp manier’, maar is OpenID het ondergeschoven kindje. De gemiddelde gebruiker gaat ervanuit dat er één manier van inloggen is op een website en zal hierdoor geneigd zijn om de gebruikersnaam en wachtwoord van, in dit geval, Yahoo! in te vullen bij Basecamp. En niet geheel verwonderlijk werkt dat niet.

Het eerste probleem is dus heel duidelijk dat de gebruiker niet weet bij welke ‘deur’ zijn sleutel werkt. Hier ligt aan de ene kant een taak voor de Relying Parties om de optie voor OpenID duidelijker aan te bieden, maar ook aan de OpenID Providers om duidelijker te maken dat en hoe de inloggegevens kunnen worden gebruikt met OpenID. Vertel de gebruikers niet dat je met je Yahoo! gebruikersnaam en wachtwoord kunt inloggen op andere websites, maar dat je als Yahoo! OpenID ondersteunt en, nog belangrijker, wat iemands OpenID URL is.

‘Using the lock’

Als de deur wel gevonden wordt treedt het tweede probleem op. Hoe gebruik je de sleutel? Gebruikers zijn al jaren gewend om een gebruikersnaam of eventueel emailadres in te vullen, maar OpenID werkt met URL’s. En dat vind ik persoonlijk geen slimme zet. Wáárom hebben ze hier gekozen voor URL’s? Een principe dat zelfs ik als doorgewinterde technisch opgeleide internetaddict in het begin moeilijk te begrijpen vond. Hoe moet een gebruiker dit dan wel snappen? Ik word gevraagd om mijn OpenID en ik verwacht zoals altijd dat dit een gebruikersnaam of emailadres is. Waarom moet ik hier een URL invoeren? “Die zijn toch voor websites?”

Als ik zou worden gevraagd om mijn (‘OpenID-enabled’) emailadres in te vullen is het voor mij ook veel beter te begrijpen dat ik vervolgens pas bij Yahoo! mijn wachtwoord invul. Een emailadres is namelijk om mee in te loggen en met een simpele zin ‘uw wachtwoord vult u pas in op de website van uw OpenID provider’ is die onduidelijkheid ook uit de wereld geholpen. Deze zin is natuurlijk ook nu al te plaatsen, maar gebruikers hebben bij een URL niet het gevoel dat het gebruikt wordt om mee in te loggen. Nog onduidelijker is het in het geval van Yahoo! waar je enkel ‘http://yahoo.com’ moet invullen in tegenstelling tot ‘http://openid.trebel.nl’ in mijn geval. Deze hele constructie heeft mij in het begin een hoop verwarring opgeleverd en dat had makkelijk voorkomen kunnen worden.

‘Understanding what the key unlocks’

Er zijn nog enkele problemen die zich voordoen, maar die zijn in mijn optiek meer een probleem van de implementatie van Yahoo! en de in dit onderzoek gebruikte ‘3rd party website’ dan een echt probleem van OpenID. Zo is het zo dat je bij Yahoo! wel automatisch inlogt op de 3rd party website EN Yahoo!, maar niet standaard ook weer bij Yahoo! uitlogt. Het is dus niet duidelijk waarop de sleutel allemaal toe te passen is en hoe het precies werkt.

Verschillende soorten sleutels

Een ander aspect, wat in dit onderzoek niet naar voren komt omdat er maar met één website is getest, wordt veroorzaakt door de verschillende versies van OpenID die momenteel in omloop zijn. Simpel gezegd was het in eerste instantie enkel mogelijk om met OpenID een gecentraliseerde loginprocedure mogelijk te maken. Gaandeweg bedacht men dat het ook best handig was als aan de Relying Parties het emailadres, gewenste gebruikersnaam, leeftijd, geslacht (etcetera) kon worden meegegeven, zodat de bezoeker deze bij het registreren met OpenID niet meer zelf hoefde in te vullen. Dit wordt echter nog slecht ondersteund. Veel OpenID Providers vragen dus wel om deze gegevens, maar je moet ze dus meestal nog (opnieuw) invullen op de Relying Party. Registreren door middel van OpenID brengt hierdoor meestal meer werk met zich mee dan ‘ouderwets’ registreren op de webste. Iets wat ook niet echt meehelpt voor de adoptatie van OpenID.

Implementatie loopt niet zoals verwacht

OpenID wordt in mijn optiek tegengewerkt door een slechte gebruikerservaring en ik vind het dan ook niet verwonderlijk dat de implementatie niet verloopt zoals verwacht. Als ik het al lastig vind om te begrijpen en er achter te komen wat het allemaal omvat, dan kan de gemiddelde internetgebruiker dit al helemaal niet.

Ik geloof nog steeds in het principe van OpenID en ben er ook van overtuigd dat een dergelijk principe de toekomst heeft. Echter, de grote usability problemen die OpenID momenteel heeft zorgen er echt voor dat het momenteel geen mainstream oplossing kan worden.

Update 20/10/2008 20:30:

Tijdens het eten bleef er in mijn achterhoofd iets knagen en na de reactie van Joost van der Borg ben ik even verder gaan zoeken. Er is kort geleden een draft uitgebracht als mogelijk extensie op het OpenID Authentication 2.0 protocol om het mogelijk te maken emailadressen te gebruiken voor OpenID. Samengevat luidt deze:

OpenID Email Address Transformation is an extension to the OpenID Authentication 2.0 protocol, and provides a straightforward mechanism to transform an RFC2822 email address into an OpenId-compatible Url. The transform procedure outlined in this document is designed to be flexible enough such that every DNS domain-owner can specify a unique transformation format that Relying Parties can easily discover and utilize in thier OpenId transactions.

Simpel gezegd komt het erop neer dat er een extra veld wordt toegevoegd aan de DNS server voor bijvoorbeeld het domein trebel.nl. Daarin staat dat de OpenID URL voor dit domein bijvoorbeeld http://openid.trebel.nl/[gebruikersnaam] is. Voor het emailadres timan@trebel.nl wordt dit vertaald naar http://openid.trebel.nl/timan.

Op deze manier wordt het voor gebruikers mogelijk om emailadressen te gaan gebruiken om in te loggen met OpenID en zal daarmee de moeilijkheidsgraad van OpenID aanzienlijk verlagen. Klein nadeel is natuurlijk dat dit enkel werkt voor Relying Parties die straks de nieuwe versie van OpenID ondersteunen.