’Form follows Function’ – Amerikkalainen arkkitehti Louis Sullivan lausui nuo kuuluisat sanat 1896 ja samalla tuli luoneeksi perustan funkkis-tyylille. Ajatus oli että rakenteiden tuli olla kestäviä, käytännöllisiä ja kauniita. Se, että turhat koristeet oli karsittu pois, ei tarkoittanut että rakennukset olisivat olleet rumia ja esteettisesti luotaantyöntäviä. Päinvastoin. Sama ajatus pätee myös toimivaan käyttöliittymään. Etenkin kun toimitaan insinöörirajapinnassa, täytyy kehityksen lähtökohtana olla ajatus, että simulaattorin toiminnallisuus on keskiössä. Tällöin sovelluksen käyttö on robustia simulaattorin huomioidessa kaikki mahdolliset eri käyttötilanteet, samalla kuitenkin näyttäytyen käyttäjälle selkeänä ja esitellen kulloinkin tarvittavat toiminnallisuudet ilman tulkinnan varaa.
Käytäntö on osoittanut että monimutkaisissakin järjestelmissä käyttäjä tyytyy käyttämään vain kourallista niistä ominaisuuksista mitä on tarjolla. Miksi siis näyttää edes näitä kaikkia vaihtoehtoehtoja tai saati käyttää kallista ohjelmointiaikaa näiden kaikkien harvoin käytettävien toimintojen tekemiseen? Tästä päästään yhteen suosikkisääntööni eli Pareton 80/20-periaatteeseen. Suhdeluku ei tietenkään ole näin tarkkaan rajattu, mutta tässä kohdin kehitystä on aina syytä kysyä: Mitkä ominaisuudet tarvitaan välttämättä ja mitkä ominaisuudet olisivat kivoja olla olemassa? Käytäntö on jälleen kerran osoittanut sen, että ne ominaisuudet jotka määritellään välttämättömiksi ovat myös niitä joita oikeasti käytetään, kun taas nämä ’olisi kiva olla’ -ominaisuudet jäävät usein käyttämättömiksi tai sitten esiintyvät ainoastaan markkinointimateriaaleissa. Kun tämä jumppa tehdään huolellisesti projektin alussa on myös kustannuksissa mahdollista säästää huomattavasti kun keskitytään niihin 20% toiminnallisuuksista joilla katetaan yli 90% kaikista käyttötilanteista, samalla pitäen käyttöliittymän selkeänä ja helposti omaksuttavana.
Erikoistapauksia tulee aina esiintymään, mutta onko näitä kaikkia heti järkevään toteuttaa sovellukseen asti? Ei ehkä ensimmäisen asiakaspyynnön jälkeen, mutta toisen ja kolmannen tapauksen tullessa eteen voi olla syytä pohtia uuden ominaisuuden lisäyksestä.
– Muoto noudattaa toiminnallisuutta –