Hulp
Boekenmaker (uitschakelen)

Research and Development 1/^Archief/2009-2010/03/Theoretisch kader

Uit Werkplaats
Ga naar: navigatie, zoeken 
Hoofdvraag: Waaraan moet het ontwerp voor een studentenportaal voldoen zodat het gebruiksvriendelijk, snel en eenvoudig is.

Inleiding

In dit theoretisch kader wordt gekeken naar de diverse aspecten die komen kijken bij het opzetten van een gebruikersinterface. Gezien de aard van dit onderzoek zal het zich slechts hier en daar bezig houden met de grafische aspecten van het ontwerp. Wel wordt gekeken naar schermgebruik in de bredere zin. Vanuit het perspectief van zowel de gebruiker als de ontwerper wordt gekeken naar de verwachtingen van beide partijen, hun gedrag en de interactie met het systeem. Punten die allemaal van belang zijn bij het opzetten van een systeem waar alle belanghebbenden tevreden mee zijn.

Aspecten van ontwerp

Gebruikerskennis

"Ken de gebruiker" is het eerste princiepe van Hansens's [1] lijst van user engineering principles, een simpel idee maar erg lastig om uit te voeren. Het wordt zelfs ondergewaardeerd . Succesvolle ontwerpers zijn er zich bewust van dat andere mensen anders leren, denken en problemen oplossen. Elk ontwerp zou moeten beginnen met een goed beeld van de toekomstige gebruikers, inclusief hun leeftijd, geslacht, opleidingsniveau, culturele achetrgrond, training, motivatie, doelen en persoonlijkheden. Dit is een nooit ophoudend proces omdat de gebruiker blijft veranderen. Het ontwerp zal hierin mee moeten gaan. Een helder voorbeeld hierin is het verschil tussen een ontwerp voor kleuters en volwassenen. Subtieler is het verschil in ontwerp tussen beta en alfa studenten. Bij het vormen van een beeld van de gebruikers wordt tevens onderscheid gemaakt tussen First time users, Knowledgeable intermittent users en Expert frequent users. Elk heeft hun eigen doelen, motivaties etcetera. Een systeem ontwerpen voor slechts één van deze gebruikersgroepen is niet moeilijk; een systeem ontwerpen voor alledrie is veel moeilijker. [2] Informatica/informatiekunde studenten zijn ook first time users, maar wel met veel voorkennis en ervaring met systemen.

Over de gebruiker worden zoals aangegeven veel aannames gedaan waarbij men denkt te weten hoe de gebruiker leert, denkt en problemen oplost. Wat voor een programmeur vanzelfsprekend is dient dan ook voor de gebruiker vanzelfsprekend te zijn. Een fout die veel gemaakt wordt en zich onder andere uit in onbegrijpbare foutmeldingen, complexe procedures en voor gebruikers onlogische structuren.

De gebruiker gedraagd zich niet altijd zoals de programmeur verwacht. Enkele voorbeelden van veelvoorkomende gedragingen zijn:

  • Gebruikers lezen niet de hele pagina
  • Gebruikers houden er niet van om tekst online te lezen
  • Gebruikers zijn erg gesteld op hun tijd
  • De meeste gebruikers maken slechts sporadisch gebruik van je site
  • Gebruikers kunnen terecht komen op je site via andere wegen dan de homepage
  • Gebruikers willen niet onnodig moeite doen
  • Gebruikers zijn slechts geintereseerd in een klein gedeelte van de inhoud per bezoek
  • Gebruikers raken de weg kwijt
  • Een prettige grafische layout wordt gewaardeerd
  • Niet alle gebruikers maken gebruik van de zelfde browser
  • Gebruiksgemak staat bij de gebruiker hoog in het vaandel.[3]

