perjantai 3. kesäkuuta 2011

Suunnittelusuosituksia Internet-palveluille

Viisi suositusta suunniteltaessa Internet-palvelujen käyttöliittymiä: 1. sisällön optimointi, 2. tietokoneen ja kännykän käyttötavat, 3. kännykän kykyjen laaja hyödyntäminen, 4. kännykän resurssien kompensointi ja 5. sisällön päivitys. Mobiili erillissovellus voi tarjota paremman käyttökokemuksen kuin mobiili selain. 


Vartiainen (2009) on kerännyt väitöskirjassaan Suunnittelusuosituksia Internet-palvelujen kännykkäkäyttöliittymille yhteensä viisi eri näkökulmaa, jotka pitäisi ottaa huomioon suunniteltaessa Internet-palvelujen käyttöliittymiä. Nämä suositukset ovat:
  1. Sisällön optimointi. Mobiilissa web-selaimessa webin sisältö pitäisi optimoida vastaamaan mobiililaitteen näytön tulostuskykyä. Vähintäänkin selaimella tulisi olla visualisointimenetelmä, joka muuntaa sisällön pienelle näytölle soveltuvaksi. Erillissovellus (mobiili client-sovellus) voi optimoida käyttöliittymän sisällön tietyn Internet palvelun tarpeisiin.
  2. Tietokoneen ja kännykän käyttötavat. Mobiilin web-selaimen pitäisi hyödyntää tuttujen pöytätietokoneiden käyttötapoja, mutta sen lisäksi tuoda uusia ratkaisuja mobiilia käyttöä varten. Erillissovellus voi olla suunniteltu erityisesti tietylle mobiililaitteelle ja mobiilikäyttöön.
  3. Kännykän kykyjen laaja hyödyntäminen. Mobiilin web-selaimen käyttöliittymän pitäisi tarjota miellyttävä käyttäjäkokemus hyvän navigointinäppäimen, pienen näytön ja yhdenmukaisen vuorovaikutuksen kautta. Erillissovellus voi hyödyntää käyttöliittymän ominaisuuksia, joita laitteella on käytössä, sisältäen parannetun grafiikan ja välittömän palautteen.
  4. Kännykän resurssien kompensointi. Mobiilin web-selaimen pitäisi tuottaa erikoislaatuisia käyttöliittymäratkaisuja korvaukseksi rajoitetuista mobiililaitteen resursseista. Mobiililla erillissovelluksella on mahdollisuus täysin hyödyntää laitteen ominaisuuksia, joilla piilottaa tekniset yksityiskohdat käyttäjältä, tarjota mielekkäitä oletusarvoja, automatisoida toimintoja ja mahdollistaa yhteydetön käyttö.
  5. Sisällön päivitys. Web-selain tarjoaa Internetin sisällön manuaalisen päivittämisen sekä automaattisen lataamisen. Sen pitäisi optimoida päivittäminen tavalla, joka on hyödyllinen käyttäjälle. Erillissovellus voi olla täysin integroitunut vastaavaan Internet-palveluun: se voi tarjota pääsyn ajan tasalla olevaan sisältöön ilman manuaalista päivitystä. (Vartiainen, 2009).
Vartiainen on lisäksi verrannut toisiinsa mobiilien erillissovellusten ja web-selaimen tyypillisiä eroja niiden ominaisuuksissa, koska mobiilit Internet-palvelut on mahdollista toteuttaa näillä kahdella eri tavalla. Mobiili web-selain on pääasiallinen tapa toteuttaa palvelut ja se voi yleensä tukea useita erityyppisiä Internet-palveluita, kuten pc-tietokone. Se ei ole kuitenkaan optimoitu erityisesti jollekin palvelulle, eikä siksi voi tarjota optimaalista käyttökokemusta millekään tietylle palvelulle. 

Mobiili erillissovellus taas on täysin integroitu vastaavaan Internet-palveluun ja se pystyy hyödyntämään alustan mahdollisuuksia ja optimoimaan käyttöliittymän palvelun tarpeita vastaavaksi. Siten sillä on edellytykset tarjota käyttäjälle parempi käyttökokemus kuin mobiililla web-selaimella. Toisaalta mobiilin erillissovelluksen kehittäminen voi olla työlästä sekä toteuttamiskelvotonta kaikille alustoille. 



Lähteet: Vartiainen, E., (2009). Design Implications for Mobile User Interfaces of Internet Services. Doctoral Dissertation Helsinki University of Technology, Faculty of Information and Natural Sciences, Department of Media Technology. Saatavilla: http://lib.tkk.fi/Diss/2009/isbn9789522481429/isbn9789522481429.pdf

