Usability und Technische Dokumentation – aus einem Guss

Das Buch, das ich mir heute vorgenommen habe, füllt – zumindest dem Anspruch nach – eine Lücke, die ich seit Längerem beklage: Technische Dokumentation und Produkt gleichermaßen aus dem Blickwinkel der Usability zu betrachten. Die Autorin Getrud Gründwied ist Professorin für Technische Dokumentation und Usability an der Hochschule München. Sie weiß also, wovon sie schreibt. Aber: Ist das Buch auch für Praktiker verwendbar?

Inhalt

Grünwieds Buch ist als Handbuch angelegt. Es verspricht damit Entwicklern, IT-Spezialisten und Technischen Redakteuren einen strukturierten Einstieg in das weite Themenfeld der Usability. Und ich muss sagen das gelingt auch voll und ganz. Ausgangspunkt ihrer Einführung ist für Grünwied der zunehmende Trend zur Digitalisierung von Produkten und Dienstleistungen. Im ersten Moment erschien mir das ein wenig weit hergeholt und mich beschlich eine leichte Ahnung von Buzzword-Dropping. Schließlich ist Usability in der  Dokumentation schon seit den Achtzigern ein Thema. Aber Grünwied legt anschaulich und plausibel nahe, wie Usability unter den Bedingungen der Digitalisierung zu einem entscheidenden Erfolgsfaktor wird, der sich weder bei Produkten noch bei der Produktkommunikation noch länger ignorieren lässt.

Die weiteren Informationen baut Grünwied dann didaktisch sinnvoll auf. Nach einem Grundlagen-Kapitel, das die verschiedenen Aspekte der Usability darstellt, zeigt sie die verschiedenen Prozessmodelle, in denen heute Produkte, Software und Technische Dokumentation entwickelt werden. Besonders wichtig war mir das darauffolgende Kapitel zu Nutzer- und Nutzungsforschung. Ich beschäftige mich seit langem damit und kann sagen, dass ich dieses Thema selten so strukturiert dargestellt gesehen habe. Nach einem kurzen Kapitel zur Gestaltung (bzw. zu Methoden um eine nutzbare Gestaltung zu finden) geht sie schließlich auf die Evaluation der Usability ein.

In diesen drei Kernkapiteln schildert Grünwied anschaulich und doch dicht eine Vielzahl von Methoden aus dem Usability-Bereich. Hier bestünde allerdings die Gefahr, dass die Materie in theoretischen Erklärungen stecken bleibt. Deshalb ist es nur konsequent, dass die Autorin das Buch mit zwei Praxiskapiteln abschließt: Kapitel 8 beschäftigt sich mit dem Anwenden der Methoden und Kapitel 9 zeigt drei ausführliche Fallstudien.

Präsentation

Insgesamt ist das Buch ansprechend gestaltet mit einem klaren Druckbild und einer haptisch gefälligen Papierqualität. Grafiken, Tabellen, Text-Inserts mit Hintergrundinformationen lockern das Schriftbild des Handbuchs auf. Die Informationen sind dadurch in kleine überschaubare Einheiten gegliedert und lassen sich leicht erfassen. Zur Verständlichkeit tragen auch sogenannte „Checklisten“ bei. Dahinter verbergen sich aber keine Checklisten im eigentlichen Sinn, sondern Kurzzusammenfassungen in Listenform. Hilfreich, aber eigentlich hatte ich mir etwas Anderes erwartet von den Checklisten, die auf dem Buchcover versprochen wurden.

Ähnlich geht es mir mit dem weiterführenden Material. Mit Endnoten (ist das nicht ein wenig „Old-School“?), einem umfangreichen Softwareverzeichnis und einem kurzen, thematisch geordneten Literaturverzeichnis findet der Leser eigentlich ausreichend Anknüpfungspunkte zur Vertiefung. Aber wieso gibt es keine Hinweise auf Webressourcen? Empfehlenswerte Usability-Blogs gibt es zuhauf, genau wie Youtube-Channels und Twitteraccounts von Usability-Experten. Und weil wir schon beim Thema Webressourcen sind: Warum gibt es keine ergänzende Website, in der man sich interaktive Beispiele herunterladen kann und  die über eine Linksammlung bequem zu Webressourcen führt? Bei all diesen Punkten nimmt das Buch seinen Anspruch, Digitalisierung voranzutreiben, nicht ernst genug. In einer nächsten Auflage sollte der Verlag hier auf jeden Fall nachbessern.

Fazit

Grünwieds Buch hält definitiv, was es verspricht. Es schafft den Spagat sowohl Entwicklern als auch Technischen Redakteuren einen Einstieg in das mittlerweile ziemlich unübersichtliche Thema Usability zu geben. Zwar hätte man bei dem Buchkonzept – insbesondere bei diesem Thema – einer modernen, digitalen Zielgruppe in ihren Rezeptionsgewohnheiten noch mehr entgegenkommen können. Dem Gesamteindruck tut das aber keinen wesentlichen Abbruch – eindeutige Lese-Empfehlung für alle Neulinge im Themenfeld Usability.

Literatur:  Grünwied, Gertrud [2017]: Usability von Produkten und Anleitungen im digitalen Zeitalter. Handbuch für Entwickler, IT-Spezialisten und technische Redakteure. Mit Checklisten und Fallstudien. Publicis Verlag, Erlangen. ISBN 978-3-89578-464-4.

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

Weltweit erfolgreich mit Single Source Publishing

Hilscher Produktseite

Hilscher Produktseite

Unser Kunde Hilscher als Hersteller von Komponenten für Industrienetzwerke agiert weltweit. Um seine wichtigsten Märkte optimal zu versorgen, pflegt Hilscher seine Website in sieben Sprachen. Sie zeigt unter anderem ein vollständiges, aktuelles Produktportfolio mit 1500 Produkten. Der Effekt dieser umfassenden Kommunikationsleistung ist messbar: bereits im ersten Jahr nach dem zurückliegenden Relaunch verdoppelten sich die Besucherzahlen des Internetauftritts. Dennoch bleibt der Gesamtaufwand für die Verwaltung der Inhalte überschaubar, die Website wird von zwei Mitarbeitern nebenbei betreut. Wie das gelingt, möchte ich in diesem Beitrag schildern.

Produktinformationen mit Single-Source-Ansatz

Detaillierte Informationen zu den einzelnen Produkten machen bei Hilscher das Gros des Website-Contents aus. Diese Inhalte werden nicht direkt im Internet-CMS TYPO3 gepflegt, sondern über einen Connector aus dem Redaktionssystem SCHEMA ST4 dort eingespielt. Es gibt eine Reihe von Gründen, die Produktbeschreibungen in dem für Single-Source-Publishing ausgelegten Redaktionssystem zu pflegen:

1. Mehrfachverwendung

