Mikähän siinä on, että suurin osa koodareista ei osaa/halua/viitsi ajatella tarpeeksi loppukäyttäjää, ja sitä kautta helppoa, nopeaa ja mukavaa käytettävyyttä? Onko syynä se että suurin osa koodareista on niin teknisiä henkilöitä, että eivät vaan osaa asettua ei-yhtään-teknisen henkilön asemaan? Koodareille pitäisi iskeä vaikka kunnolla iPhone tai iPad kouraan ja pyytää heitä ottamaan esimerkkiä kuinka ohjelmistot voivat toimia siten, että käyttäjänä ei tarvitse koko ajan miettiä, että mistä voisi tapahtua mitäkäkin. Tai miksei mitään tapahdu.
Olen toiminut IT-alalla kouluttajana monissa eri firmoissa, ja ongelma monesti ihan sama. On murheellista opettaa tavallisille työntekijöille (esim. terveydenhuollon, kaupan jne.) alalla ohjelmistoja, jotka ovat todella vaikeita käyttää. Vain siksi, että ne on tehty vaikeaksi käyttää. Samassa ajassa ne olisi voitu tehdä helpommaksikin käyttää. Usein kyse pikkujutuista.
Toki hyvääkin käytettävyyttä syntyy, mutta usein vasta sitten kun koodaajan tukena on koko tiimi suunnittelemassa käytettävyyttä. Usein resurssisyistä tuollaista tiimiä ei kuitenkin ole aina mahdollista tarjota.
Luulisi, että koodaajaki voisi välillä asettua käyttäjänkin asemaan (vaikka pienen roolileikin kautta) eikä tehdä ohjelmaa aina pelkästään insinöörille. Tuntuu, että hyvä käytettävyys on aina koodareiden mielestä jotain "turhaa" ja "kyllä se asia tuollakin tavalla pitäisi tajuta". Mutta kun suurin osa ihmisistä ei tajua. Heille IT on vain normityötä tukeva eikä normityön sisältö.
En siis usko, että kyse on taidottomuudessa vaan asenteissa.
Olen toiminut IT-alalla kouluttajana monissa eri firmoissa, ja ongelma monesti ihan sama. On murheellista opettaa tavallisille työntekijöille (esim. terveydenhuollon, kaupan jne.) alalla ohjelmistoja, jotka ovat todella vaikeita käyttää. Vain siksi, että ne on tehty vaikeaksi käyttää. Samassa ajassa ne olisi voitu tehdä helpommaksikin käyttää. Usein kyse pikkujutuista.
Toki hyvääkin käytettävyyttä syntyy, mutta usein vasta sitten kun koodaajan tukena on koko tiimi suunnittelemassa käytettävyyttä. Usein resurssisyistä tuollaista tiimiä ei kuitenkin ole aina mahdollista tarjota.
Luulisi, että koodaajaki voisi välillä asettua käyttäjänkin asemaan (vaikka pienen roolileikin kautta) eikä tehdä ohjelmaa aina pelkästään insinöörille. Tuntuu, että hyvä käytettävyys on aina koodareiden mielestä jotain "turhaa" ja "kyllä se asia tuollakin tavalla pitäisi tajuta". Mutta kun suurin osa ihmisistä ei tajua. Heille IT on vain normityötä tukeva eikä normityön sisältö.
En siis usko, että kyse on taidottomuudessa vaan asenteissa.
Vastaukset 15
Vanhimmat
Asenneongelma. Sovelluskehittäjien tukena pitää olla vahva UX osaaja, joka sanoo, että mitä käytettävyyden osalta pitää tehdä. Samoin käytettävyys pitää yhdistää osaksi laatua, ei riitä, että vain virheellinen toiminnallisuus on korjattu, vaan myös viallinen käyttettävyys pitää korjata ennenkuin softa voidaan laittaa eteenpäin. Tämä on myös johdon ongelma, eli johto ei ymmärrä, että hyvä käytettävyys on kilpailutekijä.
Tämä sama asenne on jatkunut vuosikymmeniä: "ei sillä oo väliä jos se vaan toimii oikein" tai "kyllähän tosta nyt pitää jo tajuta", eli tilanne tiedostetaan, mutta sille ei vaan haluta tehdä mitään.
On se myös jännää että kirvesmies ei osaa sisustaa...
Aikas usein käyttöliittymiä koodaa erikoismiehet.
Yleisesti ottaen, jos tavoite-määrittelyissä ei lue jotain ominaisuutta niin sitähän ei sinne koodata. Tämä on lienee useimman sw-firman ohje; Ei sen koodin tarvi täydellistä olla kunhan se vastaa kirjattuihin tavoiteisiin.
Aloittelevat koodaajat kyllä lisäävät sinne kaikkea jännää härpäkettä, kun testaavat rajojaan ja kykyjään. Ja ihastelevat aikaansaannoksiaan.
Kokoneet koodarit tekevät sen mikä on tarvis, testaavat sen, laittavat käyttöön ja piste. Joku saattaa osata huomioida hieman käytettävyyttä, joku toinen taas ei.
Ja se kokeneiden koodareiden softa sitten toimii.
Jokainen ylimääräinen koodirivi sisältää potentiaalisen bugin !!!!
Jokainen koodaa bugeja !!!
Ihan turhaa hifistelyä junnuilla härpätellä - töissä tehdään töitä - härpätellään sitten omalla ajalla omilla softilla.
Logiikka on koodattu jo pari kuukautta sitten. Käyttöliittymä ei ole vieläkään lopullisesti puikoissa ja speksattu. Ongelma on käyttöliittömän grafiikan värit ja kenttien sijoittelu. Niitä viilaillaan varmaan maailman tappiin. Tosin se ei minua haittaa koska kyseessä on vaan perus HTML osion viilausta.
Toki voin käyttää tunnin siihen että siirrän jotain kenttää pikselin vasemmalle joka on tehtävä on toki Scrumin mukaisessa Sprintissä ja
1) Avaan tehtävän xxxx projektinhallinnassa
2) Otan koodin versionhallinnasta
3) Korjaan css määrityksen arvoa 50:stä 49:n
4) Suoritan koodin ja otan näyttöstä printscreenin
5) Tarkistan että pikselien positiot vastaa vastaa tehtävän asetusten vaatimuksia.
6) Ajan yksikkötesti ja LoadTestit ettei korjaukseni rikkonut mitään aikaisempaa
7) Ajan myös apinatestit eri selaimilla ja tarkistan että kenttä on tosiaan siirtynyt pikselin vasemmalle kaikissa selaimissa.
8) Kirjaan testi myös testausdokumettiin.
9) Päivitän dokumentatioon uuden näytön.
10) Kuittaan muutoksen versionhallintaan ja kirjaan siihen tapausnumeron ja selventävän teksitn mitä tein.
11) Kuittan tehdyt tunnit projektin hallintaan ja tehtävän suoritetuksi hyväksymistä varten
12) Kirjaan tunnit työaikajärjestelmään asiakaskoodilla laskutusta varten.
13) Unohtuiko vielä jotain?
Parhaassa tapauksessa vielä:
9b) Lähetät koodimuutoksen katselmoitavaksi
10b) Mergeät muutokset N -kappaleeseen muita brancheja
10c) Paketoit sovelluksen
10d) Teet asennuksesta tiketin
10e) Saatuasi kuittauksen asennat paketin N -kappaleeseen testiympäristöjä
10f) Lähetät asennuksesta versiotiedotteen postituslistalle
11b) Kuittaat tehtävän myös erillisessä defektitrackerissä
11c) Kuittaat tehtävän ScrumWorksiin tai vastaavaan (kyllähän bugin/muutoksen pitää vähintään kolmessa järjestelmässä näkyä...)
> Mikähän siinä on, että suurin osa koodareista ei osaa/halua/viitsi ajatella tarpeeksi loppukäyttäjää, ja sitä kautta helppoa, nopeaa ja mukavaa käytettävyyttä? ... Usein kyse pikkujutuista.
Esimerkkejä?
Olet hieman hakoteillä. Koodaaja ei ajattele käytettävyyttä. Koodaaja koodaa mitä speksissä lukee. Koodaaja saattaa hyvinkin tajuta tehdessään että tästä ei tule hyvä ratkaisu, mutta yleensä ei ole aikaa siinä vaiheessa enää alkaa speksaamaan hommaa uusiksi kun kikkaretta kasaan väännetään hiki hatussa viikkoa ennen FATia taikka sen jälkeen ennen SATia. Vielä vähemmän loppukäyttäjää ajattelee intialainen alihankkijakoodari, ja yleensä asiakas haluaa saada tuotteen mahdollisimman halvalla, joka johtaa väistämättä huonoon laatuun ja halvimman mahdollisen toteuttajan etsintään.
Toki pikkupuljuissa kyse voi olla myös yhdestä ja samasta henkilöstä. Yleensä niissä homma pelaakin jouhevammin ja asiakkaan kanssa saatetaan käydä asioita läpi jopa niin että koodin toteuttaja on mukana suunnitteluvaiheessa. Mutta räätälöity softa yleensä maksaa enemmän kuin tuote, joka usein ei toimi juuri niin kuin asiakas haluaisi.
Niin just!
Ensin aattlit kirjoittaa jotakin, mutta huomasin että nyt muut ovat tehneet sen puolestani. On meinaan niin samailaista sanomaa.
Itse sanoisin: on luonnollista että koodarit eivät hallitse käytettävyyttä. Hehän koodaavat ja se vaatii erilaista ajattelua ja työt kuin käytettävyyden suunnittelu.
Eli käytettävyyden suunnitteluun, ja varmaan toteutukseenkin on ihan omat ihmisensä. On toki myös kyse siitä mille kohderyhmälle tuote kohdistetaan/tuotteistetaan. Käytettävyydessä pitää ottaa huomioon niiden tarpeet / tottumukset / taso / kyv ykkyys jolla tuote tulee käyttöön.
Parhaat käytettävyyden sunnittelijat saattaisivatkin löytyä lastentarhasta, vanhoinkodista, asiantuntijoista, ihmisista jotka eivät koskaa ole käyttäneet tietokonetta.
Toimialakohtaiset ohjelmat suunnitellan prosessilähtöisesti joten niitä on mahdotonta käyttää sellaisen henkilön joka ei ymmärrä prosessia.
Jos päiväkotilapsen käteen antaa vasaran se alkaa yrityksen ja erehdyksen kautta kokeilla mitä sillä voi tehdä. Rakennusmies taas tietää mihin käyttön se sopii ja mihin ei.
Tänään töissä juuri juteltiin aiheesta. Työkaverin mielestä rakennusinsinöörin tulisi olla ollut rakennuksella oikeissa töissä vähintään 8 vuotta ennen kuin siirtyisi suunnitelupuolelle. Auto Cad:illä ja automaattisilla rakennelaskelmilla saa kyllä aikaan piirroksia ja laskelmia, mutta niitä ei koulusta tullut osaa pitää väärinä, koska kone on ne laskenut. Yksittäinen virheelinen lähtöarvo ja halli romahtaa.
Käytettävyyteen vaikuttavat muum muassa seuraavat seikat
Käyttäjän virheisiin reagointi
Käyttöliittymän logiikka ja ulkoasu
Näissä pitäisi ainakin samassa systeemissä (ja mieluummin koko firman ohjelmistoissa) olla mahdollisimman yhtenäiset menetelmät (least surprise-periaate). Tässä auttavat valmiit huolellisesti tehdyt standardipalikat.
Jotta vältyttäisiin turhalta pikselinäpertelyltä, voisi käytettävissä olla muutama valmis GUI-malli. Niistä on helpompi rapsia pois turhia kenttiä ja muuttaa nimikkeitä, kuin viritellä täysin uutta näkymää.
Edistyneet firmat tietenkin ovat jo aikoja sitten käyttäneet näitä ideoita, joten niiden kannalta tämä juttu on tarpeeton.
Ei käytettävyydessä ole koskaan ongelmia on vain vääränlaisia käyttäjiä
Tuo on juuri todella yleinen koodareiden asenne.
Näin on ja niin tulee olemaan hamaan tulevaisuuteen.