TIPTOP-käyttöliittymästandardi Versio Päiväys Tekijä Hyväksyjä Muutos

Transkriptio

1 TIPTOP-käyttöliittymästandardi Versio Päiväys Tekijä Hyväksyjä Muutos Käyttöliittymätiimi Projektiryhmä Hyväksytty standardi 1

2 Sisältö 1 TIPTOP-käyttöliittymästandardi 1.1 Tausta 1.2 Standardin hyväksyminen ja muuttaminen projektin aikana 1.3 Sovellukselle osoitettuja vaatimuksia 1.4 Käytettävyys 1.5 Puhuttelun sävy 2 Visuaalinen ilme 2.1 Graafinen ohjeisto Tunnus ja tunnuksen käyttö Värit Typografia 3 Käyttöliittymän toimintaperiaatteet 3.1 Yhdenmukaisuus Eri etenemismuotoja 3.2 Valitut käyttöliittymämallit ja tiedon visualisointitavat Oppijan käyttöliittymä Ohjaajan käyttöliittymä 3.3 Käytettävät termit 3.4 Peruutus / uudelleensuoritus 3.5 Lokalisaatio 4 Esteettömyys 4.1 Mitä esteettömyys on? 4.2 A-tason esteettömyysvaatimukset (WCAG 2.0) 4.3 Ohitettavuus 4.4 WAI-ARIA 5 Lomakkeiden suunnittelu 5.1 Visuaalinen sommittelu Kenttäryhmät 6 Taulukoiden suunnittelu 6.1 Sarakkeet 6.2. Rivit 6.3 Taulukkodatan muokkaus 7 Käyttöliittymäelementtien ohjeistus 7.1 Navigaatio Tekstilinkit Murupolku Välilehdet 7.2 Painikkeet ja niiden asemointi Tiptop-projektissa tarvittavat painikkeet 7.3 Kuvakkeet 7.4 Automaattitäydentävä kenttä 7.5 Drag & Drop 2

3 7.6 Päivämäärän ja ajan valinta 7.7 Käyttöliittymän osien koon muuttamiseen liittyvät elementitkäyttöliittymässä voi olla elementtejä, joiden kokoa käyttäjien annetaan muuttaa. Tällaisia ovat esimerkiksi ns. leijuvat korit. Lisäksi joidenkin alueiden ympärille voidaan laittaa kehys, joka indikoi käyttäjälle kyseisen alueen skaalausmahdollisuutta. Arviointipalvelussa käyttäjä voi myös piilottaa oikean puolen käyttöliittymästä kokonaan. 7.8 Henkilön tai opintojakson valinta 7.9 Radiopainikkeet 7.10 Valintaruutu 7.11 Pudotusvalikko 7.12 Listavalikko 7.13 Varoitusikkuna Tiedote Virheilmoitus Varmennus 7.14 Sisäänkirjautuminen 7.15 Sivutus 7.16 Edistymisen ilmaisimet Tiimalasi 7.17 Vierityspalkit 7.18 Velhot 7.19 Tulostus 7.20 Haku ja hakutulosten esitys 8 Tarkistuslista 8.1 Puhuttelun sävy 8.2 Käytettävyys 8.3 Käyttöliittymän toimintaperiaatteet 8.4 Visuaalinen ilme 8.5 Esteettömyys Ohjeidenmukaisuuden vaatimukset 8.6 Käyttöliittymäelementit 9 Käytettävyyden arviointi projektissa 9.1 Yleisesti 9.2 Paikalliset läpikäynnit 9.3 Etätestaus Läpikäynnit etäyhteydellä Palautekomponentit / Asynkroninen testaus 10 Lopuksi Liitteet Lähteet 1 TIPTOP-käyttöliittymästandardi 3