Der naheliegendste Grund: Aus denselben Produktinformationen werden u. a. auch gedruckte Datenblätter erstellt. Um Konsistenz zu gewährleisten und Doppelarbeit zu vermeiden, ist da eine gemeinsame Datenquelle unabdingbar. Mit den HTML- und PDF-Ausgabmechanismen von ST4 lassen sich beide Formate auf Knopfdruck generieren.

2. Modularisierung

Eine Produktbeschreibung ist ein hochgradig strukturiertes Dokument. Sie besteht aus einem festgelegten Satz von Textbestandteilen wie Features, technischen Daten oder Bestellinformationen (Beispiel). Einige dieser Bausteine können dabei für ganze Produktgruppen identisch sein, wofür sich der Wiederverwendungsmechanismus des Redaktionssystems anbietet. Web-CMS sind nicht unbedingt für die Verwaltung dieses Komplexitätsgrads ausgelegt. TYPO3 erlaubt es immerhin, eine Seite aus mehreren Content-Elementen aufzubauen, aber Bearbeitung und Übersetzung verlieren schnell an Übersichtlichkeit.

3. Metadaten

In ST4 is es ein Leichtes, jedes Produkt mit Eigenschaften bzw. Metadaten zu versehen, die sich automatisiert aus dem Produktdatenmanagement übernehmen lassen. Im Internetauftritt entsteht mit diesen Informationen nützliche Zusatzfunktionalität. Bei Hilscher haben wir einen Technologiefilter (Beispiel) und einen kriteriengesteuerten Produkt-Finder implementiert. Beide Mechanismen erleichtern es dem Anwender, die für seine Zwecke richtigen Produkte zu identifizieren.

4. Übersetzungsmanagement

Die Produktbeschreibungen werden mithilfe von TRADOS in einer Agentur übersetzt. Die COTI-Übersetzungsschnittstelle von ST4 erlaubt eine zügige, kosteneffiziente Abwicklung der Übersetzungen und stellt mit seinem Übersetzungsreport ein mächtiges Werkzeug for die Qualitätssicherung zur Verfügung.

5. Qualitätssicherung

Der Abgleich nach TYPO3 aus dem ST4 erfolgt automatisiert über die von doctima entwickelte Standard-Schnittstelle ContentConnect, die Fehlerbehandlung, Datenmodellabgleich und Reporting mitbringt.

Redaktionsarbeit in TYPO3

Überblicksinformationen und Unternehmensbeschreibung sind in der Regel Freitext und lassen sich deshalb leichter als die Produktinformationen im Web-CMS verwalten. Auch sind bei diesen Texten die Nutzeffekte kleiner, die sich z.B. aus Modularisierung und Wiederverwendung ergeben. Deshalb werden diese Informationen direkt in TYPO3 gepflegt.

Um auch in TYPO3 ein systematisches Übersetzungsmanagement zu implementieren, haben wir die vorhandene Extension Localization Manager von Loctimize in Abstimmung mit der Übersetzungsagentur unseres Kunden angepasst.

Aus dem Produktivbetrieb

Das oben beschriebene Setting befindet sich mittlerweile seit einiger Zeit erfolgreich im Produktivbetrieb und die Projekterwartungen konnten vollständig realisiert werden. Neben den erhofften Nutzeffekten haben sich für unseren Kunden aber immer wieder auch unerwartete Benefits ergeben. Ein Beispiel: Wir hatten den  automatisierter Import von Inhalten und verknüpften Metadaten eigentlich für die Produktfinder-Funktion gedacht. Nebenbei liefert er aber systematisch Keywords und verbessert damit u.a. die Statistik-Auswertung von Marketing-Aktionen. Fazit: Wenn sich Dokumentation und Marketing enger zu verzahnen, steht dem weltweiten Erfolg nichts mehr im Weg.

Wie technische Redakteure den Wandel in der technischen Kommunikation aktiv mitgestalten können

Wenn der Zeitdruck steigt, bleibt die Qualität leicht auf der Strecke.

Wenn der Zeitdruck steigt, bleibt die Qualität leicht auf der Strecke.

In unserer Reihe zu Trends in der Technischen Redaktion haben wir heute Ina Franke zu Gast. Sie ist Senior Marketing Manager bei der Acrolinx GmbH. Acrolinx hilft Unternehmen überzeugenden Content zu erstellen: markenkonform, wirkungsvoll und skalierbar. Ausgestattet mit einer fortschrittlichen Sprachtechnologie, „liest“ Acrolinx Content und leitet Autoren an, ihn zu verbessern. Mehr Informationen dazu finden sich auf acrolinx.de.

Der Wert der technischen Kommunikation wird auf Unternehmensebene häufig unterschätzt. Manager betrachten die technische Kommunikation oft als notwendige Kostenstelle und übersehen dabei ihre enorme Bedeutung für die Gewinnung und Bindung von Kunden. Gleichzeitig tun technische Redakteure noch immer wenig, um diese Vorstellung zu korrigieren. Besonders, wenn sie ihren Aufgabenbereich darauf reduzieren, Verbrauchern Fragen zu Produkten und Fehlerbehebungen zu beantworten.

Mit der weiterhin steigenden Bedeutung von Content beobachten wir 6 wichtige Veränderungen im Bereich der technischen Kommunikation, die die Rolle von technischen Redakteuren neu definieren:

  1. Die Erstellung von technischem Content wird vorverlagert. Immer häufiger sind es Ingenieure und Mitarbeiter in der Produktentwicklung und im technischen Support, die Inhalte erstellen. Dadurch wird es schwieriger, für Konsistenz zu sorgen – sowohl innerhalb der technischen Redaktion als auch unternehmensweit. Verschärft wird das Problem dadurch, dass Content oft ohne eine abteilungsübergreifende Abstimmung veröffentlicht wird. Dies kann zu inkorrekten Informationen und unzufriedenen Kunden führen.
  2. Knappe Budgets oder eine fehlende Wertschätzung der technischen Kommunikation können zur Folge haben, dass das Erstellen von technischem Content ausgelagert wird. Auch dies führt dazu, dass Inhalte von zentralen technischen Ressourcen wie Produktentwicklungsteams oder der gesamten Content-Strategie abgekoppelt werden.
  3. Content wird zunehmend von Nicht-Muttersprachlern erstellt. Zu den Folgen dieser Entwicklung zählen fehleranfälliger und inkonsistenter Content, schwer verständliche und kostenaufwändige Übersetzungen und ein mangelnder redaktioneller Überblick. Das Fehlen effektiver Qualitätskontrollen erschwert es außerdem, Fehler zu beheben – oft bleiben diese unkorrigiert.
  4. Vor allem englischer Content wird zunehmend von Nicht-Muttersprachlern gelesen. Vor diesem Hintergrund müssen technische Informationen leicht verständlich sein und interkulturellen Anforderungen genügen. Eine computerunterstützte Übersetzung kann für die Lokalisierung von technischem Content hilfreich sein, erfordert aber eine zusätzliche Qualitätskontrolle.
  5. Engere Zeitpläne machen schnellere Turnarounds erforderlich. Dabei ist es wichtig, dass technische Redakteure frühzeitig integriert werden. Das ist leider nicht immer der Fall. Der Fokus auf Kosten und Schnelligkeit führt häufig sogar dazu, dass technische Inhalte erst auf Nachfrage von Kunden geschrieben werden. So hinkt technischer Content den Entwicklungen oft hinterher.
  6. Technische Redakteure teilen ihr Wissen in sozialen Medien, die von immer mehr Kunden als Ergänzung oder sogar als Ersatz für die eigentliche Dokumentation wahrgenommen werden. Statt Content vor der Auslieferung eines Produkts zu erstellen, reagieren technische Redakteure in Echtzeit auf Fragen von Kunden. Hierbei ist es wichtig, eine gute Balance zu finden. Ansonsten besteht die Gefahr, dass Unternehmen Social Media als zusätzliche Rechtfertigung dafür sehen, technischen Content weiter zu kürzen.

