Äh, Topics? Im Bei­trag Topics: Infor­ma­ti­ons­häpp­chen hirn­ge­recht ser­vie­ren wur­de bereits beschrie­ben, dass Topics klei­ne Ein­hei­ten in der Tech­ni­schen Doku­men­ta­ti­on sind, mit denen dem Leser (und auch dem Redak­teur) die Erfas­sung situa­tiv rele­van­ter Infor­ma­tio­nen erleich­tert wer­den soll. Wie aber macht man das? Ganz ein­fach: Man stellt den zu beschrei­ben­den Sach­ver­halt auf den Kopf und schüt­telt so lan­ge, bis nichts mehr her­aus­fällt. Dann dreht man es wie­der um und beginnt mit der Erfas­sung. Alles klar?

Wie bei den Häpp­chen spielt es auch für Topics zunächst kei­ne Rol­le, wo sie spä­ter ser­viert wer­den. Ob es bei der Aus­ga­be um ein gedruck­tes Doku­ment, eine Online­hil­fe oder eine PDF, einen kon­text­sen­si­ti­ven Hil­fe­text auf dem Bild­schirm oder ein e-Learning-Doku­ment geht, hat mit der Infor­ma­ti­on selbst nichts zu tun. Ent­spre­chend muss sie so kon­zi­piert wer­den, dass sie ohne Nach­ar­beit über­all ein­ge­setzt wer­den kann.

Position ist Bedeutung

Durch die Posi­ti­on der Topics bestimmt sich meist auch ihre Bedeu­tung. Aller­dings muss der Sach­ver­halt dann auch neu­tral beschrie­ben wer­den: die Infor­ma­ti­on muss so abge­fasst sein, dass jeg­li­cher Bezug auf eine bestimm­te Posi­ti­on ver­mie­den wird.

Einen guten Hin­ter­grund für das topic-basier­te Schrei­ben lie­fert der Text von Karen McGra­ne „Con­tent Stra­te­gy for Mobi­le“ bei A Book Apart 2012 (erhält­lich auch als eBook)

Meist wird dies in Online­hil­fe-Sys­te­men bereits umge­setzt – sofern sie modu­lar ange­legt sind. In der klas­si­schen Tech­ni­schen Doku­men­ta­ti­on im Maschi­nen­bau ist das noch nicht so weit ent­wi­ckelt, da die meis­ten Pro­zes­se aus phy­si­ka­li­schen Gege­ben­hei­ten line­ar sind und der Redak­teur dadurch ver­lei­tet ist, ent­spre­chend uni­di­rek­tio­nal zu den­ken. Die Schwie­rig­keit ist daher, uni­ver­sell ein­setz­ba­re Topics zu iden­ti­fi­zie­ren und zu bestim­men, was sie beinhal­ten wer­den – und die Bedeu­tungs­zu­wei­sung dem Kon­text zu über­las­sen. Man braucht also eine Struk­tur. Wie man das machen kann, steht auch im Bei­trag Anla­gen­do­ku­men­ta­tio­nen pla­nen und steu­ern: Erst den­ken, dann schrei­ben).

Struktur und Prozess

Zwei Schrit­te wei­ter. Wir stel­len uns vor, die­se Struk­tur ist vor­han­den, alle Topics sind bestimmt. Für die Umset­zung neh­men wir das Pro­gramm Mad­Cap Fla­re, selbst wenn wir nicht für eine Online-Aus­ga­be schrei­ben. (Natür­lich eig­net sich dazu jedes Pro­gramm, mit dem Inhal­te modu­lar erfasst und zusam­men­ge­setzt wer­den können.)

Konzept

Wer schon ein­mal mit Robo­help oder ähn­li­chen Edi­to­ren zum Erzeu­gen einer Online­hil­fe gear­bei­tet hat, kommt mit der Benut­zung des Pro­gramms zwar schnel­ler zurecht, muss aber dar­auf ach­ten, das Pro­gramm nicht in die Schub­la­de „Soft­ware­do­ku­men­ta­ti­on“ zu wer­fen. Denn Fla­re kann als Grund­la­ge für zahl­rei­che Publi­ka­ti­ons­me­di­en die­nen – ein­schließ­lich Druck.

Mögliche Publikationsprozesse mit Flare
Mög­li­che Publi­ka­ti­ons­pro­zes­se mit Flare

Dazu bie­tet Fla­re Funk­tio­nen, wie sie vor allem in der tech­ni­schen Doku­men­ta­ti­on wich­tig sind. Dort zählt die Kon­sis­tenz in Lay­out, Stil und Auf­bau zu den wich­tigs­ten Zie­len. Daher wer­den in Fla­re (wie in ande­ren HTML-Edi­to­ren auch) alle Topics nach der Erstel­lung in ein Tem­pla­te gela­den, das das spä­te­re Aus­se­hen („Look & Feel“) der Aus­ga­be defi­niert. Das bedeu­tet umge­kehrt auch, dass alle Topics unab­hän­gig von ihrem spä­te­ren Aus­se­hen erfasst wer­den müs­sen. Sie wer­den als ein­fa­che HTML-Datei­en abge­legt und erst bei der Aus­ga­be abhän­gig vom Aus­ga­be­me­di­um mit For­mat­vor­la­gen, Navi­ga­ti­ons­ele­men­ten, Such­funk­tio­nen, Index, Sei­ten­zah­len usw. ver­se­hen. Das Lay­out beim Erfas­sen der Inhal­te dient daher nur  der opti­schen Kon­trol­le, ist aber nicht iden­tisch zur spä­te­ren Aus­ga­be. Die­se spielt näm­lich für die Erfas­sung der Inhal­te kei­ne Rolle.