tiistai 28. kesäkuuta 2011

Käyttäjävaatimukset, käyttäjätarpeet, käyttäjätoiveet - mikä ero?

On tärkeää ymmärtää, mitä eri termeillä tarkoitetaan. Otsikossa mainitut termit eivät suinkaan tarkoita samoja asioita. Kirjottelen asiasta Käytettävyysnavigoija-blogissa:
http://kaytettavyysnavigoija.blogspot.com/2011/06/kayttajatarpeet-toiveet-ja-vaatimukset.html

--------------
Tämä on sitten viimeinen kirjoitus ennen kesälomia. Palataan asiaan elokuun alussa!

torstai 23. kesäkuuta 2011

Kokemuksia ulkopuolisen tekemästä käytettävyysarvioinnista

Kirjoitin Hanki käytettävyyttä! -blogiin yhden erityisen positiivisen kokemuksen tekemästäni käytettävyysarvioinnista. http://hankikaytettavyytta.blogspot.com/2011/06/ulkopuolinen-kaytettavyysarvioija-ei.html

Kyseessä oli ison julkisen organisaation verkkosivujen arviointi.  Vaikka kyseessä ei ole mobiili sovellus, niin arviointiperiaatteet ja -käytännöt ovat yleisiä ja siten myös sovellettavissa mobiilimaailmaan.

Yksi mielenkiintoinen havainto oli se, että sivujen suunnittelijat (= "käyttöliittymäsuunnittelijat") olivat olleet varsin yksinäisiä  suunnittelutyössään. Eli kollegat ja muut eivät olleet ehtineet paneutua asiaan ja sen vuoksi ulkopuolinen tuki koettiin arvokkaana.

Ja tulee mieleen: missä määrin tuotteiden käyttöliittymien suunnittelijat kokevat vastaavan tyyppistä "yksinäisyyttä"? Osaisiko joku kommentoida?

maanantai 20. kesäkuuta 2011

Mitä ovat käytettävyysvaatimukset?

Käytettävyysvaatimusten määrityksen olisi oltava käytettävyysohjatun vuorovaikutussuunnittelun keskeinen toimenpide. Käytettävyysvaatimukset määrittävät tavoitteet kehitettävän sovelluksen käytettävyydelle: kuinka hyvää käytettävyyttä tavoitellaan.

Ks. Käytettävyysnavigoija-blogi: http://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html

tiistai 14. kesäkuuta 2011

"Käytettävyysvaikuttavuus"

"Käytettävyysvaikuttavuus" kuullostaa ehkä oudolta ja epäelegantilta käsitteeltä. Kuitenkin se tarkoittaa keskeisiä perusteita käytettävyyssuunnittelulle (niin mobiilille kuin muullekin).

Tästä on kirjoitus Käytettävyysnavigoija-blogissa: http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

perjantai 10. kesäkuuta 2011

Mobiilin käyttöliittymän suunnitteluprosesseista

Tässä blogissa on kirjoitettu toistaiseksi lähinnä mobiilien laitteiden suunnitteluohjeista. Kuitenkin käytettävyyssuunnittelu prosessina on periaattessa samanlaista, on kyseessä sitten mobiili laite tai normaalinäyttöinen tietokone.

Yleisen käytettävyyssuunnittelun prosessi on kuvattu standardissa ISO 9241-210 ("ihmiskeskeinen suunnittelu). Kirjassani Navigoi oikein käytettävyyden vesillä (www.kaytettavyyskirja.net) olen tulkinnut ja vähän laajentanutkin ko. standardin esittämää mallia.

Vaikka kirja on aika uusi, niin ajatukset täsmentyvät koko ajan (toivottavasti oikeaan suuntaan). Ja kirjoitan uusiksi näitä täsmennyksiä. Silloin kun nämä asiat ovat yleisiä, ei mobiilimaailmaan rajoittuvia (mutta siis myös mobiilimaailmaan päteviä), niin kirjoitan niitä Käytettävyysnavigoija-blogiin. Laitan tähän blogiin sitten linkkejä, kun teen kirjoituksia sinne.

Ja ensimmäinen linkki: http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

tiistai 7. kesäkuuta 2011

Joskus kirjoittaminen on parempi ratkaisu kuin valinnat

Yleensä mobiililaitteilla on suositeltavaa käyttää valintoja, mutta joissakin tapauksissa kirjoittaminen on tehokkaampi ratkaisu

Tekstin kirjoittamista tarvitaan usein, mutta mobiililaitteella se on hidasta, varsinkin ilman näppäimistöä. Tämän vuoksi aina kun se on mahdollista, mobiililaitteilla tulisi käyttää valintaa kirjoittamisen sijaan.

Poikkeuksena tästä säännöstä ovat tapaukset, jossa valintojen määrä on kovin suuri, kuten vaikkapa pörssikursseissa kirjoittaminen voi olla valintaa kätevämpää. Esimerkiksi ’IBM’:n nimen kirjoittaminen on helpompaa käyttäjälle kuin valinta: ensin sopiva teollisuuden ala, sen jälkeen kirjoittaa ’I’, sen jälkeen tehdä valinta vierittämällä ruutua oikean yrityksen kohdalle. Käyttöliittymässä, joka luottaa pääasiassa valintaan kirjoittamisen sijaan on myös se hankaluus, että tieto voidaan järjestää monella eri tavalla ja käyttäjillä saattaa olla omat näkemyksensä tiedon organisointiin.

Weissin kokemuksen mukaan valintojen määrä pitäisi olla karkeasti ottaen alle 20, jotta niiden käyttäminen kirjoittamisen sijaan on kannattavaa. Erityisesti, kun valinnat voidaan jakaa osakategorioihin, kuten esimerkiksi kaupungit eri alueisiin maiden sisällä, on tekstin syöttö ön paremmin soveltuva ratkaisu kuin valinta.

"Suosi valintaa kirjoittamisen sijaan" -ohjetta ei tulekaan ottaa täysin kirjaimellisesti, kunhan muistetaan, että käyttäjillä on omat ongelmansa tiedon syöttämisessä ja se otetaan huomioon suunnittelussa.

Lähde: Weiss, Scott: Handheld Usability (2002). John Wiley & Sons

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