Nachdem es im ersten Teil dieses TextMaker-Tutorials um die Grundlagen zu Vorlagen und die Mysterien von Masterseiten ging, kann es jetzt ans Eingemachte gehen.

Zur Veranschaulichung der Möglichkeiten entsteht im Folgenden eine Briefvorlage mit einer zweiten Spalte, in der ein Logo, Seitenzahlen und ein festes Hintergrundbild (als Wasserzeichen) unterkommen.

Um dieses Tutorial Schritt für Schritt nachzuvollziehen, können Sie hier klicken, um alle für dieses Projekt benutzten Grafiken herunterzuladen.

Beim Erstellen von Dokumenten in einer Textverarbeitung werden Sie schnell feststellen, dass sich deren Aufbau oft ähnelt. Die meisten Briefe folgen einem einheitlichen Layout, ebenso wie Rechnungen, Besprechungsnotizen usw.

Einige TextMaker-Anwender beginnen jeden Brief von vorne, andere greifen auf die mitgelieferten Vorlagen zurück. Abenteuerlustige Benutzer öffnen ein altes Dokument, passen den Text an und speichern das Ergebnis unter einem neuen Dateinamen. Dieses Vorgehen ist riskant: Allzu oft vergisst man, das Dokument unter einem neuen Namen zu speichern, und überschreibt versehentlich die alte Datei.

Besser ist es, ein benutzerdefiniertes Layout einzurichten und es als wiederverwendbare Dokumentvorlage zu speichern. Das klingt dramatischer, als es ist – dieses Tutorial führt Schritt für Schritt durch den Ablauf.

Aufgrund von Unternehmensrichtlinien arbeite ich im Büro seit kurzem mit Microsoft Office. Zu Hause verwende ich nach wie vor SoftMaker Office. Das Hin- und Herwechseln hat sich als weniger problematisch erwiesen als zunächst erwartet. Ganz im Gegenteil: Wenn ich Artikel in TextMaker schreibe und Tabellenkalkulationen in PlanMaker bearbeite, habe ich dabei noch stärker das Gefühl, daheim zu sein.

Im Büro muss ich mich mit den zur Verfügung gestellten Werkzeugen arrangieren. Zu Hause habe ich meinen selbst gewählten Werkzeugkasten – und der bleibt weiterhin mit der Software bestückt, die ich am effizientesten finde.

Vor langer Zeit gab es einmal ein Betriebssystem, das derart schlecht durchdacht war, dass es, wenn es auf einen schrecklichen Fehler stieß, seine Anwender mit drei schlechten Entscheidungen konfrontierte: (A)bbrechen, (W)iederholen oder (I)gnorieren. Es lief letztlich daraus hinaus, dass die Situation absolut hoffnungslos war.

Begegnete mir diese Nachricht, wusste ich immer, dass alle drei Optionen ähnlich schlechte Ergebnisse nach sich zogen. Normalerweise wählte ich „Abbrechen“. Ich konnte ja nicht ahnen, dass das der Vorläufer des gefürchteten „Abbrechen“-Knopfs sein würde.

Wenn ein Dialog die Möglichkeit zum Abbrechen anbietet, steht man meist vor einer wesentlichen Entscheidung, die eine verbindliche Festlegung erfordert. Einige Anwender fühlen sich darauf nicht vorbereitet, weshalb sie jede Gelegenheit nutzen, um ihren Kopf aus der Schlinge zu ziehen: „Ich verstehe nicht, was passiert, wenn ich das bestätige – also drücke ich besser auf Abbrechen“. Das ist nicht immer die beste Wahl.