Figuur 8: de beschikbare tekstregels op het scherm
Dit hoofdstuk wil toekomstige ontwikkelaars een leidraad bieden wanneer zij aan de slag gaan. Deze praktische tips zorgen ervoor dat er een perfect evenwicht kan gevonden worden tussen functionaliteit en gebruiksvriendelijkheid. Want bij het ontwikkelen van toepassingen mogen we de uiteindelijke terminal niet uit het oog verliezen. De specifieke kenmerken, zoals beperkte invoermogelijkheden en een klein scherm, bepalen in grote mate de vorm en de structuur van een toepassing.
Wanneer men gaat beslissen welke informatie men wil voorzien in de verschillende toepassingen voor een mobiele telefoon, denkt men beter tweemaal na over welke informatie nu echt relevant is in die omstandigheden waarin het mobiel toestel zal gebruikt worden. Omwille van het kleine scherm is het zo dat de gebruiker een GSM zal benutten om te surfen enkel in die omstandigheden wanneer er geen toegang is tot Internet via een computer.
Het staat dan ook als een paal boven water dat de gebruikers geïnteresseerd zullen zijn in korte en snelle informatie. Bijvoorbeeld, snelle toegang tot de vluchttijden via een GSM kan relevant zijn voor de gebruiker die op weg is naar de luchthaven en moet controleren op welk uur de vlucht vertrekt. Ook korte nieuwsberichten zijn relevanter dan hun langere en uitgebreidere versies. Snelle toegang tot weerberichten is een andere interessante toepassing, omdat de gebruiker dan snel kan weten hoe het is gesteld met de temperatuur op de bestemming. Daarentegen is het zeer onwaarschijnlijk dat gebruikers de GSM zullen benutten om te surfen, daarvoor verkiezen ze de toegang tot het Internet via een computer, hetzij thuis of op kantoor.
De kleine schermen van een GSM limiteren de hoeveelheid informatie die kan worden getoond, in vergelijking met een computer. De computer voorziet meer ruimte voor animaties en extra informatie. Bij een GSM moet dan ook speciale aandacht geschonken worden aan het selecteren van de informatie die zal worden getoond. Natuurlijk zal de meest waardevolle informatie hier voorrang hebben. Zoals hierboven werd gesteld, moet grondig nagedacht worden over welke informatie relevant is voor het mobiel gebruik.
Schenk aandacht aan de lengte van de tekst in de toepassingen voor mobiele toestellen. Wanneer er tekst wordt gelezen, kunnen er slechts 4 regels per keer bekeken worden. Als de gebruiker moet scrollen, bestaat het gevaar altijd dat hij de draad kwijtraakt als de tekst te lang is.
Daarom volgende vuistregel: de tekst moet beperkt worden tot een lengte van maximaal 4 of 5 schermen, dat is dus ongeveer 16 tot 20 lijnen tekst. Onderstaande figuur toont de vier regels die beschikbaar zijn:
Merk op dat in deze vier regels de titelbalk (bovenaan: Table 2x2) en de navigatiebalk (onderaan: Options en Back) inbegrepen zijn. Men hoeft er bij het ontwikkelen dus geen rekening mee te houden.
Looping verwijst naar de manier waarop het laatste element in een lijst automatisch gevolgd wordt door het eerste uit dezelfde lijst. Als de gebruiker naar beneden navigeert wanneer het laatste element werd getoond op het einde van de pagina, zal het volgende element automatisch het eerste uit de lijst zijn.
Loops worden ondersteund bij:
Loops worden niet ondersteund bij:
Men kan gerust afbeeldingen tonen aan de gebruiker via de GSM. De maximumgrootte van de afbeelding is 96 op 44 pixels. Een afbeelding kan worden gebruikt om het logo van de dienst te tonen wanneer deze wordt opgeroepen.
Als de afbeelding maximaal één regel hoog is (11 pixels), dan kunnen er nog drie regels tekst worden getoond op hetzelfde scherm, hetzij boven of onder de afbeelding. Op dezelfde manier geldt dat wanneer de afbeelding 22 pixels hoog is, er nog twee regels tekst mogelijk zijn, en is de afbeelding 33 pixels dan kan nog net één regel tekst getoond worden op hetzelfde scherm.
Belangrijk is wel dat tekst nooit naast een afbeelding kan staan. De afbeelding "eist" altijd eigen regels op. Onderstaande figuur illustreert dit:
We zien dus dat de afbeelding een hoogte heeft van twee regels (22 pixels). Er zijn dus nog twee tekstregels mogelijk. De ene staat boven de afbeelding, de andere staat eronder.
Vermijd dat er teveel witte ruimte zit tussen verschillende elementen, vermits het afbreuk zal doen aan de eenvoudige navigeerbaarheid voor de gebruiker, en het verbetert trouwens ook het gebruik van een toepassing niet. Het is dan ook warm aanbevolen om elementen zo op een card te plaatsen, dat de gebruiker ze onmiddellijk allemaal ziet wanneer hij deze card oproept.
De linkse "softkey" (zie hoofdstuk 5: De ontwikkelomgeving) wordt gebruikt om het menu binnen te gaan, en om commando’s uit te voeren. De rechtse "softkey" wordt dan benut om uit een menu te gaan, en om commando’s te annuleren, maar ook om te navigeren in de history van het toestel.
Het is bovendien een algemene navigatieregel dat gebruikers altijd moeten beschikken over een eenvoudige manier om terug te gaan in een applicatie. De gebruiker moet altijd in de mogelijkheid gesteld worden om commando’s te annuleren. Dit is vooral belangrijk in die omstandigheden waar de gebruiker enkel nieuwsgierig is om de toepassing te verkennen (om alles uit te testen) en wanneer de gebruiker een eenvoudige manier zoekt om het programma te verlaten. Het succes van een toepassing hangt dan ook in zeer belangrijke mate af van de indruk die de gebruiker heeft over het al dan niet eenvoudig navigeren. Het is daarom ook dat een gemakkelijke ‘escape route’ het gevoel van controle die de gebruiker heeft over de applicatie, doet toenemen.
Een ander belangrijk principe stelt dat men de gebruiker altijd de mogelijkheid moet geven om belangrijke acties op meer dan één manier uit te voeren.
De hiërarchie van een toepassing bepaalt de structuur van de navigatie binnenin de toepassing. Hoe meer lagen toegevoegd werden, of door de gebruiker waargenomen worden, hoe ingewikkelder de navigatie wordt. Dan bestaat het risico dat de gebruiker de draad kwijtraakt, en een gevoel krijgt van controleverlies. De meeste gebruiker hebben graag een referentiepunt, een plaats waar ze vertrouwd mee zijn en die ze herkennen wanneer ze door de cards navigeren. Hoe verder men gaat in de hiërarchie (en dus hoe verder men weggaat van het referentiepunt), hoe meer de gebruiker zich zal ongerust maken over hoe terug te keren naar dit referentiepunt.
Het volgende voorbeeld heeft zo’n diepe hiërarchie vermeden door de gebruiker toe te laten om te scrollen in de ‘Results’ card, in plaats van de navigatie te voorzien via links.
Figuur 11 daarentegen geeft een voorbeeld van hoe het niet moet: de gebruiker kan verdwaald raken door de vele extra lagen die toegevoegd worden aan de hiërarchie als gevolg van het verzorgen van de navigatie tussen de schermen via het selecteren van links.
Denk dus grondig na over de manier waarop de navigatie moet voorzien worden!
De headers zijn titels die de inhoud van het scherm omschrijven en het gebruik hiervan wordt zeker aanbevolen. Ze helpen de gebruiker om door de toepassingen te navigeren omdat ze dienst doen als een hulpje dat aangeeft waar de gebruiker zich bevindt in de toepassing. De header moet bepaald worden door het element dat voordien werd geselecteerd door de gebruiker. De header ‘Bookmarks’ vertelt de gebruiker dat deze card een lijst bevat met alle bookmarks, en dus dat het element dat het laatst werd geselecteerd ‘Bookmarks’ was.
Er worden proportionele lettertypes gebruikt voor de headers, en wanneer de header te lang is wordt deze automatisch afgeknipt. Dit is veel beter dan wanneer men ervoor opteert om een header af te korten, omdat gebruikers verward kunnen worden door ongekende afkortingen die moeilijk te begrijpen zijn.
Omdat deze mogelijkheid goed gekend is van het Internet, weten gebruikers intuïtief dat het aanklikken van een link hun meer informatie verschaft. Links zijn dan ook een krachtige tool om verschillende informatie te verbinden en ook om te lange pagina’s (cards) te vermijden. Het gebruik van links wordt aangemoedigd, maar rekening houdend met de opmerkingen in verband met de navigatieprincipes; dus geen diepe hiërarchie!
Het is uiterst belangrijk om de gebruikte terminologie consistent te houden. Inconsistente terminologie verwart de gebruiker nodeloos, en maakt het navigeren complex. Consistente terminologie maakt het mogelijk om te denken in termen van schermen, en om elk scherm te herkennen wanneer men door ze navigeert.
In het onderstaande voorbeeld is de tekst ‘CNN Homepage’ consistent met de header van het tweede scherm ‘CNN Homepage’.
Ook hier weer een voorbeeld van hoe het niet moet. De tekst ‘Return Home’ is niet consistent met de header van het tweede scherm ‘CNN Homepage’, wat de gebruiker in verwarring kan brengen.
De woordlengte kan soms problemen stellen op kleine schermen. Daarom moet speciale aandacht geschonken worden aan de keuze van korte woorden. Probeer ook afkortingen te vermijden indien mogelijk, omdat het nagaan van de betekenis van een vreemde afkorting zeer moeilijk en verwarrend kan zijn voor de gebruiker. Om te vermijden dat woorden gesplitst moeten worden, voorzien de mobiele terminals ‘word wrapping’. Daarbij moet ook aandacht geschonken worden aan het internationale aspect. Woorden die kort zijn in het Engels kunnen zeer lang zijn in bepaalde andere talen zoals het Fins of het Hongaars.
De inhoud van helpteksten moet zeer nauwkeurig bepaald worden. Voeg helpteksten dan ook enkel en alleen toe als hun inhoud relevant is voor de specifieke gebruiks-situatie. De tekst moet relevant zijn met betrekking tot de card waarvoor ze is bedoeld.
Men moet bijvoorbeeld proberen te vermijden dat helpteksten uitleggen hoe de scrolltoets werkt omdat aangenomen kan worden dat de werking van deze toets door de gebruiker is gekend op het ogenblik dat deze de applicatie uitvoert. Het is daarentegen wel een goed idee om relevante informatie omtrent een bepaalde card te voorzien. Dat kan het best gedaan worden door op die betreffende card een duidelijk helpelement in te bouwen, zoals onderstaande figuur weergeeft.
Het is altijd aan te raden om nieuwe toepassingen grondig te testen. Mensen die niet betrokken waren bij het ontwerp van de toepassing hebben de neiging om potentiële gebruiksproblemen sneller te ontdekken die niet meteen zichtbaar zijn voor de ontwikkelaar. Deze tests moeten liefst zo vroeg mogelijk uitgevoerd worden in het proces van ontwikkeling om bijsturing zo snel mogelijk toe te laten.