Als technischer Redakteur sollten Sie die genannten Entwicklungen zum Anlass nehmen, sich geschickt neu zu positionieren. Dazu sollten Sie zunächst Ihre Selbstwahrnehmung überprüfen und sich den Wert ihrer Arbeit bewusstmachen.

Die technische Kommunikation kann einen wertvollen Beitrag dazu leisten, die Umsätze Ihres Unternehmens zu steigern. Überlegen Sie, wie Sie strategische Prioritäten Ihres Unternehmens unterstützen und dies nachvollziehbar demonstrieren können. Zeigen Sie, dass die Nachfrage nach Ihrem Content wächst. Dabei können Sie sich auch auf die Marketing-Strategie Ihres Unternehmens und die Wünsche von Kunden beziehen.

Ihre Arbeit spielt eine wichtige Rolle, das Leistungsversprechen Ihres Unternehmens umzusetzen. Um das Potential Ihrer Rolle voll auszuschöpfen, müssen Sie den Wert Ihrer Arbeit jedoch überzeugend auf den Punkt bringen.

Von A nach B – 6 Tipps zur Contentmigration

Pelikane im Flug

Nur selten ist Migration so einfach wie bei Zugvögeln…

Wenn es um die Bestandsdatenübernahme geht, kann man beim Wechsel des CMS einige böse Überraschungen erleben. Denn bei der Übernahme von Altdaten steckt der Teufel im Detail. Deshalb wollen wir heute einmal ein paar Tipps zu den Details geben, auf die Sie in Ihrem Contentmigrations-Projekt achten sollten.

Zeichenkodierung beachten

Welche Zeichenkodierung haben eigentlich die Ausgangsdaten: ISO-8859-1, Windows-1252, Unicode oder etwas noch Exotischeres? Und welche Zeichenkodierung erlaubt bzw. verlangt das Zielsystem. Gibt es im Ausgangstext ein durchgehendes Escaping (Kodierung von Sonderzeichen durch Zeichenfolgen, z. B. „äußerst“ wird zu „äußerst“) und wie lässt sich dieses in das Zielsystem transformieren? Wer hier die Daten vorab genau analysiert, kann eine Menge Probleme im Migrationsprozess vermeiden.

Inkompatible Layout- und Textkonstrukte

Sind die Textkonstrukte zwischen Ausgangs- und Zielsystem kompatibel zueinander.  Komplexe semantische Handlungsanweisungen, tief geschachtelte Listen oder Zeichenformatkombinationen sind typische Problemstellen. Manches System lässt schon die Kombination aus Fett- und Kursivmarkierung (<b><i>Si meliora…</i></b>) aus der Kurve fliegen.

Makros machen Ärger

Gelegentlich werden auch statische Dokumente teilweise dynamisch gestaltet (z. B. durch eingebundene Excel-Berechnungen) oder nachträglich verändert (z. B. durch Word-Makros). Im eigentlichen Bestandscontent sind solche Mechanismen oft nicht leicht zu erkennen und manchmal sind sie den Benutzern nicht einmal bewusst. Hier ist also Recherche angesagt und ein Vergleich zwischen dem Bestandscontent und den ausgelieferten Dokumenten. Hat man solche Mechanismen entdeckt, gilt es zu entscheiden, ob sich auf sie verzichten lässt, ob sie im Zielsystem nachimplementiert werden können oder ob sie durch geeignete Mechanismen des Zielsystems ersetzt werden müssen.

Grafikformate

Auch bei Grafiken gibt es Formatprobleme – und nicht nur wenn es um print oder online als Ausgabemedien geht. Immer wieder kommen bestimmte Zielsysteme nicht mit den Formaten des Ausgangssystems zurecht. Word kann zum Beispiel nicht mit SVG umgehen. Umgekehrt stellen Word-Zeichnungen für fast alle anderen Systeme ein Problem dar. Also: Auch hier genau prüfen, was möglich ist und im Problemfall zum Beispiel ein Kompromissformat finden, mit dem beide Systeme zurechtkommen.

Beschriftungen

Neben den eigentlichen Grafikformaten sollten Sie sich auch die Art der Beschriftung in den Grafiken ansehen. Hier sind ganz unterschiedliche Varianten üblich: fest im Bild integriert (eher selten), als gruppierte Objekte (häufig und schwierig zu migrieren), mit einer eigenständigen, unabhängigen Legende (aufpassen, damit die Zusammenhänge nicht verloren gehen) u. v. m. Bedenken Sie auch die Optionen, die das Zielsystem bietet. Vielleicht ist ja z. B. eine Clickmap die bessere Lösung für die Beschriftung. Denn wenn man schon den Aufwand für die Migration betreibt, dann sollte der Content im Zielsystem auch besser sein als zuvor.

Technischer Content – auf dem Weg in die Zukunft

Achtung CatContent: Was die Zukunft wohl bringt?

Vor einigen Jahren noch hatte ich das Gefühl, dass sich in der Technischen Dokumentation Innovationsstillstand breit macht. Dieser Eindruck hat sich Gott sei Dank in den letzten Jahren geändert. Heute erleben wir eine Branche, die sich (wieder) neu erfindet. Einige Stichworte: mobile Dokumentation, internationale Teams und Redaktionsprozesse, Digitalisierung, Industrie 4.0 und neue Techniken wie VR-Interfaces, 3D-Druck.

Aufgefallen ist mir aber auch eine größere Offenheit gegenüber den Veränderungen. Nachdem sich Technische Redakteure über lange Jahre von den Kollegen aus den Marketing-Abteilungen abgegrenzt haben, sehe ich heute wieder eine größere Offenheit und Bereitschaft von den „anderen“ zu lernen, ohne dabei die eigenen Kernthemen und -standpunkte aufzugeben. Das mag mit einer jungen, gut ausgebildeten Schar von Technikredakteuren zu tun haben, die sich oft als Medienspezialisten und nicht als schreibende Ingenieure verstehen. Begrüßenswert ist es allemal.

