Arkipäiväisessä käytössä tietokoneohjelman näkyvin osa on sen käyttöliittymä. Sovellusten käyttäjät hyödyntävät tietojärjestelmän suomia palveluita käyttöliittymäksi kutsutun rajapinnan kautta. Käyttöliittymiä on monenlaisia riippuen sovelluksesta ja käyttötarkoituksesta. Yksinkertaisimpia käyttöliittymiä näkee esimerkiksi joukkokulkuvälineiden matkakortin lukijalaitteissa, joissa ei ole juuri kuin pieni näyttö ja muutama painike. Monipuolisimmillaan käyttöliittymät ovat vaikkapa tietokoneissa, joissa käyttäjä voi käyttää useita erilaisia sovelluksia samanaikaisesti. Kaikille käyttöliittymille on kuitenkin yhteistä jonkinasteinen ihmisen ja koneen välinen vuorovaikutus. Tarkkaan ottaen myös koneet keskustelevat keskenään, jolloin varsinaista näkyvää käyttöliittymää ei välttämättä tarvita. Tällöin puhutaan rajapinnasta, joka on tietyt vaatimukset täyttävä käyttöliittymä toiselle tietojärjestelmälle.

Ihmisille tarkoitettujen käyttöliittymien ulkoasu vaihtelee laidasta laitaan. Mikrotietokoneiden sovelluksista löytyy sekä helppokäyttöisiä että vaikeaselkoisia käyttöliittymiä. Toisinaan sovellusta on helppoa ja miellyttävää käyttää, kun käyttöliittymän ominaisuudet tukevat käyttäjää ja hänen ennakkokäsityksiään. Joskus vastaan saattaa tulla ohjelma, jonka käyttö on vaikeaa ja monimutkaista. Käyttöliittymien käytettävyyteen on graafisten järjestelmien myötä alettu kiinnittää yhä enemmän huomiota. Taakse alkavat jäädä nopeasti kyhätyt tekijänsä näköiset käyttöliittymät ja tilalle on tulossa enemmän käyttäjäläheisempiä sovelluksia. Käyttöliittymien suunnitteluunkin on kehitetty vuosien varrella erilaisia menetelmiä ja prosessimalleja. Erilaiset suunnittelumallit, kuten GUIDe ja UMLi yrittävät parhaansa mukaan luoda tehokkaita ja tuottavia menetelmiä käyttöliittymien suunnitteluun.

HUIMA-malli

Olen vuosien mittaan kehitellyt omaa suunnittelumallia, johon olen ottanut parhaita paloja muista malleista sekä aimo annoksen projektien mukanaan tuomaa kokemusta. Pitkän mietinnän jälkeen päätin nimetä prosessimallini HUIMA-malliksi. Akronyymi on muodostettu englannin kielen sanoista Hectic User Interface Modeling Algorithm. Tarkalleen ottaen kyseessä ei ole algoritmi vaan prosessimalli eikä menetelmäkään ole aivan sananmukaisesti hektinen vaan oikeastaan nopea. Päädyin kuitenkin näihin sanoihin, jotta lyhenteestä tulisi tietojenkäsittelytieteen alalle tyypillinen koominen ja helposti muistettava lyhennesana. Muita ehdokkaita olivat muun muassa RUIMA (Rapid User Interface Modeling Algorithm) ja QUIPP (Quick User Interface Planning Process). Valitsinpa minkä tahansa nimen mallilleni oli tärkein sanoma viestittää nopeasta käyttöliittymän suunnittelumenetelmästä.

HUIMA-suunnittelumalli tukee nopeaa sovelluskehitystä (RAD) sekä ketteriä menetelmiä, sillä valmiiseen käyttöliittymään saavutaan usean iterointikierroksen jälkeen. Jokaisella kierroksella suunnitelma jalostuu ja tarkentuu alkaen erittäin korkean ja karkean tason mallista päätyen aivan pienimpäänkin yksityiskohtaiseen metodiin. Iterointeja voidaan joutua suorittamaan useita riippuen siitä, miten tarkalla tasolla kunkin kerroksen haluaa kuvata. Menetelmän tuloksena syntyy varsinaisen käyttöliittymämallin lisäksi dokumentaatio, joista tärkein on käyttöliittymän rakentamiseen tarkoitettu työohje (Design Guide). Työohje sisältää tarkat ohjeet käyttöliittymän toteuttamiseksi. Ohjeissa luetellaan käyttöliittymän eri osat, miten käyttöliittymä koodataan sekä lopuksi tyyleihin liittyvät yksityiskohdat, joista tyypillisesti syntyy esimerkiksi nettisovelluksen tyylisivut (Cascading Style Sheets).

