Anbei als PDF-Datei ein Handbuch für Redakteure.
Ist schon in Zusammenarbeit mit Björn etwas überarbeitet worden und wird dann ins neue WIKI übernommen, vermutlich in etwas abgeänderter Form, da sind die Cores noch am Tüfteln.
Ich für meinen Teil kann das Teil so gebrauchen, wie es ist, bin aber für Ideen und Vorschläge offen.

Werde es in dieser Form in naher Zukunft noch als HTML-Handbuch umarbeiten.

Viel Spaß beim Benutzen.

Sefrengo-Handbuch für Redakteure (PDF)
Weiter unten im Thread ist nun auch eine OpenOffice-Datei.

Ich bekomme einen Hinweis, das die Datei beschädigt ist ... kann das jemand bestätigen

Datei lässt sich hier problemlos laden/lesen:
Firefox 2.1 / OSX Viewer


Danke Paulinsche:-)

Hallo pulinsche,

erstmal vielen Dank für die Bereitstellung. Wäre es auch möglich, das Ganze in Word zur Verfügung zu stellen? Meiner Meinung wäre es gut, wenn man standardisierte Vorlagen für Sefrengo Dokus bereitstellen würde, inkl. Kopf- und Fußzeile, Inhaltsverzeichnis und sonstigem Schnickschnack.

Gruß
Andy

tolle sache ... muss mich aber teilweise Andy anschliessen - eine Quark/InDesign-datei wär mir allerdings lieber als M$ Word ... würde gerne die anleitung kundenspezifisch kürzen bspw. ... ausserdem sind die screenshots recht schlecht lesbar (zu stark komprimiert!?)

1. Der Thread ist jetzt gepinnt.

2. Wenn schon ein bearbeitbares Format, dann bitte eines welches jeder editieren kann und keinen kostenpflichtige Lizenz dafür braucht. OpenOffice eignet sich da sicherlich besser dafür als Word, Quark Express oder InDesign. Dann kann jeder mitarbeiten und nicht nur jene die über die entsprechenden Lizenzen verfügen.

Hallo,

ok das stimmt sicherlich. Aber in OpenOffice kannst du ja Word öffnen und weiterbearbeiten. Von daher ist es ja kein Problem. Oder irre ich mich da?

mfg mg

Klar kann man Word Dokumente in OpenOffice öffnen, aber ich finde den Weg gleich OpenOffice zu verwenden den bessern. Dann braucht man sich nicht mit irgendwelche Konvertierungen aufhalten. Ich finde die Grundlage der Dokumentation sollte ein quelloffenes Format haben. In welches Format man das letztendlich dann noch ausgibt/exportiert (Word, PDF ...) sei dahingestellt.

Den Gedanken finde ich gut. Werde mal das Word-Doku in OpenOffice umbauen bzw. anpassen. Und dann soll's ja irgendwann mal ins neue Wiki.
Stimmt, die Screenshots sind nicht erste Sahne, musste auf die Schnelle was zusammenbasteln und bin seither nicht dazugekommen, sie zu überarbeiten. Ist in meiner ToDo-List.


Das ging schneller als ich dachte. Hier nun eine gezippte OpenOffice-Datei.
Klicken um den Anhang anzusehen

HI, kannst Du nicht trotzdem auch mal die Wordversion hier einstellen? Das waere sehr nett. Danke!

Hi

Also was ich mir wünsche wäre eine Möglichkeit, meinen Redakteuren modular ein Handbuch zusammenstellen zu können. Ein Modul "An- und abmelden am System", ein Modul "Seiten anlegen und löschen", ein Modul "Seiten bearbeiten", eins fürs soriteren usw.. Weil ich nicht in jedem Projekt dne Redakteuren beispielsweise erlaube, Seiten anzulegen. Wenn ich denen jetzt aber ein Handbuch gebe, wo diese Möglichkeit beschrieben wird...

Machbar wäöre das z.B. wenn man sich auf den DocBook-Standard einigen könnte. Dann könnte jeder seine Module zusammenstellen und am Ende käme ein PDF oder eine HTML-Seite oder ein CHM-File oder was auch immer man will bei raus.

