Tämänkertaisen blogin aihe on yksinkertaisesti: Vältä täysin tarpeetonta työtä ja saa siistimpi lopputulos rakentamalla sovelluksesi webbikäyttöliittymä noin satasen maksavaa valmista mallipohjaa käyttäen. Kaikkihan tekevät näin, eikö niin?

Artistin näkemys

Ensimmäiset asiakkaille näytettävät hahmotelmat sovelluksen toimintaperiaatteista perustuvat usein “artistin näkemykseen” tulevasta käyttöliittymästä. Kuva on lähes kaikille helpompi ymmärtää kuin satasivuinen vaatimusmääritys, tietokantataulukaavio tai arkkitehtuuripiirros. Visuaalisesti miellyttävä kuva sovelluksen toiminnoista on hyvä keskustelun apuväline.

Artisti luo ensimmäiset hahmotelmat usein “photoshoppaamalla” syöttökenttiä ja muita käyttöliittymäelementteja satunnaisesti valitun, juuri sillä hetkellä saatavilla olevan sivupohjan päälle. Vaikka käyttöliittymän esittelijä vilpittömästi kertookin kuvan olevan ainoastaan hahmotelma, visuaalinen esitys palaa kiinni katsojan verkkokalvoon ja mielikuviin, ja alkaa elämään samantien omaa elämäänsä. Yleisön silmissä hahmotelma muuttuu todellisuudeksi: “Tämä tulee olemaan täsmälleen se, miltä valmis sovellus tulee näyttämään”. Alle tunnissa katsojat alkavat ehdottamaan photoshop-käyttöliittymän ulkonäköön liittyviä parannuksia: “Voisiko tuo väri olla punaisempi? Tuossa pitäisi olla enemmän marginaalia. Meidän logo on kyllä liian pieni.”

Kustannusansa on viritetty. Kun varsinainen koodaustyö alkaa, nähty visualisointi on täsmälleen se, mitä asiakas tulee vaatimaan. Koodaaja avaa tyhjän notepadin, ja alkaa etsimään verkosta toiminnallisuuden toteuttavia komponentteja, hieman samankaltaisia mallisivuja asetteluineen ja tyylitiedostoja joista voi ottaa mallia. Näistä löydöksistä pyritään raapimaan kasaan jotain mahdollisimman samankaltaista, mitä asiakas on nähnyt. Ei näin – Mikäli tavoite ei ole ainoastaan maksimoida asiakkaalta laskutettavat tunnit.

Oikea tapa

Ota pieni istunto asiakkaan kanssa ennen visualisointien näyttämistä. Miltä käyttöliittymä pitäisi tuntua, ja miten sen perusperiaatteet toimivat. Kerro asiakkaalle asia niinkuin se oikeasti on: Valitsemalla ensin silmää miellyttävä ja toiminnallisuuksiltaan sopivan käyttöliittymän mallipohja, säästämme merkittävästi rakennuskustannuksissa, sekä saamme tähän sovellustyyppiin tarvitut toiminnallisuudet ja “parhaat käytännöt” automaattisesti mukaan.

Mallipohjan valinta

Valmistaudu vierailemalla mieleisessäsi teemakaupassa, esimerkiksi Themeforest-sivustolla. Jos olet rakentamassa line-of-business sovellusta, katso Admin templates osasto. Jos asiakas haluaa verkkokaupan, vieraile e-commerce osastolla. Sivustolta löytyy mallipohja lähes jokaiseen käyttötarkoitukseen, valitse juuri sinun tapaukseen sopiva osasto ja mallipohja.

Mallipohjat noudattavat sovellustyyppinsä parhaita käytäntöjä: Esimerkiksi verkkokaupan mallipohjat sisältävät kaiken sen, mitä ihmiset ovat tottuneet verkkokaupalta odottamaan: Nätti etusivu, tuotelistaus, tuotekategoriat, yksittäisen tuotteen sivu, ostoskori, tilaussivu jne. Admin – mallipohja sisältää kaiken, mitä liiketoimintasovellukselta aina vaaditaan: Hakuruudut, käyttäjäprofiilit, mallit formien tekemiseen, kalenterit, käyttäjänotifikaatiot, graafit jne. Joudut joka tapauksessa rakentamaan nämä ominaisuudet, joten mikset ottaisi niitä valmiina?

