Monat: Juni 2009

Neben dem Single-Source-Publishing (aus einer Quelle baue unterschiedliche Dokumente, z.B. Admin-Handbuch und User-Quickstart) ist auch Cross-Media-Publishing ein wichtiges Schlagwort in der heutigen TR (aus einem Dokument baue verschiedene Outputs, z.B. PDF, HTML und CHM).  Beide Prinzipien finden sich auch in DITA wieder.

Maps in DITA wiederverwenden

Man kann in DITA ganze Maps wiederverwenden. Hierzu muss man im topicref einfach das Attribut format auf ditamap setzen:

<topicref scope=“local“ format=“ditamap“ navtitle=“E-Mail“ href=“../E-Mail/E-Mail.ditamap“/>

Die Topics dieser Map und ihre Hierarchie werden einfach in die Hierarchie der referenzierenden Map eingebaut, d.h. im Output kann man nicht mehr sagen, was auch welcher Map kam. Dies ist überaus praktisch, um beispielsweise nicht nur Wiederverwendung auf Topicebene zu machen, sondern eben auch auf bspw. Kapitelebene.

Cross-Media-Publishing – wie ist die Realität?

Die Crux beim Cross-Media-Publishing ist: das was im Print funktioniert, muss noch lange nicht online funktionieren. Und umgekehrt natürlich.

Hilfemedien unterscheiden sich durch mehr als das Dateiformat. In Online-Hilfen muss man z.B. viel mehr verlinken.

Ich habe nun gerade eine Map angelegt, die sehr stark auf den HTML-Output ausgelegt ist. Ich will dort beispielsweise kein komplettes Inhaltsverzeichnis, weil mir das im Onlineformat zu viel ist. Ein Inhaltsverzeichnis mit 70 Topics ist einfach zuviel (und ein hübsches JavaScript-Aufklapp-Inhaltsverzeichnis ist hier nicht angebracht). Daher habe ich sehr viele Topics auf „toc=no“ gesetzt. Die Beziehungen werden für den Nutzer über die hierarchischen Links und related Links dann schon abgedeckt.

Nun ist die Map fertig und mir wird klar, dass sie so nicht wiederverwendbar ist.  Es ist eine reine HTML-Map und wenn ich ein PDF mit einer ähnlichen Struktur bauen möchte, werde ich eine neue Map bauen müssen, was aber zu Redundanz führt (Böse, böse! BÖSE!). Oder ich ändere je nach Output jedes Mal die toc-Attribute (Blöd, blöd! BLÖD!).

Fazit?

Ich muss schauen, wie sich das entwickelt. Aktuell steht es nicht in Aussicht, dass ich ein PDF benötige, aber in der Informationsarchitektur muss ja ein wenig vorausschauen und ich sehe schon förmlich, wie die PDF-Wolke sich am Himmel zusammenbraut (oh, nicht das falsche Vorstellungen aufkommen: ich sehe meine Auftraggeber nicht als Götter an 😉 ). Leider hab ich bisher nur Schilderungen gefunden, die meine beiden Optionen bestätigen.

Irgendwie muss ich diesen Grat zwischen Cross-Media-Publishing und trotzdem „passend für das tatsächliche Medium“ noch finden. Hmmm.

Mich hat der Hype um Microsofts neue Suchmaschine Bing relativ kalt gelassen, weil…naja, seien wir mal ehrlich… wann hat einen zuletzt was aus diesem Softwarehause schon groß umgeworfen?

Nun mehren sich die Meldungen, dass der Marktanteil steigt und ich musste nun doch mal kurz reinschnuppern. „Und es hat Bing gemacht!“ weiterlesen

Mit den so genannten Relationship tables (reltable) kann man die Beziehungen zwischen Topics definieren. Hiermit implementiert man Verlinkungen, die nicht durch die Hierarchie (oder die anderen collection-types) festgelegt ist. „Links in DITA #3 – Relationship tables“ weiterlesen

Hach, auch ein Global Player wie Hasi und Mausi kann ins Fettnäpfchen treten. Da widme ich mich über die Feiertage dem angenehmen Online-Shopping, als mir die neue Kampagne ins Auge springt. Allerdings weniger wegen der Shirts:

Eingabe? Wieso Eingabe? Was soll ich denn da eingeben? Moment, dem erfahrenen Software-Dokumentar fällt sofort die Eingabe-Taste ein. Und wie heißt die in Englisch? Genau: Enter.

Ne, ne, liebe Leute, auch die 100%-Matches in einem TMS sollte man überprüfen 🙂

Hier die UK-Variante, die etwas mehr Sinn macht!

Oder nennen wir ihn auch „conditional text“. Gemeint ist das Prinzip Texte mit einem Attributwert zu versehen und beim Generieren festzulegen, ob Elemente mit diesem Attribut inkludiert oder exkludiert werden.

Eigentlich eine feine Sache, um Produktvarianten zu handhaben (So geht es in XMetal).

Praxisbeispiel

Nun wende ich das ganze wirklich zum ersten Mal an und zwar hier:

Das Feature ist eigentlich dasselbe, nur dass es in Produkt A als „Copyright-Zeile“ auftaucht und automatisch ein ©-Zeichen eingefügt wird. Während in Produkt A1 das Feature „Fußzeile“ heißt und nichts automatisch eingefügt wird.

Dem Featurenamen hab ich daher in ph-Tags gepackt und sie entsprechend mit product_a oder product_a1 attributiert. Sieht eigentlich gut aus und am Ende kommt auch das raus, was ich will!

Haken an der Sache?

In obigemFall war das ganze einfach, weil die Features denselben Genus aufweisen und beide im Singular sind. Angenommen „die Fußzeile“ hieße eigentlich „der Fußmarker“ – da müsste ich beispielsweise Artikel oder Pronomina in den ph-Tag mitaufnehmen. Das obige Beispiel sähe dann so aus:

Irgendwie hab ich das noch unbegründete Gefühl, dass genau solche Fälle beim Übersetzen Ärger machen können, aber noch hab ich keine Beispiele dazu gefunden…