Talon oman GUI-tyylioppaan eli käyttöliittymästandardin luominen on kohtuullisen iso ponnistus, mutta sen tekeminen kannattaa. Tyylioppaan tekee usein tuotteen kehittäjäorganisaatio, mutta sen voi tehdä myös tuotteita ostava organisaatio liittääkseen sen vaatimuserittelyyn. Tällöin tuotteen toimittavan yrityksen on noudatettava sitä kaupan saadakseen. Näin sellainenkin yritys, joka teettää tietojärjestelmiä useassa yrityksessä saa tuotteistaan yhtenäisiä.
Parhaimmillaan tyyliopas auttaa ja nopeuttaa suunnittelutyötä. Sen avulla voidaan poistaa – mikäli sitä noudatetaan – suuri osa kaikkein turhimmista käytettävyysvirheistä: sovellusten epäyhtenäisen toimintatapa. Jotkut pelkäävät tyylioppaan rajoittavan liiaksi työskentelyä ja suunnittelijaa. Siihen ne itse asiassa on tarkoitettukin. Tyyliopas on tärkeä, koska:
- Tyyliopas on edellytyksenä, että järjestelmistä saadaan rakennettua yhtenäisesti ja johdonmukaisesti toimivat. Tämä taas on edellytyksenä sille, että järjestelmiä oppii käyttämään kohtuullisin ponnistuksin, niiden käyttö ei kuormita käyttäjän muistia, käyttäessä ei tule epäyhtenäisestä toimintatavasta johtuvia virheitä ja uusia piirteitä uskaltaa kokeilla turvallisin mielin.
- Tyyliopas myös helpottaa ja nopeuttaa järjestelmien tuottamista ohjaamalla suunnittelijoiden luovuuden muihin kuin jo aiemmin keksittyihin asioihin. Käyttäjien edustajat voivat referenssiryhmissä keskittyä sovelluksen toiminnallisuuteen. Ilman yhteisesti hyväksyttyä tyyliopasta aikaa kuluu huomattavan paljon käyttöliittymän ominaisuuksien miettimiseen ja niiden piirteistä väittelemiseen, vaikka tarjolla on valmiita toimivia käytäntöjä.
Milloin ja miten tyyliopas kannattaa tehdä?
Paras hetki tyylioppaan tekemiselle on ensimmäisten järjestelmän prototyyppien tekemisen jälkeen. Näille prototyypeille tehdään tietenkin käytettävyystesti, jotta nähdään miten siihen toteutetut ratkaisut toimivat.
Tyyliopas pitäisi rakentaa sen käyttöjärjestelmän hengessä, jossa sovelluksia käytetään. Tyylioppaan pohjana kannattaa käyttää käyttöjärjestelmän tyyliopasta. Näissä oppaissa on hyvin eritasoista ja erityyppistä tietoa käyttöliittymien suunnittelun tueksi. Yhteistä näille käytännön standardeille on niiden väljyys. Pelkästään niitä käyttämällä järjestelmistä ei vielä tule yhtenäisiä Tyylioppaan tekemiselle kannattaa ottaa vauhtia myös virallisista standardeista. ISO 9241 -sarja määrittelee näyttöpäätetyön fyysiseen ja kognitiiviseen ergonomiaan liittyvät asiat. Hyödyllisiä osia tyylioppaan tekijälle ovat esimerkiksi osat 10 (Dialogue principles), 11 (Guidance on usability), 12 (Presentation of information), 13 (User guidance), 14 (Menu dialogues) ja 17 (Form-filling dialogues). Tyyliopas voidaan rakentaa joko kerralla projektina tai iteratiivisesti. Kerralla-valmiiksi -tapa edellyttää, että käytettävissä on henkilö, jolle tyylioppaan tekeminen on tuttua ja joka tuntee graafisen käyttöliittymän salat ja karit ja jolla on riittävät tiedot sekä visuaalisesta suunnittelusta että kognitiotieteestä.
Tyylioppaan tekemisessä kuluu eniten aikaa – organisaatiosta riippuen – joko kuvien ja esimerkkien tuottamiseen tai turhasta riitelyyn. Esimerkkejä kannattaa tästä huolimatta tehdä ja paljon, koska a) niiden avulla voi tyylioppaan tekijä tarkastaa ohjeiden mielekkyyden b) tyyliopasta on helpompi ja nopeampi noudattaa, jos näytetään kuvin mitä ajetaan takaa.
Tyylioppaan rakenne voi olla seuraava:
- Johdanto
- Ikkunalomakkeiden suunnittelu
- Ikkunat, niiden käyttö ja otsikointi
- Kontrollit
- Kentät
- Valikot
- Visuaalinen suunnittelu
- Värit
- Typografia
- Kuvakkeet
- Järjestelmän rakenne
- Tietojen syöttö- ja esitystavat
- Standardoidut toimintatavat (kaikki haku- ja suodatusrutiinit)
- Käytettävyysperiaatteet
- Tarkistuslista
Tyylioppaassa kannattaa toistaa tärkeimmät kohdat myös niistä asioista, jotka käyttöjärjestelmän tyyliopas kertoo. Esimerkiksi, miten kutakin kontrollia käytetään. Kiireinen suunnittelija ei ole halukas kahden oppaan kahlaamiseen. Kovin pitkiä tekstimääriä niistä ei kuitenkaan kannata kopioida, viite käyttöjärjestelmän tyylioppaaseen (sivunumeroineen) riittää.
Kontrolleista kirjoitettaessa kannattaa tyylioppaan tekijöiden selvittää itselleen tarkkaan hankalat rajanvetoasiat. Näitä ovat muun muassa avattavan listan (drop-down list) ja avattavan yhdistelmäkentän (drop-down combo box) erot, monivalintalistan ja yksivalintalistan käyttö, milloin käytetään valintaruutuja tai -nappeja, milloin listoja (ja minkälaisia listoja) ja milloin taas yhdistelmäkentät on paras vaihtoehto. Kunnon ohjeistusta tuntuvat vaativan myös valikot, painikkeet ja välilehtikontrolli, mikäli sitä halutaan käyttää.
Visuaalisen suunnittelun kohdassa kannattaa ottaa kantaa myös siihen, miten nimikkeet ja kentät sijoitetaan toisiinsa nähden ja tasataanko nimikkeet vasemman vai oikean reunan mukaan. Näitä miettiessä kannattaa ajatella ikkunakäsittelyä kokeneen käyttäjän kannalta: kokeneelle käyttäjälle nimikkeet ovat jotakuinkin tarpeettomia, mikäli visuaalinen suunnittelu on tehty hyvin.
Kohtaa Standardoidut toimintatavat ei kannata yrittää saada tyylioppaan ensimmäiselle kierrokselle mukaan, vaan niitä voi lisätä oppaaseen sitä mukaa, kun hyviä käytäntöjä löytyy.
Huomaa vielä
Toimiakseen hyvin on tyyliopas tehtävä huolellisesti ja ammattitaitoisesti. Tyyliopas voi kääntyä jopa haitaksi käytettävyydelle, jos se tuotetaan vääristä lähtökohdista. Tästä on esimerkkejä. Tyypillisin tapaus on, että järjestelmäkehittimen tuottanut organisaatio tekee tyylioppaan asiakkaalle, jolla ei ole resursseja mitata tyylioppaan asiallisuutta, ja asiakasorganisaatio saa tyylioppaan, jossa määritellään asiakkaan sovellukset sellaisiksi, kuin vain tämän toimittajan kehittimellä saa aikaiseksi. Tässä ei ole mitään pahaa, jos suositukset ovat yleispätevät ja hyvät. Näin ei aina ole. Suosittelen ulkopuolisen asiantuntijan lausuntoa valmiille tyylioppaalle silloin, kun järjestelmän toimittaja on ominut työn kovin kärkkäästi itselleen.
Toinen tyylioppaiden tuottamiseen liittyvä poliittinen ongelma on niihin joskus liittyvä vallankäyttö. Tarkoitan tällä sen tyyppisiä ohjeita, että määrätään että ikkunakohtaisten painikkeiden on aina oltava alareunassa (josta seuraa, että painikkeiden määrä on hyvin rajattu) tai aina oikeassa reunassa (mistä seuraa ongelmia käsiteltäessä leveitä listoja ja taulukoita). Sen sijaan säännös, että painikkeille varatulla kaistaleella, oli se oikeassa reunassa tai alhaalla, ei saa olla muuta tietoa, on selkeyssyistä perusteltu. Turha säädös on mielestäni myös ikkunakokojen ja muotojen ennalta määrääminen. Näin tehdään useissa tyylioppaissa esteettisistä syistä. Esteettisyys kääntyy päälaelleen kun tietoja on hyvin vaikea sijoittaa näihin ikkunoihin selkeästi ryhmiteltynä ja ikkunan sopivasti, mutta ei liiaksi, täyttävänä.
Syy turhiin säännöksiin on toki useimmiten väärinymmärrys. Joku käytettävyyskirjakin toteaa, että ikkunassa saa olla korkeintaan seitsemän tietoryhmää ja kussakin ryhmässä seitsemän kontrollia. Miksi ihmeessä? Säännön taustalla lienee Millerin 1956 tekemä oivallus ihmisen työmuistin koosta. Hän totesi ihmisen pystyvän pitävän mielessään ja manipuloimaan yhtäaikaa korkeintaan seitsemän numeroa tai sanaa. Nyttemmin on todettu työmuistin koon olevan keskimäärin neljä mieltämisyksikköä. Työmuistin kapasiteetilla on hyvin harvoin merkitystä silloin, kun asiat ovat edessämme ruudulla, ja käsittelemme niitä yhtä kerrallaan, niin kuin näyttöpäätetyössä on laita. Tärkeätä on sen sijaan, että tiedot ovat ikkunassa käyttäjälle ja työhön nähden mielekkäässä järjestyksessä ja sisällöllisesti oikein ryhmiteltynä.
Turhat säädökset aiheuttavat suunnittelijoille turhia ongelmia ja vähentävät tyylioppaan auktoriteettia asiallisissakin kohdin, “kun sitä ei kuitenkaan voi noudattaa.” Tämän tyyppiset karit välttää pitämällä tyylioppaan aluksi yksinkertaisen karuna eli standardoimalla vain ne asiat, jotka on pakko. Ne välttää myös pyytämällä ulkopuolisia kommentteja valmiiseen oppaaseen. Oppaan läpilukeminen ei oppaita paljon tehneeltä vie kauan aikaa ja on siten kohtuullisen edullista. Konsultilta voi myös samaan hintaan saada vähän perusteluja miksi mikin asia pitää tehdä niin kuin pitää – suunnittelijoihin puree aina paremmin perusteltu näkemys kuin perustelematon määräys. Toistan vielä samat ohjeet tyylioppaan tekijöille, jonka kirjoitin KÄLI:n Graafisen käyttöliittymän suunnittelu -kirjaani muutama vuosi sitten:
“Älä väheksy äläkä anna muidenkaan väheksyä opasta, mutta ole henkisesti valmis korjaamaan sitä tarpeen tullen. Ole jatkuvassa kanssakäymisessä sekä oppaan että järjestelmien käyttäjien kanssa, niin tiedät muutostarpeet. Käytä paljon kuvia ja esimerkkejä tyylioppaassa. Tee ikkunatyypeille esimerkkipohjat. Huolehdi siitä että tyylioppaan rakenne pysyy selkeänä myös päivitysten jälkeen. Ota suunnittelijan edustajat mukaan tekemään tyyliopasta ja anna myös muiden osallistua sen kommentoimiseen niin, että he hyväksyvät sen omakseen.”
Testaa mitä teetkin.