Synninpäästö nahalle – skeuoformismin kolme tasoa

Olli Sulopuisto huhuili taannoin Twitterissä kommenttia skeuomorfismiin – reaalimaailmaa jäljittelevään design-tyyliin. Kehitin mielipiteen siltä varalta, että minulta kysyttäisiin. Aiheesta syntyi mainio juttu ilman lausuntoanikin, mutta tulin samalla ajatelleeksi asiaa tarkemmin. Näyttäisi, että siihen liittyy kolme tasoa, joista kahta on syytä välttää.  Kolmas on makuasia.

Lue loppuun

Appy-ukosta applariin – eli mitä on sovellus suomeksi

There’s an app for that, Apple alkoi mainostaa iPhonea App Storen julkaisun myötä. Hauskoille pikkuohjelmille oli syntynyt hauska pieni sana. Mutta mistä se tuli ja mitä sen pitäisi olla suomeksi?

Alunperin app-sanassa ei ollut mitään erityistä. 2000-luvun taitteessa julkaistussa Mac OS X -käyttöjärjestelmässä siirryttiin Macintosheille ennenkuulumattomasti tiedostopäätteisiin. Tietokoneohjelmien päätteenä oli application-sanasta lyhennetty .app samaan tapaan kuin Windowsilla ohjelmien pääte oli .exe. [1]

Yleisurheilun EM-kisojen maskotin nimi oli Appy (lähde: helsinki2012.fi)

Tiedostopäätteet olivat Macillä piilotettuja, joten tavallisessa käytössä .app jäi useimmille tuntemattomaksi. Käyttöjärjestelmän Mail-sähköpostiohjelmaa saatettiin joskus kutsua selvyyden vuoksi Mail.appiksi, mutta termi app ei ollut nykyiseen tapaan kaiken kansan käytössä.

iPhonen julkaisun ja viimeistään App Storen myötä tilanne muuttui. Apple kutsui puhelinten ohjelmia appeiksi niin kuin oli aiemmin kutsunut tietokoneohjelmia. Yhtäkkiä appit olivat joka paikassa. Ihmiset tuskin mielsivät, että kyse olisi tiedostopäätteestä tai application-sanan lyhenteesttä, vaan ottivat käsitteen vastaan sellaisenaan: konsensus tuntuu olevan, että app on puhelimella käytettävä ilmainen tai edullinen pikkusovellus. Sellainen, jolla on karkkimainen kiva kuvake.

Kuin sattumalta Applelle kävi jälleen hyvä tuuri nimien kanssa. [2] App alkaa kuin Apple. Ihmisten mielissä sanat liittyvät toisiinsa, joten ei ole ihme, että Apple on pyrkinyt estämään kilpailijoitaan kutsumasta omia kauppojaan app storeiksi.

Tätä taustaa vasten on helppoa ymmärtää myös suomalainen tarve omalle sanalle. Puhelinsovellusta ei haluta kutsua sovellukseksi eikä ohjelmaksi, sillä se tuo mieleen vain työpaikan excelin. Lopputuloksena on erilaisia väännelmiä app-sanasta.

Mikä on oma suosikkisi?

Äpsi Voi, tämä sana ärsyttää minua. Minusta on ihan hyväksyttävää piittaamattomuutta, ettei ihmistä kiinnosta app-sanan tausta, mutta voisiko sen verran pyytää, ettei lähdettäisi päättömästi muuttamaan sitä monikoksi.

Suomeksi Beatles-bändin jäsen on perinteisesti biitlesi, mutta siinä monikkosekaannukselle on sentään jokin syy. Jotkut myös iskevät chicksejä ja saavat siitä kicksejä eikä kickien saaminen ole kuin ironista viisastelua. Mutta miksi kukaan ottaisi äppsin tapauksessa käännöslainansa pohjalle monikollisen apps-muodon? Muffinssikin on saatu jo aika hyvin taisteltua muffiniksi.

Appi Tämä on sinänsä loogisempi versio, mutta käytännössä hankala. Ensinnäkin se kuulostaa samalta kuin appi merkityksessä appiukko. Toisekseen se taipuu genetiivissä apin. Tämä on hankalaa teknisessä keskustelussa, kun samaan aikaan sovelluksen kanssa saatetaan puhua siitä, kuinka sovellus juttelee taustajärjestelmän kanssa APIn avulla. Apin APIn kanssa menee helposti suullisesti sekaisin, mistä puhutaan. (Tietty, jos ei itsekään tiedä, niin näin voi kätevästi yrittää vaikuttaa viisaalta.)

Äppi Tähän suuntaan olen itse taipuvainen kallistumaan. Jos en jaksa sanoa sovellus, sanon äppi – kirjoittaisin kyllä appi. Samaan tapaan kuin viittaan tablettiin sanomalla pädi. Hieman surettaa köyhä suomeni, mutta tämä on jokseenkin loogista, ei sekoitu ja sopii suuhun. [3]

