Die Redakteuse

So lange man ohne CMS arbeitet, muss man auf die gute alte Ordnerstruktur zugreifen, um seine Dateien abzulegen. Einerseits bietet DITA einem natürlich einen Haufen toller Attribute mit denen man seine Topics filtern kann, andererseits kann man damit auf Dateisystemebene erst einmal nicht so viel anfangen.

Wieviel Ordnung brauchen wir?
Mit Ordnern neigt man gerne dazu tiefste Verschachtelungen zu bauen, was irgendwann ziemlich nervig zu navigieren sein kann. Außerdem gilt es zu bedenken, dass man bei DITA Topics auch keine scharfen Grenzen ziehen sollte, was ihre Zugehörigkeit anbelangt, denn man möchte sie ja vielleicht auch an verschiedensten Stellen wiederverwenden.

Also sollte man sich gut überlegen, welche Selektionskriterien, sprich: Ordnerebenen man tatsächlich benötigt.

Warum eigentlich nicht alles in einen Ordner schmeißen?
Keine gute Idee! Alle Topics zu 2 verschiedenen Produkten in einem Ordner können folgende Probleme aufwerfen:

• Benennungschaos: Es kann durchaus sein, dass man Topics denselben Titel geben muss, aber der Inhalt verschieden ist, weil es sich um verschiedene Produkte handelt, bei denen das „Ordner bearbeiten“ unterschiedlich funktioniert. Natürlich könnte man dann sagen, dass man den Produktnamen in den Dateinamen des Topics mitaufnimmt, aber daraus resultieren dann ellenlange Dateinamen, die verwirren und schlimmstensfalls irgendwelche technischen Probleme auslösen (Zeichenbegrenzung).
• schlechte Auffindbarkeit:Da haben wir also 5 Produkte und ziemlich wahrscheinlich auch mehrere Autoren dafür. Und dann sind da pro Produkt auch so ca. 100 Topics verfügbar. Auweia! Viel Spaß beim Suchen 🙂

Ich würde sagen, das spricht dafür, schon mal ein Metadatum Produkt zu definieren 🙂

Wichtige Metadaten
Selektionskriterien für die Doku können sein:

• Sprache: Muss als DITA-Attribut vergeben werden, damit das DITA-OT variable Teile innerhalb des Topics entsprechend lokalisiert („Tip“, „Note“, „Short description“). Für einen Ordner spricht, dass je nach Sprachenanzahl die Topicanzahl wieder zu groß wird. Zudem sind die Screenshots je nach Sprache unterschiedlich
• Produkt: Siehe oben. Allerdings muss man bedenken, dass es durchaus sein kann, dass es Topics gibt, die für mehrere Produkt gelten, aber nicht für alle.
• Zielgruppe / Dokumenttyp: Dokumente, die an versch. Zielgruppen gerichtet sind oder auf versch. Dokumenttype, können trotzdem dieselben Dokuteile enthalten. Hier wird es schwierig zu unterscheiden, was man dann in welchen Ordner schmeißen würde.

Lösungsansatz

Auf diesem Level stehen als erstes Unterteilungskriterium das Produkt. Zusätzlich gibt es einen common-Ordner, der Topics enthält, die allgemein überall verwendet werden können / sollen.

Ein Schwachpunkt ist, dass es immer auch Topics geben wird, die für mehrere Produkte gelten, aber nicht für alle. Macht man solche Topics dann trotzdem in _common_ oder in einen der Produktordner? Gute Frage, deren Antwort ich in der Praxis hoffentlich bald beantworten kann

Das nächste ist die Sprache. Da die meisten Autoren in der Regel in nur einer Sprache arbeiten, sollte dieses Kriterium auch möglichst weit oben platziert sein.

Auf der nächsten Ebene folgen direkt die Dateien mit den Maps und dann jeweils ein topic-, ein images-, und ein output-Ordner. Mal sehen, wie sich das bewährt. Zumindest bin ich nicht die einzige mit diesem Ansatz 🙂

(Für das Protokoll: Ganz klar ist es am allerbesten, diese Verwaltungsebene einem CMS zu überlassen, weil man mit echter Metadaten-Vergabe viel flexibler arbeiten kann, als mit Ordnerstrukturen, die einem letztlich abverlangen, ein Topic absolut eindeutig irgendwo zuzuordnen. Aber CMSe sind noch nicht selbstverständlich in der Doku-Welt…)

