[Dutch] Als Google je ontwerp namaakt, dan moet het wel goed zijn

De 9292.nl websiteBegin dit jaar begonnen we met Q42 en Fabrique samen aan de ontwikkeling van een nieuwe iPhone app voor 9292. Natuurlijk zijn we altijd gefocust op de beste gebruikerservaring. Ook bij de ontwikkeling van de iPhone app probeerden we weer een slag te slaan op UX-gebied, zelfs ten opzichte van de vernieuwde 9292.nl website die we een half jaar daarvoor hadden gebouwd.

Om een route met het OV te plannen zijn er fundamenteel drie gegevens nodig: een vertreklocatie, een aankomstlocatie en een tijdstip. Toen we begin 2011 de nieuwe 9292.nl site maakten hebben we veel tijd besteed aan het versimpelen van adresinvoer. We zijn van drie invoervelden op de oude site (plaats, type, locatie) teruggegaan naar één invoerveld met intelligente contextgevoelige suggesties. Het tijdinvoergedeelte bleef echter hetzelfde als op de vorige site: een datumkiezer, een tijdinvoer en twee radio buttons voor ‘Vertrek’ en ‘Aankomst’.

iPhone

9292 iPhone app homescreenDe iPhone app begint heel prominent met een vraag “Waar wil je heen?”. We wilden het daadwerkelijk plannen van een reis zo dicht mogelijk brengen bij het antwoord van de gebruiker op die vraag. Dus je vult enkel het ‘Naar’ adres in (bijvoorbeeld ‘Thuis’ uit je favorieten), en dan plannen we de snelste reis naar huis met het OV. Om te kunnen plannen met maar 1 invoer moeten we default waarden kiezen voor overige velden. Dat was niet moeilijk voor de vertreklocatie, de iPhone heeft een GPS sensor, dus we kunnen je huidige locatie als vertrekpunt nemen. Het kiezen van een default voor het tijdstip was iets meer denkwerk.

Er zijn 3 verschillende scenario’s hoe gebruikers een tijdstip invoeren bij 9292:

  • Aankomst + tijdstip: “Ik heb om 18:00 afgesproken op de Korenmarkt in Arnhem, toon mij een reis.”
  • Vertrek + nu: “Ik wil zo snel mogelijk naar huis.”
  • Vertrek + tijdstip: “Om 14:00 is het seminar afgelopen, hoe kom ik weer op mijn werk?”

Het invoeren van een aankomsttijdstip is een grote use case, maar wij weten niet om welke tijd je ergens wilt aankomen, dus daar kunnen we geen default voor invullen. Vandaar dat we als default waarde hebben gekozen voor de tweede use case: Vertrek nu.

Het samenvoegen van de datum- en tijdvelden op de iPhone app was niet zo’n moeilijke keuze. iOS heeft standaard een datum+tijd control die we graag wilden gebruiken omdat iPhone-gebruikers daarmee bekend zijn. De realisatie dat de keuze voor vertrek of aankomst onderdeel van de tijdkeuze is, duurde wat langer. Je kiest niet een tijdstip, en kiest vervolgens of je dan wilt aankomen of vertrekken, nee je kiest een aankomst- of vertrektijd.

Grafisch

Toen we eenmaal door hadden dat ‘tijd’ één veld is, dat bestaat uit drie componenten, werd het grafisch ontwerp ook makkelijker. De iPhone app heeft maar drie velden (in plaats van vijf): Van-locatie (met default waarde “Huidige locatie”), Naar-locatie, en tijdstip (met default waarde “Vertrek nu”).

Het tijdinvoer schermAls je op dat veld tapt verschijnt er een datepicker. Rechtsboven zit een Kies-knop waarmee je je selectie kunt bevestigen. Links boven zit een Nu-knop. Deze stelt ‘Vertrek nu’ in en sluit de ‘datepicker’ ook weer. Tussen die twee knoppen zit de keuze voor ‘Vertrek’ of ‘Aankomst’. Hiervoor wilden we geen toggle button met twee kleuren maken, omdat het dan moeilijk is om te zien welke van de twee geselecteerd is.

De twee knoppen ‘Kies’ en ‘Nu’ hebben we dezelfde zwarte kleur gegeven omdat ze beiden hetzelfe effect hebben: de datepicker wordt gesloten. De ‘Vertrek’ en ‘Aankomst’ knoppen wilden we daarom twee andere kleuren geven: geselecteerd en niet-geselecteerd. Om extra te verduidelijken welke van de twee opties geselecteerd is, hebben we een vinkje bij de geselecteerde optie gezet. Door het vinkje in het midden de plaatsen konden we die gebruiken voor beide opties, en bespaarden we ook horizontale ruimte. Door het blauwe vlak mee te laten bewegen met je vinger lijkt het op een zelfde soort schuifje als door heel iOS gebruikt wordt als ‘on/off’-knop.

Technisch

Als programmeur ben ik de hele dag door bezig met data-modelering, en ik vraag me dan ook af waarom het zo lang heeft geduurd voordat we ons realiseerden dat ‘vertrektijd’ en ‘aankomsttijd’ één begrip is. Misschien heeft het, voor mij in ieder geval, te maken met de gebruikte technologie. We hebben het server gedeelte van 9292 ontwikkeld in C#, een taal die geen algebraische data-types kent. Daarom hebben we tijd en vertrek/aankomst met twee velden geïmplementeerd, bijvoorbeeld: ‘dateTime=2012-12-14T07:00‘ en ‘searchType=Departure‘. Dit beïnvloede mijn denken erg, waardoor ik de twee velden lang als apart heb gezien.

Als we een programmeertaal met algebraische data-types hadden gebruikt, bijvoorbeeld Scala of Haskell, had ik het waarschijnlijk zoals hieronder gemodelleerd, en had ik mij daarmee gelijk gerealiseerd dat ‘tijdstip’ één ding is.

data TimeDetails = Departure DateTime | Arrival DateTime

Als programmeur moet ik in systemen denken en het helpt erg als die systemen even expressief zijn als het mentale model van gebruikers. Dan hoef ik niet constant die vertaling te doen.

Tot slot

Gisteren kwam Google Maps voor iOS uit. Tot mijn verassing zag ik een bekend scherm daarin. Blijkbaar heeft Google dezelfde realisatie gehad als wij. Ze zij in ieder geval op exact dezelfde UI uitgekomen!

9292 tegenover Google Maps

Zou Google even veel tijd aan dit veld hebben besteed als wij? Ik hoop in ieder geval dat we hiermee duizenden gebruikers misschien een halve seconde aan tijd kunnen besparen. Ik wacht de calculatie van Google wel af waarin zij berekenen hoeveel uur frustratie we gezamenlijk de mensheid bespaard hebben.