Applari Tämä on vähän samaa tyyliä kuin läppärit ja täppärit. Jostain syystä mielikuvani eivät ole kovin myönteisiä. Alan ajatella puklata-verbiä. Applari on toki suuhun sopiva, mutta vähän hankalan pituinen. Tavujakin on jo yhtä monta kuin sovelluksessa. Ja onko tyylilaji jo hieman turhan tuttavallisen hassutteleva?

Applikaatio Tämä tuntuu viralliselta, mutta lopulta aika teennäiseltä. Kuin minkä tahansa sanan voisi suomentaa tekemällä siitä vokaaliloppuisen. Minusta applikaatio tuntuu yhtä hankalalta ja etäiseltä kuin sovellus, mutta on huonompaa suomea. Toisaalta se saattaa olla englantia osaaville ymmärrettävämpi kuin abstrakti sovellus-termi. Yleisradio kutsuu sivuillaan sovelluksia applikaatioiksi – joskin sivu näyttää siltä, etten pitäisi sitä kovin virallisena lähteenä.

Sovelma Vähän vastaavaa keskustelua on nähty aiemminkin. 90-luvulla, kun Javan piti valloittaa myös käyttäjille näkyvä maailma, verkkosivuille upotettuja pikkusovelluksia alettiin kutsua appleteiksi erotuksena applicationista. Suomalaiseksi käännökseksi ehdotettiin tuolloin sovelmaa. (Sanan luoja oli omien sanojensa mukaan Arto Wikla.)

Appletteihin törmää nykyään sen verran harvoin, että sovelmakin voisi olla vapaana uuteen käyttöön. Eri asia sitten, kuinka luontevaksi sitä koetaan.

***

Mielenkiintoista nähdä, mikä termi voittaa tämän taiston sekä päätyykö app-sana tarkoittamaan juuri mobiilisovellusta, vai hahmottavatko ihmiset sen liittyvän myös työpöytäsovelluksiin. Apple itse on jatkanut alkuperäisellä tiellään ja kutsuu myös tietokoneille sittemmin luotua sovelluskauppaansa App Storeksi. Suomeksi Apple puhuu systemaattisesti sovelluksista.

Olen huomannut, että omassa päässäni kytkennät ovat menneet pahasti solmuun. Puhuessani televisio-ohjemista olen useampaan otteeseen sanonut vahingossa äppi.

Lisäys 2015: Kielitohtori.fi-sivulla on päädytty sittemmin aika samaan tulokseen kuin täällä: virallisesti sovellus, puhekielessä appi tai äppi.

[1] Mieleen tulee, onko koko sovellus/application-sana Windows-käyttäjille ylipäänsä tuttu vai onko Windowsilla tavattu sanoa ennemmin ohjelma/program. Tuo saattaa vaikuttaa myös suhtautumiseen app-sanaan.

Sovelluksen ja ohjelman ero on lähinnä semanttinen. Usein sanotaan, että ohjelma on mikä tahansa toimiva koodinpätkä,  mutta sovelluksen pitäisi tehdä jotain käyttäjän kannalta hyödyllistä – yleensä vuorovaikuttaisesti. Niinpä jokainen sovellus on ohjelma, mutta jokainen ohjelma ei välttämättä ole sovellus.

[2] Hieman samaan tapaan Applella kävi aikoinaan tuuri, kun podcasteja alettiin kutsua juuri podcasteiksi iPodin mukaan.

[3] Helsingin yleisurheilun EM-kisojen markkinoinnissa tykättiin sovelluksista niin paljon, että maskotti nimettiin Appyksi ja tehtiin iPhone-kuvakkeen malliseksi pyöreäkulmaiseksi neliöksi. Varsinaista sovellus onkin sitten vähän ankeampi viritys. [Kenties Mahiedine Mekhissi-Benabbad oli menettänyt hermonsa sovelluksen kanssa ja tönäisi siksi syytöntä maskottityttöä.]

Mainitaan vielä hieman aihetta sivuten, että Crapapps on mainio lista esimerkkejä siitä, mitä pahimmillaan tapahtuu, kun lähdetään tekemään sovelluksia Idea edellä.

Mitä jos ei sotkettaisi termejä (case UX ja service design)

Harvalla alalla vallitsee vastaavaa termisekamelskaa kuin käytettävyysjuttujen ympärillä. HCI, UCD, IxD, IA, UI – jokaiselle jotakin. Kyynisempi voisi väittää, että lyhenteillä brassailemalla pyritään piilottamaan substanssin ohuutta. Vaan ei hätää, nykyään on lyhenne, joka sopii joka paikkaan. Ihan mitä tahansa tunnutaan voitavan kutsua UX:ksi.

Itse ymmärrän UX:n (user experience) käytettävyyden (usability) laajennuksena. Se yhtäältä korostaa subjektiivista elämykselllisyyttä pelkän utilitaristisuuden sijaan, toisaalta käsittää laajemmin käyttämiseen tai kokemiseen liittyvät tunnetilat eikä tutki pelkkää käyttöä.

