4. Typologie des Beispiels
Blindtexte dienen als Platzhalter wie „Lorem ipsum“ oder „123“, „asdf“.
Beispieldaten sind Datensätze in SW-Anwendungen für Test, Demo etc.
Code-Beispiele sind unverzichtbar in Entwickler/API-Dokumentationen.
Anwendungsbeispiele sollen in sich „rund“ und Use-Case-orientiert sein.
Demosysteme verkaufen die Software mittels Anwendungsbeispielen.
5. These: Blindtexte machen blind
Lorem ipsum dolor
sit amet, consetetur
sadipscing elitr, sed
diam nonumy
eirmod tempor
invidunt ut labore et
dolore magna
aliquyam erat, sed
diam voluptua. At
vero eos et
accusam et justo
duo dolores et ea
rebum. Stet clita
kasd gubergren, no
sea takimata …
6. Empfehlung: Blindtext vermeiden!
Blindtexte sind oft (zu) unauffällig
Fordern zum Wegsehen geradezu auf
Layouter vergisst ggf. die Ersetzung
Wenn‘s sein muss: auffällig („Grantln“)
Lieber gleich „echte und gute“ Inhalte
7. Tipp: Blindtext erzeugen (1)
Microsoft Office (insbesondere Word):
=rand(n,m)
Deutschsprachigen Blindtext mit n Absätzen und
jeweils m Sätzen einfügen, z. B. rand(1,2):
Auf der Registerkarte 'Einfügen' enthalten die Kataloge Elemente, die mit
dem generellen Layout des Dokuments koordiniert werden sollten. Mithilfe
dieser Kataloge können Sie Tabellen, Kopfzeilen, Fußzeilen, Listen,
Deckblätter und sonstige Dokumentbausteine einfügen.
=lorem(n,m)
„Lorem ipsum“-Blindtext einfügen (analog zur
rand()-Funktion)
Voraussetzung: In den Autokorrektur-Optionen von Word ist
Während der Eingabe ersetzen aktiv
8. Tipp: Blindtext erzeugen (2)
Generator auf bavaria-ipsum.de
„Schmarrn“
oder „Grantln“
„Grantl“-Ergebnis:
15. Demoinhalte ersetzen Hilfetexte
Demo-Inhalte machen Anleitungen (beinahe) überflüssig
Demoinhalte/Beispiele sind eine (bzw. für viele die) Hilfe
Hilfetexte werden (wenn vermeidbar) nicht gelesen
Einschränkung: gilt insbesondere für
handlungsrelevante Informationen
16. Anforderungen an Showcases
… und Beispielanwendungen
Voraussetzung: funktional, vollständig, sinnvoll
Ohne komplexe Fachlichkeit
Anschaulich dargestellt, spielerisch aufbereitet
Als Demodaten erkennbar und
von Produktivdaten getrennt
22. Überall benötigt: Showcases
… und Beispielanwendungen
Dokumentation: Screenshots, Beispiele, Beispielcode
Entwicklungs-/Testabteilung: mit dem Demo-System
Schulungen: Übungen, Folien, WBTs etc.
Vertrieb/Marketing: Website, Produktvideos,
Präsentationen, Webcasts etc.
Consulting: als Basis für Kundenlösungen
23. Prognose 1: Mehr Beispiele, weniger Doku
Veränderte Nutzererwartungen an „Hilfe“
Anwendungsfall „Software ausprobieren“
Bedienwissen zukünftig komplett in GUI und Demo abgebildet
Tipp: Schrittanleitungen automatisch generieren, z.B. mit
„Dr. Explain“, siehe www.drexplain.de
24. Prognose 2: die neue TR-Rolle
Beispiele kommen besser nicht von Entwicklern!
Technische Redakteure sind optimale Ersteller
Synergie-Effekte nutzen
Weg mit dem Silodenken!
25. Zusammengefasst:
Bessere Demodaten, Anwendungsbeispiele für Software
Vorhandene Möglichkeiten konsequent nutzen
Mehr Mut zur Kreativität
Weniger Schrittanleitungen (die keiner liest)
Die Mühe zahlt sich für das Unternehmen aus
Die Zukunft der User Assistance für Software
Die Zukunft des Technischen Redakteurs