Om in te spelen op het gedrag van de gebruiker en verwarring te voorkomen loont het om menu's niet dieper te maken dan drie niveaus, de grafische vormgeving rustig te houden waarbij een huisstijl het geheel ten goede zal komen. Zeker omdat deze huisstijl opgenomen kan worden in conventies over vormgeving zodat eventuele toekomstige sites goed aansluiten bij het geheel. Het ontwerp draait om het bereiken van een doel, met bepaalde beperkingen. Binnen mens machiene interactie is het doel vaak onduidelijk. Hier zou een substantieel aandeel van de ontwerptijd in moeten gaan zitten, om daadwerkelijk goed op papier te krijgen wat het doel van het systeem is, voordat het wordt gebouwd. De beperkingen hierbij liggen in het begrijpen van de materialen waarmee gewerkt wordt: de computer en vooral de gebruiker.

Dat wat uiteindelijk gebouwd wordt moet:

  • Nuttig zijn: De gebruiker krijgt wat hij wil
  • Bruikbaar: Wat wat de gebruiker wil moet eenvoudig en effectief gedaan kunnen worden
  • Gebruikt worden: De gebruiker gaat daadwerkelijk het systeem gebruiken en blijft dit ook gebruiken

Schermgebruik

Figuur 1, F-vormig kijkgedrag volgens Nielsen bij een typische pagina indeling
Figuur 2, Kijkgedrag bij een portaal-stijl pagina. De witte lijn is de "fold", alles onder die lijn is niet zichtbaar op het browserscherm zonder omlaag te scrollen.

Over de jaren zijn schermresoluties steeds groter geworden. In 2007 was de meest gangbare schermresolutie nog 800x600[4], dit is in 2009 al gestegen naar 1024x768 voor 44% van de gebruikers en nog eens 31% die een scherm gebruikt van 1280x1024.[5] Hieruit kunnen we concluderen dat verreweg het merendeel van de gebruikers een groot scherm ter beschikking heeft. Het is dan ook aan te raden om een nieuw te ontwerpen interface hieraan aan te passen. Aan de andere kant hebben we ook de smartphones die vooralsnog niet over zulke grote schermen beschikken. (HTC Desire:480x800, iPhone G4:960×640) maar hier wordt handig gebruik gemaakt van zoommogelijkheden. Met deze platforms houden we in het ontwerp geen verdere rekening omdat elke gebruiker die wij voor ogen hebben de beschikking heeft over een computer thuis, of op de faculteit.

Het gaat niet alleen over schermformaat maar ook waar iets op het scherm is te vinden. Over de jaren is de gebruiker gewend geraakt aan bepaalde schermindelingen en heeft hier verwachtingen over:

  • Een “home” knop linksboven, de home knop zit soms verwerkt in het logo, dat ook hier verwacht wordt.
  • Interne koppelingen linksboven
  • Externe koppelingen rechts of linksonder
  • Interne zoekmachine middenbovenin

Het is gebleken dat gebruikers een algemeen beeld ontwikkelen over schermindeling en het ligt dan ook in de verwachting hieraan te voldoen.[6] Deze indeling komt uit de beginjaren van het internet toen de mogelijkheden nog zeer beperkt waren (geen javascript, wel HTML). Er zijn veel sites te vinden op het web die een andere indeling hanteren maar menig site houdt vast aan deze oude indelingen waar de gebruiker (en de maker) zo vertrouwd mee zijn geraakt. Een vervolgstudie vier jaar later toont aan dat hier niet veel in is veranderd. Het meest opvallende verschillen zijn dat interne koppelingen ook wel verwacht worden in een rij bovenin het scherm en de interne zoekmachine is verschoven naar rechtsbovenin. Gebruikers verwachten nu ook een “over ons” koppeling in de footer van de pagina.[7]

