Pasi Kovanen

Pasi Kovanen

Software with Passion.

Käyttäjien odotukset Web-palveluille kasvavat jatkuvasti. Tämä johtuu mm. uusista päätelaitetyypeistä (viimeisimpänä tabletit ja äly-tv:t), selainten uusista ominaisuuksista sekä käyttöliittymätrendien muuttumisesta. Pari vuotta sitten toteutettu palvelu voi vaikuttaa jo nyt vanhanaikaiselta. Esimerkiksi mukautuva suunnittelu alkoi yleistyä vasta vuoden 2012 aikana, ja on nykyisin perusedellytys uusille palveluille.

Mikä merkitys tällä sitten on, riippuu hyvin paljon siitä, millainen palvelu on kyseessä. Yrityksen sisäiseen käyttöön tarkoitetun, hyvin suunnitellun ja toteutetun palvelun voi olettaa palvelevan käyttäjiä ainakin viisi vuotta käyttöönottohetkestä, ennen kuin suurempia muutoksia tarvitsee käyttöliittymään tehdä.

Asiakkaille suunnatun palvelun tarjoajan taas pitää hyväksyä se tosiasia, että käyttöliittymän uusimiseen voidaan joutua investoimaan usein, jos palvelu halutaan pitää modernina ja käytettävyydeltään kilpailukykyisenä.

Aiemmassa kirjoituksessa kerroin, miten Web-palvelut koostuvat asiakas- ja palvelinpäästä. Palveluiden käyttöliittymä sijaitsee siis asiakaspäässä.

Kannattaa vaatia toimittajalta asiakas- ja palvelinpäiden toteuttamista siten, että niiden välissä on hyvin määritelty rajapinta (esim. REST-teknologiaan pohjautuva). Tämä mahdollistaa parhaassa tapauksessa käyttöliittymän täydellisen uusimisen ilman mitään muutoksia palvelinpäähän. Huonosti suunniteltu ohjelmistoarkkitehtuuri voi tehdä pelkän käyttöliittymän uusimisen mahdottomaksi.

Tykkäsitkö artikkelista?

Anna pienet aplodit!