Gruß, Peter

Hi Peter,
das hört sich gut an. Hast du eine Vorstellung, wie man das technisch umsetzt?

Klro
Ich schreib grad ein HowTo.

Gruß, Peter

Hi
Okay, ein richtiges howTo ist es nicht geworden.. das wäre viel zu viel gewsenauf die schnelle.
Ich hab hier ein Paket gepackt, in dem zwei beispieldateien drinstecken, die erleutern wie Inhalte definiert werden. Ich habe alle nötigen Tools zusammengesucht und mir reingepackt. Dann habe ich ein Batchfile geschrieben welches den Make-Prozess steuert. Das ist nicht unbedingt für den DAU geeignet aber es sollte out.of-the-box funktionieren und ist beliebig anpassbar. Also einfach mal Anscheun, für mehr hats erstmal leider nicht gelangt. Vielleicht komme ich ein andermal dazu eine richtige Step-By-Step Anleitung zu schreiben. Ach ja um FOP zu benutzen (also PDFs zu erzeugen) wird Java beötigt.

Gruß, Peter

Noch ein Hinweis: Es ist besser statt "book" als Root-Type "article" zu verwenden. Anstatt "chapter" werden dann nurnoch "section"s verwendet. Vorteil ist, dass Docbook beim PDF-Output nicht so viele Leerseiten einfügt. Im book-Type fängt jedes Kapitel nämlich auf einer rechten Seite an, wesshalb viele leere Seiten eingefügt werden.

Gruß, Peter

Hallo Peter,

du schreibst in der "How To"-Datei:

Nun – ich benutze OSX…

Wäre es zudem nicht sinnvoll, eine Lösung zu suchen/finden, die dann mal ins Wiki eingebaut werden könnte?

Wäre schön, wenn der Text auch noch als ganz normales PDF zur Verfügung stehen würde. Nicht jeder hat die Zeit, sich ausgiebig mit DOCBOOK auseinanderzusetzen (Ich zum Beispiel ).

Hi

@bjoern Meine vorstellung sieht so aus:
Du hasdt eine index.xml-Datei. Da steht im prinzip nur ne liste aller Dateien drin die eingebunden werden (als URLs irgendwo auf der SF-Seite). In dem Paket ist alles drin was du brauchst und neben der index.xml gibts eine make.cmd. die starten und am Ende fällt ein PDF, eine oder mehrere HTML-Seite oder irgendwas anderes raus, welches alle Kapitel binhaltet die man vorher in der index.xml angegeben hat.
Wenn jemand java programmieren kann, könnte man das Problemlos auch in ein Applett basteln. Es gäbe dann auf der SF-Seite eine Seite mit einem Applett in dem man die gewünschten Kapitel und das Zielformat auswählt und dann einfach uf make klickt und am ende spuckt das ding die Zieldatei(en) aus. Wenn ich gelegnheit hab werd ich das mal probieren..

Das wäre übrigens auch der weg für paulinsche. Entweder du suchst xsltproc und xmllint-Binaries für dein OS/X oder du stellst auf Saxon (Java) um. DocBook geht damit auch prima (teilw. sogar besser als mit xsltproc, beispielsweise gehen damit Zeilennummern in Quellcodes; dafür ist es aber auch eeeewig laaaangsam). Natürlich musst du die Aufrufe dann entsprechend anpassen. Eventuell hilft dir auch das weiter: http://sources.redhat.com/ml/docbook-apps/...1/msg00176.html

Gruß, Peter

Hallo!

Mal mein Senf dazu: Docbook ist auf alle Fälle der richtige Weg, da kommt von nach überall, ist noch besser als LaTeX, und das sind die einzigen Universalformate die mir wirklich einfallen!

Tschüss
Tiggr

Naja der anfang ist ja gleich, egal welches Format man benutzt: Wir brauchen Texte und Redaktuere die diese korrigieren und gliedern. Daraus machen wir dann DocBook Sektionen. Ich weiß wie man mit docbook umgeht und mit Java hab ich auch schonmal gearbeitet, ich denke dass ich solch ein Aplett (s.o.) entwerfen kann. Die Textbasis bildet aber auf jeden Fall einen anfang.