Volgens Nielsen[8]zijn gebruikers geneigd hun aandacht te vestigen op de linker kant van het scherm tijdens het lezen van een pagina. Een gevolg hiervan is dat informatie aan de rechter kant van het scherm niet of nouwelijks word gezien. Hier komt nog bij dat het lezen van web content gebeurd erg snel. De meeste gebruikers nemen niet de tijd om zorgvuldig opgestelde teksten te lezen maar scannen de tekst als het ware. Het dominante patroon hierin is F-vormig met de volgende drie componenten:

  1. Als eerste wordt er in een horizontale beweging gelezen, meestal bovenaan de pagina
  2. Vervolgens wordt een stuk omlaag een tweede horizontale lijn bekeken
  3. Als laatste wordt de linker kant van de content in een vertikale beweging bekeken.

Figuur 1 toont een voorbeeld van dit patroon, warmere kleuren geven een langere fixatie aan op dat deel van het scherm. Een rede hiervoor wordt echter niet gegeven maar wel over gespeculeerd. Twee mogelijke opties zijn de verwachtingen over schermindeling en de culturele achtergrond van de Westerse wereld over hoe een tekst gelezen wordt. Merk dan ook op dat bij deze pagina de indeling overeen komt met de verwachtingen van de gebruiker. De interne snelkoppelingen links en in een rij bovenin, de zoekmachine rechts bovenin. Wat echter ook opvalt is dat de gebruiker vrijwel niet kijkt naar het logo of het horizontale menu. Ook de advertenties helemaal rechts krijgen weinig aandacht.[9] Het F-vormige patroon wordt hier ingezet op de tekst zelf, en niet op de gehele webpagina.

Deze onderzoeken geven aan dat de gebruiker bepaalde verwachtingen heeft en zich voorspelbaar gedraagd als het gaat om het consumeren van gegeven en zoeken naar functionaliteiten. Wel wordt ook aangegeven dat gebruikers erg snel leren, en zeker na herhaaldelijk gebruik een andere layout net zo snel weten te gebruiken. Een intuitief ontwerp waar gebruiksgemak voorop staat kan echter het beste aan de verwachtingen voldoen over indeling.

Ook is onderzoek gedaan naar de verschillen tussen 1-kolommige en 2-kolommige sites. [10] waar uit naar voren komt dat bij een 2-kolommige indeling de linker kolom veruit het meest beken wordt waarbij weer het door Nielsen beschreven patroon terug te zien is. Als laatste is nog gekeken naar indelingen in de stijl van iGoogle. De zogenaamde portal pagina's. Gebruikers bekijken een site in deze layout per rij in plaats van per kolom, beginnende linksboven zoals telkens het geval is in deze studies. Informatie die gezien moet worden kan dan ook het beste hier neer worden gezet. Figuur 2 toont de "heatmap" van zo'n portal pagina waar op is te zien dat ook de kanalen middenboven en linksonder veel bekeken worden. In het onderzoek is ook gekeken naar de effecten van verschillende kleuren titels voor de kanalen. Hoewel er wel een verschil waarneembaar was is hoe lang er naar werd gekeken was dit verschil marginaal. Ook was het effect sterker aan de linker kant van het scherm dan aan de rechter. [11]


De kernpunten van schermgebruik

  • Schermen worden steeds groter maar ontwerpers blijven ontwerpen voor lage resoluties (800x600)
  • De gebruiker heeft verwachtingen over de lokaties van bepaalde functionaliteiten zoals menu's, "help" en zoekbalken
  • De gebruiker gedraagd zich voorspelbaar in kijkgedrag, hij begint linksboven en werkt zich in een F-patroon omlaag
  • Belangrijke informatie moet dan ook in dit patroon worden aangeboden


Informatiearchitectuur

