Kuubi on Suomen ensimmäinen Storyblok-ratkaisukumppani!

Vuodenvaihteessa saimme päätökseen prosessin, jossa toimitimme Storyblokille riittävästi tietoa osaamisestamme ja tekemistämme projekteista, jolloin pääsimme ratkaisukumppanien listalle. Ainoana Suomessa. Varsinainen kumppanuutemme alkoi kuitenkin jo heti kun Storyblok julkaisi kumppanuusohjelman. 

Käy tutustumassa caseen, jossa toteutimme Metso Outotecille virtuaalisen showroomin hyödyntäen Storyblokia sisällönhallintajärjestelmänä: https://kuubi.fi/showroom/metso-outotec

Miksi Storyblok?

Olimme etsineet asiakkaillemme hyvän käyttöliittymän omaavaa ja kohtuuhintaista julkaisujärjestelmää, joka vastaisi monikanavaisuuden tarpeeseen. Kollegani bongasi eurooppalaisen Storyblokin ja pienen tutustumisen jälkeen ymmärsimme, että heidän ratkaisunsa on timanttinen.

Miten monoliittiset julkaisujärjestelmät eroavat rajapintalähtöisistä? Mihin tarpeeseen Storyblok ja muut rajapintalähtöiset julkaisujärjestelmät vastaavat ja mitä kysymyksiä usein niiden käyttöönottoon liittyen herää? Käydäänpä tätä aihetta hieman läpi.

Monoliittiset julkaisujärjestelmät

Monoliitti

Perinteisesti verkkosivustojen sisältö on tuotettu monoliittisen arkkitehtuurin julkaisujärjestelmään. Tällainen järjestelmä toimittaa sisällön jo palvelimelta asti tiukasti sidottuna erilaisiin sivupohjiin, mikä johtaa siihen että sisältö on heikosti hyödynnettävissä muissa kanavissa. Monoliittisia julkaisujärjestelmiä kutsutaan myös perinteisiksi sisällönhallintajärjestelmiksi, koska suurin osa niistä on ollut markkinoilla kymmeniä vuosia ja niiden markkinaosuus on suuri. 

Suomessa tunnetuimmat monoliittiset julkaisujärjestelmät ovat WordPress, Joomla!, Drupal, Liferay, Episerver (nyk. Optimizely), Adobe Experience Manager, Umbraco ja Sitecore.

Rajapintalähtöiset julkaisujärjestelmät

Polyliitti

Erilaisten käyttöliittymien ja sovellusten nopea kehitys on synnyttänyt huiman valikoiman digitaalisia kanavia joita tukea. Samaa sisältöä voidaan haluta käyttää esimerkiksi verkkosivustolla, painetussa esitteessä, mobiilisovelluksessa tai vaikka virtuaalisessa, kolmiulotteisessa esittelytilassa, kuten meillä Kuubissa useasti tehdään. Tähän haasteeseen vastaa rajapintalähtöinen julkaisujärjestelmä (Headless CMS), tarjoamalla sisältöä käytettäväksi eri kanaviin.

Tämä joustavuus on se syy miksi rajapintalähtöinen julkaisujärjestelmä on nousussa. Tänään tehdään teknologiavalinta, joka tukee huomisen tarpeita, oli se tarve sitten Web3, Metaverse tai mikä tahansa seuraava villitys.

Suomessa tunnetuimmat rajapintalähtöiset julkaisujärjestelmät ovat Contentful, Ghost, Prismic, Sanity, DatoCMS ja Strapi.

Julkaisujärjestelmiä ympäröivät ekosysteemit

Julkaisujärjestelmien ympärille on rakentunut vuosien varrella ekosysteemeitä, jotka osaltaan vahvistavat niiden markkina-asemaa. On tiettyyn sisällönhallintajärjestelmään erikoistuneita järjestelmätoimittajia. On kehittäjiä, jotka tekevät elantonsa rakentamalla valmiita sivupohjia näihin julkaisujärjestelmiin. On konsultteja, jotka tuntevat hyvin näitä järjestelmiä, niiden toimittajia ja voivat olla määritys- ja kilpailutusvaiheessa asiakkaan apuna. 

