Page 7

Sytyke_4_2015

Sytyke 4 • 2015 7 Open Source Software korkeammat vaatimukset OSS-tuotteiden käytettävyydelle. Raportit eivät enää sisällä tarpeeksi olennaista tietoa tai ne ovat toisin-toja jo raportoiduista virheistä. Avoimen lähdekoodin kehittäjäyhteisöt toimivat hallinnollisesti tavallisesti niin sa-notun sipulimallin mukaan, jossa yhteisön päätöksenteko on jakautunut eri kerroksissa toimivien henkilöiden kesken. Mitä ulompa-na yhteisön jäsenen asema sipulin kuorella on, sitä vähemmän hänellä on vaikutusvaltaa kehitettävää ohjelmistoa ja kehittäjäyhteisöä koskevassa päätöksenteossa. Eniten vaiku-tusvaltaa käyttävät sipulin ytimessä toimivat projektin vetäjät eli pääkehittäjät. Pääkehit-täjistä seuraavina sipulin kerroksella ovat ke-hittäjät, joilla on lähdekoodiin suora luku- ja kirjoitusoikeus, mutta joiden tulee kysyä pääkehittäjiltä lupa suurempiin muutoksiin. Seuraavalla, toiseksi uloimmalla kerroksella, toimivat kehittäjät, jotka tekevät pienempiä korjauksia ja muutosehdotuksia, mutta joil-la ei ole kirjoitusoikeuksia lähdekoodiin. He joutuvat hyväksyttämään muutokset vaiku-tusvaltaisimmilla kehittäjillä ja toivomaan, että muutokset julkaistaisiin. Vähiten vaiku-tusvaltaa kehittäjäyhteisössä on loppukäyttä-jillä, eivätkä he yleensä aktiivisesti osallistu kehitystyöhön. Vielä nykyäänkin käytettävyys ja käyttöliit-tymän suunnitteluprosessit ovat harvinaisia avoimen lähdekoodin projekteissa. Usein OSS-kehittäjät eivät tunne käytettävyyttä kä-sitteenä lainkaan, tai mieltävät käytettävyy-den usein pelkäksi lisäominaisuudeksi, joka voidaan helposti lisätä mekaanisesti seuraa-vaan ohjelmistoversioon. Käytettävyyttä saa-tetaan usein myös virheellisesti pitää pelkäs-tään subjektiivisena ominaisuutena tai vain käyttöliittymän ulkoasuun liittyvinä piirtei-nä. Käytettävyyden eri tekijöitä ei oteta huo-mioon tasapuolisesti varsinkaan silloin, kun kehitettävä ohjelmisto on tarkoitettu tavalli-sille käyttäjille. Tavalliset käyttäjät eivät yleen-sä osallistu avoimen lähdekoodin ohjelmis-tokehitykseen millään tavoin, eivätkä kehittä-jät ole usein juuri kiinnostuneita ei-teknisten käyttäjien mielipiteistä. Hajautetussa ja yh-teistyöllä toimivassa avoimen lähdekoodin projektissa käytettävyys muodostuu pääasi-allisesti viiden tärkeän tekijän kautta: yhteis-työhenkinen ympäristö ja erilaiset työkalut vahvistavat projektin sidosryhmien välistä kommunikaatiota; hierarkkinen, tarkkaan määritelty päätöksenteko, joka helpottaa viestintää; luottamukseen perustuva suhde kehittäjien, käyttäjien ja käytettävyysasian-tuntijoiden välillä; aikaisiin suunnittelupää-töksiin kykenevä aloitteentekijä ja käyttäjä-lähtöisen suunnittelun periaatteet hallitseva käytettävyysasiantuntija. Käytettävyyden tu-lisikin olla osa prosessia heti alusta alkaen, mutta OSS-projektin tullessa tunnetummaksi ja houkutellessa ei-teknisiä käyttäjiä, kehitys-tä on ehditty tehdä jo paljon ja käyttöliitty-märatkaisut ovat syntyneet ilman suunnitte-lua tai käytettävyysmenetelmiä. Käytettävyysasiantuntijat avoimen lähdekoodin ohjelmistokehityksessä Jotta käytettävyyden asemaa voitaisiin paran-taa avoimen lähdekoodin ohjelmistoissa, tuli-si kehitysprojekteissa olla mukana henkilöitä, joilla on tarvittavat tiedot ja taidot käytettä-vyydestä. Ohjelmistokehittäjillä ei tyypillisesti kuitenkaan ole näitä tarvittavia tietoja ja taito-ja, eivätkä käytettävyysasiantuntijat tavallisesti osallistu avoimen lähdekoodin ohjelmistoke-hitykseen. Varsinkin suurissa OSS-projekteis-sa osallistumaan pyrkivien käytettävyysasi-antuntijoiden suurimpia haasteita on tehdä itsensä tunnetuiksi yhteisön sisällä. Tärkeim-piä tavoitteita on, että yhteisössä ymmärre-tään, kuinka käytettävyysasiantuntijat voivat auttaa projektissa, kouluttaa yhteisön jäseniä käytettävyydestä ja antaa palautetta ohjelman nykyisestä käytettävyydestä. Tämä on erityisen haasteellista pienissä ja keskisuurissa OSS-projekteissa, joiden kehittäjillä ei välttämättä ole mitään tietoa siitä, mitä käytettävyys on. Avoimen lähdekoodin ohjelmistot koostu-vat tavallisesti pienistä, erillään kehitettävistä osasista, joten käytettävyyteen liittyvien muu-tosten tekeminen voi olla haasteellista varsin-kin, kun kehitystyö tehdään pääasiassa vapaa-ehtoisvoimin. Samaan tapaan käytettävyystoi-mien suunnittelu on hajautetussa ympäristös-sä vaikeaa puutteellisten työmenetelmien ja infrastruktuurin takia. Yksi olennaisimmista haasteista on se, että käytettävyysasiantunti-joiden on joskus vaikea ottaa osaa käytännön kehitystyöhön ja saada sitä kautta arvostusta, koska avoimen lähdekoodin kulttuurissa ar-vostetaan perinteisesti lähdekoodin tuotta-mista ansiota tuovana tekijänä. Käytettävyys-asiantuntijoiden on vaikeaa saada ääntänsä kuuluviin kehittäjäyhteisöissä. Kehittäjät ei-vät usein tunnista, mitä arvoa käytettävyydel-tään hyvä ohjel-misto tarjoaa. Yhteisössä pitäi-si olla tieto siitä, mitä ylipäätään voitaisiin tehdä paremman käy-tettävyyden hy-väksi. Yhtenä rat-kaisuna voisi olla erilaisia käytettä-vyyttä parantavia menetelmiä si-sältävä ohjeistus erityisesti OSS-kehittäjiä varten. Avoimen lähdekoodin kehittäjäyhtei-söissä kehittäjien välinen verkostoitumi-nen ja luottamus ovat tärkeitä tekijöitä yh-teisön menestymisen ja yhteisössä toimi-misen kannalta. Käytettävyysasiantuntijoi-den onkin vaikea saada kehittäjien luot-tamusta, sillä he eivät yleensä tuota OSS-kehittäjien arvostamaa lähdekoodia. Yh-teisön hyväksyntä tapahtuu ajallaan, ja se vaatii yhteisön ja myös sekä kyseisen OSS-projektin historian että sen sosiaalisten käytäntöjen ymmärtämistä ja kykyä näyttää omaa osaamistaan räätälöiden omat toimin-tatapansa kyseiseen yhteisöön parhaiten so-piviksi. Vaikka internet mahdollistaa osallis-tumisen avoimen lähdekoodin projekteihin monista lähtökohdista ja taustoista huoli-matta, voi erilaisten osallistujien määrä ai-heuttaa haasteita suunnittelulle yhteisen nä-kemyksen puuttuessa. Lähes kaikki käytettä-vyysasiantuntijoiden avoimen lähdekoodin kehittäjien kanssa kohtaamat ongelmat joh-tuvat luottamuksen ja meriitin puutteesta. Käytettävyyteen liittyvät ansiot eivät välttä-mättä näytä niin tärkeiltä muiden kehittäji-en silmissä kuin algoritmisten tai koodaus-teknisten ongelmien ratkaiseminen. Koska kehittäjät usein vastaavat koko ohjelmiston kehittämisestä, he mieltävät koodin omak-seen ja käyttöliittymään ehdotetut muutok-set saattavat aiheuttaa vastustusta, vaikka ne olisivatkin käytettävyyttä parantavia. Käytet-tävyysasiantuntijoiden on toisaalta oltava läheisessä yhteistyössä pääkehittäjien kans-sa, jotta tarvittavat käytettävyysparannukset toteutuisivat, mutta toisaalta pidettävä kui-tenkin etäisyyttä, jotta riittävä objektiivisuus ja käyttäjäkeskeisyys säilyisivät. Käytettävyys-asiantuntijoiden pääsy OSS-yhteisöjen tasa-vertaisiksi jäseniksi onkin erityisen tärkeää, mutta haastavaa. OSS-projektit tarjoavat käy-tettävyysasiantuntijoille ja -tutkijoille jatkos-sakin paljon haasteita, mutta myös ainutlaa-tuisen mahdollisuuden parantaa maailmaa käyttöliittymä kerrallaan. n Lähteitä Rajanen, M., Iivari, N. (2015) Power, Empowerment and Open Source Usability. In the Proceedings of the ACM SIGCHI Annual Conference on Human Factors in Computing Systems (CHI 2015). Seoul, South Korea. DOI: 10.1145/2702123.2702441 Rajanen, M., Iivari, N., Keskitalo, E. (2012) Introducing Usability Activities into Open Source Software Development Projects – a Participative Approach. In Proceedings of the 7th Nordic Conference on Human-Computer Interaction (NordiCHI 2012). Copenhagen, Denmark. pp 683-692. ISBN: 978-1-4503-1482-4, DOI: 10.1145/2399016.2399120 Rajanen, M., Iivari, N., Anttila, K. (2011). Introducing Usability Activities into Open Source Software Development Projects – Searching for a Suitable Approach. Journal of Information Technology Theory and Application (JITTA), 12(4), pp 5-26. Rajanen, M. (2011) Applying Usability Cost-Benefit Analysis – Explorations in Commercial and Open Source Software Development Contexts. PhD Dissertation. Acta Universitatis Ouluensis Series A 587. University of Oulu.


Sytyke_4_2015
To see the actual publication please follow the link above