[Diplomityössäni on minusta ihan osuvaa määrittelyä aiheesta. Tässä blogissa on myös pohdittu, pitäisikö se kääntää käyttökokemus vai käyttäjäkokemus, vaikka jälkimmäinen virallinen käännös onkin.]

Vaikka olen työskennellyt nimikkeellä UX designer, kuulun varsinaisesti koulukuntaan, jonka mielestä kokemusta sinänsä ei oikein voi suunnitella, vaan kokemukselle suunnitellaan ympäristö, jossa se voi tapahtua. Näin tuntuu hassulta lukea tekstejä, joissa UX:stä puhutaan kuin laskettavista kokonaisuuksista. ”10 UX-fiitsua, jotka tapaavat puuttua verkkokaupoista”. Espanjankielinen tuotekuvaus on näemmä sekin nykyään UX-omainaisuus.

Tarkemmin tutkimalla huomaa, että moni tuntuu kutsuvan itse käyttöliittymä [UI = user interface] UX:ksi. Käyttökokemus on seurausta käyttöliittymästä, mutta sen lisäksi monesta muusta asiasta. Ei UX:ää voi piirtää paperille.

Lopullisen UX:n kannalta vähintään yhtä tärkeää kuin että käyttöliittymä on alunperin hyvin suunniteltu on, että asia huomioidaan toteutuksen aikana. Millaisia kompromisseja tehdään, ovatko vasteajat kelvollisia, millaisia siirtymiä käytetään, mihin vaiheeseen väistämätön odottelu piilotetaan, tuntuuko kokonaisuus hyvältä – mitä milloinkin.

***

Toinen merkitykseltään pahasti liudentunut käsite on palvelumuotoilu (service design). Minua vähän vierastuttaa designin kääntäminen muotoiluksi tässä yhteydessä, sillä muotoilu-sanalla ei minusta ole suomessa oikeaa konnotaatiota filosofisloogisesta ajattelusta, vaan siitä tulee liiaksi mieleen pelkkä kiva ulkonäkö. Kuinka vain, käsitteellä on alun perin tarkoitettu fyysisen maailman palveluiden optimaalista suunnittelua käyttäjäkeskeisin menetelmin.

Palveluketjuun voi kuulua myös digitaalisia käyttöliittymiä, mutta ne ovat vain osa kokonaisuutta. Tyypillinen esimerkki muotoiltavasta palvelusta voisi olla junamatka.

  • Yöllä kiinni oleva verkkokauppa on palvelumuotoilua.
  • Liian matala lippuautomaatti on palvelumuotoilua.
  • Lippu, joka ei mahdu lompakkoon, on palvelumuotoilua
  • Asema, jossa ei ole sellaista istumapaikkaa, jolta voisi seurata taulusta, paljonko juna on myöhässä, on palvelumuotoilua.
  • Tapa päivittää taulua viiden minuutin erissä niin ettei matkustaja uskalla mennä istumaan, on palvelumuotoilua.
  • Juna, joka haarautuu kesken matkan eikä vaunun sisällä lue kyseisen vaunun määränpäätä, on palvelumuotoilua
  • Lähiliikenteen junat, joiden kirjaimista ei pysty päättelemään mitä raidetta ne ajavat (esim. kaikki K:n ja S:n välillä menisivät tiettyä raidetta), on palvelumuotoilua
  • Töykeä konduktööri on palvelumuotoilua
  • Viherpestyt junanvaunut ovat palvelumuotoilua

Palveluistakin voi joidenkin määritelmien mukaan syntyä käyttökokemus. [Ja miksi ei voisi.] Kenties palvelumuotoilun voisi määritellä palveluiden käyttöliittymä- ja vuorovaikutussuunnitteluksi, jossa yhtä lailla pyritään lopulta hyvään UX:ään.

[Lisäys 28.10.2015] Yhä useammin palvelumuotoilun yhteydessä puhutaan lopputuloksena asiakaskokemuksesta (CX), siinä missä käyttöliittymäsuunnittelu liittyy käyttäjäkokemukseen (UX). Sen lisäksi asiakaskokemus sanaa tietty käytetään myös muissa yhteyksissä ja välillä näkee sanottavan varmuuden vuoksi CX/UX. [/lisäys]

Jotenkin vain on päässyt tapahtumaan niin, että myös verkkopalveluiden suunnittelua on alettu kutsua palvelumuotoiluksi. Palveluitahan ne ovat verkkopalvelutkin, mutta kun digitaalisille palveluille on jo omat vakiintuneet sanansa (käyttöliittymä- ja vuorovaikutussuunnittelu yms.) ja palvelumuotoilua vastaavasti käytetty liittymään koko palveluketjuun fyysinen maailma mukaan lukien, niin pitikö tämäkin mennä sotkemaan.

Kuinka nappien vähentäminen lisää monimutkaisuutta

[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?

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

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

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

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

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.