Zum wiki.. Aus meiner sicht sollte das Endprodukt ein PDF oder ein Gezipter HTML-Baum sein, welchen ich zur Offline-Benutzung an meine Redakteure gebe. Es ist also nicht zwangsläufig nötig diese Texte im Wiki zu halten. Man kann aus DocBook ziemlich leicht Plaintext machen (s. z.B. hier: http://wiki.blender.org/index.php/Meta/DocBook_to_Wiki) aber ich sehe eigentlich keinen Grund die Texte im DocBook-Format mit denen im wiki aktiv zu verknüpfen.

Gruß, Peter

Och, ich fänd es schon gut, wenn das Handbuch auch im Wiki stände, da halt nur die komplette Version. Ich lad mir selber kaum noch Dokus runter, ich arbeite fast nur noch online!

Dann müssen wir einen Weg finden, entweder die DocBook-Dateien ins Wiki zu syncen oder andersrum. Ich weiß nich was besser is, jedoch ist der Weg Wiki -> DocBook -> Aggregieren -> Fo -> PDF auf jeden fall der umständlichste. Wäre es nicht eine alternative aus den DocBook-Files Chunked-HTML erstellen zu lassen und dieses aus der Wiki zu verlinken?

Gruß, Peter

Klar reicht das! Mit "im Wiki" meine ich nur, "über das Wiki erreichbar"!

@ALL: Die Dokumentation (Handbuch) wird im WIKI gepflegt, so dass jeder der möchte daran schnell und einfach mitarbeiten kann. Es wird eine definierte Struktur (an der wird noch gearbeitet) geben die dann befüllt werden kann. Wenn das ganze dan jemand in den Docbook Standard überführen möchte gerne, das Hauptdrehpunkt wird aber das WIKI sein.

Hi

Neben dem normalen Handbuch, welches selbstverständlich im Wiki verbleibt, sollte ein Redakteurs-Handbuch im PDF-Format existieren. Was ich mir vorstelle habe ich oben schon vorgestellt: Ein Applet oder ein Flash-Plugin oder ein PHP-Script, in welchem ich die Kapitel anhake, welche ich will, und welches mir ein PDF mit all diesen Kapiteln ausgibt. Ich kenne leider keine Wiki2Pdf-Konverter und außer über DocBook kenne ich keinen weg sowas zu erreichen.

Aus meiner sicht sollte die Dokumentation geteilt sein:
1. Ein frei editierbarer User-Bereich, in dem kleinere Sachen beschrieben werden, Module und Plugins dokumenteirt werden usw.
2. Ein geschlossener Bereich, der nur-lesbar für die Welt ist. Hir steht die Dokumentation des Kernsystems, der Hauptfunktionen sowie ein Redakteurshandbuch drin. Dieser Teil wird paralel als DocBook gepflegt (evtl. über DocBook2Wiki Scripte) und ist als PDF herunterladbar.

Es spricht nichts dagegen, dass die Doku im Freien bereich anfängt. Nachdem sie für umfassend genug empfunden wurde und auf inhaltliche und sprachliche richtigkeit geprüft wurde, wird sie in den geschlossenen Bereich verlegt. Das hätte außerdem zur Folge dass wichtige Dokumentationen geprüft und verlässlich vollständig sind, was sie nicht unbedingt sind wenn sie frei zu bearbeiten sind.

Gruß, Peter

Ich hoffe, dass ich jetzt nichts falsches mache, weil ich hier poste:
Können nicht registrierte User das hier auch runterladen? Würde sonst etwas dagegen sprechen, wenn ich es bei mir ins Forum hochlade, damit meine User eine Anleitung für Sefrengo haben?

Ich wollte noch ein Video machen für meine Redakteure und mache sonst davon noch eine öffentliche Version und veröffentliche die dann hier.

log dich doch kurz aus. dann wirst du sehen, dass das pdf auch von gästen heruntergeladen werden kann, da es auf einem externen server liegt. beim open-office-dokument ist dies nicht der fall.


ich denke nicht, dass unter angaben der quelle, etwas dagegen spricht.


gruss andi