Headless CMS -tuotteet Suomessa ja muissa Pohjoismaissa
Voi toki kysyä, onko headless CMS -markkina oma ja itsenäinen alueensa, mutta viime vuosien trendeissä headless on ollut varsin isossa roolissa. Siksi myös North Patrol on julkaissut erillisen katsauksen Suomessa yleisiin headless CMS -työkaluihin.
Suomessa Contentful on kiistaton pioneeri tällä alueella, ja tämä historia näkyy tämänkin selvityksen tuloksissa. Contentfulin osuus on selvästi suurempi kuin muilla kilpailevilla ratkaisuilla. Sama tilanne on muissakin Pohjoismaissa, Norjaa lukuunottamatta. Norjassa kotikentältä ponnistava Sanity on yleisin ratkaisu. Contentfulin pitkä historia ja panostukset paikalliseen edustukseen näkyvät kuitenkin hyvin tässä katsauksessa.
Allekirjoittanutkin on haastatellut Contentfulin toimaria ensimmäisen kerran vuonna 2014 Berliinissä, joten historiaa on jo kertynyt kohtuullisesti.
Viime vuosina Contentful on saanut osakseen paljon kilpailijoita, mutta monet tämän alueen työkalut ovat jääneet tähdenlennoiksi tai hiipuneet hyvin kapean asiakaskunnan työkaluiksi. Nyt ehkä aivan viime vuosina on norjalainen Sanity nostanut ainakin täällä pohjoisessa hieman päätään, mutta Sanitynkin asiakaskunta on vielä varsin pieni verrattuna Contentfuliin.
>> Lue North Patrolin datakatsaus: Rajapintalähtöiset CMS-tuotteet Pohjoismaissa
Headless CMS:t ovat täsmäratkaisuja räätälöityjen palveluiden sisällönhallintaan
Maailmanlaajuisesti Contentfulin tunnistetut sivustot ovat 40 000 sivuston luokkaa, Sanityn jäädessä noin puoleen tästä luvusta. Esimerkiksi jos tätä vertaa vaikka HubSpottiin, on HubSpotin vertailuluku huomattavasti isompi, noin 120 000 sivustoa. Täten lukumääräisesti asioita katsoen, ovat nämä headless CMS -tuotteet maailmallakin edelleen hyvin vahvasti täsmätyökaluja erityistilanteisiin.
Todellinen kilpailu tuleekin perinteisempien julkaisujärjestelmien ja verkkokauppa-alustojen suunnasta. Suomessakin kovin kilpailija lienee WordPress, joka on varmasti esimerkiksi Contentfulia isompi alusta headless-kentällä, jos lasketaan sivustojen määriä. Myös Drupalia käytetään headless-tyyppisesti varsin paljon. Osa headlessistä innostuneista tahoista kokeekin nämä kaupalliset tuotteet outoina ratkaisuina tällaisessä arkkitehtuurissa, koska jos arkkitehtuurin idea on vähentää sen CMS:n merkitystä ja siirtää se taustalle, miksi siitä pitää maksaa enemmän kuin aiemmin?
Saman ihmettelyn voi tehdä myös toiminnallisesta näkökulmasta, koska moni näistä tuotteista on vielä aika paljon jäljessä monia perinteisempiä CMS-ratkaisuja. Hinnoittelu saattaa kuitenkin olla isoissa ympäristöissä jo varsin kova (esim. Contentful), tai sitten todelliset hinnat ovat vielä selviämättä, koska asiakashankintaa tuetaan niin paljon riskirahalla (esim. Sanity).
Headless-tyyppinen mallihan ei käytännössä mitenkään edellytä erityistä headless CMS -tuotetta, koska käytännössä lähes kaikki julkaisujärjestelmät pystyvät tukemaan tällaista toteutusmallia. Headless CMS -tuotteiksi itseään kutsuvat tuotteet ovatkin käytännössä aina tuotteita, jotka ovat vain alusta asti luotu tukemaan pelkästään tällaista arkkitehtuurimallia, jossa sisällönhallintajärjestelmä jätetään taustalle, pelkkään sisältöpalasten hallintaan. Ne eivät siis ole mitenkään olennaisesti erilaisia tuotteita, kuin perinteisemmät julkaisujärjestelmät. Ne ovat yleensä vain yksinkertaisempia tuotteita, jotka tarjoavat sisällöt rajapintojen kautta ja jättävät varsinaisen esityskerroksen rakennettavaksi projektissa erikseen.
Asiakkaan kannalta headless ei todellakaan ole headless
Asiakkaiden kannalta se isompi keskustelu pitäisikin aina olla se, että tarvitsemmeko ja haluammeko sitoa itseämme toteutukseen, joka perustuu johonkin Javascript-kehyksellä toteutettavaan täysin räätälöityyn esityskerrokseen. Se, mikä headless CMS -tuote meillä on sen Javascript-pohjaisen verkkopalvelun takana, on huomattavasti pienempi ja ehkä jopa vähemmän merkityksellinen keskustelu. Ja tämä sama pätee vaikka Javascript-kehyksen sijasta ajatus olisi julkaista verkkopalvelu staattisena html-versiona hyödyntäen jotain sivustogeneraattoria tai vastaavaa ratkaisua.
Headless-termihän on ehdottomasti yksi oudoimmista slangitermeistä, joita tämä ala on kehittänyt. Jollain tavallahan se asiakkaille näkyvä palvelu pitää kuitenkin rakentaa, oli CMS:stä apua tai ei. Asiakkaiden näkökulmasta headless CMS on tavallaan auto ilman moottoria. Kyllä, se on halvempi, se on kevyempi, se ei kuormita ympäristöä, ei tarvitse lataamista, ja niin edelleen.
Useimmat asiakkaat kuitenkin haluavat autonsa jonkun moottorin kanssa, joten siksi pitäisi aina puhua myös siitä, että miten ne asiakkaille näkyvät verkkopalvelut sitten tehdään, jos CMS on mallia headless.
Alan toimistoille ja kehittäjille headless on kutsu buffet-pöytään
Toimistojen ja monien kehittäjien näkökulmasta headless-mallit ovat myös suhteettoman houkuttelevia, koska käytännössä kysymys on räätälöityjen ratkaisujen rakentamisesta uusimmilla vehkeillä mitä maailmasta löytyy. Liiketoiminnan näkökulmasta jokainen headless-projekti on helposti 2-3 kertaa isompi asiakkuus kuin perinteisen mallin vastaava projekti. Kehittäjien näkökulmasta jokainen headless-projekti on myös keino päästä tutustumaan uusimpiin tekniikoihin ja harjoittelemaan erilaisten rajapintojen ja sovelluskehysten kanssa työskentelyä. Monelle toimistolle tämä kehittäjien innostus on myös tärkeä tekijä, koska koodareiden korkea vaihtuvuus aiheuttaa nopeasti isoja ongelmia.
Ehkä juuri siksi moni toimisto näkee paljon vaivaa sen eteen, että yrittää keksiä headless-arkkitehtuurille hyötyjä myös asiakkaiden näkökulmasta. Valitettavasti se on aika hankalaa, eivätkä useimmat väitteet oikein kestä vettä.
Toimistot julkaisevat ahkerasti headless-mallia ylistäviä juttuja
Parin viime vuoden aikana on oikein kilpailtu sillä, että mikä toimisto julkaisee enemmän headless-mallia käsitteleviä blogiartikkeleita. Yhdistävä tekijä useimmille näille jutuille on lähes täysi kritiikittömyys mallia kohtaan. Tässä muutamia poimintoja alan toimistojen julkaisemista jutuista
Nitron juttu on alle vuoden ikäinen artikkeli, joten ennakko-oletus oli, että ehkä tässä olisi jo huomioitu hieman alalla käytyä keskustelua. Nitro ei kuitenkaan ole tällaiseen eipäs-juupas-väittelyyn lähtenyt, vaan ylistää headlessiä täysin kritiikittömästi: Miksi valita headless CMS? (Nitro, 23.3.2022)
”Headless CMS ja sivustogenerointi tarjoaa yrityksille (ja Nitron kaltaisille hybriditoimistoille) vapaat kädet suunnitella juuri sellaisen verkkopalvelun, jonka haluatte. Toteutusta ei rajoita teemat tai templatet, jotka on saneltu jostakin ylempää. Esimerkiksi verkkopalvelun käyttökokemus, saavutettavuus ja hakukoneoptimointi voidaan viedä aivan uudelle tasolle.”
Nitro on tässä omalla tavallaan suorastaan rehellinen. Headless todellakin tarjoaa vapaat kädet toimistoille suunnitella, toteuttaa, laskuttaa ja viedä moni asia aivan uudelle tasolle (ei välttämättä tosin paremmaksi).
Tietotalon artikkeli headless-arkkitehtuurista myös listaa pelkästään positiivisia asioita mallista, aivan kuin se olisi uudenlainen, täysin päästötön energiamuoto.
”Headless CMS -toteutustavan keskiössä on rajaton suunnittelu ja sujuva sisällönhallinta.
Headless CMS vapauttaa luomaan käyttäjäkokemukseltaan ainutlaatuisia palveluita, joissa voi yhdistellä niin sovellusmaisia toimintoja kuin eri datalähteitäkin. Tämä avaa lukemattomia mahdollisuuksia ja esimerkiksi sovelluksia tai verkkokauppaa voidaan rikastaa erilaisilla elämyksellisillä ja sitouttavilla sisällöillä.
Päättömissä järjestelmissä sisältörakenteita ja sisältötyyppejä voidaan luoda asiakkaan yksilöllisiin tarpeisiin rajattomasti. Samalla voidaan kehittää organisaation sisäisiä työnkulkuja ja yhteistyötä.”
Konkreettisuuden taso on sitä luokkaa, että kritiikkiä on oikeastaan vaikea edes esittää. On tietysti ymmärrettävää, että kun pohjimmiltaan kyse on siitä, että tehdään täysin räätälinä jotain, niin sehän voi sitten ollakin ihan mitä tahansa, joten kaipa sen hyödytkin voivat sitten olla mitä tahansa.
Pixelsin juttu parin vuoden takaa käsittelee aihetta perusteellisesti, mutta myös pääosin positiivisesti.
”Headless CMS vapauttaa suunnittelijoiden ja toteuttajien kädet luomaan ainutlaatuisia verkkopalveluita, joissa voi saumattomasti yhdistellä sovellusmaisia toimintoja, eri datan lähteitä ja interaktiivisia ominaisuuksia piittaamatta taustajärjestelmän rajoitteista.”
Tässä on hieman sama teema kuin edellisessä jutussa. Kaikki on paremmin, kun ei käytetä mitään tuotteita, eivätkä sisällöntuottajien vaatimukset pääse sotkemaan luovaa toteutusta.
Pixelsin jutun ansioksi voi kuitenkin sanoa sen, että juttu on kohtuullisen konkreettinen, sanoen aika tarkkaan sen, että mistä ne hyödyt oikein syntyvät.
”Verkkosivut voidaan esimerkiksi tarjoilla staattisen sivugeneraattorin luomina selaimelle. Toisin sanoen staattisia html-sivuja ja niiden sisältöjä, tyylejä ja kuvia ei tarvitse erikseen ladata palvelimelta. Ratkaisu mahdollistaa sen, että staattisella sivulla kaikki tieto on jo valmiina, mikä tekee sivuista äärettömän nopeita latautumaan. Tästä on hyötyä varsinkin käytettävyyden ja hakukoneoptimoinnin näkökulmasta, etenkin kun Googlen algoritmit nostavat nykyään sivuston latausnopeuden ja käytettävyyden entistä korkeampaan arvoon.
Headless-ratkaisussa kaikki data kulkee rajapinnan läpi, joka tarkoittaa että sisällönhallintajärjestelmään ei ole suoraa pääsyä käyttöliittymästä. Tämä tuo mukanaan merkittäviä tietoturvahyötyjä, kuten esimerkiksi vähentämällä taustahallinnan ylläpidon kirjautumisnäkymään kohdistuvia hyökkäyksiä.”
Staattisten sivujen hyötyjen korostaminen on monessa jutussa toistuva teema. Kovin moni ei kuitenkaan käytännössä käytä tätä mallia. Pixelsinkin artikkelissa todetaan myöhemmin, että heidän yleisin ratkaisu perustuu React-fronttiin. Tämäkin on yksi tämän aihepiirin kummallisuus. Asiakkaiden kannalta staattisten html-sivujen jakelu olisi yleensä malli, josta olisi enemmän käytännön hyötyjä, esimerkiksi hakukoneiden ja tietoturvan ja elinkaaren näkökulmasta.
Oma lukunsa ovat myös tietyn tuotteen ylivoimaisuudesta puhuvat toimistot, jotka yleensä kehuvat valittua tuotetta ylivertaisena ratkaisuna melkein mihin tahansa ongelmiin. Esimerkiksi Lamia on kirjoittanut useita juttuja Contentfulin ylivertaisuudesta ja soveltuvuudesta lähes mihin tahansa.
”Tiivistyksenä voidaan sanoa, että Contentful ja sen sisällönhallintajärjestelmän headless-lähestymistapa antaa mahdollisuuden viedä sisällön luominen ja hallinta pilvipohjaiseen prosessiin. Tämä puolestaan helpottaa kokonaisuutta poistaen teknisiä esteitä, jolloin voidaan keskittyä oleelliseen, eli tuoda käyttäjille parempaa sisältöä nopeammalla vauhdilla ja oikea-aikaisemmin.”
Suomessa etenkin Contentfulin ympärillä on jonkin verran tämäntyyppistä hypeä ollut viime vuosina. Osa näistä on myös lievän komiikan puolella olevaa tavaraa, kun huomioi että esimerkiksi verkkokauppamaailmassa Contentfulin käyttöönotto on yleensä hyvin pieni osa kokonaisprojektista, mutta toimittajan myyntipuheissa se voi näyttäytyä aivan mullistavana ja uudenlaisena ihmeratkaisuna.
Devisioonan artikkeli vuodelta 2021 aiheesta kuuluu ehdottomasti parhaimpiin juttuihin, joita toimittajapuolella on julkaistu. Juttu osaa käsitellä headless-arkkitehtuuria kriittisestikin, jopa pohtien sille sopivimpia käyttötapauksia.
”Moni toimittaja alalla puhuu headlessin puolesta lähes varauksettomasti. Devisioonan kokemukset viimeaikaisista asiakasprojekteista ja konsultointihankkeista kannustavat kuitenkin varovaisuuteen: Headlessin edut toteutuvat vain, jos niitä käytetään vastuullisesti ja niihin soveltuvissa hankkeissa. Valitettavasti IT-alalla on usein tapana lipsua kaidalta polulta.
Kehittäjäkokemuksen houkuttelevuus – mahdollisuus päästä tekemään töitä uusilla välineillä ja tavoilla – on ajoittain muuttunut itsetarkoitukseksi, ja lopputuloksena palveluiden kustannukset kasvavat, arkkitehtuuri monimutkaistuu ja toimintojoukko jää suppeammaksi kuin valmistuotteiden pohjalta.
Toisaalta rehellinen ja avoin tekninenkin analyysi on paikallaan: joissain tilanteissa voi olla, että esimerkiksi vanhakantainen verkkokaupan ulkoasukustomointi on niin hankalaa, että hyvin valmistautunut toimittaja tempaisee headless-ratkaisun pystyyn nopeammin kuin perinteisen täyden paketin toteutuksen. Tämä pitää paikkansa varsinkin, jos asiakkaan ulkoasu- ja toiminnallisuusvaatimukset eroavat tuotteen peruslinjoista. Näissäkin tapauksissa headlessin varjopuolena tulee mukana monimutkaisempi arkkitehtuuri, mutta tämä saattaa silti olla vaivan arvoista.”
Kovin kriittinen ei tosin Devisioonakaan ole, koska heidän näkökulmansa ovat hyvin toiminnalliset sovellukset, ja yleensähän headless-mallit toimivat aika hyvin silloin kun tehdään esimerkiksi jotain monimutkaista asiointipalvelua.
Valu Digital on myös toimisto, joka on kunnostautunut kirjoittamalla konkreettisia juttuja heidän käyttämästään headless-mallista. Valu kuuluu myös siihen hieman harvinaisempaan joukkoon, jonka headless-malli (Valu kutsuu malliaan Headup-malliksi) tuottaa nimenomaan staattisia sivuja lopputuloksena. Valun viimeisin artikkeli toteaa, että Valulla headless on nimenomaan tapa tarjota asiakkaalle korkeata tietoturvaa tilanteissa, joissa on todellisia riskejä siihen, että joku vihamielinen taho pyrkii estämään sivuston käytön tai pyrkii tekemään muuta haittaa sivustolle.
”Olemme pitäneet Headupin kohdalla tiukasti kiinni parista myyntiperiaatteista. Emme myy Headupia ”normaalina WordPressinä” asiakkaille, joilla ei oikeasti ole tarvetta huippukorkealle tietoturvalle ja kuormankestolle. Pystymme toteuttamaan erittäin korkean tietoturvan ja kuormankeston ratkaisut myös perinteisellä WordPressillä edistyneiden välimuistiratkaisujen avulla. ”
Tämä onkin hyvin sanottu, osaavat WordPress-toimittajat pystyvät pääsemään erittäin korkeatasoisiin toteutuksiin ihan ”tavallisilla” malleilla, eikä tällöin synny headless-toteutusten ongelmia sisällöntuotannon, kustannusten tai elinkaaren näkökulmasta.
Valun juttu tiivistää asiaa hyvin jutun lopussa:
”Lopuksi on hyvä korostaa, että Headup on erityisratkaisu poikkeuksellisiin tarpeisiin. Edelleen 95%:lle verkkosivustoista perinteinen WordPress-sivusto hyvin suojattuna ja välimuistitettuna on oikea ratkaisu. Headup puolestaan sopii, kun tarvitaan kustannustehokasta rajatonta skaalautumista ja korkeimman luokan tietoturvaa.”
Tämän näkökulman voi allekirjoittaa. Etenkin staattisina html-sivuina tehtävä sivusto skaalautuu mihin tahansa kuormapiikkeihin, oli sitten kyse Euroviisuista tai ydinräjähdyksestä tai pommi-iskusta tai mistä tahansa tapahtumasta, jonka seurauksena miljoonat ihmiset suuntaavat jonkun yksittäisen sivuston äärelle. Toinen näkökulma on juuri se äärimmäisen tietoturvan vaatimus. Jos halutaan käyttää kaikki keinot äärimmäisen tietoturvan toteuttamiseksi, on headless-tyyppinen malli, etenkin niillä staattisilla html-sivuilla tehtynä, varmasti vähemmän altis tietoturvaan liittyville virheille, joiden seurauksena jokin vihamielinen taho voisi kaapata sivuston tai sotkea paikkoja.
Kaikki tämä tietenkin myös maksaa, ja siksi Valukaan ei yritä tarjota heidän malliansa kaikille asiakkaille. Mallia tarjotaan niille asiakkaille, joiden vaatimukset ovat aidosti erityisiä ja joilla on varaa maksaa vaatimusten toteuttamisesta. Usein näiden asiakkaiden tarpeisiin ei myöskään kuulu joustavat vaatimukset digimarkkinoinnille sivuston optimointiin ja uusien laskeutumissivujen toteutukseen, joten kankeamman mallin haitat eivät tule silmille.
Ala on vaikeassa vaiheessa: vanha malli on osittain vanhanaikainen, uusi malli on vielä täysin epäkypsä
Täysin ei toimistoja voi syyttää käärmeöljyn myymisestä, koska Javascriptin merkitys on ilman muuta kasvussa, samoin esimerkiksi staattinen html-julkaisu on hyvä asia saada takaisin. Eikä julkaisujärjestelmien päälle kannata kaikkea mahdollista rakentaa, siitä on ihan hyvä ymmärrys alalla. Uudenlaisille malleille on siis tarvetta, mutta selvää on myös, että vielä ei olla siinä pisteessa, että nämä uudet mallit olisivat aina asiakkaidenkin kannalta järkeviä.
Esimerkiksi räätälöityjen sovellusten rakentaminen julkaisujärjestelmien päälle ei yleensä ole kovin järkevää, joten mitä monimutkaisempi oma verkkopalvelu on, sitä enemmän kannattaa harkita arkkitehtuurimalleja, joissa ei rakenneta kaikkea yhden kortin varaan. Joskus on myös aidosti tilanteita, joissa samat sisällöt pitää julkaista mobiilisovellukseen ja verkkopalveluihin, jolloin sisällönhallinta on ehkä syytä irrottaa yksittäisestä palvelusta omaksi saarekkeekseen.
Internet-palveluiden tekeminen siis monimutkaistuu ja moninaistuu koko ajan. Erilaiset tilanteet tarvitsevat erilaisia ratkaisuja, mutta tämä ei tarkoita sitä, että aiemmin toimivista ratkaisuista täytyisi luopua kokonaan. Eivät julkaisujärjestelmät esimerkiksi ole mihinkään häviämässä, vaikka moni kehittäjä saattaa näin toivoakin. Asiakkaiden kannalta katsottuna julkaisujärjestelmiä ja monia muita tuotteistettuja ratkaisuja tarvitaan jatkossakin, ehkä jopa enemmän kuin aiemmin. Rinnalle vain tulee paljon muutakin, ja näissä astetta monimutkaisemmissa tarpeissa saatetaan yhä useammin päätyä headless CMS -tuotteen asiakkaaksi.
On vain tunnistettava oikein ne hetket, kun näin kannattaa tehdä. Yhä useammin isot kokonaisuudet rakentuvat myös useista erilaisista palasista. Joku palanen voi tarvita headless CMS:n kaverikseen, ja joku toinen palanen viihtyy hyvin WordPressin päällä, esimerkiksi.
Asiakkailta vaaditaan paljon ymmärrystä, ehkä liikaakin
Täten nyt ollaan tilanteessa, jossa asiakkailla on ajoittain aika hankalia päätöksiä tehtävänään. Toisella puolella on vaihtoehto olla ”vanhanaikainen” ja tehdä sivusto WordPressillä tai Drupalilla tai jollain muulla alustalla. Toisella puolella taas on ”moderni” malli, jossa käytännössä tehdään räätälöity ratkaisu, josta maksetaan helposti 2-3 kertainen summa rahaa, ja lisäksi sitoudutaan räätälöidyn ratkaisun tuomaan kalliiseen ja haastavaan ylläpitovaiheeseen.
Ainakin toivoisi, että useampi asiakas ymmärtäisi, että alan toimistot eivät suinkaan ole puolueettomia neuvonantajia näiden ratkaisujen äärellä. Toimistojen kannalta on aina todella paljon parempaa liiketoimintaa puoltaa näitä ”moderneja” malleja, koska nämä tuovat aivan eri tavalla rahaa taloon. Se, että onko ratkaisusta asiakkaalle todellista hyötyä, on kuitenkin lopulta aina asiakkaan murhe, ei toteuttavan toimiston.
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
4 kommenttia on “Headless CMS -tuotteet Suomessa ja muissa Pohjoismaissa”
Kommentointi on suljettu.
Ville Huumo
Moi Perttu! Kirjoitin tuossa blogiartikkelin, jossa jatkan vielä headlessin hehkuttamista ja joidenkin usein kuultujen väitteiden debunkkausta.
https://we.knowit.fi/experience-fi/10-paatonta-vaittamaa-headlessista
Mitä autoihin tulee, niin suurin osa tehtaista on siirtynyt modulaariseen rakenteeseen. Tämä tarjoaa vapauden käyttää konsernin autoissa samoja moottoreita mutta helposti varioida käytettävää korirakennetta eri mallien ja merkkien mukaan. Kuluttajan näkökulmasta tehdas kuitenkin pitää huolen siitä, että kaikki palikat soivat yhteen.
Perttu Tolvanen
Kiitos kommentista, Ville.
Hyvä, että alalla syntyy keskustelua! Se on ehdottoman hyvä asia!
Olisikin hyvä, että joku WordPress-digitoimisto vastaisi tuohon teidän juttuun, vaikka epäilen, että jää ehkä tekemättä.
Ehkä se tärkein asia olisi se, että toimistot uskaltaisivat selvemmin puolustaa sitä omaa tekemisensä mallia. Siksi teidän ulostulo on oikein hyvä! Headlessinkin kohdalla ne isoimmat ongelmat syntyvät sellaisten firmojen tekeleistä, jotka eivät ole mitenkään omaa malliaan valinneet (vaan ovat vain vuokranneet jonkun tiimin asiakkaalle koodaamaan).
Teilläkin on Knowit Experiencessa selkeä malli, johon tuossa jutussa viittaattekin, eli suositte mallia, jossa lopputuloksena syntyy staattinen sivusto, ja taustalla oleva CMS on WordPress-merkkinen. Minusta tämä malli on yksi parhaita headless-malleja, koska sillä on selvät edut asiakkaankin näkökulmasta, eivätkä nämä edut ole täysin riippuvaisia toteutuksen laadusta (staattinen sivu on nopea latautumaan vaikka se taustaputki olisi koodattu miten huonosti). Toki tekin teette muillakin tavoilla, ehkä siksi tuo juttu ei ole niin napakka, kuin se voisi olla :)
Ehkä teidänkin kannattaisi puhua selvemmin siitä teidän edustamasta mallista. Sinunkin jutussasi kun väitetään monia asioita headlessistä, jotka eivät ole totta kuin hyvin tietyissä tilanteissa. Esimerkiksi nopeus ja korkeampi tietoturva ovat hyviä esimerkkejä asioista, jotka voivat toteutua, ja todennäköisesti toteutuvatkin, jos kyse on staattisen html:n julkaisemisesta, ja jos se CMS on tosiaan erotettu täysin siitä frontista. Mutta kuten itsekin jutussa toteat, headlessiä tehdään niin monilla eri tavoilla, että yleiset väitteet ovat tavallaan samanaikaisesti totta ja epätotta.
Tämä keskustelu tuntuu myös osittain samalta kuin millaista keskustelu oli WordPressin ympärillä vuosia sitten. WordPressiäkin haukuttiin monilla eri tavoilla, mutta sitten pikkuhiljaa kun osa toimistoista alkoi tekemään WordPressiä yhä vakiintuneemmilla ja hyväksi havaituilla tavoilla, alkoi sen maine parantua. Ja tavallaan se järjestelmä ei muuttunut mihinkään, vaan lähinnä toimistot ryhtyivät tekemään sillä järkevämmin ja kestävämmin asioita.
Headlessin kohdalla ollaan minusta vähän samantyyppisessä tilanteessa. Se on hyvä malli, joka voi olla monessa tilanteessa hyvä asiakkaalle, mutta se edellyttää sitä, että se on tehty hyvin. Ja todellisuus alalla ei tällä hetkellä ole vielä se, että useimmiten saisi hyvän headless-toteutuksen. Vähän sama tilanne siis kuin silloin WordPressin alkuaikoina. Nykyisin on jo aika paljon helpompaa ostaa laadukas WordPress-toteutus kuin 2015 (ei aivan triviaalia, mutta selvästi helpompaa). Headlessin kohdalla hyvän toteutuksen ostaminen vaatii todella osaavan asiakkaan ja myös aika vahvaa teknistä ymmärrystä siitä, mitä ollaan tekemässä.
Matti Uusitalo
Eniten tässä ihmetyttää Contentful käyttäminen joka on ihan omassa luokassaan hinnassa verattuna muihin ratkaisuun. Harvoin se kaikkein kallein on kaikkein käytetyin. Vai kertooko tämä siitä kuinka vähän näitä oikeasti käytetään.
Perttu Tolvanen
Täytyy myöntää, että Contentfulin suosio on itsellenikin aika mysteeri. Se on isossa skaalassa ihan järkyttävän hintainen lelu, etenkin suhteessa siihen mitä se tekee.
Luulen, että monelle organisaatiolle se on vain uinut sisään jostain nurkasta, ehkä jonkun sovelluksen sisältöpalasten hallintaan, sitten levinnyt pikkuhiljaa useampaan palveluun. Ja sitten kun sitä käytetään jo monen palvelun sisältöjen hallinnassa, niin kynnys ottaa joku toinen CMS, alkaa jo olemaan aika korkea. Sitten jossakin vaiheessa ihmetellään, että miten tää yks editointilelu (jota kaikki markkinointi-ihmiset yms sisällöntuottajat vihaa) voi maksaa 50k euroa vuodessa.
Devaajathan siitä tykkää, kun siinä ei tartte ymmärtää mitään siitä, miten CMS toimii. Nopean tekemisen kannalta se on hyvä systeemi, ei tartte ryhtyy miettimään sisältötyyppejä tai metatietomalleja, kun ryhtyy tekee, kunhan vaan tekee jotain.
Ja ehkä laskut maksavien asiakkaidenkin kannalta se on aika huoleton. Kunhan maksaa laskut, niin systeemi toimii, ei tartte olla mitään erityistä Contentful-kumppania, joka huolehtisi siitä (kuten esim. WordPressin kohdalla käytännössä pakko olla).
Se on siis kehitystiimin näkökulmasta aika ideaali monesti, mut eihän se oikein mikään sisällönhallinta- tai webbijulkaisutyökalu edes ole, enemmänkin sellainen random-sisältöpalasten varasto, jonka käytettävyys on täysin kiinni siitä, että onko joku asiakkaan puolella ymmärtänyt mitä ollaan tekemässä ja älynnyt pitää jotain kuria siinä, että miten sinne asiat jäsennellään ja rakennetaan. Täydellinen kaveri siis räätälitekemiselle, koska on just niin hyvä kuin sen pystyttävä tiimi :)