…sind eher selten, ob in Deutschland oder in den USA. Im neulich erschienen Artikel A Writing Test Run beschreibt Charlotte Huff, wie es in manchen Firmen abläuft:

Initially, Kush Wadhwa simply requested a writing sample when hiring contractors and employees for Global Security Intelligence, the security technologies consulting firm that he founded. [...]

These days Wadhwa selects the topic, sending it at a predetermined time. Applicants are given two hours to research and write an analysis, frequently on a subject outside their expertise. “This is about assimilating the information quickly and presenting it in a cohesive, coherent, compelling and concise fashion,” says Wadhwa, the firm’s founder and managing director.

Die Ergebnisse des Tests werden nach internen, einheitlichen Kriterien geprüft und dementsprechend umgesetzt: Wadhwa estimates that he turns down five applicants for every hire he makes, because their writing can’t withstand the screening scrutiny.

Selbst in den USA eher selten, ist mir in Deutschland nur einmal ein solcher Test begegnet – eine größere deutsche Softwareschmiede unterzieht alle technischen Redakteure einem mehrstufigen Einstiegstest. Dabei werden in einem festgesetzten Zeitrahmen sowohl Englischkenntnisse (Grammatik, Zeichensetzung und Wortschatz) als auch Schreib- und Editierfähigkeiten geprüft. Für kleinere Firmen würde sich dies kaum lohnen – ich war aber immer wieder verblüfft, dass selbst bei Vorgesprächen für Projekte, wo fließend Englisch verlangt wurde, fast nie dieses Englisch auch getestet wurde.

Insgesamt wird wohl immer noch mehr Wert auf Scheine – und Schein – als auf Können gelegt.

Okt 132008
 

Im November finden wieder die Flare-Anwendertage statt, genauer gesagt am 13.11. in Stuttgart (Donnerstag) und am 14.11. in München (Freitag). Hier werde auch ich zu finden sein.

Wer noch nie mit Madcap Flare gearbeitet hat, sollte unbedingt mal reinschauen und danach mit der Test-Version spielen – 30 Tage Zeit, diese sehr flexible und dennoch stabile Software zu testen. Die Inhalte werden im Dateisystem in W3C-konformem XHTML gespeichert, die Formatierungen mittels CSS durchgeführt. Sie können beliebige viele Ziele, Inhaltsverzeichnisse, Textbedingungen auf allen Ebenen anlegen – eine Flexibilität, von der z.B. Robohelp früher nur träumen konnte (und über das neue Robohelp habe ich bisher nichts anderes gehört).

Die Programmversionen von Flare installieren sich übrigens parallel, was bei Upgrades sehr nervenschonend ist – auf meinem Rechner laufen 2.5, 3.1 und 4 friedlich nebeneinander.

 

Über mich rollt gerade eine Arbeitswelle, aber diesen Linktip wollte ich noch loswerden: Why software is the best technical writing field – eine Meinung, der ich voll zustimme.

 

Auf der Seite “Give Away of the Day” gibt es heute was für Online-Hilfe-SchreiberInnenBearbeiterInnen – noch die nächsten 11 Stunden können Sie den CHM-Editor von Gridinsoft kostenlos herunterladen. Er ist gerade mal 1.76 MB groß, und ich bin gespannt auf seine Qualitäten.

Und von Give Away of the Day selbst bin ich fasziniert – eine Webseite, auf der täglich eine andere Firma zu Werbezwecken eine Software verschenkt. Genau das richtige für Jäger und Sammler von Software, wie ich es bin. Warum wurde mir das nicht schon viel früher verlinkt?

 

Ernst
Mit der Norm ISO/IEC 26514:2008 ist eine Richtlinie für Softwaredokumentation herausgekommen, die a) die Inhalte der Dokumentation und b) Strukturen und Formate für Softwaredokumentation aus Sicht des Entwicklers beschreibt. Wäre sicher eine interessante Lektüre, kostet aber den handlichen Preis von 216 CHF.

Spass
Für alle, die ihre Dokumente mal lieber ein wenig geschwungen hätten – Pirates Fonts lassen auch die trockenste Anleitung in heimeligem Federkiel-Stil erscheinen.

 

Zwei Links, die sich wirklich lohnen:

“Digg It” für techn. Dokumentare:
Writer River: Tech Comm Social News

