Käyttökokemus ratkaisee – panosta siihen fiksusti

Verkkopalveluiden muutospaineet keskittyvät usein ulkoasuun ja toiminnallisuuteen. Kuluttajakaupassa rahaa ei tehdä tietorakenteilla ja taustajärjestelmillä, vaikka ne ovatkin kriittinen osa kokonaisuutta.

Jos kauppa ei tao verkossa tulosta, kutsuu järkevä asiakas paikalle tuskan määrästä riippuen joko palvelumuotoilijan tai käyttöliittymäsuunnittelijan. Verkkopalvelun pintaa sitten hierotaan, kunnes sen käyttökokemus on kohdillaan ja kassavirta kasvaa toivotulle tasolle.

Käyttöliittymä ja taustajärjestelmä erillään

Perinteinen ohjelmistokehitysmalli kytkee käyttöliittymän ja sen taustajärjestelmän tiukasti toisiinsa. Jos toiseen koskee, joudutaan muokkaamaan toistakin. Tuplatyö on hidasta ja molemmat pitää tietenkin testata huolellisesti, jotta homma ei karahda karille heti palvelun julkaisun jälkeen. Kehityksen hitaus ja kalleus summaa oivasti sen, minkä takia usein tyydytään keskinkertaiseen käyttökokemukseen eikä palveluihin uskalleta koskea enää julkaisun jälkeen.

Meidän ratkaisumme on erottaa käyttöliittymä ja taustajärjestelmä erillisiksi kokonaisuuksiksi, jotka kuitenkin pelaavat yhteen. Näin vältämme tuplatyön, kehitystyö sujuu näppärästi eikä korkea hintalappu säikäytä asiakasta. 

Suunnittelu ja toteutus yhdessä

Suunnittelu on projektin tärkein osuus, jossa tekniikka ja tunteet nidotaan yhteen. Näin syntyy loppuasiakkaan käyttökokemus. Kuten kaikki myyjät tietävät, on kaupanteko myös tunnepeliä. Siksi positiivinen erottautuminen perusverkkokaupasta tai ajanvarausjärjestelmästä palkitaan varmasti. Meillä designerit ovat aina osa toteutustiimiä, sillä projekteja toteutetaan ketterästi vaiheittain ja tiivis kommunikaatio koodaajaporukan kanssa on välttämätöntä.

Tekniikan kehittymisen myötä käyttöliittymien suunnittelu ja toteutus on erikoistunut omaksi taiteenlajikseen, ja niinpä meilläkin on monia siihen erikoistuneita osaajia.

Käyttöliittymän toteutustekniikka valitaan aina asiakastarpeen mukaan. Frontend-puolella pinnalla olevat tekniikat vaihtuvat viikoittain ja muotivirtausten huipulla pysyminen on kallista ja turhauttavaa. Onkin järkevää valita vakiintuneita ja luotettavia ratkaisuja, jotka todennäköisesti ovat tuettuja vielä parinkin vuoden päästä.

Taustajärjestelmänä käytämme useimmiten Drupalia sen joustavuuden ja valmiiden komponenttien takia. Drupal on laajoihin kokonaisuuksiin tarkoitettu avoimen lähdekoodin sisällönhallintajärjestelmä.

Se on helppo saada keskustelemaan muiden asiakkaan käytössä olevien järjestelmien, kuten autentikointipalveluiden, tilausjärjestelmien tai markkinointiautomaatiosoftien kanssa. Valmistuote taustajärjestelmänä säästää aikaa ja mahdollistaa keskittymisen käyttökokemuksen kehittämiseen. Palvelu saadaan nopeasti markkinoille, minkä jälkeen sen käyttökokemusta on helppo viilata käyttäjiltä saadun palautteen perusteella.

Onko palvelusi käyttöliittymä myyvä?

Kuluttaja käyttää palveluita onnellisen tietämättömänä taustajärjestelmän hienouksista. Hän on kuitenkin yhä vaativampi ja valikoivampi palveluiden tarjoaman kokemuksen suhteen. Yhä useammin juuri palvelun käyttökokemus ratkaisee, ostaako kuluttaja vai ei. Jos ostoaie ei realisoidu, voimme yhdessä asiakkaamme kanssa kehittää käyttöliittymää myyvemmäksi aiempaa helpommin ja nopeammin.

