Aiemmassa blogikirjoituksessani käsittelin responsiivisen käyttöliittymäsuunnittelun perusteita. Tällä kertaa tutustutaan tarkistuslistan avulla muutamiin mielenkiintoisiin responsiivisuuden haasteisiin.

Uuden web-projektin käynnistyessä ulkoasun suunnittelu tulee yleensä käsiteltäväksi hyvin alkuvaiheessa prosessia. Kaikissa tapauksissa projektin kokonaiskuva ei ole vielä erityisen hyvin selvillä, joten monesti joudutaan varautumaan erilaisiin tilanteisiin, jotka saattavat realisoitua tai jäädä toiveiksi. Ulkoasun kannalta eräs tärkeä alkuvaiheen valinta on se, lähdetäänkö eri laitteita varten tekemään eri versioita sivustosta vai käytetäänkö responsiivista suunnittelua, jonka myötä ulkoasu mukautuu laitteelle sopivaksi. Viime vuosina responsiivisen suunnittelun suosio on lisääntynyt ja sen avulla saadaankin monenlaista hyötyä esimerkiksi siitä, että ulkoasumuutokset voidaan tehdä vain yhteen paikkaan.

Responsiivisuuden puolestapuhujat korostavat siitä saatavia etuja, mutta kaikkiin tapauksiin responsiivisuus ei kuitenkaan sovi. Miten siis tunnistaa kannattaako omaa projektia lähestyä responsiivisesta näkökulmasta vai ei? Eräs ajatuksia herättävä työkalu on graafikko Douglas Bonnevillen kokoama 52 kysymyksen tarkistuslista responsiiviseen suunnitteluun liittyen. Perinteisestä neutraalista tarkistuslistasta poiketen kyseinen lista ottaa asenteekseen terveen skeptisyyden responsiivisuutta kohtaan. Lista sisältää monia mielenkiintoisia kysymyksiä, joista osaa voi pohtia tarkemminkin.

10. Can you prove that a RWD that will eliminate a dedicated mobile and desktop site will actually save you money?

Alkuvaiheen suunnittelun kannalta hyödyllisiä kysymyksiä esitetään listan kohdissa 10, 13, 18, 35 ja 39. Ennen kuin sivuston suunnittelua aloitetaan sen paremmin, on hyvä miettiä mitkä seikat tukevat responsiivisuuden valintaa ja toisaalta mitkä tekevät sen käytöstä hankalaa. Monesti juuri rahaan liittyvät seikat ovat erityisen tärkeitä, mutta myös prosessin muutos ja siihen liittyvät seikat voivat aiheuttaa päänvaivaa, mikäli vanhoista tavoista poikkeaminen ei ole tuttua. Aika on rahaa, kun taas muutos puolestaan yleensä syö kallisarvoista aikaa. Esimerkiksi useasta erilaisesta julkaisukanavasta luopumalla voidaan vähentää monimutkaisuutta ja sitä kautta saavuttaa aikasäästöä. Usean ison toimijan tekemä päätös erillisestä mobiilisivustosta responsiivisuuden sijaan on sinänsä mielenkiintoinen, mutta monesti se kiteytyy paremman käyttäjäkokemuksen tavoitteluun laitteesta riippumatta.

26. Are you prepared to deal with the limitations you’ll encounter with moving to one unified RWD from an existing multi-site strategy (dedicated mobile and desktop)?

Tilanteessa, jossa tehdään vanhan sivuston uudistusta ja olemassa olevaa sisältöä olisi tarkoitus siirtää uuden responsiivisen sivuston muodossa, voidaan miettiä listan kohtia 7, 26 ja 28. Ne korostavat erilaisten muutoksen aiheuttamien haasteiden punnitsemista ja mahdollisten uusien rajoitusten pohtimista. Muutosta tarvitaan myös prosesseihin ja toimintatapoihin, jotka liittyvät sisällöntuottamiseen ja sen suunnitteluun. Eräänlaista muutosvastarintaa saattaa aina esiintyä, mutta asioiden käsitteleminen yhteisesti pienentää sen mahdollisuutta ja tarjoaa mahdollisuuden löytää ratkaisuja hankalampiin ongelmiin.

1. Will the content owners be OK with uploading multiple size photos in the CMS (if one is being used) on a frequent basis?

