10 nykyaikaisen julkaisujärjestelmän kulmakiveä

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.

Google antaa nyt sivun kertoa mikä on sen kanoninen URL

Google:

We now support a format that allows you to publicly specify your preferred version of a URL. If your site has identical or vastly similar content that's accessible through multiple URLs, this format provides you with more control over the URL returned in search results. It also helps to make sure that properties such as link popularity are consolidated to your preferred version.

Monen ei-niin-URL-tietoisen julkaisujärjestelmän elämä helpottui juuri huomattavasti.

googlewebmastercentral.blogspot.com/… →

Web-sivun kieli, osoitteessa vai ei?

Lue myös kaksiosaisen artikkelisarjan ensimmäinen osa: Kieli URL:ssä.

URL-osoitteiden hallinta on www-sivuston, julkaisujärjestelmän tai web-frameworkin avainkohtia. Joskus URL:ssä on tarve näyttää dokumentin kieli. Koska ja miksi?

Kieli URL:ssä on tarpeeton, jos sivusto ei tarjoa sisältöä kuin yhdellä kielellä. Sitä ei sinne kannata varmuuden vuoksi laittaa, vaikka sisältö joskus tulevaisuudessa saattaa laajentua. Kaikki ylimääräinen URL:ssä lisää osoitteiden monimutkaisuutta ja mitä monimutkaisempi URL, sen vaikeakäyttöisempi.

Sisältöneuvottelu

HTTP:n Content Negotiation, sisältöneuvottelu, on tekniikka, jolla voidaan vaikuttaa siihen, mikä versio sisällöstä tarjoillaan User-Agentille eli yleensä selaimelle ja sitä kautta käyttäjälle. Continue reading “Web-sivun kieli, osoitteessa vai ei?”

Kieli URL:ssä

Lue myös kaksiosaisen artikkelisarjan toinen osa: .

Kun kielitieto halutaan näyttää URL:ssä, miten ja missä kohtaa se ilmaistaan?

Monenlaisia kielikoodeja

Kielen voi useimmiten ilmaista riittävällä tarkkuudella kahdella merkillä. fi kertoo, että kieli on suomea. sv kertoo ruotsin olevan kielen. Toisin kuin suomea, ruotsia puhutaan hiukan eri tavalla useammassa maassa. On kuitenkin äärimmäisen harvinaista, että samasta dokumentista on olemassa versio sekä suomenruotsiksi että riikinruotsiksi.

Kaksi- tai jopa sitäkin useampiosaista koodia käytetään näissä harvinaisissa tapauksissa: Esimerkiksi sv-FI ilmaisee suomenruotsin. Käytäntö on kirjoittaa maakoodi isolla, primäärikieli pienellä, mutta näillä ei ole teknistä merkitystä. URL:ssä kaikkein käytettävintä on näyttää vain pieniä kirjaimia.

Ensisijaisesti kannattaa yksinkertaisuuden nimissä siis käyttää kaksimerkkistä kielikoodia ja käyttää moniosaisiakin vain silloin kuin niitä todella tarvitaan. Continue reading “Kieli URL:ssä”