Vieraskynä: Windows 8 -sovellus verkkopalvelun käyttöliittymänä – case Valio Reseptit

Artikkelissa tehdään katsaus Valio Reseptit -sovelluksen suunnitteluun ja toteutukseen Windows 8 -käyttöjärjestelmälle. Erityishuomiota projektissa kiinnitettiin kosketuskäyttöliittymän tuomiin suunnitteluhaasteisiin ja sovelluksen suorituskyvyn varmistamiseen. Sovellus nojaa Valio.fi -verkkopalvelun rajapintoihin, ja tarjoaa näin käyttäjille vaihtoehtoisen käyttöliittymän verkkopalvelun keskeisimpiin sisältöihin.

Kirjoitin toukokuussa 2011 Vieraskynä-artikkelin Valio.fi–verkkopalvelun uudistusprojektista. Tuossa hankkeessa yksi keskeinen tavoite oli luoda verkkopalvelu, joka paitsi seisoisi tukevasti omilla jaloillaan, olisi samalla myös alusta muille mahdollisille palveluille. iPhone-sovellus julkaistiinkin pian itse saitin jälkeen, ja nyt vuorossa oli Windows 8 –sovellus.

Valion Windows 8 -sovellus

Valio.fi-verkkopalvelu on suunniteltu käytettäväksi modernilla selaimella, ja siitä on myös erillinen mobiiliversio valio.mobi. Kesällä 2012 päätettiin ryhtyä toteuttamaan reseptiselailuun keskittyvää sovellusta Windows 8 –alustalle. Kohteena olivat nimenomaan tabletit ja muut kosketusohjattavat Windows 8 –laitteet. Motivaatiota sovelluksen tekemiseen kuvaa parhaiten Valion digimarkkinoinnista vastaava Jussi-Pekka Erkkola: “Halusimme Valiolla lähteä kokeilemaan erilaista laajennusta verkkopalvelullemme ja –sisällöillemme. Uskomme Windows 8 –tabletien löytyvän tulevaisuudessa myös useiden suomalaisten kotikokkien keittiöstä.”

Tavoitteena oli luoda sovellus, joka jatkaisi saitin visuaalisesti houkuttelevaa linjaa, ja tekisi uusien reseptien löytämisen ja kokeilemisen helpoksi. Erityisesti tablettikäytössä kiinnostava on ajatus reseptien esillä pitämisestä nimenomaan ruoanlaittokäytössä. Läheskään koko valio.fi:n toimintovalikoimaa sovellukseen ei haluttukaan: yksinkertaisella on hyvä lähteä, ja sovellusten helppo päivitettävyys tekee paloittain kehittämisestä houkuttelevaa. Näistä syistä esimerkiksi oma keittokirja ja kauppalistatoiminnot päätettiin jättää ulos sovelluksesta.

Saitin toteutusprojektin tapaan konseptoinnista huolehti Valve Branding, ja Offbeat Solutions veti ja toteutti projektia Appelsiini Finlandin avustuksella. Projekti aloitettiin kesä-heinäkuussa, ja sovelluksen ensiversio julkaistiin Windowsin Storeen syyskuun lopussa. Ja onneksi Erkkola jatkaa: “Olemme hyvin tyytyväisiä Valio Reseptit -applikaation ensimmäiseen Windows 8 -versioon.”

Kosketuskäyttöliittymää tekemässä

Melko harvalla webin vääntäjällä on kokemusta kosketusohjatun käyttöliittymän suunnittelusta. iOS-appsien kermasta kosketuskokemuksensa ammentaneelle ajatus oman sovelluksen suunnittelusta tuntuu enimmäkseen helpolta, niin kuin parhaiden sovellusten käyttäminenkin tuntuu. Mutta kuten yleensä, kepeän käytettävyyden takana on raskasta suunnittelua ja päinvastoin.

Microsoftille täytyy antaa pisteet kahdesta asiasta: Ensinnäkin Windows 8 –käyttöliittymien periaatteet on sekä suunniteltu että kuvattu erittäin hyvin. Ohjemateriaalia riittää, ja iso osa siitä on ihan laadukastakin – kunhan vain saa tekemissuuntautuneen sielunsa motivoitua opiskeluun.

Toisekseen kosketuskäyttöliittymän teknisestä toteuttamisesta on tehty suurin piirtein niin suoraviivaista kuin siitä nyt järkevästi voi tehdä. Kosketuseleiden tunnistamista ja kohdentamista ei tarvitse juuri miettiä.

