Man kann das "you [should]" sowohl mit "man" als auch mit "du/Sie" übersetzen. Das englische "one" ist zwar eine recht direkte Übersetzung von "man", wird aber nicht sehr oft verwendet und klingt anders als das deutsche "man" etwas gestelzt. Ich bin aber kein englischer Muttersprachler - Kritik und Korrekturen sind mir willkommen.

Ich möchte auch erwähnen, dass man in englischen juristisch angehauchten Texten manchmal Konstruktionen verwendet, die auf mich als deutschsprachigen wie ein Konjunktiv wirken, obwohl es keiner ist. Etwa: "This device may not cause harmful interference" statt "... must not ..."

(Auszug aus den FCC-Rules Part 15, http://www.fcc.gov)

als statist der sich mit der erstellung von dokumenten beschaeftigt .. darf ich dir erst einmal sagen .. dass in handbuechern die direkte ansprache sehr verbreitet ist .. allein schon um sicher zu stellen .. dass klar ist WER welche tätigkeit ausfuehren soll (Gedankenspiel: wenn dort man stehen wuerde .. wuerdest du sicher nachdenken wer damit gemeint ist .. dann auf dich schliessen und dann .. dinge tun .. und genau das wird durch You / Sie abgekuerzt)

Ausserdem gibt es wundervolle buecher ueber technical writing .. und diese besagen ausdruecklich eine persoenliche anrede zu verwenden ..

Der Konjunktiv sollte darin ueberhaupt nicht vorkommen .. es sei den .. es gaebe möglichkeiten des betriebs die intressant sind .. aber sicherheitstechnisch ueberhaupt keine rolle spielen ..

unverstaendlich manuals fuehren in .us ja auch zu gerichtsstreitigkeiten .. und in .de zu erheblichen nachteilen im rahmen der produkthaftung ..

ich verwende in Handbüchern für dieses "you" entweder das unpersönliche deutsche "man", eine Befehlsform ohne Personalpronomen (.. um dies und das zu erreichen, bitte dies und das tun) oder eine Passivkonstruktion. Ich vermeide wenn möglich die persönliche Anrede in technischen Texten

Ich schreibe Bedienungsanleitungen personen- und handlungsorientiert, d.h. ich spreche die Person, die etwas tun oder lassen soll direkt an, also machen Sie dies, lassen Sie jenes. Daher auch im englischen "you" als Anrede.

Auch ich gehöre zur Fraktion der direkt ansprechenden.

Es ist - besonders bei ganz wichtigen Warnhinweisen - in meinen Augen ein Kunstfehler, wenn der Autor/die Autorin es den Lesern/Leserinnen überlässt draufzukommen, wer denn jetztn gemeint sein könnte. Allerdings kommt in meinen Handbüchern auch noch unser Kundendienst vor, so dass hier natürlich dringend Eindeutigkeit erforderlich ist.

Genau das ist bei mir auch der Fall. Und auch Passivkonstrukte vermeide ich so weit es geht. Aber da kocht ja jeder sein Süppchen :-)). Freut mich jedenfalls, hier auch gleichgesinnte aus der schreibenden Zunft zu finden :;-)

*lächel* aus sicherheitstechnischer sicht sind personenbezogene anweisungen eh ein muss .. bei kleinkram .. (rasierer etc) waere es fast egal .. insofern niemand bei gebrauch des geraetes einen schaden erleiden KANN.

passivkosntruktionen mag ich ueberhaupt nicht .. weil der lesende das im kopf eh ins aktiv wandeln muss .. um zu verstehen .. dass er der ausfuehrende sein wird .. und sollte das nicht ersichtlich sein aus dem text .. dann *autsch* :o)

hab leider nix literatur zu im kopf um mal was zum nachlesen anzubieten ..
aber ich werde mich mal kuemmern ..

Es geht in diesm Handbuch nicht um präzise Rollenverteilung, es ist eher eine algemeine Fesstellung, dass der Leser (oder wer auch immer) diese umd jenes machen soll, um zum Ziel zu kommen. Ich denke daher, dass "Man" hier passend ist, kann aber auch die anderen Argumente bei sicherheisrelevanten Themen verstehen.

