Bedienungsanleitung — Industrie-Benchmark & ehrliche Selbstkritik

Erstellt: 2026-05-07 · Reviewer: Claude (eigene Sicht + Industrie-Vergleich) Software-Stand: SARmission v4.0.0 Handbuch-Stand: v4.0.0 (docs/MANUAL.de.md, 2.690 Zeilen, 24 Screenshots, nach P0+P1)

Anlass: „Lese das Handbuch kritisch durch und mache dir ein Bild wie du findest. Recherchiere danach im Internet wie ein professionelles Software-Handbuch auszusehen hat und vergleiche deine Auswertung mit anderen Software-Handbüchern."

Disclaimer & Selbstkritik-Pflicht: Ich habe P0+P1 selbst angelegt (§ 0 Hintergrund, Glossar, §§ 36-41, Screenshots). Diese Lektüre kritisiert daher auch eigene Arbeit. Ich versuche das ehrlich zu halten — nicht zu wohlwollend, nicht zu hart.

---

Teil A — Eigene Lektüre (vor Industrie-Benchmark, ungebrieft)

Ich habe das Manual durchgelesen und nach Eindrücken sortiert, ohne mich an einen Bewertungsrahmen zu binden. Was mir auffiel:

A.1 Was sehr gut ist

#	Beobachtung
A.1.1	Inhaltliche Tiefe — POA/POD-Mathematik, Crypto, DSGVO werden in einer Schärfe erklärt, die in OSS-Manuals selten ist
A.1.2	Tabellen-Dichte — Schwellwerte, Wetter-Faktoren, KDF-Versionen, Tactical-Signs — alles tabellarisch und scannbar
A.1.3	Cross-Refs funktionieren technisch — [§ 5.4](#54-...) rendert in HTML korrekt
A.1.4	Praxis-Boxen mit > Blockquotes geben dem Manual eine persönliche Note („Praxis: Vor dem Druck Karte zoomen…")
A.1.5	Glossar ist umfassend (60+ Begriffe nach P0) und alphabetisch sortiert
A.1.6	24 Screenshots, davon zentrale UI-Elemente alle abgedeckt
A.1.7	Versionshistorie mit Datum + Highlights — gibt einen Überblick über die Reife
A.1.8	Kontext-Hinweise „ab v3.7.0" / „neu in v4.0.0" — orientiert sich an Versions-Timeline

A.2 Was mir Sorgen bereitet

Hier die Liste, sortiert nach Schwere für die Lese-Erfahrung. Jeder Punkt mit konkretem Beispiel:

A.2.1 Gemischte Inhaltstypen in derselben Sektion (zentralster Punkt)

§ 7 „Suchgebiete mit POD/POA-Priorisierung" tut vier Dinge gleichzeitig: - 7.1 Liste & Karte → Reference (UI-Beschreibung) - 7.2 POA-Initialverteilung → Explanation (Konzept) - 7.3 Gebiet abschließen mit POD-Eintrag → How-to mit eingebettetem Bayes-Update-Code (Reference + Explanation) - 7.4 Ranking → Explanation - 7.5 Farbe, Einheit, Vertex-Edit → How-to - 7.6 Waldgebiete vorschlagen → How-to

Folge: Wer „Wie schließe ich ein Gebiet ab?" sucht, bekommt erst die Mathematik. Wer die Mathematik verstehen will, findet sie nicht, weil sie als Beiwerk im How-to-Schritt steht.

Dasselbe Problem in § 9 (Vermisstenverhalten — Koester-Tabelle in Reference + IPP-Setzen in How-to + „Hinweis: Heuristik, keine Prognose" in Explanation), § 18 (Live-Sync — How-to + Crypto-Background + mDNS-Implementation-Detail), § 31 (Encryption — Reference + Explanation + How-to).

Diese Vermischung ist der größte Lese-Hindernis.

A.2.2 Inkonsistente Anrede

Im selben Manual: - „Klicke auf der Karte" (du-Imperativ) - „Klick öffnet das Detail-Formular" (3. Person, beschreibend) - „Die EL muss eine Entscheidung treffen" (3. Person Singular) - „Sie sollten zuerst Wetter abrufen" (Sie-Form)

Verteilung sehr unsystematisch — wirkt, als hätten verschiedene Autoren Sektionen geschrieben. Tatsächlich Single-Maintainer-Drift über 4 Jahre.

A.2.3 Installation nur für macOS detailliert beschrieben

§ 2.1 hat 3 Schritte für macOS (DMG → Programme → Doppelklick). § 2.2 hat nur 2 Zeilen für PWA. Windows fehlt komplett, Linux fehlt komplett, Mobile (iOS Testflight, Android Play) wird nur in § 34.3 gestreift. Auf einer Mehr-Plattform-Software ein offensichtliches Loch.

A.2.4 „Erste 10 Minuten — Hands-on" fehlt

Das neue § 0 (Hintergrund) ist konzeptionell, nicht praktisch. Es gibt keine geführte Tutorial-Sequenz: „Öffne die App → klicke auf Action-Bar → zeichne ein Polygon → setze IPP → fertig."

Stattdessen muss der Leser durch §§ 4-9 traversieren und mental zusammensetzen, was die einzelnen Operationen bedeuten.

Der Quick-Start (docs/QUICK-START.md, separat) ist nicht ins Manual eingebunden und wurde nicht für v4.0.0 aktualisiert.

A.2.5 Bayes-Code-Block in § 7.3 ist mathematisch, nicht praktisch

Aktuell:

POA_neu(Gebiet_geschlossen) = POA_alt × (1 − POD/100)

Das ist eine Formel. Eine durchgerechnete Beispiel-Sequenz wäre 10× hilfreicher:

Beispiel: 4 Gebiete, jedes initial 25 % POA. Sektor A wird mit POD 70 % abgesucht (FL-Hund Standard). POA(A) = 25 % × 0.30 = 7.5 % POA(B,C,D) bleiben absolut bei 25 %. Total-POA = 82.5 %. Differenz von 17.5 % zu 100 % = die Wahrscheinlichkeit, dass die Person bereits gefunden wurde oder nie in den Gebieten war.

Konkrete Zahlen schlagen abstrakte Formeln in Operativ-Doku.

A.2.6 Image-Alt-Text zu spärlich

![Topbar mit allen Buttons](manual/screens/01-overview.png)

Alt-Text reicht für Screenreader nicht — sollte beschreiben, was im Bild zu sehen ist:

![Hauptansicht mit Topbar links (Logo, Einsatzleiter-Feld, Datum,
Einsatz-Nr.), Karten-Bereich Mitte, Tool-Rail rechts (9 Werkzeuge),
Action-Bar unten (Einheit, POI, Funkspruch, Drucken).](manual/screens/01-overview.png)

Plus: Kein Figure-Caption-System. Das <figure><img><figcaption>-Idiom fehlt.

A.2.7 Same Screenshot referenced twice

01-overview.png taucht in § 2.3 (Erststart-Check) und § 3.2 (Topbar Detail) auf — dasselbe Bild, beide Male voll eingebettet. Sollte einmal mit Anker referenziert werden.

A.2.8 § 3 Subsections out of order

3.1 Haupt-Tabs in der Sidebar
3.2 Topbar (Detail)
3.4 Action-Bar  ← out of order
3.3 Tool-Rail   ← out of order

Trivial-Bug, aber stört bei der Orientierung.

A.2.9 Versionshistorie ist Listen-Tabelle, kein „What's New"

§ 42 listet Versionen tabellarisch:

| v3.10.0 | 2026-05 | Tactical Signs DV-101, Mission-Timer, ... |

Aber kein per-Version-Walkthrough mit „Hier sind die 3 wichtigsten Änderungen in v4.0.0 für Sie als Einsatzleiter:". Das wäre für Power-User wesentlich nützlicher.

A.2.10 Praxis-Boxen ohne einheitliches Icon-System

Verwendet: - > **Praxis-Tipp:** - > **Tipp:** - > **Hinweis:** - > **⚠️ Wichtig:** - > **Praxis:**

Keine konsistente Konvention, welcher Marker für welche Art von Box. Eine MDN-Web-Docs-style Konvention (Note / Warning / Caution / Tip mit festen Farb-Codes) würde das vereinheitlichen.

A.2.11 Code-Format-Konvention für UI-Elemente uneinheitlich

Im selben Absatz: - „klicke auf Einheit hinzufügen" (bold) - „klicke auf Speichern" (code) - „klicke auf 'Pause anordnen'" (single quotes) - „klicke auf „Löschen"" (typografische Anführungszeichen)

Das ist Editor-Wildwuchs. Eine einheitliche Konvention (z. B. immer bold für Buttons, code für Pfade/Identifier) fehlt.

A.2.12 Kein Persona-/Rollen-Index am Anfang

Das Manual ist linear. Eine ELW-Disponentin braucht andere Kapitel als ein Hundeführer. Ein Persona-Mapping wie:

Wenn Sie … sind, lesen Sie zuerst: - Einsatzleiter:in → §§ 0, 4, 5, 7, 18, 36, 37 - Hundeführer:in → §§ 0, 5, 9, 35 - Funkwart → §§ 0, 13, 18 - ELW-Disponent:in (HiOrg-extern) → §§ 0, 36, Anhang B - Datenschutzbeauftragte:r → §§ 30-33, Anhang A (DSGVO-Begriffe)

…fehlt aktuell.

A.2.13 Kein Suchindex / kein Page-Index

Bei 2.690 Zeilen brauche ich Suche. Glossar deckt nur Begriffe ab, kein Feature-Index. „Wo wird ‚Briefing-Druck' beschrieben?" — keine Index-Suche möglich, nur Volltext-Search im PDF.

A.2.14 Kein „Cheat-Sheet" / Quick-Reference-Card

Nach allen 42 Sektionen: keine 1-Seiten-Übersicht der häufigsten Aktionen („Einsatz starten / IPP setzen / Suchgebiet zeichnen / Einheit anlegen"). § 21 (Tastaturkürzel) ist nahe dran, aber nicht workflow-orientiert.

A.2.15 Inkonsistente Gender-Inklusivität

• „Einsatzleitung" (geschlechtsneutral)
• „Hundeführer:in" (Doppelpunkt-Genus, modern)
• „Hundeführer" (generisches Maskulinum)
• „Person mit Hund" (Umschreibung)

Einheitlicher Stil wäre erforderlich. Empfehlung im deutschen Behörden-Kontext: Doppelpunkt-Genus durchgängig.

A.2.16 Keine Accessibility-Sektion

• Gibt es Keyboard-only-Bedienpfade?
• Funktioniert die App mit Screenreadern?
• Welche Color-Contrast-Levels werden eingehalten?
• Sind Statuswechsel auch ohne Farbe erkennbar (für Farbenblinde)?

Eine § A11y wäre für eine BOS-Software, die auch ältere/sehschwache Hundeführer:innen bedienen können soll, eine Pflicht.

A.2.17 Keine Internationalisierung erwähnt

Das Manual ist nur Deutsch. Englische Version (MANUAL.en.md) existiert nicht. Bei einer Software, die zukünftig DACH-weit oder ggf. EU-weit ausgerollt werden soll (siehe Marketing-Strategie Phase 3 „DACH-Expansion"), ein offenes Loch.

A.2.18 § 18 Live-Sync ist zu technisch für Endnutzer

Yjs-CRDT, WebRTC-UDP, y-websocket-Relay, mDNS-Discovery, Peer-Cursor — das ist Implementierungs-Detail, das in einem Architektur-Dokument gehört, nicht ins User-Manual. Endnutzer-Frage: „Wie teile ich Daten mit meiner Kollegin?" Antwort sollte 4 Schritte lang sein, nicht 90 Zeilen.

A.2.19 Keine „Limitations" / „Bekannte Grenzen"-Sektion

Realistische Software hat Grenzen. Z. B.: - Live-Sync hat Latenz von ~500 ms im LAN, ~2 s über WebRTC-Internet - POI-Anzahl-Begrenzung bei ~500 ist visuell unübersichtlich - Karten-Tile-Cache füllt die Festplatte bei großen Regionen - iOS-PWA hat Bluetooth-GPS-Limitations

Solche „Caveats" gehören in eine Limitations-Sektion — schafft Vertrauen, weil ehrlich.

A.2.20 Keine „Daten-Schema"-Doku

Was steht eigentlich in der .rhs-Datei? Welche Felder hat ein Suchgebiet? Wie werden GPS-Tracks gespeichert? Für Power-User, die externe Auswertungen machen wollen, ein offenes Loch. Das format: 'rhs-einsatz-v1'-Schema müsste dokumentiert sein.

A.2.21 Glossar definiert, verlinkt aber nicht zurück

Im Glossar steht „IPP — siehe § 9.2". Im Body verwendet § 4.1 oder § 7 das Wort „IPP" ohne Glossar-Link. Inverse-Verlinkung fehlt.

A.2.22 Footnotes / Quellenangaben fehlen

POD-Werte sind „NASAR Managing Search Operations" — keine genaue Edition / Jahreszahl / ISBN. Koester-Daten „Lost Person Behavior 2008" — korrekt, aber kein DOI / ISBN. Für Versicherungs-Dokumentation und externe Audits müssten genaue Quellen referenziert sein.

A.2.23 Lange Sätze in Crypto-Sektionen

§ 31.4 hat:

„Modus B — Master-Passphrase (opt-in, ab v3.7.0): sar-passphrase-key.bin enthält den per User-Passphrase ge-AES-GCM-wrappten Master-Key. Schutz greift auch im laufenden User-Account (siehe [§ 32]…)."

Das ist 2 Sätze + 4 Kommas mit 7 Fachbegriffen. Erste-Mal-Leser:in gibt auf.

A.2.24 Keine Audio-Visual-Begleitmaterialien referenziert

In 2026 sind Video-Tutorials State-of-the-Art. Das Demo-Video-Drehbuch existiert (docs/marketing/demo-video-drehbuch.md), aber das Manual referenziert es nicht („Siehe das 22-Min-Demo-Video für eine durchgespielte Sequenz.").

A.2.25 Footer-Stand „v3.8.0" wurde geändert auf „v4.0.0", aber Bestandsaufnahme prüft das nicht

Aktuell sehe ich „Stand: SARmission v4.0.0 (2026-05-06)." — gut. Aber es gibt keine automatische Konsistenz-Prüfung zwischen Footer-Stand, Header-Stand, Versionshistorie und CHANGELOG.

---

Teil B — Industrie-Standards (Recherche)

B.1 Diátaxis-Framework (Daniele Procida, Canonical)

Kernidee: Vier orthogonale Dokumentations-Typen, die niemals gemischt werden sollten.

              ACTION
                │
   ┌────────────┼────────────┐
   │            │            │
TUTORIAL    │ HOW-TO       │
(lernen)    │ (Problem     │
            │  lösen)      │
ACQUISITION ┼ ──────────── ┼ APPLICATION
            │              │
EXPLANATION │ REFERENCE    │
(verstehen) │ (nachschlagen)│
            │              │
   └────────────┼────────────┘
                │
            COGNITION

Typ	Zweck	Adressiert
Tutorial	Lernen durch Tun	Anfänger:innen
How-to-Guide	Konkretes Problem lösen	Kompetente Nutzer:innen
Reference	Faktisches Nachschlagen	Alle
Explanation	Hintergrund verstehen	Vertiefung

Kritischer Befund: „Crossing or blurring the boundaries described in the map is at the heart of a vast number of problems in documentation."

B.2 IEEE 1063 / ISO/IEC/IEEE 26514

Internationale Norm für Software-User-Dokumentation. Pflicht-Komponenten:

1. Audience identification
2. Conceptual information
3. Instructional information (Tasks)
4. Reference information
5. Troubleshooting
6. Error messages
7. Glossary
8. Modular information design
9. Information for users with disabilities (Accessibility)
10. Internationalization considerations

B.3 Google Developer Documentation Style Guide

Die 15 Top-Highlights:

1. Conversational, friendly tone
2. Active voice
3. Second person ("you")
4. Accessibility focus
5. Global audience
6. No future announcements (kein „kommt in v5.0")
7. Descriptive link text
8. Sentence case for headings
9. Structured lists (numbered/bulleted/description)
10. Code formatting
11. UI elements bold
12. Serial comma
13. Unambiguous dates (ISO 8601)
14. Alt text for images
15. High-resolution images

B.4 Microsoft Writing Style Guide

Komplementär zu Google: stärker Customer-Centric, „crisp, clear, warm, relaxed". Empfiehlt einfache Grammatik + technisches Vokabular nur, wenn nötig.

B.5 Stripe / Linear / Notion — moderne SaaS-Docs

Stripe-Pattern (vorbildhaft im B2B-SaaS-Bereich): - Task-orientierte Landing-Page (Use Cases statt Feature-Liste) - Quick-Start-Pathways ("Sell subscriptions", "Accept payments") - Reale Szenarien zuerst, technische Details nachgeordnet - Suche & Index prominent - Live-Code-Examples (interaktiv) - Versions-Switcher (API v2024-04-01, v2024-09-15 …) - Dark Mode + Light Mode beide - Persona-Pfade (Developer / Operator / Manager)

B.6 Personas + User-Journey-Mapping

Modern (2026) Standard: - Multiple Personen-Profile am Doku-Anfang - Pro Persona: erwartete Aufgaben + Pfad-Empfehlung - Journey-Map: Wo bouncet ein Nutzer? Wo bleibt er hängen? - Persona-bezogene Inhalts-Filter

---

Teil C — Benchmark-Tabellen

C.1 Diátaxis-Test je Sektion

§	Titel	Ist-Typ	Soll-Typ	Verstoß?
0	Hintergrund	Explanation	Explanation	✅ sauber
1	Was SARmission ist	Explanation	Explanation	✅
2	Installation	How-to	How-to	✅
3	Bedienoberfläche	Reference + Explanation	Reference	⚠️ leichte Mischung
4	Einsatzführung	How-to + Reference	How-to	⚠️
5	Einheitenverwaltung	How-to + Reference + Explanation	How-to	❌ stark gemischt
6	Karten-Werkzeuge	How-to	How-to	✅
7	Suchgebiete POD/POA	alle 4 Typen	How-to + Explanation getrennt	❌ kritischer Verstoß
8	POIs	How-to	How-to	✅
9	Vermisstenverhalten	Reference (Koester) + How-to	Reference + How-to getrennt	❌
10	Wetter	How-to + Reference	How-to	⚠️
11	UTM	Reference + How-to	Reference + How-to	⚠️ Trennung nötig
13	Tagebuch	How-to	How-to	✅
14	Import/Export	How-to + Reference	How-to	⚠️
18	Live-Sync	alle 4 Typen	How-to + Explanation getrennt	❌ kritischer Verstoß
21	Tastaturkürzel	Reference	Reference	✅
22	Dateispeicherorte	Reference	Reference	✅
23	FAQ	Troubleshooting	Troubleshooting	✅
24	POD-Slip	Reference	Reference	✅
30-33	DSGVO-Pack	How-to + Explanation + Reference	nach Typ trennen	❌
36	Tactical Signs	How-to + Reference	How-to + Reference	⚠️ leichte Mischung
37	Hundewohl	Explanation + How-to + Reference	nach Typ trennen	❌
42	Versionshistorie	Reference	Reference	✅
Anhang A	Glossar	Reference	Reference	✅
Anhang B	HiOrgs	Reference	Reference	✅
Anhang C	Wartung	How-to (für Maintainer)	How-to	✅

Diátaxis-Score: - ✅ 11 Sektionen sauber - ⚠️ 7 Sektionen leicht gemischt - ❌ 5 Sektionen stark gemischt (kritisch)

Verdict: SARmission folgt nicht dem Diátaxis-Framework. Es ist eher ein klassisches User-Manual nach IBM-1985-Stil: feature- zentriert mit eingestreuten Erklärungen.

C.2 IEEE 26514-Pflicht-Komponenten-Test

Komponente	Status
Audience identification	✅ (Header v2 nach P0)
Conceptual information	✅ (§ 0 + § 9 + § 18 + § 31)
Instructional information	✅ (§§ 4-19)
Reference information	✅ (§§ 21, 22, 24, Glossar)
Troubleshooting	✅ (§ 23 FAQ)
Error messages	⚠️ (verstreut, keine eigene Sektion)
Glossary	✅ (Anhang A nach P0)
Modular information design	❌ (siehe Diátaxis-Verstöße)
Accessibility for users with disabilities	❌ (nicht adressiert)
Internationalization considerations	❌ (nur Deutsch)

IEEE-Score: 7 von 10 — gut, aber 3 strukturelle Lücken.

C.3 Google Style Guide Test

Highlight	SARmission	Note
1. Conversational, friendly	✅	Du-Form (de-DE)
2. Active voice	⚠️	Inkonsistent — passiv in vielen Beschreibungen
3. Second person	⚠️	Sometimes „du", sometimes „die EL", sometimes „Sie"
4. Accessibility focus	❌	Komplett ungeschrieben
5. Global audience	❌	Nur Deutsch
6. No future announcements	⚠️	„v5.x geplant" mehrmals — Standard-Verstoß
7. Descriptive link text	⚠️	„siehe § 5.4" ist okay, aber „klicke hier" wäre schlechter
8. Sentence case headings	✅	Mostly
9. Structured lists	✅	Tabellen + Bullets gut
10. Code formatting	⚠️	Inkonsistent (siehe A.2.11)
11. UI elements bold	⚠️	Mostly bold, aber gemischt
12. Serial comma (Oxford)	n/a (DE-Optional)	—
13. Unambiguous dates (ISO 8601)	✅	„2026-05-06" durchgängig
14. Alt text for images	⚠️	Vorhanden aber zu kurz (siehe A.2.6)
15. High-res images	✅	1600×1000 PNG

Google-Score: 6 ✅ / 7 ⚠️ / 2 ❌ — durchschnittlich.

C.4 Stripe-Style Modern Docs Test

Stripe-Pattern	SARmission
Task-orientierte Landing-Page	❌ Lineare TOC
Quick-Start-Pathways	❌ keine Persona-Pfade
Reale Szenarien zuerst	⚠️ § 0.5 hat 7-Schritt-Workflow
Suche & Index	❌ Glossar only
Live-Code-Examples	n/a (keine API)
Versions-Switcher	❌
Dark Mode	❌ statisches Markdown
Responsive	✅ HTML responsive
Persona-Pfade	❌
Per-Release Walkthrough	❌ nur Tabelle

Stripe-Score: 1 ✅ / 1 ⚠️ / 7 ❌ / 1 n/a — modernes SaaS-Docs- Idiom kaum erfüllt.

C.5 Persona-Test

Persona	Hat das Manual einen Pfad für sie?
Hundeführer:in (Anfänger)	⚠️ nur linear
Einsatzleiter:in (Power-User)	⚠️ nur linear
Funkwart	❌
Kartenführer:in (iPad-PWA)	⚠️ § 34, isoliert
ELW-Disponent:in (HiOrg-extern)	⚠️ nur § 0 + Anhang B
Datenschutzbeauftragte:r	⚠️ §§ 30-33, isoliert
Verein-Vorstand (Trägerschaft, Lizenz)	❌
Schulungs-Leiter:in (Multiplikator)	❌

Persona-Score: 0 von 8 echten Persona-Pfaden — alle landen linear in einem 2.690-Zeilen-Strom.

---

Teil D — Synthese: ehrliche Gesamt-Einschätzung

D.1 Was das Manual jetzt ist

Eine inhaltsreiche, fachlich sehr starke Operativ-Doku in klassischem User-Manual-Stil aus den 1990ern, mit modernen Elementen (Glossar, ELW-Persona im Header, Screenshots, Anhängen), aber strukturell nicht nach Diátaxis und nicht nach modernem SaaS-Docs-Idiom.

D.2 Lese-Erfahrung-Score (subjektiv, 1-10)

Aspekt	Score
Inhaltliche Tiefe	9
Fachliche Korrektheit	9
Vollständigkeit (alle Features)	9 (nach P0)
Aktualität (vs. v4.0.0)	9 (nach P0+P1)
Bildmaterial	8 (nach P1)
Tonalität-Konsistenz	5 ⚠️
Inhalts-Typ-Trennung (Diátaxis)	4 ❌
Persona-/Rollen-Navigation	3 ❌
Onboarding-Flow für Erstnutzer	5 ⚠️
Power-User-Cheat-Sheet	4 ❌
Accessibility-Awareness	2 ❌
Internationalisierung	2 ❌
Quellen-Belege (Referenzen)	5 ⚠️
Gesamt-Score	6 / 10

Zur Einordnung: - 6/10 ist deutlich überdurchschnittlich für OSS-Single-Maintainer- Doku (typisch: 2-4/10) - aber unter dem Niveau, das modernes B2B-SaaS-Onboarding-Doku erreicht (Stripe / Linear / Notion: 8-9/10)

D.3 Stärken-Schwächen-Profil

        Inhalt     ████████████████████░  9
   Aktualität     █████████████████████  9
        Bilder     ████████████████░░░░  8
     Tonalität     ███████████░░░░░░░░░  5
       Struktur    █████████░░░░░░░░░░░  4
      Personas    ███████░░░░░░░░░░░░░  3
       A11y/i18n   ████░░░░░░░░░░░░░░░░  2

Inhalt ist das Hauptasset, Struktur ist die Hauptschwäche.

D.4 Vergleich zu „Best in Class"-Manuals

Aspekt	SARmission	Stripe Docs	Notion Help	Linear Docs
Diátaxis-Sauberkeit	4/10	9/10	8/10	9/10
Persona-Pfade	3/10	9/10	8/10	8/10
Suche/Index	2/10	10/10	10/10	10/10
Versions-Switcher	0/10	10/10	6/10	7/10
Mobile Responsive	7/10	10/10	10/10	10/10
Dark Mode	0/10	10/10	10/10	10/10
Inhaltliche Tiefe (in Niche)	9/10	9/10	7/10	7/10
Multilingual	1/10	9/10	8/10	6/10

Wo SARmission Best in Class ist: Inhaltliche Tiefe in der K9-SAR-Niche — kein anderer Anbieter dokumentiert wetter-adaptive Hundewohl-Schwellwerte oder DV-101-Tactical-Signs auf diesem Niveau.

Wo SARmission unterhalb von Best in Class ist: Strukturelle Modernität (Diátaxis, Personas, Suche, Multi-Lingual, Dark Mode).

---

Teil E — Empfehlungen (priorisiert)

E.1 Iteration-3 — Diátaxis-Refactor (P2, ~5-7 Tage)

Maßnahme	Sektion	Aufwand
§ 7 splitten in: 7-A How-to + 7-B Reference (POD-Werte) + 7-C Explanation (Bayes)	§ 7	1 Tag
§ 9 splitten in: 9-A Reference (Koester-Tabelle) + 9-B How-to (IPP setzen) + 9-C Explanation (Methodik)	§ 9	0.5 Tag
§ 18 splitten in: 18-A How-to (Sync teilen) + 18-B Reference (Topologie) + 18-C Explanation (CRDT/Yjs)	§ 18	1 Tag
§ 31 splitten in: 31-A How-to (Encryption aktivieren) + 31-B Reference (Container-Format) + 31-C Explanation (Crypto-Architektur)	§ 31	0.5 Tag
§ 37 splitten in: 37-A How-to (F3 Modal bedienen) + 37-B Reference (Schwellwert-Tabellen) + 37-C Explanation (Hundewohl-Hintergrund)	§ 37	0.5 Tag
Tutorial-Sektion 㤠2.4 Erste 10 Minuten" anlegen mit Demo-Datei	neu	1 Tag

E.2 Iteration-3 — Persona-Pfade (P2, ~1 Tag)

Persona-Mapping-Box am Anfang (nach Inhaltsverzeichnis):

## Persona-Pfade — wo soll ich anfangen?

| Wenn Sie … sind | Lesen Sie zuerst | Dann |
|---|---|---|
| **Hundeführer:in** | § 0 → § 5 → § 9 | § 13, § 35 |
| **Einsatzleiter:in** | § 0 → § 4 → § 7 → § 36 → § 37 | §§ 16, 38 |
| **Funkwart** | § 0 → § 13 → § 18 | § 35 |
| **ELW-Disponent:in (extern)** | § 0 → Anhang B → § 36 | §§ 14, 16 |
| **Kartenführer:in (PWA)** | § 0 → § 34 → § 18 | §§ 6, 11 |
| **DSB / Datenschutz** | §§ 30-33 | Anhang A (Begriffe) |

E.3 Iteration-3 — Tonalität vereinheitlichen (P3, ~2 Tage)

• Anrede: Durchgängig „Sie" (Behörden-Standard) ODER durchgängig „du" (RHS-Vereinston). Empfehlung: „Sie" für formelles Manual, Quick-Start-Tutorial darf „du" verwenden.
• Imperativ: Durchgängig „Klicken Sie auf …" (nicht „Klick öffnet…")
• Gender: Durchgängig Doppelpunkt-Genus („Hundeführer:in")
• UI-Elemente: Immer fett, nie code-Format
• Pfade/Identifier: Immer code-Format
• Konvention dokumentieren im Anhang C oder neuen Anhang D

E.4 Iteration-3 — Strukturelle Lücken schließen (P2, ~3 Tage)

#	Maßnahme
1	§ 2 Installation um Windows + Linux + Mobile-Sub-Sektionen erweitern
2	Neuer § A11y „Barrierefreiheit" — Keyboard-Pfade, Screenreader, Color-Contrast
3	Neuer § Limitations „Bekannte Grenzen" — ehrlicher Caveats-Abschnitt
4	Neuer § Daten-Schema — .rhs-Format, GPS-Track-Format, KML-Konvention
5	Englische Version MANUAL.en.md (mindestens § 0 + § 36 + Glossar)
6	„Cheat-Sheet" / Quick-Reference-Card als 1-Seiten-PDF
7	Per-Release-Walkthrough für letzte 3 Major-Versionen (statt nur Tabelle)
8	Footnotes / Quellen-Belege (NASAR-ISBN, Koester-DOI)

E.5 Iteration-3 — Format-Konventions-System (P3, ~0.5 Tag)

Einführung eines konsistenten Callout-Box-Systems:

> **💡 Tipp:** … (Praxis-Empfehlung)
> **ℹ️ Hinweis:** … (Information)
> **⚠️ Achtung:** … (Vorsicht, kann schief gehen)
> **🚨 Warnung:** … (Daten-Verlust-Risiko)
> **🔧 Fortgeschritten:** … (Power-User-Funktion)
> **🌐 Hilfsorganisations-übergreifend:** … (HiOrg-Kontext)

Plus dokumentierte Style-Konvention in einem MANUAL-STYLE-GUIDE.md.

E.6 Iteration-4 — Modernes Docs-Site (P4, ~2 Wochen)

Statt Markdown → HTML → PDF: - Docusaurus oder MkDocs Material als Static-Site-Generator - Suche, Versions-Switcher, Dark Mode out-of-the-box - Persona-Filter via Tags - Live-Demo-Embeds (Sandboxed Karten-Widget, das man im Manual selbst manipuliert) - Hosted unter docs.sarmission.de

E.7 Empfehlungs-Score-Karte

Iteration	Aufwand	Score-Verbesserung
Aktuell (nach P0+P1)	—	6/10
+ Iteration 3 (E.1-E.5)	~12 Tage	7.5/10
+ Iteration 4 (E.6)	~12 + 14 Tage	9/10

---

Teil F — Reflexion: was ich an meiner eigenen Arbeit (P0+P1) bemerke

Da ich P0+P1 gemacht habe, hier ehrliche Selbstkritik:

F.1 Was ich gut gelöst habe

• § 0 Hintergrund ist solide für die Persona „Florian (ELW-Außensicht)"
• Glossar Anhang A ist umfassend
• Anhang C Wartungs-Prozess ist neuartig und nützlich
• Screenshots sind systematisch generiert via Playwright-Skript (reproduzierbar bei jedem Release)
• Bestandsaufnahme + Score-Karte sind ein gutes Tracking-Werkzeug

F.2 Was ich übersehen habe

• Diátaxis-Framework habe ich nicht angewandt — meine neuen Sektionen (§§ 36-41) mischen genauso wie die alten Inhalts-Typen
• Persona-Pfade habe ich erkannt aber nicht implementiert — nur in der Bestandsaufnahme erwähnt, nicht im Manual selbst
• Tonalität habe ich nicht vereinheitlicht — meine neuen Sektionen bringen wieder neue Anrede-Varianten („die EL" / „der Einsatzleiter" / „Sie")
• Accessibility wurde nicht berührt (nicht im Auftrag, aber Standard-Pflicht)
• § 0.7 „Was SARmission nicht ist" ist Wert, aber ein vergleichbarer „Bekannte Grenzen"-Abschnitt im Body fehlt
• Quellen-Belege (NASAR / Koester) habe ich übernommen ohne ISBN/DOI zu ergänzen

F.3 Was ich anders machen würde

Bei einem nächsten Durchgang würde ich:

1. Diátaxis als verbindliche Konvention voraussetzen — jede neue Sektion explizit in einem der vier Typen
2. Style-Guide als parallele Datei anlegen (docs/MANUAL-STYLE-GUIDE.md)
3. Persona-Pfade direkt im Manual-Header verankern, nicht nur in der Bestandsaufnahme
4. Tutorial-Sektion mit der Demo-.rhs-Datei als Teil des Onboarding-Flows
5. „Bekannte Grenzen"-Sektion ganz an den Anfang stellen — schafft Vertrauen durch Ehrlichkeit

---

Zusammenfassung in einem Absatz

Das SARmission-Manual ist nach zwei Iterationen (P0+P1) eine inhaltlich überdurchschnittlich starke Doku, die Florian (ELW-Außensicht) jetzt versteht. Strukturell folgt sie aber dem klassischen 1990er-User-Manual-Idiom statt dem modernen Diátaxis-Framework: Inhalts-Typen werden in vielen Sektionen gemischt, Persona-Pfade fehlen, Tonalität ist inkonsistent, Accessibility und Internationalisierung sind nicht adressiert. Im Vergleich zu Best-in-Class-Manuals (Stripe, Linear, Notion) liegt SARmission bei 6/10 — deutlich über OSS-Single-Maintainer- Durchschnitt (2-4/10), aber unter SaaS-Premium-Niveau (8-9/10). Für die nächsten 6/10 → 7.5/10 sind ~12 Personentage Refactor- Arbeit nötig (Diátaxis-Trennung, Persona-Pfade, Tonalitäts-Vereinheitlichung, Lücken-Schluss). Für 7.5 → 9/10 bräuchte es zusätzlich 14 Tage Migration auf eine moderne Docs-Site (Docusaurus / MkDocs Material) mit Suche, Versions-Switcher, Dark Mode und Persona-Filter.

---

Bezüge

• Handbuch: docs/MANUAL.de.md
• Bestandsaufnahme (P0+P1): docs/MANUAL-BESTANDSAUFNAHME.md
• Diátaxis-Framework: https://diataxis.fr/
• IEEE 26514: https://standards.ieee.org/ieee/26514/7467/
• Google Style Guide: https://developers.google.com/style
• Microsoft Writing Style Guide: https://learn.microsoft.com/en-us/style-guide/

Industrie-Benchmark v1, 2026-05-07. Nächste Iteration: Iteration 3 (Diátaxis-Refactor + Persona-Pfade + Tonalität), ~12 Personentage. Empfohlener Trigger: vor Marketing-Phase-1-Launch von sarmission.de.