Archive for the ‘terminologia’ Category

Kuinka nappien vähentäminen lisää monimutkaisuutta

Tuesday, November 24th, 2009

[Tämä teksti on julkaistu alun perin työblogissani, mutta sopii varmasti tännekin.]

Applen laitteita yksinkertaisiksi kehuvat muistavat mainita yhdeksi syyksi sen, että nappuloita on vähän. Googlekin saa kehuja: siinä on vain yksi luukku ja hakunappi. “Voisiko meidänkin tuotteemme olla niin kuin Google”, jotkut suunnittelijat tuskailevat pomojensa vaatimuksia. Asia ei ole noin yksinkertainen.

Nappien ja valintojen poistaminen on triviaalia. Karsimisen tekeminen niin, että aiotut tehtävät saa suoritettua jouhevasti, on haastavaa.

Kuka tahansa pienellä näytöllä ja parilla painikkeella varustettuja piippaavia laitteita säätänyt tietää tämän. Laite voi olla digitaalikello, askelmittari tai polkupyörän nopeusmittari. Yhteistä näille on, että ne näyttävät yksinkertaisilta vähine nappeineen, mutta todellisuus on tuskainen. Lukuja saa nylkyttää eteenpäin painallus kerrallaan ja jos innostuu painamaan kerran liikaa, joutuu kelaamaan koko listan läpi uudelleen. Taaksepäin liikkumiselle kun ei omaa nappia riittänyt.

Kun nappeja on enemmän kuin toimintoja, yksi painike joutuu vastaamaan monesta asiasta. Tällöin käyttöliittymään tuodaan erillisiä tiloja eli moodeja (mode). Moodeja kannattaa välttää, jos suinkin mahdollista, sillä ne ovat ihmisille vaikeita ja aiheuttavat joidenkin tutkimusten mukaan suurimman osan tilanteista, joita onnettumuusuutisissa kutsutaan inhimillisiksi virheiksi (yleensä inhimillisen virheen takana on epäinhimillinen järjestelmä, mutta tätä harvoin mainitaan uutisissa).

***

Moodi voidaan määritellä niin, että eri moodeissa sama toiminta aiheuttaa eri vasteen. Näin esimerkiksi tietokoneen caps lock -painikkeella siirrytään moodista toiseen. a-painikkeen painaminen tuottaakin yhtäkkiä vasteeksi A:n. Moodista kerrotaan valolla, joka monissa näppäimistöissä sijaitsee aivan muualla kuin caps lock -nappi, ja jää näin helposti huomaamatta. Työnäppäimistössäni ei näköjään ole minkäänlaista indikaattoria asiasta.

Yleensä vahingossa painetun caps lockin huomaakin vasta jäljestä, joka ei vastaa tarkoitusta (erään tiedon mukaan viimeisin tahallinen caps lockin painallus sattui vuonna 1987). Moodivirhe on tapahtunut, mutta onneksi lopputulos ei ole sen vakavampi.

Yksi liennytys määritelmälle on. Jos moodi on käyttäjän huomion kohteena, painikkeen modaalisuus on hyväksyttävää. Näin on ihan ok tehdän play/pause-painike musiikkisoittimeen, sillä käyttäjä tietää missä moodissa hän on kuulemalla äänen korvissaan. Musiikin pysäyttäminen on paljon hankalampaa, jos kuulokkeet eivät ole korvilla ja joutuu pohtimaan, tarkoittaako näytöllä näkyvä play-symboli, että musiikia toisetaan parhaillaan vai että musiikin toisto alkaa, jos nyt painan vieressä olevaa nappia.

Viimeksi tuskailin moodien kanssa suuremmin viime kesänä. Yritin katsoa kelloa Helsinki-Tallinna-purjehduskilpailussa. Kädessäni oli Claes Ohlsonilta ostettu anadigikello, jonka näytön taustavaloa en tahtonut saada päälle. Painoin kaikkia neljää nappia vuoron perään, mutta mikään ei toiminut.

Valonappi oli modaalinen, se toimi vain tietyssä moodissa. Muissa tiloissa se teki jotain muuta. En muistanut ulkoa myöskään mode-napin sijaintia, joten olin täysin arvailun varassa. Jonkin aikaa nappeja painettuani valo viimein syttyi, mutta huomasin harmikseni, että nappeja hakatessani olin tullut säätäneeksi kellonajan vääräksi. Onneksi valo valaisi myös viisareita sen verran, että sain lopulta ajan selville.

***

Einstein kehotti tekemään asioista niin yksinkertaisia kuin mahdollista, mutta ei yhtään yksinkertaisempia. Larry Tesler on samassa hengessä todennut, että järjestelmiin liittyy tietty määrä välttämätöntä monimutkaisuutta. Sähköposti vaatii lähettäjän ja vastaanottajan osoitteet, joten ne on pakko tietää.

