Single sourcing – mis, milleks, ja kuidas?

Tänapäeva tehnosuhtluse maailmas on kesksel kohal termin single sourcing. Kahjuks ei suutnud ma kusagilt selle eestikeelset tõlget leida – ettepanekud on teretulnud.

Mis see on?

Ühe lausega – sama sisu kasutamine erinevates dokumentides või erinevates formaatides (näiteks HTML ja PDF).

Pikemalt – see on sisu avaldamise meetod. Autorid (tehnosuhtlejad) loovad sisu täpselt ühe korra ja sellest luuakse mehaaniliste vahenditega erinevad dokumendid. Sel juhul on dokumentatsioon nagu kastitäis Lego klotse, millest saad kokku panna kõike, mida vaja on. Traditsiooniline dokumentatsioon on nagu rida automudeleid – need võivad küll olla ilusamad, aga samas on nad kõik erinevad. Ja kui üks mudel katki peaks minema (loe: dokument uuendamist vajama), siis selle parandamine on väga raske.

See illustreerib ka üht single sourcingu põhimõtet – info ühikuks on teema, mitte dokument. Teisisõnu ei saa enam mõelda infost näiteks manuaalide kaupa – toote A manuaal, toote B manuaal, ja nii edasi. Selle asemel tuleks mõelda üksikutest teemadest, millest manuaalid kokku pannakse. Teemasid on mitut liiki – mõiste selgitus, protsess, õpetus, ja nii edasi. Iga teema on iseseisev infokogum, mis ei tohiks otseselt sõltuda tema asukohast dokumendis. See ei tähenda, et kasutajalt ei tohiks mingeid teadmisi eeldada – õpetus MySQL serveri üles seadmiseks peab paratamatult eeldama, et kasutaja teab, mis on andmebaas, mis on server, ja nii edasi. Aga samas ei tohi teema eeldada, et kasutaja on vahetult enne mingit konkreetset teist teemat lugenud.

Teemapõhine lähenemine on single sourcingu aluseks. Väga raske on hakata dokumentidest tükke lõikuma ja neist uut dokumenti kokku panema. Samahästi võiks ette võtta Tammsaare kogutud teosed ja üritada sealt peatükke välja lõikudes uut romaani kokku panna.

NB! Single sourcing ei tähenda lihtsalt seda, et sisu avaldatakse erinevates formaatides. Näiteks Microsoft Word lubab nii HTML kui PDF formaadis dokumente salvestada, aga see ei ole single sourcing – tegu on ikkagi sama dokumendiga, mitte erinevate osade taaskasutusega.

Milleks seda üldse vaja on?

Ennekõike vähendab see tehnosuhtlejate tööd, kuna enam ei pea iga dokumenti eraldi koostama. Tehnosuhtleja ülesandeks on ainult sisu luua; edasine protsess (kujundus jms.) ei ole enam tema mure.

Samuti tagab see, et dokumendid oleks omavahel kooskõlas – nende sisul on ühtne allikas ja kui sisu muutub, siis on kõigi seda sisu kasutavate dokumentide uuendamine mõne minuti küsimus.

Tõlkimine on samuti lihtsam – selle asemel, et iga dokumenti eraldi tõlkida, tõlgitakse vaid algne sisu. Esiteks on see oluliselt odavam, kuna iga teemat tõlgitakse ainult üks kord, hoolimata sellest, kui mitmes dokumendis see esineb. Ja teiseks tagab see, et mitmes dokumendis esinev sektsioon on alati täpselt samamoodi tõlgitud, mis tähendab vähem vigu.

Dokumentide kujunduse haldamine on lihtsam – kuna kujundusega tegelevad automaatsed protsessid, siis ei pea autorid enam sellele mõtlema. Ja kui kujunduses midagi muutub (näiteks otsustatakse, et klahvide nimed ei pea enam kaldkirjas olema; või muutub ettevõtte nimi), siis ei ole vaja enam iga dokumenti ridahaaval läbi käia.

Lisaks saab ka sisu taaskasutada. Näiteks faili avamise või salvestamise protseduur võib esineda paljudes erinevates ülesannetes. Single sourcing lubab seda ühe korra kirjutada ja siis igas vajalikus kohas kasutada. Jah, tavalistes dokumentides on ka võimalik seda kuskilt vajadusel kopeerida. Aga mis siis saab, kui näiteks faili avamiseks kasutatava menüü nimi muutub? See võib küll mõjutada ainult ühte sammu, aga kui see samm esineb dokumendis kümme korda? Ja kui dokumente on paarkümmend? Suurem osa single sourcing lahendustest lubab sellist fragmenti kasutada viitena (programmeerijatele – analoogiline include käsule). Kui lõppdokument genereeritakse, tõmmatakse ka viidatud fragment dokumenti, nii et seda ei pea käsitsi uuendama.

