English
Français
Deutsch
PolskiJos haluat tehdä jotain kunnolla, tee se itse. Tekoälyn avulla.
Verkkosivustomme latautuu nyt alle sekunnissa. Salamannopeasti.
Aiemmin tällä viikolla, 21. lokakuuta, julkaisimme kokonaan uudelleen rakennetun verkkosivustomme. Suorituskyky ei kuitenkaan ollut ainoa syy uudistukseen.
Lähes jokainen pienyritys ja markkinointitiimi tunnistaa varmasti useita näistä ongelmista.
Sinulla on idea.
Tiedät, mitä haluat kertoa.
Tiedät, miltä sen pitäisi näyttää.
Ja miten palvelusi pitäisi esitellä.
Mutta…
Koottavana on niin paljon osioita, kuvia ja muita elementtejä. Sinun tarvitsee vain muotoilla kaikki ja saada kokonaisuus näyttämään oikealta, mutta jotenkin siihen kuluu lopulta kokonainen päivä.
Turhautuminen
Käytät liikaa aikaa ideoiden ja määrittelyjen muuttamiseen verkkosivuston sisällöksi sekä sen varmistamiseen, että lopputulos näyttää hyvältä ja vastaa alkuperäistä näkemystäsi.
Ja tietenkin haluat julkaista sisällön mahdollisimman nopeasti, tehdä muutoksia matkan varrella ja korjata asioita, kun lopputulos näyttää erilaiselta kuin alun perin kuvittelit. Muutoksesi voivat kuitenkin helposti pudota tärkeysjärjestyksessä toiselle tai kolmannelle sijalle. Sivuston odottamaton toiminta, tekninen monimutkaisuus tai lisäominaisuuksien tarve voivat viivästyttää julkaisua ja jättää ideasi odottamaan tehtäväjonoon.
Vanha sivustomme oli hidas, kömpelö ja vaikea ylläpitää. Käyttöliittymään oli kertynyt paljon parannuksia ja epäyhtenäisiä komponentteja. Perinteisesti tällainen uudistus tehtäisiin vaiheittain: ensin siirrettäisiin nykyinen sivusto, sitten yhtenäistettäisiin komponentit ja lopuksi otettaisiin käyttöön uusi ulkoasu. Sadoista sivuista huolimatta päätimme kuitenkin tehdä kaiken kerralla.
Miten siis jätimme WordPressin ja PHP:n taaksemme ja siirryimme johonkin virtaviivaisempaan, nopeampaan ja modernimpaan, jossa on myös ripaus pumpkin spice latten tunnelmaa? Tässä katsaus matkaamme kohti Next.js:ää ja Payload CMS:ää. Samaan aikaan suunnittelijamme työsti uutta UI/UX-suunnittelua, ja Codex hoiti koodin generoinnin, toteutuksen ja käyttöönoton.
Ongelma ei ollut vain verkkosivusto
Olin sietänyt verkkosivustomme teknisiä ja toiminnallisia ongelmia noin vuoden ajan.
Tekninen velka
Verkkosivustomme oli ollut käytössä seitsemän vuotta. Sinä aikana sen parissa oli työskennellyt monia ihmisiä, joista jokainen toi mukanaan omat ideansa ja toimintatapansa. Teknistä velkaa kertyi jatkuvasti. Komponentteja ei ollut yhtenäistetty, vaikka ne näyttivät samanlaisilta. Sivujen lataaminen kesti keskimäärin viidestä kuuteen sekuntia, ja joidenkin sivujen lataaminen vei jopa kymmenen sekuntia.
Monta välivaihetta
Vaikka sisältö oli valmis, sen julkaiseminen tarkoitti kirjautumista sisällönhallintajärjestelmään, tekstin kopioimista käsin Wordista, muotoilua, kuvien lisäämistä ja yksittäisten osioiden säätämistä. Sisältöpäivitys, jonka olisi pitänyt olla yksinkertainen, saattoi helposti viedä kokonaisen päivän.
”Yksinkertaiset” muutokset
Tekninen velka teki yksinkertaisistakin muutoksista painajaisen. Komponentit, joiden olisi pitänyt olla uudelleenkäytettäviä, oli toteutettu erikseen, mikä vaikeutti sivuston yhtenäisyyden ylläpitämistä. Laskeutumissivun lisääminen, palvelukuvauksen päivittäminen tai uuden idean toteuttaminen vei keskimäärin noin kuukauden, joskus useita kuukausia.
Suurempi ongelma oli kuitenkin se, miten vaikeaa osaamistamme ja ideoitamme oli välittää suoraan mahdollisille asiakkaille.
Yrityksen omistajana ja perustajana keskustelen säännöllisesti asiakkaiden kanssa, perehdyn heidän tarpeisiinsa ja osallistun teknisten ratkaisujen arkkitehtuurin suunnitteluun kehitystiimimme kanssa.
Kehittäjämme työskentelevät suoraan asiakkaiden kanssa. He tietävät, millaisia ongelmia asiakkaat kohtaavat ja mikä voisi parantaa heidän liiketoimintaansa, ja heillä on usein hyviä, jakamisen arvoisia ideoita. Sama koskee myyntitiimiämme, joka keskustelee jatkuvasti asiakkaiden kanssa ja tunnistaa heidän haasteitaan ja tarpeitaan.
Kysymys kuuluu: miten lyhennämme näiden ideoiden ja asiakkaan välistä matkaa säilyttäen samalla kirjoittajan alkuperäisen näkemyksen ja tarkoituksen?
Näin työskentelimme ennen
Aiemmin noudatimme perinteistä sisällöntuotantoprosessia.
1. Haastattelu ja valmistelu
Ensin kerättiin näkemyksiä kehittäjältä. Sen jälkeen artikkelille laadittiin määrittely, joka sisälsi hakukoneoptimoinnin avainsanat, mahdolliset kuvat ja muut vaatimukset.
2. Tekstin ja ulkoasun suunnittelu
Määrittely siirtyi sisällöntuottajalle ja suunnittelijalle. Pelkästään tekstin ja muun aineiston luominen saattoi viedä viikon.
3. Toteutus
Toteutus tarkoitti kuvien luomista, jokaisen kappaleen kopioimista ja liittämistä sisällönhallintajärjestelmään sekä jokaisen kappaleen ulkoasun muokkaamista käsin, jotta sivu näyttäisi oikealta.
4. Tarkistukset ja merkittävät muutokset
Tarkistusten yhteydessä jouduimme usein tekemään merkittäviä muutoksia, koska alkuperäinen tekninen idea oli tulkittu matkan varrella eri tavalla. Se, mitä kirjoittaja halusi kertoa, ei välttämättä vastannut sitä, mitä artikkeliin lopulta päätyi. Sitten palattiin vaiheeseen 3 tekemään muutokset.
5. Julkaisu
Lopuksi artikkeli julkaistiin.
Ymmärsin, että tekoäly voisi auttaa poistamaan nämä tarpeettomat välivaiheet.
Näin työskentelemme nyt
On tärkeää, että kirjoittaja päättää itse, miten idea välitetään, sen sijaan että nämä päätökset ja toteutus jätetään kokonaan sisällöntuottajalle tai suunnittelijalle. Kirjoittaja voi esittää selkeämpiä konsepteja, jolloin suunnittelijat ja hakukoneoptimoinnin asiantuntijat voivat keskittyä täsmällisesti ideaan ja kirjoittajan näkemykseen.
1. Kirjoittaja kuvailee idean ja asettelun
Kirjoittaja kuvailee ongelman, tehdyn työn ja saavutetut hyödyt. Sen jälkeen hän kertoo, miten artikkeli pitäisi jäsentää, ja ehdottaa kuvia, sisältölohkoja ja kaavioita.
2. Tekoäly valmistelee sisällön ja visuaalisen aineiston
Tekoäly muuttaa kirjoittajan ohjeet artikkeliksi, luo visuaalista aineistoa ja sijoittelee kuvat, kaaviot ja rakenteiset sisältölohkot sivulle.
3. Kirjoittaja tarkistaa ja viimeistelee
Kirjoittaja tarkistaa, että lopputulos vastaa alkuperäistä ideaa ja tarkoitusta, ja ohjaa sitten tekoälyä muokkaamaan sanamuotoja, visuaalista aineistoa tai asettelua.
Ja muutokset, jotka aiemmin veivät päivän, voivat nyt valmistua vain minuuteissa.
Tämä artikkeli on itsessään hyvä esimerkki. Sanelen ajatuksiani, jotka eivät aina ole kovin jäsenneltyjä. Sitten luen tuloksen, tarkistan sen, siirtelen kappaleita, täsmennän ongelmien kuvauksia tai annan yksinkertaisesti kehotteen: "Näytä nämä ongelmat sivulla erillisinä lohkoina."
Halusin luoda juuri tällaisen kokemuksen: verkkosivuston, jolla aiheensa todella tuntevat ihmiset voivat viestiä ideoistaan suoraan, hioa niitä heti ja julkaista ne ilman tarpeettomia siirtoja ihmiseltä toiselle.
Tekoälyn pitäisi tuoda työn tekijät lähemmäs asiakasta eikä luoda heidän välilleen uutta kerrosta.
Tylsä osuus: korjataan se, mitä meillä jo on
Aloitin sivuston uudistamisen 1. lokakuuta 2026.
Ensimmäinen ajatukseni oli suoraviivainen: siistitään nykyinen sivusto, refaktoroidaan koodipohja, poistetaan tarpeeton toisto ja parannetaan suorituskykyä.
En kuitenkaan pystyisi tuottamaan valtavasti koodia lyhyessä ajassa, joten päätin käyttää Codexia.
Kävin PHP-koodin läpi ja huomasin, että lähes jokaisessa sivupohjassa oli huomattavan paljon päällekkäistä koodia.
Epäyhtenäiset toteutukset
Eri ihmiset olivat toteuttaneet samankaltaisia osioita erilaisin menetelmin ja eri näkemyksin siitä, miten asioiden pitäisi toimia.
Epäyhtenäiset visuaaliset tyylit
Sama ongelma näkyi ulkoasussa. Samaan tarkoitukseen tehdyt komponentit näyttivät eri sivuilla erilaisilta, ja värit, reunukset sekä elementtien väliset etäisyydet vaihtelivat.
Koodin siistiminen ennen yhtenäistämistä
Päätimme suunnittelijamme kanssa yhtenäistää sivuston tyylit ja komponentit. Ensin halusin kuitenkin saada nykyisen koodipohjan kohtuulliseen kuntoon.
Codexin avulla pystyin erottamaan uudelleenkäytettäviä komponentteja, poistamaan sivujen välistä päällekkäisyyttä, pienentämään koodipohjaa ja parantamaan suorituskykyä.
Kiinnostavaa oli, että kehotteet olivat varsin yksinkertaisia.
Esimerkiksi:
Ota tämä osio, [anna renderöidyn HTML-sivun osion tunniste], korvaa se ja erota siitä uudelleenkäytettävä komponentti. Tarkista kaikki muut sivuston sivut ja korvaa vastaavat toteutukset uudella komponentilla. Muista poistaa lopuksi kaikki vanha ja käyttämätön koodi ja tarkistaa työsi.
Siinä se käytännössä oli.
Pystyin tunnistamaan osion renderöidystä HTML:stä, antamaan sen tunnisteen Codexille ja pyytämään sitä erottamaan toteutuksen uudelleenkäytettäväksi komponentiksi.
Sen jälkeen se pystyi etsimään vastaavat toteutukset eri puolilta sivustoa, korvaamaan ne ja poistamaan vanhan koodin.
Matkan varrella löysin paljon muitakin ongelmia.
Esimerkiksi jotkin navigointivalikon kuvakkeet näytettiin 32 pikselin kokoisina, mutta niiden kuvatiedostot olivat noin yhden megatavun kokoisia.
Kuvittele lataavasi megatavun kuvan vain pienen navigointikuvakkeen näyttämistä varten.
Pyysin siis Codexilta:
Ota [kuva], analysoi se, suurenna tarvittaessa ja muunna WebP-muotoon. Optimoi se sivun latausnopeutta varten, muuta se todelliseen näyttökokoon (esimerkiksi 32 × 32 pikseliä) ja pienennä tiedostokokoa mahdollisimman paljon tinkimättä visuaalisesta laadusta.
Toistimme tämän eri puolilla sivustoa: korvasimme tarpeettoman suuret kuvat ja siistimme koodipohjaa.
Ja se toimi.
Ennen
Noin viidestä kuuteen sekuntia. Keskiarvo: 5,7 sekuntia.
Jälkeen
Alle kaksi sekuntia. Keskiarvo: 1,7 sekuntia.
Se oli varsin vaikuttavaa.
Työskentelin tämän ensimmäisen vaiheen parissa 1.–10. lokakuuta noin neljä tuntia työpäivässä, viikonloput pois lukien.
Käytin siis noin 28 tuntia PHP-koodipohjan siistimiseen ja nykyisen WordPress-sivustomme optimointiin.
Tässä vaiheessa luulin teknisten muutosten olevan valmiit.
Tarvitsimme enää suunnittelijaltamme viimeistellyn uuden ilmeen, ja voisimme jatkaa eteenpäin.
Pidin siis tauon aktiivisesta kehityksestä.
Tilanne kuitenkin paheni odottamatta.
Häiriö 12. lokakuuta: sivusto lakkasi toimimasta
En työskennellyt aktiivisesti sivuston parissa 10.–12. lokakuuta, mutta seurasin palvelimemme mittareita silloin tällöin.
Huomasin ajoittaisia piikkejä muistin ja suorittimen käytössä.
Sivusto toimi, mutta jokin ei selvästi ollut kunnossa.
Sitten, noin 12. lokakuuta, sivusto lakkasi toimimasta.
Aluksi ajattelin, että syynä saattoivat olla äskettäin tekemäni muutokset.
Aloin tutkia asiaa ja käytin myös ChatGPT:tä nykyisen sivuston ja palvelimen asetusten selvittämiseen.
Selvityksen perusteella ongelma ei vaikuttanut johtuvan koodimuutoksistani.
PHP-työprosessit näyttivät jumittuvan käsitellessään GTranslateen liittyviä pyyntöjä. Käytimme tätä lisäosaa sisällön reaaliaikaiseen kääntämiseen.
Pyyntöjä kertyi jonoon, ne kuluttivat palvelimen vapaat resurssit ja lopulta sivusto lakkasi vastaamasta.
Ongelma näytti olevan siinä, että pyyntöjä kertyi jatkuvasti lisää, kunnes käytettävissä olevat resurssit loppuivat.
Sivustomme toimi palvelimella, jossa oli 2 Gt RAM-muistia ja kaksi suoritinta. Olisin odottanut sen riittävän sivustollemme.
En tarkoita, että GTranslate olisi huono tuote.
Ongelma oli luultavasti usean infrastruktuuriimme liittyvän tekijän yhteisvaikutus. Lisäosa edellytti meiltä aktiivista ylläpitoa ja säätämistä, jotta kaikki toimisi oikein.
Tiesin, että ongelma voisi toistua. Meillä oli myös melko paljon lisäosia, jotka oli käytännössä otettu käyttöön, jotta suhteellisen yksinkertaisia toimintoja, kuten yhteydenottolomakkeita, käännöksiä ja muutamia muita ominaisuuksia, ei tarvitsisi ohjelmoida itse.
Monet näistä lisäosista olisi helppo poistaa tai korvata. Ihannetapauksessa uusi sisällönhallintajärjestelmä hoitaisi niiden toiminnot suoraan.
Ja jos halusimme ylläpitää ja tukea sivustoamme itse, oli järkevää siirtyä PHP:stä johonkin, jonka jokainen Salesforce-kehittäjä osaa ulkoa: JavaScriptiin.
Siksi valitsimme palvelinpuolelle Node.js:n.
Uudelleenrakennus Node.js:n, Next.js:n, Reactin ja Payload CMS:n avulla
Aloitin siis sivuston rakentamisen uudelleen 12. lokakuuta.
Halusin vähentää riippuvuutta lisäosista ja rakentaa yhtenäisen alustan, jossa olisi sisällönhallinta, integroidut käännökset ja hallittavissani oleva rakenne.
JavaScript ja Node.js ovat minulle tuttuja, ja olin aiemmin toteuttanut niillä useita projekteja.
Miksi Payload CMS?
Koska se rakentuu Next.js:n ympärille, ja Next.js vaikutti minusta varsin hyvältä vaihtoehdolta.
Halusin ratkaisun, jossa voisin käyttää tuttua teknologiapinoa sen sijaan, että ottaisin käyttöön taas uuden joukon työkaluja ja riippuvuuksia.
Payload ja Next.js antoivat myös järkevän arkkitehtuuripohjan, joten kaikkea ei tarvinnut keksiä alusta.
Ja kyllä, teki mieli vain sanoa agentille:
Kirjoita koko WordPress-sivusto uudelleen haluamallani Node.js-, Next.js-, React- ja Payload CMS -teknologiapinolla. Tee se oikein ja kunnolla, tarkista kaikki, käytä aliagentteja äläkä häiritse minua.
Minun oli kuitenkin edettävä toista kautta.
Ensin rakensin Payload CMS:stä perustason käyttöön otettavan version ja käynnistin sen tyhjästä.
Sen jälkeen aloin rakentaa Reactilla käyttöliittymäsovellusta ja käytin nykyisiä sivupohjia ja komponentteja refaktoroinnin lähtökohtana.
Ensimmäinen alfaversio oli käytännössä suora siirto tietokantaa lukuun ottamatta.
Lisäsimme useita uusia tietokokonaisuuksia ja järjestimme sisällönhallinnan uudelleen. Halusin CMS:n käyttökokemuksen muistuttavan enemmän Pipedrivea tai HubSpotia: navigointi vasemmalla ja sisältö oikealla.
Nykyisen sivuston siirtäminen
On tärkeää mainita, ettemme rakentaneet koko sivustoa tyhjästä.
Meillä oli jo sisältöä, sivurakenteita, suunnitteluideoita ja vuosien työ takana.
Tämä on itse asiassa luultavasti sivustomme neljäs suuri versio.
Aloitimme vuonna 2019 Flaton-nimisellä WordPress-teemalla. Meillä oli silloin jopa eri logo.
Myöhemmin kehitimme oman teemamme, päivitimme sitä ja jatkoimme käyttöliittymän parantamista.
Suunnittelijamme oli myös työskennellyt uusimman design-järjestelmän parissa jo ennen tämän siirron alkua.
Kyse oli siis olemassa olevan sivuston täydellisestä teknisestä siirrosta ja uudelleenjärjestelystä, ei kokonaan uuden tuotteen rakentamisesta tyhjästä.
Sisällön siirtoa varten poimimme kaiken WordPressistä ja käytimme tekoälyagenttia kohdistamaan sen uuteen Payload CMS:n tietokantamalliin.
Agentti auttoi muokkaamaan sisällön uuteen rakenteeseen sopivaksi sen sijaan, että kaikki olisi vain kopioitu toiseen tietokantaan.
Käytimme agentteja myös uuden sivuston käyttöönottoon, PHP-toteutuksesta siirtymiseen sekä vanhojen PHP-tiedostojen ja asetusten siivoamiseen palvelimelta.
Oliko se kaikkein tyylikkäin ratkaisu?
Ei luultavasti.
Mutta meille se oli nopein tapa siirtää kaikki ja saada sivusto toimimaan.
Uudelleenkirjoituksessa rikkoutuneiden asioiden korjaaminen
Kun ensimmäinen uudelleenkirjoitus oli valmis, edessäni oli käytännössä sama sivusto muutamin pienin eroin.
Sitten aloin korjata virheitä.
Jossain liukusäädin ei enää toiminut. Jossain sivun rakenne oli siirtynyt paikaltaan. Jotkin komponentit eivät käyttäytyneet aivan kuten ennen.
Näitä ongelmia korjatessani huomasin, ettei kaikkia komponentteja ollut korvattu kunnolla.
Joissain sivupohjissa oli edelleen raakaa HTML:ää, kun taas toisiin oli tehty uusia komponentteja, jotka muistuttivat hieman jo olemassa olevia uudelleenkäytettäviä komponenttejamme.
Aloin siis tunnistaa ja luetteloida näitä kohtia sekä korjata niitä yksi kerrallaan.
Kehote oli suunnilleen tällainen:
Hei, tässä on osio [anna osion nimi tai tunniste]. Korvaa se nykyisellä uudelleenkäytettävällä komponentilla [anna komponentin nimi]. Säilytä sama tai vastaava semantiikka ja toiminta, poista vanha toteutus ja siivoa käyttämätön koodi.
Jatkoin vanhojen toteutusten korvaamista, palvelinpuolen renderöinnin parantamista, välimuistin käyttöönottoa ja komponenttien optimointia.
Käytin 12.–23. lokakuuta tähän toiseen vaiheeseen noin neljä tuntia työpäivässä, yhteensä noin 32 tuntia.
Yksi agentti toteuttaa, toinen tarkistaa ja ihminen päättää
Kiinnostavaa oli myös se, miten järjestin kehityksen ja käyttöönoton.
Sen sijaan, että olisin käyttänyt yhtä agenttia kaikkeen, loin useita agentteja, joilla oli omat vastuualueensa: yksi selvitti vanhan toteutuksen, toinen toteutti nykyisen käyttöliittymän uudella alustalla, muut tarkistivat toteutuksen ja yksi hoiti käyttöönoton.
Loin myös uudelleenkäytettäviä taitoja eli skill-ohjeita, jotka sisälsivät käyttöönoton skriptejä, testausta ja validointia koskevat ohjeet. Näin agentit saattoivat noudattaa samoja prosesseja ilman, että kaikkea tarvitsi selittää joka kerta alusta.
Näissä skill-ohjeissa kerrottiin, miten suunnittelujärjestelmässämme toimitaan, miten suunnittelutokeneita käytetään uudelleen ja miten vasta käyttöön otettujen ohjelmistokehysten kanssa työskennellään.
Miksi skill-ohjeita? Niiden avulla agentit voivat hyödyntää samaa tietoa ja samoja ohjeita uudelleen ilman, että jokaista yksittäistä tehtävää varten täytyy luoda oma pitkälle erikoistunut agenttinsa.
Koodikatselmoinnissa tukeuduin vahvasti Gitin diff-näkymiin. Etsin muutoksista päällekkäistä koodia, tarpeetonta monimutkaisuutta ja epäyhtenäisiä toteutuksia. Aina kun löysin jotakin tällaista, pyysin agentteja korjaamaan sen.
Koska Next.js ja Payload CMS tarjoavat jo vakiintuneet arkkitehtuurimallit, ohjeistin agentteja noudattamaan niiden käytäntöjä oman arkkitehtuurin keksimisen sijaan.
Annoin myös erillisille agenteille tehtäväksi tarkistaa toteutuksen.
Prosessi oli varsin suoraviivainen:
Yksi agentti toteuttaa, toinen tarkistaa ja ihminen päättää, mikä on oikein ja mikä väärin.
Ja ihminen tarkastelee varsinaista sivustoa, ei pelkkää koodia.
Tarkistimme käyttöliittymää käsin, katsoimme, miten sivut renderöityivät, testasimme komponentteja ja etsimme visuaalisia ongelmia, joita ei välttämättä huomaa pelkästään koodia katselmoimalla.
Noin 30 % ajastani kului koodin katselmointiin, toteutusten tarkistamiseen ja tulosten varmistamiseen.
Lisäsin myös agenttien tekemiä tarkistuksia ennen käyttöönottoa, jotta jäljellä olevat ongelmat löytyisivät ja toistuvien muokkauskierrosten jäljiltä jäänyt koodi siistiytyisi.
Tekoäly nimittäin tuottaa valtavasti koodia.
Jos kukaan ei kiinnitä huomiota sen tuottamaan koodiin, vanha tekninen velka voi helposti vain vaihtua uudeksi.
Sivuston kääntäminen tekoälyagenttien avulla
Toinen tärkeä osa toteutusta olivat käännökset.
Aiemmin käytimme GTranslatea sisällön reaaliaikaiseen kääntämiseen.
Tällä kertaa halusin hoitaa käännökset suoraan omalla alustallamme.
Käytimme tekoälyagenttia kääntämään englanninkielisen sisältömme sivuston kaikille muille kielille.
Kehote oli seuraava:
Käännät sisältöä englannista kielelle [kohdekieli].
Analysoi sisällön englanninkielinen versio ja tunnista brändien nimet, teknologiakohtaiset termit, tuotenimet ja muut erisnimet.
Varmista ennen kääntämistä, että ymmärrät alkuperäisen tarkoituksen ja sisällön täsmällisen merkityksen. Säilytä käännöksessä alkuperäinen merkitys ja tarkoitus mahdollisimman tarkasti ja noudata samalla kohdekielen kielioppia. Kohdekieli: [kohdekieli].
Säilytä brändien nimet, tuotenimet ja teknologiakohtainen terminologia tarvittaessa.
Tarkista käännöksesi lopuksi ja varmista, että merkitys on säilynyt, kieli kuulostaa luontevalta eikä mitään sisältöä ole jäänyt pois.
Käännä kaikki sisältö, myös artikkelin otsikko, väliotsikot, leipäteksti ja kaikki siihen liittyvät metatiedot.
Tavoitteena ei ollut vain kääntää sanoja. Halusin sisällön noudattavan kohdekielen käytäntöjä ja kuulostavan paikallisille lukijoille luontevalta.
Pidimme myös brändikohtaiset tiedot erillään käännettävästä sisällöstä, jotta yritysten nimet, tuotenimet ja muut tärkeät termit eivät kääntyisi väärin.
Nyt voimme hallita käännöksiä suoraan CMS:ssämme ilman lisäosaa, joka kääntää kaiken reaaliajassa.
Tekoälykäännökset eivät tietenkään ole täydellisiä, varsinkaan Salesforcea, CRM:ää ja ohjelmistokehitystä käsittelevissä teknisissä sisällöissä.
Jos siis käytte sivustollamme omalla kielellänne ja huomaatte, että jokin kuulostaa epäluontevalta, on huonosti kirjoitettu tai ei käy järkeen, lähettäkää minulle yksityisviesti.
Korjaan asian.
Kun Figma, Codex ja GPT-6 kohtasivat
Sillä välin suunnittelijamme sai uuden design-järjestelmän valmiiksi Figmassa. Tässä kohtaa asiat alkoivat muuttua kiinnostaviksi.
Figma tukee MCP-integraatiota, ja käytämme jo OpenAI:ta Salesforcen ja muiden alustojen kanssa. Yhdistin siis Figman OpenAI-tiliini.
Näin pystyin ottamaan linkin Figman solmuun, oli se sitten painike, osio tai muu komponentti, ja antamaan sen GPT-6:ta käyttävälle Codexille. Codex otti suunnitelman ja toteutti sen suoraan sivustollemme.
Aiemman komponenttien erottelutyön ansiosta se pystyi soveltamaan uutta design-järjestelmää eri sivuille sen sijaan, että samat muutokset olisi toteutettu erikseen joka paikassa. Sen sijaan, että kirjoittaisin CSS:n käsin ja säätäisin jokaisen sisämarginaalin, kulman pyöristyksen ja komponentin asettelun, pystyin hyödyntämään suunnittelijan Figma-työtä ja toteuttamaan sen koodipohjassa.
Täysin automaattista se ei tietenkään ollut. Minun piti edelleen tarkistaa koodi, HTML-rakenne, komponenttien toiminta ja kohdat, joissa OpenAI oli saattanut oikaista tai ymmärtää vaatimukset väärin.
Kukin komponentti vaati keskimäärin noin kaksi kierrosta.
Ensimmäisellä toteutettiin ulkoasu. On eri asia saada komponentti näyttämään samalta kuin Figmassa.
Toisella korjattiin puuttuvat toiminnot, palautettiin kadonnut logiikka tai sovitettiin ulkoasu komponentin todelliseen toimintaan. Toiminnan oikeellisuuden ja ominaisuuksien säilymisen varmistaminen on toinen asia.
Juuri siihen keskityin eniten.
Mitä oikeasti saavutimme
Ennen
Noin viisi tai kuusi sekuntia.
Jälkeen
Keskimäärin alle sekunti.
Uuden Node.js-toteutuksen, välimuistin, palvelinpuolen renderöinnin ja muiden optimointien ansiosta sivut latautuvat nyt keskimäärin alle sekunnissa. Ennen uudistusta aikaa kului noin viisi tai kuusi sekuntia.
artikkelien luominen ja päivittäminen
Nyt voimme luoda ja päivittää artikkeleita samalla Codexiin ja ChatGPT:hen perustuvalla tavalla, jota käytimme sivuston kehittämiseen.
nykyisten sivujen päivittäminen
Oikean sivupohjan etsimisen tai HTML:n muokkaamisen sijaan voimme viitata sivun URL-osoitteeseen, otsikkoon tai osion tunnisteeseen ja kertoa, mitä haluamme muuttaa.
Tarkastelimme selaimen suorituskykymittareita, kuten sivun renderöintiä, Largest Contentful Paint -mittaria ja asettelun siirtymiä. Semrush-auditoinneilla arvioimme sivuston teknistä kuntoa, indeksointirobottien pääsyä sisältöön, navigointia ja muita teknisiä asioita.
Arvioin suorituskykyä myös paljon yksinkertaisemmalla tavalla.
Vanhalla sivustolla näin viiveet itse sekä mobiilissa että tietokoneella. Sivujen lataaminen kesti, eikä käyttökokemus ollut erityisen miellyttävä.
Uudessa toteutuksessa eron huomasi heti.
Sivusto vain tuntuu selvästi nopeammalta.
Silmin havaittava nopeus ei tietenkään korvaa teknisiä mittauksia. Minulle se oli silti tärkeä merkki, koska juuri tämän todelliset kävijät kokevat.
Mittari | Tulos |
|---|---|
Sivuston kunto | 94% |
Tekoälyrobottien pääsy sisältöön | 92 %, aiemmin 30 % |
Indeksointirobottien pääsy sisältöön | 97% |
Sisäinen navigointi | 100% |
Sivuston suorituskyky | 100% |
Semrush-tulostemme mukaan:
Toinen tärkeä parannus koski teknisten ongelmien määrää.
Syys–lokakuun tienoilla Semrush raportoi noin 2 000 ongelmaa, ja määrä oli enimmillään lähes 3 000.
Nyt ongelmia on noin 400. Niistä noin 200 liittyy Cloudflaren sähköpostisuojausmekanismiin, jonka linkit raportoidaan rikkinäisinä sisäisinä linkkeinä.
Parannettavaa on edelleen, mutta lähtötilanteeseen verrattuna ero on valtava.
Sivuston ylläpidosta suoraan asiakkaille suunnattuun sisältöön
Suorituskyky ei ollut ainoa parannus.
Saavutimme myös jotain luultavasti vielä tärkeämpää: paljon sujuvamman tavan luoda ja hallita sisältöä.
Aiemmin sivun muuttaminen edellytti, että joku päivitti sivupohjat käsin, muokkasi sisältöä ja hoiti teknisen työn.
Sen sijaan, että kierrättäisimme kokemuksemme usean ihmisen kautta verkkosisällöksi, voimme hoitaa suurimman osan rutiinityöstä alustamme avulla.
Kehittäjän ei tarvitse ryhtyä tekstisuunnittelijaksi. Asiakasvastaavan ei tarvitse ryhtyä kehittäjäksi. Eikä idean keksijän pitäisi joutua odottamaan kuukausia, että joku toteuttaa sen sivustolle.
Tämä ei tarkoita mitäänsanomattoman tekoälymassan tuottamista.
Otetaan esimerkiksi tämä artikkeli.
Sitä ei oikeastaan kirjoiteta käsin. Ideat ja ajatukset sanellaan, muutetaan tekstiksi ja viimeistellään.
Voimme sanoa esimerkiksi: ”Muotoile tämä uudelleen, tee tuosta kohdasta sujuvampi, poista turhat sanat ja käytä kohteliaampaa kieltä.”
Ideat, kokemukset ja kertomus ovat silti meidän.
Tekoäly auttaa muuttamaan ajatuksemme luettavaksi tekstiksi aivan kuten se auttoi muuttamaan suunnittelun ja tekniset vaatimukset oikeaksi koodiksi.
Juuri tällaisen työnkulun halusimme.
Tämä artikkeli on itse asiassa hyvä esimerkki rakentamastamme sisällönjulkaisuprosessista.
Ideat tulevat suoraan kokemuksistamme. Sanelemme ne, muutamme ne tekstiksi, tarkistamme ja parannamme tekstiä ja annamme sitten agentin valmistella sisällön sivustollemme.
Artikkeli viedään CMS:äämme, käännetään muille tuetuille kielille, tarkistetaan ja julkaistaan.
Sama toimintatapa sopii teknisiin artikkeleihin, asiakastarinoihin, palvelukuvauksiin ja muuhun sisältöön, jota haluamme jakaa.
Aiemmin tukeuduimme vahvasti tekstisuunnittelijoihin ja sivuston ylläpitäjiin, jotka muokkasivat teknisten asiantuntijoiden muutamasta sanasta kokonaisia artikkeleita.
Tekninen asiantuntija käyttää muutaman minuutin työnsä selittämiseen, ja tekstisuunnittelija muuttaa sen tuhansiksi sanoiksi.
Isoja, näyttäviä artikkeleita, joissa on paljon tekstiä, selityksiä ja melko usein myös runsaasti täytettä.
Varsinainen kehittäjä kuvaisi saman projektin luultavasti muutamalla lauseella:
”Joo, tehtiin se homma. Se oli helppoa. Kiinnostavaa. Ja hauskaa.”
Ehkä hän mainitsee siinä sivussa joitain liiketoimintahyötyjä. Tosin asiakasvastaavan pitäisi luultavasti osata selittää ne paljon paremmin.
Haluamme, että kehittäjämme kertovat lyhyesti, mikä toteutuksessa oli kiinnostavaa, mikä oli teknisesti haastavaa ja mistä oli hyötyä, ja palaavat sitten muiden kiinnostavien töiden pariin.
Sen sijaan, että he käyttäisivät tuntikausia kaiken kuvaamiseen ihmiselle, joka lopulta muuttaa sen artikkeliksi.
Tällaista rutiinityötä halusimme poistaa.
Tätä tarkoitan myös sillä, että toteutus tuodaan lähemmäs asiakasta.
Tekoäly voi auttaa poistamaan näiden ihmisten välistä rutiinityötä, jolloin tieto kulkee paljon suoremmin sitä omaavilta sitä tarvitseville.
Kehitystyö ja kustannukset
60 tuntia
Kaikkiaan sivuston viimeisimpään uudistukseen kului noin 60 tuntia omaa kehitys- ja katselmointiaikaani kahdessa vaiheessa lokakuun aikana.
30%
Noin 30 % ajasta kului koodin katselmointiin, teknisten ratkaisujen tarkistamiseen, ongelmien löytämiseen ja tekoälyn tekemien muutosten varmistamiseen.
€245
ChatGPT Business -tilaustemme lisätokenien käyttö maksoi noin 245 € tavallisen, noin 23 € maksavan tilaukseni lisäksi.
Tämä ei tietenkään tarkoita, että koko sivusto olisi rakennettu uudelleen 245 €:lla.
Summa ei sisällä omaa aikaani, suunnittelijamme työtä, infrastruktuuria eikä sivustoon vuosien aikana tehtyjä aiempia investointeja.
Olemme kehittäneet ja parantaneet sivustoamme vuodesta 2019: vaihtaneet teemoja, päivittäneet ulkoasua, luoneet sisältöä ja muokanneet rakennetta.
Viimeisimmässä siirrossa hyödynnettiin suuri osa tästä työstä.
Kiinnostavaa on kuitenkin se, kuinka paljon sain aikaan noin 60 tunnin omalla panoksellani käyttämällä tekoälyä kehitykseen, refaktorointiin, testaukseen, käyttöönottoon ja koodin katselmointiin.
Mikä muuttui käytännössä
Alla verrataan toteutukseen kulunutta kalenteriaikaa freelance-kehittäjän kanssa työskenneltäessä. Kyse ei ole projektibudjeteista eikä suoraan vertailukelpoisista työtuntimääristä.
Esimerkiksi yhden sivun tekemiseen saattoi kulua noin 40 tuntia kehitystyötä, joka jakautui usealle viikolle työn ja jatkuvien parannusten lomaan.
Arviot alkavat siitä, kun idea ja vaatimukset on määritelty. Ideointi ja vaatimusten määrittely ovat itsessään tärkeitä vaiheita, eikä niitä lasketa tähän mukaan.
Ennen
Artikkeli sisältöbriefin pohjalta: 8 tuntia.
Sivun lisääminen: 3–4 viikkoa.
Useiden sivujen lisääminen: 1–3 kuukautta.
Jälkeen
Artikkeli sisältöbriefin pohjalta: 1 tunti.
Sivun lisääminen: 1–4 tuntia.
Useiden sivujen lisääminen: 1–4 tuntia.
Responsiivinen suunnittelu ja tarkistukset
Agentti hoitaa myös suurimman osan responsiivisesta suunnittelusta ja tarkistuksista sekä korjaa niin ilmeisiä kuin vaikeasti havaittavia ongelmia.
Odotukset ylittävä tulos
Joskus se ylittää odotukset ja luo jotain parempaa kuin alun perin pyysin.
Ohjausta tarvitaan edelleen
Se voi kuitenkin myös tehdä ratkaisusta liian monimutkaisen tai tuottaa jotain, mikä ei vastaa visiotani. Selkeitä ohjeita, katselmointia ja ihmisen ohjausta tarvitaan edelleen.
Mitä seuraavaksi?
Tekninen perusta on nyt paikallaan.
Meillä on alusta, jota voimme ylläpitää muokkaamatta sivuston jokaista yksityiskohtaa käsin.
Voimme tietenkin halutessamme yhä muokata kaikkea suoraan. Nyt voimme kuitenkin vain sanoa sivustoa ylläpitävälle agentille:
Hei, lisää [artikkeli], käytä [kuvia], luo sisällöstä infografiikkaa tai taulukoita ja julkaise se muodossa [asiakastarina tai blogiartikkeli].
Sama pätee nykyisten sivujen päivittämiseen.
Esimerkiksi:
Ota tämä sivu [anna URL-osoite tai sivun otsikko], etsi tämä osio [anna osion nimi, otsikko tai tunniste] ja päivitä se. Vaihda kuva, päivitä tai täydennä tekstiä ohjeideni perusteella ja varmista, että kaikki noudattaa nykyistä suunnittelujärjestelmäämme. Säilytä komponentin toiminnallisuus ja tarkista muutokset.
Haluammepa vaihtaa kuvan, täydentää palvelukuvausta, julkaista artikkelin tai päivittää kokonaisen osion, voimme kertoa tavoitteemme, tarkistaa tuloksen ja tarvittaessa tehdä korjauksia.
Näin säästyy tuntikausia rutiinityötä, ja ajan voi käyttää ideoiden kehittämiseen, asiakkaiden tarpeiden tutkimiseen ja hyödyllisen sisällön luomiseen.
Ja kyllä, tilanne on nyt huomattavasti parempi melkein joka näkökulmasta.
Infrastruktuuri on valmis. Alustaa on helppo ylläpitää. Kerro vain selkeästi, mitä tarvitset, ja agentti voi lisätä sen minuuteissa. Sisältöä on helpompi julkaista, ja hallitsemme sivuston toimintaa paljon paremmin.
Nyt voimme keskittyä ideoihin teknisten yksityiskohtien sijaan.
Tärkeämpi muutos liittyy kuitenkin siihen, miten voimme työskennellä asiakkaidemme kanssa.
Sen sijaan, että kehittäjien, asiakasvastaavien, markkinoinnin ja sivuston ylläpitäjien välillä olisi useita vaiheita ja prosesseja, voimme tehdä tiedonvaihdosta paljon suorempaa.
Asiakkaan ongelmat ymmärtävät ihmiset voivat jakaa osaamistaan, ja ratkaisuja rakentavat ihmiset voivat kuulla, mitä asiakkaat todella tarvitsevat.
Teknologian ei koskaan pitänyt olla ongelma, jonka ratkaisemiseen käytämme suurimman osan ajastamme.
Sen piti auttaa meitä viemään ideamme asiakkaiden ulottuville.
Ja nyt teknologia ei vihdoin enää ole riesa.
