Monat: November 2009

Ich war in sage und schreiben einem DITA-Vortrag. Erstens gab es davon gar nicht so viele („Der Hype flaut ab“, wie ein CMS-Hersteller mir bestätigte), zweitens waren die meisten davon eher auf einem Anfängerlevel.

Bei diesem Vortrag war ich fast geneigt nicht hinzugehen, da mir der Titel zuerst zu gewollt witzig vorkam. Ein Blick in den Tagungsband hat mich dann doch überzeugt.

Hier ging es um einen rein semantischen Blick auf DITA – was ich zur Abwechslung mal sehr erfrischend fand. Das ganze hier spielte hier keine Rolle:  „Dann kannst du auch noch das machen – und Maps und Conref… und DITAVAL… das Open Toolkit und Spezialisierung“

DITA – die Informationsarchitektur

Im Blickpunkt stand: die Sicht des Redakteurs. Kann man als Redakteur relativ einfach mit der DITA-DTD arbeiten? Erschließen sich bspw. Elementnamen sofort („Self-documenting structure“), braucht man am Ende keinen Styleguide mehr?

Ralf Steiner und sein Team haben sich DITA angeschaut und ihnen ist Folgendes aufgefallen

• endlos viele Titles (searchtitle, navtitle, title) und keine gute Abgrenzung
• Abgrenzung zwischen abstract und shortdesc unklar
• das Schachteln von versch. Topictypen ist fragwürdig.
  Ich finde es schon fragwürdig, zwei tasks ineinander zu schachteln.
• Unterschied zwischen choices und choicetable ist unklar.
  Für mich ist das eine Layoutsache, manchmal lassen sich Handlungsvarianten besser tabellarisch darstellen. Aber natürlich ist das wieder so eine Sache, weil man ja hier semantisch denken sollte und nicht layoutorientiert. Doch zu 100% lässt sich das nie trennen, wie ich festgestellt habe.
• Was soll das info-Element, wo doch ein Task keine Hintergrundinfo geben soll?
  Nun ja, ganz ohne Hintergrundinfo geht es eben nicht. Ich platziere hier auch nur Hintergrundinfo, die sich auf den spezifischen Schritt bezieht, daher hab ich an dem Element nichts auszusetzen.
• Wozu braucht man steps-unordered?
  Ja, allerdings, wozu? Ob die Steps später nummeriert werden oder als Bullets dargestelt werden, entscheidet sich doch erst beim Generieren.
• Die Concept-Topics sind eine Glaskugel aus der man alles ableiten kann.
  Oh ja! Ich habe bis heute nur eine vage Idee, wie ich Concepts wirklich standardisieren soll.
• Die Benennung der Element ist inkonsistent bzw. nicht sprechend. Man könnte eine dl auch deflist nennen, äquvalent zur linklist.

Ich füge noch hinzu:

• Abgrenzung zwischen context und shortdesc ist schwammig.
• Wozu werden related-links ermöglicht, wenn man doch nur die Wiederverwendung damit erschwert und Relationship tables eigentlich viel besser sind?
• Für Tasten gibt es kein Element! Wie soll den Software-Dokumentation ohne Tasten gehen? Ich habe uicontrol daher eben auch hierfür als Auszeichnungselement definiert.
• Ich kann das p überall benutzen, aber sollte ich auch? Zum Beispiel innerhalb von note, li, shortdesc, context etc.

DITA – ohne Styleguide? Lieber nicht…

Das ist das Fazit von Ralf. Und da kann ich mich voll und ganz anschließen. Ich habe auch zuerst ein Funktionsdesign erarbeitet und dann quasi mit DITA verheiratet. Es sind einfach zu viele Elemente, die nicht eindeutig out-of-the-box zu befüllen sind. Und man hat ja auch bei der Strukturierung immer noch sehr viele Freiheiten, die am Ende dann auch nicht mehr wirklich Standardisierung bedeuten.

Insgesamt ein sehr guter und gut gehaltener Vortrag, der sich mal dem gewidmet hat, auf das es am Ende ankommt: kann man gut damit arbeiten?

PS: Zu viele Bilder der personifizierten DITA sind dann irgendwann auch nicht mehr witzig…

So, ich versuche mal einige Vorträge derselben Themengebiete zusammenzufassen:

Nicoletta Bleiel, ComponentOne – Improving Software Usability with Embedded User Assistance

Ich hatte Nickys Vortrag aus dem letzten Jahr noch gut im Gedächtnis und da auch das Thema passte, bin ich also nichts wie hin.

Hauptthema war Hilfe, die in die Software eingebettet ist und sich nicht außerhalb des Nutzungskontexts befindet. Damit soll gewährlkeistet werden, dass man den Nutzer nicht aus seinem Workflow reißt, indem man ihn dazu zwingt erst einmal die Hilfe zu öffnen, zu suchen, die „richtige“ Frage zu stellen etc. Embedded help wird oftmals gar nicht als „Hilfe“ empfunden.

Nicky zeigte uns hier ihre Umsetzung davon bei der Hilfe von Doc-to-help.

Das Besondere hier war ein bestimmtes Modul, das es dem Redakteur ermöglicht sehr einfach einen Bezug zwischen einem GUI-Element und einem Hilfetext herzustellen – direkt am Interface und nicht über die Verwaltung von irgendwelchen GUI-Element-IDs. Sprich: der Redakteur markiert ein GUI-Element (Button / Menüpunkt etc) , öffnet einen bestimmten Hilfetext in der Applikation und stellt so einen Bezug zwischen den beiden her. Wenn also der Nutzer das entsprechende GUI-Element anklickt o.ä., kommt direkt der dazu passende Hilfetext.

