Die Redakteuse

Kategorie: Nice to know

  • Konferenz für Informationsarchitektur 2012 – Rückblick

    Ich interessiere mich schon lange für Informationsarchitektur – wie baut man Informationen so auf, wie stellt man sie so dar, dass sie möglichst einfach gefunden werden? Das klingt auch erst einmal einfach nach der Beschreibung eines technischen Redakteurs 😉 Eine gute Beschreibung einer Konzepter/Informationsarchitekten-Stelle gibt es bei designerdock.

    Mir wurde die Konferenz für Informationsarchitektur schon vor längerer Zeit empfohlen, und so hab ich nicht lange gezögert als ich sah, dass das Schwerpunktthema für 2012 „Content Strategy“ heißen sollte 🙂

    Da war ich also mit einem unhippen Thema „Doku im Umfeld der Content Strategy“ unter all den Konzeptern, denen in der Regel dieser wohlbekannte, sofort latent gelangweilte Ausdruck über das Gesicht huschte, wenn ich das Wort „Dokumentation“ erwähnte und den wohl jeder TRler zur Genüge kennt 😉

    Content-Strategy nur als Werkzeug im Pre-Sales
    In den Vorträgen ging es in der Regel vor allem um einen Aspekt in der Content Strategy: die Pre-Sales-Phase. Wie konvertiere ich einen Website-Besucher zu einem zahlenden Kunden? Das war’s. Das lässt sich vielleicht damit erklären, dass hier relativ viele Agenturen vertreten waren, die in der Regel mit einem speziellen Auftrag betraut sind und die Firmen nicht unbedingt langfristig begleiten. Und wie mir bestätigt wurde, sind die Kunden am Ende auch nur darauf fokussiert auf Ihren Webseiten die Konversionsrate zu erhöhen.

    Das Bewusstsein für ein allumfassendes Produkterlebnis bei dem man nicht nur den Neukunden becirct, sondern auch den Bestandskunden hegt und pflegt, scheint sowohl in Firmen als auch in Agenturen noch nicht so stark zu sein. Die After-Sales-Phase spielt meiner Meinung nach eine große Rolle, um eine Marke zu stärken, und Dokumentation bzw. Support-Material gehört hier zum zentralen Content. Aus Marketing-Sicht ist dieser Content halt so wahnsinnig „unsexy“, dass er gerne ausgespart wird, anstatt dass man mal darüber nachdenkt, dass JEDER Content letztendlich Marketing ist und wie man diesen Content verbessern kann. Da sehe ich noch großes Potential!

    IAK12-Schnipsel

     Know thyself (Margot Bloomstein)

    Diese Aussage fasst gut zusammen, was ich desöfteren hören konnte: Am Anfang von allem steht die Kernbotschaft, die man als Unternehmen vermitteln möchte. Sie ist die Grundlage für jedwede Strategie und Kommunikation. In einem Vortrag zur Kommunikationsstrategie vom Taschenhersteller Freitag konnte man sehr schön sehen, wie die Unternehmenskommunikation von dem speziellen Freitag-Geist durchdrungen ist und damit eine Einheit nach außen bildet. Wenn man nicht weiß, was man vermitteln soll, kann das Wie fast nur schief gehen.

    Information gestalten. Nicht Gestaltung mit Informationen füllen (Fabian Lang)

    In vielen Firmen ist es Gang und Gäbe, das erst designt wird und dann am Ende der Texter noch seinen Text „reinhämmert“. Wenn dann beispielsweise eine Überschrift der 2. Ebene konzipiert wird, aber der Texter da eigentlich nichts Sinnvolles reinzuschreiben hat, ist das sein Problem. In der Regel wird er dann irgendwas reinschreiben, auch wenn man diesen Text eigentlich nicht braucht. Deswegen ist es wichtig, dass auch die Texter in die Konzeption miteinbezogen werden, so dass sie ihr Feedback und ihren Text frühzeitig miteinbringen können. Sonst passiert beim Aufeinandertreffen von Konzept und Content eben das hier  (ein Schnappschuss aus Fabians Vortrag):

    Change-Management

    Content betrifft oft sehr viele verschiedene Mitarbeiter in einem Unternehmen, und jeder folgt seinem eigenen Weg. Für eine erfolgreiche Content-Strategy ist es aber erforderlich, dass sich alle auf einen Vision einigen und an einem Strang ziehen. Wie schafft man das? Laut Stefan Freimark:

    • Schwächen aufzeigen und den Handlungsbedarf verdeutlichen
    • Alle Betroffenen einbeziehen: mit regelmäßigen Meetings, Newslettern, alle an einen Tisch setzen

    Fazit

    Es war durchaus interessant, das Thema „Content-Strategy“ mal aus der Konzepter-Perspektive zu sehen. Rückblickend hätte ich   gerne einen Vortrag auf der Konferenz gehalten, um mal die TR-Perspektive an den Konzepter zu bringen. Der Blick auf einen komplette Produkterfahrung wird nämlich langfristig noch sehr wichtig werden, wie ich denke. Und spätestens als in einem Vortrag plötzlich das Wort „DITA“ an der Wand stand (wobei ich noch nicht genau verstanden habe, warum…), war ich mir sicher, dass hier auf jeden Fall irgendwann eine Annäherung stattfinden wird.

    Ein bisschen gestört hat mich, dass es den Referenten mit einer Vortragszeit von nur 35 Minuten oft nicht möglich war, richtig in die Tiefe zu gehen. Ich fände 45 Minuten angemessener und 15 Minuten Pause langen eigentlich auch vollkommen 🙂

    Ansonsten: Die Location in der Zeche Zollverein Essen war toll – in den Pause konnte man mal kurz durch das Museum schlendern und abschalten. Die Idee jedem Teilnehmer Methodenkarten zu einem Thema zu geben, damit man diese untereinander tauscht, war auch klasse, denn man hatte einen guten Anknüpfungspunkt für Gespräche.

    Methodenkarten zum Thema "Content Strategy" auf der iak12

     

     

     

  • tekom Frühjahrstagung 2012 – Dies und das

    CMS-Coaching von Nebil Messaoudi

    Nebil teilte in diesem Kurztutorial seine bisherigen Erfahrungen mit CMS-Einführungen mit uns. Wenn man selbst schon einmal ein CMS eingeführt hat, kommt einem einiges bekannt -nur zu bekannt-  vor. Manch einer konnte sich auf die Schulter klopfen und sagen: „Ja, das haben wir zum Glück von Anfang an beachtet“, aber so richtig rund scheint es am Ende wohl nirgends zu laufen, wenn es um CMSe geht:

    (Dieser Tweet wurde dann auch von einigen Entwicklern aus meiner Timeline retweetet 😉 )

    Was laut Nebil häufig vergessen wird, ist die konzeptionelle Vorarbeit, also erst einmal die Umstellung auf standardisierte Dokumentationserstellung mit Leitfäden, Standardisierungskonzept, Terminologie etc. Letzten Endes ist ein CMS nur eine Software, das Prozesse unterstützt – die Prozesse muss man sich aber immer noch selbst ausdenken. Gern verdrängt wird von TR-Abteilungschefs auch die Tatsache, dass es mit dem CMS-Kauf nicht getan ist: jetzt fängt nämlich der Spaß mit der Datenmigration oder -neuerfassung und kontinuierlicher Weiterentwicklung an. Und hier sollte von Anfang an schon genug Budget miteingeplant werden. Gerade wenn man fachfremde Doku-Chefs hat, müssen die Redakteure hier sehr viel Überzeugungsarbeit reinstecken. Denn da hört man schon mal gerne den Spruch: „Aber ihr habt doch da jetzt so ein tolles Redaktionssystem. Das kann doch alles“ – und dem muss man von Anfang an entgegenwirken. Denn leider kann das System nie direkt alles, was man braucht.

    Ein weiteres Thema war die Frage: Wie erleichtert man Redakteuren, die bisher vor allem mit DTP gearbeitet haben den Umstieg auf XML? Gerade bei diesem Thema hat sich eine längere Diskussion entsponnen. Hier einfach mal eine Sammlung der Publikumsstimmen:

    • „Als Redakteur muss man ja nicht unbedingt programmieren können, deswegen sollte man XML als Auszeichnungssprache verkaufen und das Wort ‚Programmierung‘ am besten gar nicht erwähnen. Nur gegenüber der Geschäftsleitung sollte man XML als möglichst kompliziert darstellen – das heißt Budget!“
    • Quereinsteiger-Redakteure müssen richtig mit eingebunden werden. Es hilft nichts, wenn nur der eingekaufte Freelancer das CMS bedienen kann oder nur der Kollege, der TR studiert hat.

    Weitere Empfehlungen waren:

    • das CMS mit echten Daten zu befüllen, auch wenn es um Tests geht, weil man so das genaueste Bild bekommt, wenn man testet
    • externe CMS-Coaches zu beauftragen, um sicherzustellen, dass man auf dem richtigen Weg ist.

    JavaScript-Frameworks von Edgar Hellfritsch

    Ich habe den Mobil-Hype bisher so ein bisschen aus der Ferne verfolgt. Bisher hatte sich einfach keine Gelegenheit ergeben in diesem Bereich zu arbeiten und jetzt wollte ich es mal genau wissen.

    Edgars Vortrag hat einen sehr guten Überblick darüber verschafft, wie das aktuell so läuft bei der Entwicklung für mobile Endgeräte und im Endeffekt gibt es drei Wege:

    • Native Entwicklung: Man programmiert eine richtige App, die man sich aus dem jeweiligen Store herunterladen muss. Leider ist das im Fall von Apple richtig kompliziert (Anmeldung des Entwickler-Accounts, Anmeldung der App) und dann muss man auch noch eine neue Programmiersprache lernen (Objective C). Hinzu kommt, dass für jede Plattform (iOS, Android) eine eigene App entwickeln muss, was auf die Dauer ziemlich suboptimal ist.
    • Web-Entwicklung: Man programmiert quasi eine Webseite, die ganz normal auf einem Webserver abgelegt wird und dann über den Browser der mobilen Endgeräte abgerufen wird. Das hat den Vorteil, dass man auf jeden Fall plattformunabhängig arbeitet und eben nicht redundant. Man kann alles selbst per CSS gestalten, hat aber keinen Zugriff auf Gerätefunktionen, wie z.B. die Kamera.
    • JavaScript-Frameworks als Mittelding: Ein Framework ist eine Art Gerüst, oder auch Bibliothek, die verschiedene häufig benötigte Funktionen beinhaltet, die man direkt benutzen kann, ohne sie erst einmal mühsam zusammenprogrammieren zu müssen.  JavaScript-Frameworks für Mobiles wie jQuery Mobile oder Sencha Touch bringen also z.B. einen Standard für GUI-Elemente mit, so dass man sich nicht selbst dauernd mit dem CSS-Styling befassen muss. Je nachdem kann man auch auf die Geräteschnittstellen zugreifen.

    Ich hab jetzt auf jeden Fall Lust bekommen mehr in dieser Welt herumzuspielen!

     

  • Gelesen: DITA Best Practices

    Vor kurzem ist das Buch DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA von Laura Bellamy, Michelle Carey und Jenifer Schlotfeldt erschienen. Bei dem Wort „Architecting“ im Untertitel bin ich hellhörig geworden, denn die meisten Bücher, die derzeit auf dem Markt sind beschäftigen sich entweder stark mit den Basics (Warum soll ich DITA verwenden?) oder mit der Autorensicht (Wie schreibe ich in DITA?). Das ist zwar nicht verkehrt, aber viele weitere Infos musste man sich bisher dennoch eher im Netz zusammensuchen.

    Part I: Writing in DITA

    Dies ist der erste Teil des Buchs und handelt wie der Titel schon sagt alle Basics rund um das Schreiben mit DITA ab. Für jeden Topictyp gibt es ein einzelnes Kapitel in welchem anhand von konkreten Beispielen die wichtigsten Elemente gezeigt werden und eben auch Tipps, wie sie am besten zu nutzen sind. Manche Dinge sind ja z.B. aus der DITA-Referenz nicht unbedingt ersichtlich, wie z.B. der Unterschied zwischen choices und choicetable. Die Autorinnen benennen konkret in welchem Fall welches Element geeignet ist.

    Und einer der wichtigsten Sätze in diesem Zusammenhang ist vielleicht dieser:

    Avoid using  […] elements simply because they’re available.

    DITA bietet wirklich eine riesige Fülle an Elementen, aber man muss sie gar nicht immer alle verwenden.

    Ein besonderes Augenmerk legen die Autorinnen auf die shortdesc (short description) und so bekommt dieses unscheinbare Element ein eigenes Kapitel. Der Grund dafür ist, dass der Inhalt dieses Elements das erste ist, was der Nutzer zu sehen bekommt. Dieser Text erscheint in den Suchergebnissen oder Linkübersichten und  hilft dem Nutzer so zu entscheiden, wohin er navigieren soll. Das Kapitel enthält viele nützliche Negativ-und Positivbeispiele für short descriptions

    Part II:  Architecting Content

    Dieser Teil hat mich schlichtweg begeistert und hätte mir vor 4 Jahren ziemlich viel Recherchearbeit abgenommen. Hier verlässt man die reine Autorenschiene von Teil 1 und befasst sich wirklich mit dem Eingemachten von DITA. Es gibt eine sehr ausführliches Kapitel über Maps; wie man diese am besten aufbaut und welche Möglichkeiten man generell in Maps hat. Weiter geht es mit den verschiedenen Arten des Verlinkens in DITA, also Related links, relationship tables etc.

    Und dann kommen natürlich auch die Themen Metadaten, conditonal processing und Wiederverwendung dran.

    Fazit

    Zuerst muss ich noch erwähnen, dass das Buch noch einen 3. Teil namens „Converting and Editing“ enthält, den ich allerdings noch nicht gelesen haben.

    Jedoch finde ich die ersten beiden Teile des Buchs schon so gelungen, dass der Teil nun auch nicht so schlecht sein wird 😉 Das Buch besticht auf jeden Fall durch sehr viel Praxisorientierung und hält sich nicht lange mit irgendwelchen Grundlagen und Randinformationen auf: es gibt viele Beispiele, wie sie auch im Redaktionsalltag auftreten können, und sehr gut finde ich die Checklisten am Ende jedes Kapitels, die nochmal alles gut zusammenfassen und somit eine gute Referenz für den Alltag darstellen.

    Das Buch enthält allerdings keine Informationen zum DITA Open Toolkit und dem großen Thema Ausgabeformate, aber das hätte auch nicht wirklich in das Konzept gepasst, denke ich.

    Kurzum: Ich empfehle dieses Buch absolut, wenn man einen Rundumschlag von der Autoren- bis hin zur Informationsarchitekten-Ebene möchte.

  • tekom 2011 – Content Strategy

    Auf der Jahrestagung 2011 gab es die so genannten Trendthemen, welchen dann jeweils ein gesamter Vortragsstrang an einem Tag gewidmet wurde: „Mobile Dokumentation“ und „Content Strategy“. Von ersterem Thema habe ich leider gar nichts mitbekommen, weil ich zum Einen auf  einem 1,5stündigen Workshop war und zum Anderen dann parallel stattfindende Vorträge vom Thema her bevorzugen musste. Sehr schade, aber das war mein persönliches Pech.

    Dafür habe ich dann mehrere Vorträge der „Content Strategy“-Reihe mitgenommen, die von Scott Abel moderiert wurde, der im Übrigen auch eine sehr tolle Keynote zur Tagung gehalten hat, die auch sehr in Richtung Content Strategy ging.

    Ich habe mal ein paar Schnipsel zu dem Thema festgehalten, die sich mir eingeprägt haben.

    „Technical communication IS marketing even if it doesn’t know it’s marketing.“ (Scott Abel)

    Der Satz hat mir unheimlich gut gefallen. Das Hilfeangebot ist ab dem Produktkauf DIE eine Kommunikationsschnittstelle zum Kunden. Ab diesem Zeitpunkt sind im Marketingunterlagen und die Webseite egal, denn nun geht es an die Produktnutzung. Und es ist fatal, dass diese Kommunikation häufig vernachlässigt wird, weil es „nur die Doku ist“, denn sie hat die Chance den Kunden in einer negativen Situation mit dem Produkt eventuell nochmal positiv zu stimmen. Und wir alle lieben doch zufriedene Kunden 😉

    „The user doesn’t care about your org chart.“ (Noz Urbina)

    Der Nutzer hat immer eine ganzheitliche Produktsicht – im Gegensatz zu den Firmen selbst, die sich häufig in historisch gewachsenen Strukturen verstricken und darüber vergessen, wie es dem Nutzer eigentlich so geht. Dem ist es egal wie eine Firma organisiert ist, am Ende braucht und will der Kunde eine Produkterfahrung aus einem Guss. Das heißt z.B., dass überall dieselben Informationen erhältlich sein müssen.

    „Software does not only act on content – it provides content.“ (Ray Gallon)

    Ray zielt hier darauf ab, dass heutzutage eine größere Verschmelzung zwischen der Software- und der Content-Welt besteht. Software ist heutzutage eben auch Informationslieferant und auch diese Informationen müssen geplant, erstellt und verwaltet werden.

    Content ist nicht gleich Content

    Eine Sache ist mir  besonders aufgefallen: der Content-Begriff wurde hier weit gefasst und nicht nur auf technische Kommunikation im Sinne von Anleitungen begrenzt. Bei „Content Strategy“ geht es darum, eine ganzheitliche Produktkommunikation aufzubauen, oder wie es Noz Urbina sagte: „Breaking down information silos.“

    Technische Kommunikation ist dann eigentlich „nur“ ein Teilaspekt, aber das Know-How, dass die technischen Redaktionen vielfach im Bereich des Single-Source-Publishing besitzen, macht sie sicherlich zu denjenigen in einer Firma, die prädestiniert sind, eine solche Produktkommunikation mit umzusetzen. In der TR hat man sich einfach schon mit allen Fragen des Contents beschäftigt, die bei den anderen Abteilungen vielleicht jetzt erst zum Thema werden.

    Zum Blogpost von techwriterkai gab es hierzu auch einen umfassenden Kommentar von Scott Abel, der auch nochmal herausstellt, dass es für ein tatsächliches Umsetzen von einer „Content Strategy“ fast noch wichtiger ist, z.B. supergut präsentieren zu können, sich in Manager hineindenken zu können, sich mit Dingen wie ROI etc. auseinander setzen zu können.

    Nur: Wo lernt man solche Dinge eigentlich? Kann man sie lernen? Sollten solche Aspekte stärker im TR-Studium berücksichtigt werden? Im Aufbaustudium zur Führungskraft Technische Redaktion der tecom.ch ist z.B. ein Block „Kommunikation im Unternehmen“ drin, was ich sehr interessant finde. Ich hatte das z.B. gar nicht im Studium und habe da dann eher von Kollegen lernen müssen, die schon länger im Spiel sind.

    Fazit

    Ich mag meinen Beruf, weil er mir so viele Entwicklungsmöglichkeiten bietet (ok, manchmal verdamme ich das auch, denn man muss sich ja doch auch für etwas entscheiden 😉 ). Deswegen finde ich es immer spannend, neue Möglichkeiten aufgezeigt zu bekommen. Und hier ist es eben der Fakt, dass es vielleicht in Zukunft nicht mehr nur bei der technischen Kommunikation bleiben wird.

    Oder wie Scott Abel bei Kai kommentierte:

    It’s an exciting time to be in the content industry.

  • Die Redakteuse schreibt auch für dich!

    Hier und da konnte man es schon von Twitter ahnen und der eine oder andere wusste es: ich arbeite ab sofort freiberuflich als Technische Redakteurin.

    Ich werde weiterhin hier als Redakteuse schreiben, aber wer nun auch mit mir zusammenarbeiten will, darf gerne zu mp dokumentation rübergehen.

    Heute mache ich mich auch auf den Weg zur tekom-Jahrestagung – also vielleicht sieht man sich ja 🙂

    Logo mp dokumentation

  • tekom Jahrestagung 2010 – Rückblick

    So, es ist geschafft 🙂

    Ich habe den Beinahe-Laptopausfall und die Vor-Vortrags-Nervosität halbwegs überstanden und ich denke, mein Vortrag ist ganz gut angekommen. Aber Genaueres weiß ich erst, wenn die Feedback-Bögen eintreffen. Und da bin ich äußerst gespannt! Meine Folien werde ich demnächst hier veröffentlichen sind nun unter Downloads erhältlich.

    Nun, wie sah es mit dem Rest der Tagung aus?

    Das Zielgruppen-Problem

    Bei mir und bei vielen anderen (u.a. auch im neuentdeckten Blog von Jason A. Nichols), herrschte ein wenig Unmut darüber, dass man in vielen Fortgeschrittenen- oder Experten-Vorträgen dann doch wieder mit sehr vielen Basics konfrontiert wurde. Ich weiß schon gar nicht mehr in welchem Vortrag das war, aber als man anfing uns zu erklären, dass Standards gut sind, da kam ich mir etwas veräppelt vor (das gehört für mich zur Grundausstattung des Redakteurs!). Vielen fiel es sichtlich schwer, den Vortrag zielgruppengerecht aufzubereiten. Vielleicht fehlt aber auch ein genaue Beschreibung der Klassifikationen „Einsteiger – Fortgeschrittene -Experten“? Ich habe mir rückblickend nämlich überlegt, dass ich meinen Vortrag wohl besser als „Für Experten“ eingestuft hätte, aber so richtig sicher bin ich mir nicht. Daher mein Vorschlag an die tekom, da vielleicht mal den Versuch einer detaillierten Klassifikation zu starten. Als Zuhörer ist es wirklich sehr ärgerlich, wenn man sich in einem Vortrag wiederfindet, der einfach gar nicht passt. Ich kann mir gut vorstellen, dass sich viele die Investition in die nächste Tagung nochmal gut überlegen.

    Die Idee von Urs Klenke nicht mehr so viele verschiedene Vorträge anzubieten, aber dafür ausgewähltere und diese auch zu wiederholen, finde ich prinzipiell auch ganz gut, wobei es organistorisch bestimmt ziemlich kompliziert wäre…

    iPad, iPhone, ePub

    Das war definitiv der Hype in diesem Jahr. Vieles war hier noch recht theoretisch – ich hoffe im nächsten Jahr auf erste richtige echte Beispiele!

    User assistance

    Der Hype dauert immer noch an, wobei ich da weiterhin hoffe, dass es auch hier noch mehr echte Beispiele geben wird. Die Theorie ist so langsam bekannt – jetzt will ich sehen was andere machen 🙂

    … und der Rest

    Es war einfach mal wieder nett so komplett unter „seinesgleichen“ zu sein und sich über das Fach austauschen zu können – und auch so einige Leute mal „in echt“ zu treffen 😉 Zielgruppen hin oder her – es waren immer noch Vorträge dabei, die einem hier und da wieder einen neuen Denkanstoß gegeben haben. Ich werde mir zum Beispiel in nächster Zeit einige Gedanken dazu machen, wie ich eventuell eine Verknüpfung meiner Hilfedateien mit den Textdateien unserer Applikationen hinbekommen kann, so wie in dem Vortrag „User Interface-Texte in der Dokumentation„.

    Und last but not least: endlich ist mir bei einem von Tony Selfs Vorträgen eine Frage eingefallen! Dafür wird man nämlich mit einem echten Aussie-Koala belohnt 😉

    Tony-Self-Koala

    EDIT: einen interessanten Rückblick bietet auch Sarah.

  • Firefox & seine html.css

    Ich bin gerade dabei meine DITA-HTML-Hilfe zu stylen. Da es lediglich um Aufhübschen ohne große Effekte geht, reaktiviere ich also meine HTML & CSS-Fähigkeiten.

    Eben hat mich aber eine Sache zum Wahnsinn gebracht, von der ich echt überrascht bin, dass ich sie noch nie bemerkt habe. Denn ich habe schon durchaus einige Zeit beim Webseiten-Bauen verbracht und das eigentlich immer nur unter Firefox.

    In meinem Firebug hieß es bei einigen Elementen plötzlich, dass sie ihre CSS-Styles aus einer „html.css“ beziehen würden. Nun hieß meine eingebundene CSS-Datei aber anders! Ich hatte eine solche Datei nie erstellt und auch nie eingebunden! Argh!

    Nun diese Datei repräsentiert anscheinend die Default-Einstellungen des Browsers, d.h. solche Dinge wie Überschriften werden standardmäßig gestylt, was ja auch sehr nützlich sein kann, wenn eine HTML-Seite mal gar nicht „extra“ gestylt ist. Aber irgendwie ist mir in Firebug diese Datei noch nie aufgefallen…

    Extrem hilfreich zu wissen, wenn man mal wieder Webdesign betreibt. Wer mehr wissen möchte, möge bitte hierlang gehen: Undoing html.css

    PS: Ich habe bestimmt noch nicht das tolle Firefox-Addon IETab empfohlen. Damit kann man den Internet Explorer im Firefox verwenden, was absolut genial ist 🙂

  • Gelesen: DITA – Der neue Standard für technische Dokumentation

    Bisher sind die Informationsquellen bzw. die Literatur zu DITA eher rar, im Endeffekt bleibt man beim User-Guide und der Yahoo-Group hängen und sammelt sich dort alles irgendwie zusammen.

    Nun bin ich endlich dazu gekommen mir das erste deutschsprachige Buch rund um DITA zu bestellen und zu lesen: DITA – Der neue Standard für technische Dokumentation von Johannes Hentrich. Frau Closs Buch konzentriert sich ja mehr auf Topicorientierung als auf DITA, auch wenn das natürlich gut zusammenpasst.

    Was steht zu DITA drin?

    Es ist so ziemlich alles drin, was man über DITA wissen muss:

    • Welche Philosophie dahinter steht,
    • wie es funktioniert,
    • was das Open Toolkit ist,
    • wie man den Output, also die Stylesheets, verändert,
    • wie man mit DITA wiederverwendet und filtert,
    • welche Editoren es gibt,
    • warum ein CMS Sinn macht…

    Sehr gut fand ich die Anwendungsbeispiele. Erst hier hab ich mal so richtig kapiert, was chunking eigentlich bedeutet (und das werde ich hier sicherlich mal noch in eigenen Worten wiedergeben). Ein bisschen überflüssig fand ich, dass sehr viele Dinge wiederholt wurden, z.B. was Topicorientierung bedeutet…

    Unnötige Basics

    So gut ich den Umfang zu DITA fand, so schlecht fand ich, dass das Buch gleichzeitig noch versucht einen Rundumschlag in Sachen „Technische Redaktion“ zu machen. Das macht das Buch ein bisschen unausgewogen in seiner Zielsetzung. Und mal ganz ehrlich – wenn man sich in DITA reinkniet und bereit ist Stylesheets u.ä. anzufassen, dann muss man hier nicht bei den Binsenweisheiten der TDOKU anfangen. Ja, ich weiß, dass Standardisierung wichtig ist und Wiederverwendung sowieso. Wer es nicht weiß, hat den falschen Beruf gewählt oder sollte erst einmal bei den echten Basics-Büchern anfangen.

    Rechtschreibprüfung?

    Was mein Redakteusenauge sehr genervt hat, waren die zahlreichen Tippfehler und auch Satzfehler in dem Buch. Mindestens alle drei Seiten war irgendetwas falsch geschrieben oder umgebrochen. Für das nächste Buch empfehle ich hier einen sorgfältigeren Lektor. Bei so einer kritischen Zielgruppe MUSS da alles stimmen.

    Fazit

    Für Leute, die sich in DITA reinknien wollen, ist das Buch auf jeden Fall das Richtige. Die unnötigen Kapitel kann man ja zum Glück einfach überspringen 😉 Ansonsten bekommt man alle Infos, insbesondere auch die zum Toolkit kompakt und gut dargestellt und erklärt. Dieser Teil hat mich persönlich sehr überzeugt.

    Für Anfänger in der technischen Doku hingehen enpfehle ich das Buch eher nicht, da die Kapitel, die richtig in die DITA-Materie reingehen, hier meiner Meinung nach eher abschrecken / überfordern.

    Zum Abschluss muss ich noch erwähnen, dass ich die Behauptung, dass gute Stichwortverzeichnisse bei Büchern kaufentscheidend sind, sehr witzig fand. Das trifft bei mir allerhöchstens auf Lexika und Telefonbücher zu 😉 Ansonsten ist in der Regel sicherlich das Inhaltsverzeichnis der ausschlaggebendere Punkt, nicht umsonst stellt amazon bei vielen Büchern das Inhaltsverzeichnis online zur Verfügung. Keine Frage Indizes sind ein wichtiges Navigationsmittel, aber meist bemerke ich die erst weit nach dem Kauf.Umso lustiger fand ich es aber mir auf diese Aussage hin mal den Index dieses Buchs anzuschauen und etwas darin zu suchen. Es sei nur soviel gesagt: Er sollte nicht eure Kaufentscheidung beeinflussen. Denn eigentlich lohnt sich das Buch 🙂

  • Firebug – neu entdeckt

    Ich habe ja schon einmal über den Nutzen von Firebug für Screenshots erzählt. Und schon wieder habe ich ein nützliches Feature entdeckt, auf das ich bisher einfach noch nie geklickt hatte, das aber insbesondere für die Webentwicklung extrem praktisch ist. Denn beim Layouten hat man oft das Problem, dass sich die CSS-Definitionen für padding oder margin einzelner Elemente in die Quere kommen und damit das Layout verhunzen.

    Einen schnellen Zugriff auf die Info, welches Element nun welche Werte für padding, margin oder border hat, bekommt man im Layout-Tab rechts unten im Firebug:

    In diesem Tab wird einem auf einen Blick zum aktuell in Firebug angewählten Tag angezeigt, welche Werte ihm für padding, margin oder border zugewiesen sind.

    Beispiel:

    1. Man rufe dieses Blog auf.
    2. Man öffne Firebug.
    3. Man markiere im Firebug folgenden Tag:

    4. Man sieht nun, dass die Navigation den Innenabstand 1 an allen Seiten hat und dass es beispielsweise nach oben hin 210px vom oberen Seitenrand entfernt ist.

  • Meine liebsten Tools

    Ich bin immer wieder höchst entzückt, wenn ich irgendwo ein Programm entdecke, dass mir die Arbeit wirklich erleichtert. Der Vorteil an einem IT-Unternehmen liegt darin, dass man solche Sachen gerne mal zufällig beim Kollegen oder der Kollegin entdecken kann. Ich liebe Open-Source. Meistens.

    Daher habe ich gedacht, poste ich einfach mal eine Liste meiner unverzichtbaren Programme (tw. mit Plugins), was die Arbeit anbelangt.

    • Mozilla Firefox: Mal ernsthaft – er ist einfach nur genial! Und jede Webseite, die nur IE-kompatibel ist, stinkt! (An dieser Stelle ein freundlicher Gruß an den englischen Billigflieger! Es hat Spaß gemacht, herauszufinden, dass eure Ticketbestellung nur mit dem IE geht. Oh ja!)
      • Firebug: darum und für die Webentwicklung
      • Greasemonkey: um Seiten, die ich oft aufrufe, und an denen mich bspw. die Unübersichtlichkeit nervt, mit einem kleinen bisschen JavaScript so zu modifizieren, dass ich damit „leben“ kann (wie z.B. mein Firmen-Speiseplan…). Es gibt eine Vielzahl an fertigen Skripten für viele Seiten – einfach mal stöbern!
      • Adblock Plus: ebenfalls genial! Damit kann man Werbung bestimmter Seiten blocken und wird endlich nicht mehr von Werbebannern genervt. Zudem kommt dieses Add-on schon direkt mit einer Liste zu blockender Werbung, so dass das meiste schon direkt ausgeblendet wird. Und man hat die Möglichkeit diese Liste auch zu abonnieren.
      • Delicious Bookmarks: wer del.icio.us nutzt, kann hier beim Surfen seine Bookmarks direkt dort speichern
    • Total Commander: ein sehr komfortabler Dateisystem-Explorer mit zwei Panes und auch Tabs, den man sehr schön über die Tastatur bedienen kann (das weiß man sehr zu schätzen, wenn das Betriebssytem so fertig ist, dass es die Maus nicht mehr erkennt…). Und der gleichzeitig auch als FTP- oder SSH-Client fungieren kann. Für SSH benötigt man noch ein Plugin. Das Programm ist zwar nicht Open-Source, aber es kostet nicht viel bzw. kann man die Testversion unbegrenzt nutzen (beim Starten muss man dann lediglich immer einen Dialog wegklicken).
    • Launchy: ein kleines Progrämmchen, über das man in Windeseile andere Programme aufrufen kann, ohne sich durch das Start-Menü, Desktop-Verknüpfungen zu hangeln. Man ruft das kleine Launchy-Fenster über ein Tastenkürzel auf, tippt die ersten Buchstaben des gewünschten Programms ein und kann es direkt aufrufen. Mac- und Linux-Usern sollte das ganze bekannt vorkommen 🙂 An dieser Stelle nochmal Danke für den Tipp, liebe Kollegin 🙂
    • TortoiseSVN: SVN-Client, der sich in den Windows Explorer und auch den Total Commander integriert. Für den Total Commander muss man einige Einstellungen vornehmen.
    • Notepad++: ein Editor für jede Art von Quelltext. Sei es XML, XSLT, HTML oder PHP, ein rundum guter Editor. Die Dateien werden in Tabs angezeigt, das Syntax-Highlighting passt. Ein Tipp von Entwicklern und ich arbeite wirklich gern damit.

    Das sind einmal die wichtigsten Sachen. To be continued 🙂