Sähköpostiohjelma voi auttaa niin, ettei omaa osoitetta tarvitse kirjoittaa, ja vastaanottajakin osataan täydentää muutaman kirjaimen perusteella. Jos halutaan säästää käyttäjää ajattelulta, suunnittelijan on ajateltava etukäteen tämän puolesta. Monimutkaisuuden määrä on vakio, mutta toisessa tapauksessa lopputuloksena on tyytyväinen käyttäjä.

Joskus ajattelun tekee suunittelijan sijaan tekniikka. Google pystyy tarjoamaan yksinkertaisen hakuluukun juuri siksi, että heillä on valtava määrä dataa ja mielettömät algoritmit sen läpikäymiseen. Lopputulos on yksinkertainen, mutta ei liian yksinkertainen. Välttämätön monimutkaisuus on mukana

Pitäisikö murupolkuelementin kertoa, missä käyttäjä on oikeasti käynyt?

Wednesday, November 4th, 2009

Murupolku on hauska käännös nokkelasti nimetystä breadcrumb trail -navigointielementistä. Hannu ja Kerttu jättivät muruja taakseen löytääkseen tiensä kotiin. Tyypillinen murupolku ei sittenkään kuvaa käyttäjän todellista historiaa, vaan sivuston hierarkista rakennetta.

Mm. Arthur Clemens on suosittanut käyttämään elementille toista termiä, ja Jakob Nielsenkin on huomauttanut, että nimi johtaa harhaan.

Apple - Magic Mouse - The world2019s first Multi-Touch mouse.

Applen sivuilla murupolku sijaitsee tyypillisen sivun ylälaidan sijaan huomaamattomasti alatunnisteen lisänavigaation osana

Nielsenin ohje on kuitenkin yksikäsitteinen: murupolun tulee kuvata sivuston rakennetta, muuten se vain toistaa paluu-painikkeen toiminnallisuuden. Juho Päivärinta on tehnyt murupoluista hiljattainkokonaisen gradun [PDF, 1,5 Mt] ja toteaa (s. 29), että kävijän todellista historiaa kuvaavia murupolkuja käytetään harvoin:

Polku-murupolut (“miten sinä tulit tänne”) ovat dynaamisia ja edustavat termin alkuperäistä metaforaa eli näyttävät polun, jonka käyttäjä on kulkenut Web- sivuston sisällä päästäkseen nykyiselle sivulle (Rogers & Chaparro 2003, 1; Instone 2002, 1). Sivuston sama sisältö voidaan esittää myös toisten murupolkujen avulla, koska käyttäjät voivat kulkea eri reittejä samaan kohteeseen. Nämä murupolut ovat yleisiä tietokantapohjaisten Web-sivustojen keskuudessa. (Instone 2002, 1.) Murupolkujen linkit eivät viittaa sivuston laajempiin luokkiin hierarkiassa, vaan ne viittaavat sivuihin, joissa käyttäjä on aikaisemmin käynyt (Aery 2006). Spoolin (2008) mukaan näitä murupolkuja käytetään harvoin Web-sivuilla (Spool 2008).

Lainauksessa sanotaan, että historiaa näyttävät polku-murupolut (sanana vähän hupsu) olisiat käyttökelpoisia tietokantapohjaisilla web-sivuilla. Onko nykyään olemassa muitakin?

Perinteiset hierarkiset murupolut tuntuvat minusta usein teennäisiltä, kun sivustolla ei ole varsinaista hierarkita rakennetta. Mikä on vaikka Amazonin, Youtuben tai Flickr:n hierarkia? Niissä on pääsivu ja sisältöä, joihin liittyy erilaisia tägejä, mutta tägeillä ei ole keskinäistä hierarkiaa. Jos valitsen yksittäisen videon tai kirjan etusivulta, enkö ennemminkin hämmenny, että olen hypännyt satunnaisen kategoriapolun päähän.

Ehkä tästä syystä mainituissa palveluissa ei murupolkua näykään.

Päivärinnan viittaama Jared Spoolin artikkeli sisältää hyviä ajatuksia. Siinä varoitetaan murupolkujen itsetarkoituksellisuudesta ja kehotetaan miettimään, mikä on oikeasti hyödyllistä. Spoolin attribuuttipohjainen murupolku kuulostaa mielekkäältä tietokantapohjaiselle sivulle. Kun käyttäjä kaventaa tuotevalikoimaa hakutuloksia suodattamalla, tehdyt valinnat näytetään murupolussa.

Tämä ei korvaa selaimen paluutoimintoa, sillä suodattaminen saattaa tapahtua ajax-henkisesti yhdellä ainoalla sivulla. Saatu informaatio on myös mielekkäämpää kuin kiinteä hierarkian esittely, sillä se heijastelee käyttäjän tekemiä todellisia valintoja.

Taannoin kehumani Fruugo toimii näin, kuinkas muuten. Murupolku kuvaa käyttäjän hakutulosta rajatessaan tekemiä valintoja.

Sisustus - Koti | Fruugo

