Mobiili- ja tablet-vallankumouksen myötä WWW, tuttavallisemmin Web, on ottanut valtavan harppauksen eteenpäin varsinkin saavutettavuuden ja käytettävyyden saralla. Responsiivinen, mukautuva Web on ottanut tiukan otteen nykyaikaisissa verkkopalveluissa ja Web-applikaatiot tekevät tuloaan. Onko julkaisujärjestelmän keskiössä usein oleva muinaiseen tekstinkäsittelyohjelmaan perustuva rikas sisällönmuokkaustyökalu tullut tässä suhteessa tiensä päähän? Voidaanko sille opettaa uusia tapoja vai tulisiko meidän muuttaa omia käytäntöjämme?

Palataan historiassa muutama vuosi taaksepäin, Web 2.0:n alkuaikoihin. Julkaisujärjestelmät olivat kehittäneet sisällöntuotannon menetelmiä ja keskiössä oli usein selaimessa pyörivä tekstinkäsittelyohjelmaa jäljittelevä rikkaan HTML:n muokkaukseen ja tuottamiseen erikoistunut työkalu. Olennainen ero tässä työkalussa verrattaessa aiempaan lomake-pohjaiseen julkaisujärjestelmään oli se, että sivulla oli yleensä ainoastaan yksi sisältökenttä, johon sisällöntuottaja pystyi tuomaan tekstiä, kuvia, videoita, taulukoita ja muotoilemaan näitä visuaalisesti miellyttäväksi, tasapainoiseksi kokonaisuudeksi. Tästä muokkaustyökalusta käytettiin tuttavallisemmin nimitystä WYSIWYG-editori; What You See Is What You Get.

Or do you?

Samaan aikaan WWW-suunnitelijat olivat murskaavan suurella enemmistöllä omaksuneet W3C:n, WWW:n standardeja ja suosituksia ylläpitävän yhteenliittymän suosituksen HTML:n pyrkimyksestä erottaa sisältö ja esityskerros toisistaan. Käytännössä tämä tarkoitti sitä, että sisällön rakenne tulisi esittää semanttisilla HTML-tageilla ja sen asettelu tulisi toteuttaa CSS:n keinoin.

Kuitenkin valtaosa WYSIWYG-editoreista muokkasi nimensä mukaisesti sisältökerrosta, lisäten sen sekaan esityskerroksen vaatimat määrittelyt. Näin ollen samanaikaisesti, kun editorilla tuotettu sivu saatiin sisällöntuottajan toimesta näyttämään toimivalta, ei noudatettu tärkeitä suunnitteluperiaatteita sisällön ja esityskerroksen erottamisesta toisistaan.

Tämä johtaa ongelmiin nykypäivän modernin ja mukautuvan webin aikakaudella. Kun sisältö on tarkasti aseteltu WYSIWYG-editorissa jonkin tietyn työasemaselaimen vaatimaan muotoon, on hankala esittää se luontevasti millään muulla laitteella.

Mobiili Web tulee ohittamaan työasema webin ensi vuonna ja jos verkkopalvelu kohdennetaan ainoastaan työasemaselaimia käyttäville kävijöille, jätetään enemmistö asiakkaista huomioimatta. Kenelläkään ei ole varaa siihen.

Mitä tilalle?

Web-applikaatioiden ja responsiivisen suunnittelun näkökulmasta kätevin ratkaisu olisi, jos WYSIWYG-editori poistettaisiin ja sisällöntuottajan muokattavissa olevan sivun sisältö jaettaisiin vanhanaikaisesti muutamaan erilliseen lomake-kenttään. Esimerkisi sivun otsikko, -ingressi, -sisältöalue ja -kuva. Nämä kentät olisi helppo huomioida mukautuvasti siten, että saataisiin mahdollisimman laaja-alainen päätelaitenäkyvyys.

Tämä taas johtaisi kuitenkin siihen, että sivupohjien määrää jouduttaisin kasvattamaan sisältökenttäkohtaisesti ja sisällöntuottajille tulisi ylimääräistä hallinnoitavaa. Sisällöntuotantoprosessi kärsisi.

Kultainen keskitie

Ehdottomasti joustavin keino on opettaa WYSIWYG-editorille uusia tapoja. Opettaminen alkaa sillä, että kitketään vanhat, pinttyneet tavat pois. Editorista poistetaan tarpeen mukaan turhat asemointiin vaikuttavat työkalut kuten kuvan- ja tekstin asemointi sekä tekstityypin koko- ja valinta. Taulukkotyökalu saa kuitenkin usein jäädä, mikäli sen käyttö rajataan data-taulukoille.

Sen jälkeen kun editorin työkalupalkista on karsittu pois kaikki sisällön ja esityskerroksen väärinkäyttöön ohjaavat työkalut, opetetaan sille muutama uusi temppu. Useimmat WYSIWYG-editorit mahdollistavat omien tyylien lisäämisen työkaluvalikoimaan. Responsiivisen suunnittelun tarkoituksena on esittää sisältö parhaalla mahdollisella tavalla riippumatta käyttäjän päätelaitteesta. Tämä onnistuu silloin, kun sisältö-elementti voidaan tunnistaa ja ennenkaikkea huomioda eri päätelaitekohtaisissa tilanteissa erillisen tyylitiedoston kautta.

Käytännössä tämä tarkoittaa sitä, että lisätään työkaluvalikkoon esimerkiksi uusi tyyli kuvan asemointia varten. Tätä tyyliä voidaan kutsua mieluummiin vähemmän asemointia määrittelevällä nimellä kuten ”sivun-kuva”. (Jos nimeäisimme tyylin asemointiin viitaten ”kuva-oikealla” niin se viittaisi liikaa työasemanäkymän tilaan, jossa kuva asemoidaan oikealle.)

Nyt kun kuvan tyyli on nimetty, voidaan sen asemointi ja koko määritellä tyylioppaan mukaisesti erikseen mm. mobiili-, tablet- ja työasemaselaimille. Jatkotoimenpiteinä voidaan ottaa kantaa myös siihen, tulisiko kuvasta ladata korkearesoluutioversio (ns. retina) HiDPI näytöillä varustetuille päätelaitteille.

Nyrkkisääntönä voidaan ajatella että sen sijaan, että sisältöelementin kokoa, -väriä ja asemointia muokataan erillisillä työkaluvalikon toiminnoilla, luodaan yksi työkalu mikä suorittaa kaikki nämä toimenpiteet tyylioppaan pohjalta. Annetaan sisällöntuottajalle mahdollisuus keskittyä sisällön asemoinnin viilauksen sijaan sisällön sanomaan.

 

Lisätietoja Sinisen Meteoriitin palveluista