Het beschikbaar stellen van informatie is een delicate balans. Te veel en de gebruiker ziet door de bomen het bos niet meer, te weinig en de gebruiker is ontevreden. Al in 1998[12] is onderzoek gedaan naar informatie presentatie op een web pagina. Hoewel de mogelijkheden tegenwoordig veel groter zijn, zijn de zeven belangrijkste punten van datapresentatie nog altijd van toepassing:

  1. Displayed information should be readable to the degree of accuracy required by the task
  2. Text should be readable from normal viewing distance
  3. Users should be able to distinguish between available and unavailable options
  4. Largest text size should not exceed 10% of vertical display height
  5. Error messages should reflect a user's viewpoint, not a programmer's
  6. Location of recurring functional groups or items should be the same from panel to panel
  7. Criteria should be established for prioritizing information, and this priority should be utilized in the placement of information.

Naast deze punten zijn er nog meer opgesteld, 63 in totaal, waarop de onderzoeksgroep (n=34) werd beoordeeld. Van de applicaties waren er 8 die het eerste punt uit de hierboven genoemde lijst misten en een applicatie mistte in totaal 22 van de gestelde punten over de gehele lijst. Representatie van informatie is niet het enige waarvoor richtlijnen te vinden zijn. Ook is er veel geschreven over hoe het invoeren en manipuleren van data in zijn werk zou moeten gaan. Het gaat hierbij om gegevensuitwisseling tussen de gebruiker en het systeem. Niet alleen moet de gebruiker data aan het systeem door kunnen geven maar het systeem moet ook terugkoppelingen geven. De basiselementen hiervan zijn:

  • Data acceptance or rejection Actieve bevestiging danwel verwerping van de ingevoerde gegevens.
  • Log-on prompts Toepassingen die een login vereisen moeten voorzien zijn van promts die aangeven wat er mis gaat indien dit van toepassing is.
  • Help Een deugdelijke up-to-date help die vanuit alle locaties te bereiken is, gesorteerd op onderwerp. (Een f.a.q. is ook een goed idee)
  • Omissions Indien een verplicht veld niet is ingevuld moet het systeem dit aangeven als de gebruiker de informatie wil invoeren.
  • Error correction Een eenvoudige manier om foutief ingevoerde gegevens te weizigen. Dit op zo'n manier dat alleen de foutive data opnieuw hoeft te worden ingevuld.
  • Meaningful messages Alle berichten moeten betekenisvol zijn voor de gebruiker; aangevende welke stappen ondernomen moeten worden om verder te gaan.
  • Positive indication function actuation Toepassingen moeten als zij worden geactiveerd dit duidelijk aangeven.
  • User information Toepassingen die potentieel destructief zijn (wissen of overschijven van gegevens) dienen een bevestiging van de gebruiker te vragen.
  • Minimizing user action Voor zover mogelijk moet het systeem de gebruiker bijstaan in invullen van gegevens en deze aanvullen indien mogelijk.
  • Data entry Complexe regels voor de invoer van gegevens moeten zo veel mogelijk vermeden worden. De invoer van gegevens moet alleen case sensitive zijn indien hier een goede rede voor is.
  • Required or optional fields Van in te vullen velden moet duidelijk zijn of dit verplichte velden of optioneel.
  • Process abort Indien dit relevant is dient het systeem aan te geven dat een proces mislukt.
  • Data entry field Het formaat van de datavelden dient aangepast te zijn aan de hoeveelheid in te voeren data.
  • Sequencing Items moeten in het algemeen zo geordend zijn dat hier een logische volgorde in zit ten behoeve van de taak.

Om al deze punten consequent toe te passen moeten conventies opgesteld worden over hoe het systeem dient te werken. Bij grotere projecten met verschillende belanghebbenden en programmeurs zal ieder er zijn eigen invulling aan geven tenzij er duidelijke conventies zijn. Met als gevolg dat de gebruiker gefrustreerd raakt, omdat de gezochte informatie niet te vinden is, pagina's ongeorganizeerd zijn, verwarrende informatie wordt aangeboden, pagina's zich nog in een ontwerpfase bevinden, koppelingen nergens heen gaan, er geen duidelijkheid is over navigatie binnen het systeem en allerhande andere problemen. Binnen de conventies moet er zo veel mogelijk een overeenkomst gevonden worden tussen het systeem en de echte wereld. Naamgevingen, codes en procedures moeten overeen komen en in een natuurlijke en logische volgorde verlopen zoals dat ook in de echte wereld het geval is.

