Schlagwort: Informationsarchitektur

  • Konferenz für Informationsarchitektur 2012 – Rückblick

    Ich interessiere mich schon lange für Informationsarchitektur – wie baut man Informationen so auf, wie stellt man sie so dar, dass sie möglichst einfach gefunden werden? Das klingt auch erst einmal einfach nach der Beschreibung eines technischen Redakteurs 😉 Eine gute Beschreibung einer Konzepter/Informationsarchitekten-Stelle gibt es bei designerdock.

    Mir wurde die Konferenz für Informationsarchitektur schon vor längerer Zeit empfohlen, und so hab ich nicht lange gezögert als ich sah, dass das Schwerpunktthema für 2012 „Content Strategy“ heißen sollte 🙂

    Da war ich also mit einem unhippen Thema „Doku im Umfeld der Content Strategy“ unter all den Konzeptern, denen in der Regel dieser wohlbekannte, sofort latent gelangweilte Ausdruck über das Gesicht huschte, wenn ich das Wort „Dokumentation“ erwähnte und den wohl jeder TRler zur Genüge kennt 😉

    Content-Strategy nur als Werkzeug im Pre-Sales
    In den Vorträgen ging es in der Regel vor allem um einen Aspekt in der Content Strategy: die Pre-Sales-Phase. Wie konvertiere ich einen Website-Besucher zu einem zahlenden Kunden? Das war’s. Das lässt sich vielleicht damit erklären, dass hier relativ viele Agenturen vertreten waren, die in der Regel mit einem speziellen Auftrag betraut sind und die Firmen nicht unbedingt langfristig begleiten. Und wie mir bestätigt wurde, sind die Kunden am Ende auch nur darauf fokussiert auf Ihren Webseiten die Konversionsrate zu erhöhen.

    Das Bewusstsein für ein allumfassendes Produkterlebnis bei dem man nicht nur den Neukunden becirct, sondern auch den Bestandskunden hegt und pflegt, scheint sowohl in Firmen als auch in Agenturen noch nicht so stark zu sein. Die After-Sales-Phase spielt meiner Meinung nach eine große Rolle, um eine Marke zu stärken, und Dokumentation bzw. Support-Material gehört hier zum zentralen Content. Aus Marketing-Sicht ist dieser Content halt so wahnsinnig „unsexy“, dass er gerne ausgespart wird, anstatt dass man mal darüber nachdenkt, dass JEDER Content letztendlich Marketing ist und wie man diesen Content verbessern kann. Da sehe ich noch großes Potential!

    IAK12-Schnipsel

     Know thyself (Margot Bloomstein)

    Diese Aussage fasst gut zusammen, was ich desöfteren hören konnte: Am Anfang von allem steht die Kernbotschaft, die man als Unternehmen vermitteln möchte. Sie ist die Grundlage für jedwede Strategie und Kommunikation. In einem Vortrag zur Kommunikationsstrategie vom Taschenhersteller Freitag konnte man sehr schön sehen, wie die Unternehmenskommunikation von dem speziellen Freitag-Geist durchdrungen ist und damit eine Einheit nach außen bildet. Wenn man nicht weiß, was man vermitteln soll, kann das Wie fast nur schief gehen.

    Information gestalten. Nicht Gestaltung mit Informationen füllen (Fabian Lang)

    In vielen Firmen ist es Gang und Gäbe, das erst designt wird und dann am Ende der Texter noch seinen Text „reinhämmert“. Wenn dann beispielsweise eine Überschrift der 2. Ebene konzipiert wird, aber der Texter da eigentlich nichts Sinnvolles reinzuschreiben hat, ist das sein Problem. In der Regel wird er dann irgendwas reinschreiben, auch wenn man diesen Text eigentlich nicht braucht. Deswegen ist es wichtig, dass auch die Texter in die Konzeption miteinbezogen werden, so dass sie ihr Feedback und ihren Text frühzeitig miteinbringen können. Sonst passiert beim Aufeinandertreffen von Konzept und Content eben das hier  (ein Schnappschuss aus Fabians Vortrag):

    Change-Management

    Content betrifft oft sehr viele verschiedene Mitarbeiter in einem Unternehmen, und jeder folgt seinem eigenen Weg. Für eine erfolgreiche Content-Strategy ist es aber erforderlich, dass sich alle auf einen Vision einigen und an einem Strang ziehen. Wie schafft man das? Laut Stefan Freimark:

    • Schwächen aufzeigen und den Handlungsbedarf verdeutlichen
    • Alle Betroffenen einbeziehen: mit regelmäßigen Meetings, Newslettern, alle an einen Tisch setzen

    Fazit

    Es war durchaus interessant, das Thema „Content-Strategy“ mal aus der Konzepter-Perspektive zu sehen. Rückblickend hätte ich   gerne einen Vortrag auf der Konferenz gehalten, um mal die TR-Perspektive an den Konzepter zu bringen. Der Blick auf einen komplette Produkterfahrung wird nämlich langfristig noch sehr wichtig werden, wie ich denke. Und spätestens als in einem Vortrag plötzlich das Wort „DITA“ an der Wand stand (wobei ich noch nicht genau verstanden habe, warum…), war ich mir sicher, dass hier auf jeden Fall irgendwann eine Annäherung stattfinden wird.

    Ein bisschen gestört hat mich, dass es den Referenten mit einer Vortragszeit von nur 35 Minuten oft nicht möglich war, richtig in die Tiefe zu gehen. Ich fände 45 Minuten angemessener und 15 Minuten Pause langen eigentlich auch vollkommen 🙂

    Ansonsten: Die Location in der Zeche Zollverein Essen war toll – in den Pause konnte man mal kurz durch das Museum schlendern und abschalten. Die Idee jedem Teilnehmer Methodenkarten zu einem Thema zu geben, damit man diese untereinander tauscht, war auch klasse, denn man hatte einen guten Anknüpfungspunkt für Gespräche.

    Methodenkarten zum Thema "Content Strategy" auf der iak12

     

     

     

  • Metadaten-Chaos: Komplette Topics filtern

    Der Dating DITA-Vortrag kommt mir gerade wieder in den Sinn, wo ich mich Metadaten beschäftige. Und da stehen mir wirklich die Haare zu Berge – das ist das erste Mal, dass ich DITA wirklich, wirklich unpraktisch finde und noch keine gute Lösung habe, wie ich da in Zukunft verfahren soll.
    Wie man komplette Topics nicht rausfiltert
    Nehmen wir mal an, ich generiere aus einer Map einen User-Guide und einen Admin-Guide. Viele Inhalte überschneiden sich, aber einige sind exklusiv nur für eine der Zielgruppen gedacht.

    Bisher dachte ich mir das so: Wenn ich von einem kompletten Topic weiß, dass es nur audience=“user“ ist, dann setz ich das Attribut auf das Root-Element, also so:
    <task id="123" product="wundertuete2" audience="user">...

    Dann wird doch dieses Topic, auf diese Weise attributiert, nun beim Generieren des Admin-Guides bestimmt nirgends verlinkt bzw. gar nicht erst generiert.

    Weit gefehlt. Das Topic wird generiert und zwar leer (und damit nicht valide). Alle Verlinkungen, sprich: alle Topicrefs, sind auch im Output existent, führen aber natürlich ins Leere.

    Wie man komplette Topics wirklich rausfiltert
    Um zu verhindern, dass etwas überall verlinkt wird, muss man das Attribut auf jeden Topicref setzen!
    <topicref id="123" product="wundertuete2" >
    <</topicmeta></topicref>

    Und zwar auf wirklich jeden, auch die in den Relationship tables. Und das in allen Maps in denen das Topics vorkommt. Wenn ich da an zentrale, so gut wie immer gültige Attribute wie audience oder product denke, wird mir übel. Wie soll man das denn anständig pflegen oder gar mal aktualisieren? So müsste jeder Redakteur für jedes Topic erneut prüfen, welche Gültigkeit es hat und es auch wieder in der Map hinterlegen. Und darauf hab ich eigentlich überhaupt keine Lust.

    (Im Übrigen gilt das Prinzip nicht nur für Topicrefs, sondern auch für den Einsatz anderer interner Verlinkungsarten wie xref oder related-links)

    Zudem ist es sehr inkonsistent, dass es hier plötzlich ein eigenes Element audience gibt, zusätzlich zum gleichnamigen Attribut. Um die Verwirrung zu komplettieren, kann man beides gleichzeitig auf einen einzelnen Topicref beziehen.

    <topicref id="123" product="wundertuete2" audience="user">
    <topicmeta></topicmeta></topicref>

    Eine passende Diskussion auf der Yahoo-Group hab ich schon gefunden, aber eben leider noch keine Lösung. Und sowas muss ich kurz vor dem Wochenende rausfinden 🙁

  • Task-Grenzen

    Beim Texten von Tasks gibt es etwas, was mich als Redakteur von Software-Doku seit den Anfangstagen als TR regelmäßig verrückt macht: wo hört ein Task auf und wo beginnt der nächste? Speziell bei Handlungen, die im Großen und Ganzen dasselbe Ziel haben, aber die man auf verschiedenen Wegen erreichen kann.

    1 Handlung = mehrere Varianten

    Ein gängiges Beispiel ist das Einfügen von Bildern, z.B. in ein Blog oder eine Website.

    Ziel: Bild in den Artikel einfügen

    Möglichkeiten zur Zielerreichung:

    • Bild vom PC hochladen
    • Bild aus dem Web verlinken
    • Bild aus vorhandener Galerie einfügen

    Die Handlungen sind in den ersten Schritten typischerweise identisch, aber unterscheiden sich dann in den meisten folgenden Schritten. Nur das Ziel ist am Ende dasselbe: ein Bild wurde eingefügt. Ich bin nie so ganz schlüssig, was ich in solchen Fällen tun soll.

    Option 1:Rigoroses Splitten

    ich teile das ganz rigoros in drei Topics auf. Der Nutzer sieht ganz spezifisch an der Topic-Überschrift um was es geht.

    • Bild vom PC hochladen
    • Bild aus dem Web verlinken
    • Bild aus vorhandener Galerie einfügen

    Das Problem ist, dass ich auf diese Weise ganz schön viele Topics produziere, die den Nutzer fast erschlagen. Zudem gibt es auch Nutzer, die nur wissen, dass sie ein Bild einfügen wollen, aber mit den drei Optionen einfach so nichts anfangen können. Und prinzipiell sucht wahrscheinlich auch ein erfahrener Nutzer eher nach „Bild einfügen“ als nach „aus dem Web verlinken“.

    Option 2: In ein Topic verpacken

    Es gibt einen Ort an dem der Nutzer nachschaut – bingo, da sieht er alles was zu dem Thema wissen muss.

    • Bild einfügen

    Das Problem ist, dass man so unter Umständen ganz schön lange Topics produziert – zudem kann man es kaum in die SITA-Struktur packen. Es gibt zwar Handlungsvarianten (choice), aber die beziehen sich meist auf einen Handlungsschritt, und nicht einen ganzen Handlungsstrang. Sowas wäre mir am liebsten:


    Um ein Bild hochzuladen, wählen Sie eine der folgenden Möglichkeiten:



    Um eine eigene Datei hochzuladen...
    ...



    Um eine Datei aus dem Web zu verlinken...
    ...



    Aber das lässt DITA nicht zu. Mir ist auch klar warum: damit fällt es einem leichter mehrere Topics in eins zu verpacken. Und man will ja immer nur ein Thema pro Topic. Dummerweise ist das Leben nicht immer so einfach. Hier würde ich mir zumindest mehr Flexibilität wünschen.

    Fazit
    Hält man sich streng an die DITA-Informationsarchitektur kann man eigentlich nicht anders als das auf 3 Topics zu splitten. Aber aus Nutzersicht gefällt es mir nicht.

  • Breadcrumbs in DITA-XHTML

    Der Name Breadcrumb-Navigation wurde in Anlehnung an das Märchen Hänsel und Gretel der Brüder Grimm gebildet, in dem die in den Wald geführten Kinder Brotkrumen (englisch breadcrumbs, plurale tantum) auf den Weg streuen, um den Weg zurück zu finden (PediaWiki)

    Mir geht es speziell um die „Location-Breadcrumbs“, d.h. ich möchte, dass in meiner HTML-Hilfe sichtbar ist, wo in der Hierarchie sich der Nutzer gerade befindet.

    Ein sehr klassisches Instrument in der Nutzerführung, das aber lustigerweise in dem Standard-XHTML-Output gar nicht drin ist.

    Nachdem ich etwas recherchiert habe, bin ich recht schnell auf ein relativ frisches Plugin gestoßen, das genau das macht: Ancestors

    So sieht eine Topic-Seite in HTML dann auch aus, wenn man sie generiert:

    Installation

    Die Installation ist denkbar einfach:

    1. Herunterladen.
    2. Das Verzeichnis qwcode.ancestors in das plugins-Verzeichnis im DITA-OT kopieren.
    3. Im DITA-OT-Verzeichnis eine Shell öffnen und ant -f integrator.xml eintippen.
      –> In der Datei dita2xhtml.xsl sollte das Stylesheet des Plugins nun referenziert werden.
    4. Im Verzeichnis qwcode.ancestors eine Shell öffnen und ant buildDemo eintippen.
      –> Hier sollten nun im Unterverzeichnis demo/xhtml die XHTML-Dateien generiert werden.

    Das ganze hat bei mir echt gut geklappt und daher spreche ich eine eingeschränkte Empfehlung aus. Die Einschränkung folgt auch sofort.

    Bug bei Verwendung von reltables

    Aktuell werden leider bei allen Topics, die in Reltables referenziert werden, die Breadcrumbs falsch dargestellt, so wie in diesem Beispiel, in dem die Startseite „Index“ zweimal verlinkt wird. Das zu fixen ist sicherlich kein Hexenwerk, aber ich habe gerade keine Zeit…  Wenn das aber gefixt ist, empfehle ich absolut uneingeschränkt 🙂

  • Wiederverwendbarkeit von Maps & Cross-Media-Publishing

    Neben dem Single-Source-Publishing (aus einer Quelle baue unterschiedliche Dokumente, z.B. Admin-Handbuch und User-Quickstart) ist auch Cross-Media-Publishing ein wichtiges Schlagwort in der heutigen TR (aus einem Dokument baue verschiedene Outputs, z.B. PDF, HTML und CHM).  Beide Prinzipien finden sich auch in DITA wieder.

    Maps in DITA wiederverwenden

    Man kann in DITA ganze Maps wiederverwenden. Hierzu muss man im topicref einfach das Attribut format auf ditamap setzen:

    <topicref scope=“local“ format=“ditamap“ navtitle=“E-Mail“ href=“../E-Mail/E-Mail.ditamap“/>

    Die Topics dieser Map und ihre Hierarchie werden einfach in die Hierarchie der referenzierenden Map eingebaut, d.h. im Output kann man nicht mehr sagen, was auch welcher Map kam. Dies ist überaus praktisch, um beispielsweise nicht nur Wiederverwendung auf Topicebene zu machen, sondern eben auch auf bspw. Kapitelebene.

    Cross-Media-Publishing – wie ist die Realität?

    Die Crux beim Cross-Media-Publishing ist: das was im Print funktioniert, muss noch lange nicht online funktionieren. Und umgekehrt natürlich.

    Hilfemedien unterscheiden sich durch mehr als das Dateiformat. In Online-Hilfen muss man z.B. viel mehr verlinken.

    Ich habe nun gerade eine Map angelegt, die sehr stark auf den HTML-Output ausgelegt ist. Ich will dort beispielsweise kein komplettes Inhaltsverzeichnis, weil mir das im Onlineformat zu viel ist. Ein Inhaltsverzeichnis mit 70 Topics ist einfach zuviel (und ein hübsches JavaScript-Aufklapp-Inhaltsverzeichnis ist hier nicht angebracht). Daher habe ich sehr viele Topics auf „toc=no“ gesetzt. Die Beziehungen werden für den Nutzer über die hierarchischen Links und related Links dann schon abgedeckt.

    Nun ist die Map fertig und mir wird klar, dass sie so nicht wiederverwendbar ist.  Es ist eine reine HTML-Map und wenn ich ein PDF mit einer ähnlichen Struktur bauen möchte, werde ich eine neue Map bauen müssen, was aber zu Redundanz führt (Böse, böse! BÖSE!). Oder ich ändere je nach Output jedes Mal die toc-Attribute (Blöd, blöd! BLÖD!).

    Fazit?

    Ich muss schauen, wie sich das entwickelt. Aktuell steht es nicht in Aussicht, dass ich ein PDF benötige, aber in der Informationsarchitektur muss ja ein wenig vorausschauen und ich sehe schon förmlich, wie die PDF-Wolke sich am Himmel zusammenbraut (oh, nicht das falsche Vorstellungen aufkommen: ich sehe meine Auftraggeber nicht als Götter an 😉 ). Leider hab ich bisher nur Schilderungen gefunden, die meine beiden Optionen bestätigen.

    Irgendwie muss ich diesen Grat zwischen Cross-Media-Publishing und trotzdem „passend für das tatsächliche Medium“ noch finden. Hmmm.

  • Links in DITA #3 – Relationship tables

    Mit den so genannten Relationship tables (reltable) kann man die Beziehungen zwischen Topics definieren. Hiermit implementiert man Verlinkungen, die nicht durch die Hierarchie (oder die anderen collection-types) festgelegt ist. (mehr …)

  • Bedingter Text in der Praxis

    Oder nennen wir ihn auch „conditional text“. Gemeint ist das Prinzip Texte mit einem Attributwert zu versehen und beim Generieren festzulegen, ob Elemente mit diesem Attribut inkludiert oder exkludiert werden.

    Eigentlich eine feine Sache, um Produktvarianten zu handhaben (So geht es in XMetal).

    Praxisbeispiel

    Nun wende ich das ganze wirklich zum ersten Mal an und zwar hier:

    Das Feature ist eigentlich dasselbe, nur dass es in Produkt A als „Copyright-Zeile“ auftaucht und automatisch ein ©-Zeichen eingefügt wird. Während in Produkt A1 das Feature „Fußzeile“ heißt und nichts automatisch eingefügt wird.

    Dem Featurenamen hab ich daher in ph-Tags gepackt und sie entsprechend mit product_a oder product_a1 attributiert. Sieht eigentlich gut aus und am Ende kommt auch das raus, was ich will!

    Haken an der Sache?

    In obigemFall war das ganze einfach, weil die Features denselben Genus aufweisen und beide im Singular sind. Angenommen „die Fußzeile“ hieße eigentlich „der Fußmarker“ – da müsste ich beispielsweise Artikel oder Pronomina in den ph-Tag mitaufnehmen. Das obige Beispiel sähe dann so aus:

    Irgendwie hab ich das noch unbegründete Gefühl, dass genau solche Fälle beim Übersetzen Ärger machen können, aber noch hab ich keine Beispiele dazu gefunden…

  • Links in DITA #2 – Hierarchien und collection-type

    Ich habe bereits vorgestellt, welche Möglichkeiten des manuellen Verlinkens es gibt. Wie gesagt, erschwert diese Methodik die Wiederverwendung eines Texts. Da Wiederverwendung jedoch einer der Kernpunkte von DITA ist, gibt es natürlich auch hier Mittel und Wege. Und zwar indem man die Verlinkungregeln in die Maps auslagert. So kann man auch nur das verlinken, was in der Map drin ist und läuft nicht Gefahr tote Links zu erzeigen.
    (mehr …)

  • Spezialisierung: Eigene DITA-Attribute definieren

    DITA bietet bereits einige Attribute, die schon sehr viele wichtige Dinge in der technischen Dokumentation abdecken: product, audience, platform seien da als Beispiele genannt.

    Wenn es um sehr firmenspezifische Dinge geht, benötigt man hier schnell eigene Attribute. Für mich persönlich sehr wichtig, sind auch vorgegebene Attributwerte, weil eine vorgegebene Auswahl immer sehr viel weniger fehleranfällig ist.

    Was bedeutet Spezialisierung?

    In DITA nimmt man etwas Vorhandenes, also einen bereits vorhandenen Topictyp (z.B. Concept) oder ein bereits vorhandenes Attribut, und leitet davon seine eigene Version ab: man spezialisiert. Inbesondere in Bezug auf Topictypen ist wichtig zu wissen, dass man Festlegungen der DTD von der man ableitet, nicht „aufweichen“ kann. Wenn ein Element <hups> in der Ur-DTD zwingend erforderlich ist, kann man es in der Spezialisierungs-DTD nicht optional definieren.

    Attribute spezialisieren

    Es gibts 2 Arten von Attributen, die man spezialisieren kann: props (speziell für Filtern) und base (Sinn und Zweck hat sich mir noch nicht erschlossen…). Da ich mein neues Attribut zum Filtern des Contents benutzen möchte, benutze ich daher das props-Attribut.

    Schritt 1: Attribut deklarieren
    Ich werde nun ein Attribut definieren, das beschreiben soll, für welchen Hilfekontext das Element gilt: für die Hilfe im Web oder für die Hilfe in der Software.

    1. Zuerst erstelle ich eine Datei namens helpContextPropsDomain.ent mit folgendem Inhalt:



      Im ersten Teil lege ich den Namen des Attributs (help-context) fest und in meinem Fall auch 2 vordefinierte Werte (webpage, software).
    2. Ich speichere die Datei im dtd-Verzeichnis des DITA-OT ab.

    Schritt 2: Attribut der DTD bekannt machen

    1. Nun öffne ich die concept.dtd und lege noch eine Sicherheitskopie von ihr unter anderem Namen ab Man weiß nie… ;).
    2. Unter dem Bereich DOMAIN ATTRIBUTE DECLARATIONS füge ich ein:

      SYSTEM "helpContextPropsDomain.ent"
      >
      %help-context-props-d-dec;
    3. Unter dem Bereich DOMAIN ATTRIBUTE EXTENSIONS erweitere ich :

    4. Unter dem Bereich DOMAINS ATTRIBUTE OVERRIDE erweitere ich :

      &ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att;
      &ut-d-att; &indexing-d-att;&help-context-props-d-att;" >
    5. Diese Schritte müssen nun für alle Topictypen wiederhiolt werden, für die man das Attribut braucht.

    Schritt 3: testen 🙂

    1. Ich erstelle eine XML-Datei auf Grundlage dieser DTD
    2. Ich füge das Attribut _help-context=“webpage“_ in ein-Element ein
    3. Ich jage das Dokument durch einen Validator – und wenn der nicht meckert, hat es funktioniert

    Spezialisierung in XMetal DITA Edition
    Der XMetal DITA Edition bindet ein DITA-OT ein. Wie es scheint benutzt er dieses ausschließich zum Generieren.
    Die DTDs, die XMetal benutzt, liegen im Programmverzeichnis unter „…XMetaL 5\Author\DITA\DITA_OT_DTD\“<.

    1. D.h. die oben erstellten bzw. bearbeiteten Dateien müss dort hinein kopiert werden.
    2. XMetal neu starten
    3. Ein Concept anlegen
    4. Und sich freuen, dass man ein neues Attribut im Attribute Inspector sieht 🙂

    Mehr zum Thema
    In Eliot Kimbers Tutorial erfahrt ihr mehr zur Spezialisierung.

  • Links in DITA #1

    Der Link ist essentieller Bestandteil der Online-Welt. Gerade bei der Topicorientierung, in der Information quasi auseinandergerissen ist, ist er die beste Navigationsmöglichkeit für den Leser und stellt einen Kontext her.

    DITA ermöglicht einem einerseits manuell Links zu setzen oder sie automatisiert setzen zu lassen, indem man vorher den Beziehungsstatus definiert.

    Heute gibt es erst einmal etwas zu den Links, die man als Redakteur selbst direkt einfügen kann.

    <xref> – Inline-Links
    Diese Links setze ich manuell mitten im Textfluss. Etwa so wie diesen hier. Dieses Vorgehen ist eigentlich allgemein bekannt.
    Im Code sieht es so aus:

    hier

    Verlinken kann man alles von anderen Topics bis hin zu Webseiten (nur bei Links von generierten PDFs auf Online-PDFs muss man bei Verwendung des FOP aufpassen).
    Generell ist das Verwenden von Inline-Links aber eigentlich nicht so toll:

    • sie unterbrechen des Lesefluss und die Aufmerksamkeit des Nutzers. Will man den Nutzer wirklich mitten im Task in einen völlig anderen Kontext schicken? Eigentlich nicht. Höchstens wenn es sich um eine Handlungsvoraussetzung handelt.
    • ein Topic ist durch einen Inline-Link in der Regel schlechter wiederverwendbar. Verwendet man es wieder, könnte der Link kaputt gehen, weil das Linkziel in diesem neuen Kontext nicht vorhanden ist.

    <related-links>
    In der manuellen Variante der „Related links“ fügt man den Tag <related-links> ein und setzt die Links in einzelne <link>-Tags oder in eine <linklist>. Das Gute an diesem Tag ist, dass er am Ende des Topics gesetzt wird, also den Nutzer nicht aus dem Kontext reißt. Aber auch in dieser Option steckt der Nachteil, dass die Wiederverwendung des Topics eingeschränkt wird.