keskiviikko 1. kesäkuuta 2011

Suunnitteluohjeita mobiililaitteiden web-lomakkeille

Suunnittele erilaiset lomakkeet mobiilinäyttöön kuin isolle näytölle. Esimerkiksi otsikot kenttien yläpuolelle, erilaiset haut samaan kenttään, yleensä yksinkertaista lomakkeet. 


Mobiililaitteissa tarvitaan myös lomakkeita, niitä käytetään esimerkiksi erilaisten asiakasrekisteröintien ja varausten teon yhteydessä. Chui Chui Tan (2011) pureutuu aiheeseen artikkelissaan “Forms that work: Designing web forms for usability” (http://www.formsthatwork.com/Mobile-forms).

Tan mukaan web-lomakkeet, jotka toimivat hyvin tietokoneilla, eivät välttämättä sovi mobiililaitteille. Tan (2011) esittää strategioita, joiden avulla voi suunnitella tehokkaampia ja vähemmän virheille alttiita web-lomakkeita mobiililaitteille. Kirjoittajan mukaan tietokoneiden web-lomakkeita ei ole suunniteltu tehokkaiksi, mikä on tärkeää lomakkeissa mobiililaitteissa käytettäessä. Lisäksi mobiililaitteissa webyhteys on rajoitetumpi, johtuen 1. käyttäjän käyttöympäristöstä 2. hitaammasta/epäluotettavasta verkosta ja 3. itse laitteesta, jossa on pienempi näyttö.

Www-lomake mobiililaitteeseen voi olla: 1. yksinkertaistettu versio pöytätietokoneen weblomakkeesta (ei mainoksia, kuvia, tai muita häiritseviä tekijöitä) 2. Kokonaan eri versio, jossa on yksinkertaisempi ja selkeämpi käyttöliittymä, tai 3. samat lomakekentät kuin web versiossa, mutta pienillä muutoksilla layoutissa ja kenttien otsikoiden asettelussa.
Tan antaa yhteensä kahdeksan eri suunnitteluohjetta mobiililaitteiden web-lomakkeille.
  1. Sijoita kenttien otsikot kenttien yläpuolelle. Vältä asettamasta otsikoita kentän vasemmalle tai oikealle puolelle, koska horisontaalisten otsikoiden näyttäminen samalla ruudulla on monesti mahdotonta, varsinkin pidemmät otsikot voivat olla ongelma.
  2. Mobiililomakkeiden tulee olla niin yksinkertaisia ja suoraviivaisia kuin mahdollista. Tarpeettomien elementtien ja ominaisuuksien poisjättäminen helpottaa käyttäjää fokusoitumaan tehtävään ilman turhia häiriöitä tai ei-tarpeellisia kenttien täyttämistä. Yksi tekniikka on poistaa valinnaiset ja vähemmän tärkeät -kentät. Toinen tapa on poistaa elementit, joilla ei ole ensisijaista käyttöä, kuten vihjeet, kuvaukset ja linkit. Se vähentää visuaalista epäjärjestystä ja yksinkertaistaa käyttäjäkokemusta. Näytä ainoastaan sellaiset kentät, joiden ehdottomasti välttämättömiä prosessin ja tehtävän täyttämiseksi. Karkeana ohjeena voi pitää sitä, että jos kentän syötteellä ei ole merkitystä lopputulokseen, sen voi poistaa.
  3. Toinen tapa yksinkertaistaa mobiililomaketta on yhdistää useammat samantyyppiset syöttökentät yhteen kenttään. Esimerkiksi eri etsintäkentät voidaan yhdistää samaan kenttään. Esimerkkinä kirjoittaja antaa Mapquestin hakutoiminnon (http://classic.mapquest.com/), jossa käyttäjä on voinut hakea ajo-ohjeita kahden eri paikan välillä kolmella eri tavalla. 1. Yrityksen nimellä, 2. osoitteella, tai 3. tallennetuista, tai edellisistä sijainneista. Palvelu yhdistää eri haut yhteen kenttään. Käyttäjä voi kirjoittaa vapaasti joko tietyn osoitteen tai yrityksen nimen kenttään ja kun kenttä on valittuna, käyttäjän nykyinen sijainti on oletusarvona. Käyttäjälle jää näin samat valinnan mahdollisuudet kuin useammalla kentällä, mutta lomake on yksinkertaisempi, eikä käyttäjää kuormiteta eri vaihtoehtojen miettimisellä.
  4. Mobiililaitteissa on monia sisäänrakennettuja ominaisuuksia, joita kannattaa hyödyntää lomakkeiden yksinkertaistamiseksi. Tällaisia ominaisuuksia on muun muassa sijainnin tunnistin, GPS:n tai satelliittien välityksellä. Esimerkkinä Europcar, jonka mobiililomakkeessa ehdotetaan käyttäjälle, että laite etsii käyttäjän sijainnin perusteella lähimmän noutopaikan. Lisäksi mobiililomakkeen valikossa 139 eri maa vaihtoehtoa on rajattu 40 yleisimpään.
  5. Hitaiden internet yhteyksien takia mobiililaitteissa suositellaan käyttämään yleensä minimimäärää sivun latauksia. Tätä sääntöä voidaan rikkoa syöttämisvalintojen parantamiseksi. Esimerkkinä AirAsian lentojen varaus, jossa tietokoneella käytettävässä versiossa kaikki 80 kaupunkia 25:ssä eri maassa, on näkyvissä yhdellä valinnalla, mutta mobiililaitteen lomakkeella ne on jaettu useille eri sivuille (maan mukaan), koska noin pitkä alasvetovalikko ei toimi mobiililomakkeella. Pitkän lomakkeen jakamisessa useisiin osiin täytyy kuitenkin olla varovainen; tehtävän suoritus ei saisi venyä käyttäjälle loputtoman pitkäksi. Koska tapa vaatii useita sivunlatauksia, kaikkien turhien elementtien poistaminen sivuilta on erityisen tärkeää.
  6. Käytä sopivia syöttö elementtejä ja valikon kontrolleja. Mobiililomakkeiden suunnittelussa voi muuttaa kontrollien tyyppiä toiseksi, mikä saattaa yksinkertaistaa lomaketta ja sen vuorovaikutusta käyttäjän kanssa. Esimerkkinä tästä kirjoittaja käyttää Expedian hotellin varauslomaketta, jossa alasvetolistan kolme valintaa on korvattu erillisillä hyperlinkeillä. Suurta määrää linkkejä ei kuitenkaan kannata käyttää sivun alussa, koska vaarana on, että itse lomake jää pois näytöltä. Toisena esimerkkinä kontrollien vaihtamisesta Tan (2011) käyttää Shangri La hotellin varauslomaketta, jossa radiopainikkeiden luettelo on vaihdettu lyhyeen alasvetovalikkoon, jolloin lomaketta on saatu yksinkertaisemmaksi.
Mobiilikäyttäjien tarvitsee monesti täyttää vain osa lomakkeesta. Aseta etusijalle pakolliset kentät ja sisällöt ja vältä valinnaisten tai vain joidenkin käyttäjien tarvitsemien kenttien painottamista. KLM:n lentojen seuranta on toteutettu mobiililomakkeella siten, että 151 eri lentokenttää sisältävä alasvetolista on korvattu ennustavalla tekstinsyöttökentällä, johon käyttäjä voi syöttää joko lennon numeron tai lentokentän nimen. Tekstin syöttäminen toimii tässä tapauksessa hyvin, koska käyttäjä tietää aina, mitä lentokenttää etsii.

  1. Valitse soveltuva listatyyppi. Listan valinnat on mahdollista toteuttaa kahdella eri tavalla, joko lukitulla alasvetovalikolla (aakkosjärjestyksessä tai satunnaisessa järjestyksessä), tai avoimella ennustavalla tekstihaulla, joista molemmilla on omat hyvät ja huonot puolensa.
Lukittu alasvetovalikko soveltuu tapauksiin, joissa käyttäjä tietää tarkasti mitä etsii, tai sellaisiin tapauksiin, joissa aakkos- tai kronologinen järjestys on luonnollinen, kuten maiden, numeroiden, tai päivämäärien kanssa. Lukittu alasvetovalikko ei sovellu sellaisiin tilanteisiin, joissa valinnat ovat satunnaisessa järjestyksessä, tai käyttäjä ei tarkasti tiedä, mitä valinnat ovat. Näiden lisäksi lukittu alasvetovalikko ei sovellu tilanteisiin, joissa eri vaihtoehdoilla on pitkät kuvaukset, koska kuvaustekstit todennäköisesti katkaistaan automaattisesti.

Avoin ennustava tekstin haku soveltuu tapauksiin, joissa eri vaihtoehdoilla on pitkät kuvaukset, jotka voivat jatkua usealle riville. Jos lista on kovin pitkä, eikä alasvetovalikko sovellu, tai ole järkevästi ryhmiteltävissä tiettyyn järjestykseen, avoin ennustava haku voi olla parempi valinta. Avoin ennustavat haku soveltuu tapauksiin, joissa käyttäjä tietää mitä etsii, ainakin sen verran, että osaa näppäillä muutaman kirjaimen tekstikenttään.

Avointa tekstin hakua käytettäessä kannattaa muistaa, että ennustavan haun listan ei pitäisi olla liian pitkä. Käyttäjä vierittää listaa läpikäydessään alaspäin ja jos hän ei löydä etsimäänsä, hänen täytyy vierittää takaisin ylöspäin tekstikenttään syöttääkseen uudet hakusanat. Pitkän listan läpikäyminen on aikaa vievää ja suuritöistä.

  1. Aseta mielekkäät oletusarvot. Tarjoa käyttäjälle mahdollisuuksien mukaan joitakin oletusarvoja sopiviin kohtiin lomakkeilla. Kaikilla lomakkeilla on omat käyttötapauksensa, esimerkiksi junan aikataulujen etsintä lomakkeella käyttäjä todennäköisesti tahtoo etsiä aikatauluja junille, jotka lähtevät samana päivänä alkaen nykyisestä kellon ajasta. Siksi, on järkevää asettaa lähtöajaksi nykyinen päivä ja seuraava lähtevä juna oletusarvoiksi. Mielekkäät oletusarvot ovat minimalistisen suunnittelun perusta.

Yhteenvetona mobiililomakkeiden suunnittelusta Tan (2009) teroittaa: Ensinnäkin, suunnittelijan pitää ymmärtää milloin ja miksi käyttäjät käyttävät mobiililomaketta. Toiseksi pitää tunnistaa lomakkeen ensisijaisen tehtävän sisältö ja/tai kentät. Sen jälkeen on sovellettava edellä mainittuja strategioita parhaan vuorovaikutuksen saavuttamiseksi. Kannattaa muistaa, että ensisijaisena tavoitteena käyttäjällä on saada tehtävänsä suoritettua tehokkaasti ja vaivattomasti.

Lähteet: Tan, C., C., (2011). Forms that work: Designing web forms for usability. Saatavilla: http://www.formsthatwork.com/Mobile-forms

tiistai 31. toukokuuta 2011

Kontrastit ja värit

Kontrasti tulisi olla riittävä. Värejä ei tulisi koskaan käyttää ainoana koodaustapana. 

Pienten näyttöjen käyttöliittymistä on tullut ubiikki osa nykypäivän yhteiskuntaa. Pieniä näyttöjä löytyy aina digitaalikelloista autojen näyttöihin saakka. Näyttöjen määrästä huolimatta niiden monimutkaisuus ja käytettävyys vaihtelevat runsaasti eri toteutuksissa. Pienten näyttöjen kehittymisessä on nähtävissä useita eri trendejä, laitteiden koko on pienentynyt, laskentateho on lisääntynyt, ohjelmistojen ja käyttöliittymien kompleksisuus on kasvanut ja ominaisuuksien lähentyminen on parantunut. (Mauney, Masterton, 2008).

Pienten näyttöjen suunnittelu perustuu pääasiassa näköaistiin. Suunnittelussa yleisiä ovat kysymykset siitä, kuinka pieniä dataelementtejä voidaan laittaa näytölle, että ne voidaan vielä kunnolla nähdä ja tunnistaa. Tähän seikkaan vaikuttavat valon määrä, silmän anatomia ja herkkyys, sekä tarkkuus. (Mauney, Masterton, 2008).

Visuaalinen tarkkuus tarkoittaa pienintä yksityiskohtaa, jonka silmä voi havaita tietyltä etäisyydeltä. Kohteen visuaalinen terävyys riippuu sen koosta ja sen etäisyydestä katsojaan. Pieni lähellä oleva objekti voi näyttää suuremmalta kuin kauempana oleva suurempi esine. (Mauney, Masterton, 2008).

Monet asiat vaikuttavat tarkkuuteen, kuten valaistus, kontrasti, aika, ja aallonpituus. Yleisesti ottaen, kun valoisuus ja kontrasti lisääntyvät ja aika, joka kohdetta katsotaan, pitenee, tarkkuus paranee.

Värin suurempi kontrasti parantaa tarkkuutta. Punainen väri on helpoiten nähtävissä tilanteessa, kun on vähän kontrastia, seuraavaksi helpoimpia ovat järjestyksessä vihreä, keltainen ja valkea. Noin 8 prosentilla miehistä ja 0,5 prosentilla naisista on jonkinlainen häiriö värien näkemisessä. Yleisin värisokeus on puna-vihersokeus, jolloin henkilö ei erota punaista ja vihreää väriä toisistaan. Tämän vuoksi väriä ei koskaan tulisi käyttää ensisijaisena tapana erottaa kahta eri asiaa. (Mauney, Masterton, 2008).

Lähteet:
Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

Lukeminen pieneltä näytöltä

Pienellä näytöllä kannattaa varata koko näytön leveys tekstin kirjoittamiseen. Pieneltä näytöltä ei ole yhtä helppoa ymmärtää tekstiä kuin suurelta näytöltä.

Pieneltä näytöltä lukeminen on tutkimusten mukaan hieman hitaampaa kuin suurelta näytöltä lukeminen. Kun näytöllä on vain kerrallaan luettavissa vain 1-2 riviä, suoritus on hieman huonompi kuin, jos luettavia rivejä on 4:stä 20:een. Kun näytön rivimäärä nostetaan 1:stä 20:een, lukeminen on ainoastaan 9 % nopeampaa, eikä tekstin ymmärtämisessä ole eroja. (Mauney, Masterton, 2008).

Näytön leveyden vaihtelulla on sen sijaan suurempi merkitys. 1/3 -levyisellä näytöllä lukeminen on 25% hitaampaa kuin 2/3 levyiseltä tai täysleveältä näytöltä. Tämän takia, jos näyttöä käytetään usein tekstin lukemiseen, sen leveydestä kannattaa varata tekstille mahdollisimman paljon tilaa. Tämä löydös tukee myös navigointi- ja muiden kontrollien sijoittamista vertikaalisesti näytöllä. (Mauney, Masterton, 2008).

Kokemusten mukaan käyttäjät lukevat mieluummin suurelta näytöltä ja käyttävät pientä näyttöä vain satunnaiseen lukemiseen. Monesti käyttäjät eivät lue tekstiä pieneltä näytöltä lineaarisesti, vaan enemmänkin silmäilevät sitä ja lukevat vain lyhyitä kohtia. (Mauney, Masterton, 2008).

Nielsen esittelee www-sivuillaan tutkimustuloksen, joka on ristiriidassa sen väitteen kanssa, että tekstin ymmärtämisessä ei ole eroja erikokoisten näyttöjen välillä. Ainakin monimutkaisen tekstin lukemisessa iPhonen näytön kokoiselta näytöltä, käyttäjät saivat 48% vähemmän pisteitä sisällön ymmärtämistä testattaessa kuin tietokoneen näytöltä lukevat käyttäjät. Tämä tarkoittaa, että mobiilin sisällön ymmärtäminen on kaksi kertaa hankalampaa kuin tietokoneen näytöltä. (http://www.useit.com/alertbox/mobile-content-comprehension.html, 2011).

Pieneltä näytöltä lukemisen heikon ymmärtämisen syiksi Nielsen antaa kaksi asiaa: Ensinnäkin, käyttäjät näkevät vähemmän tekstiä annetussa ajassa ja joutuvat luottamaan enemmän muistiinsa. Toiseksi, käyttäjät joutuvat liikuttelemaan ja vierittämään sivuja enemmän. Vierittäminen vie enemmän käyttäjän aikaa ja huomiota itse ongelmasta, sekä aiheuttaa ongelmia edellisen kohdan paikantamisesta sivulla.

Lukemiseen vaikuttavat näytön koon ja vierittämisen lisäksi myös muut seikat, kuten tekstin koko ja tarkkuus.

Lähteet: Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

Nielsen, J., (2011). Nielsen's Alertbox, February 28, 2011. Www-sivu, saatavilla: http://www.useit.com/alertbox/mobile-content-comprehension.html

torstai 26. toukokuuta 2011

Valikot ja niiden suunnittelu

Hierarkkisen rakenteen teossa olisi muodostettava toisensa poissulkevia kategorioita, joissa valinnat sopivat hyvin ainoastaan kyseessä olevaan ryhmään. Otsikoiden pitäisi olla selkeitä ja sisältöä kuvaavia. Käytön yleisyyttä pidetään yleensä parhaana vaihtoehtona järjestää valinnat; muita ovat ”luonnollinen” järjestys (esim. viikonpäivät) tai aakkosjärjestys (valtiot).  Syvempi hierarkia on tehokkaampi kuin laaja hierarkia.

Valikoiden avulla käyttäjä voi valita suuresta määrästä eri vaihtoehtoja. Valikoiden hyvänä puolena on, että käyttäjä voi muistamisen sijaan tunnistaa ja valita tarvittavan toiminnon kirjoittamatta, mikä on hyödyllistä erityisesti silloin, kun laitteessa ei ole täyttä näppäimistöä kirjoittamiseen. (Mauney, Masterton, 2008)

Suunnittelussa tavoitteena on, että käyttäjä löytää haluamansa valinnat nopeasti ja mahdollisimman virheettömästi minimimäärällä näppäilyjä. Useimmiten valikon virheelliset valinnat johtuvat valintojen huonosta luokittelusta, päällekkäisistä luokista tai epäselvistä luokkien otsikoista. (Mauney, Masterton, 2008).

Valikon järjestämisessä pitää tehdä valikon yleisen rakenteen organisointi ja valikon sisäisten valintojen järjestäminen. Tutkimusten mukaan paras tapa valikon järjestyksestä päättämisessä on ottaa käyttäjät mukaan suunnitteluprosessiin. Pyrkimyksenä hierarkkisen rakenteen teossa on muodostaa toisensa poissulkevia kategorioita, joissa ei ole yhteisiä ominaisuuksia ja jotka on selkeästi määritetty niin, että valinnat jokaisessa kategoriassa sopivat hyvin ainoastaan kyseessä olevaan ryhmään. Kategorioiden otsikoiden pitäisi olla selkeitä ja sisältöä kuvaavia. (Mauney, Masterton, 2008)

Valikon sisällä valinnat voidaan järjestää: aakkos- tai aikajärjestykseen, koon mukaan, yhdenmukaisesti (jos samat valinnat ovat useassa eri paikassa, niiden järjestyksen tulisi olla aina sama), kategorioihin ja käytön yleisyyden mukaan (useimmin käytetyt ylös). (Mauney, Masterton, 2008).

Käytön yleisyyttä on monesti pidetty parhaana vaihtoehtona järjestää valikon eri valinnat. Tällainen järjestys voi säästää käyttäjän aikaa ja virheellisiä valintoja, koska syvällä valikkorakenteessa olevia valintoja on usein hankala löytää. Käyttäjät yleensä valitsevat heti ensimmäisenä löytämänsä kategorian, joka voisi sisältää heidän etsimänsä valinnan, joten käytön yleisyyden mukaan lajiteltu valikko helpottaa tällaista etsintää ja myös nopeuttaa jatkuvaa käyttöä. (Mauney, Masterton, 2008)

Jos valinnoilla on jokin ”luonnollinen” järjestys kuten esimerkiksi viikonpäivät, tai kuukaudet, sitä kannattaa hyödyntää. Samoin, jos muualla ohjelmassa on samoja valintoja, niiden järjestys on hyvä pitää yhdenmukaisena. Aakkosjärjestystä hyödyttää käyttää vain, kun valintojen aakkosjärjestys on käytössä vakiintunut, kuten esimerkiksi eri maita sisältävät valinnat. (Mauney, Masterton, 2008)

Valikot voivat olla rakenteeltaan leveitä, jolloin niissä on paljon eri valintoja per kategoria, tai ne voivat olla kapeita, jolloin niissä on vain muutama valinta per kategoria. Valikot voivat olla myös syviä, jolla tarkoitetaan, että niissä on useita alikategorioiden tasoja, tai matalia, jolloin niissä on vain muutama alikategoria. Tätä valikkojen hierarkiaa on tutkittu paljon kirjallisuudessa, pöytätietokoneiden valikoista yleensä leveät hierarkiat ovat tehokkaimpia käyttäjille, erityisesti silloin, kun valinnat ovat selkeitä. Leveät hierarkiat ovat myös parhaita edistyneille käyttäjille. Kuitenkin, tilanteissa joissa virheitä esiintyy paljon, tai ne ovat tuhoisia, kapea hierarkia, joka ohjaa käyttäjiä parhaaseen valintaan voi olla paras valinta. (Mauney, Masterton, 2008)

Lisäksi on tutkittu valikkojen erilaisten muotojen vaikutusta, jolloin huomattiin, että kovera rakenne on navigoinnin kannalta tehokkaampi kuin samankokoinen suhteellisen tasainen valikko. Koveralla valikolla tarkoitetaan, että valikossa on enemmän valintoja ylä- ja alatasoilla kuin keskitasoilla. Tasaisessa valikossa on suurinpiirtein sama määrä valintoja per taso. (Mauney, Masterton, 2008; Jones, Marsden, 2005)

Suurin osa em. tutkimuksista on tehty pöytätietokoneilla, joiden näytöille sopii enemmän tietoa. Jos kaikkia valintoja ei voi näyttää kerralla yhdellä näytöllä, syvyys vs. leveys kompromissi vaihtuu toisin päin. Mauney&Masterton (2008) viittaavat tutkimukseen, jossa aihetta on selvitetty puhelimissa ja pda-laitteissa. Tutkimuksessa havaittiin, että tehokkain hierarkia mobiililaitteissa on vain neljästä kahdeksaan valintaa per taso ja jos paljon valintoja tarvitaan, on parempi kasvattaa tasojen määrää kuin valintojen määrää per hierarkia taso. Siten, syvempi hierarkia on tehokkaampi kuin laaja hierarkia monen tasoisille käyttäjille. (Mauney, Masterton, 2008)

Valikon suunnittelusäännöt Mauneyn & Mastertonin mukaan (2008)
  1. Järjestä valikon valinnat toisensa pois sulkeviin kategorioihin, jotka noudattavat tulevien käyttäjien/suurimman osan käyttäjistä hahmottamaa järjestystä.
  2. Anna valikoille selkeät otsikot, joista käy hyvin ilmi niiden sisältö.
  3. Käytä yksinkertaisia toimintaa kuvaavia verbejä kuvaamaan valintoja.
  4. Käytä päätason otsikkoa vaikka otsikkorivillä, kun alivalikon valinta on valittuna.
  5. Kun käytetään ympäri kiertävää valikkoa varmista, että käyttäjä tietää milloin valikko on kiertänyt ympäri ja palannut ensimmäiseen kohtaan. Tämän voi tehdä esimerkiksi niin, että sijoittaa ensimmäisen valikon valinnan aina näytön yläreunaan ja kun käyttäjä vierittää valikkoa alaspäin, korostettu valinta siirtyy näytöllä alaspäin ja hyppää taas ensimmäisen valinnan kohdalla näytön alareunasta yläreunaan.
  6. Helpota käyttäjien navigointia ylöspäin valikkohierarkiassa. Näin käyttäjä voi nopeasti korjata virheensä, kun hän on valinnut väärän kategorian.
  7. Tarjoa käyttäjälle tapa poistua valikosta ilman valinnan tekemistä. Siten käyttäjä voi poistua huomatessaan, että hänen etsimäänsä valintaa ei ole valikossa.
Lähteet: Jones, M., Marsden G., (2005) Mobile Interaction Design. John Wiley & Sons, Ltd.
Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

tiistai 24. toukokuuta 2011

Vähennä käyttäjän työskentelyä

Monimutkaisten tehtävien suorittamista varten wizardit eli velhot ovat tehokas tapa. Moniajoa pitäisi pääasiallisesti käyttää järjestelmän, ei käyttäjän. Esimerkkinä tehokkasta kontaktien hausta kontakteista suodattuu kaikki nimet, joissa näppäimistöltä annettu kirjain on ensimmäisenä joko etu- tai sukunimessä. 

Mauney ja Masterton (2008) antavat kirjassa HCI Beyond the GUI – Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces suunnittelusääntöjä mobiililaitteille. Kirjoittajat jakavat suunnitteluohjeet viiteen eri osioon, joista seuraavaksi on esitetty tiivistetysti viides osuus, eli käyttäjän työskentelyn vähentäminen.

Käyttäjän psyykkisen sekä fyysisen työskentelyn määrä käyttäjävuorovaikutuksessa käyttöliittymän kanssa täytyy pitää mahdollisimman vähäisenä. Sen sijaan, että pakotettaisiin käyttäjä tekemään ylimääräistä työtä, hyvä suunnittelu tekee käyttäjän tehtävistä vaivattomia.

Monimutkaisten tehtävien suorittamista varten wizardien eli velhojen käyttäminen on tehokas tapa. Wizard ohjaa käyttäjän läpi asteittain etenevien osatehtävien ja vähentää näin käyttäjän muistikuormaa. Hyvin suunniteltu wizard antaa käyttäjän liikkua eteenpäin ja taaksepäin eri askeleiden välillä ja pitää käyttäjän jatkuvasti tietoisena siitä, missä vaiheessa prosessia ollaan menossa. Wizardien suunnittelussa pienille näytöille keskeistä on eliminoida mahdollisimman monta syöttökenttää käyttäjältä, teettämällä mahdollisimman paljon työstä ohjelmalla. Esimerkiksi osoitteen syöttämisessä, ohjelma voi täyttää kaupungin ja maan tiedot automaattisesti, kun käyttäjältä on ensin kysytty postinumero. (Mauney, Masterton, 2008)

Monet mobiilit käyttöjärjestelmät tukevat moniajoa. Moniajo on ohjelmistokehityksessä todellisessa kasvussa ja sen käytössä on oltava huolellinen käyttöliittymän toteutuksessa. Koska mobiililaitteen käyttäjän huomio kohdistuu vain rajallisesti laitteeseen ja hänellä on todennäköisesti tavoitteena suorittaa yksi tehtävä mahdollisimman nopeasti, käyttäjää ei pitäisi pakottaa ”tekemään moniajoa” tehtävän suorittamiseksi. Moniajo on tehokas apukeino, mutta pääasiallisesti sitä pitäisi käyttää järjestelmän, ei käyttäjän. Esimerkiksi, sellaiset järjestelmän tehtävät, joiden suoritus ei tapahdu sopivaan aikaan, voidaan suorittaa taustalla ilman, että se häiritsee käyttäjän laitteen käyttämistä. (Mauney, Masterton, 2008)

Yksi esimerkki tehokkaasta ja samalla yksinkertaisesta suunnittelusta on Nokian S60 sarjan kontaktien selaaminen. Käyttäjä voi vierittää aakkosjärjestyksessä olevia kontakteja pystysuunnassa, mutta jos kontakteja on paljon, vierittämisen sijaan käyttäjä voi syöttää haluamansa kirjaimen näppäimistöltä. Tämän jälkeen kontakteista suodattuu kaikki nimet, joissa näppäimistöltä annettu kirjain on ensimmäisenä joko etu- tai sukunimessä. Tekniikka on yllättävän tehokas ja helposti käyttäjän opittavissa. (Mauney, Masterton, 2008)

Lähteet: Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

Noudata standardeja

Käyttöliittymän suunnittelussa olisi noudatettava käyttöjärjestelmän suunnittelustandardeja, samoin kuin yleisesti käytössä olevia metaforeja.  

Mauney ja Masterton (2008) antavat kirjassa HCI Beyond the GUI – Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces suunnittelusääntöjä mobiililaitteille. Kirjoittajat jakavat suunnitteluohjeet viiteen eri osioon, joista seuraavaksi on esitetty tiivistetysti neljäs osuus, eli standardien ja metaforien käyttäminen.

Suunnittelun lähtökohtana toimivat olemassa olevat standardit. Monilla kehittyneimmillä pieninäyttöisillä laitteilla, kuten Windows Mobile alustalla, on yksityiskohtaiset käyttöliittymän ohjeistukset, joilla varmistetaan yhdenmukaisuus kaikissa alustalle tehdyissä sovelluksissa. On tärkeää tutustua laitteen standardeihin, jotka koskevat esitystapaa, komponentteja (widget) ja vuorovaikutusta, ennen suunnittelun aloittamista. Näiden käyttöliittymän perusrakennuspalikoiden unohtaminen voi johtaa huomattavaan korjaustarpeeseen, jos käyttäjätestaus paljastaa ongelmia epästandardissa suunnittelussa. Visuaalisen suunnittelun standardeja tulisi rikkoa vain erityistapauksissa, kuten jos olemassa olevat puitteet eivät tue tehtävää. (Mauney, Masterton, 2008)

Oikean maailman metaforat, jotka siirtyvät hyvin ohjelmistomaailmaan, ovat yksi tehokkaimmista käyttöliittymä paradigmoista. Esimerkiksi play, pause, track forward ja track back –painikkeet ovat kaikissa digitaalisissa musiikkisoittimissa ja ovat olleet käytössä nauhasoittimista lähtien. Hyvin ymmärrettyjen metaforien rikkomisessa on omat vaaransa, koska suunnittelijalla ei ole mitään takeita siitä, että uusi käyttöliittymä toimii tehokkaasti ennen käytettävyystestien tekemistä. Sama sääntö koskee muidenkin olemassa olevien ja vakiintuneiden kontrollien, kuten valintaruutujen tai radiopainikkeiden, muokkaamista. (Mauney, Masterton, 2008)

Lähteet: Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.