Leider ist das Modul nur in .NET-Applikationen verfügbar. Ich finde diese visuelle Unterstützung für das Mapping äußerst attraktiv (nicht zuletzt, weil ich mich bald mit diesem Thema beschäftigen werde und da wohl eher die Lösung mit GUI-IDs übrig bleiben wird).

Im restlichen Teil des Vortrags hat Nicky ihre Vorgehensweise dargestellt – von der Konzeption bis zur Umsetzung verriet sie Tipps und Tricks, u.a.:

• keine Sackgassen-Topics, d.h. jedes Topics sollte verwandte Topics verlinken, und wenn es nur die Verlinkung von Eltern-Kind-beziehungen ist.
• Trotz kontextbasierter Hilfe bei der Erklärung von Funktionen immer auch erwähnen, wie man eine Funktion findet. Ein Nutzer liest den Hilfetext evtl. nicht im Kontext und weiß gar nicht, wie er die Funktion erreichen kann.

Weitere Details könnt ihr auch inNickys entsprechendem Artikel auf der tcworld nachlesen.

User Assistance 2.0 – Produktinformation als Mittel für Kundenbindung und Kundenmehrwert

Anfangs wurde hier die These aufgestellt, dass Serviceangebote, eben auch umfassende Hilfeangebote, zukünftig immer wichtiger werden. Irgendwann hat jede Produkt-Featuritis ein Ende: man kann einfach nichts mehr Sinnvolles dazubauen. Und dann fängt man eben mit Dienstleistungen an.

Hier hat t3 eine ganzheitliche Informationslösung zusammengestellt, die ich persönlich ziemlich cool fand. Angefangen von embedded help, die sich konkret auf aktuelle Aufgaben bezieht, hin zu einer  dynamischen Hilfe, die mehr prozessorientiert und wissensvertiefend angelegt ist. Am Ende steht ein Wissensportal, das sowohl prozess- und aufgabenorientiert augebaut ist als auch produkt- und themenorientiert. Durch das Portal hat man auch einen Feedbackkanal und gibt den Nutzern auch die Möglichkeit eigene Tipps & Tricks und sogar Dateien austauschen können.

Diese „mehrstufige Vernetzung“ hat mir sehr gut gefallen. Jeder Mensch verhält sich ein bisschen anders bei der Informationssuche und dieses Konzept deckt für mich ein großes Spektrum ab.

Software und Dokumentation – Mit XML zusammenfügen, was zusammengehört

Hier wurde eine sehr spezifische Lösung präsentiert, wie ein Hilfetext in die Software-Oberfläche gelangen kann. Die hier eingebettete Hilfe war jedoch relativ statisch ohne Navigations- oder Suchmöglichkeiten und auch optisch eher „nüchtern“ – das ist sicher noch ausbaufähig. Es wurde vor allem auf den Prozess eingegangen, d.h. wie der Austausch zwischen Redaktionssystem und Software funktioniert.  Ich glaube mich noch zu erinnern, dass ich das ganze etwas frickelig fand – spätestens bei der Excel-Tabelle, die für bestimmte Workarounds nötig ist, war ich etwas entsetzt (aber wer hat sie nicht, die kleinen ekligen Workaorunds, die man lieber nicht weitererzählt….).

Das Endergebnis ist ein rudimentäres Beispiel von embedded help und höchstens dahingehen interessant, wie das Zusammenspiel zwischen Doku und Entwicklung funktionieren kann.

Der diesjährige Dokupreis ging an einen Waffenhersteller.

Das ganze hat ein wenig Wirbel ausgelöst – einerseits bei Friedensaktivisten, andererseits wurde die Frage aufgeworfen, ob hier alles korrekt abgelaufen ist.

Zu letzterem: ich kann es mir nicht wirklich vorstellen, dass hier quasi Bestechung stattgefunden haben soll, aber das ist auch schon alles, was ich dazu sagen kann. Mir kommt es so vor, als ob der Hersteller sich einfach noch einmal rückversichern wollte, dass die Anleitung auch wirklich toll ist, bevor sie eingereicht wird. Und das wäre echt etwas affig…

Mich stört eher der Aspekt, dass eine Waffenanleitung gewonnen hat. Mein erster Gedanke bei der Nachricht, war einfach: „Spinnen die total?“. Auch Prof. Schwermer – ehemals Jurymitglied- hat diese Anleitung wohl verstimmt:

Im März 2009 verlässt Schwermer die Jury, weil er es verwerflich findet, an der Prämierung von Waffenanleitungen mitzuwirken. (Quelle)

Ich habe TR-Fremde aus meinem privaten Umfeld dazu befragt und habe u.a. gehört: „Na, bei Waffen ist doch eine gute Anleitung gerade wichtig.“ / „Das ist auch Teil der Wirtschaft.“

Nach meiner ersten Reaktion hab ich mir auch einige Fragen gestellt:

• Darf man so eine Firma von vorneherein aus so einem Wettbewerb ausschließen?
• Fängt da nicht schon eine Art ungerechte Selektion statt?
• Muss nicht einfach das TR-Handwerk bewertet werden, unabhängig ob es eine Saftpresse oder eine Waffe ist?
• Und wenn wir mit der Moral als Instanz beginnen – wer definiert die Grenzen dazu?

Der Versuch diese Fragen zu beantworten, erklärt mir schon warum diese Anleitung nicht „rausgeworfen“ wurde. Objektiv und fair betrachtet spricht nichts dagegen diese Industrie in so einem Wettbewerb zuzulassen. Alleine: mir bleibt trotzdem ein schaler Nachgeschmack, wenn ich daran denke.

Ich jedenfalls könnte es nicht mit mir vereinbaren hier an einer Bewertung mitzuwirken. Und eigentlich wünsche ich mir – so ganz persönlich-, dass das auch anderen so ginge.