Rakenteisen kirjoittamisen ympäristön rakentamisessa ja ylläpitämisessä riittää viilattavaa. Yksi tällöin helposti unohtuva seikka ovat sisältöjen nimeämisperiaatteet ja niiden tuomat hyödyt. Varsinkin DoX CMS:n suodattimet tekevät nimistä tärkeitä oikeiden osuuksien nopeasti löytämistä. Tämä ei kuitenkaan ole ainoa syy huomioida nimeämisen perusteita.
Vertaa samalle käyttöliittymän komennon muuttujalle nimiä Tallenna ja ui_command_save. Ne ovat kutakuinkin skaalan ääripäät. Mutta miksi toinen niistä on parempi?
Komponenttien nimet
Tässä tapauksessa komponentit tarkoittavat kaikkia järjestelmän erottamia palasia, joiden perusteella julkaisut kasataan. Otsikkosisällöt ovat ilmeisin esimerkki, mutta niiden nimet vastaavat kyseisten osuuksien otsikoita. Sen sijaan tagit, otsikkopuut, elementtiluokat, muuttujat ja kieliryhmät nimetään erikseen. Samat periaatteet koskevat osittain myös esimerkiksi käännösprojekteja.
Luokittelu
Kun komponentit järjestetään aakkosjärjestykseen kuten muuttujat tekstieditorissa tai niitä voi hakea suodattimilla, niiden nimiin rakennetut luokat helpottavat oikeiden komponenttien paikantamista.
Tällainen luokittelu perustuu avainsanoihin etuliitteinä. Sen voi rakentaa useammaksi tasoksi, missä alun avainsanaa seuraavat avainsanat muodostavat alaluokkia. Ne auttavat puolestaan kaventamaan hakuavaruutta entisestään esimerkiksi aakkosjärjestyksen perusteella, kun jokaista merkkiä vastaavassa sijainnissa olisi muutoin liian monta samoilla kirjaimilla alkavaa vaihtoehtoa.
Ennakoiva lokerointi
Mutta miksi luokat ja alaluokat ovat niin tärkeitä?
Ne ovat ennakoiva toimenpide komponenttien määrän kasvamisen huomioiden.
Kun jonkin tyypin komponentteja on enintään muutama tusina, voi niitä selata läpi oikeiden tilannekohtaisesti löytämiseksi ilman sen suurempaa vaivaa. Mutta niiden määrä voi helposti nousta satoihin ajan kanssa ja tämä on syytä huomioida varhaisessa vaiheessa. Suurta osaa niistä ei voi nimetä uudelleen jälkikäteen ilman niiden aiempien käyttöpaikkojen metsästämistä sisällöstä ja käytettyjen arvojen korjaamista siellä.
Käytännössä lisäluokat luovat lokeroita, joista oikeat arvot löytää samalla tavoin silmäilemällä kuin lyhyeltä listalta. Samoilla merkeillä alkavia nimiä kunkin tällaisen lokeron sisällä on riittävän vähän, jotta joukosta voi tunnistaa oikeat komponentit nopealla silmäilyllä tarkemman syynäyksen sijaan. Esimerkiksi kaksi tai kolme ensimmäistä kirjainta jakavia komponentteja per luokka on vähemmän eli jo niiden perusteella tunnistaa oikeat.
Avainsanavalikoima
Valinnoilla koskien luokkien merkkeinä toimivia avainsanoja on myös merkitystä.
Varsinkin useamman luokkatason kohdalla on syytä miettiä, mille tasolle kukin mahdollinen erotus kuuluu.
Esimerkiksi luokkien avainsanoina voisivat olla
- button,
- command,
- company,
- contact,
- dealer,
- icon,
- menu,
- resource ja
- UI.
Oletetaan näiden olevan lyhyen alustavan kirjaamistuokion tulos. Kirjoittajat tietävät tarvitsevansa muuttujia ainakin käyttöliittymän osuuksille sekä yhteystiedoille.
Ensimmäinen askel itselleni olisi käydä ne vielä läpi ja miettiä, onko osa kehnosti soveltuvia. Tällöin voi esimerkiksi harkita, millaisilla akseleilla jaottelut halutaan tehdä. Yksi tärkeä tällainen erottelu on, perustetaanko jaot toiminnollisiin eroihin vai esityksellisiin eroihin. Suosittelen itse pääasiassa ensin mainittuja, vaikka aina erot näiden vaihtoehtojen välillä eivät ole aivan selviä. Varsinkin toiminnollisten erojen osalta täytyy sitten harkita, mihin erotteluihin siltä osin keskitytään.
Tässä esimerkissä karsisin avainanan button, koska se tuntuu tarpeettomasti käyttötapaa rajaavalta ja samaa muuttujaa voidaan ehkä tarvita myös muutoin. Jos tosin painikkeiden arvot halutaan tietoisesti erottaa muista sillä hetkellä vastaavista arvoista erikseen hallinnoitaviksi, olisi tämä avainsana edelleen tarpeellinen. Myös resource on luultavasti vain liian laajamerkityksinen ja epämääräinen ollakseen merkityksellinen erotteluperuste.
Pyrkimyksenä on asettaa kaikkein laaja-alaisimmat luokat ensisijaisiksi erotteluperusteiksi nimien alkuun. Aina yläluokat eivät ole aivan selviä. UI eli käyttöliittymä on selvästi yläluokka ikoneille (icon) ja komennoille (command). Mutta esimerkiksi luokat company eli (oma) yritys ja contact eli yhteystieto leikkaavat toisiaan sen sijaan, että yksi olisi toisen yksiselitteinen alaluokka. Tällöin tärkeintä on huomioida tarvitut muut erottelut.
Jos esimerkiksi tarvitsette muuttujina enemmän eri yrityksien yhteystietoja, on järkevintä asettaa yhteystiedot ylemmäksi luokaksi. Jos puolestaan ette esimerkiksi merkitse ylös muita kuin omat yhteystietonne ja tarvitsette muuttujiksi myös yrityksenne logon, eri tehtäviä vastaavien henkilöiden nimiä ja niin edelleen, on yritys luultavasti parempi yläluokka. Toki nämä eri osuudet voidaan tarvittaessa myös jakaa usean yläluokan kesken käyttämällä omaa yritystänne väliluokkana jokaisessa niistä. Tämä vaihtoehto on avoimempi luonnolliselle laajentamiselle.
Itse siis käyttäisin tässä esimerkissä seuraavanlaista jaottelua:
- UI
- Command
- Icon
- Menu
- Contact
- Company
- Dealer
Suosittelemaan kirjaamaan nämä avainsanapohjaiset luokkahierarkiat ylös muodossa, joka myös sallii luokkien määrän laajentamisen. Tämä auttaa varmistamaan nimien yhdenmukaisuuden suhteessa niihin. Vaikka käytin yllä syvennettyjä listoja, suosittelen tähän mieluummin taulukoita, joissa luokat ovat rivejä ja niiden järjestys ilmaistaan sarakkeilla.
Kieliasu
Myös muotoiluilla on merkitystä. Nämä arvot täytyy kyetä paikantamaan vaivatta ja niitä täytyy kyetä käyttämään virheettä. Kumpaakaan näistä vaiheista ei tule epähuomiossa vaikeuttaa tarpeettomasti.
Isot kirjaimet ja erottimet
Jokainen taso täytyy erottaa muista ja siihen löytyy useampia keinoja. Niitä voi tarvittaessa myös yhdistää erityyppisten erojen ilmaisemiseksi. Olen esimerkiksi joskus käyttänyt alaviivaa ainoastaan erottaakseni pohjimmaisen arvon sitä edeltävien luokkien nimistä. Tällä tavoin on selvää, mitkä osuudet ovat avainsanoja ja mitkä pohjimmaisen arvon osia. Useasta sanasta koostuvat pohjimmaiset arvot ovat usein tarpeellisia ainakin käyttöliittymän palasissa.
Vaihtehtoja tältä osin ovat esimerkiksi:
- erotus-välimerkeillä: Tähän voi käyttää eri merkkejä kuten väliviivoja, alaviivoja ja ristikkomerkkejä (varsinkin avainsanoille).
- IsotAlkukirjaimet: Jokainen osuus tai sana alkaa isolla alkukirjaimella.
- kameliTeksti: Muut kuin ensimmäinen osuus tai sana alkavat isolla alkukirjaimella.
Merkitsevää on, että kieliasun tältä osin täytyy olla helposti toisinnettavissa ja soveltua yhteen käyttötavan kanssa. Esimerkiksi isot alkukirjaimet merkintäkeinona ja lyhenteet eivät näytä hyvältä yhdessä ja estävät peräkkäisten lyhenteiden käyttämisen avainsanoina ilman poikkeussääntöä niille. Poikkeussäännöt puolestaan sotkevat järjestystä ja vaikeuttavat oikeiden toimintamallien muistamista. Sikäli pelkät pienet kirjaimet ovat isoja parempia. Tällöin käyttäjän ei tarvitse muistaa, minne hänen täytyy lisätä isot kirjaimet.
Ymmärrettävyys
Kaikkein tärkeintä on, että käyttäjät ymmärtävät käytetyt ilmaisut. Kaikkein yleisin näkemäni mahdollinen ongelma tältä osin ovat suomenkieliset nimet. Ne voivat toimia nykyisille käyttäjille, mutta tällöin käytännössä evätään itseltä kyky palkata tehtävään myös muita kuin suomenkielisiä tai ainakin tarpeetta vaikeutetaan heidän työtään merkittävästi. Suurin osa näkemästäni kirjoittamisesta tapahtuu joka tapauksessa englanniksi.
Lisäksi ymmärrettävyyttä voivat haitata esimerkiksi liika nojautuminen lyhenteisiin tai erikoissanastoon. Ajoittain ne ovat välttämättömiä, koska liika pelkistys heikentää kognitiivista yhteyttä tarkkaan viittauskohteeseen. Riippumatta kummasta ääripäästä on kyse, mitä enemmän tulkintatyötä käyttäjien täytyy tehdä, sitä kehnommin ymmärrettävä sanavalinta on kyseessä.
Myös liian samannäköiset sanat voivat haitata nimien käytettävyyttä. Luonnollisten kielien tapauksessa tämä on pienempi mutta silti huomioimisen arvoinen ongelma. Sen osatekijöitä ovat vastaavat pituudet, helposti keskenään sotkeutuvat tai edes muodoltaan samansuuntaiset kirjaimet ja vastaavat osuudet. Esimerkiksi englannin sanojen ’experience’ ja ’experiment’ toisistaan erottaminen vaatii välitöntä tunnistusta enemmän silmäilyaikaa, mikä myös lisää virhesyötteiden riskiä. Ne ovat selvästi kaksi eri sanaa, mutta ainoa syntaksiero koostuu kummankin neljästä viimeisestä kirjaimesta. Lisäksi molempien viimeiset kirjaimet sisältävät e-kirjaimen ja kirjaimet n ja m koostuvat hyvin vastaavista muodoista.
Suurempi ongelma samannäköisyyden kannalta ovat kuitenkin koodit. Niillä ei pääasiassa ole vastaavaa välitöntä, kokemukseen perustuvaa tunnistettavuutta kuin luonnollisen kielen sanoilla. Ne täytyy siis käsitellä merkki merkiltä, kunnes käyttäjä huomaa ainakin joitakin tunnistamista nopeuttavia kaavoja. Esimerkiksi muuan iisalmelaisen kaiutinvalmistajan tuotteiden tai vaikkapa Sonyn kuulokkeiden nimet sisältävät tällaisia kaavoja, mutta ne täytyy oppia huomion nopeasti oikeisiin osuuksiin kiinnittämiseksi ja oikean mielikuvan kuhunkin tuotekoodiin ankkuroimiseksi.
Muistettavuus
Muistettavuus ei ole sama asia kuin ymmärrettävyys, mutta myös se perustuu riittävään erotettavuuteen ja selkeisiin viittauskohteisiin. Ymmärrettävyys auttaa osaltaan muistettavuutta, koska helpommin ymmärrettävä ilmaisu on usein myös helpommin muistettava. Sen kohteen selkeys auttaa muistijäljen syntymistä ja ylläpitoa. Kliseet ja vakioilmaisut ovat sikäli hyviä vaihtoehtoja, koska niille löytyy usein valmiita kognitiivisia malleja.
Kaavat ja säännöt ovat erityisen tärkeitä muistettavuuden kannalta ja mitä yksinkertaisempia kukin niistä on, sitä parempi. Niiden täytyy olla selkeästi sanoitettavissa tavalla, jossa kukin osa-arvo vastaa selkeästi jotakin seikkaa. Ei pelkästään kaavan osana vaan myös varsinaiselta arvoltaan. Esimerkiksi koon voi ilmaista koodissa varsinaisina arvoina ilman yksiköitä, vakioiduilla kokoluokan kirjaimilla kuten S ja M tai skaalaavilla suhteellisilla numeroarvoilla.
Lyhenteiden välttäminen on erityisen tärkeää muistettavuudelle. Kirjainlyhenteiden tulisi olla helposti lausuttavissa tai vastata jotakin sanaa. Pelkkä kirjaimien sanoista pudottaminen on erityisen riskialtista, koska tällöin käyttäjien täytyy muistaa tarkat kohdat, joissa nämä katkaisut on kussakin tapauksessa tehty.
Vaikka voi olla houkuttelevaa käyttää esimerkiksi käyttöliittymän osuuksia vastaavien komponenttien nimissä suoraan samoja ilmaisuja kuin niiden senhetkiset arvot, en suosittele tätä. Tällöin niiden nimet ankkuroidaan pysyvästi arvoihin, jotka voivat vanhentua ja vaihtua. Käyttäkää mieluummin esimerkiksi pelkistettyjä yhdistelmiä avainsanoja. Kun kyse on uudesta sisällöstä, vaikka käytetty arvo olisi ’Add folder’, voi vastaavalle komponentille olla parempi käyttää nimeä kuten NewFolder. Näin on selvää, että kyse on esimerkiksi uudesta kansiosta eikä olemassaolevan kansion lisäämisestä uuteen valikkoon.
Elementtien nimet
Itsenäisten komponenttien lisäksi myös yksittäiset elementit voivat vaatia nimiä. Varsinaisten elementtien tapauksessa kyse on niiden ID-arvoista. Myös elementtiluokat tosin kuuluvat tähän joukkoon, koska myös niiden nimiarvoihin kytketään toiminnallisuutta. Elementtien ID-arvoja käytetään ensisijaisesti erilaisiin viitteisiin eli linkkien ja sisältöviitteiden (conref) kohdentamiseen. Myös niihin voi joissakin tapauksissa kuitenkin kytkeä myös tyylisääntöjä. Elementtiluokkia käytetään ensisijaisesti tyylisäännöille. Nämä käyttötavat määrittävät elementtien nimiä koskevat hyvät käytänteet.
ID-arvot
Viitteet ID-arvoihin tekevät arvojen muistettavuudesta erityisen tärkeää. Tällöin niitä ei tarvitse välttämättä aina tarkistaa osana viitteiden tekemistä, vaikka tulokset täytyy aina katselmoida. Jos näitä arvoja ei voi kopioida leikepöydälle helposti, on niiden myös syytä olla mahdollisimman helposti myös lähimuistista kirjoitettavia. Luonnollinen kieli on helpommin muistettavaa sen muistisääntöjen perusteella jaottelun vuoksi kuin merkkijonot, joissa jokainen merkki täytyy muistaa erikseen.
Myös näissä arvoissa voi käyttää avainsanoja. Ne auttavat osaltaan muistettavuutta luomalla kaavoja. Mutta niihin voi myös tarvittaessa kytkeä sääntöjä tyylitiedostoissa esimerkiksi kansia varten. Koska esimerkiksi linkkien kohteet määritetään näitä samoja ID-arvoja hyödyntävillä href-arvoilla, voi avainsanoja käyttää myös erilaisiin kohteisiin kohdennettujen linkkien toisistaan erottamiseen esimerkiksi väreillä tai loppuun lisätyillä tunnisteilla kuten t yläindeksinä linkeissä tutoriaalien sisältöihin.
Valitettavasti avainsanoja ei voi käyttää otsikkosisältöjen (topic) ID-arvoissa DoX CMS:ssä. Ainoastaan kaikkiin niistä voi kuitenkin kohdentaa sääntöjä esimerkiksi määreellä, että ID-arvossa ei saa olla mitään aakkosia. Tämän voi tehdä antamalla erillisen lisämääreen jokaiselle kirjaimelle muodossa :not([href*=”a”]) eli ’ei arvoja, joissa tämä kirjain on mukana’.
Elementtiluokat
Elementtiluokkiin pätevät kaikki samat säännöt kuin muihin komponentteihin. Lisäksi niiden nimissä on syytä huomioida tyylitiedostojen kanssa käytettävyys. Attribuuttien ala-arvoihin kohdennetut valitsijat antavat lisätä sääntöjä useammalla elementtiluokalle kerrallaan perustuen niiden sisältämiin avainsanoihin. Tällä tavoin esimerkiksi kaikkiin taulukkojen sarakeleveyksiä säätävissä elementtiluokissa ei vaadita toistoja, jos jokaisessa niistä on mukana haluttuja sarakeleveyksiä ilmaisevia avainsanoja. Tarkkojen arvojen sijaan nämä voivat olla myös suhteellisia arvoja kuten narrow, wide tai half. Näille voi määrittää oletusarvot merkityn taulukon sarakkeiden kokonaismäärän mukaisesti ja esimerkiksi erikseen muille sen perusteella, onko myös half osa kyseistä arvoa.
Tällaisen elementtiluokan nimi voisi siis esimerkiksi olla Table_5col_1wide_2narrow_3wide. Tämä ilmaisee, että kyseessä on viiden sarakkeen taulukko, jonka ensimmäinen ja kolmas sarake ovat leveitä ja toinen kapea. Loput kaksi jätetään määrittämättä eli jäljelle jäävä tila jaetaan tasan niiden kesken.
table[doxelementclass*="half"], table[doxelementclass*="narrow"], table[doxelementclass*="wide"], [doxelementclass*="half"] > table, [doxelementclass*="narrow"] > table, [doxelementclass*="wide"] > table
{table-layout: fixed;}
[doxelementclass*="_1narrow"] th:nth-child(1),
[doxelementclass*="_2narrow"] th:nth-child(2)
{max-width: var(--columnNarrow);}
[doxelementclass*="_1wide"] th:nth-child(1),
[doxelementclass*="_2wide"] th:nth-child(2)
{min-width: var(--columnWide);}
[doxelementclass*="_1half"] th:nth-child(1),
[doxelementclass*="_2half"] th:nth-child(2)
{width: var(--columnHalf);}
[doxelementclass*="_1narrow"][doxelementclass*="half"] th:nth-child(1),
[doxelementclass*="_2narrow"][doxelementclass*="half"] th:nth-child(2)
{max-width: var(--columnNarrowWithHalf);}
[doxelementclass*="_1wide"][doxelementclass*="half"] th:nth-child(1),
[doxelementclass*="_2wide"][doxelementclass*="half"] th:nth-child(2)
{min-width: var(--columnWideWithHalf);}
body {
--columnHalf: 50%;
--columnNarrow: 15%;
--columnNarrowWithHalf: calc(var(--ColumnNarrow) * (2 / 3));
--columnWide: 40%;
--columnWideWithHalf: calc(var(--ColumnNarrow) * (3 / 4));
}Aivan yksinkertaisesta ratkaisusta ei ole kyse, koska eri järjestyslukujen sarakkeita varten täytyy kopioida ja mukauttaa niitä koskevat osuudet. Yllä näin on tehty vain kahdelle ensimmäiselle sarakkeelle. Lisäksi jaetut tai yhdistetyt solut voivat sotkea näitä sääntöjä, joten niiden käytölle täytyisi asettaa selvät säännöt.
Muuttujia ja laskelmia ei välttämättä tarvita osana näitä määreitä. Ne kuitenkin antavat suhteuttaa nämä arvot toisiinsa helposti ja hallinnoida niitä yksittäisistä sijainneista. Puolet tilasta vievän leveyden muuttujalle on annettu varmuuden varalta oma muuttujansa, koska sen arvoa voi olla tarpeen sopeuttaa esimerkiksi eri julkaisumuodoille ja näin sen saa tehtyä yhtä arvoa muokkaamalla.
Yhteenveto
Sekä komponentit että elementit on syytä nimetä järjestelmällisesti. Tämä sekä auttaa löytämään ne nopeammin ja vähentää niiden virheellistä käyttämistä. Löytämistä nopeuttaa varsinkin suodattimille soveltuvien avainsanojen käyttäminen, joka myös antaa lokeroida kyseiset sisällöt varsinkin valikoissa, jotka esittävät ne aakkosjärjestyksessä. Tällaiset alaluokat varmistavat, että muutoin helposti keskenään sotkeutuvat arvot on luultavammin erotettu toisistaan eri sijainteihin listalla. Lisäksi ne tarjoavat seurattavia ajatuspolkuja, kun käyttäjät eivät muista tarkkoja pohja-arvoja ulkoa.
Luokitteluun käytetyt avainsanat tulee valita ja järjestellä harkiten näiden polkujen luomiseksi sekä tulevien arvojen ennakoimiseksi. Aloittakaa yleisimmältä tasolta. Ylemmän tason ollessa epäselvä usean vaihtoehdon kesken harkitkaa, mitkä luokat ovat tärkeimpiä teille ja voiko samaa avainsanaa toistaa useamman luokan sisällä.
Hyvä nimien kieliasu vaatii yhteneväisiä muotoiluja, mikä kattaa sekä isojen kirjaimien käyttöpaikat että käytetyt välimerkit ja niiden paikat. Tältä osin valitun järjestelmän on tärkeää olla mahdollisimman yhteneväinen ja selkeä, jotta käyttäjät muistavat käyttää molempia oikein.
Lisäksi sanavalintojen täytyy olla mahdollisimman ymmärrettäviä ja muistettavia. Käyttäjien täytyy tunnistaa ilmaisujen merkitys ilman tarvetta tulkita niitä tietoisesti ja muistaa oikeat etsittävät ilmaisut ajatuspolkujen seuraamiseksi. Lähekkäiset sanat eivät saa muistuttaa toisiaan liikaa ja lyhenteitä kannattaa välttää. Koodien osalta niissä on ihanteellisesti selkeitä kaavoja, joiden mukaiset arvot käyttäjä voi oppia sääntöinä yksittäisarvojen sijaan.
Samat seikat voi ja kannattaa huomioida myös elementtien nimissä. Niiden osalta kyse on ID-arvoista ja elementtiluokista. Niiden tapauksessa näihin arvoihin ja niiden alaosuuksiin liittyy myös toiminnallisuutta, jolla on omat vaateensa. ID-arvojen muistettavuuden merkitys korostuu, koska niitä käytetään viitteisiin. Molempien avainsanoja voi käyttää myös tyylitiedostoissa ilman tarvetta viitata koko arvoihin joka yhteydessä.