Wie wird es nun weitergehen mit der Technischen Dokumentation? Wir haben dazu Hersteller von Software-Systemen aus der Dokumentationsbranche gefragt: „Was sind in den nächsten fünf bis zehn Jahren die großen Trends in der Technischen Dokumentation? Wie wird sich das Arbeiten verändern? Wird es Dokumentation im heutigen Sinn überhaupt noch geben?“ Und spannende Antworten bekommen. Die Beiträge zu dieser Reihe „Trends in der Technischen Dokumentation“ werden in loser Folge erscheinen. Den Anfang macht an diesem Donnerstag Uwe Reißenweber von DOCUFY mit einem Post über „Informationsräume“.

Posts zu dieser Themenreihe

API-Dokumentation – Was brauchen und wollen Entwickler?

Code ist undokumentiert schwer zugänglich
(c) Markus Vogelbacher via pixelio.de

Heute freuen wir uns, wieder einmal eine Gastautorin im doctima-Blog zu begrüßen. Stephanie Steinhardt ist Dipl. Technik-Redakteur (FH) und wissenschaftliche Mitarbeiterin an der Hochschule Merseburg. Als freiberufliche Technik-Redakteurin betreut sie außerdem verschiedene Kunden z. B. aus dem Automobilbereich. In ihrem Post zeigt Sie uns erste Ergebnisse aus einer gemeinsamen Forschungsarbeit mit Prof. Dr. Michael Meng und Andreas Schubert (MA) an der HS Merseburg. Doctima ist an diesem Projekt als Vernetzungspartner beteiligt.

Die Sicht von Entwicklern auf API- Dokumentation ist oftmals sehr verschieden. Während die einen davon überzeugt sind, dass guter Code keiner Dokumentation bedarf, schreiben die anderen selbst gern Dokumentation und konsultieren sie auch häufig. Die Meinungen darüber, wie sie denn aussehen soll, die perfekte API-Dokumentation, gehen ebenfalls auseinander. Es existieren unterschiedliche Ansätze zu Aussehen, Darreichung und Inhalt einer solchen.

An der Hochschule Merseburg widmet sich seit zwei Jahren ein kleines Team von Technik-Redakteuren in einem Forschungsprojekt der Optimierung von API-Dokumentation. Die Fragen nach Struktur und Inhalt der perfekten API-Dokumentation sowie nach dem Leseverhalten der Entwickler stehen dabei im Mittelpunkt der Untersuchungen. Auf Basis von 23 durchgeführten Interviews, der Erhebung von Daten aus rund 100 Fragebögen und einer Beobachtungsreihe, bei der genau verfolgt wurde, wie Entwickler Programmieraufgaben lösen, sowie unter Berücksichtigung der bereits existierenden Studien im Umfeld von Entwicklerdokumentation können wir Empfehlungen geben, die API-Dokumentationen deutlich besser und effizienter nutzbar machen.

Nicht jeder Entwickler ist wie der andere.

Entwickler unterscheiden sich nicht nur in ihrer Einstellung zur Dokumentation, in den Jahren ihrer Programmiererfahrung oder bezüglich der Systemwelt, in welcher sie zu Hause sind. Sie unterscheiden sich vor allem in ihrer Arbeitsweise. So konnten wir in unseren erhobenen Daten zwei verschiedene Ansätze identifizieren, welche vor allem bei der Einarbeitung in eine neue API deutlich hervortreten. So gibt es Entwickler, die einen eher codegetriebenen Ansatz verfolgen und nach eigener Aussage gern direkt mit einem Code-Beispiel einsteigen. Sie erarbeiten sich den Umfang einer API eher intuitiv von unten nach oben. Es gibt aber auch Entwickler, die konzeptorientiert arbeiten und sich vor der Nutzung einer neuen API zunächst einen Überblick verschaffen. Entwickler, die der Meinung sind, dass es nützlich ist, das Konzept der API in Gänze zu verstehen, auch wenn nur ein Teil der API tatsächlich zur Problemlösung genutzt wird.

Abb.: 1 – Absolute Zeitwerte: Recherchezeit (farbig) vs. Bearbeitungszeit (grau) der Probanden 01-11

Besonders deutlich traten diese Verhaltensmuster in der von uns durchgeführten Beobachtungsreihe hervor. So haben 6 der 11 beobachteten Probanden im Konzeptbereich der API-Dokumentation unserer Test-API gelesen, wohingegen die anderen 5 kaum einen Blick hinein warfen und vorrangig auf Beispielcode fixiert waren.

Lesen ist nicht gleich lesen.

Trotz der gegensätzlichen Sichtweisen der Entwickler auf API-Dokumentation hat die Beobachtung gezeigt, dass im Beobachtungszeitraum von jeweils einer Stunde alle Probanden nahezu die Hälfte der Zeit mit der Recherche in der API-Dokumentation zubrachten, während die andere Hälfte für die tatsächliche Programmierung zur Lösung der Aufgaben verwendet wurde.

Wie die Analyse der entstandenen Eyetracking-Aufnahmen zeigte, scannten und überflogen die Entwickler die einzelnen Inhalte mehr, als dass sie tatsächlich Zeile für Zeile lasen. Dabei fokussierten Sie vorrangig auf die visuell hervorgehobenen Elemente, wie Hyperlinks, die Navigation und Beispielcode. Der erklärende Fließtext wurde meist nur dann gelesen, wenn aus dem Beispielcode allein keine Lösung abzuleiten war.

Das Leseverhalten schien darüber hinaus nicht nur beeinflusst von der individuellen Arbeitsweise, sondern war auch geprägt von der Einschätzung zum Schwierigkeitsgrad der gestellten Aufgabe. Bei Aufgaben, die schwieriger zu lösen schienen, waren die Probanden eher geneigt zu lesen, als bei Aufgaben, die einfacher wirkten.

Wer die Prozesse kennt, ist klar im Vorteil.

Bereits in den Interviews und in existierenden Studien kam zum Vorschein, dass mitunter alleinige Programmiererfahrung kein Garant ist für die schnelle Einarbeitung in eine neue API. Vielmehr entscheidend ist das vorhandene Domainwissen. Wer mit den zugrunde liegenden Prozessen vertraut ist, welche die API abbildet und dazu das Fachvokabular kennt, ist deutlich schneller bei der Einarbeitung und Lösung von Programmieraufgaben. Das zeigte auch unsere Beobachtungsreihe sehr eindrücklich (vgl. Abbildung 1 – Probanden 03, 04, 05,06 und 10 besaßen Domainwissen).

Demnach kommt der Vermittlung von Domainwissen in einer API-Dokumentation eine wichtige Rolle zu. Die Platzierung dieser Informationen ist mit Hinblick auf Leseverhalten und Arbeitsweise der Entwickler elementar.