Sie haben die folgenden Möglichkeiten:
-
-
-

Passive Sprachformen haben den Nachteil erst "uebersetzt" werden zu muessen.
Daher .. wenn es der Stil des Handbuchs nicht verhindert, empfehle ich direkte Sprache.

Es gehört hier zwar nur am Rande dazu, aber ich findes es wie Chris_791 (AT) schwierig mit diesen Formulierungen in englischen Verträgen.
The vendor should care for....

Für mich ist dann nie eindeutig, was davon man tun "MUSS" und was "SOLL". Gibt es da eine Hilfe?

@la.ktho

Wobei Du ja wohl eher schreiben würdest:
sie hab’en..die.... folgen den... möglich!!...keiten:

Als Benutzer von Handbüchern empfinde ich das Duzen, man liest es immer häufiger, stets als deplaziert, es sei denn, es handelt sich um Kinderspielzeug.

Ich bevorzuge den Stil:
wenn man auf den linken Knopf drückt, passiert das und das.

Schliesslich ist es gleichgültig, ob ich oder jemand anders das Gerät bedient.

Ich habe schon fast Probleme mit Windows vorgegebenen Directories My Computer, My Pictures, My Documents.

wieso Meine? Weder der PC ist meiner, noch das was auf der Festplatte ist. Alles gehört dem Arbeitgeber.

Duzen finde ich auch in der Regel deplaziert - aber unpersönliche Frmulierungen wie "es passiert" oder "man muss" oder gar "man sollte" sind auf jeden Fall eine Qualitätsminderung für technische Dokumente. Es gilt NICHT der an Universitäten übliche Duktus, wo unpersönlich formuliert wird, sondern generell wird der Leser persönlich angesprochen. Dabei ist es tatsächlich egal, wem das Gerät gehört, aber eine Anleitung wendet sich an den Anwender - und nur der wird eine solche Anleitung lesen (der Fall, dass sich jemand so langweilt, dass er ein Handbuch zum Vergnügen liest, obwohl er gar nichts mit dem Gerät machen will, kann getrost vernachlässigt werden).

duscholux .. dafuer haben wir ja auch eine ausbildung als technische redakteure ..

was du beschreibst ist ein referenzhandbuch .. wo nur der funktionsumfang erklaert wird .. bei oracle sind dass schon ein par hundert seiten ..
aber in diesen handbuechern kannst du auch nicht lesen wie du probleme loesen kannst .. es werden dir nur die funktionen vorgestellt ..

bei z.b. MAN stellt man grosse schiffmotoren her .. die durchaus auch als lokale ernergieerzeuger verbaut werden .. an dieser stelle fordern gesetz und auch der kaeufer .. dass das personal genau weiss wie die wartung vor ort durchzufuehren ist .. es darf dort keine zweideutigkeiten oder missverstaendlichkeiten geben ..

*gg* schon mal die schaufel des turbolader gesehen .. die sich im betrieb aus dem gehaeuse einer maschine bewegt? *ggg*

Interessante Diskussion. Ich schreibe seit Jahren Bentzerdokumentationen für Software. Am Anfang wars recht technisch und ich habe den Benutzer nicht herumkommandiert, d.h. ich schrieb im Passiv. Da nun praktisch alle Dokus im Passiv sind (immerhin ein paar tausend Seiten) wirds immer schwieriger, den Stil zu ändern -- und genau das wäre Momentan sinnvoll, denn die Sätze werden schon extrem schwerfällig im Passiv. Je komplizierter ein Sachverhalt wird, desto mehr Vorteile hat ein möglichst direkter Stil. Darum würde ich den Benutzer mit "You" ansprechen; im Deutschen dann mit "Sie", oder "Du" (Verzeihung doscholux, aber viele Leute stören sich nicht wirklich an der "Verduisierung" im Deutschen; die Diskussion hat ihre Berechtigung, gehört jedoch nicht hierher).

Vorteil der "aktiven" Beschreibung ist ja auch, dass man eine Handlung bequem in kleine Häppchen unterteilen kann und so einzelne Funktionsschritte kurz und verständlich darstellen kann. Mit Blickfangpunkten oder einer Nummerierung versehen, kann der Kunde dann (fast) nichts mehr falsch machen. Ich schreibe auch Softwarehandbücher und wende diese Technik schon lange an.

