Im drit­ten Teil geht es um das Publi­zie­ren und Ver­sio­nie­ren: Wer darf wel­che Infor­ma­tio­nen ver­öf­fent­li­chen, in wel­cher Form und wohin? Und wie „friert“ man einen Stand ein – und taut ihn wie­der auf?

Gleich vor­weg: Doku­men­te in Fla­re (und in Cen­tral) wer­den nicht publi­ziert, son­dern erst „gebaut“ und dann ver­teilt. Das ist tech­nisch kor­rek­ter, denn statt des Dru­ckens wer­den die Doku­men­te in Cen­tral wie auch in Fla­re „on the fly“ aus den dafür frei­ge­ge­be­nen Topics zusam­men­ge­setzt und mit Hil­fe der CSS formatiert.

Das bedeu­tet aber auch, dass alle Ein­stel­lun­gen zu For­ma­ten, Lay­out, Aus­ga­be­me­di­en, etc. bereits vor­han­den sein müs­sen, bevor in Cen­tral die Doku­men­ten­pro­duk­ti­on anlau­fen kann. Die­se Ein­stel­lun­gen nimmt der Redak­teur in Fla­re vor und gleicht sie als „Tar­gets“ mit Cen­tral ab.

Bauen“

central-build
Das „Build manage­ment“ in Cen­tral. Hier wird die Pro­duk­ti­on ange­sto­ßen (und protokolliert).

 

Ein Benut­zer – sofern er über die ent­spre­chen­den Berech­ti­gun­gen ver­fügt – wählt das Pro­jekt (also die Doku­men­ta­ti­on) aus, die erstellt wer­den soll, und wählt dann das gewünsch­te Target.

Cen­tral erstellt dar­auf­hin auf dem Ser­ver die Doku­men­ta­ti­on. Das ist inso­fern cle­ver, als dass damit der Pro­duk­ti­ons­pro­zess kei­ne eige­ne Soft­ware mehr ver­langt. Jeder Benut­zer mit der ent­spre­chen­den Berech­ti­gung (also auch ein Ver­triebs­lei­ter in Sin­ga­pur, der sonst nichts mit der Doku­men­ta­ti­on zu tun hat), kann sich bei­spiels­wei­se eine PDF des aktu­el­len Sta­tus erstel­len las­sen. Sogar zeitgesteuert.

Die Doku­men­te ste­hen nach der Erstel­lung ent­we­der zum Down­load zur Ver­fü­gung oder kön­nen in einen Ziel­ord­ner („Desti­na­ti­on“) kopiert wer­den. Die­ses Ziel wird in Fla­re defi­niert und kann bei­spiels­wei­se der Inter­net­ser­ver des Unter­neh­mens sein. Das bedeu­tet, dass der Ver­triebs­lei­ter zu jeder Zeit die Doku­men­ta­ti­on auf dem Ser­ver des Unter­neh­mens aktua­li­sie­ren kann – sei es nun eine kom­plet­te HTML-Doku­men­ta­ti­on oder ein fer­tig gelay­ou­te­tes PDF.

Versionieren fertiger Dokumente

central-build-2
Meh­re­re Ver­sio­nen aufheben

Nor­ma­ler­wei­se über­schreibt der Ser­ver bei jedem Erstel­lungs­pro­zess die bereits vor­han­de­nen Datei­en. Das spart Platz und soll ver­hin­dern, dass man vor lau­ter Doku­men­ten die Über­sicht ver­liert – vor allem, wenn sie wäh­rend des Kor­rek­tur­pro­zes­ses erstellt wer­den und noch kei­ne fina­len Fas­sun­gen sind.

central-build-liveUm sich aber wich­ti­ge Zwi­schen- oder End­fas­sun­gen auf­zu­be­wah­ren, setzt man in Cen­tral ein Häk­chen („Keep“) vor das Dokument.

Damit wird es auf­be­wahrt und kann gege­be­nen­falls live geschal­tet wer­den, also auf einen Ser­ver publi­ziert, der öffent­lich ver­füg­bar ist. Soll­te der Ver­triebs­lei­ter bei­spiels­wei­se fest­stel­len, dass eine neu hin­zu­ge­kom­me­ne Infor­ma­ti­on im aktu­el­len Doku­ment feh­ler­haft ist, lässt sich so ohne erneu­ten Upload und Down­load das Doku­ment auf dem Unter­neh­mens­ser­ver aus­tau­schen: Dazu muss nur die noch auf­be­wahr­te Fas­sung live geschal­tet wer­den. Dann wan­dert die feh­ler­haf­te Fas­sung zurück in „Auf­be­wah­ren“ und kann gelöscht werden.

Immer Bescheid wissen

central-notificationsIn einem Sze­na­rio, bei dem so bei­spiels­wei­se der Ver­triebs­lei­ter in Sin­ga­pur merkt, dass ein Feh­ler in der Über­set­zung ist, zieht er die feh­ler­haf­te Fas­sung aus dem Ver­kehr und tauscht sie gegen eine kor­rek­te, aber älte­re Fas­sung aus. Nach der Kor­rek­tur wird die neue Fas­sung dann wie­der online gestellt und die älte­re Fas­sung bleibt im Archiv.

Der Redak­teur (und alle ande­ren Betei­lig­ten) bekom­men dazu eine Mel­dung per E-Mail oder im Nachrichtenfenster.

Oder bei­des.

Und noch bes­ser: Dazu muss der Redak­teur noch nicht ein­mal aufstehen.