Kirjoitus on julkaistu alunperin Duden blogissa.
Duden blogissa on puhuttu viimeaikoina suhteellisen paljon siitä, paljonko nettisivut maksavat ja mistä se hinta sitten koostuu. Jokaisessa kirjoituksessa olemme kertoneet sivuston olevan aina räätälöity 100% asiakkaan tarpeita varten, tuo räätälöinti ulottuu aina visuaalisesta ilmeestä syvälle konepellin alle.
Roni tiivistikin aiemmin
osuvasti tuota konepellin alla olevaa osuutta. Ajattelin nyt avata tätä
teemaa hieman enemmän näin back-end kehittäjän roolissa kahdessa
erillisessä kirjoituksessa.
Kehitämme projektia mieluusti eteenpäin ja ainakin rakennamme sivustomme sellaiseksi, että niitä pystyy kehittämään eteenpäin.
Ensimmäisessä osassa käsittelen tietorakenteen suunnittelun tärkeyttä
ja kerron miten me Dudella hoidetaan asia. Seuraavassa osassa kerron
minkä takia ja miten kiinnittää huomiota myös hallintapaneeliin.
Kävijä näkee sivustosta ainoastaan ns. julkisen puolen, sen miltä
kaikki tieto näyttää hienosti ja visuaalisesti aseteltuna. Tuskinpa
kukaan tulee ajatelleeksi millä tavalla jokin tieto on tallennettu
tietokantaan tai minkälaisilla palikoilla visuaalisuus on kasattu.
Käytännössä projektin koodaamisen aloitus alkaa aina tietorakenteen
suunnittelusta. Yhtään riviä koodia ei kirjoiteta, ennen kuin
tietorakennetta on mietitty vähintään päässä, mieluusti jopa
analogisella paperilla.
Miksi suunnitella tietorakennetta?
Selkeyden vuoksi samaan asiaan liittyvän tiedon hallinnoiminen on
hyvä olla mahdollista yhdestä paikkaa. Sivuston sisällön ylläpitäjälle
on paljon selkeämpää päivittää yhden ominaisuuden kuvausta itse
ominaisuuden muokkasnäkymästä, kuin erikseen jokaisella sivulla missä
kyseinen ominaisuus näkyy tavalla tai toisella.
Tietorakenteen suunnittelu liittyy hallintapaneelin käyttömukavuuden
ja selkeyden lisäksi vahvasti jatkokehityksen ennakointiin. Kuvitellaan
tilanne, jossa esimeriksi ominaisuuksia listataan ainoastaan etusivulla
ja etusivulle on luotu lisätietokentät ominaisuuksien lisäämistä varten.
Mitä sitten kun asiakas haluaakin listata ihan samoja ominaisuuksia,
edes osaa niistä muilla sivuilla tai jokaiselle ominaisuudelle oman
laajan esittelysivun?
Kaikki aiempi ominaisuuksiin liittyvä back-end koodi muuttuu turhaksi
ja hommat joudutaan tekemään tältä osin nollasta uusiksi. Jos
tietorakennetta on taas mietitty etukäteen edes hieman ja luotu
ominaisuuksille oma sisältötyyppinsä (custom post type, CPT), on homma todennäköisesti paljon kivuttomampi.
Miten Dude tekee tämän käytännössä?
Projekti käydään vielä kerran läpi yhdessä graafikon kanssa, jotta
saadaan vastauksia seuraaviin kysymyksiin: minkälaisia sisältötyyppejä
sivustolle tarvitaan? miten sen artikkelit jäsennellään? tarvitaanko
kategorioita? onko sisältötyypillä arkisto tai sen yksittäisillä
artikkeleilla julkista näkymää? linkittyykö joidenkin sisältötyyppien
tiedot keskenään? mikä on sisältötyypin osoiterakenne (slug)? mikä on koko projektin kaiken sisällön osoiterakenne?
Vasta kun nämä asiat alkaa olla selvillä, aletaan kasaamaan sisältötyyppejä, niiden lisätietokenttiä (metadata) ja sivupohjia.
Käytännössä Duden back-end kehittäjän workflow lisäkenttien luomiseen ja sivuston julkiselle puolelle saamiseksi on seuraava:
- Huomataan että esimeriksi etusivulla on nostoja tuotteen
ominaisuuksista ja jokainen nosto sisältää otsikon, ikonin sekä lyhyen
kuvauksen.
- Selataan leiskat läpi ja katsotaan onko joillain toisella sivulla
samanlainen elementti tai samat sisällöt esitettynä hieman eri tavalla.
- “Ahaa, kaikki ominaisuudet esitellään yhdellä koontisivulla ja
siellä näyttäisi olevan sama otsikko sekä ikoni, mutta eri kuvaus ja
erilainen visuaalisuus.”
- Luodaan ominaisuus -sisältötyypin artikkelille lisätietokentät
ikoni, lyhyt kuvaus, lyhyt kuvaus etusivun nostossa ja käytetään
otsikkona ominaisuuden nimeä.
- Luodaan etusivulle lisäsisältökenttä josta voi valita nostettavat
ominaisuudet, tai vaihtoehtoisesti luodaan yksittäisen ominaisuuden
muokkaukseen valinta tätä varten. Tapa riippuu hieman siitä, miten
etusivun muu sisältö rakentuu ja tarvitaanko ominaisuusnostoja myös
muualla.
- Luodaan teemaan osat (template part) erikseen yksittäisen
ominaisuuden nostolle koonti- ja etusivulla. Näissä käytetään edellä
mainittuja lisätietokenttiä. Ensimmäistä osaa käytetään ominaisuuksien
koontisivun listassa ja toista etusivulla.
- Teeman osissa tulostetaan kaikki olennaiset tiedot, tässä
tapauksessa otsikko, edellä mainitut lisätietokentät ja yksittäisen
ominaisuuden osoite ilman html-rakennetta (poislukien kuvien, otsikoiden
ja linkkien html tagit).
Sama rumba toistetaan sivupohja kerrallaan ja sivun elementti kerrallaan.
Käytännössä Duden työmallilla, jossa jokaisessa projektissa on
erikseen back-end ja front-end kehittäjät, sivuston julkinen puoli
näyttää hyvin rujolle näiden työvaiheiden jälkeen, ennen kuin front-end
kehittäjä rakentaa asettelun visuaaliseen muotoon. Kaikki sisältö on
näkyvissä kuten kuuluukin, mutta ei kovin nätisti.
Front-end kehittäjä rakentaa projektista riippuen html-rakenteen ja
css-tyylit sisällön ympärille ennen tai jälkeen taustatyön, usein antaen
lisätehtäviä, korjaustöitä tai muita muutoksia back-end kehittäjälle.
Loppu projektista etenee siis samaan aikaan front-end sekä back-end
kehittäjän pöydillä yhteistyötä tehden.
PS. Ollaan Ronin kanssa höpöttämässä marraskuussa Tampere WordPress Meetupissa meidän tavasta tehdä sivustoja, tulehan ihmeessä paikalle!