@b1o: In manchen Fällen schreiben ich in solchen Fällen ein "Buch im Buch", dann wirkt der Stilwechsel nämlich nicht so, als sei er vom Himmel gefallen. Ich schreiben z.B. im Passiv, was der Benutzer tun und lassen könnte/sollte und dann:

"Weitere Informationen und ein kommentiertes Beispiel ('walk through' *g*) finden sich im nachfolgenden Abschnitt/im Kasten ab Seite xxx/..."

In diesem "Kasten" schreibe ich dann im Stil eines "Klicken Sie jetzt hier, dann da, dann wieder hier"-Tutorials

*smile* Markus .. das meinte ich mit

Referenzhandbuch .. wo man Funkttionen vorstellt .. aber nicht detailliert ueber ihre Benutzung eingeht .. und

Bedienanleitung .. wo detailliert auf die ausfuehrung von Bedienungen eingegangen wird .. und die Möglichkeiten ueberhaupt nicht erklaert werden

Softwaredoku und Maschinenbaudoku sind natuerlich etwas vollkommen verschiedenes :o) ..

Sehr intressant finde ich zum Beispiel Information Mapping .. wo es verschiedene Informationstypen mit verschienden Anwendungarten gibt ..
wenn man sich an dieses System haelt sieht das handbuch leider sehr eintoenig aus .. allerdings ist die verstaendlichkeit fuer mich schon fast unschlagbar .. speziell bei sehr komplexen Sachverhalten ..

und .. ich bin absoluter Gegner der Möglichkeiten :) .. um ein klares Anwendungbeispiel zu erklaeren .. zeige ich nur einen weg auf .. auch wenn mehrere möglich waere .. (eigentlich schon fehler der benutzerfuehrung waehrend der Programmierung ) .. es reicht meiner meinung nach vollkommen aus wenn der Anwender sehr gut zum Ziel gefuehrt wird .. alternative Wege die keine Vorteile bieten .. sondern nur andere Weg verwirren zu sehr ..

@lala: Die Unterscheidung ist mir durchaus klar, ich wollte aufzeigen, dass man (in vielen Fällen) beides mischen kann. Ich habe schon einige Referenzhandbücher gesehen (und ein, zwei selbst geschrieben) bei denen in einem Kasten oder am Ende des Kapitels ein "How do I ...?"- oder "Problems and Solutions"-Abschnitt angefügt war - und aus Benutzer(Leser-)sicht muss ich sagen, das gefällt mir, weil es mir Arbeit abnimmt und mir das Leben leichter macht.

Markus .. klar .. wenn deine Hauptaufgabe vorallem daran besteht die Funktionen des Programmes zu erklaeren .. ich kenn leider SAP-Doku nicht ..
aber ich wuerde zweifeln .. dass du dort mit einem Referenzhandbuch und den Bedienhinweisen am Kapitelende weit kommst :o)

Aber auch egal wie du es machst .. das einzige was zaehlt .. ist das der Kunde das versteht ..was er benoetigt ..

ein ganz komisch albern geschriebenes XML-FO Buch .. war trotz und vorallem durch seine alberne schreibweise so verstaendlich .. dass es rcithigspass gemacht hat sich durch die specs zu quaelen ..

aber .. der hat auch permanent geduzt .. und dich dabei noch verarscht *gg*

@ Markus: Der "Buch im Buch" Vorschlag ist gut. Ich hatte mal sowas im Kopf, hab' mich aber nicht getraut (da ich Stilbruch etwa gleich schlimm finde wie Schwerfälligkeit). Werde aber das aber nochmal durchdenken.

@ lala: Das ist wohl eigentlich der Traum eines jeden Doku-Schreibers, dass seine Ausführungen gelesen und erst noch für spannend empfunden werden. Leider sind nicht alle Leser Programmierer (du selbst hast ja SAP erwähnt...) und bei Kreditsachbearbeiter, die ein neues Programm vorgesetzt bekommen, wirkt wohl verarschen eher kontraproduktiv (obwohl, das würde ich gerne mal ausprobieren: Starten sie das Programm und drücken Sie Alt-F4...) Naja, eine Auflockerung des Stils würde wahrscheinlich ganz allgemein nicht schaden, obwohl mir duscholux wahrscheinlich widerspricht...

