Vanhojen järjestelmien käyttöliittymät tuppaavat olemaan murheenkryynejä. Ne voivat olla hankalia, hitaita ja epävakaita käyttää, ja saavutettavuusvaatimuksien täyttäminen voi olla työn ja tuskan takana. Käyttöliittymien uudistaminen tuntuu lisäksi pitkältä ja kalliilta projektilta.
Ratkomme käyttöliittymäongelmia tämän tästä. Meillä on siis jo aika lailla kokemusta siitä, miten käyttöliittymäuudistukset kannattaa tehdä, ja miten niitä ainakaan ei kannata tehdä.
UI-uudistus – miksi se oikeastaan on niin työlästä?
Vanhojen järjestelmien kehittäminen on rasittavaa puuhaa monestakin syystä. Useimmat ongelmat kulminoituvat back endiin. Myös arkkitehtuuri voi aiheuttaa esimerkiksi suorituskyvyn kautta haasteita, joskus taas ihan rehti UI-määrittely ja sitkeä halu toteuttaa sama käyttöliittymä mutta vain uudella tekniikalla.
Käytännössä isoimmat esteet veteraanijärjestelmien UI-uudistuksissa on, että usein niiden alkuperäiset tekijät ovat jo lähteneet yrityksestä. Mitään kunnollista dokumentaatiota ei useinkaan ole. Järjestelmät ovat monoliittisia järkäleitä, ja niihin on ympätty sekä asiointi- että käsittelyjärjestelmät. Jos ne onkin eroteltu, niin välissä olevaan integraatioon voi mahtua ongelmia.
Järjestelmien uudistaminen ja kehittäminen on siis hidasta. Voi olla, että yhden pienen tietokenttäruudun muuttamiseen menee neljä kuukautta. Tuo yksi ruutu voi vaikuttaa todella laajalle, ja lopulta täytyy tehdä hitaita päivityksiä lähes kaikkialle. Jos samalla halutaan tehdä saavutettavaa käyttöliittymää, aikaa ja kahvia kuluu sitäkin enemmän.
Eikä näiden järjestelmien arkinen käyttäminenkään usein kovin letkeää puuhaa ole. Ne voivat olla hitaita, jähmeitä ja hankalia käyttää – saavutettavuuden ja käytettävyyden näkökulmasta jopa täysin mahdottomia.
Kolme erilaista ja -kokoista tapaa uudistaa käyttöliittymä
Karkeasti jaoteltuna monoliittisten järjestelmien käyttöliittymäuudistuksen voi tehdä kolmella tavalla.
1. Australian kokoinen projekti. Tässä perinteisessä ratkaisutavassa kirjoitetaan järjestelmän back end kokonaan uusiksi. Se on erittäin työläs ja hankala tapa saada aikaan tarvittavat muutokset, koska käyttöliittymän uudistamiseksi käytännössä koko asiointijärjestelmä ja ainakin osa käsittelyjärjestelmästä täytyy uusia.
2. Etelä-Australian kokoinen projekti. Ensimmäistä tapaa pienempi, mutta silti iso ja työläs tapa on päivittää järjestelmän asiointisovellus back endissä. Päivitettävän määrä on pienempi, mutta aikaa kuluu silti, koska välissä on integraatio, joka saattaa myös vaatia uusimista.
3. Mukava kämmenenkokoinen paketti. Suositeltavammassa tavassa asiointijärjestelmä otetaan pois back endistä ja tehdään siitä selaimeen progressive web application eli PWA-sovellus tai single page app eli SPA-sovellus. Ensin mainittu on suosikkimme, mutta kummallekin on ehdottomasti omat käyttötilanteensa. Toki tässäkin ratkaisutavassa täytyy UI:n lisäksi tehdä muitakin muutoksia. Asiointi- ja käsittelyjärjestelmän väliseen integraatioon voidaan käyttää Node-yhdyskäytävää, jolla voidaan ketterästi muodostaa käyttöliittymälle sopivia rajapintoja.
Miksi PWA on suosikkitapamme toteuttaa asiointisovellus
Olennaista käyttöliittymän uudistamissa vähemmän australiankokoisena projektina on, että asiointijärjestelmä ja käsittelyjärjestelmä ovat erillisiä, ja että asiointijärjestelmä tuodaan selaimeen. Muut yksityiskohdat muotoutuvat yleensä tapauskohtaisesti, eli ne riippuvat niin uudistettavasta käyttöliittymästä kuin sitä uusivasta tiimistä. Jos kuitenkin saamme valita, valintamme on PWA-sovellus.
Tässä 9 syytä käyttää PWA-arkkitehtuuria asiointijärjestelmässä:
- Se on responsiivinen
- Sovellus ladataan vain kerran
- Sovellus suoritetaan selaimessa
- Se on API-riippuvainen
- Voidaan asentaa mobiilisovelluksena
- Tukee offline-tilaa
- Toimii vain https:n yli
- Service worker -ohjelma palvelee taustalla
- Mahdollistaa push-notifikaatiot (iOS:ää lukuun ottamatta).
Milloin kannattaa valita PWA ja milloin SPA? Yksinkertaistettuna toimii tämä muistisääntö: Valitse aina PWA, ellei ole tarvetta täysin reaaliaikaiselle tiedonkululle. Perinteiseen malliin molemmilla erona on se, että palvelimen sijasta ne pyörivät selaimessa ja tarvitsevat REST-rajapintoja.
PWA:n yhdeksästä syystä neljä ensimmäistä sopivat myös SPA:han, kun taas perinteisessä verkkopalvelussa vain ensimmäinen kohta, responsiivisuus toteutuu. Se on siis ehdottomasti parannus aiempaan!
Jos tarvitset heti tukea UI-uudistukseen, ota toki meihin yhteyttä.