Loomulikult ei ole single sourcing kõigele lahendus. Kui dokumendid on väga erineva sisuga, siis ei anna single sourcing midagi juurde. Kriitikud väidavad ka, et selle tarbeks tuleb info väga kitsastesse raamidesse suruda ja see omakorda vähendab teksti sujuvust. Autorid peavad ümber õppima dokumentide asemel teemasid koostama. Selle rakendamine võib olla kulukas ja aeganõudev. Mis on kõik tõsi. 🙂 Aga samas võib see õigetes tingimustes kõvasti aega ja vaeva kokku hoida.

Kuidas see käib?

Selle küsimuse vastus on kaheosaline: sisuline ja tehniline pool.

Sisusine pool tähendab eelkõige oma dokumentide ümberstruktureerimist teemade tasemele. Selleks tuleb nende sisu analüüsida, see loogiliselt eri tüüpi teemadeks jaotada, ja koostada dokumendikaardid (document maps), mis ütlevad, mis teemadest mingi dokument kokku pandud on. Kindlasti ei ole see lihtne ega kiire protsess, aga lõpptulemus peaks olema hulk üksteisest sõltumatuid teemasid, mis on piisavalt lühikesed ja paindlikud, et neid eri kontekstis kasutada saaks.

Kui õigel kujul sisu olemas, siis edasine töö on lihtne. Uue dokumendi avaldamiseks tuleb koostada vastav dokumendikaart ja sööta see ette avaldamisprotessile. See protsess korjab kokku kõik teemad, millele dokumendikaart viitab, kujundab need ja väljastab soovitud tulemuse. Enamasti saab seda protsessi käivitada nii ühe dokumendi kui kõigi dokumentide tasemel.

Tehnilisi lahendusi on palju. Enamasti on sisu XML formaadis, kuna see on väga paindlik – avamiseks piisab suvalisest tekstitoimetist. Samas on ka lahendusi, mis kasutavad näiteks Microsoft Wordi dokumente allikana.

Selleks, et sisu soovitud väljundformaati jõuaks, on ka palju võimalusi. Adobe FrameMaker (structured), MadCap Flare, Adobe Robohelp, Help & Manual, AuthorIT, DITA… See, millist kasutada, on igaühe enda valik, vastavalt vajadustele ja eelarvele.

Minu kokkupuude

Et see jutt väga teoreetiliseks ei jääks, siis väike ülevaade ka sellest, miks see mind huvitab. Kui ma praegusele tööle asusin, oli dokumentatsioon rangelt eraldatud. Ühes andmebaasis oli online help, mida programmis F1 vajutades näidati; seda haldasid dokumenteerijad. Teises andmebaasis olid Microsoft Wordis kirjutatud manuaalid, mida haldasid osalt dokumenteerijad, osalt koolitajad, osalt projektijuhid… Kokkuvõttes ei vastutanud nende eest väga keegi, aga muudatuste tegemine oli enamasti dokumenteerijate ülesanne. Ainuke seos nende vahel oli see, et manuaalide sisu oli praktiliselt üks-ühele ka online helpi kopeeritud ja vahel lausa mitu korda eri aegadel. Seda siis lisaks online helpis endas olevatele juhenditele.

Tulemuseks oli see, et kui programmis miski muutus, tuli seda mitmes kohas uuendada:

  1. Online help – eraldiseisev osa.
  2. Online help – manuaali koopia.
  3. Manuaal.

Et elu huvitavam oleks, olid manuaalid kujundatud kahes veerus tabelitega – vasakul pildid ja pisut infot, paremal põhitekst. Selle tulemusena tuli alati pärast kuhugi paari lause lisamist kogu manuaal üle vaadata – kas tabeli read lõppesid ikka koos leheküljega? Kas mõni pilt lükkus järgmisele lehele, jättes endast maha suure tühja lahtri? Ja nii edasi.

Kuna minu arvates oli see protsess väga tüütu, aeganõudev ja vigadealdis, siis rääkisin oma tollasele juhile ideest, et teisiti saaks ka. Aasta hiljem oligi tulemuseks praeguseni kasutusel olev protsess, kus online help muudetakse XSL abil PDF manuaalideks. Nüüd saame keskenduda ainult online helpis info haldamisele ja manuaalide uuendamine on vaid mõne minuti küsimus.

Samas ei ole ka see süsteem probleemideta. Kõige suurem miinus on see, et me ei saa luua tekste, mis on kasutusel ainult manuaalis – kuna manuaalid genereeritakse F1 helpi HTML failide põhjal, siis ei saa neisse midagi lisada. Samuti seavad HTML failid piiranguid info organiseerimise ja esitamise osas. Seetõttu ongi juba paar aastat käigus vaikne liikumine DITA kasutusele võtu poole…

Lisa kommentaar

Sinu e-postiaadressi ei avaldata. Nõutavad väljad on tähistatud *-ga