DITA varjuküljed

Eelnevatest postitustest võib jääda mulje, nagu ma oleks tulihingeline DITA entusiast. Mingil määral ongi see nii – kuna ma alustasin dokumenteerijana tühja koha pealt, ei ole mul mingit formaalset erialast haridust ja seega ka mingit süsteemi, kuidas dokumenteerimisele läheneda. DITA kui moodne avatud standard kõlas just sellena, mida vaja – see on suhteliselt paindlik ja samas piisavalt formaalne.

Samas ei ole ka DITA täiuslik. Mark Baker on oma blogis avaldanud viieosalise kriitilise artikli The Tyranny of the Terrible Troika: Rethinking Concept, Task, and Reference DITA negatiivsete külgede kohta, millest üritan olulisemad punktid siin välja tuua.

Kõigepealt – Baker ei kritiseeri otseselt DITA kui arhitektuuri aluseid. Vastupidi, tema arvates on mõiste-ülesanne-viide üsna hea kolmik info analüüsimisel, kuna need vastavad kolmele käitumismustrile – õppimine, tegemine ja faktide kontrollimine. Populaarne on aga nende kolme tüübi kasutamine info vormide tähenduses – viited on tabelid, ülesanded on protseduurid ja igasugune muu tekst on mõisted. Kuna DITA ei sisalda informatsiooni disainimise juhiseid (erinevalt näiteks Information Mappingust), siis arvavad paljud inimesed, et see ei olegi vajalik. DITA õpetab, kuidas info kildudeks jagada, kuid mitte seda, kuidas need killud uuesti kokku panna.

Ülesanded ei ole protseduurid

Ülesanne on mingi tegevus, mida kasutaja soovib teha, või eesmärk, mida ta soovib saavutada. Protseduur on kõigest juhend, kuidas masinat käsitseda. Aga masina käsitsemine ei ole eesmärk iseenesest – kasutaja soovib masinat käsitsedes mingit oma eesmärki saavutada. Seega võib protseduur olla osa ülesande teemast, kuid see ei ole ülesanne ise.

Paljude ülesannete puhul ei ole aga tegelikud protseduurid vajalikud. Heaks näiteks on programmeerimine – kuigi see hõlmab mingite programmidega tegutsemist, on see tegevus alati sarnane sõltumata konkreetsest eesmärgist. Ükskõik mida programmeeritav funktsioon teeb, selle funktsiooni sisestamisse arvutisse on alati sama – programmeerijale ei ole vaja kirja panna, et ta peab trükkima funktsiooni nime ja siis parameetrid ja… Küll aga on programmeerimisülesannetes reglina koodinäited – kuidas eesmärgiks olev kood välja peaks nägema.

Konkreetsete seadmete (fotoaparaadid, mikrolaineahjud, lennukite autopiloodid, jne.) puhul on olukord veel keerulisem. Ülesanded peavad kirjeldama ka süsteemi omapärasid – millist koodi need üldse suudavad jooksutada, kui kiiresti, ja nii edasi. DITA paradigmas ei ole see osa ülesannetest, vaid tuleks esitada pigem mõistete või viidetena. Samas on selle info lahutamine ülesannetest endist kahjulik.

Seega – ülesanded ei tähenda lihtsalt protseduuride eraldamist muust tekstist.

Viited ei ole teemad

Baker väidab, et viited ei tohiks tegelikult olla isegi teemaliik. Kuigi näiteks programmeerimiskeele liides (API) koosneb paljudest üksteisega sarnastest teemadest, millest igaüks konkreetset funktsiooni kirjeldab, siis teemad on ainult üks viis seda infot esitada. Tänapäeval kolib dokumentatsioon järjest rohkem internetti ja seega ei pea sundima inimesi infot ainult mingil kindlal moel otsima. Miks peaks liidese teemad olema esitatud nagu paberkataloogi lehed, kui need võiks panna otsitavasse andmebaasi? Lugeja võib näiteks soovida nimekirja kõigist funktsioonidest, mis konkreetset andmestruktuuri puudutavad. Sellised nimeirjad on tihti liideste dokumentatsioonis olemas, kuid reeglina tuleb need käsitsi genereerida. Tunduvalt lihtsam oleks seda probleemi lahendada ühe andmebaasipäringuga.