Kommentit

  • Jo tuolta vuodesta 1996 saakka on puhuttu erilaisita esityskerroksista. Aluksi se höpötys oli pitkälti selainsotaa ja erilaisia tekniikoita, joilla koristeltiin webbisivuja.

    Käytännössä ainakin koko 2000- luku on puhuttu esityskerroksen ja sisällön suhteesta toisiinsa. Eli yksi noista perushaasteista on oppia ymmärtämään se, että esityskerros vasta muotoilee tuon sisällön päätelaiteille sopivaksi.

    Esim. tuolla 2000- luvun alkupuolella tuota esityskerrosta luotiin esimerkiksi XML/XSLT- muunnosten avulla tai esimerkiksi template engineiden (esim. Smarty http://en.wikipedia.org/wiki/Smarty ) avulla.

    Eli kuten Pasi sanoo, niin sisältöön ja esitystapaan on kiinnitettävä huomiota, koska käyttöliittymät vanhenevat nopeasti ja esim. mobiililaitteet voivat vaatia vain osajoukkoa sisällöstä esitettäväksi.

    Eli aika monelle palveluiden tekijälle on aika suuri mahdottomuus erottaa esityskerros sekä sisältö toisistaan. Eli palvelua ajatellaan käyttöliittymänä joka kuorruttaa ja koristelee datan. Eli selvän rajapinnan luominen tiedon ja ulkoasun välille on haastavaa.

    Eli käytännössä informaation ja kuorrutuksen erottaminen monille on liian vaikeaa. Nykyäänhän annetaan yhdeksi ohjeeksi käyttöliittymäsuunnittelussa Mobile First- ajatus. Eli lähdetään siitä liikkeelle, että palvelua pitää käyttää mahdollisimman yksinkertaisella laitteella. Ja sitä mukaa kun toiminnallisuudet lisääntyy, niin myös käyttöliittymä monimutkaistuu.

    Aihe on siinä mielessä aika haastava, että monikin loppukäyttäjä ja tilaaja ei osaa ajatella sitä, että käyttöliittymä on pieni osa kokonaisuutta. Ja kuitenkin suurin osa palvelun hiomiseen käytettävästä ajasta kuluu kuitenkin käyttöliittymän hiomiseen.

    En viitsisi kirjoittaa ilkeästi, mutta käsittääkseni koko webin käyttöajan on pohdittu tuota sisällön ja esityskerroksen problematiikkaa. Aluksi kait kuitenkin niin päin, että optimoidaan palvelu yhdellä päätelaitteelle tai selaimelle ja sitten pyritään saamaan se toimimaan auttavasti myös muissa selaimissa.

    Yksi syy siihen lienee se, että tekijöillä ei ole riittävästi historiatuntemusta vaan oletetaan, että nykyiset ongelmat ovat uusia ja ennenkuulumattomia. Mutta vertaamalla hiukan seuraavia ongelmapareja, saa kuvan että pyörää ollaan jällkeen kerran keksimässä uudelleen:

    – Lynx – Netscape Navigator
    – Yksinkertainen mobiililaite – Mozilla

    Eli molemmilla ongelmat ovat samankaltaisia eli kaikkea samaa toiminnallisuutta ei voida toteuttaa molemmissa. Eli ongelma on ollut jo olemassa jotain lähes parikytä vuotta, mutta koska tekijöiden tietämys historiallisita laitteista on rajattua, niin ongelmaa pidetään uutena.

    Sama koskee vanhaa fat/thin-client ongelmaa eli kuinka paljon toiminnallisuutta tuodaan asiakasohjelmaan. Eli tuota pohdittiin tuolla 90- luvun alkupuolella ja mietittiin mikä osuus business logiikasta kuuluu asiakasohjelmalle ja mikä serveripäälle. Sama ongelma näkyy nykyään rikkaissa käyttöliittymissä eli pohditaan samaa asiaa. Eli analogia on sama, mutta päätelaitteet eri.

    Kun tiedetään, että uuden teknologian käyttöönottoaika on noin kymmenen vuotta sen keksimisestä, niin tarvitaan jonkin verran perspektiiviä asioiden ymmärtämiseen. Tuo kymmenen vuotta löytyy esim. tablettien ideoinnin ja käyttöönoton väliltä (väite perustuu tietoon).

    Kuhan pohdin, Kari…

    P.S. Saatan kirjoittaa ehkä hiukan ilkeän ja sarkastisen tuntuisesti, mutta tarkoitus ei ole aliarvioida ketään. Itse kaipaisin sitä, että yrityksillä olisi ”historoitsija” kertomassa vanhoista hyvistä ajoista. Eli kertomassa kuinka asioita on tehty ennen. Se saattaisi auttaa muunmuassa integrointitilanteissa sekä etsittäessä analogioita vanhoihin ratkaisuihin. Legacy- järjestelmät saattavat olla pahimmillaan jopa uusien koodareitten ikäisiä eli silloin voidaan tarvita niiden ymmärtämiseen hyvinkin erilaista ajatusmaailmaa.

    P.S.S. Ensin sisältö ja sitten ulkoasu: http://www.cowboykoodari.com/koodari/ensin-sisalto-ja-sitten-ulkoasu/

  • REST on hyvä ratkaisu jos halutaan tilaton web-rajapinta. Moderneissa single-page applikaatioissa alkaa kuitenkin yleistyy tilallisuus, full-duplex yhteydet ja muiden protokollien kuin HTTP:n käyttö. Vuosi 2014 on varmaan ”year of the Web Socket”, johon REST ei enää ole järkevä ratkaisu. Web Socketilla palvelin voi pushata tietoa clientille ilman pollausta (vaikka fallback:ina clientit käyttävätkin pollausta, jos selain ei tue Web Socketia).

  • Kertokaapa tähän aiheeseen liittyen miten teidän mielestänne ostajan tulisi käyttöliittymien ”vanhentuminen” huomioida hankintavaiheessa? Mitkä ovat niitä tekijöitä tai vaatimuksia, joita hankittavalle järjestelmälle kannattaa esittää? Toisin sanoen: Minkä asioiden perusteella ostaja pystyisi arvottamaan eri järjestelmien muuntautumiskykyä ja/tai dynaamisuutta, jotta siinä vaiheessa kun järjestelmän käyttökokemusta halutaan muuttaa, olisi muutos mahdollisimman helppoa? Näin ehkä vältyttäisiin pitkiltä ja arvokkailta muutosprojekteilta…

  • Tuomo, viittaisin kirjoituksen viimeiseen kappaleeseen: kannattaa vaatia että käyttöliittymän ja backendin välillä on standardi rajapinta (kuten esim. REST tai Panun mainitsema Web Sockets).

    Lisäksi käyttöliittymissä on dynaaminen single page -toiminnallisuus yleistämässä nopeasti. Riippuen sovelluksen luonteesta voi olla hyvä varmistaa että toimittajan ehdottama toteutusteknologia siihen taipuu.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *