Emme vain rakentaneet verkkosivustoa: miten sivusto auttoi rakentamaan DETai-ekosysteemin

Tämä kirjoitus kertoo siitä, miten verkkosivustomme syntyi. Prosessin teknisistä ja luultavasti osittain myös psykologisista puolista.

Vaikka nyt, kun aikaa on kulunut riittävästi, alkaa olla selvää, ettei ilmaus ”verkkosivusto syntyi” ole aivan täsmällinen.

Siitä me todella aloitimme. Halusimme rakentaa modernin DETai-verkkosivuston: kauniin, nopean, monikielisen, ihmiselle ymmärrettävän ja teknisesti niin hyvin rakennetun, ettei kaikkea tarvitsisi muutaman kuukauden välein tehdä alusta. Tehtävä vaikutti varsin selkeältä. Mutta mitä pidemmälle sivuston kanssa etenimme, sitä enemmän alkoi ilmaantua kysymyksiä, jotka eivät enää oikeastaan koskeneet itse sivustoa.

Mikä tarkalleen kuuluu DET:iin ja mikä DETaihin? Missä yksi suunta päättyy ja tuote alkaa? Mitkä ekosysteemin osat tarvitsevat omat sivunsa? Miten tutkimus, koulutus, psykoterapia, tuotteet ja teknologia-alusta liittyvät toisiinsa? Mikä tieto on julkista ja minkä pitäisi jäädä sisäiseksi? Mitä oikeudellisia asiakirjoja eri pinnoille tarvitaan? Kuka omistaa datan? Missä sijaitsee määritelmän kanoninen lähde ja missä sen julkinen tulkinta? Sitten mukaan tulivat lokalisoinnit, SEO, GEO, kuvien alkuperä, sivujen luonti- ja muokkauspäivät, ihmisten ja organisaatioiden identiteetit, entiteettien väliset suhteet ja rakenteinen data — lähes näkymätön kerros, joka auttaa hakujärjestelmiä ymmärtämään, mitä niiden edessä oikeastaan on.

Kuka tässä on ihminen ja mikä on organisaatio. Mikä on julkaisu, mikä tuote ja mikä projekti. Milloin sivu syntyi ja milloin se todella muuttui. Mistä kuva on peräisin. Miten yksi objekti liittyy toiseen. Tavalliselle kävijälle lähes mitään tästä ei ole olemassa: hän avaa sivun ja näkee tekstin, kuvat ja painikkeet, mutta niiden alle kasvaa vähitellen toinen sivusto — sellainen, joka on tarkoitettu vähemmän silmille ja enemmän koneelliselle ymmärtämiselle. Ja suunnilleen kolmantena päivänä taas yhden tällaisen syväsukelluksen keskellä mieleeni nousi täysin luonnollinen kysymys: entä jos puolen vuoden päästä puolet tästä ei olekaan enää tarpeen? Tai jopa kahden viikon päästä.

Google muuttaa suosituksiaan, AI-haku oppii ymmärtämään sivustoja jollain toisella tavalla, Schema.org menettää osan nykyisestä merkityksestään, syntyy uusi standardi tai framework, jonka päällä kaikki toimii, vaihtuu.

Digitaalisessa ympäristössä se, mitä eilen pidettiin best practicena, voi huomenna muuttua historialliseksi sivuhuomautukseksi. Tarkoittaako se, että usean päivän työ olisi voinut mennä suoraan hukkaan? Kysymys muuttuu erityisen huvittavaksi, kun muistaa, mistä koko tarina alkoi. Meidänhän oli tarkoitus vain tehdä verkkosivusto.

Kun verkkosivusto oli vielä vain verkkosivusto

Jossain vaiheessa WordPress oli todella melkein jumaluus.

Nyt se kuulostaa hieman ironiselta, mutta silloin asia oli täysin vakava. WordPress antoi ihmiselle ilman kehittäjätiimiä mahdollisuuden rakentaa oikean verkkosivuston, asentaa teeman, liittää lisäosia, tehdä blogin, lomakkeita ja analytiikkaa — ja sitten avata Elementorin ja tuntea yhtäkkiä olevansa lähes web-suunnittelija.

Omaan aikaansa se oli uskomattoman vahva malli: ei tarvinnut suunnitella erillistä frontendia ja backendia eikä ajatella infrastruktuuria toisiinsa liittyvien järjestelmien joukkona — rakensit verkkosivuston. Jos tarvittiin uusi ominaisuus, sille löytyi melkein varmasti lisäosa; jos ulkoasua haluttiin muuttaa, tarjolla oli teema tai visual builder.

Elimme pitkään suunnilleen tässä ajattelumallissa, kunnes aivan työn alussa esitettävä kysymys alkoi vähitellen muuttua.

Ennen se kuului: ”Millaisen verkkosivuston haluamme rakentaa?” Nykyään yhä useammin pitää kysyä: ”Millaisen järjestelmän haluamme rakentaa — ja mikä osa sitä verkkosivusto on?”

Moderni web-kehitys muuttui komponenttipohjaiseksi, GitHubista tuli kehitystyön keskus, Next.js mahdollisti perinteisen sivuston ja sovelluksen ominaisuuksien yhdistämisen, ja Vercel teki deploymentista lähes luonnollisen jatkon koodin muuttamiselle. Todellinen käännekohta tapahtui kuitenkin silloin, kun AI tuli tähän kokonaisuuteen. Aiemmin raja oli melko selvä: joko osasit itse ohjelmoida tai työskentelit niiden mahdollisuuksien sisällä, jotka ohjelmoijat olivat sinulle rakentaneet.

AI:n myötä tästä rajasta tuli huomattavasti vähemmän jäykkä. Se ei tarkoita, että ohjelmointi olisi kadonnut tai yhtäkkiä lakannut vaatimasta ammatillista osaamista. Pikemminkin insinöörityöhön tuli mahdolliseksi osallistua toisella tasolla: keskustella datarakenteista, ownershipista, järjestelmien rajoista, niiden välisistä rajapinnoista, yksittäisten objektien kanonisista lähteistä ja arkkitehtuuripäätösten seurauksista ilman, että jokainen funktio täytyy itse kirjoittaa käsin. Vähitellen työ alkoi kuulostaa suunnilleen tältä: tätä dataa ei saa kopioida; kieliversioiden täytyy olla saman merkityksen itsenäisiä representaatioita; tämä kerros kuuluu sivustolle, tämä Storytellingille ja tämä Knowledge Substratelle; tähän tarvitaan provider, tähän consumer ja niiden väliin vakaa contract. Tässä kohtaa kaikki lopullisesti erkani alkuperäisestä suunnitelmasta. Suunnitelma kun oli ollut hyvin yksinkertainen: vielä pari viikkoa, ja sivusto on valmis.

Nyt tuo lause näyttää jo melkein historialliselta vitsiltä 🙂

Miksi käytimme tähän niin paljon aikaa?

Jossain vaiheessa jouduimme kysymään vielä yhden kysymyksen, ja se osoittautui paljon teknisiä kysymyksiä tärkeämmäksi: miksi emme voi vain lopettaa?

Miksi emme voisi ottaa jo kaunista etusivua, muutamaa osiota, kunnollista mobiiliversiota, liittää analytiikkaa ja sanoa: siinä, sivusto on olemassa? Luultavasti siksi, että vähitellen aloimme nähdä sen aivan eri tavalla. Mikään yksittäinen verkkosivusto ei tietenkään ole olemassa ”ikuisesti”. Design muuttuu. Koodi kirjoitetaan uudelleen. Jotkin sivut katoavat. Jotkin teknologiat, jotka nyt näyttävät moderneilta, näyttävät muutaman vuoden päästä suunnilleen samalta kuin nykyään vanha WordPressin ylläpitonäkymä, jossa on 47 lisäosaa eikä kukaan enää muista, mihin viimeiset kaksitoista tarvittiin. Mutta verkkosivuston rooli kestää paljon pidempään kuin sen nykyinen toteutus.

DETain teknologiapino voi muuttua, uusia tuotteita, ihmisiä, tutkimuksia ja työmuotoja voi syntyä, mutta paikka, jonka kautta ekosysteemi esittelee itsensä ulkomaailmalle, tulee todennäköisesti säilymään hyvin pitkään.

Verkkosivusto on yksi koko järjestelmän tärkeimmistä julkisista representaatioista.

Kun sitä katsoo tällä tavalla, tehtävä muuttuu yllättäen. Ei tarvitse yrittää rakentaa sivustoa, jota ei koskaan tarvitse muuttaa — se on mahdotonta. Pitää rakentaa sellainen perusta, joka voi muuttua pitkään yhdessä ekosysteemin kanssa menettämättä omaa identiteettiään.

Stewart Brandilla on kirjassaan How Buildings Learn: What Happens After They're Built tähän hämmästyttävän osuva ajatus:

”Rakennus ei ole jotain, minkä saat valmiiksi. Rakennus on jotain, minkä aloitat.”

Brand kirjoitti rakennuksista, jotka jatkavat elämäänsä sen jälkeen, kun arkkitehti pitää työnsä valmiina: ihmiset muuttavat niitä, rakentavat uudelleen, sovittavat uusiin olosuhteisiin, ja juuri kyky kestää näitä muutoksia määrittää suurelta osin alkuperäisen arkkitehtuurin laadun. Jossain vaiheessa huomasin ajattelevani, että verkkosivustolle tapahtuu melkein sama asia. Emme rakenna sivua, jonka jonain päivänä juhlallisesti julistamme valmiiksi.

Käynnistämme pitkäikäisen digitaalisen rakenteen, jonka sisällä lähes kaikki tulee vielä muuttumaan monta kertaa.

Kun verkkosivusto pakottaa vastaamaan kaikkeen

Ja tässä tapahtui ehkä kaikkein odottamattomin asia: sivusto ei enää vain kuvannut DETaita — se alkoi pakottaa meitä määrittelemään DETaita.

Niin kauan kuin ekosysteemi elää keskusteluissa, erillisissä dokumenteissa, repositoryissä ja ihmisten mielikuvissa, monet rajat voivat pysyä pitkään hieman epätarkkoina. Kaikki ymmärtävät suunnilleen, mistä puhutaan. Mutta yrittäkää jakaa tämä kaikki konkreettisiksi sivuiksi.

Mitä kuuluu ylänavigaatioon? Mikä ansaitsee oman sivunsa ja mikä on osa toista entiteettiä? Jos sivulla lukee ”DETain tuotteet”, mitä tarkalleen kutsumme tuotteeksi? Jos tutkimukselle on oma osionsa, missä kulkee raja tutkimustoiminnan, menetelmän ja teknologia-alustan välillä? Jos projektilla on omaa käyttäjädataa, kuuluuko se yhteiseen ekosysteemiin vai tietylle tuotteelle? Jos ihminen avaa juridisen asiakirjan, mille pinnalle se kuuluu? Jos sama idea esiintyy Knowledge Substratessa, julkaisussa ja verkkosivustolla, missä on sen kanoninen määritelmä ja missä tietylle yleisölle tehty sovellus?

Jossain vaiheessa kävi ilmi, että verkkosivuston navigaation rakentaminen muuttui lähes huomaamatta työksi itse ekosysteemin ontologian parissa. Meidän piti kirjaimellisesti päättää, mistä objekteista se koostuu ja miten nämä objektit liittyvät toisiinsa. Niinpä design veti yllättäen mukanaan arkkitehtuurin, ja julkiset käyttäjäpolut oikeudelliset asiakirjat ja datan käsittelyn säännöt.

Ja tarve selittää kaikki tämä ihmiselle yksinkertaisella kielellä pakotti palaamaan arkkitehtuuriin yhä uudelleen ja kysymään: ymmärrämmekö me itse oikeasti, mitä olemme täällä rakentaneet?

Syntyi aika kiinnostava sykli: yritimme kuvata ekosysteemiä verkkosivuston avulla, mutta tarve tehdä hyvä verkkosivusto pakotti meidät kuvaamaan itse ekosysteemiä aina täsmällisemmin. Lopulta sivustosta tuli eräänlainen DETain integraatiotesti. Jos kahta järjestelmän osaa ei voi yhdistää ymmärrettävästi julkisella sivulla, ongelma ei ehkä ole sivussa. Jos emme osaa selittää, miten kaksi entiteettiä eroavat toisistaan, emme ehkä ole itse määritelleet niiden rajoja riittävän hyvin. Ja jos ei ole selvää, kuka omistaa datan tai mistä määritelmän pitäisi tulla, kaunis UI ei ratkaise ongelmaa. Ehkä juuri siksi useiden kuukausien työ ”verkkosivuston” parissa sisälsi lopulta designia, ohjelmointia, semantiikkaa, SEO:ta, juridista arkkitehtuuria, lokalisointeja ja työtä itse DETai-mallin parissa: yksi julkinen pinta vaati yllättäen, että koko sen takana oleva järjestelmä on riittävän hyvin määritelty.

Verkkosivusto, joka lakkasi olemasta vain verkkosivusto

Itse sivusto ei tietenkään kadonnut mihinkään. Päinvastoin: vähitellen siitä tuli yksi DETain tärkeimmistä julkisista pinnoista. Sen kautta ihminen voi tulla menetelmään, tutkimukseen, koulutukseen, tuotteisiin, tiimiin, tapahtumiin, julkaisuihin ja dokumentaatioon. Tämä rooli on nyt erikseen kuvattu Knowledge Substraten projektisivulla ”DETai-verkkosivusto”: sivusto on ekosysteemin julkinen web-kerros, joka selittää sen rakennetta, näyttää yhteyksiä ja ohjaa ihmisiä tuotteisiin, tietoon ja osallistumiseen.

Juuri siksi se muistuttaa yhä vähemmän säiliötä, johon vain laitamme valmiin sisällön. Otetaan tavallinen julkaisu: se voi alkaa ajatuksesta tai äänimuistiinpanosta, muuttua tekstiksi, käydä läpi editoinnin, saada kuvia, metadataa, kieliversioita ja useita representaatioita eri kanavia varten — ja vasta sen jälkeen päätyä sivustolle tai Telegramiin. Sivusto ei siis enää ole objektin syntypaikka eikä hallitse sen koko elinkaarta; siitä tulee yksi muoto, jossa objekti on läsnä.

Siksi sivuston rinnalle kasvoi vähitellen Storytelling — erillinen Publication Core, joka vastaa julkaisujen valmistelusta ja liikkumisesta; Knowledge Substrate säilyy vakaiden määritelmien, arkkitehtonisten rajojen, ownershipin, policiesien ja versioiden tilana; yksittäiset tuotteet säilyttävät oman logiikkansa ja datansa; ja verkkosivusto kokoaa tästä kaikesta ihmiselle johdonmukaisen julkisen kuvan.

Ja ehkä juuri tässä syntyy ilmaus, josta pidän tällä hetkellä eniten: verkkosivustosta tuli vähitellen digitaalisen läsnäolon järjestelmä. DETain pitää olla olemassa ihmiselle, hakukoneelle ja AI-agentille ei satunnaisesti yhteen liitettyjen URL-osoitteiden joukkona, vaan tunnistettavana rakenteena, jossa on selvää, mitä tämä on, miksi se on olemassa ja miten se liittyy kaikkeen muuhun.

Ja tässä alkaa seuraava ironia: mitä ymmärrettävämmäksi arkkitehtuuri muuttuu, sitä selvemmin näkyy, kuinka paljon siinä on vielä parannettavaa.

Projekti, jolla ei ole ”valmis”-tilaa

Monimutkaisilla järjestelmillä on aika epämiellyttävä ominaisuus: niin kauan kuin niitä ei juuri ole olemassa, ne näyttävät hyvin yksinkertaisilta. Kun on vain ajatus tulevasta verkkosivustosta, tehtävä näyttää rajalliselta — tehdään sivut ja valmista. Sitten sivut ilmestyvät ja niiden mukana yhä uusia kerroksia. ”Valmis” tuntuu koko ajan siirtyvän muutaman askeleen kauemmas.

Tätä voi katsoa upeana loputtomana projektina, jota ei voi koskaan saada valmiiksi 😅 Tai sitten voi yhtäkkiä huomata jotain muuta: ehkä ajatus lopullisesta valmiudesta oli alun perinkin väärä.

Ja tässä palaamme kysymykseen, josta kaikki alkoi: jos merkittävä osa tämän päivän työstä vanhenee joka tapauksessa joskus, eikö se tarkoita, että vaiva meni hukkaan?

Jostain syystä mieleeni tulee tässä hyvin yksinkertainen vertaus harjoitteluun.

Kun ihminen harjoittelee pitkään, tulos näyttää hyvin konkreettiselta: lihakset, voima, kunto. Mutta kaikki tietävät, että jos harjoittelu jää tarpeeksi pitkäksi aikaa tauolle, merkittävä osa tuloksesta alkaa kadota. Silloin voisi kysyä: miksi kaikki ne sarjat piti tehdä, jos niiden vaikutus ei säily ikuisesti?

Vastaus tuntuu melko ilmeiseltä juuri siksi, ettei harjoittelun tulos koskaan rajoittunut lihaksiin. Samalla syntyi kyky kestää kuormitusta, palata taukojen jälkeen, pitää kiinni rutiinista, tehdä vielä yksi sarja ilman erityistä halua ja olla riippumatta joka kerta inspiraatiosta. Vaikka tietty fyysinen muoto katoaisi, ihminen, joka kerran oppi rakentamaan sen, on jo hieman erilainen kuin ihminen, joka vasta aikoo aloittaa.

Teknologian kanssa näyttää tapahtuvan jotain hyvin samanlaista. Tietyn koodin voi heittää pois, frameworkin vaihtaa, deploymentin kirjoittaa uudelleen, datamallin muuttaa kokonaan ja jonain päivänä koko sivuston rakentaa alusta — mutta kyky ymmärtää vierasta järjestelmää, nähdä yhteyksiä, kestää monimutkaisuutta ja viedä jotain toimivaan tilaan ei katoa repositoryn mukana.

Vielä melko vähän aikaa sitten monet asiat, joiden kanssa nyt työskentelemme lähes arkipäiväisesti, olivat tutun kielen ulkopuolella. Ei siksi, että olisi ollut ovela suunnitelma opetella vielä viisi ammattia, vaan siksi, että projektin jokainen seuraava kerros vaati ymmärtämään hieman enemmän kuin edellinen. Ja jossain vaiheessa tapahtuu aika huvittava käänne: ensin pelottaa avata koodi ja rikkoa siellä vahingossa jotain; sitten alkaa pelottaa koskea arkkitehtuuriin; ja vielä jonkin ajan kuluttua syntyy täysin päinvastainen tilanne — joskus paljon pelottavampaa on olla muuttamatta sitä, kun jo näkee, ettei vanha ratkaisu enää vastaa järjestelmää.

Ehkä tämä on yksi DETai-työn tärkeimmistä tuloksista, jota sivustolla ei voi nähdä lainkaan.

Se, mitä verkkosivustolla ei näy

Sen kolmannen päivän iltaan mennessä pää ei enää halunnut nähdä JSON-LD:tä, canonicalia, provenancea, päivämääriä, tunnisteita tai entiteettien välisiä suhteita. Täyden työpäivän jälkeen jäljellä oli vain tavallinen fyysinen väsymys, ja jossain pyörämatkalla syntyi yllättävän rauhallinen tunne: tänään jokin muuttui paremmaksi.

Ei ikuisesti — ja ehkä juuri tämä on tässä tärkein huomautus.

Vähitellen katoaa ajatus siitä, että työn merkityksen pitäisi välttämättä olla jonkin sellaisen luomisessa, jota ei enää koskaan tarvitse muuttaa. Verkkosivusto muuttuu, yritys muuttuu, ammatti muuttuu, keho muuttuu, teknologia muuttuu ja ihminen, joka kaiken tämän kanssa työskentelee, muuttuu.

Kestävyys ei kummallista kyllä synny silloin, kun järjestelmä lakkaa muuttumasta, vaan silloin, kun se oppii muuttumaan menettämättä itseään.

DETaille tästä syntyy aika luonteva paradoksi. Rakennamme teknologista ekosysteemiä inhimillisen käytännön ympärille ja samalla emme halua antaa teknologian korvata itse käytäntöä; luomme melko tiukkoja arkkitehtonisia rajoja juuri siksi, että järjestelmä voisi kehittyä vapaammin; kiinnitämme kanonisen tiedon Knowledge Substrateen mutta annamme julkaisuille oikeuden olla eläviä kuvia tietystä hetkestä; käytämme AI:ta liikkumiseen nopeammin ja ymmärrämme samalla yhä vahvemmin ihmisen vastuun arvon merkityksen säilyttämisessä.

Siksi verkkosivuston tarina ei lopulta ollut niinkään tarina Next.js:stä, Vercelistä, GitHubista, Schema.orgista tai AI:sta. Kaikki nämä teknologiat ovat tärkeitä, mutta jokainen niistä on oman aikansa väline.

Mielenkiintoisin tapahtui toisella tasolla.

Aloitimme halusta tehdä verkkosivusto ja opimme vähitellen ajattelemaan järjestelmää. Aloitimme yksittäisistä sivuista ja päädyimme objektien välisiin suhteisiin. Aloitimme kysymyksestä ”mitä ihminen näkee?”, ja nyt kysymme rinnalla ”mitä kone ymmärtää?” Yritimme esittää jo olemassa olevan ekosysteemin — ja samalla huomasimme, että pelkkä tarve esittää se pakottaa ymmärtämään paljon tarkemmin, mistä se oikeastaan koostuu.

Siksi alkuperäinen kysymys — ”entä jos kaikki tämä osoittautuu joskus turhaksi?” — kuulostaa nyt hieman erilaiselta.

Yksittäinen tulos voi todella kadota. Koodi voidaan kirjoittaa uudelleen, standardi vaihtaa, teknologia unohtaa ja verkkosivusto rakentaa kokonaan uusiksi — ja hyvin todennäköisesti niin sille jonain päivänä tapahtuukin. Mutta jos Stewart Brand on oikeassa ja rakennus ei ole jotain, minkä saa valmiiksi, vaan jotain, minkä aloittaa, ehkä digitaalisiin järjestelmiin pitäisi suhtautua samalla tavoin: ei yrittää arvata niiden lopullista muotoa, vaan rakentaa ne niin, että ne voivat elää alkuperäistä arkkitehtuuriaan pidempään.

Ja ehkä juuri siksi erittäin raskaan työpäivän lopussa syntyy joskus outo mutta miellyttävä tunne: voimia ei juuri ole, pää on väsynyt, huomenna kaikki jatkuu — ja silti sisällä tuntuu hyvältä.

On väsymystä merkityksettömästä liikkeestä. Ja sitten on aivan toisenlaista väsymystä — sellaista, joka syntyy, kun tänään onnistui tulemaan kykeneväksi hieman vaikeampaan asiaan kuin eilen.

Ehkä juuri tällaisina hetkinä yksi yksinkertainen ajatus tuntuu erityisen selvältä:

elämä on sitä, että olet iloinen väsymyksestäsi.

Lähteet ja materiaalit

1. Brand, Stewart. How Buildings Learn: What Happens After They're Built. Viking Press, 1994. Kirja arkkitehtuurista järjestelmänä, joka jatkaa muuttumistaan rakentamisen valmistumisen jälkeen; tästä teoksesta on peräisin lainaus ”A building is not something you finish. A building is something you start”.
   https://www.penguinrandomhouse.com/books/320919/how-buildings-learn-by-stewart-brand/

2. Google Search Central — Introduction to structured data markup in Google Search. Kuvaa, miten rakenteinen data antaa hakujärjestelmille eksplisiittistä tietoa sivun sisällön merkityksestä ja tyypistä.
   https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

3. Schema.org. Avoin sanasto tyypeille, ominaisuuksille ja suhteille rakenteista dataa varten verkossa.
   https://schema.org/

4. DETai Knowledge Substrate — ”DETai-verkkosivusto”. Kanoninen kuvaus verkkosivuston roolista ekosysteemin julkisena web-kerroksena, sen rajoista sekä suhteista tuotteisiin, tietoon ja Storytellingiin.
   https://docs.detai-x.com/ru/ecosystem/DETai/Platform_DETai/E2-Brand/sites/

5. DETai Knowledge Substrate — ”Storytelling — Publication Core”. Kanoninen kuvaus DETain julkaisukerroksesta ja vastuunjaosta sisällön valmistelun ja sen eri kanaviin toimittamisen välillä.
   https://docs.detai-x.com/ru/ecosystem/STORYTELLING/