Nämä ekosysteemit kertovat siitä, että markkina toimii ja tukea eri tarpeisiin on saatavissa. Joskus nämä ekosysteemit voivat kuitenkin hidastaa tarpeellista kehitystä. Koetaan muutosvastarintaa. Ei haluta luopua vanhasta ja hypätä uuteen, ennen kuin uusi järjestelmä on kasvattanut riittävän suuren käyttäjäkunnan, markkinaosuuden tai ekosysteemin. Tämä on luonnollista, mutta myös syy siihen miksi uusien järjestelmien on vaikea lyödä läpi, ja miksi niitä jätetään tarpeettomasti vähemmälle huomiolle.

Myös Gartner tunnistaa tämän haasteen vuosittaisessa nelikenttäanalyysissaan, jossa se jaottelee julkaisujärjestelmätoimittajat johtajiin, visionääreihin, markkinarakopelaajiin ja haastajiin. Toivotaan, että Storyblok pääsee nelikentälle tänä vuonna. Arvioiden perusteella se ainakin olisi mahdollista.

Määräävä tekijä minkä tahansa järjestelmän valinnalle tulisi kuitenkin olla, että se vastaa käyttäjiensä tarpeisiin.

Viestinnän ammattilaisten vaatimukset

Kyselyjen ja kokemukseni mukaan viestinnän ammattilaiset arvostavat ensisijaisesti sitä, että julkaisujärjestelmä on nopea käyttää ja helppo. 

On yleinen väärinkäsitys, että rajapintalähtöiset julkaisujärjestelmät ovat sisällöntuottajille hankalampia käyttää kuin perinteiset julkaisujärjestelmät ja Storyblok osoittaa tämän käsityksen vääräksi. Sen käyttöliittymä on intuitiivinen ja vastaa sisällöntuotannon tarpeisiin. Kun halutaan muokata jotain sisältöä, sitä osoitetaan, muokkaus aukeaa ja muokkauksen tuloksen näkee verkkosivuston kontekstissa välittömästi.

Jos olet aiemmin käyttänyt esimerkiksi Optimizelyä, jossa on erinomainen käyttökokemus, arvostat varmasti myös Storyblokin käyttökokemusta.

Julkaisujärjestelmää valitessa arvostetaan myös sitä, että se tukee tiettyjä toimintatapoja ja työkaluja. On pystyttävä tehdä luonnoksia, hyväksyntäkierroksia, käännöksiä, rajauksia käyttäjäryhmille sekä ajastettuja julkaisuja. On voitava analysoida sisällön toimivuutta ja reagoida muutostarpeisiin.

Esimerkki tarpeellisesta työkalusta voi olla lisäosa, joka toimittaa sisällön käännöstoimistolle ja palauttaa käännöksen julkaisujärjestelmään. Toinen on palvelu, joka mahdollistaa sisällön A/B-testauksen. Analytiikkaan ja liidien generointiin on omat työkalunsa.

Oleellista ei ole saako jonkin työkalun asennettua sivustolle julkaisujärjestelmän kautta, vaan se että saako sen asennettua. Nykyään useimmat lisäosat joka tapauksessa halutaan asentaa julkaisujärjestelmän sijasta esimerkiksi Googlen Tag Managerin kautta. Näiden asetusten hallinnan voi tarvittaessa rakentaa julkaisujärjestelmään.

Storyblok ei siis ota kantaa siihen millaisia lisäosia sivustolla haluat käyttää. Kaikki työkalut jotka ovat rakennettu kyseiseen kanavaan, toimivat varmasti myös Storyblokia käytettäessä.

Monikanavainen sisältö, mutta editointi yhtä kanavaa (verkkosivusto) vasten?

Saatat nyt miettiä, että jos Storyblokin editointi näkymä on hiottu toimivaksi verkkosivustoa vasten, eikö se aiheuta ongelmia sisällön viemisessä muihin mahdollisiin kanaviin?

On totta, että sisältöä luodessa tulee pitää mielessä sen uudelleen käytettävyys. On hyvä mallintaa sisältö (Content Modeling) alusta lähtien sellaisiksi kokonaisuuksiksi, että sisältö taipuu mahdollisimman vähällä työllä useisiin kanaviin. Ei esimerkiksi pilkota sisältöä tarpeettomasti liian pieniin kokonaisuuksiin, mutta toisaalta ei myöskään ympätä kaikkea samaan kenttään. Pidetään siis huolta sisällön muodosta. 