@ alle: Lustig, wie schnell man bei Leo "Leidensgenossen" mit Sachverstand in einem doch eher vernachlässigten Bereich (Dokumentation) beisammen hat.

*laaaach .. du unausprechlicher :)

ich denke es waere nicht mal ein problem ein sehr lustiges handbuch zu schreiben .. das sehr hunorvoll die dinge erklaert .. wenn am ende noch eine gute zusammenfassung steht .. die die informationen nochmals gut und uebersichtlich anordnet ..

kennst du information mapping (da muss noch nen (c) dahinter *gg*)
wie gesagt recht eintoenig .. aber extrem gut strukturierte informationen ..
und vorallem bei umfangreichen dokumentationen kann man dadurch inhalte noch ueberfliegen und die wichtigen stellen auffinden und lesen ..

ich arbeite im mom fuer eine groesssere firma die beeindruckt ist ..
wie verstaendlich auf einmal alle dinge sein koennen ..
dabei frag ich mich immer ob eine hausfrau mit entsprechendem ordnungssinn nicht zum gleichen ergebnis kaeme ..

Das Hauptproblem ist wohl, dass salopp formulierte Dokus eher als unprofessionell angesehen werden, obwohl sie durchaus verständlicher sind und vielleicht sogar unterhaltend sein können. Aber wenn ich anfangen würde, kleine Gimmicks mit einzubauen, hätte ich ziemlich schnell den Lektor am Hacken oder den Cheffe. Aber reizend wäre es schon mal, eine Art Ulk-Doku zu erstellen....

Nachtrag: wenn ich mir das für bestimmte Produkte vorstelle, überkommt mich ein fettes Grinsen :-)

ich werd mal das betreffende buch heraussuchen lassen .. und bei interesse ggf mal rundsenden lassen .. es ist auf jeden fall sehr intressant ..

und selbstverstaendlich heulen lektor und cheffe bei sowas rum ..
allerdings ist meine auffassung einer guten doku simple ..
sie muss dem leser viel bringen . und weiterhelfen .. wenn noetig ..

und sleipnir .. *laechel* .. du musst keine ulkdokus schreiben ..
ich schlag vor dich im maschinenbaubereich mal umzuschauen ..
dort findest du alles was es zu einer ulk brauchst ..

ein freund hat grad dokus in ein redaktionssystem eingepflegt ..
und das resultat ist .. dass er dokus fand .. und sie nem koellegen zum ausprobieren gab ..
der wunderte sich nicht schlecht als er feststellte ..
dass die doku nicht mit der genanten maschine zu tun hatte ..
bzw eine wartungsanleitung ganz sicher mit lethaler tinte geschrieben wurde ..
oder wer koennte schon 600kg abfangen ..
weil er laut doku zuerst die falschen schrauben loest :o)

*grins*, jaja, es gibt da die herrlichsten Sachen.....muss man nur aufpassen, dass man selber nicht auch mal einen Bock schiesst...

im rahmen einer doku erstellung wurde eine gefahrenanalyse nach din en 1050 durchgefuehrt .. sie fuehrte zur feststellung .. dass eine person in einen weichbehaelter von 36m durchmesser und 4m hoehe fallen koennte .. der dann mit wasser und eingeweichten pflanzenstoffen gefuellt sein wuerde ..

im weichbehaehaelter laeuft eine 39 m lange und ??t schwere schneckewelle um .. die den inhalt des weichbehaelters in bewegung haelt

frage des ingenieurs dann:

muss da ein notausschalter rein .. oder koennte das opfer nicht bis zum ende der schicht (8h:) vor der schnecke davon rennen?

Das Grundproblem ist doch, dass deutsche Ingenieure an ihren TUs manches lernt haben, aber keinesfalls schreiben.

dafuer beherrschen ja redakteure interviewtechniken ..

auweia, auch so ein Thema: da wil der Ingenieur sein ganzen Wissen loswerden, aber die eigentliche Frage doch partout nicht beantworten. Aber ich lass ihn nicht los hehe...

@Pachulke: das ist für mich kein Problem, sondern meine ökologisch-ökonomische Nische :-)

He, jetzt muss ich aber protestieren: nicht alle Ingeneure können nicht schreiben. Bin selber Elektroingenieurin und habe mein Sprachtalent dann in diesem Beruf (Technische Redaktion) eingebracht.

Und was die "häppchenweise" Darbietung angeht: Die dient auch dem Profi, der ganz schnell mal den einzigen Schritt, den er nicht mehr auswendig kann, raussuchen möchte.

Karin H. .. nichts schreibt sich schneller .. als ein Vorurteil.
Als technischer Redakteur wirst du sicher aber auch genug mit ingenieuren zu tun haben, die bitte gegenueber jeglichen externen besser den Mund halten sollten.

Wie sleipnir schon sagte, ist das ja unser Job:o) und persoenlich fuer mich ist es nicht verwunderlich, da der Schwerpunkt zumindest in weiten Teilen auf gaenzlichen anderen Gebieten liegt und ohne Training im Schreiben auch einfach Grundlagen fehlen.

Karin .. DU bist die Ausnahme :o)

Da protestiere ich auch gleich mit. Ich bin selber Ingenieur (und außerdem noch Mathematiker) und glaube schon, dass ich gute Texte schreiben kann.

Der Ingenieur, der keinen korrekten Satz zustande bringt, und der Germanist (oder Anglist), der nicht bis drei zählen kann: das sind doch bitteschön Klischees.

Chris nicht boese sein ..
aber ich habe schon viiiele kunden kennengelernt ..
die deinem sogenannten klischee entsprechen ..

allerdings kenne ich auch physiker mit denen man sich stundenlang sehr kommunikativ unterhalten kann ..

@ lala: Hab' mir mal das Information Mapping (r)(TM)(c) System angeschaut. Nicht übel, aber jetzt so auf die Schnelle hab' ich auch keine bahnbrechend Neue Methode entdeckt. Ich meine, es ist klar, dass eine bessere Darstellung das Verständnis fördert.
Muss auch noch sagen, dass mir Information Mapping primär für lineare Zusammenhänge geeignet erscheint, häufig ist aber das Zeugs ziemlich vernetzt (dürfte auch im Maschinenbau so sein), darum sind auch Online-Helps eine gute Sache. Ebenso die Mind Maps (muss jetzt hier auch ein (c) hin?)

Anyway, danke für den Tip.

P.S. Bin eigentlich Wissenschaftler und Ingenieur (merkt man vielleicht am unothodoxen Schreibstil, vielleicht auch nicht) und habe von objektiver Seite erfahren, dass meine Ausführungen gegenüber der einer ausgebildeten Redaktorin (und promovierten Germanistin) zwar etwas schwerfälliger, dafür strukturiert, korrekt und durchdacht sind...(und viel zu viele Klammern enthalten :)
Dies einfach so als Beitrag zur Diskussion über schreibende Ingenieure

@lala: natürlich bin ich dir nicht böse! Danke für die Aufnahme in deine Positiv-Liste!

Mein Bruder ist übrigens Physiker und man kann sich sehr gut mit ihm stundenlang auf sprachlich hohem Niveau unterhalten. Mit meiner Schwester übrigens auch - aber da sie Anglistin ist, erwartet man sich das. Darüber hinaus ist sie durchaus naturwissenschaftlich begabt ;-)

eine typische ingeneurskrankheit .. oder eben nur sehr weit verbreitet ist..

ich kann alles machen .. dir aber nicht sagen wie es funktioniert

richtig schlimm wird es .. wenn du ihnen alles aus der nase ziehen musst .. und trotz minutenlanger verstaendlicher erklaerungen zu deinem vorhaben .. sich imgesicht den ing sich immer noch unverstaendnis abzeichnet ..

natuerlich gibt es auch gegenteilige beispiele .. aber .. wen wunderts .. dir fallen nur die besonders doofen noch nach jahren ein :o)

aber natuerlich habe ich als technischer redakteur auch viel von ingenieuren lernen muessen .. und da hab ich dann defintiv sehr gute ingenieure gehabt .. damit das klappt :o)