Olin aikeissa sanoa, että tuotteen itsensä sivulla murupolkua ei kuitenkaan ole, vaan tarjolla on vain linkki takaisin tuotteen pääkategoriaan. Tuo on näemmä muuttunut sitten viimenäkemän. Nyt siellä on sittenkin murupolku.

Esimerkki havainnollistaa hyvin, kuinka tuotteen omalla sivulla oleva kiinteään hierarkiaan perustuva murupolku näyttää erilaisesta kuin haettaessa syntynyt valittuihin attribuutteihin perustuvat murupolku. Tuote olisi ollut löydettävissä myös ilman valitsemaani määrettä Kiinteä kattovalaisin, mutta koska satuin sen valitsemaan, minun murupolussani se näytettiin.

Pendant Nova Small Lamp | Fruugo - Tuotteet

(Hollanti sentään on kiva kieli, jos ei muuta.)

Mitähän tästä nyt pitäisi sanoa.. Tietokantapohjaisilla sivuilla kannattaa tarjota attribuuttiperusteinen murupolku, joka peilaa käyttäjän tekemiä valintoja. Yksittäisen tuotteen sivulla voi näyttää hierarkisen murupolun, jos mielekäs hierarkinen rakenne on luotavissa. Kuten Nielsenkin toteaa, ei murupoluista pahemmin haittaakaan ole.

Me & My – paluu

Monday, June 2nd, 2008

Lienen joskus aiemmin nurissut, kuinka Windows XP:n tapa merkitä kohteet hyödyttömällä My-etuliitteellä on hölmö (My documents, My Computer, My Music jne.). My ei tuo mitään lisäinformaatiota, mutta hankaloittaa nimien hahmottamista ja etenkin kohteen löytämistä listasta näppäimistön avulla. Sittemmin Microsoft otti opikseen ja poisti turhat my:t Vistasta. Nyt aihe on jälleen ajankohtainen, kun Applen juorutaan muuttavan .mac-palvelunsa me.comiksi. (Se olisi hyvä, sillä .mac on kurja nimi. Yrittäkääpä löytää siihen liittyvää keskustelua Googlella. Se ei ole helppoa, sillä haku ei huomioi pistettä, ja tulokseksi kelpaa mikä tahansa macciin liittyvä.)

Jos on olemassa riski, että omat ja vieraat menevät sekaisin, omuuden korostaminen voi olla hyödyllistäkin. Blogilista.fi esimerkiksi käyttää nimeä Omat suosikit sivulle, joka listaa käyttäjän tilaamat blogit. Näin ei jää epäselväksi, ovatko ne suosikkeja käyttäjän mielestä vai koko palvelunlaajuisesti. Toisaalta oma-sanaa voitaisiin pitää tuossa redundanttina, sillä suosikit on listattu ympäristöön, jonka muutkin linkit ovat käyttäjäkohtaisia, eikä suosikki-sanaa käytetä palvelussa missään muussa kuin käyttäjäkohtaisessa merkityksessä. Windows XP:n My Computer on käännetty suomeksi Omaksi tietokoneeksi, ja oma onkin parempi sana kuin minun – jo siksi, että minun vaatii jälkimmäiselle sanalle ohjelmallisesti hankalasti toteutettavan possessiivisuffiksin.

Blogilista.fi - Omat suosikit

Oma ei myöskään Kaikkiaan näyttää, ettei ole millään lailla selvää, milloin kyseessä ovat minun asiani, milloin taas sinun. Suomen kielen vihulaisena kunnostautunut Sonera tarjoaa tästä hupsun esimerkin. Jos kerran Minun Sonera on juuri sellainen kuin sinä haluat, onko Sinun Sonera vastaavasti sellainen kuin minä haluan?

Kuka on sinä ja kuka on minä menee äkkiä sekaisin. Blogilistallakin käy näin. Linkki Muokkaa tietojasi antaa ymmärtää, että käyttäjä on persoonaltaan sinä. Avautuvan sivun valinta Olen kiinnostunut taas vihjaa, että käyttäjä onkin minä.

Blogilista.fi

Kamalan vaarallista tuo tuskin on, mutta jossain tapauksissa lievästi hämmentävää. Tietokoneohjelmien käyttöliittymissä neuvottiin jo kauan sitten kirjoittamaan dialogien tekstit niin, että tietokone ei puhu minämuodossa. Tällöinhän ohjelman asetuksetkin olisivat äkkiä minun asetukseni, jos tietokone onkin minä. Jossain vaiheessa tuosta tulisi kovin sekavaa, eikä kaikkiaan liene kovin käyttäjäkeskeistä, jos tietokone noin varastaa show’n itselleen. Sinun ja minun käyttämisestä käyttäjää puhuteltaessa en ole vastaaviin ohjeisiin törmännyt. Neuvoisin sittenkin käyttämään mieluummin oma-sanaa ja harkitsemaan vahvasti, onko sekään tarpeen.