Abb.: 2 – Beispiellayout für Codekommentare im Beispielcode (adaptierter Inhalt, basierend auf https://developers.shipcloud.io/reference/)

Der beste Ort für wichtige Informationen in einer API-Dokumentation ist einer, den alle Entwickler tatsächlich anschauen. Auf Basis der Interviews, den Fragebögen und der Beobachtung können nur Codebeispiele dieser Anforderung genügen. Sie werden von allen Entwicklern angesehen und als Basis der eigenen Programmierung verwendet. „Verkleidet“ man wichtige Informationen als Codekommentar und setzt diese deutlich vom restlichen Codebeispiel ab, kann man sicher sein, dass sie gesehen und, wenn kurz, auch gelesen werden. Auf ausführlichere Beschreibungen sollte zugunsten der eher konzeptorientierten Entwickler aber dennoch nicht verzichtet werden.

Dieser konkrete Optimierungsvorschlag und die zuvor genannten Erkenntnisse sind natürlich nur ein kleiner Teil der bisher gewonnenen Forschungsergebnisse. Unsere Untersuchungen dauern im Moment noch an. Daher sind wir auch sehr interessiert an Unternehmen, die bereit sind, sich an ähnlichen Studien zu beteiligen und damit die Zahl der möglichen Probanden vergrößern.

Kontakt: stephanie.steinhardt@hs-merseburg.de

Migration – eine neue Heimat für den Content

Edgar Hellfritsch

Edgar Hellfritsch

Daten und Content: Ein Schatz, den wir im Lauf der Jahre mühsam aufgebaut haben. Und der zum Problem wird, wenn wir uns zum Beispiel entscheiden von der altgedienten Textverarbeitung (z. B. Word oder FrameMaker) auf ein Content-Management-System umzusteigen. Seltene Aufgabe, die aber doch immer wieder zu erledigen ist, wenn ein Systemumstieg ansteht. Wir haben mit Edgar Hellfritsch geredet. Er beschäftigt sich seit über zwanzig Jahren mit der Frage, wie man Daten und Content am besten migriert und hat über hundert Migrationsprojekte geleitet. In diesem Interview schildert er uns seine Erfahrungen.

doctima: Edgar, wie sieht denn das typische Migrationsprojekt aus?

Jedes Projekt ist irgendwie natürlich wieder anders. Aber grundsätzlich kann man sagen: Ein typisches Migrationsprojekt hat etwa 10.000 Seiten DIN A4, die in etwa 30 Sprachen vorliegen. Migriert wird meistens von einem layout-orientierten Textverarbeitungssystem in ein strukturiertes Format, also ein CMS oder xml-basierte Standards wie DITA. Letzten Endes kommt aber alles vor. Wir hatten auch schon Fälle wo wir DITA nach DITA migriert haben, weil zwei Unternehmensteile sich für einen gemeinsamen Standard entschieden haben.

doctima: Und wie geht man dabei vor?

Grundsätzlich muss man sich entscheiden, ob der Content schrittweise nach und nach migriert werden soll oder zu einem Stichtag in einer großen Hauruck-Aktion. Welches Vorgehen da sinnvoll ist, lässt sich nicht pauschal sagen. Das hängt von der Gesamtdatenmenge, vom Vernetzungsgrad des Contents, von den Redaktions- und Freigabeprozessen und natürlich von der Terminplanung für den Produktionsstart im neuen System ab.

Nach und nach zu migrieren erscheint auf den ersten Blick oft erst einmal wünschenswerter. Altdaten können fallweise auch einmal unmigriert bleiben, der Aufwand ist überschaubarer und die ersten Erfolgserlebnisse sind schnell vorhanden. Aber: Nach und nach zu migrieren bedeutet einen deutlichen Mehraufwand, denn beide Systeme müssen über einen längeren Zeitraum weiterbetreut werden. Und wenn die Redaktion diesen Mehraufwand personell nicht leisten kann, kommt es im schlimmsten Fall dazu, dass die (produktive) Systemeinführung sich so lange verzögert, bis sie komplett scheitert.

Und dann gibt es noch eine Fülle weitere Entscheidungen: intern oder extern, automatisiert oder manuell und, und, und. Jede dieser Entscheidungen hat ihr eigenes Für und Wider. Aber ich glaube das würde jetzt zu weit führen, wenn ich da im Detail darauf eingehe.

doctima: Übernimmt so eine Migration der Systemhersteller?

In den seltensten Fällen. Denn Migration bedeutet eine ganz eigene Art von Expertise, bei der man Ausgangsformat und Endformat genau im Blick haben muss. Auf dem Weg gibt es dabei einige Tücken, die für Systemhersteller schwer zu kalkulieren sind. Im Normalfall ist es hier besser, sich einen Dienstleister ins Boot zu holen, der auf Migrationsprojekte spezialisiert ist.

doctima: Welche Formate sind denn besonders schwer zu migrieren?

Wahrscheinlich erwarten jetzt viele als Antwort: Word! Das ist aber gar nicht so. Denn das Problem liegt nicht so sehr im Format selbst, sondern eher darin, wie strukturiert die Redakteure gearbeitet haben und wie konsequent sie ihre Standards eingehalten haben. Da sind mir Word-Dokumente, bei denen sauber mit Formatvorlagen gearbeitet wurde, tausendmal lieber als Dokumente, bei denen die Redakteure versucht haben, mit XML zu layouten.

Umgekehrt kann eine scheinbar einfache Anforderung, wie DITA nach DITA zu migrieren, sich im Projektverlauf als extrem heikel erweisen, wenn z. B. Metadaten zur Steuerung des Publikationsprozesses verwendet wurden oder eben semantische Strukturen missbraucht wurden, um ein bestimmtes Erscheinungsbild zu erzeugen. Da werden dann Informationssequenzen als Bildbeschriftung getaggt, weil man das Ganze gerne in einer Box darstellen will. Für die Migration ist so etwas ein Desaster.

doctima: Ein Erfolgserlebnis?

Für unsere Kunden ist der größte Erfolg wohl immer, wenn sie sehen, wie schnell ein Großteil des Contents migriert ist. Als derjenige, der sich um die Umsetzung kümmert, sind die ERfolge für mich aber oft eher die Kleinigkeiten am Rande. Vor einiger Zeit ist es mir z. B. in einem Projekt gelungen, komplexe Tabellen automatisiert von CALS nach HTML und wieder zurück umzuwandeln. Der Weg von CALS nach HTML ist mehr oder weniger trivial. Der Weg zurück ist aber ziemlich trickreich, weil das CALS-Tabellenmodell – na sagen wir mal – „originell“ ist. Da muss man sich letzten Endes jede Tabellenzelle einzeln angesehen haben, bevor man die Tabelle zusammenbauen kann. Für den Laien ist das dann nicht weiter spektakulär, wenn am Ende alles klappt. Aber als Spezialist ist man da schon ein wenig stolz.

doctima: Zum Abschluss: Was würdest du jemandem für die Migration raten,  bevor er einen Systemumstieg plant?

Sich neben dem Dokumentbestand auch den Redaktionsprozess vorher genau anzusehen und sich im Zweifelsfall Hilfe von außen zu suchen.  Ohne Bestandsanalyse kann man sonst manche böse Überraschung erleben, weil zum Beispiel im Publikationsprozess Makros nachträglich noch den Content verändern. Generell ist es sinnvoll sich anzusehen, welche Strukturen im Content vorhanden sind und welche davon erhalten bleiben müssen. Wir haben dazu automatisierte Verfahren mit denen wir Bestands-Content analysieren. Da stellt sich dann eigentlich meistens heraus, dass es eine ganze Reihe von Dokumentstrukturen gibt, die bei 10.000 Seiten vielleicht nur drei oder vier Mal vorkommen. Und da sollte man sich dann schon fragen, ob es sich lohnt, das auch im Zielsystem abzubilden.

doctima: Danke für das spannende Interview.

Gerne.

 

Eine App für Arbeitssicherheit und Umweltschutz

dka_screenshot

Die Startseite der Handbuch-App

Heute möchte ich ein Projekt aus dem Bereich Mobile Dokumentation vorstellen, das wir mit unserem Kunden Dresdner Kühlanlagenbau GmbH, kurz: DKA, umgesetzt haben. Einen kurzen Vortrag dazu habe ich bereits im „Showcase Mobile Doku“ auf der letzten tekom-Jahrestagung gehalten. Nach einem Jahr im Produktivbetrieb liegt uns nun eine ganze Reihe von positiven Rückmeldungen vor, die unser Credo bestätigen, dass mobile Dokumentation im richtigen Kontext einen deutlichen Mehrwert gegenüber herkömmlichen (Papier-)Dokumenten schafft.

Die DKA installiert und wartet Kühlanlagen und Klimatechnik für Handel, Gewerbe und Industrie. Die mehreren hundert Monteure im Außeneinsatz sind verpflichtet, ein Handbuch mit Betriebsanweisungen dabei zu haben, die den Umgang mit Gefahrstoffen und gefährlichen Situationen regeln. Das Unternehmen ist vielfach zertifiziert, u. a. nach ISO9001 und §6 ChemKlimaschutzV, und wird auch von seinen Kunden regelmäßig evaluiert. Mit dem Handbuch als Loseblattsammlung war es schwierig sicherzustellen oder nachzuweisen, dass alle Monteure immer mit dem aktuellsten Stand von Informationen versorgt sind. Daraus entstand die Idee, das Handbuch in eine Smartphone-App umzusetzen und um einige hilfreiche Funktionen zu ergänzen.

Was die App leistet

Die App soll im Kern zwei Dinge erreichen: Sicherstellen, dass die Mitarbeiter Änderungen in den Betriebsanweisungen zeitnah und nachweisbar erhalten.Und sie motivieren, das Handbuch tatsächlich zu verwenden.

Um auch in Kellern und Tunneln verfügbar zu sein, bringt die App alle wesentlichen Inhalte – das sind v.a. Betriebsanweisungen und ein Gefahrstoffverzeichnis mit Sicherheitsdatenblättern der Hersteller – offline mit. Verteilt und aktualisiert wird sie via Mobile Device Management.

Um unsere eher handwerklich fokussierte Zielgruppe zum Lesen zu motivieren haben wir uns einige Dinge einfallen lassen. Begonnen mit einer ansprechenden Aufmachung, weiter mit schnellen und alternativen Zugangswegen zur Information, deren Formulierungen wir gestrafft und auf Verständlichkeit optimiert haben bis hin zu einer Kommentarfunktion, um den Kollegen die Möglichkeit zu geben, sich aktiv in den Gestaltungsprozess des Handbuchs mit einzubringen.

Geänderte Anweisungen werden direkt auf der Startseite angezeigt. Im Dokument selbst sind die geänderten Abschnitte farbig hervorgehoben. Zudem erscheint in geänderten Dokumenten ein Button um zu bestätigen, dass man die Änderungen wahrgenommen hat. Nach dem Bestätigen verschwinden Button und Markierungen. Die Bestätigungen aller Mitarbeiter werden auf einem Server gesammelt, wo sie sich für Audits auswerten lassen.

Um einen weiteren Anreiz zu schaffen, regelmäßig in das Handbuch hineinzusehen, haben wir eine Rubrik mit aktuellen Meldungen eingerichtet. Das sind die einzigen Inhalte die direkt vom Server bezogen werden. Sie werden prominent auf der Startseite angezeigt.

Welche Technologien wir verwenden

Das Handbuch ist eine hybride Android-App, d.h. HTML-Seiten verpackt mit Adobe PhoneGap. Das HTML für die Inhalte basiert auf dem responsiven Framework Bootstrap von Twitter, das wir um einige eigene Funktionen erweitert haben. Von den PhoneGap-Features nutzen wir v. a. den lokalen Dateizugriff, um die zugelieferten Sicherheitsdatenblätter-PDFs anzuzeigen, und die lokale Datenbank und die Abfrage des Verbindungsstatus zu Pufferungszwecken. Die Interaktionen mit dem Server erfolgt über Javascript und HTTP.

Ein TYPO3-Server, den wir entsprechend erweitert haben, dient als zentrale Gegenstelle für die Nutzerverwaltung, die aktuellen Meldungen, das Feedback und die Lesebestätigungen.

Für die Redaktion der Inhalte verwenden wir SCHEMA ST4. Dessen Datenmodell mit klassifizierten Knoten, Links und Metadaten nutzen wir, um die Inhalte mit Intelligenz auszustatten.

Intelligenter Content

Neben der Wiederverwendung (in den Betriebsanweisungen werden sehr viele Textbausteine mehrfach eingesetzt) und dem Single Source Publishing (neben einer Desktop-Ausgabe fürs Intranet gibt es von der App auch eine PDF-Druckversion) nutzen wir die Features unseres Redaktionssystems v. a. dazu, um ein möglichst smartes Endprodukt zu erzeugen. Im Folgenden will ich ein paar Beispiele zeigen:

Aufklappbereiche strukturieren die einzelnen Betriebsanweisungen. Zu diesem Zweck haben wir die Betriebsanweisungen in einzelne Objekte (in ST4: „Fragmente“) zerlegt, die über ein Metadatum als Aufklappbereiche markiert sind. Im HTML werden diese Bausteine zu Bootstrap-Panels mit klickbarer Kopfzeile und versteckbarem Body. Der Aufwand für dieses Feature besteht hauptsächlich darin, redaktionell ein Metadatum zu setzen und in der Generierung dafür zu sorgen, dass das Fragment mit Metadatum in ein DIV der Klasse „panel“ umgesetzt wird.

Ein anderes Metadatum steuert, welche Sicherheitssymbole zu Beginn eines Seitenbereichs ausgegeben werden. Das Erfassen über eine Mehrfachauswahl ist leichter und flexibler als das direkte Zuordnen von Bildreferenzen.

Die Einteilung des Inhalts in Bausteine ist auch Voraussetzung dafür, dass einzelne Abschnitte ihr Überarbeitungsdatum kennen und in der App als geändert markiert werden können. Auch hier wird ein Metadatum aus dem Redaktionssystem, diesmal als HTML-Attribut „data-lastchanged“,ins Endprodukt übertragen.

Eine wesentliche Verbesserung der Bedienbarkeit am Smartphone erreichen wir durch die einfache Maßnahme, dass Links als Buttons dargestellt werden. Insbesondere die Notrufnummer, die im Bereich Erste Hilfe immer wieder im Text erscheint, wird als roter Button mit Telefonsymbol umgesetzt – der natürlich bei Betätigung sofort den Notruf auslöst.

Gefahrstoffverzeichnis

Type Ahead: Das Gefahrstoffverzeichnis verkürzt sich während des Tippens

dkagefstoff

Alles zum Gefahrstoff auf einen Blick

Die umfassendste Veränderung haben wir der Gefahrstofftabelle angedeihen lassen. Die ist im Original eine Tabelle mit einem Dutzend Spalten und einigen hundert Zeilen, die sich im Querformat über mehrere DIN-A4-Seiten verteilt. Gefolgt wird sie im Original von einer Reihe von Legenden, da in der Gefahrstofftabelle nur Platz ist für die ISO-Kürzel der verwendeten Gefahrensymbole und Hazard- bzw. Precautionary Statements. Diese Tabelle und ihre Legenden haben wir in einzelne Objekte und Querbeziehungen zwischen ihnen aufgelöst. Das erlaubt uns, mit einer Type Ahead-Auswahlliste in der App einen schnellen Zugang zu den Gefahrstoffen zu legen und jeden Gefahrstoff als eigene übersichtlich gelayoutete HTL-Seite zu erzeugen. Im PDF generieren wir wieder die Tabelle im Querformat.

Mit diesen Beispielen möchte ich zeigen, dass intelligente Information schon mit kleinen Eingriffen in den Redaktionsprozess erreicht werden kann. Die Liste ist nicht vollständig, aber sie soll auch nur ein Gefühl dafür geben, dass es mit überschaubarem Aufwand und ohne das Budget eines Großkonzerns möglich ist, dem Medium mobile Dokumentation einen spürbaren Mehrwert zu verleihen.

Projektergebnisse

Nach einem Jahr Produktivbetrieb sehen wir alle Projektziele erreicht. Die Aktualität nach Rechts- und Sachstand ist deutlich verbessert. Reaktionszeiten sind verkürzt, Lesbarkeit und Zugänglichkeit erhöht, und nebenbei wurden die Verteilkosten gesenkt. Die Nachweisbarkeit ist erreicht, was bereits beeindruckte Rückmeldungen von Auditoren und Großkunden zur Folge hatte. Die App kommt bei der Zielgruppe ebenso gut an wie bei führenden Mitarbeitern und hat im Unternehmen einen hohen Stellenwert, sodass Erweiterungen und weitere ähnliche Anwendungen diskutiert werden.

Wir als doctima (das „wir“ bisher in diesem Beitrag bezog sich immer auf das Projektteam bei uns und bei DKA) haben aus diesem Projekt viel gelernt, insbesondere, was das Zusammenspiel von Redaktionssystem und intelligentem mobilem Informationsprodukt angeht. Im Augenblick entsteht eine Masterarbeit auf der Grundlage unserer Erkenntnisse.

Auf der kommenden tekom-Tagung haben wir außerdem eine Demo-App im Gepäck, mit der Sie sehen können, wie die hier erarbeiteten Konzepte in der Praxis aussehen. Falls Sie noch keine Karten zur tekom Messe haben – kein Problem: Hier anmelden und Sie erhalten gratis von doctima Ihren persönlichen Aktions-Code für eine Freikarte. Und übrigens: Besucher unseres Messestands erhalten einen kostenlosen 3D-gedruckten „Textbaustein“.

Warum ich SCSS nicht mehr missen möchte

Schickes CSS mit Sass

Schickes CSS mit Sass

Ich beschäftige mich mit Redaktionsprozessen und deren Optimierung. D. h. ich werde immer hellhörig, wenn es eine Chance gibt, etwas zu vereinfachen oder besser zu strukturieren.

In einem anderen Teil meines Jobs gestalte ich Online- und mobile Medien. Dort spielt HTML 5 eine große Rolle. Für dessen Gestaltung verwendet man CSS, und mit CSS habe ich als jemand, der in Strukturen denkt, ein Problem.

Mein Problem mit CSS

CSS bietet kaum Möglichkeiten, zu strukturieren. Es ist auf schnelle Verarbeitung durch den Browser hin optimiert, Wartbarkeit hat nicht Priorität. Im Wesentlichen bestehen CSS-Dateien deswegen aus einer linearen Abfolge von Regelsätzen, die bestenfalls in Blöcke für unterschiedliche Zielmedien gruppiert sind, also z.B. für Mobilgeräte oder Drucker. Alle Angaben sind explizit. Das bedeutet, jede Farbangabe, die mehr als ein Element betrifft, muss mehrfach identisch hingeschrieben werden. Es gibt keine Variablen. Damit werden komplexe Stylesheets schnell unübersichtlich und sind schwierig zu pflegen.

Eine Lösung

Konzeptionell lässt sich die Unstrukturiertheit von CSS nur rudimentär behandeln: Man kann die CSS-Regeln auf mehrere Dateien verteilen. Effektiver wäre es aber, CSS zumindest für die Erfassung um gängige Programmierkonzepte zu erweitern wie Variablen, Vererbung, Hierarchien oder Berechnungsfunktionen.

Tatsächlich haben sich seit Längerem mehrere Formate etabliert, die genau das leisten. Beispiele sind LESS, Coffeescript oder SASS. Das Format SCSS, das ich hier vorstellen will, ist eine syntaktisch andere Geschmacksrichtung von SASS. Diese Sprachen erlauben es, Regelsätze strukturiert zu erfassen, sind aber leider für Browser nicht lesbar. Deshalb werden sie mit sog. Präprozessoren ausgeliefert. Präprozessoren sind Konverter, die Dateien vor dem Ausliefern an den eigentlichen Prozessor (hier: den Browser) verarbeiten. Somit besteht SCSS aus zwei Komponenten:

  • einem Format, bei dem es sich um eine funktionale Erweiterung von CSS handelt.
  • einem Prozessor, der für unterschiedliche Betriebssysteme unter einer MIT-Opensource-Lizenz frei erhältlich ist.

Sassy CSS

Ich möchte die wesentlichen Features von SASS (die Abkürzung steht für „Syntactically Awesome Style Sheets“) bzw. SCSS („Sassy CSS“) hier nur kurz anreißen.

  • Regelsätze schachteln: Angaben beispielsweise für Links, die im Footer oder im Header stehen, lassen sich innerhalb des Regelsatzes für allgemeine Links platzieren, anstatt sich irgendwo über die CSS-Datei zu verteilen.
  • Abgeleitete Klassen: Formate für Warn- und Gefahrenhinweis-Boxen lassen sich von einer gemeinsamen, allgemeineren Klasse Hinweis-Box ableiten, anstatt alle Angaben zu wiederholen oder in mehrere gemeinsame und spezifische Regelsätze zu verteilen.
  • Ausgelagerte Dateifragmente, Partials: In sich geschlossene Teilbereiche, beispielsweise die Regelsätze für das Navigationsmenü, lassen sich in einzelne Dateien auslagern. Das geht auch mit CSS, wo aber jede ausgelagerte Datei im HTML-Kopf explizit referenziert werden muss. Der SCSS-Präprozessor fasst die Partials zu einer einzigen Datei zusammen, was sowohl die Verwaltung der Referenzen im HTML erleichtert als auch die Performance verbessert.
  • Variablen: Werte, aber auch ganze Regeln lassen sich in Variablen deklarieren. Wiederkehrende Gestaltungselemente oder CI-Farben lassen sich somit an einer Stelle verwalten und bei Bedarf zentral austauschen.
  • Operationen und Funktionen: SCSS stellt eine ganze Reihe von Manipulationen und Berechnungen zur Verfügung. Das Spektrum reicht von einfachen Farbänderungen wie darken($color) über Textfunktionen und Mathematik bis hin zur Verarbeitung von assoziativen Listen wie mit map_get($map, $key).
  • Mixins: Mixins sind aufrufbare Makros, denen man Parameter mitgeben kann. Um auf das Beispiel mit den Hinweis-Boxen zurückzukommen: Ein Mixin hinweisbox($severity, $symbol) kann die Darstellungsregeln für eine Hinweis-Box enthalten, mit Parametern für die Gefahrenstufe und das anzuzeigende ISO-Symbol. Die Gestaltung eines Gefahrhinweises mit Augenschutz kann sich dann auf den Aufruf @include hinweisbox(‚Gefahr‘,‘Laser‘) beschränken.

SCSS im Alltag

Wir verwenden SCSS mittlerweile seit mehreren Jahren in praktisch allen Projekten, in denen CSS eine Rolle spielt, und bereuen den Schritt in keiner Weise. Die Aufwände für Installation und Einarbeitung waren kaum der Rede wert. SCSS ist anders als SASS eine reine Erweiterung der CSS-Syntax, womit der Einstieg sehr schnell vonstattenging.

Die Features, die wir am meisten nutzen und die uns massiv Zeit ersparen, sind Variablen und Partials, die besonders in Projekten mit mehreren Layouts (Kunde und Tochterfirma, Eigenmarke und OEM) ihren Nutzen ausspielen. Und, ganz wesentlich: das Schachteln von Regelsätzen, das ein sinnvolles Strukturieren der Stylesheets erst ermöglicht und nebenbei sehr viel Schreibarbeit erspart.

Eine nicht zu unterschätzende Nebenwirkung dieser Strukturierung ist, dass wir automatisch sehr viel systematischer an die Gestaltung der Stylesheets herangehen als zu Zeiten, als wir nur einzelne Regeln hintereinander weggeschrieben haben. Da war es schnell passiert, dass der allgemeine Regelsatz für Links und der spezielle Regelsatz für Links im Footer tausend Zeilen weit auseinander standen. Mit SCSS erhöht sich die Wartbarkeit der Lösung deshalb ganz ungemein.

Was den Übersetzungsvorgang von SCSS nach CSS angeht: Wir haben das in den beiden Entwicklungsumgebungen, mit denen wir arbeiten, PhpStorm und Visual Studio, über Plugins so eingerichtet, dass der Präprozessor beim Speichern der SCSS-Datei automatisch anspringt. Das bedeutet, dass die generierten CSS-Dateien nebenbei und ohne unser explizites Zutun entstehen. Der administrative Mehraufwand besteht also vor allem im einmaligen Einrichten der jeweiligen Plugins.

Fazit

Wir haben SCSS für meinen Geschmack viel zu spät entdeckt, als es bereits jahrelang zur Verfügung stand. Mittlerweile ist es aber für mich und mein Team aus dem Arbeitsalltag nicht mehr wegzudenken, wenn es um Online- und mobile Medien geht. Auch wenn wir seine Möglichkeiten nicht bis ins Letzte ausreizen, sind bereits die wenigen Key Features, die wir ausführlich nutzen, eine erhebliche Erleichterung beim strukturierten Entwickeln und Warten von Stylesheets. Wenn Sie also mit CSS im Vanillegeschmack arbeiten, und gerne effizienter damit umgehen möchten, kann ich Ihnen dringend einen Blick auf SCSS empfehlen.

 

Startpunkt für Redaktion und Übersetzung

(c) Peter Smola pixelio.de

MIt den richtigen Werkzeugen für die Technische Redaktion und Übersetzung lässt sich so manche Hürde im Arbeitsalltag leichter bewältigen. Und es gibt ja auch jede Menge Hilfsmittel:

  • Übersetzungsspeicher
  • Terminologie-Datenbanken
  • Leitfäden
  • Online-Grammatiken
  • Sprachprüf-Software
  • und vieles mehr…

Studierende an der FH Wels in Oberösterreich haben im Sommersemester 2015 „Hilfsmittelbenutzung und Rechercheverhalten in der technischen Redaktion“ erforscht und daraus einen Überblick zu den Hilfsmitteln in der Technischen Redaktion und Übersetzung entwickelt. Die daraus entstandene Microsite ist ein hervorragender Einstieg für Neulinge in der Technischen Dokumentation und Übersetzung. Sie hält aber auch für den Profi noch den einen oder anderen Tipp bereit.

Vollständig ist die Microsite der FH Wels allerdings bei weitem nicht. Zum Beispiel fehlt bei den Sprachprüf-Werkzeugen unser ContentRuleset. Und leider gibt es auch keine Kontaktadresse, bei der man weitere Fundstücke einreichen kann. Schade, denn gut gepflegt hätte der Hilfsmittel-Überblick das Zeug dazu, eine zentrale Anlaufstelle für Technische Redakteure zu werden.

Übrigens: Auf die Welser Microsite wurde ich aufmerksam gemacht durch Klaus Schubert. Er ist Professor in Hildesheim und Herausgeber der Online-Zeitschrift transkom, einer weiteren wichtigen Ressource für Übersetzer.