Storyblok tarjoaa tähän työkalut esimerkiksi uudelleen käytettävien sisältölohkojen (Blok) muodossa, ja rajapinnasta tulevaa sisältöä voi helposti mukauttaa eri päätelaitteille. 

Saat tarvittaessa verkkosivuston kontekstin pois esikatselusta ja tehtyä editoinnin kokonaan lomakenäkymässä, jos verkkosivuston konteksti ei ole oleellinen.

Useimmiten verkkosivusto on pääkanava sisällön esittämiseen ja sen vuoksi on sopivaa, että kun sisältöä luodaan, tehdään sisällön esikatselua juuri tuossa kontekstissa.

Miksi ohjelmistokehittäjät suosivat rajapintalähtöisiä julkaisujärjestelmiä?

Suurin syy oman kokemukseni mukaan on, että se mahdollistaa suuren joustavuuden siinä millaisen ohjelmointikehyksen päälle toteutuksen rakentaa. Jokainen kehittäjä voi käyttää itselle tuttuja työkaluja ja ympäristöjä.

Vertailun vuoksi suosituimpaan julkaisujärjestelmään, eli WordPressiin, kehittäminen on nykyään hidasta ja tuskallista. WordPressin editointipuolen käyttöliittymäuudistukseen (Gutenberg) oli aikoinaan kovat odotukset, mutta lopputulos on osoittautunut pannukakuksi. Eri toimijat tekevät hyvin erilaisia toteutuksia ja jopa sisällön mallintamiseen WordPressin Gutenberg-blockeille on tehty lisäosia (ja niille lisäosia). Editointipuolen esikatselunäkymätkään harvoin jos koskaan Gutenbergissä vastaavat sitä miltä sivusto todellisuudessa lopulta näyttää. Monet pysyttelevät tämän vuoksi edelleen Elementorin kaltaisissa lisäosissa, jotka tarjoavat samoja ominaisuuksia paremmalla käyttöliittymällä.

Jos verkkopalvelun ylläpito ja jatkokehitys halutaan myöhemmin siirtää toiselle toimittajalle,  erilaisten toteutusten kirjavuus aiheuttaa haasteita ja pahimmillaan johtaa toimittajaloukkuun (Vendor lock-in).

Näistä syistä myös perinteiset julkaisujärjestelmät kehittävät tukea rajapintalähtöisille toteutuksilleen.

Entä hakukoneoptimointi, vahingoittaako rajapintalähtöinen julkaisujärjestelmä hakukonenäkyvyyttä?

Toteutuksen voi tehdä monella tapaa ja on oltava huolellinen siinä, että valitsee kehitystyökalut jotka eivät haittaa hakukonenäkyvyyttä. Useimmiten SEO-ongelmat rajapintalähtöisten julkaisujärjestelmien kanssa ovat johtuneet siitä, että on luotu JavaScriptiin pohjaavia sivustototeutuksia, jotka eivät ole tarjonneet indeksoitavassa muodossa sisältöä hakukoneille. Nämä ajat ovat takanapäin ja esim. Next.js (React) ja Nuxt.js (Vue) osaavat ottaa hakukoneet huomioon ilman kyyneleitä. 

Next.js ja Nuxt.js ovat moderneja JavaScript-kehyksiä, joita käytetään nykyaikaisten verkkosovellusten rakentamiseen. Molempia voidaan käyttää luomaan staattisia sivustoja, jotka vastaavat Jamstack-arkkitehtuurin vaatimuksiin. Tämä tarkoittaa mm. hyvää hakukonenäkyvyyttä ja nopeita sivustoja.

Varsinainen hakukoneoptimointi on edelleen pitkäjänteistä käsityötä, aivan kuten perinteisten julkaisujärjestelmien kanssa.

Kuinka voimme auttaa?

Tarvitsetko uutta verkkopalvelua, tai ovatko tarpeesi muuttuneet niin, että tarvitset tukea useampia kanavia? Me Kuubilla autamme mielellämme teitä toteuttamaan ratkaisun, joka samaan aikaan tukee useita kanavia ja tuntuu myös kivalta käyttää.

Ota yhteyttä helou@kuubi.fi niin kartoitetaan tarpeesi.