(Wikipedia kertoo, että Me & My kävi tosiaan Movetronin tapaan kokeilemassa Tanskan euroviisukarsinnoissa 90-lukuboomin voimakkuutta. Yrittäessäni hakea Baby Boyn videota YouTubesta huomasin, että hakuluukkuun ei jostain syystä voi kirjoittaa &-merkkiä.)

Käyttäjät ja kokijat

Wednesday, May 7th, 2008

Skrubun Pni kirjoitti kiinnostavasti, ja vastauksesta tuli sen verran pitkä, että kirjoitan sen kommenttilaatikon sijaan tähän.

Käyttäminen liitetään usein negatiiviseen yhteyteen. Usein kuulee, että joku ei halua tehdä jotain koska ei osaa käyttää jotain laitetta tai ohjelmaa. Lopputulokseen pääseminen on positiivinen asia, käyttäminen ei niinkään.

Käyttäjä on sanana vähän hassu. Vuorovaikutteisten laitteiden ohellahan sitä käytetään lähinnä päihteistä puhuttaessa. Tässä blogissa esimerkiksi käyttäjäksi on tavattu ymmärtää kuka tahansa toimija ja käyttöliittymäksi mikä tahansa rajapinta, jossa vuorovaikutusta tapahtuu, mutta jotkut ovat tarkkoja siitä, että käyttäjästä saa puhua vain kun systeemissä on kyse jonkinlaisesta tietokoneesta. Toiset taas ovat sitä mieltä, että käyttäjästä voi puhua yhtä hyvin kuvatessaan kivan t-paidan herättämää tunnetta tai täytekakkua syödessään. (Esimerkit Virpi Roton artikkelista, jonka kaivan tähän ehtiessäni.)

Jos oletetaan, että käyttäjät liittyvät ainoastaan tietokoneisiin, ja tietokoneet ovat insinöörimäisiä järjestelmiä, joilla saadaan suorettua tietyt tehtävät – aivan kuten auton ainoa ominaisuus olisi viedä jostain jonnekin – ei ihme, että käyttäjä-sana assosioituu epämiellyttäviin tilanteisiin.

Käytettävyyden määritelmään liitetään miellyttävyys, mutta se tulee mukaan pääasiassa sitä kautta, että tehtävä saadaan suoritetuksi tehokkaasti, virheittä ja vähäistä oppimista ja muistamista vaatien. Näin itse käyttäminen ei ole miellyttävää, vasta perille pääsy on. Asiaan liittyy myös tavoitteiden ja tehtävien erot. Ihmiset haluavat saada tavoitteensa (goals) aikaiseksi, kuten Pnin äiti saada langan päähän haluamansa ihmisen. Vuorovaikutteisten laitteiden käytön taas näetään koostuvan yksittäisistä tehtävistä (tasks). Luontevaa järjestelmää käyttäessään henkilöstä (tai käyttäjästä) tuntuu, että hän on matkalla tavoitteeseensa. Hankalassa systeemissä edetään vaivalloisesti tehtävä kerrallaan.

Tulin vasta Skrubun jutun luettuani ajatelleeksi, että käyttäjä on ehkä huono sana siksi, että se liittyy niin voimakkaasti käytettävyyteen, joka on viimeisen reilun kymmenen vuoden aikana koettu liian suppeaksi käsitteeksi ja alettu sen sijaan puhua käyttökokemuksesta (jotkut puhuvat käyttäjäkokemuksesta).

Pni toteaa:

Käyttöliittymän käyttäminen ei tuota onnistumisen tunnetta.

Jos käyttäjä liittyy utilitaristiseen käytettävyyteen, kenties käyttökokemuksen yhteydessä pitäisikin puhua laajemmin kokijasta. Käyttökokemuksen määritelmät vaativat, että jo pelkän käytön pitäisi kyetä herättämään mielihyvää, mutta ehkä ihminen ei tässä tapauksessa saakaan tyytyväisyyttä käyttäjänä vaan kokijana. Tällaiseen erotteluun en ole kyllä törmännyt. Yleisemmin vaikuttaa, että moni kutsuu käyttäjiä Pnin tavoin nykyään ihmisiksi, mikä ei ole yhtään pöllömpi ajatus.

(Täällähän vatvottiin aiemmin, ovatko käyttäjä- ja ihmiskeskeinen suunnittelu samoja asioita.)

Lead userit ja kuuluuko ideoilla olla arvoa

Sunday, April 27th, 2008

Eric von Hippel kehitti lead user -käsitteen 80-luvun lopulla ja on julkaissut kaksi ilmaiseksi ladattavissa olevaa kirjaa aiheesta (Sources of Innovation, 1988 ja Democratising Innovation, 2006). (En löytänyt lead userille suomennosta, joten kutsun heitä alliteraatiointoilijana kärkikäyttäjiksi. Lisäys: mutta vain tässä yksittäisessä merkinnässä, sillä sana on kommenttien mukaan jo muussa käytössä, joskaan Googlen mukaan ei kovin laajasti). Hippelin mukaan kärkikäyttäjät ovat halukkaita modaamaan käyttämiään laitteita paremmin omia tarpeitaan vastaaviksi. Kaksi tärkeää kärkikäyttäjiä yhdistävää piirrettä ovat:

