Ohjelmistojen kanssa säätäminen on tuttua jokaiselle, joka tietokonetta käyttää – ja nykyisellään saman kokemuksen saa jo mobiilistikin. Tekstinkäsittely kaatuu, tyylit eivät osu kohdilleen, pdf-dokumentit jumittavat koko koneen, virheilmoituksista ei ota mitään tolkkua, virustarkistus vetää ruudun siniseksi. On laskettu, että ohjelmistomokien aiheuttamat kustannukset vuodessa ovat liki 60 miljardin dollarin luokkaa, mikä on ihan tolkuton luku. 60 miljardia dollaria. Ja miksi? Siksi, että loppukäyttäjät on jätetty yhtälöstä pois, kertoo tämänpäiväinen New York Timesin artikkeli:
”The reasons arent hard to divine. Programmers dont know what a computer user wants because they spend their days interacting with machines. They hunch over keyboards, pecking out individual lines of code in esoteric programming languages, like medieval monks laboring over illustrated manuscripts. Worse, programs today contain millions of lines of code, and programmers are fallible like all other humans: there are, on average, 100 to 150 bugs per 1,000 lines of code, according to a 1994 study by the Software Engineering Institute at Carnegie Mellon University. No wonder so much software is so bad: programmers are drowning in ignorance, complexity and error.”
Koska ohjelmistojakin tekevät ihmiset ihmisille, olisi siis syytä kiinnittää huomiota myös niihin, jotka ohjelmia lopulta käyttävät. Yksi tapa, jolla koodarit voisivat ottaa loppukäyttäjät huomioon on intentional programming, jolle en löytänyt järkevää suomennosta, mutta josta joku alan ihminen varmasti osaisi kertoa tarkemminkin.
”[…] in which programmers would talk to machines as little as possible. Instead, they would concentrate on capturing the intentions of computer users.
The method begins with the intentions of the people inside an organization who know what a program should do. Mr. Simonyi [ohjelmointitavan keksijä] calls these people ’domain experts’, and he expects them to work with programmers to list all the concepts the software must possess.
The concepts are then translated into a higher-level representation of the softwares functions called the domain code, using a tool called the domain workbench. […] Using the workbench, domain experts and programmers can imagine the program however they want: as something akin to a PowerPoint presentation, as a flow chart, as a sketch of what they want the actual user screen to look like, or in the formal logic that computer scientists love.
Thus, programmers and domain experts can fiddle with whatever projections they prefer, editing and re-editing until both parties are happy. Only then is the resulting domain code fed to another program called a generator that manufactures the actual target code that a computer can compile and run. If the software still doesnt do what its users want, the programmers can blithely discard the target code and resume working on the domain workbench with the domain experts.”
Mutta onko hyvä käytettävyys pelkästään käyttäjästä ja koodarista kiinni?
Jos joku tietää aiheesta lisää, niin otan mielelläni selkokieliset linkkivinkit vastaan.
Ei tuossa nyt suoranaisesti mitään uutta ole. Uusia nimiä vanhoille asioille lähinnä.
Eikä käytettävyys ole niinkään koodaajasta kiinni vaan nimenomaan siitä, että prosessissa käytettävyys otettaisiin alusta asti huomioon. Ei tuollainen kohdealueen asiantuntijakaan välttämättä auta ohjelmaa olemaan yhtään sen käytettävämpi.
Hyvän käytettävyyden kannalta ongelmia ovat käyttäjien tarpeiden huono tuntemus, heikot kuvaukset toimintaprosesseista (monesti prosesseja luodaan vasta ohjelmaa suunniteltaessa ja seuraus on sen mukainen) sekä ohjelmien ja proessien valitettavan suuri monimutkaisuus.
Eivätkä kaikki ohjelmavirheet (bugit) aiheuta huonoa käytettävyyttä vaan usein voi olla kyse puhtaista laskuvirheistä tms. koska kukaan ei ole osannut ilmaista yleispätevää kaavaa laskutoimituksille (esimerkiksi palkanlisien laskeminen kaikissa tapauksissa).
Ohjelmien bugisuuden kannalta ainoastaan hyvät testausprosessit toimivat kunnollisena laadunvarmistuksena. Täysin bugitonkaan järjestelmä kun ei välttämättä ole mitenkään käytettävä.