Muistan venäläisen luennoitsijan vitsin yliopiston kansainvälisen kommunikaation kurssilta: ’Suomessa kaikki toimii, mutta mitään ei saa tehtyä. Venäjällä mikään ei toimi, mutta mikä vain on tehtävissä.’ Tällainen tasapainottelu valmiuden ja sovellettavuuden välillä pätee myös muissa asiayhteyksissä, ja siihen liittyy lahjuksia vain osan ajasta. Sen sijaan joustavampien toimintojen soveltaminen vaatii enemmän suunnittelua ja kasaamista. Tämän artikkelin ohjeista on hyötyä siltä osin DoX CMS:n eri toimintojen tällä tavoin soveltamisen osalta.
Iso osa DoX CMS:n toiminnoista on jossakin määrin sovellettavissa. Toiset näistä toiminnoista ovat muita joustavampia. Tagien eri tavoin käyttäminen johtaa aina tarpeeseen huomioida myös niihin sisäänrakennettu julkaisujen sisältöjen suodatus. Sen sijaan elementtiluokat ovat pelkkä vapaamuotoinen kohdentamiskeino, ja niihin liittyvä toiminnallisuus täytyy lisätä esimerkiksi tyylitiedostojen kautta. Tyylitiedostojen vapaa muokkaaminen puolestaan antaa lisätä tyylejä mihin tahansa saatavilla oleviin kohdistamistapoihin perustuen eli jopa yksittäisille elementeille niiden ID-arvojen perusteella.
Käyn tässä artikkelissa läpi tarkemmin, kuinka yleisluontoisten toimintojen suomaa vapautta voi soveltaa parhaiten DoX CMS:n käytön ohessa sekä tällaisten käyttötapojen rajoituksia.
Tausta-arkkitehtuuri
Sisällön muotoiluun ja hallintaan käytettävissä olevat toiminnot voi nähdä rakennustarvikkeina ja työkaluina, joiden avulla käyttäjät muodostavat sisältönsä. Tarkemmin määritetyt toiminnot koostuvat kovista materiaaleista ja niillä on ennalta tarkkaan määritetyt muodot. Jos niitä alkaa vääntämään uusiin käyttötarkoituksiin, on riskinä aina, että ne napsahtavat palasiksi. Yleisluontoiset toiminnot ovat puolestaan raaka-materiaaleja. Niistä saa muotoiltua halutunlaisia kokonaisuuksia, mutta se vaatii enemmän omaa työstämistä.
Toimivien kokonaisuuksien eri tarpeisiin rakentaminen näissä puitteissa vaatii suunnittelua. Mitä soveltavampia tällaiset ratkaisut ovat, sitä enemmän tällaista tausta-arkkitehtuuria täytyy kehittää. Yleisluontoiset toiminnot ovat tärkeä osa tätä prosessia, koska niiden sovellettavuus sallii täyttää aukkoja järjestelmien sisällä ja välillä. Käyn alla läpi periaatteita tähän liittyen ja esitän lisäksi yhden DoX CMS:n puitteissa kehittämäni esimerkin.
Toiminnallisuuden rakentaminen
Kukin näistä toiminnoista vastaa ainakin yhtä kahdesta avainroolista. Nämä roolit ovat toiminnallisuuksien kohdentaminen ja toiminnallisuuksien lisääminen. Osa kuten tagit soveltuvat molempiin. Tällöin toisen toiminnon sovittaminen yhteen niiden kanssa vaatii valmiin käyttötavan ympärille rakentamista.
Kohdentaminen
Kohdentaminen perustuu tunnisteisiin. Tämä toimintamalli on rakenteisen kirjoittamisen ytimessä: kaikkien eri elementtien oletusasettelu perustuu niille määritettyihin tunnisteisiin kuten ’<p>’ tekstikappaleille. Vastaavasti erilaisille elementeille annetut muut tunnisteet kuten niiden DITA-ominaisuudet tai tagit määrittävät, kuinka näihin tunnisteisiin perustuvat järjestelmät käsittelevät kyseisiä sisältöjä. Esimerkiksi DoX CMS suodattaa sisältöjä niiden tagien perusteella, ja nämä tagit ovat elementtien attribuutteja.
Yleisluontoiseen kohdentamiskeinoon ei liity minkäänlaista sisäänrakennettua toiminnallisuutta. Tällöin sitä voi tarvittaessa soveltaa eri yhteyksissä. Ihanteellisesti järjestelmä kuitenkin tukee tällaista kohdentamiskeinoa, jolloin se ei tuota ongelmia sisällön standardien osalta ja nämä tunnisteet voi lisätä järjestelmän tukemalla tavalla niiden itse joka kerta kirjoittamisen sijaan.
DoX CMS:ssä tällainen avonainen kohdentamiskeino ovat elementtiluokat. Niiden ensisijainen suositeltu käyttötapa on poikkeuksien luominen yleisiin elementtien tyyppejä koskeviin asettelun sääntöihin. Tällöin tyylitiedostossa saa määritettyä elementtiluokkaan perustuvat tilannekohtaiset säännöt kuten taulukon asettelun yksityiskohdat. Tämä toiminnallisuus perustuu kuitenkin kokonaan tyylitiedostojen käyttämiseen tällä tavoin elementtiluokkien käyttämisen jälkeen. Kyse ei ole elementtiluokkiin sisäänrakennetusta toiminnosta.
Periaatteessa myös muita järjestelmän tunnisteita kuten tageja voi käyttää tällä tavoin. Koska niihin liittyy myös muuta toiminnallisuutta, täytyisi tämä kuitenkin huomioida näiltä osin ongelmien välttämiseksi. Esimerkiksi tagien tapauksessa kyseiset tagit täytyy valita julkaisujen käyttöön niihin liittyvien sisältöjen sisällyttämiseksi julkaisuihin. Esimerkki tästä on mobiilikohtaisten sisältöjen näkyvyyden hallinnointi tageihin kytketyillä tyyleillä. Lisätietoja aiheesta löytyy täältä.
Muuttujat eivät anna kohdentaa toiminnallisuutta suoraan. Sen sijaan ne antavat kohdentaa niiden sisään muilla tavoin kohdennetut toiminnallisuudet sisältöön yksilähteistetyllä tavalla. Tämä vähentää työmäärää soveltuvien monimutkaisten rakennelmien tapauksessa. Tällöin näitä kohdentamiskeinoja ei tarvitse toistaa jokaisessa käyttöpaikassa.
Toiminnallisuus
Pelkkä kohdentaminen ei koskaan riitä. Kohdennustavan ympärille täytyy myös rakentaa toiminnallisia eroja jollakin tavoin. Nämä toiminnallisuudet voidaan periyttää valmiilta ominaisuuksilta kuten tageilta kohdentamalla niitä poikkeavalla tavoin. Ne voidaan myös kirjoittaa järjestelmän kanssa yhteensopivilla avoimilla menetelmillä. DoX CMS:n sisällä tämä tarkoittaa lähinnä CSS-tyylitiedostoja. Kun sisällöt siirretään muiden järjestelmien käsiteltäviksi esimerkiksi niiden julkaisemisen jälkeen, tämä toiminnallisuus voi myös perustua kyseisiin muihin järjestelmiin.
Tyylitiedostot antavat esimerkiksi hallinnoida sisällön näkyvyyttä tilannekohtaisesti kuten olen käynyt läpi aiemmissa artikkeleissa. Esimerkiksi täältä löytyy keino vaihtaa näytetyt elementit mobiilipäätteillä. Sama artikkeli viittaa myös uudelleenasettelun keinoihin kuten flexbox-asetteluun. CSS tukee sen lisäksi muita vastaavia keinoja. Lisäksi niiden avulla voi määrittää sivuryhmiä DocRaptorin käyttöön. Tällaisiin sivuryhmiin voi puolestaan kytkeä muita ominaisuuksia kuten erilaisen asettelun liitteille tai sivun suunnan kääntämisen. Tyylitiedostot antavat myös lisätä osuuksia pseudoelementteinä tai toiminnallisuuksia pseudoluokkien kuten osoittimen sijaintiin perustuvan :hover-valitsijan avulla. Myös CSS-animaatiot ovat mahdollisia, ja niistä löytyy lisätietoja täällä. Tällaisten työkalujen puitteissa yllättävän laaja toiminnallisuuden laajentaminen on mahdollista pelkkien tyylitiedostojen kautta.
Suurempi vapaus tältä osin perustuu kuitenkin sisällön valmistelemiseen muiden järjestelmien käyttöön.
Järjestelmäintegrointi
Sisällölle DoX CMS:ssä annetut tunnisteet pysyvät osana sisältöä, kun se julkaistaan rakenteisissa formaateissa kuten HTML tai DITA. Tällöin myös järjestelmät, joihin nämä sisällöt sijoitetaan voivat käyttää näitä tunnisteita niihin kuuluvien toimintojen kohdentamiseen. Toki se vaatii, että tällainen kohdentaminen on hallinnoitavissa. Käyn alla joitakin esimerkkejä tältä osin.
Sisällön käsittelyn integroinnin kannalta tärkeimmät toiminnot liittyvät sisällön jaotteluun ja sijoitteluun sen päämäärissä. Rakenteiset sisällöt voi paloitella sen sisältämien tunnisteiden perusteella ja nämä palat voi sijoittaa näytettäviksi halutuilla tavoin. Tällaisen hallinnoinnin tukena voi käyttää myös lisätunnisteita, jotka kohdejärjestelmä lisää DoX CMS:ssä kirjoitettuihin sisältöihin sen aiempien tunnisteiden perusteella. Tällaiset lisätunnisteet voivat olla tilannekohtaisia ja niiden käyttö aktiivisesti hallinnoitua. Esimerkiksi WebHelp-julkaisut DoX CMS:ssä perustuvat osaltaan tällaisiin tunnisteisiin kuten luokkaan .open, jonka sisällysluettelo saa ollessaan näytettynä ja menettää ollessaan piilotettuna.
Muita dokumenttien toiminnallisuuteen vaikuttavia tapoja, joiden taustalla on mahdollista käyttää niiden jo sisältämiä kohdennuskeinoja, ovat esimerkiksi
- osioiden sisällön muokkaamisen mahdollistaminen,
- kohdistetun kommentoinnin mahdollistaminen,
- lisättyjen korostuksien mahdollistaminen,
- kirjanmerkkien ankkuroiminen,
- sisällön uudelleenjärjesteleminen,
- sisältöjen välisten siirtymien itse lisäämisen mahdollistaminen,
- upotettujen jakamismuotojen mahdollistaminen ja
- pääsyn rajaaminen ja hallinnointi.
Esimerkkisovellus: Yksilähteistetty julkaisun sisällä muuttuva osuus
Olen esitellyt erilaisia keinoja yhdistää DoX CMS:n toimintoja myös aiemmissa artikkeleissa. Tärkeimpiä normaalin käytön osalta ovat esimerkiksi eri tavoin toteutetut sisäkkäiset muuttujat sekä muuttujat, joiden arvot on ehdollistettu. Jälkimmäiset ovat yleinen tapa viitata esimerkiksi laitteiden malleihin.
Ehdollistamisen normaali rajoitus on kuitenkin, että tällä tavoin näytetyt arvot perustuvat koko julkaisun tageihin. Esimerkiksi tällä tavoin toteutetun muuttujat arvo on sama halki koko dokumentin.
Tämä kuitenkin tarkoittaa, että saman dokumentin sisällä eri asioihin viittaavat toistuvat osiot eivät ole yksilähteistettävissä tavanomaisin keinoin. Esimerkiksi eri valikoiden komentorivejä kuvaavat osuudet, jotka viittaavat kyseisiin valikoihin nimeltä, eivät voi perustua sisältöviitteisiin (conref), koska jokainen käyttöpaikka ei ole sisällöltään täysin vastaava.
Tämän ohittaminen vaatii käytännössä julkaisun sisäisiä tageja, jotka kertovat aluekohtaiset aiheet. Valitse julkaisujen käyttöön tämän kategorian tagit, joihin liittyvät sisällöt haluat mukaan julkaisuihin. Tee näin myös silloin, kun julkaisuun täytyy tulla kaikkien näistä sisällöistä. Lisää myös elementtiluokka, joka merkitsee tällaiset osuudet. Muussa tapauksessa julkaisuihin voi syntyä virheitä tähän ratkaisuun liittyvien sääntöjen astuessa voimaan vahingossa. Elementtiluokka varmistaa, että kirjoittajan on täytynyt päättää käyttää tätä vaihtoehtoa.
Saman dokumentin sisällä toistuvat osiot, jotka viittaavat eri asioihin, saa yksilähteistettyä tällä tavoin:
- Lisää järjestelmään saman kategorian sisäiset tagit kullekin vaihtoehdolle siltä osin, mihin kyseinen osio voi viitata.
- Lisää järjestelmään elementtiluokka tämän toiminnallisuuden kohdentamiseksi.
- Lisää järjestelmään lähdeversiot näille osuuksille niille omistettuihin otsikkosisältöihin.
- Merkitse lähdeversiot tähän tarkoitetulla elementtiluokalla.
- Lisää lähdeversioiden sisään fraasielementit (ph) kullekin vaihtoehdolle kohdissa, joissa niihin viitataan. Valitettavasti muuttujat eivät toistaiseksi toimi sisältöviitteiden (conref) sisällä.
- Lisää kullekin fraasielementille sen sisältöä vastaava tagi.
- Lisää lähdeversioille ID-arvot ja julkaisujen sisällä oleville kohdeversioille Conref-arvot, jotka osoittavat lähdeversioiden sijainteihin.
- Lisää joko otsikkosisällöille (topic) tai osioelementille (section), joiden sisällä kohdeversiot ovat, tagit, jotka vastaavat niiden käyttöön tarkoitettuja arvoja näissä käyttöyhteyksissä.
- Lisää tyyleihin alla esitettyjä vastaavat säännöt oikealla elementtiluokalla ja oikeilla tageilla.
Näkyvyyden hallinnointi tässä tapauksessa tapahtuu tyylitiedoston kautta. Näkyvyyttä hallinnoivat säännöt on kohdennettu siten, että sisäkkäiset elementit näyttävät vain keskenään koordinoidut versiot, kun sisempi osuus on osa tähän tarkoitetulla elementtiluokalla merkittyä elementtiä. Valitettavasti yleistä sääntöä tältä osin ei voi määrittää pelkän CSS:n puitteissa, vaan jokaiselle tagille täytyy antaa oma kohdistajansa tältä osin.
Muista korvata tagikategorioiden nimet, tagien nimet ja elementtiluokan nimi vastaamaan käyttämiäsi tunnisteita. Tämä on myös mahdollisimman yleisluontoinen muotoilu. Jos lisäät valitsijaan lisämääreitä oman käyttötapanne mukaisesti, se vähentää riskiä, että kyseinen sääntö astuu voimaan väärässä yhteydessä.
[data-doxattribute-featurenames="Feature1"] [doxelementclass~="TopicalValue"] span[data-doxattribute-featurenames]:not([data-doxattribute-featurenames="Feature1"]) {
display: none;
}
Rajoitteet
Yleisluontoisten toimintojen varaan rakennetuilla toteutuksilla on myös rajoitteensa. Käyn alla läpi kolme eri seikkaa, jotka toteuttajien on syytä huomioida tältä osin. Näistä syistä joskus on parempi tyytyä järjestelmän määrittämään toimintatapaan, vaikka kyseessä olisi kompromissi verrattuna toteutettavissa olevaan ratkaisuun.
Oletustoiminnallisuus
Jos ratkaisun kehittäminen vaatii koskemista järjestelmän osuuksiin, joilla on valmiiksi määritellyt toiminnallisuudet, on riskinä aina, että tämä rikkoo kyseisten järjestelmien normaalin käytön. Tämä voi joko rajoittaa tai monimutkaistaa järjestelmän käyttöä tältä osin, koska kyseinen järjestelmän osuus ei ole enää käytettävissä sen oletustavalla tai vastaava toiminnallisuus täytyy rakentaa uudelleen muuta kautta. Kun kyseisenlaiset toiminnot ovat osa suunniteltua ratkaisua, varmista, että tämä on yhteensopivaa niiden ensisijaisen käyttötavan kanssa.
Olen nähnyt varsin monenlaista säätöä tältä osin. Kenties varoittavin esimerkki oli kuitenkin näistä tuotoksista toimivin. Sen tekijöiltä löytyi riittävästi osaamista viedä ratkaisunsa loppuun saakka, ja lopputulos oli teknisesti hyvin vaikuttava. Ellen ole tulkinnut tilannetta väärin, kaikki heidän näkemänsä työ tältä osin oli kuitenkin turhaa, koska helpompi ratkaisu olisi ollut saatavilla alusta alkaen.
Kyseisessä tapauksessa erinäiset sisällöt haluttiin kehystää laajemmiksi, useasta eri elementistä koostuviksi askeliksi. Kirjoittajat olivat päättäneet käyttää tähän taulukoita. Koska simpletableissa ei ollut kaikkia vaadittuja toimintoja, he käyttivät täysiä taulukoita. Koska täysillä taulukoilla on jokaisen tällaisen taulukon laskeva numeroitu otsikko, he poistivat käytöstä oletusotsikkoformaatin ja kirjoittivat tyylitiedostojen avulla tilalle uuden. Koska oletusotsikkoformaatti vaikuttaa myös kuvakehyksien (fig) otsikoihin, he joutuivat tekemään saman myös niille. Koska järjestelmän lisäämät valmislinkit näihin elementteihin viittasivat käytöstä poistettuihin varsinaisiin otsikkokenttiin, täytyi heidän lisätä linkeille uuden toteutuksen arvot hakeva toteutus. Tämä toteutus vaati jokaisen linkin kohteen nimeämistä linkille annettavalla elementtiluokalla. Yhden järjestelmän perustoiminnallisuuden kaataminen siis aiheutti dominoefektin, jonka jokaisessa vaiheessa heidän täytyi rakentaa itse korvaava ratkaisu edellisen ratkaisun kaataman oletustoiminnallisuuden tilalle.
Ymmärtääkseni koko tämä tilanne olisi ollut vältettävissä käyttämällä kehyksinä taulukoiden sijaan osioelementtejä (section). Ennen tällaisten toteutuksien rakentamista on siis syytä käydä läpi saatavilla olevat vaihtoehdot ja mielellään kysyä mielipiteitä myös järjestelmän tarjoajalta.
Monimutkaisuus
On valitettava tosiasia, että joissakin tapauksissa halutunlaisen toteutuksen ollessa saatavilla, sen tekeminen tai käyttäminen olisi kuitenkin liian monimutkaista ollakseen sen arvoista. Tällöin on parempi hyväksyä, että saatava lisäarvo ei vastaa toteutukseen ja sen ylläpitoon menevää aikaa ja vaivaa.
Lisäksi monimutkaiset toteutukset ovat aina lisähaaste uusille käyttäjille, joiden täytyy päätellä oikea toimintamalli. Kun kyse on oletustoiminnallisuuden taivuttamisesta, on tämä erityisen vaikeaa. Järjestelmän käyttöopas on tällöin mahdollisesti harhaanjohtava, koska se kertoo vain näiden toimintojen oletustoiminnallisuuksista.
Yllä mainitussa tapauksessa uudet käyttäjät olivat todella haastavassa tilanteessa, koska kyseinen järjestelmä oli rakennettu äärimmäisen tarkkarajaisesti. Pienikin virheaskel sisällön muotoilussa johti odottamattomiin tuloksiin, koska sisällön ja tyylitiedoston välinen suhde oli niin tiukka. Esimerkiksi kuvakehyksissä (fig) ylimääräisen tekstikappaleen lisääminen listan alapuolelle johti sen siirtymiseen listan yläpuolelle julkaisuvaiheessa, koska ymmärtääkseni kuvakehykset oli määritetty flexboxeiksi, joissa listat ja otsikot oli määritetty peräkkäisiksi pohjimmaisiksi elementeiksi. Lopputulos oli sellaisenaan toimiva ja jopa kaunis samalla tavoin kuin jalokivi. Valitettavasti se oli myös yhtä periksiantamaton ja hauras.
Sisäinen dokumentaatio
Koska tällaiset käyttötavat ovat lähtökohtaisesti asiakaskohtaisia, ei niihin liittyen löydy kuin teidän oma sisäinen dokumentaationne. Jos tällaista sisäistä dokumentaatiota ei löydy niiden osalta, joutuvat ilman edeltäjiensä opastusta aloittavat uudet käyttäjät päättelemään oikeat toimintatavat näiltä osin itsenäisesti. Kun nämä ratkaisut perustuvat osittain valmiiden toimintojen soveltamiseen poikkeavilla tavoin, on riskinä myös näiden toimintojen käyttäminen väärin seuraamalla niiden oletustoimintamallia. Tällaiset toteutukset voivat vaikuttaa oikeaan tapaan käyttää niihin liittyviä toimintoja.
Lisätietoja sisäisen dokumentaation merkityksestä ja ylläpitämisen tavoista DoX CMS:ään liittyen löytyy täältä.
Esimerkkinä käyttämässäni tapauksessa oikeisiin toimintatapoihin liittyen ei löytynyt sisäistä dokumentaatiota. Aiemmat käyttäjät kuitenkin tarjosivat uusille käyttäjille esittelyä liittyen kyseisen järjestelyn oikeaan käyttötapaan osana normaalia työnkiertoa. Tällöin haasteeksi jäi silti toimintamallien taustatekijöiden ymmärtäminen ja tästä syystä muutoksien toimintamalleihin sovittaminen yhteen näiden tekijöiden kanssa.
Yhteenveto
Eri toiminnot asettuvat eri kohtiin jatkumolla toiminnallisuudeltaan tarkkarajaisista täysin avoimiin. Tarkkarajaiset toiminnot tekevät, mitä ne lupaavat, mutta yritykset soveltaa niitä muilla tavoin voivat rikkoa ne. Avoimemmat toiminnot ovat joustavampia ja niitä voi käyttää tarkkarajaisten toimintojen ohjaamiseen uudella tavoin. Mitä vähemmän sisäänrakennettua toiminnallisuutta niissä tosin on, sitä enemmän työtä tällaisen toiminnallisuuden rakentaminen vaatii.
Uusien toimintamallien rakentaminen vaatii sekä kohdentamista että jonkinlaista kohdennettua toiminnallisuutta. Toimintoja yhdistettäessä kukin niistä toimii ainakin yhdellä näistä tavoista, ja kumpikin näistä rooleista täytyy täyttää jollakin tavoin. Esimerkiksi elementtiluokat ovat kohdentamiskeino ilman minkäänlaista sisäänrakennettua toiminnallisuutta. Tyylitiedostot puolestaan antavat laajentaa järjestelmän toiminnallisuutta sisältöjen muokkaamisen osalta CSS:n rajojen ja saatavilla olevien tunnisteiden puitteissa.
Kohdentamiskeinot sallivat myös sisällön valmistelemisen muiden järjestelmien käyttöön. Tällöin nämä muut järjestelmät voivat käyttää tällä tavoin merkittyihin sisältöihin omia toiminnallisuuksiaan ilman lisäaskelia.
Näillä tavoin DoX CMS:ään voi rakentaa esimerkiksi keinon yksilähteistää toistuvia osuuksia saman julkaisun sisällä, vaikka niiden aiheet vaihtuisivat eri käyttöyhteyksissä. Ehdottamassani mallissa kohdistaminen perustuu elementtiluokan ja tyylitiedoston avulla mukautettuihin tageihin sisältöviitteiden (conref) tukena.
Tällaisten ratkaisujen rakentamisella on toki myös rajoitteensa. Kaikkien toteutuksien täytyy huomioida myös käytettyjen toimintojen oletustoiminnallisuudet ja varmistaa, että uudet ratkaisut ovat yhteensopivia niiden osalta tarvitun normaalin käytön kanssa. Jos toteutus on liian monimutkainen suhteessa sen avulla saavutettuihin hyötyihin, ei se myöskään yleensä ole hyvä ajatus. Koska kaikki tällaiset ratkaisut poikkeavat järjestelmän normaalista käytöstä, eivät uudet käyttäjät löydä ohjeita koskien oikeita tapoja toimia käyttöohjeista. Sen sijaan vaaditaan sisäistä dokumentaatiota, joka selittää heille sekä oikeat tavat toimia että niiden taustasyyt.