1. Kärkikäyttäjät kohtaavat tarpeita, jotka yleistyvät markkinoilla, mutta he kohtaavat ne kuukausia tai vuosia ennen markkinoiden valtavirtaa.

2. Kärkikäyttäjät hyötyvät itse merkittävästi näihin tarpeisiin vastaavasta ratkaisusta.

Esimerkkejä kärkikäyttäjäinnovaatioista ovat maastopyörät ja WWW. Molemmissa tapauksissa kehittäjiä kiinnosti saada ratkaisu tarpeeseensa, ei niinkään valloittaa maailmaa tai luoda omaisuutta. Hippel toteaakin, että kärkikäyttäjät jakavat tyypillisesti mielellään keksintönsä, sillä he ovat jo tyytyväisiä saatuaan oman ongelmansa ratkaistuksi, eikä tiedon panttaaminenkaan onnistu, sillä jos yksi maastopyöräilijä päättää jättää ideansa kertomatta ilmaiseksi, joku toinen kertoo sen kyllä.

Tietenkin, innovaatio on innovaatio vasta kun se tuottaa rahaa, ja suomalaiset ovat huonoja kaupallistamaan mitään jne., mutta minusta malli tuntuu vähän kestämättömältä. Olen taipuvainen olemaan samaa mieltä kuin Hippeliä haastatellut Leonard Witt:

Yeah, but in your video you show how some companies are making $300 million on lead user ideas, and what does the lead user get, a lousy mountain bike. Seems unfair.

Eikö innovaation demokratisointi jää hieman puolitiehen, jos valmistajat yksin keräävät hyödyt. Etenkin, jos valmistajat eivät mitenkään avusta alkuperäisessä innovoinnissa. Kunhan keräävät hedelmät. Eikä sillä, on toki olemassa ihmisiä, jotka tekevät laadukkaita ilmaisohjelmia. Jotkut käyttävät aikaansa kirjoittaen mainioita blogeja. Ja ilmaiseksihan Hippelkin kirjansa jakaa. Minua vain ärsyttäisi, että joku tekisi rahaa sillä, minkä itse jakaa ilmaiseksi, mutta niinhän niitä Linux-distrojakin on luvallista myydä, jos haluaa.

Antamisen strategia lopulta olettaa sekin vastavuoroisuutta. Ehkä homman voisi katsoa muodostuvan kärkikäyttäjän kannalta mielekkääksi siinä tapauksessa, että valmistajan tuottama ratkaisu on parempi kuin mitä kärkikäyttäjä pystyy itse luomaan eikä valmistaja olisi koskaan keksinyt tehdä tuotetta ilman kärkikäyttäjän ideaa. Tällöin kaikki voittavat.

Toinen juttu, joka minua hieman häiritsee Hippelin mallissa on sen suhde tässäkin blogissa taannoin käsiteltyyn Mooren kuiluteoriaan. Hippel kehitti mallinsa ennen Moorea, mutta on sittemmin mm. tässä 245-megatavuisessa videossa esittänyt, että lead userit sijaitsevat ennen Mooren (ja Rogersin) mallin käyttäjätyyppejä, sillä he tuotteen kehittäjinä käyttävät tuotetta jo ennen kuin se on markkinoilla. Kuitenkin kuvaan lead userit on piirretty tylysti innovaattoriryhmän päälle.

lead users

Sikäli lead user -malli kyllä tuntuu järkevältä, että se ei ole niin rajoittunut katsomaan ihmisiä näiden teknologiasuhteen kannalta kuin Mooren kuilumalli, vaan arvostaa käyttäjien syvällisestä domaintuntemuksesta kumpuavaa näkemystä.

Instill confidence

Tuesday, April 8th, 2008

Lähettäjä nimeltään Lainaus lähestyi minua sähköpostilla, jossa kysyttiin, olenko jo vastannut asiakaskyselyyn ja kerrottiin, että vielä onnistuisi. Otsikon lukeminen paljasti, että Lainaus liittyi Teknillisen korkeakoulun kirjastoon. Minua oudoksutti, sillä en ollut kuullut asiasta aiemmin ja viestistä syntyi kuva, että olisin aiemmin jättänyt sen väliin.

Ajattelin, että käyn pikaisesti klikkaamassa kyselyn läpi, sillä tokihan kirjastossa ärsyttää muutama juttu. TKK:n kirjastosta olen kirjoittanut niin tässä blogissa kuin toisessakin. Web-palvelusta riittäisi kirjoitettavaa enemmänkin.

