Sisällönhallintaa ja sisällön suunnittelua
Olen kirjoittanut aiemminkin sisällönhallintajärjestelmistä. Silloin tuuletin ajatuksiani ylläpidon käyttöliittymän toteutuksesta sivuston kehittäjän ja sivuston sisällön syöttäjän näkökulmasta. Tämänkertainen aihe on samalla suunnalla, sisällön teknisessä suunnittelussa.
Reagoiva websuunnittelu
Nykyisellään on vallalla ajattelumalli reagoivasta websuunnittelusta (responsive web design, RWD). Tai mukautuvasta suunnittelusta. Itse puhun reagoivasta, koska sisältö reagoi laitteen ominaisuuksiin. Mukautuminen astuu kehiin, kun laitteiden ominaisuuksia hyödyntämällä sivun sisältöä rikastutetaan tai elävöitetään. Aiheesta on kirjoitettu paljon muiden toimesta.
Reagoiva suunnittelu korostaa sisällön asemaa. Kun laitteen näytön koko on pieni, on sisällön oltava hyvin harkittu. Visuaaliset elementit ja jopa toiminnallisuus rajautuvat tukemaan sisältöä. Tästä päästään hyvin yksinkertaiseen päätelmään, että sivustoa ei voi suunnitella ennen kuin sisältö on suunniteltu. Reaalimaailmassa tällä hetkellä helpommin sanottu kuin tehty.
Sisällön suunnittelun tärkeys
Hyvin moni visuaalinen ulkoasu rakennetaan dummy-sisällön ympärille. Lorem ipsum on aika monelle web-suunnittelijalle tuttu lause. Rakenteita ei tehdä oikean sisällön ympärille, mikä on jo itsessään väärä lähestymistapa. Pahimmillaan ei välttämättä edes tiedetä, minkä tyyppistä sisältöä sivustolle tulee. “Tähän voisi tulla uutislistaus” sekä “Tähän voisi tulla pääkuva ja tänne nosto” ovat varmasti tuttuja mietteitä suunnittelijalle. Minä en harmikseni osaa visuja suunnitella, mutta monessa ulkoasussa olen tuon nähnyt. Ja lopputulos on yleensä rakenteellisesti huono.
Huono rakenne tässä tapauksessa tarkoittaa sitä, että se ei sovellukaan sitten lopulliselle sisällölle ollenkaan. Jos rakenne on suunniteltu dummy-sisällöllä, johon tulee yksi leveä kuva ja kolme kappaletta tekstiä ei lopullinen sisältö kolmella pienellä kuvalla ja yhdellä kappaleella tekstiä näytäkään hyvältä ja tarkoituksenmukaiselta. Huonosta rakenteesta asiakas yleensä syyttää tekijöitä ja osittain aiheesta. Tekijöiden “tyhmyyttä” on suunnitella rakenteita ilman lopullista sisältöä. Kuin suunnittelisi kerrostalon tietämättä tuleeko sinne asuntoja vai toimistotiloja. Tarpeet vaihtelevat.
Sivuston kannalta on hyvin tärkeää tietää lopullinen sisältö, vaikka vain rakenteellisesti.
Sisällön tekninen suunnittelu
Tekninen sisällön suunnittelu tarkoittaa sisällön meta-rakenteen suunnittelua. Mihin tulee teksti, mihin kuva, mitä muita elementtejä tähän sisältöön pitää kuulua (tagit, kategoriat, liitteet, viittaukset). Kyseessä on yhden sivun pääsisällön semanttinen rakenne ilman merkkaukseen liittyviä tyylirakenteita (esimerkiksi css) sekä kaikki kyseiseen sisältöön liittyvät metatiedot. Käytännössä tuo rakenne pitäisi pystyä rakentamaan puhtaasti esimerkiksi markdown-kielellä.
Kun sisällön rakenne on selvillä on se helppo muuttaa html-muotoiseksi sisällöksi. Optimaalisessa tilanteessa sisältö voidaan muuttaa lähes mihin tahansa muotoon (esimerkiksi pdf, json, xml, epub) yhtä helposti kuin html:ksi. Etuna tästä on se, että sama sisältö voidaan julkaista monessa paikassa. Tämä optimi on kuitenkin tällä hetkellä valitettavan kaukana todellisuudesta. Sisällön syötössä puututaan ulkoasuun kun huomio pitäis olla sisällössä ja sen rakenteessa.
Jos projektin alussa ei ole tiedossa sisällön rakennetta päädytään polulle jossa visuaalisuus sanelee sisältö eikä toisin päin.
Ongelmat sisällön syötössä
Nykyaikainen pieni tai keskisuuri sisällönhallintajärjestelmä (cms) on hyvin monipuolinen julkaisujärjestelmä. Asiakkaille, sisällön ylläpitäjille esitellään kuinka sisällön syöttö on helppoa kuin wöördissä. On lihavoinnit, korostukset, tekstivärit ja kaikki vipstaakit. Kuvat ja taulukot on mahdollista keskittää ja asettelua voi säätää. Käytössä on monipuolinen sisällönsyöttötyökalu (rich text editor, editori). Wysiwyg joku saattaisi sanoa, what you see is what you get. Käyttäjän ei tarvitse osata koodata, sen kun napsuttelee nappeja.
Valitettavasti sisällön syöttäjälle annetaan liian paljon mahdollisuuksia rikkoa sisällön rakenne. Sivuston suunnittelijan säätömahdollisuudet editoriin ovat huonot tai olemattomat. Editori tulostaa suoraan html-tiedostoja (tai tiedoston osia) html-muunnoksineen. Lisäksi hyvin usein sisällönhallintajärjestelmän suhtautuminen sisältöön on julkaisuperusteinen. Rakennetaan sivukartta jossa sivujen toiminta liitetään sivupohjaan. Sivupohjassa määritellään nipullinen osa-alueita. Osa-alueille määritellään sitten sivupohjaisesti toiminnallisuuksia, joista yksi voi olla sisältöä (editori). Jälleen kerran sivuston suunnittelijalla on hyvin rajatut työkalut vaikuttaa sisällön tekniseen rakenteeseen tai syöttötapaan. Tämän tyyppisen rakenteen siirto toiseen formaattiin on hankalaa, koska se saattaa sisältää tyyliin vaikuttavia muotoiluja tai pahimmassa tapauksessa toiminnallisuutta.
Toiveita reagoivammasta ja mukautuvammasta tulevaisuudesta.
Kuten aikaisemmassa kirjoituksessani totesin, olen käyttänyt webbiurani aikana muutamaa sisällönhallintajärjestelmää. Olen jopa suunnitellut ja toteuttanut sellaisen. Teknisesti se oli vakaa mutta käyttöliitymältään kömpelö. Mutta mikä cms ei olisi ollut tuollainen alkutaipaleellaan?
Joomla on tietyllä tapaa eriyttänyt sisällön ja ulkoasun mutta siinäkään itse sisällön tyypin tai rakenteen muotoilu ei oletuksena ole parempi kuin muissa. WordPressissä pystyy vaikuttamaan jollain määrin sisältötyyppiin mutta ideologia on edelleen julkaisu edellä. Samoin oli Tumblrn kanssa. Olen aina vierastanut Drupalia sen monimutkaisuuden takia mutta yllätyin positiivisesti, miten siinä pystyy vaikuttamaan sisällön rakenteeseen. Drupal taitaa olla yksi parhaita tämän eriyttämisen tekevistä järjestelmistä. Jopa omaa saittiani pyörittävä Modx tekee sen huonommin ja monimutkaisemmin kuin Drupal. Modx:n eduksi täytyy sanoa, että siinä on mahdollisuus pudottaa editori pois. Silti sisältö ja rakenne sidotaan sivupohjaan, ulkoasuun eikä sisältötyyppiin.
Sisimmässäni toivon, että joku huomaa tämän pienen huutoni ja vastaa siihen tarjoamalla ratkaisun. Ehkä meidän olisi aika ajatella sisällön syöttö ja ylläpito uusiksi. Ehkä askel pois wöördimäisistä käyttöliittymistä olisi tervettä. Tarvitseeko sisällön syöttäjän nähdä sisältö visuaalisena, jos esitystapa kuitenkin muuttuu päätelaitteen mukaan? Pystyisimmekö opastamaan sisällön syöttäjän käyttämään uudenlaisia, tehokkaampia sisällön rakenteen hallintaan soveltuvia työkaluja? Enemmän kysymyksiä kuin vastauksia.