Uusi sovellusprojekti - Näin se toimii

Moi! Minä olen Aija, olen Simplifiedilla päädevaajana. Sain tehtäväksi tehdä sovelluksen, joka toimii lisäpalveluna nykyisille asiakkaillemme. Tämä oli myös loistava tilaisuus kertoa käytännössä, miten me tehdään sovelluksia.

Tervetuloa seuraamaan sovellusprojektia!

Kertaus edellisistä osista

Olemme tämä sovellusprojektin ja blogisarjan viimeisessä osassa. Jännittävää!

Olemme nyt tähän mennessä:
1) Validoineet ja teroittaneet sovellusideaa
2) Valinneet sopivan Low-code alustan sovellukselle
3) Tehneet päätöksiä datatyypeistä ja rakentaneet tietokantaa
4) Suunnitelleet sovelluksen ulkonäköä ja käyttökokemusta
5) Kirjoittaneet ylös sovelluksen toiminnallisuuksia
6) Aloittaneet sovelluksen varsinaisen suunnittelu- ja toteutustyön

Ja nyt ollaan tilanteessa, jossa meillä on valmis sovellus, joka voidaan julkaista käyttäjille.

Vaihtoehdot sovelluksen julkaisuun

Se, minne sovellus lopulta julkaistaan riippuu eniten siitä, missä ja miten käyttäjät käyttävät sovellusta. Usein sovellukset julkaistaan usealle alustalle, jotta käyttäjien on helppo päästä sovellukseen paikasta ja laitteesta riippumatta. Tästä esimerkkinä voisi olla vaikka pankkisovellukset. Niitä voit käyttää joko nettisivujen kautta kirjautumalla tai sovelluskaupasta ladattuna appina.

Julkaisuvaihtoehdot ovat: Selain, työpöytä, iOS (App Store), ja Android (Play Store).

Jos kyseessä on työkoneella käytettävä sovellus, kuten CRM tai muu tiedonhallinta, pääasiallinen käyttö tapahtuu yleensä selaimessa tai työpöytäversiona. (Esimerkiksi Hubspot, Canva tai Figma). Jos taas sovellusta käytetään puhelimella, on sovelluskauppaan julkaisu yleensä parempi vaihtoehto (Esimerkiksi MobilePay, Whatsapp tai EasyPark). Käydään tarkemmin yksityiskohtia näistä vaihtoehdoista.

Low-coden suuri etu on se, että samalla koodipohjalla voidaan julkaista sovellus joka paikkaan, eikä tarvitse esimerkiksi tehdä erillisiä versioita selainversioon ja mobiilisovellukseen. Tämä helpottaa ylläpitoa ja jatkokehitystä huomattavasti.

1. Selain ja työpöytä

Katsotaan ensin tietokoneen kautta käytettäviä sovelluksia. Sovelluksen selainversion tunnistaa siitä, että sovellusta käytetään jonkin www-osoitteen kautta. Tämä on käyttäjälle helppo tapa, osoitteen kirjoittamalla pääsee helposti sovellukseen missä tahansa. Miinuspuoli tässä on se, että kännykällä nopea pääsy sovellukseen vaatii sivuston pitämisen välilehtenä koko ajan, tai toki helpommin valikkoon lisätyn kuvakkeen kautta, mutta ei aivan sama asia, kuin mobiilisovellus.

Selainversion julkaisu on helppoa! Tarvitset vain oman domainin (www.domain.com) ja kun DNS-tiedot on päivitetty, voit julkaista sovelluksen.

Toinen vaihtoehto on työpöytäsovellus, kuten Spotify tai Teams, jolloin sovellus asennetaan omaan laitteeseesi ja pääset käyttämään sovellusta suoraan valikosta. ‍

2. Android ja iOS

Sovellusversion julkaisussa on muutamiakin etuja: Helppo pääsy puhelimella, ihmiset ovat tottuneet lataamaan ja käyttämään appeja, sekä mobiiliversiossa voit esimerkiksi lähettää push-ilmoituksia käyttäjille. Tämän projektin kohdalla huomionarvoista on myös, että FlutterFlow:lla tehty sovellus performoi paremmin mobiilissa, koska alusta on tarkoitettu ensisijaisesti mobiilisovellusten kehittämiseen.