Vaan kyselyn nähtyänipä lannistuin ja koin pienemmäksi vaivaksi tulla itkemään internetiin kuin määritellä 9-portaisella asteikolla, kuinka paljon luottamusta henkilökunnan pitäisi minimissään ja optimaalisesti herättää asiakkaassa ja mikä mahtaa olla tilanne nyt. Kysely oli saatavilla ainoastaan englanniksi [lisäys: käännös on olemassa, mutta siihen ei voi vastata suoraan], mutta en varmaankaan jaksaisi vastata siihen suomeksikaan.

Library Service Quality Survey - Welcome!

Tiedot kuulemma prosessoidaan Yhdysvalloissa. Tiedä sitten, onko kyseessä jokin määrämuotoinen tutkimus, joka pakottaa moiseen pikkutarkkuuteen.

Lisäys: testasinpa, että lopun taustatietokysymykset täyttää noin minuutissa, jolloin varsinaiselle kyselylle jää aikaa noin 9 minuuttia. Tässä ajassa tulisi ehtiä miettiä 9-portainen vastaus 74 kysymykseen. Yhtä kysymystä kohti jää aikaa yli seitsemän sekuntia, joten tuo nyt ei ole reippaalle teekkarille temppu eikä mikään. Vapaata palautetta ei tuossa ajassa ehdi antaa lainkaan.

Näemmä linkittämiskelvottomassa kehyksessä on lisää selittelyä siitä, miksi kysely on näin hankala:

Koska olemme menossa kohti Innovaatioyliopistoa, käytämme kansainvälistä LibQUAL -kyselyä, jonka on kehittänyt yhdysvaltalainen ARL -konsortio. Kyselylomake on englanninkielinen.

[– –]

Kaikki kysymykset eivät täysin sovellu meidän ympäristöömme, mutta käytä lähinnä sopivia vaihtoehtoja.

Lisäys 2: kommenteissa nähtävillä kirjaston kattava kommentti asiasta.

Palailu: käyttökokemus vs. käyttäjäkokemus

Monday, April 7th, 2008

Kirjoitin aiemmin käytettävyysalan termien sekamelskasta, mm. user experiencen kääntämisestä vuoroin käyttökokemukseksi, vuoroin käyttäjäkokemukseksi. Adagen sanasto tarjoaa jälkimmäistä, joten kirjoitin heille ja kysyin, mistä tämä johtuu. Info-osoitteeseen laittamani viesti sai viimein kattavan vastauksen itseltään Janne Tompurilta, ja julkaisen sen hänen luvallaan:

Tervehdys

Pohdin hiljattain eräitä käytettävyysalan terminologisia omituisuuksia ja tulin samassa yhteydessä kiinnittäneeksi huomiota user experiencen suomenkieliseen käännökseen. Enemmistö kirjoittajista näkyy kääntävän sen käyttökokemukseksi. Teidän sanastonne ja wikipedia puhuvat käyttäjäkokemuksesta.

Ennen vanhaan puhuttiin vastaavalla tavalla user suoraan suomeksi kääntäen käyttäjäliittymästä. Sittemmin käyttöliittymä on vakiintunut suomalaiseksi termiksi. Onko jokin syy, miksi käyttäjäkokemus tulisi kääntää eri logiikalla kuin käyttöliittymä, ja käykö käyttäjäkokemukselle jatkossa kuten käyttäjäliittymälle aiemmin?

Terveisin,
Matias Pietilä, käytettävyyskiihkoilija ja entinen kielipoliisi

Terve Matias,

Selatessani vanhoja sähköpostiviestejäni huomasin lähettämäsi viestin ja muistin, että en vielä vastannut kysymykseesi. Kysymys on minusta hyvä ja täytyy myöntää, että olemme Adagessa käyttäneet molempia käännöksiä termille “user experience”, joista kumpikaan ei liene vielä vakiintunut. Virallista käännöstä termille voisi tiedustella kielitoimistosta.

Olen samaa mieltä, että termin “user interface” vakiintunut käännös ilman muuta viittaisi siihen, että myös “user experience” tulisi kääntää “käyttökokemukseksi”. Toisaalta englannin kielessä voidaan käyttää myös termiä “use experience”, jonka käännös olisi myös “käyttökokemus”. Katso esimerkiksi:
http://blog.jonudell.net/2007/01/20/first-have-a-great-use-experience-then-have-a-great-user-experience/

Lisäksi käännöksillä on suomen kielessä pieni merkitysero, jota on toki vaikea pukea sanoiksi. En tiedä miksi alallamme halutaan ankkuroitua aina käyttäjiin, jotka kuitenkin ovat aina ihmisiä. Kuluneen vitsin mukaan vai käytettävyysasiantuntijat ja huumepoliisi puhuvat ihmisistä käyttäjinä. Itse olen pyrkinyt pois tämän yksiulotteisen termin käytöstä, sillä se tavallaan rajoittaa suunnittelijan mielikuvaa tuotetta käyttävistä ihmisistä, jotka tuotteen käyttämisen lisäksi elävät arkielämää, muodostavat mielipiteitä ja kokevat tunteita.