4 1.1 Tausta Tiptop-projektissa on päätetty tuottaa käyttöliittymästandardi, jonka mukaisesti projektin aikana tuotettavat käyttöliittymät toteutetaan. Projektiin nimetty käyttöliittymätiimi ( on työstänyt dokumenttia syksyllä Ensimmäinen luonnosversio (dokumentin rakenne ja alustava sisältö) valmisteltiin kehityssprintin 4 aikana elo-syyskuussa. Sprintissä 5 käynnistettiin varsinainen kirjoitustyö ja tuotettiin standardiin osiot mm. käyttöliittymän toimintaperiaatteista ja esteettömyydestä. Standardin näin syntyneestä välituloksesta kerättiin projektilta kommentteja sprintin lopussa järjestetyssä esittely- ja palautetilaisuudessa. Sprintissä 6 käyttöliittymätiimi tuotti standardiin puuttuvat osiot (esim. visuaalinen ilme, käyttöliittymäelementtien ohjeistus, lomakkeiden ja taulukoiden suunnittelu), jonka jälkeen standardista kerättii uudelleen palautetta esittelytilaisuudessa Saadun palautteen perusteella standardi viimeisteltiin 7. sprintin aikana ja se esitetään hyväksyttäväksi projektiryhmässä Tässä dokumentissa kuvataan projektissa noudatettavat käyttöliittymäsuunnittelun periaatteet ja käytännöt, joiden nähdään olevan laajemminkin hyödynnettävissä vastaisessa opiskelun ja opetuksen tukipalveluiden alueen tietojärjestelmäkehitystyössä. Tavoitteenasetannassa projektissa toteutettavien käyttöliittymien on edellytetty olevan intuitiivisia, esteettömiä ja innovatiivisia. Standardilla pyritään osaltaan edistämään näiden yleisten tavoitteiden saavuttamista. Laajempaa yleisten hyvien käyttöliittymäsuunnitteluperiaatteiden tunnettuutta edistävän tavoitteen vuoksi standardi on suhteellisen laaja, ja se jakautuu osassa luvuista taustoittavaan ainekseen, josta edetään laajemman käsittelyn kautta Tiptopprojektissa käytettäviin malleihin ja valintoihin (ks. 1.2 Standardin hyväksyminen ja muuttaminen projektin aikana). Keskeisimmin tämä ilmenee käyttöliittymäsuunnittelun toimintaperiaatteita käsittelevän luvun vaihtoehtoisiin käyttöliittymärakenteisiin ja visualisointiin keskittyvässä osiossa. Niin ikään esteettömyyden osalta standardissa käydään selkeästi läpi yleiset tavoiteltavat esteettömyystasot, joita vasten arvioidaan Tiptop-projektissa tuotettavia referenssipalveluita. Projektin aikana ei saavuteta kaikilta osin esteettömyyden vähimmäistasona pidettävää luokituksen A-tasoa. Niissä tunnistetuissa kohdissa, joissa tälle tasolle ei päästä, standardissa todetaan tilanne ja kuvataan miksi tavoitetasoa ei saavuteta. Edelleen kohdittain lisätään arvio, millaisella työllä projektin jälkeisessä jatkokehityksessä A-taso voidaan saavuttaa. Tiptop on monitoteuttajaprojekti ja luotavan standardin yhtenä perustavoitteena on varmistaa toteutettavien käyttöliittymien yhtenäinen ilme. Standardi toimii muistilistana kehittäjille ja auttaa osaltaan käyttöliittymäasiantuntijoiden ja kehittäjien välisessä 4

5 kommunikaatiossa. Tiptop-projektin aikana käyttöliittymät toteutetaan Liferayportletteina Java-pohjaisella Vaadin-tekniikalla. Tiptop-käyttöliittymästandardissa esitettävät periaatteet ovat kuitenkin pääsääntöisesti hyödynnettävissä riippumatta käyttöliittymäkerroksessa käytettävästä tekniikasta. Tämä tarkoittaa käytännössä sitä, että käyttöliittymäkerros sisältää mahdollisimman vähän logiikkaa, minkä ansiosta käyttöliittymät ovat tarvittaessa vaihdettavissa. 1.2 Standardin hyväksyminen ja muuttaminen projektin aikana Tiptop-projektin päätöksentekomallin mukaisesti standardi hyväksytään projektiryhmässä. Projektissa ei ole tehty vielä päätöstä käyttöliittymässä eri osioissa hyödynnettävistä käyttöliittymän rakennemalleista ja visualisointitavoista. Tehtävien päätösten mukaisesti standardia tarkennetaan, kun palvelukohtaisesti on päätetty halutusta esittämistavasta. Hyväksytty standardi julkaistaan ja säilytetään projektin wikissä. Mahdolliset myöhemmin projektin aikana esiintulevat standardin muutostarpeet valmistellaan käyttöliittymätiimissä, joka tuo muutokset projektiryhmän päätettäväksi. Muutokset standardiin valmistellaan google docissa säilytettävässä standardin muokattavassa versiossa. 1.3 Sovellukselle osoitettuja vaatimuksia Opittavuus, muistettavuus ja intuitiivisuus Rakenne ja reitit ovat helposti opittavissa, rakenne ja sisältö ovat selkeitä Käytetty kieli on selkeää ja tarkoituksenmukaista Graafinen ohjeisto Palvelu noudattaa "yleisiä konventioita" Käytetty terminologia ja ilmaisut ovat tuttuja Nopeus ja tehokkuus Sovellus reagoi käyttäjän toimiin viiveettä tai minimaalisella viiveellä Virheettömyys, virheiden estäminen ja niistä toipuminen, palaute Sovellus antaa käyttäjälle riittävästi palautetta tämän toimista Sovellus ohjaa käyttäjän toimintaa niin hyvin, ettei virheitä synny Jos virhe tapahtuu, siitä tulee selkä ja selväkielinen virheilmoitu Sovellus "täyttää käyttäjän odotukset" Huomioitava suhde muun muassa uusien palveluiden ja vanhojen välillä. Kyseessä voi olla kulttuurinmuutos, kun uusia palveluita tai työskentelytapoja otetaan käyttöön. Esteettömyys Esteettömyyden suhteen otetaan tavoitteeksi A-taso 5

6 Visuaalinen esteettömyys: kontrasti on oltava riittävä, sivulayoutin ja elementtien on oltava selkeitä, sovelluksen on oltava esteettinen ja minimalistinen Koodin validius Tekninen toimivuus Selaimista tuetaan Vaatimen tukemat: Mozilla Firefox 14 Internet Explorer 9 Google Chrome (uusin versio) Safari 4 ja 5 Opera 10 ja 11 Päätelaitteista tuetaan perustietokoneita. Kännyköille ja tableteille toteutetaan omat versiot tuotekehittelyn myöhemmässä vaiheessa projektin jälkeen. Ruudunlukijat ja tekstipohjaiset (Lynx ym.) sovellukset pyritään ottamaan huomioon mahdollisimman hyvin jo projektin aikana osatavoitteena olevan esteettömyyden saavuttamiseksi. Jos esteettömyyden A-tason edellyttämälle tasolle ei päästä, tulee syy dokumentoida selkeästi ja tuottaa tieto, millä toimenpiteillä A-taso saavutetaan projektin jälkeen. 1.4 Käytettävyys Termillä käytettävyys (engl. usability) tarkoitetaan sitä, kuinka hyvin käyttäjä onnistuu käyttämään jotakin laitetta, sovellusta tai järjestelmää saavuttaakseen tavoitteensa sen suhteen. Käytettävyys määrittää sovelluksen laatua käyttäjän näkökulmasta karkeasti kahdesta näkökulmasta: onko sovelluksessa käyttäjän tarvitsemat ominaisuudet ja onko sitä helppo käyttää? Käytettävyyden perustavoitteena on parantaa käyttökokemusta eli sujuvoittaa ihmisen ja koneen välistä vuorovaikutusta. Yleisiä käytettävyystavoitteita määritellään mm. ISO standardissa, joka sisältää mm. tavoitteet tarkkuudesta (kuinka tarkkaan käyttäjä saavuttaa tavoitteensa), tehokkuuden sekä tyytyväisyyden. ISO-standardin ohella käytettävyyttä on luonnollisesti tutkittu laajalti, ja käytettävyystavoitteiden saavuttamiseksi on laadittu runsaasti eri ohjeistuksia, kuten Jacob Nielsenin heuristiikat käytettävyyden arvioimiseen. Nielsen on täydentänyt ISO-standardiin nähden käytettävyyden arvioimiseen opittavuuden, muistettavuuden ja virheiden vähyyden. Nämä ovat olleet vaikuttamassa myös Tiptopkäyttöliittymästandardin tavoitteisiin alusta saakka. Käytettävyyttä määrittävistä termeistä opittavuus ja muistettavuus liittyvät vahvasti toisiinsa; kun sovellusta on helppo oppia käyttämään, sen käytön muistaa hyvin myös sovellukseen palattaessa. Opittavuus voi tarkoittaa myös sitä, että sovellus hyödyntää 6

7 muista sovelluksista tuttua toimintalogiikkaa; käyttäjä löytää napit ja toiminnot oletetuista paikoista, jotka myös pysyvät läpi käyttöliittymän. Tätä kautta opittavuus ja muistettavuus ovat ominaisuuksia, jotka vähentävät koulutuksen tarvetta sovelluksen käytössä. Samalla ne säästävät kustannuksia, kun työaikaa ei kulu ylettömästi koulutuksiin ja sovelluksen toimintojen toistuvaan etsimiseen. Opittavuuteen ja muistettavuuteen liittyy olennaisesti myös tehokkuus. Tehokkaaksi suunniteltua käyttöliittymää on helppo oppia käyttämään ja sen toimintaperiaate on hyvin muistettavissa. Tehokkuus liittyy myös nopeuteen, eli siihen, että sovellus vastaa nopeasti käyttäjän toimintaan ja on vakaa. Välitön palaute on oleellinen osa tätä, etenkin siitä näkökulmasta, että jokin toiminto on hidas; tästä pitää antaa heti tieto käyttäjälle. Jokaisessa vuorovaikutustilanteessa on tärkeää informoida käyttäjää välittömästi hänen toimintansa seuraamuksista. Jotta sovellus voi olla helposti opittava ja muistettava sekä tehokas ja nopea, vaaditaan siltä myös virheettömyyttä. Virheettömyydellä tavoitellaan käyttäjän tekemien virheiden ennaltaehkäisemistä sovelluksessa, käyttäjien tekemien virheiden määrä on mahdollisimman alhainen. Virhetilanteita hyvin tyypillisesti kuitenkin syntyy, jolloin hyvin tärkeäksi nousee se, miten käyttäjä selviää niistä mahdollisimman yksinkertaisesti. Virhetilanteen piilottaminen ei koskaan ole ratkaisu, vaan käyttäjälle pitää ilmoittaa selkeällä kielellä yksiselitteisin virheilmoituksin tapahtuneesta. Kun aikaisemmat kriteerit toteutuvat, ja lisäksi visuaalinen ilme on selkeä ja esteettisesti onnistunut, saavutetaan myös miellyttävyys. Tämä kriteeri parantaa käyttökokemusta ja vaikuttaa myös käyttäjän motivaatioon käyttää sovellusta. Käyttäjän ei tarvitse tuskailla, vaan hän saavuttaa tavoitteensa sovelluksen suhteen onnistuneesti. Tällöin käyttömotivaatio nousee ja jos sovellus liittyy käyttäjän työhön, saattaa tämä parantaa jopa työilmapiiriä. Hyvin usein käytettävyydeltään heikot sovellukset vievät käyttäjiltään paljon ylimääräistä aikaa ja aiheuttavat stressiä jo senkin takia, että niitä on työn takia pakko käyttää. Käytön miellyttävyys on kuitenkin hankalasti määritettävissä ja sen kokemuksen muodostuminen on käyttäjäkohtaista. Käytettävyys on riippuvainen ensisijaisesti käyttöliittymästä, mutta myös ohjeistuksesta, käyttöympäristöstä (tietokone, kannettava, älypuhelin, kännykkä, tabletti ) ja käytön tarpeesta. Kun käytettävyyttä suunnitellaan, on oleellista tuntea sovelluksen tulevat käyttäjät, heidän toiveensa ja tarpeensa. Tämä voidaan saavuttaa esimerkiksi haastattelemalla ja seuraamalla käyttäjiä heidän työssään. Muuten on hyvin vaikeaa tai lähes mahdotonta huomioida käyttäjänäkökulma aidosti suunnittelussa, selvittää mitä käyttöliittymältä vaaditaan käyttäjän näkökulmasta. 7

8 Tässä projektissa pyrkimys toki on siihen, että kaikki käyttöliittymät täyttävät kaikki kriteerit, mutta painotus vaihtelee eri käyttäjäryhmittäin. Tehokäyttäjille tarjotaan oikopolkuja ja mahdollisuuksia tehdä yhdellä klikkauksella useammalle kohteelle sama valinta. Peruskäyttäjän kohdalla painotetaan yksinkertaista käyttöliittymää. 1.5 Puhuttelun sävy Puhuttelun sävyllä tarkoitetaan tapaa, jolla käyttöliittymän teksteissä puhutellaan käyttäjää. Se on erittäin tärkeä osa käyttöliittymää, koska tekstimuotoinen puhuttelu on yksi tärkeimmistä kommunikointitavoista järjestelmästä käyttäjään päin. Jos käyttäjä tuntee itsensä taitamattomaksi tehtävän suorittamisessa tai kykenemättömäksi kommunikoimaan sovelluksen kanssa, pitää puhuttelun sävy tarkistaa. Käyttöliittymän puhuttelun sävyssä kannattaa ottaa huomioon seuraavia seikkoja: Kielen tulisi olla selkeää ja sen tulisi olla kirjoitettu käyttäjän eikä sovelluksen näkökulmasta. Tekstin tulisi olla rohkaisevaa; sen tulisi kertoa käyttäjälle mitä sovelluksella voi tehdä ja sen tulisi ohjata käyttäjää kokeilemaan uusia käyttötapoja. Teknistä ammattikieltä (jargonia) ja slangia tulee välttää. Käyttöliittymässä tulisi käyttää aktiivimuotoista sinuttelua: Voit tallentaa muutokset tästä (ei: Muutoksia tallennetaan tästä ) Samankaltaisia lyhenteitä esimerkiksi SBR ja SPB, tulisi välttää. Käyttäjän on vaikea erottaa nämä toisistaan. Huutomerkkien käyttöä tulisi välttää, sillä niistä syntyy helposti käskevä vaikutelma. Käytetään mieluummin kysymysmerkkiä esimerkiksi seuraavassa tilanteessa: Haluatko tallentaa muutokset? sen sijaan, että kirjoitettaisiin Tallenna muutokset! Vältetään hymiöitä ja huumoria. Huumori on monitulkintaista, eikä yleensä palvele käyttöliittymän tarkoitusperää. 2 Visuaalinen ilme 8

9 Portaalin etusivu HOPS-alasivu, opintojaksolle ilmoittautuminen tehty 9

10 HOPS-alasivu, opintojakson rakenteen tarkastelu 2.1 Graafinen ohjeisto Tunnus ja tunnuksen käyttö Tiptop-projektin tunnus näkyy jokaisella projektin Internet-sivulla. Asettelu on tapauskohtaista, mutta tunnus pyritään sijoittamaan alareunaan oikealle. Tiptop-projektin tunnus Värit Värit ovat visuaalisen ilmeen elementti. Värien avulla voidaan kiinnittää käyttäjän huomio johonkin käyttöliittymän alueeseen tai osa-- alueeseen. Niiden avulla voidaan nopeuttaa tiettyjen käyttöliittymän osien tunnistusta (esim. varoitusvärit) tai niiden avulla voidaan ilmaista yhteenkuuluvuutta ja rakennetta. Oikealla värimaailmalla voidaan parantaa käyttöliittymän käytettävyyttä esimerkiksi parantamalla sen luettavuutta ja vähentämällä virhepainallusten määrää. 10

11 Tiptop-projektin eri sovelluksissa käytetään samoja tai toisiaan muistuttavia värimaailmoja, näin voidaan mm. parantaa käyttöliittymien opittavuutta. Leipätekstissä käytetään joko tummaa sinistä tai mustaa tekstiväriä vaaleilla pohjilla. Mustalla tai tummalla pohjalla käytetään värinä valkoista. Otsikoissa käytetään pääsääntöisesti mustaa tai tummaa sinistä, paitsi mustalla pohjalla valkoista. Silloin, kun tarvitaan eri otsikkotasoille omat värit (erottumisen lisäämiseksi), käytetään H1-tason otsikoissa tumminta sinistä, H2-tason otsikoissa keskisävyistä sinistä ja H3-tason otsikoissa vaaleaa sinistä. Lisäksi H1-tason otsikko on boldattu ja H3-tason otsikko kursivoitu. Linkeissä avaamattomien linkkien väri on vähän harmaaseen murrettu sininen. Fokustilassa oleva linkki ja klikattu, aktiivinen linkki ovat vaaleampisävyisiä siniharmaita. Vierailtu linkki on tumma siniharmaa. Huomiovärinä voidaan käyttää tummankeltaista väriä. Huomioväriä käytetään esimerkiksi rivin korostusvärinä. 11

12 Kun on tarve ilmaista erilaisin värein joko fonteissa tai ikoneissa sitä, onko jokin osio käytettävissä vai ei, käytetään liikennevalotyyppisesti punaista (pinkkiä), keltaista ja vihreää. Tätä värikoodausta voidaan käyttää esimerkiksi silloin, kun ilmaistaan voiko opiskelija ilmoittautua jollekin toteutukselle vai ei. Varoitusväreinä käytetään Microsoft Windowsin varoitusvärejä. Niitä tulee käyttää vain ja ainoastaan kuvaamaan järjestelmän virhetilannetta. Navigaatioelementtien ja välilehtien ei-aktiivista tilaa kuvaa valkoinen taustaväri ja joko sininen tai musta kirjasimen väri. Fokustilaa kuvaa valkoinen taustaväri ja vaalea siniharmaa kirjasimen väri. Aktiivista, valittua tilaa kuvaa puolestaan tummempi sininen taustaväri ja kirjasimen valkoinen väri. 12

13 2.1.3 Typografia Typografia eli kirjasinten käyttö tähtää mahdollisemman hyvään luettavuuteen sovelluksessa. Selkeä typografia tekee sovelluksesta miellyttävämmän käyttää sekä lisää sovelluksen luotettavuutta käyttäjän silmissä. Näytöltä luettavaksi tehdylle tekstille pätee erilaiset säännöt kuin paperille painattaessa. Esimerkiksi paperilla jotain asiaa painotettaessa voidaan käyttää joko kursiivia tai lihavointia, mutta kursiivi on erittäin vaikeasti luettavaa näytöllä. Näytöllä korostaessa tulisi käyttää joko lihavointia tai toista väriä. Myöskään alleviivausta ei pidä käyttää näytöllä paitsi hyperlinkeissä. Tiptop-projektin sovelluksissa yleisenä kirjasimena (mm. leipätekstissä, tekstilinkeissä ja otsikoissa) toimii Arial. Vaihtoehtoinen kirjasin on Calibri. Leipätekstissä ja linkeissä pistekoko on Otsikoissa pistekoko on suurimmillaan 16, laskien siitä tasaisesti tarpeen mukaan (riippuen kuinka monta alaotsikkoa tarvitaan) aina pistekokoon 12 asti, jolloin otsikko on syytä boldata jotta se erottuu riittävästi leipätekstistä. 13

14 3 Käyttöliittymän toimintaperiaatteet Käyttöliittymästä on varsinaisesti vain yksi versio. Eri käyttäjäryhmästä ja toiminnosta riippuen painotetaan kuitenkin erilaisia käytettävyyden painopisteitä. Samoja toimintoja usein käyttävillä ns. tehokäyttäjillä painotetaan tehokkuutta, nopeutta ja virheettömyyttä. Tällainen käyttäjä voi olla esimerkiksi opettaja tai suunnittelija, joka useita kertoja kuukaudessa päivittää opiskelijoille arvosanoja. Vastaavasti toiminnoissa, joita käytetään harvemmin, painotetaan opittavuutta ja muistettavuutta. Esimerkkinä tällaisesta käyttäjästä käy opiskelija, joka käyttää palvelua ehkä vain muutaman kerran lukuvuodessa suunnitellessaan hopsiaan tai ilmoittautuessaan opintojaksojen toteutuksille. 3.1 Yhdenmukaisuus Elementtien yhdenmukaisuus sovelluksessa sisäisesti ja eri sovellusten välillä on keskeinen käyttöliittymien toteutusta ohjaava periaate. Ihminen muodostaa luontaisesti kuviomalleja näkemistään asioista, esimerkiksi jokaisen ihmisen kasvot ovat kuvio, joka noudattaa tiettyä mallipohjaa. Ihminen pystyy erottamaan tuhansia kasvoja toisistaan vilkaisulla, vaikka periaatteessa kasvot poikkeavat toisistaan hyvin pienellä marginaalilla. Vastaavalla periaatteella käyttäjä luo merkityksiä myös käyttöliittymien kuviomalleille. Koska aivot jatkuvasti rakentavat kuviomalleja, ne myös tallentavat eri merkityksiä niille. Ihminen oppii nopeasti esimerkiksi että hakulaatikko on oikeassa yläkulmassa verkkokäyttöliittymissä, koska on ennestään tottunut näkemään samantyyppisiä kuviomalleja. Vaikka ratkaisu tai toiminto olisi kuinka epätäydellinen, oppii käyttäjä tekemään sen suorittaessaan toiminnon samalla tavalla useasti. Hänen aivonsa muodostavat kuviomallin, jota käyttäjä seuraa toiminnan kontekstissa. Jos käyttöliittymän toiminnot ovat aina samalla tavalla toimivia, pystyy käyttäjä oppimaan helposti useita käyttöliittymiä. Jos taas toiminnot ovat hyvin erilaisia, käyttäjä joutuu luomaan uuden kuviomallin jokaisessa tilanteessa tehdäkseen oikean valinnan. Pahin tilanne muistamisen kannalta on, jos toiminnot eivät ole yhdenmukaisia, mutta niiden semanttinen sisältö, merkitys, on sama tai lähes vastaava. Tällöin käyttöliittymän toimintaperiaatteet menevät käyttäjällä täydellisesti sekaisin. Tehtäessä olemassa oleviin sovelluksiin muutoksia täytyy muistaa, että vaikka uusi ratkaisu olisi käytettävämpi kuin vanha, voi se tuottaa vanhoille käyttäjille ongelmia. 14

15 Tästä näkyy yhdenmukaisuuden ja ihmisen muistin voima; käyttäjät muistavat aikaisemman version toiminnan ja se häiritsee uudenlaista käyttöä. Mitä enemmän käyttöliittymä muistuttaa vanhaa, sitä varmemmin käyttäjä toimii vielä pitkään vanhasta käyttöliittymästä opittujen toimintatapojen mukaan. Tämän takia käyttöliittymän perusteellinen uudelleenrakentaminen on parempi ratkaisu kuin yksittäisten pienten toimintasarjojen korjailu Eri etenemismuotoja Käyttöliittymässä voidaan kulkea eri suuntiin, esimerkiksi vasemmalta oikealle tai ylhäältä alas. Tiptop-projektissa käyttöliittymissä kuljetaan pääsääntöisesti juuri näin. Vasemmalla käyttöliittymässä sijaitsevia tietoja tarkennetaan lisätiedoin tai niihin tehdään valintoja oikealle avautuvissa näkymissä. Esimerkiksi hopsissa vasemman palstan tutkintorakennepuuhun tehdään valintoja oikealle aukeavissa leijuvissa ikkunoissa. Vastaavalla tavalla toimitaan esimerkiksi opintojen vaiheittaisuuden kuvauksissa ja erilaisissa listauksissa (kuva) 3.2 Valitut käyttöliittymämallit ja tiedon visualisointitavat Lopullisessa käyttöliittymärakenteessa sovelletaan enimmäkseen lineaarista käyttöliittymärakennetta, puumallista hierarkian esitystapaa, kalanruotomaista timeline-navigaatiomallia sekä Moire Tree ja Zoomology -tyylistä alemmalle hierarkiatasolle mahdollistavaa zoomaus-tekniikkaa. Käyttöliittymätiimi tutki standardin valmisteluvaiheessa useita vaihtoehtoisia käyttöliittymien rakennemalleja ja tiedon visualisointitapoja. Mallit on kuvattu dokumentin liitteessä Oppijan käyttöliittymä Tiptop-portaalin oppijan käyttöliittymä koostuu etusivusta, hops-näkymästä, opintojen seurannan näkymästä sekä viestit-osioista. Etusivulla esitetään omalla palstallaan oppijan kalenterinäkymä sekä ajankohtaiset tiedotteet. Hops-näkymässä vasen puoli noudattaa klassista hierarkista puurakennetta. (kuva) 15

16 Hopsin oikean puoleinen näkymä on vastaavasti timeline-mallinen opintopolku ja lähemmäksi zoomatessa puumallinen opintopuu. Opintopolulle suunnitellaan ja ajoitetaan opintoja joko viemällä opinnot drag&drop-tekniikalla suoraan opintopolulle, tai määrittelemällä opintojen ajoitus valintakentissä. (kuva) Opintopolku esitetään horisontaalisessa muodossa niin, että opintojen eteneminen ja esittäminen tapahtuu vasemmalta oikealle. Opinnot tullaan sijoittamaan timelinelle suorakaiteen muotoisena palikkana, joka on sitä paksumpi mitä suurempi opintopistemäärä siihen sisältyy suhteessa suoritettuun ajanjaksoon. Opintojakso voi hajautua myös usealle eri aikajaksolle, jolloin opintojaksoa yhdistää laatikoiden välissä oleva nauha. Kun horisontaaliin timeline-ajatteluun yhdistää suorakaiteen muotoisten yksiköiden, tässä tapauksessa opintojen sijoittelun, muistuttaa käyttöliittymän oikean puolen näkymän alkuasettelu Gantt-tyylistä rakenteelta. Kun opintopuuta zoomaa opintopolullaan lähemmälle tasolle, polku muuttuu opintopolusta hierarkiseksi puumalliksi. Tässä mallissa ollaan hyödynnetty Moire Tree tyylistä visualisointimallia. Kun opinnon on zoomannut kaikista syvimmälle hierarkian tasolle, esitetään opinnon osa-suoritustavat Zoomology-tyylisenä kakkuna. (kuva) Oppijan käyttöliittymässä opintojen seurannan näkymä koostuu vasemman palstan opintosuorituslistauksesta ja oikean palstan etenemistä kuvaaviin graafeihin. Graafit ovat erityyppisiä diagrammeja, jotka kuvaavat oppijan etenemistä opintopolullaan valittuja vertailukohtia vasten. (kuva) Viestit-osion rakenne kuvataan tarkemmin standardiin, kun portaalin suunnittelussa on edetty riittävän pitkälle Ohjaajan käyttöliittymä Tiptop-portaalin ohjaajan käyttöliittymä koostuu etusivusta, ryhmäkohtaisesta koostenäkymästä, oppijan puolta vastaavasta hops-näkymästä, opintojen seurannan näkymästä, viesti-osioista sekä roolipohjaisesti esitettävästä arviointipalvelusta. Etusivulla on suunniteltu esitettävän vasemmalla palstalla kalenteri- ja tehtävänäkymät 16

17 sekä ohjausryhmäkohtaista yleistietoa. (kuva) Ryhmäkohtainen koostenäkymä sisältää suunnitelman mukaan taulukkomuotoisen yhteenvedon eri ohjausryhmien tilanteesta. Hops- ja opintojen seuranta -näkymät mukailevat oppijan puolella kuvattuja esitystapoja sillä poikkeuksella, että ohjaajalla on käytettävissään opintojen seuranta -osiossa useampia tapoja tarkastella oppijan tai oppijaryhmän etenemistä. (kuva) Arviointipalvelussa arvioitavien opiskelijoiden tiedot kootaan listaksi vasemmalle palstalle, ja oikealle avautuvassa ikkunassa syötetään tai valitaan kenttiin mm. arvosana-, laajuus- ja opettajatiedot. (kuva) 3.3 Käytettävät termit Koko palvelussa pyritään käyttämään yleismaailmallista kieltä, vältetään vain tietyn ryhmän käytössä olevia termejä. Käytettävää terminologiaa ohjaa osaltaa korkeakoulujen tietomallin (XDW) käyttämä terminologia. Käyttöliittymässä käytetään mahdollisimman lyhyitä ja yksinkertaisia sanoja. Tekstisisällön tulee olla yksinkertaista kieltä, ei monimutkaisia tai pitkiä lauseita eikä vieraskielisiä termejä. Vältetään myös laajoja kuvauksia, pyritään esittämään asiat tiivistetysti. 3.4 Peruutus / uudelleensuoritus Aina sen ollessa mahdollista tulisi käyttäjälle tarjota mahdollisuus peruuttaa suoritettu toiminto. Käyttöliittymä, jossa peruutettavuus on helppoa, rohkaisee käyttäjää kokeilemaan erilaisia käyttö- ja työtapoja. Peruutettavuus toteutetaan sellaisilla toiminnoilla kuin "Peruuta" (Undo) tai "Palaa tallennettuun versioon" (Revert to saved). Lisätään Olet nyt lähettämässä AHOT-hakemusta kurssista x, oletko aivan varma? - tyyppisiä vahvistuksia tilanteisiin, joissa opiskelija on lähettämässä ns. peruuttamatonta tietoa. Pakotetaan käyttäjä näin varmistamaan ja vahvistamaan lähetettävät tiedot. 17

18 Joihinkin tilanteisiin voidaan tarjota myös esikatselutoimintoa, eli annetaan käyttäjän katsoa lähetettävää tietoa vastaanottavan osapuolen näkökulmasta. Tämä voisi olla hyvä tarjota esimerkiksi sellaisiin tilanteisiin, joissa tekeillä olevaa asiaa ei voi peruuttaa. Jos käyttäjän tekemää komentoa ei voi peruuttaa ja siitä seuraa tallentamattoman tiedon menettäminen, on siitä ilmoitettava käyttäjälle. Tällaisessa tapauksessa käytetään varoitusikkunaa. 3.5 Lokalisaatio Suomi, ruotsi ja englanti ovat palvelun viralliset kielet. Projektin aikana toteutetaan ainakin suomi-versio. Projektin jälkeen jatkokehitysvaiheessa tulee täten ainakin ruotsija englanti-versiot. Suunniteltaessa käyttöliittymää on otettava huomioon, että myös vieraskieliset tekstivastineet mahtuvat painikkeisiin ja toimintokuvauksiin. Suomi-kieliversiossa ajan kuvaus sovelluksissa tehdään suomalaiseen malliin eli malliin pp.kk.vvvv. Sama toimii suurimmassa osassa maailmaa, joten euroopan sisällä toimiessa sama esitystapa voi olla englanninkielisessä versiossa. Ainoa suuri ryhmä, joka esittää ajan kk.pp.vvvv-mallin mukaan, on amerikkalaiset. Tämä tulee ottaa huomioon, jos sovellusta aiotaan kohdentaa amerikan markkinoille. Jos sovellusta aiotaan suunnata monikansalliseen levitykseen, tulee harkita ajan kuvauksen esittämistä englanninkielisessä versiossa niin, että kuukaudet kirjoitetaan joko kokonaan auki tai lyhennettyinä (Jan, Feb, Mar, Apr jne.) Desimaalien erotteluun tulisi voida käyttää sekä pilkkua että pistettä. Järjestelmä tulee siis tukea kumpaakin. Pilkun käytön mahdollistaminen edesauttaa näppäimistön oikeassa laidassa sijaitsevan numeronäppäimistön (numpad) sujuvan käytön käsiteltäessä numeraalista tietoa. 4 Esteettömyys 4.1 Mitä esteettömyys on? Käsittettä esteettömyys (engl. accessibility) käytetään usein kertomassa tuotteen tai palvelun yhdenvertaisesta ja helposta lähestyttävyydestä. Palvelun esteettömyys ei koske ainoastaan rajoitteisia erityisryhmiä, vaan myös tavanomaisista poikkeavien laitteiden käyttäjiä. Esteettömyyden arviointi eroaa käytettävyyden arvioinnista mm. siten, että käytetyt esteettömyyden tarkistuslistat eroavat käytettävyyden heuristiikkalistoista. Itse arviointi on kuitenkin hyvin samankaltaista. Tärkeimpiä esteettömyysohjeita: 18

19 Rakenne: tee sivu sellaiseksi, että se alusta loppuun luettuna on toimiva, mm. tärkeimmät asiat ovat ensin. Kieli: käytä yksinkertaisinta kieltä, jonka sisällön luonne sallii. Tekniikat: käytä yksinkertaista ja loogista HTML-merkkausta, ja virittele ja sommittele ulkoasu ensisijaisesti CSS:llä. Pidä huolta, että tekniikat ovat standaradinmukaisia. Linkit: nimeä linkit sisältöä kuvaaviksi, ei esimerkiksi "klikkaa tästä". Multimedia: tarjoa kaikelle kuva-, ääni-, video- yms. aineistolle tekstivaihtoehto. Taulukot: huolehdi, että taulukot ovat mielekkäitä myös riveittäin luettuina. Ohitettavuus: tarjoa mahdollisuus ohittaa ne aineistot, jotka voivat olla esteellisiä, kuten isot taulukot. Huomionarvoista on myös se, että erilaisilla erityisryhmillä ja eri käyttötilanteissa on myös erilaisia tarpeita: Sokeat (tai heikkonäköiset) voivat käyttää Internetiä esimerkiksi ruudunlukuohjelman avulla tai erityisellä laitteella (pistenäyttö) joka muuttaa tekstin pistekirjoitukseksi. Jos sivua ei ole vähintäänkin tehty HTML-suositusten mukaisesti validiksi, ei lukuohjelma osaa välttämättä lukea tietoa oikein. Tämän todentamiseen käytetään validaattoria. Myös web-sivuihin upotetut kuvat ovat sokeille hankalia. Tämän takia kuvien tietosisältö tulisi ilmaista vaihtoehtoistekstien (käytännössä HTML:n alt-attribuutti) avulla. Heikkonäköiset ihmiset saattavat käyttää sivustoa suurella tekstikoolla tai ruudunsuurennusohjelmaa käyttäen. Sivun on toimittava myös näissä tilanteissa. Monipalstaisen sivun seuraaminen voi olla ruudunsuurennusohjelmaa käyttävälle hankalaa. Kuurot tai huonokuuloiset ihmiset eivät välttämättä kykene havaitsemaan merkkiääniä tai kuulemaan videoiden ääniraitaa. Liikuntavammaiset eivät välttämättä kykene käyttämään hiirtä lainkaan. Siksi sivun on oltava käytettävissä myös pelkällä näppäimistöllä. Ei toteuteta näin projektin aikana. Rinnakkaisen käyttöliittymän toteuttaminen vaatii toiminnallisuuksien muokkaamista esteettömiksi, tai kokonaan korvaavien toiminnallisuuksien suunnittelua. Työmäärä riippuu vahvasti korvattavien toimintojen monimutkaisuudesta. Varsinaisen ohjelmointityön määrä riippuu toteutettavista toiminnoista, mutta sen voi olettaa olevan alhaisempi kuin alkuperäisen käyttöliittymän vaatima, sillä esteetön käyttöliittymä on todennäköisesti paljon yksinkertaisempi. 19

20 Kognitiivisista (ymmärrykseen ja oivaltamiseen liittyvistä) ongelmista kärsivät tarvitsevat selkeitä ja ytimekkäitä sivuja, joissa on paljon kuvia, kuvaajia ja listoja selkeyttämässä asiaa. Esteettömyyden arvioinnissa olisi edullista, mikäli käytettävissä olisi ainakin yleisimpien esteellisten käyttäjäryhmien edustajia. (Vastaavasti kuin käytettävyyden arvioinnissa.) Valitettavasti parhaallakaan esteettömyyssuunnittelulla ei voida ottaa huomioon yksilöllisiä esteellisyyden tasoja, eikä yhdellä versiolla voida kattaa jokaisen erikoisryhmän tarpeita, mutta täyttämällä eritasoisia vaatimuksia voidaan esteettömyyttä yleisellä tasolla merkittävästi lisätä. Projektissa olisi edullista toteuttaa ainakin W3-konsortion esteettömyysvaatimusten A- taso, sillä jos tätä tasoa ei toteuteta, joidenkin ryhmien on mahdotonta käyttää sivua. Seuraavassa on lyhyesti esitelty kyseinen vaatimuslista: 4.2 A-tason esteettömyysvaatimukset (WCAG 2.0) 1 Havaittavuus 1.1 Tekstivastineet: Tarjoa tekstivastineet kaikelle ei-tekstuaaliselle sisällölle siten, että sisältö voidaan muuttaa muihin tarvittaviin muotoihin, kuten isokokoiseksi tekstiksi, pistekirjoitukseksi, puheeksi, symboleiksi tai yksinkertaisemmaksi kieleksi. 1.2 Aikasidonnainen media: Tarjoa vastine aikasidonnaiselle medialle. 1.3 Mukautuvuus: Tuota sisältöä, joka voidaan esittää eri tavoin (esimerkiksi yksinkertaisemman asettelun avulla) informaatiota tai rakennetta menettämättä. 1.4 Erottuvuus: Helpota käyttäjiä näkemään ja kuulemaan sisältö lisäämällä taustasta erottuva etuala. 2 Hallittavuus 2.1 Saavutettavuus näppäimistöllä: Toteuta kaikki toiminnallisuus siten, että se on käytettävissä näppäimistöltä. 2.2 Tarpeeksi aikaa: Anna käyttäjille tarpeeksi aikaa lukea ja käyttää sisältöä. 2.3 Kohtaukset: Älä suunnittele sisältöä tavalla, jonka tiedetään aiheuttavan sairauskohtauksia. 2.4 Navigoitavuus: Tarjoa käyttäjille tapoja navigoida, etsiä sisältöä ja määrittää sijaintinsa. 3 Ymmärrettävyys 3.1 Luettavuus: Tee tekstisisällöstä luettavaa ja ymmärrettävää. 3.2 Ennakoitavuus: Tee verkkosivuista sellaisia, että niiden ilmiasu ja toiminta ovat ennakoitavissa. 20