Ota yhteyttä ja kerro meille haasteistasi, niin etsitään niihin yhdessä ratkaisut.

Drupalgeddon 2 – bugi ja kuinka se korjattiin

28.3.2018: “Kriittinen haavoittuvuus Drupal -sisällönhallintaohjelmistossa. Päivitä viipymättä!”

Eräänä kevättalvisena iltana ohjelmistokehittäjämme Jasper Mattsson selaili työpäivänsä päätteeksi Drupal-julkaisujärjestelmän uusimman version lähdekoodia perehtyäkseen sen ominaisuuksiin ja selvittääkseen, kuinka päivityksen tuomia ominaisuuksia voisi hyödyntää omassa työssään sekä tutkiakseen samalla järjestelmän mahdollisia haavoittuvuuksia.

“Homma lähti siitä, että halusin opetella Drupal kasia. Luin sen lähdekoodia läpi ja aloin miettiä, että voisivatko jotkin asiat aiheuttaa tietoturvaongelmia. Sitten aloin etsimään ja purkamaan muutamaan eri asiaan liittyviä ongelmia. Tässä vaiheessa minulla ei ollut edes Drupalia asennettuna tätä varten – kaikki etsiminen tapahtui lähdekoodia lukemalla.”

Kokeneelle ohjelmistokehittäjälle muiden kirjoittaman koodin tutkiminen on rutiininomainen keino tutkia, kuinka muut ovat ratkaisseet tiettyjä ongelmia ja siten syventää myös omaa osaamistaan. Käytäntöä voisi verrata minkä tahansa teknisen laitteen purkamiseen ja erillisten osien sekä niiden välisten kytkentöjen tutkimiseen. Yleensä osia ja kytkentöjä – tässä tapauksessa koodia – tutkimalla ei löydy juuri käytännön pikkuniksejä ihmeellisempää, mutta tuona iltana tilanne oli toinen.

Bugi löytyy

“Kiinnitin huomiota tapaan, jolla joissain lomakkeissa käsiteltiin käyttäjän syöttämiä arvoja ja aloin sen perusteella etsiä kohtia, joissa tästä voisi seurata tietoturvaongelmia.”

Jasper huomasi, että ohjelmointivirheen avulla Drupal oli mahdollista saada käsittelemään käyttäjän lomakkeelle syöttämiä arvoja ohjelmakoodina. Tämän avulla hyökkääjä voi esimerkiksi ajaa omaa haittakoodiaan Drupalissa. Näin on esimerkiksi onnistuttu asentamaan kryptovaluuttojen mainaukseen tarkoitettuja ohjelmia palvelimelle sivuston ylläpitäjän tietämättä. Hyökkäyksiä tehdään automatisoidusti – hakkeroidut sivustot valjastetaan hyökkäämään muihin päivittämättömiin sivustoihin. Ovelimmat automaattisista hyökkäyksistä asentavat Drupaliin tietoturvapäivityksen päästyään sisään, jotta kilpailevat hyökkääjät eivät pääse palvelimelle.

Itse bugiin liittyi kaksi puolta; vahingollisen syötteen saaminen Drupaliin sisään ja se, että Drupalin sai suorittamaan sen koodina. Mikäli satunnainen lähdekoodia tutkiva henkilö olisi löytänyt vain toisen näistä ongelmista, hän ei välttämättä olisi ajatellut kyseessä olevan tietoturvaongelma. On varsin todennäköistä, joskin täysin spekulatiivista, että molemmat yksittäiset ongelmat ovat olleet joidenkin toimijoiden tiedossa, sillä haavoittuvuus oli ehtinyt ollut Drupalissa ainakin vuonna 2011 julkaistusta 7-versiosta lähtien, sekä mahdollisesti jossain muodossa jo vuonna 2008 julkaistussa Drupal 6:ssa. Kahden satunnaisen pikkuongelman havaitsemisen lisäksi erityisen ratkaisevaa tässä tapauksessa oli kuitenkin ongelmien välisten syy-seuraussuhteiden ja niiden yhdessä muodostaman riskin vakavuuden ymmärtäminen.

Korjaustoimenpiteet

Ensimmäisestä huomion herättäneestä havainnosta bugiepäilyn vahvistamiseen kului aikaa vain muutamia tunteja. Ongelman havaittuaan Jasper raportoi bugin Drupalin tietoturvatiimille ja ilmoitti havaintonsa tueksi esimerkkitilanteen (Proof of Concept), jossa haavoittuvuus oli hänen koneellaan ilmennyt. Tarvittavien tietojen raportoimiseen kului aikaa muutama päivä, tosin esimerkkitilanteen toistamisessa oli alkuvaikeuksia.

Hyvin pian vapaaehtoisista ja luotettaviksi todetuista Drupal-kehittäjistä koostuva tietoturvatiimi pääsi kuitenkin tekemään korjauksia. Myös Jasper osallistui niiden testaamiseen, mahdollisten uusien aukkojen etsimiseen ja korjausehdotuksiin liittyvään keskusteluun.

“Drupalin tietoturvatiimi kehitti korjauksia nopealla tahdilla ja hyvällä yhteistyöllä – keskustelun ja korjauksien testaamisen tahdissa ei meinannut pysyä mukana”.

Kehittämiseen vierähti muutama viikko ja useampi iteraatiokierros ennen kuin päivitys oli saatu riittävälle tasolle julkaisua varten.

Kun tietoturvatiimillä oli aukko tiiviisti tilkittynä, he tiedottivat korjauspäivityksen julkistamisajankohdan. Tässä vaiheessa itse haavoittuvuuden yksityiskohdat pidettiin luonnollisesti vielä tiukasti salassa ja kerrottiin vain, että kyseessä on kriittinen tietoturva-aukko. Myös päivitysversion korjaukset koordinoitiin ja toteutettiin siten, ettei päivityksen koodista pystyisi helposti päättelemään mistä tietoturva-aukko tarkemmin löytyisi.

Välttämättömät korjaukset paikkaava päivitys julkaistiin pääsiäistä edeltävänä keskiviikkona 28.3. jolloin Druidilla sekä muissa Drupal-taloissa oltiin valmiudessa päivittämään sivustot. Drupal.org kaatui hetkellisesti suuren kävijämäärän vuoksi kehittäjien ladatessa sivua uudelleen malttamattomina.

Ennen päivitystä pelättiin, että päivityksen perusteella saattaisi huolellisista varotoimista huolimatta olla mahdollista päästä tietoturva-aukon jäljille ja että sitä hyödyntävää haittakoodia voisi olla tarjolla hyvinkin pian päivityksen julkaisun jälkeen. Näin oli käynyt ensimmäisen Drupalgeddon-haavoittuvuuden kanssa vuonna 2014. Ensimmäiset haavoittuvuutta käyttävät hyökkäykset huomattiin kuitenkin vasta 11.4., joten sivustojen ylläpitäjillä oli lähes kaksi viikkoa aikaa päivittää sivustonsa.

Mikäli sivustosi jäi Drupalgeddonin jalkoihin tai tarvitset luotettavaa kumppania pitämään huolta verkkopalveluistasi, ota meihin yhteyttä!

Kuinka visualisoida sprintin tila JIRAssa?

Valittu projektimalli on usein ratkaisevassa asemassa projektin onnistumisen kannalta. Siksi me Druidilla vannomme ketteryyden ja Scrumin nimeen. Scrum edellyttää, että kaikki tehtävä työ kasataan yhteen paikkaan, jotta sitä voidaan hallinnoida järkevästi. Vaikka tämä onnistuisi ihanan hipsteristi seinällä ja paperilapuilla, olemme päätyneet käyttämään insinöörimäisempää JIRA-projektinhallintaohjelmistoa. Se mikä hipsteriydessä hävitään, voitetaan monin verroin takaisin erilaisilla näkymillä, kattavalla raportoinnilla ja muilla hyödyllisillä ominaisuuksilla.