Verzeichnis von Doku-Blogs:
Tech Writer Blog Directory

Sep 162008
 

Die Software SnagIt für Screenshots gehört seit vielen Jahren zu meinen Leib- und Magentools. In meinem neuesten Projekt nutze ich allerdings zum ersten Mal die Multimedia-Fähigkeiten von SnagIt.

Hintergrund
Für mehrere Bereiche einer Firma müssen Software-Schulungsunterlagen verfasst werden. D.h. wir benötigen sowohl die Prozesse als auch Screenshots dazu – was entweder in länglichen Sitzungen und eigenen Tests erarbeitet oder in kleinen 10-Minuten-Filmen festgehalten werden kann. SnagIt befindet sich bereits auf allen Kundenrechnern, musste also nicht neu angeschafft werden.

Vorgehen
Für jeden Bereich der Firma gibt es ein Startup-Meeting, in dem wir zunächst in die Aufgaben und Schnittstellen des Bereichs eingeführt werden, und dann im Gegenzug die Mitarbeiter in die Nutzung von SnagIt und Headset zur Aufnahme von AVI-Filmen einführen. Die Filme werden dann von uns “in Papier” gegossen, wobei die Screenshots direkt den Filmen entnommen werden.

Pro und Contra
Zunächst war es für alle sehr ungewohnt, sich an den Rechner zu setzen und ein Tutorial aufzuzeichnen, bei dem man jeden Schritt erklären soll. Doch durch die relativ einfache Bedienung und die hohe Zeitersparnis für die Mitarbeiter kommt das Vorgehen sehr gut an. Also bisher nur Pro!

Beispiel
Die entstehenden Filme sind nicht unähnlich diesem professional aufgenommenen SnagIt-Tutorial.

Veröffentlicht werden sie nicht, auch wenn der Projektleiter gerne einige “amüsante Auszüge” hätte. Bisher sind die Videos allerdings alle sehr ernsthaft.

Fazit
Ich bin von der hohen Akzeptanz angenehm überrascht. Vermutlich auch ein Verdienst von Youtube und Co., dass inzwischen alle Welt Filme aufnimmt und damit die Hemmschwellen stark gesunken sind. Und wie meinte mein Kollege so schön: “Das fühlt sich so nach High-Tech an.”

Brave new world…

 

Wenn man im deutschen Raum – z.B. auch Google – nach “Lerntypen” sucht, so landet man oft bei der Aufteilung nach auditiven, visuellen, kommunikativen und motorischen Lerntypen. Diese von Frederic Vester begründete Topologie wird zwar laut Wikipedia aufgrund ihrer Oberflächlichkeit und Inkonsistenz [...] von der Lernpsychologie nicht ernst genommen, dennoch ist sie vielerorts verbreitet und wird für Lehransätze verwendet.

Der neulich von Herrn Apholz in einer Xing-Diskussion aufgebrachte Ansatz von Bernice McCarthy dagegen findet sich kaum im deutschsprachigen Raum, dabei empfinde ich ihn als sinnvoller als den von Vester. Auszug aus seinem Posting:


Die Warum-Menschen (Lernstil: Diskussion)
Warum-Menschen lernen am besten, indem sie über die Gründe für etwas diskutieren…

Die Was-Menschen (Lernstil: Vortrag)
Was-Menschen lernen am besten, wenn man ihnen die Information entweder mündlich oder in gedruckter Form vermittelt…

Die Wie-Menschen (Lernstil: Coaching)
Wie-Menschen lernen am besten, indem sie etwas tun. Die Theorie interessiert sie ebensowenig wie Begründungen…

Die Was-wenn Menschen (Lernstil: eigenes Entdecken)
Was-wenn-Menschen lernen am besten, indem sie Dinge selbst entdecken…

Der Dreh-und Angelpunkt ist, dass Sie die Typen in der aufgezählten Reihenfolge auch abholen müssen. Erzählen Sie als erstes dem Warum-Typen, warum die folgenden Informationen hilfreich für ihn sind. Erzählen Sie dann dem Was-Typen, welches die Inhalte sind. Den Wie-Typen holen Sie mit den Übungen ab. Der Was-Wäre-Wenn-Typ hat dann den Spielraum, die Abweichungen und Fehler im System auszutesten.