Suunnitteluprosessi tai minun tapauksessani siis algoritmi sisältää eri vaiheita. Vaiheet ovat kuin sipulinkuoria, joita voidaan kuoria uloimmasta kuoresta kohti sisustaa. Tämä kuvaa samalla menetelmän tapaa aloittaa yleiskuvasta ja porautua vähitellen yksityiskohtiin. HUIMA-mallin käyttö edellyttää vaatimusmäärittelydokumenttia. Koko prosessi alkaa nimittäin vaatimusmäärittelystä, joka on itse asiassa koko sovelluskehityksen perusta. Oheisessa aktiviteettikaaviossa (kuva 1) on esitetty HUIMA-suunnittelumallin päävaiheet. Käytän tässä artikkelisarjassa esimerkkinä kuvitteellista blogisovellusta. Tämän yksinkertaisen ohjelman vaatimuksiin kuuluu uusien blogimerkintöjen kirjoitus, kommenttien käsittely, sivujen laatiminen ja järjestelmän hallinnointi.

Vaatimusmäärittelystä käyttötapauksiin

Tietojärjestelmän suunnittelu alkaa vaatimusmäärittelystä. Työn tuloksena syntyy määrittelydokumentti, jossa on kuvattu tuleva järjestelmä ja sille asetetut toiminalliset ja ei-toiminalliset vaatimukset. Vaatimusmäärittely ei suoranaisesti kuulu HUIMA-prosessiin, vaan on paremminkin syöte prosessille. Kattavasta vaatimusmäärittelystä johdetaan HUIMA-prosessia varten käyttötapaukset karkealla tasolla. Tavoitteena on laatia ns. sivukartta, jossa on lueteltu eri käyttötapausten vaatimat sivut. Mikäli toteutettava järjestelmä ei ole nettisovellus, korvautuu sivukartta eri näyttöjen luettelolla. Molemmissa tapauksissa käyttötapaukset kuvitellaan toteuttavaksi eri sivuilla tai näytöillä. Esimerkiksi blogisovelluksessa artikkelin kirjoitus muodostaa yhden sivun ja kommenttien ylläpito toisen sivun. Nämä ovat samalla kaksi suuren luokan käyttötapausta, jotka löytyvät vaatimusmäärittelystä. Käyttötapaukset käsitellään käyttöliittymäsuunnittelua varten karkealla tasolla, sillä tässä vaiheessa ei pureuduta käyttötapausten yksityiskohtiin. Blogiartikkelin kirjoituksessa on luonnollisesti lukuisia pienempiä käyttötapauksia, jotka eivät vielä tässä vaiheessa ole kiinnostavia, sillä HUIMA-malli etenee vaiheittain tarkemmalle tasolle.

Jos vaatimusmäärittelydokumentti on laadittu huolellisesti, on suuret kokonaisuudet todennäköisesti koottu eri lukujen alle. Näistä luvuista voi periaatteessa jo johtaa käyttötapaukset karkealla tasolla ja samalla alkaa hahmotella seuraavassa vaiheessa syntyvää sivukarttaa. Tärkeää on kuitenkin edetä aluksi kokonaiskuvasta (big picture) alkaen ja jättää yksityiskohdat myöhempiin iterointikierroksiin. Blogisovelluksen määrittelystä voidaan johtaa esimerkiksi seuraavia suuria käyttötapauskokonaisuuksia:

• blogimerkintöjen esitys,
• blogimerkintöjen kommentointi,
• blogimerkintöjen haku arkistosta,
• blogimerkintöjen käsittely,
• kommenttien käsittely,
• sivujen käsittely ja
• järjestelmän hallinnointi.

Blogimerkintöjä eli artikkeleita voidaan esittää monella tavalla, mutta ensimmäisellä iterointikierroksella riittää tunnistaa vain ylipäätään tarve näyttää merkintöjä sivulla. Seuraavassa vaiheessa tarkennetaan, mitä erilaisia tapoja on esittää blogin kirjoituksia. Tällaisia käyttötapauksia ovat esimerkiksi blogimerkintöjen esitys etusivulla ja yksittäisellä artikkelisivulla.