Vakioasetuksilla JIRA luo Scrum-projektille kaksi näkymää: backlog-näkymän sekä näkymän aktiiviseen sprinttiin. Lisäksi työnkulku on yksinkertaisesti mallia “To Do → In progress → Done”. Monille tämä riittää…vai riittääkö? Testataanpa.

Backlog-näkymässä luodaan tarinoita, annetaan pisteet, kasataan sprintti ja käynnistetään se. Tarinoille lisätään (tekniset) alitehtävät. Toistaiseksi kaikki on kunnossa. Näkymä vaihdetaan aktiivisen sprintin puolelle. Otan yhden tarinoista tekoon. Näen helposti, mitä alitehtäviä tarinalla on ja missä tilassa ne ovat. Yksi kerrallaan alitehtävät valmistuvat, kunnes kaikki on tehty. Story on valmis!

Eipäs kun hetkinen… Pitäähän valmistunut tarina kierrättää vertaisarviossa, jotta työn tekninen laatu voidaan varmistaa. Ja toki tuoteomistaja haluaa tarkastaa erillisessä testausympäristössä, että tarinan vaatimukset täyttyvät ennen hyväksymistä. Hmm… Pitäisikö näistä tehdä erilliset alitehtävät? Jokaiselle tarinalle? Kuulostaa toistuvalta käsityöltä.

Oikea ratkaisu on noudattaa hyvän ohjelmistoarkkitehtuurin kultaista sääntöä: luo mallinnettava kokonaisuus järjestelmän tarjoamilla ominaisuuksilla, jolloin järjestelmä “ymmärtää”, mitä olet tekemässä. Tässä tapauksessa tarkoituksena on mallintaa tarinoiden matka alusta loppuun, joten ensimmäinen askel on laajentaa JIRA-projektin työnkulku kattamaan kaikki mahdolliset vaiheet. Tarvittavat askeleet vaihtelevat projekteittain. Tässä yksi esimerkki:

• Sprint Backlog (Kehitystyötä ei aloitettu)
• In progress – Frontend (Frontend-kehitystyö käynnissä)
• In progress – Backend (Backend-kehitystyö käynnissä)
• Development Done (Kehitystyö valmis)
• Peer Review & Deployment (Toisen kehittäjän vertaisarviointi)
• Acceptance testing (Tuoteomistajan hyväksymistestaus)
• Done (Story tehty ja hyväksytty)

Tässäkin asiassa kannattaa toimia ketterästi. Ensimmäinen versio tehdään parhaan tiedon mukaan ja sen jälkeen vaiheita muutetaan saadun kokemuksen perusteella. (Pro tip: Projektin workflowksi kannattaa valita “Simplified Workflow”, jolloin muutosten tekeminen on helpompaa.)

Kun työnkulku on kunnossa, tehdään taikuuksia näkymille. Aktiivisen sprintin näkymän tulee edelleen toimia kuin aiemminkin, jotta kehittäminen sujuu mahdollisimman helposti. Siksi näkymässä ei tarvita kuin neljä ensimmäistä askelta (Sprint Backlog–Development Done). Sen lisäksi luodaan uusi näkymä, joka kulkee meillä nimellä Review. Review-näkymän tehtävänä on näyttää sprintin tila yhdellä silmäyksellä sekä mahdollistaa työn käsittely tarinatasolla, jota putken loppupäässä tarvitaan. Lisäksi haluamme niputtaa ensimmäiset neljä askelta (Sprint Backlog–Development Done) yhteen sarakkeeseen nimeltä Develop, sillä siellä työskennellään alitehtävien parissa ja nyt olemme kiinnostuneita itse tarinoista.

Katso tarkemmat asennusohjeet videosta:

Lopputuloksena tarinoiden kulku on mallinnettu JIRAan, eikä niiden tiloja tarvitse enää arvuutella tai muistella. Lisäksi kaikkien – jopa projektin ulkopuolisten tahojen – on helppo tarkistaa, miten sprintti menee.