Kasin käyttöliittymä tarjoaa joukon hyviä valmiita ratkaisumalleja, mutta niiden soveltaminen omaan käyttöön haastaa suunnittelijan. Esimerkiksi laajoille listauksille suositellaan toteutettavaksi ns. semanttinen zoom, joka mahdollistaa pitkän listan tarkastelun ryhmiteltynä, visuaalisesti tiiviimmässä muodossa. Hyvä idea, mutta millainen esitystapa missäkin näkymässä toimii?

Yllä Valio Reseptit –sovelluksen etusivu “zoomattuna ulos” – siis supistettuna kategorioiksi. Alakuvassa taas sama etusivu ilman zoomia, vaakasuunnassa vierivänä listana.

Entä kun käyttäjä “snappaa” sovelluksen pieneksi, 320 pikseliä leveäksi palstaksi näytön reunaan? Kätevä toiminto mahdollistaa kevyen kahden tehtävän moniajon tablettiympäristössäkin, mutta millainen asettelu on käyttökelpoinen 320 pikselin leveydessä?

Kuvassa Valion sovellus snapattuna näytön vasempaan reunaan. Lopun näyttöpinnan täyttää selain, jolla voi vaikka hakea lisätietoja ruoanlaiton tueksi.

Snapattu sovellus on aina 320 pikseliä leveä, mutta voi olla kummalla puolella tahansa. Jäljelle jäävään tilaan voi avata minkä vain sovelluksen.

Oma kysymyksensä on näytön pistetiheyden vaihtelu. 1920×1080-resoluutio kannattaa täyttää 24” näytöllä aivan eri tavalla kuin jos kysymys on kymmeneen tuumaan puristetun HD-tabletin näytöstä. Windows 8 tukee tätä erottelua todella hyvin, mutta miten näihin kaikkiin eri tilanteisiin kannattaa suunnitella? Entäpä jos näyttö on pystysuorassa?

Kuvassa Valion sovelluksen etusivunäkymä 2560×1440 –työpöytänäytöllä.

Vastaavia kysymyksiä on paljon, ja erilaisia taittoja kertyy. Suunnittelijan urakka tietysti helpottuu muutamassa kuukaudessa, kun Windows Storeen kertyy tuhansia hyviä ja huonoja malleja – muotokielen eri variaatiot tulevat helposti näkyville. Projektia aloitettaessa valmiita sovelluksia ei montaa kymmentä ollut, joten vaikutteita oli haettava lähinnä demosovelluksista. Niissä vain harvemmin on riittäviä datamääriä kunnolliseen käytännön testailuun.

Vähän kerrassaan käyttöliittymä kuitenkin löysi muotonsa, ja iso kiitos siitä kuuluu Valvelle: jos suunnittelija olisi lähtenyt vääntämään käyttöliittymää iOS-opeilla saati sitten web-pohjalta, eihän siitä mitään olisi tullut. Nyt kun kaikki osapuolet perehtyivät muotokielen spekseihin, kommunikaatio ja iterointi oli varsin jouheaa.

Pohjana rajapinnat

Verkkopalvelun asiakasliittymänä toimivan sovelluksen on saatava yhteys kotipesäänsä. Yksinkertaisimmillaan tarvittava rajapinta voi olla vaikkapa RSS-feedi, mutta useimmiten tarvitaan jotain monimutkaisempaa. Meillä hyvä ennakkosuunnittelu maksoi itseään takaisin, sillä toteutimme jo alkuperäisen verkkopalveluprojektin yhteydessä OData-muotoon pohjautuvat rajapinnat tiedonhakuun. OData tarjoaa sekä suht’ luettavaa ATOM-formaattia että kompaktia JSONia, joista jälkimmäisellä päädyimme siirtämään reseptidatan palvelimelta clientille. Sovellukseen upotettujen videoiden takia käytämme myös YouTuben APIa.

Tiedonsiirron tekeminen itsessään ei ole kovinkaan kivuliasta tai työlästä. Hyvän käyttökokemuksen takaaminen vaati kuitenkin enemmän miettimistä: miten paljon dataa siirretään missäkin vaiheessa?

Teknisillä tempuilla päästiin siihen, että kerran vuorokaudessa päivitettävä reseptidata pieneni kolmeen megatavuun. Tämän jälkeen pohdintaa vaativat reseptikuvat, jotka tietysti välimuistitetaan päätelaitteeseen. Mutta onko tehokkaampaa hakea kaikista kuvista yksi isompi versio ja tehdä skaalaukset asiakaspäässä – omalla clientilla sen voi tehdä hyvin laadukkaastikin – vai hakea kuva eri versiona eri käyttötilanteisiin, jolloin selailu toimii nopeammin?

Reseptikuvien kokonaismassa oli selailunäkymien pienessäkin koossa noin 40 megatavua, ja reseptisivujen isomman kuvakoon vaatimat kuvat olisivat olleet jo päälle sadan megan pläjäys. Kun osa laitteista käyttää verkkoa 3G-yhteydellä, ei tällaisten tietomäärien siirtäminen sovelluksen käynnistyessä oikein tullut kyseeseen.

Niinpä päädyttiin hakemaan kuvia sitä mukaa kuin tarvitaan, ja kaikki haettu materiaali pidetään paikallisessa välimuistissa. Kuvia haetaan kolmessa koossa, joista skaalataan muut tarvitut näkymät. Sovellusta voi käyttää myös ilman internet-yhteyttä – tällöin käytetään välimuistissa olevia kuvia, jos niitä suinkin on.

Verkkoyhteyksien ja rajapintojen käyttöä voi optimoida lähes rajattomasti. Windows 8 kertoo sovellukselle, jos käyttäjä on 3G-vierasverkossa (roaming) tai jos hän maksaa verkkoyhteydestään siirtomäärän mukaan. Tällöin sovellus voi optimoida tiedonsiirtonsa näiden tietojen mukaan. Jälleen kerran: teknisesti helppoa, mutta mikä palvelee parhaiten käyttäjää?

Sertifiointi ja julkaisuprosessi

Microsoftin sovelluskaupan sertifiointiprosessi muistuttaa Applen vastaavaa. Ennen sertifiointia kehittäjä ajaa työasemallaan tekniset tarkastukset, jolloin teknisten perusvikojen (liian hidas käynnistys, väärin tehty paketointi tms.) osalta palautteen saa saman tien, ilman odotusta. Kauppaan lähetetyn sovelluksen katselmointi kestää joitain päiviä, ja sinä aikana Microsoft tarkastaa myös sovelluksen sisällön soveltuvuuden ja käytännön toimivuuden.

Meillä oli ennen sertifiointia pieniä epäilyksiä siitä, mahtavatkohan ne siellä oikeasti suomenkielisiä softia tarkastella. Mutta kyllä näin mitä ilmeisimminkin käy, sillä ensimmäinen versio palasi bumerangina pikapuoliin: olivat osanneet navigoida videoihin ja todenneet, etteivät ne heillä toimineet. Tämä johti meidän kannaltamme hankalaan tilanteeseen, kun ongelma ei toistunut meillä millään keinolla.

Tässä kohtaa paljastuukin niin Windowsin kuin Windows Phonenkin kauppasertifiointien pahin ongelma: palautteen laatu ei ole kovin hääviä. “Videos do not seem to be functional” ei lopulta auta kovastikaan kehittäjää, joka on huolella yrittänyt sovelluksensa testata, eikä saa ongelmaa millään toistumaan. Tämä videomysteeri saatiin kierrettyä, mutta ei vieläkään kokonaan ratkaistua.

Toivoa sopii, että Microsoft onnistuu kehitettämään sertifiointiprosessistaan interaktiivisemman ja läpinäkyvämmän. Tällä hetkellä se on kiistatta Windows 8 –ohjelmoinnin epämiellyttävin kohta. Alustan eduksi täytyy tosin sanoa, että sertifiointikriteerit on määritelty melko yksityiskohtaisesti ja yksikäsitteisesti, joten kehittäjällä on kohtalaiset mahdollisuudet ymmärtää ja jopa ennakoida saamaansa sertifiointipalautetta.

Windows 8 ympäristönä

Kun sovellus viimein päätyy Storeen, sen käytöstä saa koko joukon mielenkiintoisia tilastoja: Kuinka moni kopioi sovelluksen? Millaiset ihmiset sitä käyttävät ja missä päin maailmaa? Kuinka kauan päivässä? Valion sovellus on vielä sen verran nuori, että näistä tilastoista on liian varhaista vetää mitään johtopäätöksiä sen paremmin keittiötablettikäytön yleisyydestä kuin Windows 8:n menestyksestäkään.