Was hat das mit Dokumentation zu tun? Dort wird aktuell gerne darauf verwiesen, dass Leute angeblich keine Hintergrundinformationen nutzen, sondern direkt die Anleitung einsetzen. Am liebsten würden viele diese “unnötigen Einleitungen” ganz wegfallen lassen – ich als Warum-Typ schaue aber immer genau auf diese Einleitungen und habe jetzt wenigstens eine gewisse Argumentationshilfe, warum dies kein guter Weg ist. Eine bis zwei Zeilen zum Hintergrund einer Aktion sind nicht so teuer, als dass man sie wegstreichen müsste, und nicht so störend, als dass der anwendungsorientierte Nutzer nicht an ihnen vorbeikäme – sie bringen aber die hinterfragenden Leser mit an Bord.

 

MediawikiVielleicht werde ich irgendwann noch einen ausführlichen Bericht über mein Projekt (ca. 100 Seiten jeweils in Deutsch und Englisch) schreiben, doch heute möchte ich vorweg einige wichtige Gedanken zum Thema “Dokumentation in einem Mediawiki” teilen.

  • Mehrere Bearbeiter – im Prinzip eine tolle Sache, allerdings ist es in Sachen QM und Konsistenz eine große Herausforderung, wenn man von außen die Artikel liefert und der Kunde dann Texte ändert oder hinzufügt, ohne das nochmals zurückzumelden. Und das in zwei Sprachen und bei ggf. nicht sichtbarer Versionierung.
  • “Suchen und ersetzen” ist eine sehr wichtige, hilfreiche Funktion, die man bei einem Wiki von außen nicht erhält. Generell ist die Granulierung der Suche ziemlich oberflächlich.
  • Auch eine Sicherung der Wiki-Quelltexte von außen ist nicht so einfach möglich. Daher rechtzeitig nachfragen, ob der Kunde selbst Backups macht.
  • Die Bearbeitung ist eine Klick-Orgie; für jeden Text den Link im Hauptverzeichnis anklicken, dann “Editieren” anklicken, am Ende “Speichern”. Und das für jede Sprache.
  • Die Druckausgabe ist tendenziell ein echtes Single Sourcing und erlaubt nicht unbedingt die schöne Ausgabensteuerung, wie sie z.B. Madcap Flare mit “Publishing Targets” und bedingten Texten (print, online etcpp.) hat.
  • Schön wäre ein Knopf für Printausgabe on-the-fly, da ein PDF fürs Korrekturlesen hilfreich bis notwendig ist.
  • Man ist leicht von den Entwicklern abhängig ist, wenn diese am Wiki etwas ändern. So wurde in meinem Projekt nach einer Migration die Versionierung abgeschaltet, was zum “Blindflug” bei Korrekturen führte (bzw. zu einem “Backup in Word”).

Mein Fazit: Eigentlich bräuchte man eine gute Schnittstelle zu Word o.ä., und zwar in beide Richtungen – die Tools, die ich vor einigen Monaten geprüft habe, arbeiteten leider immer nur von Word nach Wiki oder benötigten besondere Einstellungen. Einiges wäre leichter gewesen, wenn ich einen direkten Zugriff auf die Wiki-Datenbank gehabt hätte.

Daher würde ich von solchen Dokumentationsprojekten in einem Wiki aktuell eher abraten. Auf jeden Fall aber sollte man das Arbeitsumfeld sehr ausführlich auf die Anforderungen für Dokumentation abklopfen, und ggf. eine extra “Handling”-Gebühr drauflegen – bevor man selbst drauflegt.

Wer weiterlesen möchte – bei Xing gab es neulich ebenfalls eine Diskussion dazu.

 

Ein leidiges Thema, um das ich mich nie wirklich gekümmert habe (dank Quereinstieg und vornehmlich elektronischer Korrektur) – eigentlich gibt es hochoffizielle Korrekturzeichen. Und die sehen etwas anders aus als meine seitlichen Striche wie vom Deutschlehrer oder meine kreativen Schlangenlinien.

Falls es Ihnen auch so geht, so gibts Nachhilfe im CleverPrinting-Newsletter unter Korrekturzeichen nach DIN 16 511. Außer einem Überblick finden Sie dort auch ein kostenfreies PDF zum Herunterladen, in dem die Anwendung dieser Korrekturzeichen ausführlich dargestellt ist.

Ein echtes Schnäppchen für alle, die sich mit diesem Thema befassen wollen (oder müssen).

© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha