Year: 2009

Nykyaikainen julkaisujärjestelmä on aika erilainen kuin vielä vaikkapa viisi vuotta sitten osattiin kuvitella. Millainen olisi se “unelmien” järjestelmä, jonka kanssa itse tekisin mieluiten töitä?

(Julkaisujärjestelmä-sana on varsin ylikuormittunut. Puhun tässä julkaisujärjestelmästä, mutta tarkennan tarkoittavani sekä sisällönhallintaa että sellaista sovelluskehystä, jonka päälle on vaivatonta kehittää melkein minkälaisia verkkopalveluita vain.)

1. Sisältökeskeisyys

Kun kerran puhutaan julkaisujärjestelmästä, on tärkeää, että sisältö on järjestelmässä etusijalla. Moni julkaisujärjestelmä unohtaa olevansa sisällönhallintajärjestelmä ja keskittyy sivuhierarkian ja irrallisista komponenteista muodostettujen sivujen sisäisen rakenteen hallintaan.

Sivuston rakenne tai komponentti ei varsinaisesti ole sisältöä, yksittäinen juttu tai vaikka video on. Sisällöntuottajat tuottavat juttuja. Asiantuntijat rakentavat sivustoja ja suunnittelevat informaatioarkkitehtuurin. Tämän jaon ympärille on rakentuu luontevasti niin käyttöliittymäsuunnittelu kuin hakukonenäkyvyyden vastuualueetkin.

Kun kaikki sisältö on jollain tasolla samanarvoista, kaikesta sisällöstä voidaan ilman lisäohjelmointia muodostaa vaikkapa syötteitä tai tarjota yleiskäyttöinen web-API sisällön hallintaan.

2. Sisällön uudelleenkäytettävyys

Järjestelmän avulla tuotettu tai järjestelmään tuotu sisältö on mahdollisimman uudelleenkäytettävää. Tämä tarkoittaa sitä, että sisällöstä on riisuttu kaikki esityksellisyys. Ylläpitotyökalut eivät siis esimerkiksi tarjoa sisällöntuottajille fonttivalikkoa vaan asiantuntijan koostamaa tyylivalikkoa.

Toinen merkittävä uudelleenkäytettävyyteen vaikuttava asia on sisällön tallentaminen tiukan rakenteisena. Useimmiten tämä tarkoittaa tallentamista puhtaassa XML-muodossa. Mitä hallitumpi sisällön rakenne on, sitä varmemmin sisältö saadaan taipumaan myös tulevaisuuden tarpeisiin. Epämääräisen Office-HTML-mössön hallinta ei voi mitenkään olla kustannustehokasta pitkällä aikavälillä.

Miksi tämä on tärkeää?

Sivuston kuin sivuston ulkoasu tuppaa menemään uusiksi noin parin vuoden välein. Sisällön on mukauduttava tähän. Ei ole realistista joutua korjaamaan tai jopa syöttämään sisältöä uusiksi ulkoasun vaihtuessa.

Toinen etu on se, että sisältö on vietävissä helposti muille sivustoille tai kokonaan muihin medioihin. Rupu-“HTML” tuottaa aina ylimääräistä päänvaivaa vastaanottavassa päässä ja tekee hommasta siten tehotonta.

Kehittynyt järjestelmä ei tuota esimerkiksi sisältöä, jossa kappalevaihdot on merkitty pakotetuin rivinvaihdoin, väliotsikot eivät ole lihavoituja kappaleita eikä tekstin loppuun ole lyöty tyhjää, jotta olisi tilaa kirjoittaa. Suorastaan itkettää, kun näen isojen mediatalojenkin tuottavan tällaista sisältöä verkkoon. Mikä se niiden bisnes olikaan?

Uudelleenkäytettävyys tavataan nähdä jo ratkaistuna ongelmana, mutta ei se ihan niin ole. Selainpohjaiset HTML-editorit tuntuvat edelleen tuottavan kuraa.

3. Käyttöönoton helppous

Kun käyttäjä kirjautuu järjestelmään, hän voi välittömästi alkaa tuottaa sisältöä, jopa täysin ilman opastusta. Tämä säästää valtavasti kustannuksissa, kun ei tarvitse kouluttaa ainakaan kaikkein yleisimpiin tehtäviin. Se myös osaltaan vaikuttaa järjestelmällä toteutetun sivuston menestykseen, koska mitä helpompi sisältöä on tuottaa, sen todennäköisemmin sitä myös tuotetaan. Mitä enemmän sisältöä, sen suurempi menestys.

Toinen puoli käyttöönoton helppoutta on tekninen. Mitä nopeammin saadaan projekti ja prototyyppisivusto pystyyn, sitä nopeammin voi web-kehitys olla tuottavaa. Pystytys ei saa vaatia erityistaitoja ja mitä vähemmän vaiheita se vaatii sen parempi.

4. Edistyneet SEO- ja analytiikkaominaisuudet

Nätit, kanoniset URL:t ovat itsestäänselvyys. Edistyneet SEO-ominaisuudet ovat esimerkiksi sellaisia, jotka huolehtivat kerran käytettyjen osoitteiden toimivuudesta viimeiseen asti, vaikka sisältöä siirrettäisiin paikasta toiseen. Linkkien toimivuuden varmistaminen on myös olennaista, hyvä järjestelmä tarkistaa kaikki ulkoisetkin linkit aika-ajoin, korjaa ne, mikäli osaa ja ilmoittaa ylläpitäjälle tarvittaessa.

Integraatio Google Analyticsiin esimerkiksi ulkoisten linkkien mittaamisen osalta on hyödyllistä ja poistaa yhden tyypillisen erillisen työvaiheen. Analyticsin API:n kautta voidaan tuoda sisällöntuottajalle juuri häntä varten räätälöityä tietoa kävijöistä ilman erillisen järjestelmän tuomaa vaivaa. Näin sitoutuminen sisällöntuotantoon kasvaa.

5. Todellinen modulaarisuus

Mihin tahansa järjestelmän osa-alueeseen on päästävä käsiksi plugin-tasolta. Toiminnallisuutta voi näin laajentaa koskematta itse tuotteeseen jolloin päivitettävyys ei kärsi. WordPress on osoittanut, että laajennettavuus yhdessä avoimuuden kanssa mahdollistaa järjestelmän menestyksen.

Rajapintojen on oltava erittäin monipuoliset ja ne on tarkkaan dokumentoitu. Kynnyksen tuottaa moduuleita tai muuta lisätoiminnallisuutta on oltava mahdollisimman alhainen.

6. Päivitettävyys

Ajan tasalla pysymisen on oltava mahdollisimman helppoa. Käsin tehtävä päivitystyö ei ole kenenkään intresseissä, koska se on itseään toistavaa ja virhealtista. Mitä laajemmassa käytössä järjestelmä on, sitä kriittisempää on suojautua tietoturva-aukkojen hyväksikäytöltä nopealla automaatti- tai puoliautomaattipäivityksellä.

Ajan tasalla olevat installaatiot myös vähentävät eri versioista välisten eroavaisuuksien aiheuttamia ongelmia, joita modulaarisessa järjestelmässä saattaa helposti tulla.

7. Skaalautuvuus

Nykyaikainen julkaisujärjestelmä on skaalautuva. Tämä tarkoittaa käytännössä, ettei järjestelmän ydinkään ole monoliittinen. Osaset ovat eroteltavissa toisistaan ja siten jaettavissa toisistaan täysin irrallisiksi kokonaisuuksiksi.

Tiedon tallennus- ja kyselytapa on abstraktoitu, jolloin voidaan ainakin tarvittaessa tallentaa tietoa tyypillistä relaatiotietokantaa skaalautuvammalla tavalla. Abstraktio ei saa merkittävästi hidastaa sovelluskehitystä, varsinkin kun useimmissa tapauksissa se ei ole käytännössä hyödyksi.

8. Avoimuus

Suljettu järjestelmä rajaa itsensä tehokkaasti pääasiassa avoimen webin ulkopuolella. Mitä avoimempi järjestelmä, sen vaivattomammin se on liitettävissä toisiin verkkopalveluihin.

Ideaalit rajapinnat webissä noudattavat REST-ideologiaa. Oleellisia rajapintoja ovat ainakin Atom (Syndication Format ja Publishing Protocol) ja OpenID – ja miksei vaikkapa OAuth.

9. Modernien web-käyttöliittymien monipuolinen tuki

JavaScript ja Ajax ovat oleellisia osia modernia web-kehitystä. Näitä on tuettava voimakkaasti. Tulevaisuudessa ainakin HTML 5 tuo kaikenlaista muuta uutta. Järjestelmä ei saa abstraktoida käyttöliittymätasoa niin, että täysi kontrolli merkkaus- ja HTTP-tasoilla katoaa.

10. Sosiaalisen webin perustoiminnallisuudet

Erittäin monella sivustolla tarvitaan rekisteröitymistä, käyttäjäprofiilia, sisällön kommentointia ja arviointia, vapaata avainsanoitusta, jopa sosiaalisten verkostojen luomista. Järjestelmän ydin on suunniteltava niin, että tällaiset asiat ovat joko kiinteä osa tai ne on helppo toteuttaa laajennuksina.

Julkaisujärjestelmän toivelistalle ei ole vaikea keksiä ominaisuuksia. On vaikeaa jopa rajata niitä lähtökohtia, joiden pohjalta ominaisuuksia aletaan valita. Web kehittyy edelleen niin huimaa vauhtia, että täydellistä alustaa ei mikään yksittäinen toimija voi mitenkään rakentaa. Ympärille tarvitaan vahva yhteisö.

Aikaa mitataan usein tunneissa, kun joku kirjoittaa hyvästä ideastaan webissä ja toiset jo julkaisevat alpha-versioitaan plugineista eri alustoille. Julkaisujärjestelmä ei voi olla menestyvä, jos se ei pärjää tässä todellisuudessa.