Sovelluskauppoihin julkaisu eroaa selainversiosta muun muassa siinä, että julkaisu maksaa erikseen. Julkaisu Play Storeen maksaa 25 € / kerta (vain ensimmäisen sovelluksen kohdalla, seuraavat ovat ilmaisia!) ja se vaatii Google Developer -tilin, joka luodaan Google Play Consolessa. App Storeen julkaisu puolestaan maksaa 99 € vuosi, eli on Play Storeen verrattuna kalliimpaa.

Toinen ero on se, että sovelluksen julkaisu vaatii hieman enemmän asetusten säätämistä. Molemmissa tapauksissa, asetusten viimeistelyn jälkeen sovellus julkaistaan sovelluskauppaan käyttäjien ladattavaksi.

Mitä tehdään julkaisun jälkeen?

Tämä on varmasti sovelluskehityksen tärkein vaihe. Miten sovellus lähtee oikeasti toimimaan käyttäjien käsissä?

Kun sovellus on julkaistu, on ensisijaisen tärkeää seurata sitä, miten käyttäjät käyttävät sovellusta, kerätä heiltä palautetta ja pyrkiä tekemään käytöstä aina vain mukavampaa.

1. Bugikorjaus

Tämä on sovelluskehityksessä enemmän sääntö, kuin poikkeus. Bugeja tulee aina ja se on ok. Sovelluskehitys on pienissäkin projekteissa monivaiheinen työmaa, joskus sitä ei vain tehdessä huomaa ajatella kaikkea. Low-code alustojen etu on se, että alusta osaa hyvin itse kertoa suorat errorit ja virheelliset kohdat, jos näitä on, sovellusta ei itseasiassa edes pysty julkaisemaan.

Toisenlaiset bugit ovat sitten ne, joissa nappulasta painamisen jälkeen pitäisi tapahtua jotain, joka on teknisesti oikein, mutta ei aivan se, mitä kehittäjä oli suunnitellut tai käyttäjä ajatellut. Tällainen voisi olla esimerkiksi puuttuva steppi logiikan kulussa, kuten lomakkeen kenttien automaattinen tyhjennys, tietyn toiminnallisuuden liian hidas toiminta tai muuta vastaavaa. On tärkeää etenkin alkuvaiheessa, että käyttäjillä on helppo väylä bugien ilmoittamiseen.

2. Palaute ja jatkokehittäminen

Palautetta ei kannata kerätä, jos sen perusteella ei aio tehdä mitään. Mutta eihän Facebookiakaan rakennettu niin, että palkattiin kehittäjät kehittämään  ja ensimmäisen version jälkeen koko porukka lomautettiin. Sovellus muuttuu koko ajan ja sitä pyritään jatkuvasti parantamaan. Tämän vuoksi saat ilmoituksia puhelimeesi, että "sovelluksen uusi versio on valmiina asennettavaksi". Harvoin saadaan heti kerralla niin hyvää sovellusta, että sitä ei tarvitsisi muokata jälkeenpäin.

Ole siis valmiina siihen, että kun lähdet mukaan sovelluskehitykseen, et osta sovelluskehitysprojektia, vaan otat sovelluksen osaksi liiketoimintaasi ostopäätöksestä eteenpäin ja sitoudut siihen, että sovelluksesi pysyy kilpailukykyisenä, toimivana ja käyttöystävällisenä myös tulevina vuosina.

Esimerkkinä tästä kirjoitushetkellä hiljattain julkaistu uutinen EasyParkilta, jossa he ilmoittavat UI-muutoksista ja perustelevat myös syyt muutoksille.

"Me emme ryhtyneet arvailemaan, mitä pitäisi kehittää. Sen sijaan analysoimme huolellisesti käyttäjädataa, asiakaspalvelukontakteja, vapaaehtoisten tutkimusosallistujien palautetta ja asiakkaidemme jättämiä arvosteluja tehdäksemme käyttökokemuksesta vieläkin paremman."

Juuri näin!

Se oli siinä!

Nyt sinulla on toivottavasti selkeämpi kuva sovelluskehityksestä ja sen vaiheista ja olet ennen kaikkea innostuneempi ja rohkaistunut oman sovellusideasi eteenpäin viemisessä!