Visualisointi auttaa myös hahmottamaan pullonkauloja: jos esimerkiksi nähdään, että tarinoita kertyy jatkuvasti vertaisarviointisarakkeeseen, kehitysprosessia tulee muuttaa vertaisarviointia suosivaan suuntaan. Poikkeuksia tapahtuu, mutta jatkuvat sumat kielivät yleensä puutteellisesta prosessista. Onneksi Scrumiin sisäänrakennetuissa retrospektiiveissä asia voidaan nostaa esille ja korjausehdotusta on helppo lähteä kokeilemaan. Näkymät näyttävät suoraan, onnistuiko kokeilu vai ei.

Pari tunnettua ongelmaa:

– Sprintin päätteeksi tarinat ovat Done-tilassa, mutta niiden alitehtävät jäävät Development Done -tilaan. Ennen sprintin sulkemista alitehtävät on käytävä siirtämässä Done-sarakkeeseen. Homman voi hoitaa kerralla kaikille alitehtäville etsimällä ne Issue Navigatorilla ja muuttamalla tila Bulk edit -työkalulla. Korjauksen voi myös hoitaa ohjelmallisesti JIRAn omalla skriptikielellä, mutta emme ole vielä menneet niin pitkälle.

– Review-näkymässä pitää erikseen painaa Only stories -filtteri päälle. Jos klikkailu ärsyttää, pikaratkaisuna näkymän voi lisätä selaimen kirjanmerkkeihin ja tuoda kirjanmerkkityökaluriville. Me kehittäjät käytämme Grease Monkey -skriptejä, jotka ohjelmallisesti lisäävät oikeanlaiset linkit selaimiimme.

Kuntien avoin verkkopalvelualusta – todistetusti toimiva

Viime syyskuussa Turun kaupunki kertoi avaavansa verkkopalvelunsa lähdekoodin yhteiseen käyttöön. Turku siis päätti antaa kehittämänsä alustan veloituksetta kaikkien hyödynnettäväksi ja jatkokehitettäväksi. 

Koodin avaamistyö saatiin nyt alkuvuodesta päätökseen, eli muiden kuntien on nyt mahdollista ottaa turku.fi-lähdekoodiin perustuva avoin verkkopalvelualusta käyttöönsä. Kiinnostus alustan hyödyntämiseen onkin jo herännyt varsin monen kunnan suunnasta!

Turun kaupunki on tehnyt todella uraauurtavaa työtä kehittäessään laajan ja pitkäikäisen verkkopalvelualustan monine hyödyllisine toiminnallisuuksineen. Alusta on vakaa ja skaalautuva, ulkoasultaan räätälöitävä, helppokäyttöinen ja saavutettava. Se on myös responsiivinen, eli se toimii mobiileissa päätelaitteissa.

Miten tähän pisteeseen on tultu?

Turun kaupunki halusi onnistua sivustouudistuksessaan, ja siitä rakentuikin hieno tarina. Täydet pisteet Turun kaupungin rohkeille päättäjille erilaisesta kilpailutuksesta, joka johti verkkopalvelun toteutukseen ketterällä monitoimittajamallilla. Onnistunut hankinta ja toimittajayhteistyö valittiinkin Blue Arrow Awards -kilpailun finalistiksi kategoriassa ”Epic Purchasing”. 

Turku.fi-projekti aloitettiin loppuvuodesta 2014. Jo puolen vuoden päästä julkaistiin ensimmäinen versio uudesta sivustosta. Kehitystyötä jatkettiin ja kuntalaisten palautteisiin reagoitiin koko projektin ajan – esimerkiksi esteettömyyttä parantava isompi päivitys julkaistiin kesällä 2016. Ketterin menetelmin toteutettu projekti oli menestys, mutta sitäkin merkittävämpi uutinen oli kehitetyn alustan julkaisu yhteiseen käyttöön.

Olemme olleet alusta alkaen mukana rakentamassa turku.fi-verkkopalvelua yhtenä Turun kolmesta teknisestä kumppanista ja luonnollisesti myös mukana koodin avaamistyössä. Meille on kunnia olla mukana rakentamassa tätä kokonaisuutta, joka mahdollistaa entistä parempien ja monipuolisempien verkkopalveluiden rakentamisen erittäin kustannustehokkaasti.

Miksi alusta on merkittävä mahdollisuus kunnille?