Luin blogikirjoituksesi käytettävyysalan termien käännöksistä ja täytyy sanoa, että itsekin olen törmännyt samoihin haasteisiin. Tyyppillinen esimerkki haasteista on vaikka ISO-standardin käytettävyyden määritelmä, jonka termeille “effectiveness”, “efficiency” ja “satisfaction” näkee hyvin erilaisia käännöksiä, jotka eivät täysin vastaa käsitteiden englanninkielistä merkitystä ilman tarkennusta. Olen toisaalla pohtinut kirjoituksesi teemaa (ihmiskeskeinen vs. käyttäjäkeskeinen suunnittelu) eli UCD-käsitteistön määrittelyä seuraavasti:

The terms “human-centred” and “user-centred” are often used synonymously without any conceptual distinction, which has led to some sort of terminological confusion. There are also a number of similar terms such as “customer-centred” and “client-centred” with a slight shift in focus. All these concepts emphasise the centredness or importance of humans in certain role in the design process. However, there are differences in how authors understand and apply the terms. Therefore, a few conceptual clarifications are required. First, I will use the general term “human-centred”, its opposite being “technology-centred”, to emphasise the importance of common human capabilities and limitations such as those originating from human physiology or psychology. By “humans” I do not only refer to the users of the product, but all relevant stakeholders that are affected by or involved with particular technology. Second, I will use the term “user-centred”, its opposite being “machine-centred”, to emphasise the importance of the skills and needs of specific users and user groups, such as those of the novice and expert users. Some authors refer by the term “user-centred” to more specific task-related requirements. Third, to catch this conceptual distinction, I will use the term “task-centred” to emphasise the importance of task-related requirements, such as task workflow or distribution of tasks.

Edellä mainittu lähestymistapa erottelee vastakohtaparien avulla merkityseroja toisilleen läheistä sukua oleville käsitteille. Täytyypä tutustua kirjoituksessasi mainitsemaasi Susan Gasson artikkeliin, joka vaikuttaa ihan mielenkiintoiselta.

Ystävällisin terveisin,

Janne

Vielä jatkoviesti ISO-määritelmän human centrednistä:

Itsekin olen ihmetellyt tuon ISO 13407:n suomenkielistä käännöstä. Tunnen SFS:n julkaisuprosessin ja epäilen, että syy käännökseen voi olla joku ihan arkinen kuten se, että käsitteellä “ihmiskeskeinen” on kielessämme jo tietty käyttöyhteys (vrt. luonto- vs. ihmiskeskeinen). Tässä yhteydessä “ihmiskeskeinen” on termin “antropocentric” käännös. Toisaalta myös englanninkielisessä maailmassa lyhenne UCD lienee vakiintuneempi kuin HCD, joten UCD:n käyttäminen lienee ihan perusteltua ISO:n määritelmästä riippumatta.

ISO käyttää HCD:ta varsin systemaattisesti standardeissa ja teknisissä raporteissaan (esim. ISO/TR-16982, ISO/TR-18529). Mielenkiintoista on, että he käyttävät termin “user interface” rinnalla kuvaavampaa termiä “human-computer interface”. Lisäksi esimerkiksi Applen käyttöliittymästandardin nimi on “Apple Human Interface Guidelines”. Ehkä pääsemmekin vielä jonain päivänä eroon termistä “käyttäjä”, joka korostaa yksipuolisesti teknologian välineellistä ulottuvuutta.

Porttiteoria

Thursday, February 21st, 2008

Osaako joku kertoa kylmiltään, miksi stage gate -malli on hyvä ajatus, jos oletetaan, että vesiputousmalli ei ole? Minulle kun ei ole koulussa opetettu, kuinka käytettävyysintoilijan tulee suhtautua stage gateen. Äkkiseltään näyttäisi, että se etenee vesiputouksen tapaan lineaarisesti vaiheesta seuraavaan ilman sen kummempia iteraatioita. Tietyn vaiheen sisällä on sallittua tehdä useita asioita rinnakkain, mutta portin läpäisyn jälkeen paluuta ei ole. Tämän eri malleja visualisoivan artikkelin luoma kuva sitä vastoin on myönteisempi.

Ymmärretään tässä yhteydessä vesiputousmalli siten, kun se on linkatussa wikipedia-artikkelissa selitetty. Tarmo Toikkanen kertoo kiinnostavasti, kuinka malli julkaistiin alun perin esimerkkinä toimimattomasta prosessista, mutta omaksuttiin sittemmin laajaan käyttöön. Kannattaa katsoa myös kommentit, kuten:

So, the “iterative process” makes the (socialistic) assumption that everyone is entitled to their job.

“Waterfall” works in capitalism, ‘iterative process” serves to justify socialism.

Käyttäjä vs. ihminen – termien sekamelskaa

Monday, February 18th, 2008