Kiinnitä myös huomiota siihen, kuinka suosittu malli on (latausten määrä), ja kuinka kauan mallin tekijä on ollut olemassa. Nämä ovat paras saatavilla oleva takuu sille, että malli tulee todennäköisesti ainakin lähitulevaisuudessa saamaan vielä päivityksiä.  Muutama esimerkki (eivät toki ainoat) ovat Metronic line-of-business sovelluksille, tai vaikkapa Avada e-commerce/sekakäyttöön.

Valitse muutama sopiva vaihtoehto, ja näytä teeman valmisdemo(t) asiakkaallesi. Miltä teema yleisesti näyttää, miltä sillä toteutetut lomakkeet tuntuvat, mitä toiminnallisuuksia saadaan valmiina, voiko teeman värejä muokata helposti, ja onko muita rajoitteita. Tämän jälkeen asiakkaalla on oikea mielikuva: “Tältä sovellus suurinpiirtein tulee lopulta näyttämään, ja näiden asioiden käyttöliittymät löytyy valmiina. Seuraavaksi alamme lisäämään omaa sisältöä valmiiseen mallipohjaan”. Asiakasta miellyttänee myös teeman avulla saatu kustannus- ja ajansäästö. Jos visuaalinen demo on oltava valmiina jo ennenkuin kauppa on tehty (RFI, tarjouspyyntö), niin valitse teema parhaan oman arvauksen mukaan, ja käytä teemaa jo ensimmäisessä pienessä visualisoinnissa – ajatusmalli kohdalleen heti alusta asti.

Sitten protoilemaan!

Kunhan yleinen tyyli (=teema) on sovittu, voit päästää html/css/js- ja UX-sankarit töihin. Protojen rakentamisessa käytetään heti alusta alkaen teemaa ja sen valmiina tarjoamia ominaisuuksia, huomioiden teeman asettamat rajoitteet. Teemaa voi pakkotilanteessa laajentaa omilla komponenteilla. UX-suunnittelija voi toki halutessaan käyttää rautalankamallejaan, mutta varmempi lähestymistapa olisi tässäkin käyttää teemaa ja sen komponentteja törmäyksien ja väärinymmärrysten välttämiseksi.

Mitä jäi käteen?

En oikein keksi perustetta, miksi en käyttäisi valmisteemoja ja niiden valmiiksi yhteensovitettuja komponentteja sovelluksen käyttöliittymän pohjana. Joutuisin joka tapauksessa rakentamaan/raapimaan kasaan omin kätösin verkosta samat toiminnallisuudet. Varsinkin kun teeman hinta on tyypillisesti enintään sata euroa. Ja teeman on tehnyt hivenen paremmalla graafisella silmällä varustettu graafikko kuin minä. Eikö niin?

Vasta-argumentit

Jos teeman ylläpito (tai oikeammin sen mahdollinen puute) huolettaa, maailmalta löytyy myös vain tähän toimintaan keskittyneitä yrityksiä ja ammattimaisesti valmistettuja ja tuettuja komponenttikirjastoja, joilla voit rakentaa oman sovelluksesi. Hintalappu on näissä kuitenkin aivan toinen. Pienen (tai edes keskisuuren) projektin budjettiin nämä harvemmin mahtuvat. Esimerkkeinä telerik, Infragistics ja devexpress.

Toinen yleinen lähestymistapa on haalia tarvittavat mallit asetteluineen, navigoinnit sekä tarvittavat komponentit yleisistä netin opensource-lähteistä (näitähän teemakin lopulta käyttää!). Tai kierrättää edellisen projektin malleja. Saattaa kuulostaa järkevältä, mutta ero on siinä, että teema on valmiiksi koherentti – teema on käytännöiltään ja ulkoasultaan valmiiksi yhdenmukainen (värit, asettelu, marginaalit), ja sen komponentit toimivat yhteen. (Vrt. esim. millä jquery-versiolla mikäkin opensource-kilkutin toimii, pystyyko komponentin sovittamaan tähän värimaailmaan ja asetteluun jne). Teema on jo valmiiksi testattu, yhdenmukainen ja toimii. Senkun alat käyttämään.

Helpota elämääsi, käytä mallipohjia!