Auf Tom Johnsons Blog gibt es gerade einen guten Artikel zum Thema „Vom Literaturstudium zur Technischen Redaktion“, den ich so ziemlich unterschreiben kann 🙂

Von der Goethe-Bibliographie zum Software-Handbuch

Wie schon früher erwähnt komme ich ja ursprünglich von der Germanistik und bin absolut überzeugt, dass ein solcher Hintergrund bestens auf die Dokumentation vorbereitet. Und zwar weniger wegen dem Schreiben, sondern viel mehr wegen dem Recherchieren, Analysieren und Strukturieren. Damals waren das für mich die Grundlagen, um eine gute Hausarbeit, einen guten Aufsatz über ein Thema zu schreiben.

Und wie Tom bemerkt, unterscheiden sich Hausarbeit und Handbuch am Ende gar nicht so stark voneinander 😉

Much like a scholarly essay on literature, almost no one will read it, except a select handful of people whom you will never meet.

Kreativ versus standardisiert

Das Schreiben selbst ist für mich in meinem jetzigen Job zwar schon herausfordernd, aber es ist eben auch notwendig standardisiert zu schreiben. Und das ist nicht kreativ! Wer also technischer Redakteur werden will, weil er supergerne schreibt, muss sich darüber im Klaren sein, dass das Schreiben nicht den Hauptteil der Arbeit ausmacht und man dann auch meistens in der Wortwahl und dem Stil sehr eingeschränkt ist. Wer schreiberische Freiheit will, sollte Journalist oder Werber werden. Oder anfangen zu bloggen 😉 Oder nebenbei daheim den langjährigen Roman fertigstellen 😉

Das Kreative liegt für mich in der Art wie ich den Wust an Information, den ich mir zu einem Thema/Produkt aneigne, aufbereite und in eine passende Struktur bringe. Womit wir auch wieder bei den Grundlagen wären, die man aus einem literatur- bzw. sprachwissenschaftlichem Studium mitbringt. Nicht umsonst trifft man in diesem Berufszweig so viele Germanisten, Übersetzer, Romanisten etc.pp.

Das Problem mit der Strukturierung, das ich unlängst hatte, ist tatsächlich nicht so einfach zu lösen. Kurzzusammenfassung: Es ging darum zwei Unterkapitel in einem Oberkapitel zusammenzufassen, das selbst aber eigentlich keinen Inhalt enthält.

title-only topics

Es gibt einerseits den Ansatz  sog. title-only Topics zu benutzen, die lediglich den Titel und eine short description enthalten. Damit kann man dann die gewünschten „leeren“ Oberkapitel erzeugen. Einige argumentieren hier, dass man so eine <shortdesc> auslesen kann, um sie bei Bedarf anzuzeigen, z.B in einer Online-Hilfe. Das ist für mich schon ein smartes Argument, das dem Nutzer hier und da nützen kann. Ein Topichead hat eben keine Beschreibung.

Keine unnötigen Topic-Hülsen!

Jedoch wiegt es für mich schwerer, was für ein Wirrwarr dann auf Erstellerseite entsteht. Ein Topic mit nur einem Titel als Inhalt ist für mich kein Topic, da es kein abgeschlossenes Thema beschreibt o.ä. Punktum! Wenn man mit title-only Topics auch nur anfängt landet ganz man schnell in einem Haufen eigentlich inhaltsleerer Topics und das sollte man meiner Meinung nach tunlichst vermeiden.

Keine Oberkapitel mehr?

Andere Stimmen sagen, dass man einfach davon wegkommen sollte, solche „leeren“ Oberkapitel überhaupt zu benutzen. Aber gerade in klassischen Handbüchern finde ich das irgendwie kaum machbar, ohne dass der Nutzer leidet (wer sich für eine längere Diskussion interessiert, bitte hier lang zur YahooGroup).

Kurzum

Ich habe immer noch keine Lösung. Ich kann aktuell nur hoffen, dass das <topichead>-Verhalten in einer der nächsten OT-Versionen geändert wird. Aktuell fungiert ein <topichead> eben einfach nur als Zwischenüberschrift, jedoch ohne Link, sowohl im PDF als auch im HTML. Oder ich mach’s halt selber 🙁