Kuvassa Storen tarjoamia tilastonäkymiä ajalta ennen Windows 8:n julkaisua.

Joka tapauksessa telemetria antaa hyvää pohjaa sovelluksen kehittämiselle. Kehittäjälle erityisen hyödyllistä on se, että sovelluksessa tapahtuneet virheet siirtyvät myös kehittäjän tarkasteltavaksi, jolloin tavanomaisia kaatumistilanteita voi korjailla ilmankin, että käyttäjät edes suoranaisesti raportoivat niistä.

Uudessa Windowsissa on omia erikoisuuksiaan: esimerkiksi reseptihaku tehdään Windowsin yleisellä hakutoiminnolla, joka vain kohdentuu oletuksena nimenomaan valitun sovelluksen aineistoon. Ratkaisussa on paljon hyvää, mutta käyttäjä tietysti etsii ensin hakutoimintoa sovelluksen käyttöliittymästä, ei Windowsin valikosta. Samaten esiin pyyhkäistävät sovelluskohtaiset toimintovalikot ovat yllätyksiä vanhaan Windowsiin tottuneelle, käyttipä sitten näppäimistöä, hiirtä tai kosketusohjausta.

Sovelluskauppa ja sertifiointikäytännöt kannustavat voimakkaasti luottamaan siihen, että Microsoft opettaa kyllä käyttäjät Windows 8:n tavoille. Kehittäjää tietysti huolettaa toimintojen piilottaminen näkymättömiin valikoihin. Aika näyttää, miten kasi rupeaa käyttäjiltä sujumaan.

On hyvä idea sijoittaa haku kaikissa sovelluksissa samaan paikkaan, mutta milloin käyttäjät oppivat pyyhkäisemään hakutoiminnon esiin oikealta?

Projektista opittua

Windows 8 –sovelluksen tekeminen oli opettavainen kokemus kaikille projektiin osallistuneille. Ensimmäistä versiota voi hyvällä omallatunnolla kutsua valmiiksi, mutta tiimin hampaankoloon jäi monta toteuttamatonta kehitysideaa. Optimoitavaa olisi rajattomasti – aina suorituskyvystä, isojen resoluutioiden taitoista ja tiedonsiirtomääristä alkaen. Projektiin kuluneita työtunteja ei kukaan täsmälleen laskenut, mutta pelkkä tekninen toteutus kasvoi varmastikin sadan henkilötyöpäivän luokkaan. Toisaalta iso osa tehdystä perehtymistyöstä ei myöskään päätynyt tämän sovelluksen hyödyksi, olihan kyseessä yleisempi alustaanperehtymishanke.

Sovelluksen “oikeaa työmäärää” on vielä näin vähäisellä kokemuksella mahdotonta luotettavasti arvioida. Osaavalta talolta on kuitenkin selvästi jatkossa lupa odottaa varsin paljon toteutusta muutaman kymppitonnin budjetilla.

Tämä sovellus tehtiin käyttäen C#-kieltä ja XAML-pohjaista taittoa, mutta sovelluksia voi vääntää myös HTML5/CSS/JavaScript-yhdistelmällä. Käyttöjärjestelmän tarjoama ominaisuusvalikoima ja kaikki mahdollisuudet ovat samat. Tämä ei tarkoita sitä, että vanhan Windowsin XAML-gurun kyvyt kelpaisivat suoraan, tai että webbiveteraani voisi välttää opiskelun. Kohtuullisella pohjaosaamisella täyttyy kuitenkin uuden alustan tärkein kriteeri: kehittäjä voi enimmäkseen keskittyä suunnitteluhaasteisiin. Karmeita viime metrien tunkkauskokemuksia toki nähtiin tässäkin, mutta seuraavan projektin osalta toivoa on jo paljon enemmän. :-)

Tulemme julkaisemaan projektista vielä tarkempia teknisiä tarinoita. Linkit niihin laitamme ainakin Facebook-sivullemme. Ja kuten viimeksikin, vastaamme mielellämme kysymyksiin tämän kirjoituksen kommenttiosuudessa. Haluamme vielä lopuksi esittää kiitoksen kumppaneillemme Appelsiinille ja Valvelle – ja tietysti ennen muuta Valiolle, jonka ennakkoluulottomuus ja avoimuus mahdollistivat sekä projektin teon että tämän tarinan kertomisen.

Valio Reseptit Windowsin sovelluskaupassa