Seit dem 21.03.2019 steht’s fest: IEEE 82079-1-2019 ist als « International approved Draft Standard » (« Preparation of Information for Use ») vorhanden.

Unter den Neuigkeiten finden wir im Art. 5.3 « Informationsqualität » « 5.5.3. – Minimalism »                   

« Minimalism shall be applied »

Also Minimalismus MUSS angewandt werden. Keine Frage.

Minimalismus: wie geht das?

© Schmeling Consultants

Prinzipien

Minimalismus ist nicht ein Prinzip, sondern « an approach to information for use that includes critical information« .

Diese Vorgehensweise wurde Ende der Neunziger Jahre von John Carroll und Dr Hans van der Meij entwickelt und besteht aus 4 Prinzipien

• • • • •  Choose an action-oriented approach (Aufgabenorientiert oder Aktionorientiert)
        •  Anchor the tool in the Task domain = the product should be considered as used in the user’s   environment (an die Arbeitsumgebung, die Ausbildung, die Erfahrung der Endverbraucher denken)
    • Support Error Recognition and Recovery (« Troubleshooting »)
      (Wichtig: wie kann der Endverbraucher schnell und effizient Fehler beheben?)
    • Support reading to do, study and locate (« Findability »)
      (Oft vergessen: wie und wo findet er die richtige Information)

Missverständnisse: kurz muss es sein!

Aufgepasst, Minimalismus bedeutet nicht unbedingt kurze Sätze oder kurze Wörter, sondern « the least amount of information needed to be complete ».

In einem Interview mit STC Vorstandsvorsitzende Nicky Bleiel erklärte John Carroll: « Wantonly slashing text and leaving other design characteristics unchanged will not lead to a minimalist design. »

Und zum Schluß noch:  Kürze ist nicht immer die Lösung!

Zuviel des Guten

Wohlgemerkt, « In contrast to minimalist information, excessive documentation of all possible product functions for example is wasteful » (Art. 5.3.3.)

Also, lange, detailierte Funktionsbeschreibungen helfen wirklich nicht. Der Endverbraucher braucht keine ausgedehnte Liste der Funktionen, sondern die Handhabung, wie er die gewünschten Aufgaben mit Hilfe der Funktionen erledigen kann.

Prozeduren

Wichtig auch ist Art. 8.3.4.3 « Instructional steps shall be numbered using Arabic numerals and presented in the order of performance »

Als Regel gilt folgendes

• Anweisende Schritte werden nummeriert
• Jeder Schritt, einer Handlung
• Resultate der Schritte werden nicht nummeriert

Weiterhin empfehlt die Norm « …languages where the imperative exists and is culturally acceptable, the instructional steps should use the imperative to describe the target audience’s action « .

Daher « Program starten

1. Auf den grünen Knopf drücken
2. Warten, bis die gelbe Lampe blickt

Die Fortschrittsanzeige startet. »

Warnhinweise, Kompetenzen und ein Webinar

Mit Warnhinweise soll der Redakteur sparsam umgehen:

« If warning messages are integrated between the steps of a procedure, the formatting (especially excessive highlighting) of the warning message should not distract the target audience from reading the information ».

Dies kommt uns irgendwie bekannt vor… s. Dieter Juhl « Warn out – Konzep für sinnvolle Sicherheits- und Warnhinweise »
Eine weitere Diskussion über Warnhinweise ist (auf Frenglish) vorhanden  .

Um Fachkompetenzen des Technischen Redakteurs geht es auch in der Norm und zwar unter 10.2 « Task-related competencies ». Die 13 Kompetenzen sind (auf Englisch) bereits aufgelistet und kommentiert.

Hier geht es weiter : Podcast vom Webinar. Es geht um Minimalismus, Sicherheitshinweise, Ikonen und « Information types »