Hatte ich bei diesem Usability-Vortrag noch gehört, dass User oft Dinge wollen, von denen sie selbst nichts wissen, stolpere ich doch heute glatt über einen uralten Artikel bei Jacob Nielsen: First Rule of Usability? Don’t Listen to Users

Feedback vom User ist wohl so ziemlich für alle Redakteure schwarzes Loch. Was wollen die eigentlich? Wie finden die das, was ich schreibe?

Nur, wie bekommt man dieses Feedback? Eine der Standardantworten ist immer: Umfragen. Wer allerdings schon einmal versucht hat, eine Umfrage aufzusetzen, weiß, dass man sehr viele konzeptionelle Arbeit hineinstecken muss. Gibt man dem User zu viel in der Fragestellung vor oder zu wenig? Versteht er, was nun genau damit gemeint ist? Was ist das Ziel dieser Frage? Lenke ich den User damit schon in das, was ich eigentlich hören will?

Dabei ist dann auch noch wichtig, sich damit zu beschäftigen, wann man das Feedback einholen will.

Finally, you must consider how and when to solicit feedback. Although it might be tempting to simply post a survey online, you’re unlikely to get reliable input (if you get any at all). Users who see the survey and fill it out before they’ve used the site will offer irrelevant answers. Users who see the survey after they’ve used the site will most likely leave without answering the questions.

Bei Hilfetexten ist es für mich klar, dass ich nur Feedback einholen möchte nachdem ein User die Hilfe genutzt hat. Das Spannende dabei ist, wie man den User dann noch abholen kann, da die meisten ja recht fix von der Hilfe verschwinden, wenn sie ihnen was gebracht hat und die meisten auch nicht sehr motiviert sind Feedback zu geben.

Ich habe einen Haufen Vorträge gesehen und nachdem ich nun meine Highlights schon beschrieben habe, kommen wir zu der Kategorie „Ferner liefen…“. Hier findet sich sowohl Gutes als auch Schlechtes 😉

Adobe Air, eine neue Basis für Onlinehilfen?

Der erste Vortrag meines Tagungsprogramms lieferte einen gute Überblick über das was Air ist, was es kann und wozu es gut ist. Die Folien gibt es online.

Content Reuse – Zusammenspiel von Software-Entwicklung und Technischer Dokumentation

Definitiv eine der größten Enttäuschungen (neben der Tatsache, dass ich in manche Workshops nicht mehr reinkam). Es ging hier um ein Beispiel in dem für die Dokumentation die strukturierten Daten, die schon bei den Entwicklern vorkamen, wiederverwendet werden konnten. In diesem Fall handelte es sich um 15.000 Fehlermeldungen, deren Kodierung und Text über XML dann an die Doku weitergereicht wurde, auf dass diese die entsprechenden Erklärungen schreibt. Klar, das ist Reuse, aber definitiv eine Variante, die in der freien Wildbahn echt nicht oft auftaucht. Und in der Vortragsbeschreibung kam das auch ganz klar nicht raus. Da haben sehr viele etwas anderes erwartet 🙁

Von 0 auf XML in 80 Tagen: Einführung eines XML Redaktionssystems auf Basis von Funktionsdesign

Hier hat der Kaffeemaschinenhersteller Jura vorgestellt, wie die Doku sich bei ihnen entwickelt hat. Irgendwann wurde ein Cut gemacht bei dem entschlossen wurde, dass nicht mehr Entwickler die Doku schreiben *lach*. Es wurde ein Funktionsdesign entwickelt, das dann auf alle neuen Anleitungen angewandt wurde. Irgendwann war alles an Doku standardisiert und dann kam man auf die Idee ein CMS einzusetzen. Und nachdem man sich für ein CMS entschieden hatte, dauerte es tatsächlich nur 80 Tage bis es einsatzbereit und mit bisherigem Content angefüllt war. Herrlich! Genauso sollte es laufen. Naja, bis auf die Tatsache InDesign einzusetzen… Aber ansonsten bin ich neidisch 🙂

Wissensmanagement bei dezentraler Dokumentationserstellung für multiple Märkte, Marken und Sprachen