Gebruiksvriendelijkheid, snelheid en eenvoud

De drie punten die genoemd worden in de hoofdvraag. Wat maakt een interface gebruiksvriendelijk, snel en eenvoudig. Deze drie punten hebben heel veel overlap. Onder gebruiksvriendelijkheid verstaan wij dat de gebruiker krijgt wat hij wil en wat wat de gebruiker wil eenvoudig en effectief gedaan kan worden. Hiervoor moet een dialoog aangegaan worden met de gebruiker over de verwachtingen van het systeem. Doordat het ontwerp eenvoudig wordt gehouden kan de first time user er vanaf het begin mee overweg. Eenvoud dient dan wel hand in hand te gaan met intuitief ontwerp. Een eenvoudig ontwerp laadt snel en door het intuitieve ontwerp werkt het snel.

Gebruiksvriendelijkheid, snelheid en eenvoud bereik je door een eenvoudig, intuitief ontwerp. Door deze twee punten werkt het systeem vanzelf snel. Om te weten hoe een systeem intuitief gemaakt kan worden moet je in dialoog gaan met de gebruikers om voldoende gebruikerskennis op te doen. Alleen dan kun je slagen in het ontwerpen van een systeem dat volledig aansluit bij de gebruiker.


Resultaten uit het focusgesprek

Gebruikte faciliteiten, op- en aanmerkingen

Blackboard

Een redelijk bruikbare omgeving waar verder niet veel aan gedaan kan worden binnen dit project. Wat wel prettig zou zijn is als de nieuwe studentenportaal de announcements die via blackboard worden gegenereerd door geeft naar een aparte app op de portaal. Hierbij wel de mogelijkheid om in te stellen hoe oud een announcement maximaal mag zijn wil deze op de portaal zichtbaar blijven.

Portaal wens: Een app die de announcements weergeeft

KISS/TIS

Een van de studenten heeft er een shell voor ontworpen (Kizz). Een groot probleem hierbij is dat je password onversleuteld wordt verzonden naar kiss. Dit is voor de ondervraagden reden genoeg om het niet te gebruiken. Het zoeken naar de juiste vakken om je in te schrijven kan makkelijker. Zoeken op opleiding (voor verplichte vakken binnen het curriculum) is wenselijk. Zo is er nu niet de mogelijkheid om rechtstreeks de vakken te vinden onder de noemer "Informatica propodeuse". Het toevoegen van een dergelijke structuur waarbij ook pakketten te vinden zijn van de standaard-minoren moet zoeken eenvoudiger maken.

De interface van TIS is "web 1.0" waarbij als je het scherm klein genoeg maakt de menuitems verdeeld worden over meerdere regeld. Zo krijg je Raadplegen/n afmelden/n tentamens/n te zien. Dat alledrie deze items bij mekaar één menuoptie vormen is onduidelijk. TIS geeft in de kern twee mogelijkheden: Aanmelden en Raadplegen/uitschrijven. Een app voor de portaal zou deze twee opties kunnen geven, samen met een overzichtje van de vakken waarop je op dit moment bent ingeschreven en een kolom daarachter met de huidige resultaten. Meer informatie is niet nodig.

Wat op dit moment mist bij TIS is een duidelijk overzicht van de stand van zaken. Het menu is te onduidelijk vormgegeven. De site is puur functioneel maar weinig intuitief. De functionaliteit en overzichtelijkheid die KIZZ biedt wordt geheel teniet gedaan door de onveilige verzending van wachtwoorden dat niet iets is dat je onbeveiligd door wilt sturen.

Portal wens: Een simpele manier om in te schrijven, uit te schrijven en een overzicht te hebben.

Ru mail (Share)

Voor de mensen die deze interface willen gebruiken is hij gewoon goed. Hij wordt ook wel "werkbaar" genoemd. Zoals ook bij iGoogle de mogelijkheid bestaat is het wenselijk om een app te hebben waarbij je de laatste mails kunt zien. (Met een zelf te kiezen tijdsinterval en aantal). De focusgroepleden gebruiken echter allemaal een eigen mail client en komen dus zelden op de ru mail pagina.

Portal wens: Een overzichtje van de laatste paar mails.

De Rooster generator

Hiervoor gebruiken bijna alle focusgroepleden ruuster omdat die een aantal mogelijkheden biedt die de rooster site van de RU niet heeft. De belangrijkste hierbij is de synchronisatie met google calender of iCal. Het enige lid die ruuste rniet gebruikt doet dit niet omdat hij geen digitale agenda gebruikt en de tijd nooit heeft genomen om alle vakken bij ruuster in te voeren.

Portaal wens: Een overzichtje van het rooster voor deze week/dag. Vak en lokaalnummer zijn voldoende.

Verdere opmerkingen

Er is de mogelijkheid tot een 6-tal apps op het scherm zoals we terug kunnen zien in figuur 2. Dit is een gebruikelijke indeling die je bij iGoogle terug ziet. De focusgroepleden geven ook aan dat het handig zou zijn als de diverse apps voor de studentenportaal ook gewoon bij iGoogle in te pluggen zijn zodat ze (aangezien ze iGoogle gebruiken) maar één scherm hebben voor al hun zaken.

Portaal wens: apps ook in iGoogle te gebruiken

References

  1. ↑ Hansen WJ. (1971). User engineering principles for interactive systems. Proc. Fall Joint Computer Conference 36 (pp. 523-532), New York: AFPIS Press
  2. ↑ Shneiderman B. (1992) Designing the user interface, strategies for effective Human-Computer Interaction. Massachusetts: Addison-Wesley Publishing Company
  3. ↑ Vora P. (1998) Human Factors in Methodology for Designing Web Sites. In Forsythe C, Grose E, Rather J. Human Factors and Web Development (pp. 153 - 172). New Jersey: Lawrence Erlbaum Associates
  4. ↑ Robbins JN. (2007) Learning Web Design. Sebastepol California: O'Reilly Media Inc.
  5. ↑ http://www.thecounter.com/stats/2009/March/res.php Resolution Stats Fri Feb 1 2008 - Tue Mar 31 2009 425.0 Days
  6. ↑ Bernard M. (2001) Developing schemas for the location of common web objects. Usability News 3(1) http://bit.ly/an7zOL
  7. ↑ Shaikh AD, Lenz K. (2006) Where's the Search? Re-examining User Expectations of Web Objects. Usability News 8(1) http://bit.ly/aafMJB
  8. ↑ Nielsen J. (2006) F-Shaped pattern for reading web content http://bit.ly/18Zl1I
  9. ↑ Shrestha S, Lenz K. (2007) Eye gaze patterns while searching vs. browsing a websit. Usability News 9(1) http://bit.ly/cjTlQO
  10. ↑ Shrestha S, Owens JW. (2008) Eye Movement Patterns on Single and Dual-Column Web Pages Usability News 10(1) http://bit.ly/19lFM
  11. ↑ Owens JW, Shrestha S (2010) Does Coor Impact How Users View a Portal Web Page? Usability News 12(1) http://bit.ly/a4vIBg
  12. ↑ Gose E, Forsythe C, Ratner J. (1998) Using Web and traditional style guides to design web interfaces. In Forsythe C, Grose E, Rather J. Human Factors and Web Development (pp. 121-136). New Jersey: Lawrence Erlbaum Associates
Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Research_and_Development_1/%5EArchief/2009-2010/03/Theoretisch_kader&oldid=131996"