Listan kohdat 1, 50 ja 51 nostavat esille kysymyksen usean eri kokoisen kuvan lataamisen tarpeesta. Kuvien osuus sivulatauksen yhteydessä ladattavan datan määrästä on suuri, joten niiden merkitys sivun nopeutta ajatellen on merkittävä huolimatta nykyajan nopeista yhteyksistä. Pienellä näytöllä ei luonnollisestikaan kannata ladata jättimäisiä kuvia, jotka säädetään selainpäässä sopivan kokoisiksi. Monet sisällönhallintajärjestelmät mahdollistavat kuvien koon automaattisen muuttamisen, joten sen kannalta käyttäjälle ei aiheudu lisätyötä. Muunlaisiakin ratkaisuja on tarjolla tilanteisiin, joissa taustalla ei ole sisällönhallintajärjestelmää. Näitä ovat esimerkiksi web-palvelimen avulla toimiva Adaptive Images tai kohtalaisen tuoreiden selainominaisuuksien hyödyntäminen.

4. Are you prepared to defend giving users of IE6-8 a slower or worse experience than their current experience on your non-RWD site?

Kohta 4 kysyy joissain tapauksissa tärkeän kysymyksen, johon myös kohta 22 liittyy. Monet vanhoja selaimia käyttävät käyttäjät joutuvat tyytymään uusien teknologioiden osalta huonompaan kokemukseen, koska responsiivisuuden kaltaiset uudet asiat tarvitsevat selaimilta uusia ominaisuuksia. Responsiivisuuden kohdalla esimerkiksi media queryjen puute on Internet Explorerin vanhempien versioiden haaste. Selainten eroihin törmää web-kehityksessä joka tapauksessa, joten mahdollisimman alussa onkin hyvä miettiä, mikä tavoite selainyhteensopivuudelle asetetaan ja mitä selaimia tuetaan aktiivisesti. Tämä valinta riippuu hyvin paljon sivuston tai sovelluksen käyttäjäkunnasta ja heidän laitteistaan. Erilaisten kirjastojen ja muiden apuvälineiden käyttö vähentää manuaalista työtä, mutta asia täytyy kuitenkin tiedostaa, jotta sen osaa huomioida valintoja tehdessä.

40. Would a slower mobile site cause you to bounce more visitors?

Sivuston nopeus on eräs seikka, johon kohdat 11, 23, 40, 42 ja 49 ottavat kantaa. Koska responsiivisuuden lähtökohtana on yhden rakenteen mukautuminen kaikkiin tarpeisiin, saattavat sivujen latausnopeudet pidentyä verrattuna mahdolliseen mobiiliversioon, jossa sisällön määrää on optimoitu. Tämä haaste on suurempi tilanteissa, joissa voidaan käyttää olemassa olevaa mobiilisivustoa vertailukohtana. Toisaalta ladattavan datan määrän lisääntyminen voi vaikuttaa etenkin heikon yhteyden päässä oleviin mobiilikäyttäjiin ja ärsyttää datasiirtorajoitusten kanssa taistelevia käyttäjiä.

47. Have you fallen for unsubstantiated hype about RWD, like how it will “maximize user experience”, or do you have specifics you can talk about intelligently?

Kokonaisuuden kiteyttää hyvin listan kohta 47. Se kyseenalaistaa responsiivisuuden valinnan ja vaatii selkeitä perusteluita, jotta valinta ei jää pelkästään markkinointipuheiden varaan. Tehtävien valintojen pohdinta vaatii toki hieman aikaa, mutta aiemmassa vaiheessa käytetyllä hetkellä voidaan säästyä isoilta ongelmilta myöhemmin.

Esimerkkinä toimineen listan kohdat ovat osittain päällekkäisiä, mutta silti listalta puuttuu varmasti paljon tärkeitä asioita. Tarkistuslistojen kaltaiset työkalut ovat hyviä herättämään ajatuksia ja ne tarjoavat helpon mahdollisuuden haasteiden paikantamiseen. Viime kädessä tärkeintä on kuitenkin sovellusalaan, tarpeisiin ja tavoitteisiin liittyvä ymmärrys, sillä ilman sitä tehdyt päätökset ovat parhaimmillaankin valistuneita arvauksia.