“No onhan näitä alustoja nähty aiemminkin, ei toiminut”, skeptikko ehkä tuumii. Tämä on totta. Mikä siis tekee tästä verkkopalvelualustasta erilaisen? Onnistunut turku.fi-uudistus oli jo sinänsä lupaava lähtökohta. Turun kaupungin hankejohtaja Päivi Saalasto valottaa alustan tuomia hyötyjä seuraavasti:

“Turku.fi-lähdekoodi tarjoaa hyödyntäjälleen win-win-tilanteen: täydellisen vapauden vähäisemmin kustannuksin. Jokainen voi poimia luodusta paketista vain haluamansa toiminnot ja järjestää verkkopalvelun ylläpidon parhaaksi katsomallaan tavalla. Samaan aikaan kuitenkin yhteisiä toiminnallisuuksia voidaan jatkokehittää tiiviissä yhteistyössä muiden kanssa jakaen syntyvät kulut.”

Alustan vahvuudet ovat moninaiset. Tässä niistä muutamia:

• Laatu. Suomen ykkösluokan Drupal-talot ovat olleet kehittämässä alustaa.
• Riippumattomuus toimittajasta. Alustalla on jo tässä vaiheessa useita sitoutuneita teknisiä toimittajia, sekä Turku.fi-projektissa mukana olleita että projektin ulkopuolisia Drupal-taloja.
• Toimivuus. Alusta on testattu ja todistettu käytännössä toimivaksi.
• Tietoturva. Alusta on tietoturva-auditoitu.
• Laaja käyttö. Käyttäjäyhteisön laajuus takaa alustan nopean kehityksen.

Pilotointia Porissa

Porissa innostuttiin jo hyvin varhaisessa vaiheessa Turun kehittämän alustan hyödyntämisestä, minkä johdosta heidän verkkouudistuksensa sai varsinaisen lentävän lähdön: syntyi ensimmäinen POC (proof of concept), jonka yhdessä Porin kaupungin kanssa toteutimme.

Pilottihankkeen tavoitteena oli varmistaa alustan tekninen soveltuvuus Porin tarpeisiin, toimiva ja helppokäyttöinen sisällönsyöttö sekä rakenteen joustavuus muuttuville tarpeille. Vaikka hanke aloitettiin jo ennen avoimen alustan julkaisuversion valmistumista, tulokset olivat vakuuttavia. Turun alustan todettiin tarjoavan toimivan ratkaisun Porinkin tarpeisiin ja se otettiin ilolla vastaan. Alustan helppokäyttöisyys kirvoitti jopa aplodit koulutuksessamme, jossa perehdytimme sisällönsyöttäjiä alustan käytön saloihin.

Porin pilotin valmista perustoteutusta laajennettiin vielä kattavalla hakumoottorilla, jonka jälkeen kaikki tekniset linjaukset olivat kasassa tulevaa sivustouudistusta varten. Yhteistyömme Porin kanssa jatkuu avoimen kilpailutuksen suunnittelulla, jonka tavoitteena on löytää Porille oikeat yhteistyökumppanit, joiden avulla turku.fi-lähdekoodi saadaan palvelemaan Porin sähköisen asioinnin ja viestinnän uusia ja tulevia tarpeita.

Mahdollisuus jatkokehittää huolella suunniteltua ja toteutettua verkkoalustaa sekä uudenlaiset yhteistyömahdollisuudet kuntien välillä saivat Porin kiinnostumaan Turun alustasta. Tietohallintojohtaja Heikki Haaparanta näkee yhteiskehittämisessä huimasti potentiaalia:

“Vaikka kunnissa ja niiden tarjoamissa palveluissa on paljon eroavaisuuksia, on niissä kuitenkin myös paljon yhteneväisyyksiä. Tämä yhteinen palvelurakenne ja lukuisat muut yhtäläisyydet palveluiden tuottamisessa tarjoavat mahdollisuuden yhteistyöhön, jakamiseen ja eri kuntien jo tekemän työn hyödyntämiseen. Projektimme valmistuttua tavoitteena onkin julkaista myös turku.fi-pohjalta rakennettu pori.fi-lähdekoodi avoimeksi. Näemme, että parhaimmillaan verkkoalustan ympärille muodostuu kuntien yhteistyöverkosto, joka jakaa avoimesti alustaan liittyviä kokonaisuuksia ja osaamista.”

Suomessa on yli 300 kuntaa, joiden on KaPa-lain velvoittamina uudistettava verkkopalvelunsa. Nyt Turku tarjoaa kuin hopeatarjottimella auttavan käden kaikille Suomen kunnille. On helppo nähdä alustan ympärille muodostuneen avoimen lähdekoodin ekosysteemin kasvavan ja laajentuvan modulaariseksi kuntien digipalveluiden työkalupakiksi. 

Haluatko tietää lisää?

Tietoa Turku.fi -alustan sisällöstä: Kuntien avoin verkkopalvelualusta
Turun tiedote: Turku.fi:n lähdekoodi kiinnostaa jo monia
Alusta on saatavilla Turun GitHub-tilillä 
Turun digitaalisen kehittämisen blogi

Yläkuva: “Porin Eteläranta” / Jukka Peura / CC BY 2.0

Sulava käyttökokemus uudella teknologialla

Lääkärikeskus Aava on yksi asiakkaistamme, jolla on erittäin korkeat vaatimukset palveluidensa käyttäjäkokemukselle. Pystyäksemme vastaamaan näihin odotuksiin kustannustehokkaasti, on tärkeää että käytössämme on palveluiden rakennusvaiheessa moderneimmat mahdolliset työkalut. Onneksemme Aava on ollut koko yhteistyömme ajan sitoutunut päivittämään teknologiaa uudempaan. Näin Aavallekaan ei ole aiheutunut turhan suuria kertakustannuksia järjestelmien päivittämisestä. 

Tavoitteena yhtenäinen käyttökokemus

Loppuvuodesta 2016 asetimme Aavan kanssa tavoitteeksi yhdistää heidän eri palveluidensa frontend-ratkaisut, jotka on toteutettu eri taustajärjestelmillä. Nykytilanteessa kaikissa järjestelmissä on perinteiseen tapaan oma käyttöliittymänsä, mikä on järjestelmien kasvamisen myötä tehnyt ylläpidosta haastavampaa. Siitä huolimatta, että olemme hyödyntäneet moderneja työkaluja nykyisten järjestelmien rakentamiseen, työ joudutaan käytännössä aloittamaan aina alusta joka järjestelmässä. Palveluiden käyttökokemuksen kehittäminen ei myöskään ole mahdollista äärettömiin, koska järjestelmät näyttävät keskenään hyvinkin erilaisilta.

Lähdimme liikkeelle Aavan Terveytesi-palvelun rakentamisesta. Projektin tavoitteena oli luoda nopeasti uusi palvelu, josta asiakas pystyy helposti hakemaan tietoja terveydestään, kuten vaikkapa diagnooseja ja ajanvarauksia.

Miksi päädyimme Reactiin?

Palvelun rakentaminen edellytti muutoksia olemassa olevaan arkkitehtuuriin. Jotta kehitystyö olisi pitkällä tähtäimellä kustannustehokasta, päätimme, että kaikkien ennen arkkitehtuuriuudistusta tehtävien toiminnallisuuksien on oltava käytettäviä uudessakin arkkitehtuurissa. Tämän vuoksi päädyimme keskittämään suurimman osan ajasta toimivien rajapintojen muodostamiseen. Tässä projektissa oli luonnollista luoda selaimessa toimiva sovellus, koska palvelu ei vaatinut paljoa business-logiikkaa rajapintojen ulkopuolella.

Ember.js sekä React.js valikoituivat arvioitaviksemme, koska näistä tiimiläisillä oli aikaisempia hyviä kokemuksia. Aluksi pyrimme arvioimaan, kumman järjestelmän tuominen nykyiseen arkkitehtuuriin olisi helpointa, mutta totesimme vertailun olevan melko hankalaa, sillä kumpikaan ei tuntunut täyttävän vaatimuksia, jotka alkuvaiheessa asetimme. Niinpä päädyimme vertailemaan yhteisöjen kokoja ja millä tavoin järjestelmiä on käytetty. Lopulta valitsimme Reactin, koska uskoimme sen olevan pitkällä tähtäimellä paremmin tuettu.