Die Essenz dieses Vortrags war, dass jedes Wissen, dass in einem Prozess wichtig ist, auch in diesem Prozess verankert sein muss. Ein durchaus interessanter Ansatz. Sehr schön fand ich den Begriff „Denk-dran-Lösungen“: er wurde hier für alle Informationsinseln verwendet, die sich mit der Zeit in einem Unternehmen entwickeln. Ein bisschen schade fand ich, dass der Redner Wikis komplett als Lösungswegs ausgeschlossen hat, weil sie zu „unstrukturiert“ wären und ja auch bei der Wikipedia nur 1% der Nutzer auch aktiv wären, was bei einer Firma dann auch nichts bringen würde. Aus eigener Erfahrung kann ich sagen, dass die Wikipedia nicht mit einem Wiki in einem Firmenumfeld vergleichbar ist. Letzten Endes lebt jedes Wissensmanagementsystem davon es gut an die Mitarbeiter zu vermarkten, sei es ein schnödes Wiki oder irgendetwas Kommerzielles.

An overview of localization in Latin America

Der Titel sagt genau worum es ging, aber noch treffender wäre der Begriff „localization industry“ gewesen. Ich hatte mir erhofft zu hören, was es für Strategien oder Tipps gibt, wenn man für Lateinamerika lokalisieren muss. Aber es ging wirklich nur um die Lokalisierungsindustrie dort. Das einzig Interessante war hier die Anmerkung, dass man sich als Unternehmen durchaus mal überlegen solle, ob es nicht effizienter und qualititatv besser wäre, die Lokalisierung in die jeweiligen Länder zu geben. Mir kam es alles in allem mehr wie eine Marketingveranstaltung für die Lok-Industrie da drüben vor.

Writing for an International Audience

Gute Zusammenfassung dazu wie schlechte Doku und auch Gedankenlosigkeit die Übersetzungskosten in die Höhe treiben können und am Ende vielleicht doch nur Müll rauskommt, weil eben Müll reinkam. Schönstes Rechenbeispiel: wie die Änderung eines Field Labels am Ende 5500$ kostet 😀

Zielgruppen im Fokus – Zielgruppendefinition in der Technischen Dokumentation

Hm ja, das Übliche eigentlich:

• site visits
• workshops
• Fragebögen
• Communities
• Usability-Tests
• Auswertung der Definitionen von Marketing und Vertrieb

Interessant war der Ansatz, dass man festlegen sollte, welche Zielgruppe strategisch wichtig für das Produkt ist (sowas macht dann wahrscheinlich das produktmanagement) und dann die Redaktion deren Kommunikationsbedürfnisse ermittelt. Einfaches Beispiel: ein Flugzeugtechniker braucht für die tägliche Arbeit kein umfangreiches Handbuch, sondern vielleicht eher eine Loseblatt-Sammlung mit Checklisten.

Das Deutsch der Technischen Redaktion

Bei einer Kaffeepause erzählte mir eine Kommilitonin, dass Prof. Baumert aus Hannover ganz tolle Vorlesungen halten soll. Und so bin ich ganz spontan hineingelaufen – der Vortragsraum war schon 10min vor Beginn randvoll. Ich war hin und weg: er legte los mit den philosophischen Grundlagen, die letzten Endes unser alle Muthig+Schäflein-Armbruster zum Designen des Funktionsdesigns verleiteten. Supertoll vorgetragen und wirklich interessant, weil ich bisher eigentlich immer nur wusste, dass das Funktionsdesign aus der Sprechakttheorie hervorgeht. Aber mehr auch nicht.

Leider musste ich während des Vortrags wg. eines Termins raus. Sehr schade!

Fazit

Ich war teilweise doch sehr enttäuscht darüber, wie sehr manche Vortragsbeschreibungen von der Realität abwichen und man dann in einem Vortrag nach 5min merken musste, dass man wohl in die Falle getappt war.

Leider sind auch einige Vorträge ausgefallen, die ich sehr gern gehört hätte.

Alles in allem fand ich es aber trotzdem sehr gelungen. Ich hatte einige schöne Highlights, habe alte und neue Bekannte getroffen und nächstes Jahr werde ich wohl hoffenltich auch dazu kommen mehr von Wiesbaden zu sehen als die Messe und das Hotel 😉