Olen toistuvasti saanut ärsyttävän vähäisiä pisteitä erilaisista terminmäärittelykysymyksistä opiskelujeni aikana, vaikka olen mielestäni ymmärtänyt oikein hyvin, mistä puhutaan. Nyt on jälleen edessä yksi hiustenhaljonnan paikka. Pidättekö ihmiskeskeistä ja käyttäjäkeskeistä tuotekehitystä synonyymeinä ja jos ette, kuinka näette näiden poikkeavan toisistaan?

Taustalla on ISO 13407 -standardi, jonka englanninkielinen nimi on Human-centred design processes for interactive systems. Suomeksi se on kuitenkin Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnitteluprosessi ja saksaksikin Benutzer-orientierte Gestaltung interaktiver Systeme. Hassusti englanniksi yleisesti käytettävä lyhenne UCD (user-centred design) puhuu jälleen käyttäjistä.

Muun muassa Susan Gasson näkyy kirjoittaneen pitkälti käyttäjä- ja ihmiskeskeisyyden eroista. Ehkä ihmiskeskeinen sitten liittyisi enemmän ihmiselle tyypillisten ominaisuuksien huomioimiseen ja käyttäjäkeskeisyys miettisi ihmistä spesifimmin käyttäjän roolissa.

Tuo alkaakin jo lähestyä ACD:tä (action-centred design). Pari vuotta sitten käytiin kiihkeää keskustelua siitä, onko koko UCD väärä tapa ajatella asioita. Viulua on vaikeaa soittaa eikä moista tuotetta syntyisi UCD:n metodein, mutta ACD:lläpä syntyisikin, sanovat.

Joku voisi väittää, ettei moinen kinastelu ole hyväksi, kun pitäisi kyetä esittämään kohtalaisen yhdenmukainen näkemys siitä, mitä tuotekehitysprosesseille pitäisi tehdä, jotta lopputulokset olisivat käytettäviä.

Surullinen on vaikka user experience (UX), josta innostuttiin puhumaan, kun käytettävyys alkoi kuulostaa liian puisevalta, mutta jota on sittemmin tungettu niin löyhillä määritelmillä joka paikkaan, että se on kokenut melkoisen inflaation. Tuonkin sanan taisi ensimmäisenä ottaa käyttöön Donald Norman, joka kommentoi jo kymmenen vuotta sitten sen löyhää käyttöä:

I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical
interaction, and the manual.

Since then, the term has spread widely, so much so that it is starting to lose its meaning.

Suomeksi user experience tilanne on hieman epämääräinen. Suora käännös on käyttäjäkokemus, ja tuota sanaa tarjoaa niin Wikipedia kuin Adagen sanasto. Käyttökokemus sitä vastoin on jo Googlen valossa paljon käytetympi (1900 vs. 6400 osumaa).

Nykyään käyttöliittymä on vakiintunut suomalaiseksi termiksi, mutta pitkään yritettiin tyrkyttää suoraa käännöstä käyttäjäliittymä (300 osumaa). Minusta tässä näyttäisi olevan kyse samasta asiasta, mutta pitää varmaan soittaa kielitoimistoon.

Logitech ja tuotteiden nimeäminen

Thursday, December 27th, 2007

Tutustuin joulun alla web-kameravalikoimiin. Näemmä Nokia ei ole ainoa yhtiö, jolla on suuri määrä toisiaan muistuttavia tuotteita, joita on vaikeaa erottaa myöskään nimien perusteella.

Tässä on Logitech Quickcam Pro for Notebooks.

pro for notebooks

Tässä vastaavasti Logitech Quickcam for Notebooks Pro.

for notebooks pro

Edelleen Logitech Quickcam Deluxe for Notebooks.

deluxe for

Ja viimeisenä sarjan täydentää Logitech Quickcam for Notebooks Deluxe.

for deluxe

Hirvittää maksaa 100 euroa web-kamerasta, kun minun koneessani sellainen on integroituna näytön kehykseen. Pikaisten testien perusteella MacBook Pron sisäinen kamera pärjää kuvanlaatunsa puolesta hankkimalleni viitisen kymppiä maksavalle Quickcam Pro for Notebookille. Tämä sisäinen kamera onkin yllättävän hyvä, ja tuntuu tuottavan peräti paremman kuvan kuin alkuperäinen ulkoinen iSight.

Olisin ollut ulkomuoden puolesta halukkaampi hankkimaan tuon alimman saman hintaluokan deluxen, mutta niitä ei löytynyt mistään. Siinä toisaalta itse kamera sijaitsee väkisin niin korkealla, että lähimainkaan silmiin katsominen ei onnistu luontevasti videoneuvottelussa. 100 euron Quickcam for Notebook Pro olisi luultavasti kuvanlaadultaan huomattavasti parempi ja on myös ulkoisesti minun silmääni parhaan näköinen. Sinänsä hauskana ominaisuutena hankkimani kamera osaa tunnistaa kasvot ja seurata niitä zoomailemalla. Vinkeää.