See ei tähenda, et andmebaasid on hea viis viidete esitamiseks. Andmebaasid lihtsalt pakuvad info otsimiseks rohkem võimalusi kui fikseeritud kujundusega teemad. Seetõttu peaks viiteid esitama pigem andmebaasina, mitte olema kinni paberil manuaalidest pärit süsteemis. Loomulikult käib siin jutt XML andmebaasidest, mitte relatsioonilistest nagu MySQL – relatsioonilised andmebaasid ei ole kuigi sobiv viis sellise info säilitamiseks.

Kõik muu ei ole mõisted

Igas klassifikatsioonisüsteemis kipub olema eraldi kategooria selliste asjade jaoks, mis kuhugi mujale ei sobi. DITAs on selleks mõisted. Probleem on selles, et “mõiste” ei ole sama, mis “üldine”. Bakeri arvates on selline vale terminoloogia väga kahjulik järgnevatel põhjustel:

  1. “Üldine” paneb sind mõtlema, kas sa oled info tüüpimise lõpetanud – järsku ei ole see teema mitte üldine, vaid midagi muud. “Mõiste” jätab mulje, et selle teemaga on nüüd ühel pool.
  2. “Mõiste” ise on väga mitmetähenduslik. Samas peaks kategooria nimi olema võimalikult konkreetne.
  3. Tegelikkuses on “mõisted” ka reaalselt olemas – need on fundametaalsed ideed, millest toote kasutamiseks aru peab saama. Kui aga dokumentatsioonis on sadu “mõisteid”, kaovad tegelikud mõisted nende hulka ära.
  4. On palju teemasid, mis ei ole ei ülesanded ega viited, aga mis ei sobi ka mõistete alla ning ei ole üldised. Baker toob kaks näidet – kommenteeritud koodinäited (jupp koodi koos selgitustega, mida see teeb, mis on selle piirangud, ja nii edasi) ja “rajaleidja” teemad (selgitused, mis komponendid olemas on ja kuidas need koos töötavad). Kumbki neist ei ole mõiste selle traditsioonilises tähenduses.

Kokkuvõttes – “mõiste” ei ole hea termin kõige jaoks, mis ei ole ülesanded või viited. Info jagamine ülesanneteks, viideteks ja mõisteteks on nagu loomariigi jagamine kassideks, koerteks ja kõigeks muuks.

Kokkuvõte

Tehnosuhtluse maailmas on kuum teema teemapõhine kirjutamine ehk siis info kirjeldamine tillukeste kängardena (chunks). Samas on puudu teemapõhine infodisain ehk õpetus, kuidas need tükid kokku panna. Niisama teemasid kokku liites on tulemuseks Frankensteini koletise laadne elukas, mis koosneb kuidagiviisi kokku lapitud tükkidest. Põhiprobleemiks on see, et piisavalt tillukesed infokänkrad ei ole lugejale kuigi kasulikud – ühe mõiste kirjeldus võib tõesti koosneda ainult ühest lõigust, kuid see ei ütle lugejale kuigi palju. Mida selle mõistega edasi teha? Millega see seotud on? Kuhu edasi minna? Seda ei asenda ka hulk linke teistele teemadele – sel juhul oled sa nagu labürindis, kus on küll võimalik igas suunas liikuda, kuid sul pole õrna aimugi oma tegelikust asukohast. Seetõttu ei ole DITA stiilis info lahterdamine piisav kasuliku dokumentatsiooni koostamiseks.

Lisa kommentaar

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