Miten projekti sujui?

Uuden teknologian käyttöönotto tuo aina mukanaan haasteita. Tässä projektissa haasteena oli ennen kaikkea se, miten moderni teknologia yhdistetään Aavan jo olemassa olevaan infrastruktuuriin sekä ohjelmistoihin, vaikka kokonaisuus sinänsä olikin jo ennestään moderni. Lisäksi kaikilla tiimimme jäsenillä ei ollut aiempaa kokemusta modernista JavaScriptistä (es2016+). Mutta mehän pidämme haasteista, joten huolehdimme projektin aikana siitä, että kaikki tiimiläiset saivat yhtäläiset valmiudet kehittää projektia.

Aavan olemassa olevaa infrastruktuuria on pidetty ajan tasalla koko yhteistyömme ajan, mutta siitäkin huolimatta kehitystyö tuntui alussa etenevän hitaasti, koska jouduimme keskittymään paljon infrastruktuurin kehittämiseen – pohjatyö vaati oman aikansa. Tähän oli syynä pääosin se, ettei Aavalla aiemmin ollut käytössä vastaavia JavaScript-toteutuksia.

Koska halusimme nopeuttaa projektin alkua, otimme paljon mallia boilerplate-tyyppisistä ratkaisuista. Tämä kuitenkin myöhemmässä vaiheessa kostautui, kun jouduimme selvittämään kopioituihin osiin liittyviä bugeja. Selvittäminen oli haasteellista, koska emme täysin ymmärtäneet kaikkia valintoja tai heikkouksia, joita koodissa oli.

Kun saimme ensimmäiset komponentit valmiiksi, vauhti alkoi kiihtyä ja uusien toiminnallisuuksien teko sujua erittäin nopeasti. Koko projektiin meni lopulta noin kaksi kuukautta, ja noin puolet tästä ajasta käytettiin vanhan infrastruktuurin kehittämiseen. Sovellus on parhaillaan sisäisessä testauksessa ja se julkaistaan helmikuun aikana. 

Tekniset valinnat

Koska edelleenkin laajasti käytetty PHP 5.6 alkaa Aavan korkeiden standardien mukaan vedellä viimeisiään, päätimme tässä yhteydessä myös päivittää palvelun PHP 7.1:een, jotta saimme siihen lisää nopeutta ja uusia ominaisuuksia käyttöön. Monet PHP-kirjastot ovat jo lopettaneet tuen PHP 5 -versioille, mikä omalta osaltaan hankaloittaa uusien asioiden kehittämistä PHP 5 -versioiden päälle. Aava oli ensimmäinen asiakkaamme, joka otti PHP 7.1 -version käyttöön olemassa olevaan projektiin. Tämä herätti myös paljon kiinnostusta Druidin ulkopuolella.

Taustajärjestelmänä sovellukselle toimii tällä hetkellä Drupal 7. Suunnittelemamme API on tehty niin, että frontend-sovellus on tulevaisuudessa helppo siirtää minkä tahansa alustan päälle. Näin Aavan ei tarvitse rajoittaa teknisiä valintojaan meidän teknisten valintojemme vuoksi. Tähän ratkaisuun päädyttiin, koska Drupalin päälle on rakennettu merkittävä määrä olemassa olevia toiminnallisuuksia, jotka nopeuttivat sovelluksen kehittämistä.

API-dokumentaatioiden tekemiseen käytimme Swagger-työkalua. Swagger-dokumentaatio on koostettu JSON-datasta. Samaa tiedostoa käytetään myös rajapintojen generoimiseen.

Yhteenveto

Projekti kokonaisuudessaan oli erittäin mielenkiintoinen. Etenkin jatkuva uusien teknologioiden hyödyntäminen pitää mielen virkeänä ja motivoituneena. Tämä myös varmistaa Aavan järjestelmille pitkän käyttöiän, ja mahdollisimman matalat kustannukset rakennusvaiheessa.