- Dies ist eine Übersetzung von FishTanks Blog „Short and long pages on Fandom“.
Fandom ist die umfassendste Quelle von Informationen für Fans aus allen möglichen Bereichen, die wir lieben. Autoren, von den umfangreichsten Geschichtsschreibern bis hin zu hingebungsvollen Fans, teilen jeden Aspekt ihres Lieblingsthemas mit den Wikis. Das führt dazu, dass die Leser viel zu erkunden haben, und genau das ist Sinn fast jeden Wikis.
Manchmal ist diese Information allerdings nicht so einfach zu finden, weil sie zum Beispiel gut versteckt oder nur knapp vorhanden ist. Viele Wikis nutzen Tabs und Tab-Panels („Tabber“ genannt), um ihre Inhalte anzuordnen. Mit diesem Post möchten wir über die Möglichkeiten sprechen, wie man Artikelinhalte anordnet, um ihn möglichst vielen Lesern und auch denen, die gezielt nach diesem Inhalt suchen, verfügbar zu machen.
Irrtümer über die Artikellänge verringern[]
Ein Baumstumpf, unvollständig
Es gibt einen großen Unterschied zwischen Raum erschaffen und Raum unterhalten. Sowohl aus der Sicht der Leser-Erfahrung als auch aus der Sicht der Suchmaschinen, sollte eine Community unvollständige Seiten vermeiden. Es ist zu einer Tradition geworden, eine Seite, die bewussterweise unvollständig ist (insbesondere, wenn sie als Platzhalter für spätere Arbeit dient) als „Stub“ zu bezeichnen. Es kommt aus der Wikipedia, diesen Seiten am Anfang oftmals eine Vorlage namens „Stub“ hinzuzufügen; das erklärt neuen oder potentiellen Autoren aber nicht, was ein Stub genau ist. Im Laufe der Zeit ist die ursprüngliche Bedeutung eines Stubs in den Köpfen der Autoren dahingehend verwässert, dass jede kurze Seite ein Stub sei, was nicht wirklich stimmt.
Die beste Vorgehensweise ist die, Stub-Seiten so schnell wie möglich so vollständig wie möglich zu machen. Ob das eine kurze (vollständige) oder eine lange Seite hinterlässt, ist nicht wichtig für die Suchmaschinen, sondern eher für die Leser-Erfahrung. Weder kurze noch lange Seiten sind direkt schlecht; diese Tatsache ist ein bisschen verwirrend. Stubs sorgen allerdings für eine schlechte Erfahrung, denn die Leser und Suchmaschinen, die auf diese Stubs stoßen, werden bei dem Wunsch nach Mehr allein gelassen und es hat sich, trotz vorheriger Annahme, nicht bewiesen, dass eine unvollständige Seite (selbst, wenn sie als unvollständig gekennzeichnet wurde) „aus den Lesern Autoren hervorbringt, die diese Seite vervollständigen möchten“. Jeder Tag, an dem ein Stub existiert und unvollständig bleibt, ist ein Tag, an dem die schlechte Leser-Erfahrung andauert.
Kurze Seiten sind nur dann schlecht, wenn sie nicht alle Information für das Thema dieser Seite beinhalten und die Leser sich an anderen Orten diese Informationen beschaffen müssen. Kurze Seiten sind nicht schlecht, wenn sie umfassend alles das behandeln, was nötig ist, um das Konzept dieser Seite zu verstehen. Das klassische Beispiel für diesen Fall wäre Aunt Barbara aus „The Big Bang Theory“ (englisch). Diese Seite ist vollständig, nicht als Stub markiert, und auch wenn einige diese Seite als kurz empfinden könnten (oder gar sagen würden, sie wäre zu kurz), ist diese Seite perfekt für das, was sie beschreibt. Wenn eine Seite die Hürde „Muss diese Seite wirklich existieren?“ überwindet, sie aber auch nicht das Gefühl in den Lesern erweckt, woanders nach den Informationen zu suchen, die sie finden möchten, und die Seite sowohl zu anderen Seiten verlinkt als auch verlinkt wird, dann hat sie einen akzeptable Länge.
Andersherum sind lange Seiten nur dann schlecht, wenn die Seite zu viele Informationen enthält und die Aufmerksamkeit des Lesers überfordert wird. Der Punkt, an dem ein Autor einen langen Abschnitt vollständiger Informationen zusammenfassen kann, ist der, an dem der Autor diesen Abschnitt abtrennen und zu der dann abgetrennten Seite verlinken kann. Eine Community kann sich entscheiden, Abschnitte als Unterseiten abzutrennen oder nicht, obwohl einige fälschlicherweise denken, Unterseiten seien schlecht. Das ist auf einem weiteren Irrtum begründet, der damit zu tun hat, dass die Wikipedia aus technischen Gründen Unterseiten im Hauptnamensraum deaktiviert hat und viele Titel „/“ enthalten. Vielmehr versteht Google sogar, das Unterseiten eine klare Eltern-Beziehung zu der Hauptseite haben. Wenn ein einzelner Abschnitt ein gutes Buch-Kapitel mit eindeutigem Titel abgeben würde, kann er meist unbedenklich abgetrennt werden. Es ist kein Problem, eine Zusammenfassung der wichtigsten Dinge auf der Hauptseite zu lassen, während man auf einer anderen Seite ins Detail geht.
Einen Artikel aufteilen[]
Es ist immer eine gute Sache, eine Hauptseite zu haben, die vollständig ist, aber nicht so detailliert, dass sie den Leser durch ihre Länge langweilt. Deshalb empfehlen wir die {{Hauptartikel|/Unterseite}} + Zusammenfassung Aufteilungsmethode. Es erlaubt dir, der Unterseite mehr Details hinzuzufügen, ohne das große Ganze des Themas der Seite aus den Augen zu verlieren. Weitere Infos dazu findest du in den folgenden englischen Blogs von FishTank: Categories and Navigation on Fandom und Articles on Fandom. Weil das aber so eine wichtige Methode ist, möchten wir im Detail darauf eingehen.
So könnte ein Kontextlink über einer Zusammenfassung aussehen.
Wenn ein Hauptartikel lang genug geworden ist, könnte er Teile haben, die durchaus auf unabhängige, eigene Artikel aufgeteilt werden könnten. Zum Beispiel könnte die Handlung eines Charakters in einer TV-Staffel nach „Charakter/Staffel 1“ ausgelagert werden, die dann ausführliche Punkte der Handlung und auch Spoiler enthält. Der Hauptartikel könnte dann stattdessen eine spoilerfreie Zusammenfassung mit den wichtigsten Punkten erhalten und einen Kontextlink darüber bekommen (zum Beispiel so: {{Hauptartikel|Charakter/Staffel 1}}). Diese Unterseiten besitzen sogar eine direkte Möglichkeit, zum Hauptartikel zurückzukehren: Sie besitzen einen Link zu ihm direkt am Anfang der Seite!
Wenn ein Autor Informationen über etwas verlinkt, was vom Hauptartikel trennbar ist, anstatt sie einzubetten oder hinzuzufügen, erstellt der Autor damit auch ein besser verständliches Ziel für Suchmaschinen (und Menschen). Das Ergebnis ist eine kürzere Seite, auf der man weniger scrollen muss, aber auch ein besseres Verständnis dafür bekommt, was die Autoren zu vermitteln versuchen.
Eine einfache Methode:
- Finde einen Abschnitt an Informationen, der auch für sich genommen als Artikel bestehen könnte, entweder weil er sehr lang und vollständig ist oder ein nebensächliches Thema oder Unterthema behandelt.
- Entscheide dich für einen angemessenen Seitentitel, der sich genau auf den Abschnitt bezieht, den du auslagerst. Wenn deine Community Unterseiten benutzt, kann dieser Artikel gut als Unterseite realisiert werden. Der Titel sollte klar das wiedergeben, nach dem ein Benutzer suchen würde, „Naruto Uzumaki/Teil II“ sollte zum Beispiel von denen verstanden werden, die genau diesen Teil seiner Handlung suchen. Wenn der Abschnitt ein komplett anderes Thema beschreibt (also nicht aus dem Original abgeleitet werden kann), sollte er nicht als Unterseite realisiert werden (beispielsweise sollte „Matrix#Fortsetzungen“ besser „Matrix Reloaded“ sein).
- Erstelle diese Seite, entferne den Inhalt aus dem ursprünglichen Abschnitt und füge ihn in die neue Seite ein, inklusive aller Unterüberschriften (die von H3- zu H2-Überschriften angepasst werden sollten), Bildern, Galerien, Anmerkungen und Infoboxen, die in diesem Abschnitt enthalten sind.
- Wenn Infoboxen übertragen werden, sollten die enthaltenen Informationen sich nur auf das beziehen, was in diesem Abschnitt steht. Eine Infobox ist auch nur dann notwendig, wenn die Seite eine andere Instanz repräsentiert. Mit anderen Worten und auf das obige Beispiel bezogen, sollte Naruto Uzumaki keine Infobox nur für das haben, was ihm in den Handlungsabschnitten von „Teil II“ passiert ist; diese Infobox sollte auf seinem Hauptartikel verbleiben. Wenn es aber um einen anderen Charakter oder Typus von etwas geht, dessen Abschnitt abgetrennt werden soll, würde dieser Teil seine eigene Infobox bekommen. In beiden Fällen kannst du auch eine Infobox dazu benutzen, zwischen den Seiten zu navigieren, um Navigations-Tab-Links oder ähnliche Button- und Icon-Vorlagen zu vermeiden.
- Wenn du die Seite gespeichert hast, kannst du ihm Hauptartikel einen Link zu der Seite hinzufügen, die du gerade abgetrennt hast. Eine Methode, die schon lange funktioniert, ist die, dass man die Überschrift des Abschnitts bestehen lässt, direkt darunter eine Vorlage hinzufügt (typischerweise „Hauptartikel“ – als „Kontextlink“ klassifiziert – was einfach nur dazu gedacht ist, anzuzeigen, wo der Hauptartikel für diese Zusammenfassung zu finden ist) und dann eine kurze Zusammenfassung (ungefähr ein oder zwei Absätze) der wichtigsten Inhalte des Abschnitts, den du gerade ausgelagert hast. Das bewahrt die Vollständigkeit des ursprünglichen Artikels und bietet tiefere Einblicke für den Leser, wenn er mehr zu diesem Thema wissen möchte.
Tabs[]
Tabs sind ein umstrittenes Thema in Wikis, entweder geliebt oder gehasst. Viele Wiki-Leiter ziehen sie aus ästhetischen Gründen vor und benutzen sie dazu, Seiten kürzer aussehen zu lassen oder eigenständige Informationsteile einzufügen. Auch wenn gewöhnlich gesagt wird, dass Tabs grundsätzlich vermieden werden sollten, können sie durchaus eine effektive Methode sein, Inhalt aufzuteilen. Die größten Probleme beim Nutzen von Tabs leiten sich aus den zwei völlig unterschiedlichen Wegen, sie zu benutzen, ab: bestimmten Inhalt auszublenden und Inhalt auf andere Seiten zu verteilen. Es gibt weit weniger Beispiele, bei denen Tabs gut genutzt wurden, als solche, die Herausforderungen oder Probleme mit sich bringen. Daher ist es eine gute Idee, die Möglichkeiten zu erklären, sie zu nutzen, aber auch zu erklären, wann (und wie) man davon absieht, sie zu nutzen.
Die Richtlinien für Tabs (englisch), die im Laufe der Zeit von Experten in Sachen Benutzerfreundlichkeit sehr genau untersucht wurden, dienen uns als objektiver Maßstab. Diese Richtlinien sind das Ergebnis von Untersuchungen, wie Leser mit Webseiten interagieren.
[]
- Siehe auch: Navigation boxes and bars and beyond
Viele Leute sind der Meinung, dass Tab-Navigation zwischen Seiten gut sei. Der Hauptgrund für diese Meinung ist die Bequemlichkeit der Navigation. Wenn Tabs klar erkennbar vorausgewählt sind, können sie auf jeden Fall eine leicht auszumachende Möglichkeit zur Navigierung sein.
Richtlinie #1 ist:
- Nutze Tabs, um zwischen Ansichten innerhalb desselben Kontexts umzuschalten, nicht um zu verschiedenen Bereichen zu navigieren. Das ist der wichtigste Punkt, denn der Hauptgrund, warum wir Tabs haben, ist der, dass man am selben Ort bleibt, während man die Ansichten wechselt.
Für die Erfahrung, die die Leser machen, ist es wichtig für sie zu wissen, was passiert, wenn sie klicken oder tippen. Benutzt man dagegen Tabs, um zum Beispiel auf eine andere Seite zu verlinken, verliert sich der Sinn dieser Tabs, da die Erwartungshaltung dahingehend ausgerichtet ist, dass der erste Artikel nicht verlassen wird; die Leser denken nun (es funktioniert nahezu überall gleich, daher existieren diese Richtlinien), sie sehen eine andere Ansicht derselben Seite. Wenn sie auf eine andere Seite gehen wollen, klicken sie auf etwas, das ein offensichtlicher Link zu dieser anderen Seite ist, in der Erwartung, dass sie auf dieser Seite auch ankommen.
Oberflächlich betrachtet, wünscht man sich etwas, das wie ein Link funktioniert, was aber nicht das ist, was normalerweise passiert, wenn man auf einen Tab klickt. Wenn man auf einen inaktiven Tab klickt, geht man eher davon aus, dass man eine versteckte Ansicht hervorholt. Das führt uns zu Richtlinie #2:
- Teile den Inhalt hinter den Tabs logisch auf, damit Benutzer leicht voraussehen können, was sie erwartet, wenn sie einen Tab auswählen.
Weil das ein unerwarteter Effekt ist, der im Widerspruch zu der Erwartungshaltung der Benutzer steht, versuchen wir das beim Design von Benutzer-Erfahrung zu vermeiden. Logisch eingeteilter Inhalt ist einheitlich, ein Tab, der von Äpfeln handelt, sollte nicht über Orangen sprechen.
Richtlinie #4 ist auch sehr relevant.
- Gestalte Tabs so, dass sie im Grundsatz parallel sind. Wenn die Tabs deutlich verschieden sind, werden die Benutzer sie als Seiten-Navigation interpretieren.
In diesem Fall erwarten die Leser, zu einem anderen Teil der Seite und nicht zu einem verwandten Artikel geführt zu werden. Die zusätzliche Navigationsebene lässt die Leute durcheinander bringen, was der Unterschied zwischen der Navigationssymbolleiste, den Werkzeugen zum Bearbeiten der Seite und der lokalen Absicht, die Leute zu einem stark verwandten Artikel zu führen, ist. Ein Beispiel für parallele Tabs wären einzelne Episoden oder Spiele, keine Galerien oder Abschriften.
Damit wären wir bei Richtlinie #12, die die Dinge super zusammenfasst.
- Tabs sollten alle gleich aussehen und gleich funktionieren. Einheitlichkeit ist wichtig beim Designen der Benutzeroberfläche, weil es dem Benutzer das Gefühl gibt, über die Oberfläche auf verschiedenen Wegen bestimmen zu können:
- Wiedererkennbarkeit. Wenn etwas immer gleich aussieht, weißt du, wonach du suchen sollst und du weißt, was es ist, wenn du es gefunden hast.
- Vorhersehbarkeit. Wenn etwas immer gleich funktioniert, weißt du, was passiert, wenn du damit interagierst.
- Befähigung. Wenn du dich auf dein bisheriges Verständnis der verfügbaren Funktionen verlässt, kannst du leicht eine Reihe an Möglichkeiten zusammenstellen, um dein Ziel zu erreichen.
- Effizienz. Du musst dich nicht damit aufhalten, etwas Neues zu lernen oder dir über die Auswirkung von uneinheitlichen Funktionen Gedanken machen.
Wenn ein Wiki zwei Dinge hat, die wie Tabs aussehen (Seitennavigations-Tabs und Tabber), erwarten die Leser auch, dass sie auf die gleiche Weise funktionieren, was nicht der Fall ist, wenn sie in derselben Community genutzt werden. Es gibt also nichts, was direkt gegen das eine oder das andere spricht, allerdings gibt es weitere Bedenken, die uns dazu führen, Alternativen für beide vorzuschlagen.
[]
Menschen verarbeiten semantische Daten und Beziehungen intuitiv (so wird es technisch genannt). Damit wird beschrieben, wie sich ein Thema oder ein Objekt oder eine Seite zu einer/m anderen verhält.
Datenzeilen, die auf andere, verwandte Seiten verweisen
In einigen Fällen gibt es eine klar definierte informative Beziehung zwischen Seiten. In anderen Fällen ist das reine Information zum Navigieren.
Navigations-Links in einer Zeile, mit Punkten dazwischen
Auf den vielen verschiedenen Bildschirmgrößen eines Computers kann es verlockend sein, so viele Navigationsmöglichkeiten wie möglich auf kreative Art und Weise unterzubringen. Häufig finden diese sich dann als Tabs oder Icons am Anfang des Seiteninhalts. Da diese Links allerdings im Grund Inhalt sind (von Vorlagen erstellt), werden sie von Lesern, die mehrere Wikis besuchen, nicht so leicht erkannt. Je kreativer diese Tabs werden, desto eher werden sie aufgrund der „banner blindness – Bannerblindheit“ vermieden. Diese Links in besser bekannte Elemente zu integrieren, besonders, wenn das bei der Erkennung von semantischen Beziehungen durch Menschen (und Maschinen) hilft, gibt Lesern besser verständliche und einheitliche Fixpunkte, damit sie die verwandte Information finden, die sie suchen. Es hat auch den Nebeneffekt, mehr Inhalt „auf die Vorderseite“ zu bringen und reduziert auch die wahrgenommene Seitengröße.
Auf mobilen Geräten ändert sich das Aussehen von Elementen zu einem mehr minimalistischen (ausgelegt für kleinere Bildschirme mit begrenzteren Anzeige-Möglichkeiten und Datentarifen) oder fingerfreundlichen Design. Navigations-Tabs sind grundsätzlich Links, sie erscheinen als unformatierte Links in dem mobilen Skin von Fandom. Manchmal resultiert das in einer schwachen mobilen Erfahrung, die mobilen Lesern weniger verständlich ist.
Deswegen denken wir, dass man sie besser als Teil eines anderen, stabileren Elements wie dem <navigation>-Bereich von Portablen Infoboxen platziert, als eigene Navigationselemente zu erstellen. Selbst, wenn du keine Portablen Infoboxen nutzt, bedeutet das Platzieren von Navigations-Links in Infoboxen einen einheitlichen Ort für Leser, an den sie schauen und dort Beziehungen zwischen den Seiten vermuten können. Wenn man das macht, führt das zu einer im Ganzen besseren, informativeren und kürzer erscheinenden Seite. Weiterführende Informationen dazu, wie man das macht, finden sich hier: „Navigation boxes and bars and beyond“. Das Ergebnis kann eine Navigationsbox im „Navbox-Stil“ sein, die in die Infobox eingebaut wurde, was Navigations-Optionen gleich am Anfang der Seite präsentiert (damit Leser ihre begehrte richtige Seite schneller finden), anstelle davon, dass diese am Ende der Seite sind (wo sie durch den ganzen Artikel gehen müssten, um das zu finden, was sie wollen).
Infobox-Navigation im tschechischen Star Wars Wiki
Wenn du Portable Infoboxen nutzt, ist das meistens schnell durch Reihen von <data>s erledigt (wenn du auf abgeleitete Seiten verweist und du Links auf der Seitenebene der Vorlage unterbringen musst, wie zum Beispiel „| hardline = [[M16 (Hardline)]]“; siehe das Bild zu den Datenzeilen oben) oder durch Reihen von <navigation>s (für verwandte Seiten, die keine Links auf der Seitenebene haben müssen; siehe das Bild zu der Episode). Wie im Wikitext können sie auch logische Funktionen durch Parser-Funktionen (innerhalb der Format-, Default- und Navigations-Tags) verwenden, um sich besser an die Seiten anzupassen, auf denen sie eingebunden werden. Wenn du klassische Wikitext-Infoboxen nutzt, wäre es auch eine gute Lösung, einen Weg zu finden, wie du die Wikitext-Funktionen dazu nutzen kannst, deine Vorlagen zu erweitern. Ein zweiter Effekt, der zugleich vorausdenkend ist: Fandom kann die Daten- und Navigationsbeziehungen in den Infoboxen nutzen, um semantische Daten-Werkzeuge bereitzustellen, wenn sie weiter entwickelt wurden.
Tabber[]
Tabber sind Blöcke, dessen Inhalt in Abschnitte eingeteilt ist, jeder mit einem Tab am Anfang betitelt. Alter Tabber-Methoden funktionieren unter Nutzung einer JavaScript-Methode, die den Inhalt „versteckt“, bis er gebraucht wird. Die Hauptinformation sollte direkt sichtbar sein, ohne, dass man etwas machen muss. Fandoms Standard-<tabber>-Erweiterung zeigt den Inhalt aller Tab-Bereiche im mobilen Skin an, ohne Namen und nicht getrennt, weil das im mobilen Skin nicht funktioniert. Es ist schwer, Beispiele im Internet zu finden, bei denen Oberflächen mit Tabbern gut auf mobilen Geräten genutzt werden, was dazu geführt hat, dass Google die Material Design-Richtlinien (englisch) aufgestellt hat, die sich damit befassen.
Wenn ein Leser die Werte für eine Waffe in einem Browser-Tab und eine verwandte Waffe in einem anderen Tab geöffnet haben möchte, um sie zu vergleichen, sollte das ermöglicht werden (viele Browser erlauben es, diese Fenster nebeneinander anzuzeigen). Das ist nicht so einfach zu erledigen, wenn beide Gegenstände auf derselben Seite sind und der Leser zwischen den Tabs hin- und herschalten muss.
Um es mit den Worten unseres SEO-Leiters zu sagen: „Wenn Inhalt wichtig genug ist, um auf der Seite zu sein, warum sollte man ihn dann überhaupt verstecken wollen? (englisch)“. Die Analyse der Elemente, mit denen interagiert werden kann, zeigt einen starken Abfall des Interesses/der Klickrate jeden Tabs nach dem ersten, selbst wenn der Inhalt eigentlich von gleicher Wichtigkeit ist. Mit anderen Worten wird wahrscheinlich nur der erste Tab besucht werden. Im Durchschnitt sinkt das Interesse, den nächsten Tab zu besuchen, um 70 %. Ein zweiter Tab wird also nur 30 % der Zeit sichtbar sein, ein dritter 10 %, ein vierter nur 3 % und so weiter. Ausgehend von den Erfahrungen zeitgesteuerten Fortschreitens von Tabs in einem Carousel, ist das kein ungewöhnliches Problem im Internet.
Außerdem ist der genutzte Code, den man für die Tabber-Erweiterung braucht, für neue Autoren nicht selbsterklärend und auch der Quell-Wikitext kann selbst erfahrene Autoren verwirren beim Erstellen der erforderten enorm komplizierten Textblöcke, die von begrenzender Syntax eingerahmt werden. Es bringt oft auch den VisualEditor durcheinander, der den manchmal instabilen Code der Seite zerstört.
Diese Erklärung sagt zwar nicht „Benutze keine Tabber“, es ist aber wichtig zu wissen, was die Probleme sind, wenn man es tut und auch zu wissen, was es für Alternativen gibt. Das Aufteilen von Seiten, das Nutzen von Galerien oder Navigation in Infoboxen sind effektivere Wege, Inhalt zu präsentieren und bewahrt Seiten davor, zu lang zu werden.
TabView[]
Um eines klar zu stellen: Bitte benutze Tab view nirgends, wo es nicht schon benutzt wird.
Tabber stecken Inhalt in einen Bereich der Seite. TabView erstellt eine Benutzeroberfläche mit Tabbern und fügt dort (als Kopie von einem anderen Ort) Inhalt von einer anderen, eigenständigen Seite ein und fügt das dann in die Seite ein, die TabView nutzt.
Es gibt viele Probleme mit TabView, die uns zu dieser Empfehlung führen.
- TabView verursacht Benutzbarkeits-Probleme für Autoren, weil nicht klar ist, wo der Inhalt genau herkommt.
- TabView beeinträchtigt andere Elemente, denn der eingebundene Inhalt weiß nicht, welche Randgrenzen zu setzen sind, weswegen Elemente in Schichten aufeinander gestapelt werden. Ebenso funktioniert das JavaScript nicht richtig, wenn der eingebundene Inhalt aus einer anderen Seite JavaScript benutzt. Darüber hinaus funktionieren CSS-Selektoren nicht immer gleich, wenn der Inhalt von einem anderen Ort eingebunden wurde.
- Die Tabs von TabView sind Links, was dieselben Probleme aufzeigt wie Links in Headern. Links in Headern führen zu Problemen der Benutzererfahrung auf verschiedenen Oberflächen (z. B. Unklarheit, ob das Tippen auf einen eingeklappten Header im mobilen Skin diesen ausklappt oder zu einer anderen Seite führt), führen zu weniger beständigem Verständnis bei Lesern (z. B. „Muss ich jetzt zu dieser anderen Seite zuerst gehen?“, „Wie ist die Beziehung zwischen diesem Abschnitt und der Seite, die verlinkt wird?“) und auch Software wie Vorlese-Anwendungen oder Suchmaschinen verstehen dieses Verhalten nicht.
- TabView erzeugt eine große Abweichung zwischen mobilen und Desktop-Ansichten, was Google in Betracht ziehen lässt, die Community basierend auf der Inhaltsqualität herunterzustufen, was noch dadurch verdoppelt wird, dass es große Mengen doppelten Inhalts gibt (was an sich schon schlecht für das Suchmaschinen-Crawling ist).
- Wenn das JavaScript schließlich auf dem Computer verarbeitet wird, verlangsamt der Code die Seite, aufgrund der Art und Weise, wie die Informationen aus der anderen Seite gezogen werden. Außerdem passiert das auf dem Gerät, das sich die Seite ansieht, was schnell im Datenverbrauch des Lesers zu Buche schlägt.
- Seiten, die eingebunden werden, tauchen nicht einheitlich als Seitenaufrufe in den Analytics auf, was das Zählen dieser Seitenaufrufe erschwert.
- Und auf einem mobilen Gerät produziert TabView eine Liste an Links, bei denen nicht klar ist, warum sie dort hinführen, wo sie hinführen, weil es keinen Kontext gibt.
Statt TabView empfehlen wir dringend die Aufteilungsmethode von oben zu benutzen.
Tabs und Suche[]
So, nachdem wir das geklärt haben, sollten wir noch darüber sprechen, wie Seitentabs, Tabber, TabView etc. Suchmaschinen beeinflussen.
Wie bereits in dem Abschnitt über „Stubs“ gesagt wurde: Was wir vermeiden wollen – aus Benutzererfahrungs- und Suchmaschinen-Sicht – sind unvollständige Seiten. Das hat denselben Grund bei Menschen und Suchmaschinen, was nicht überraschend ist, wenn man darüber nachdenkt, dass Suchmaschinen so aufgebaut sind, dass sie das menschliche Verhalten imitieren sollen.
Wenn du eine eindeutige „Inhalts-Entität“ hast – das ist ein „ein einzigartiges, unabhängiges Objekt“ korrekt ausgedrückt, ob das jetzt eine einzelne Person, ein Objekt, ein Ort oder irgendeine Art eines bestimmten Nomens ist – sollte es sich normalerweise auf einem Hauptartikel (und nicht auf einer Unterseite) befinden. Jegliche Unterseiten sind für Dinge gedacht, die sich ableiten lassen und ohne den Hauptartikel nicht existieren können. Wenn du über [[Jon Snow/Staffel 1]] oder [[Cloud Strife/Final Fantasy VII Remake]] sprichst, ist klar verständlich, dass du über bestimmte Aspekte oder Handlungen des Hauptartikels sprichst.
Aus der Sicht einer Suchmaschine: Wenn es auf der gleichen Browserseite ist (selbst, wenn es von einer anderen Seite eingebunden wird), beschreibt es das Thema des Hauptartikels. Wenn man Inhalt für „FishTank#Schwert“ hinzufügen würde, könnte Google denken, dass ich vielmehr ein scharfes Stück Metall bin als eine Person. Deswegen ist es besser, dass sich mein Schwert – es gibt viele wie dieses, aber dieses eine ist das von mir – auf einer seperaten Seite mit eigener URL befindet.
Wie weiter oben schon mit dem „Warum sollte man Inhalt verstecken wollen“ darauf angespielt wurde, wenn man Inhalt in einem zweiten (oder hinteren) Tab verbirgt, wird es mit einer Kombination aus CSS und JavaScript als versteckt markiert und erst durch Interaktion sichtbar gemacht. „Lazy-loaded Bilder“ (also Bilder, die erst geladen werden, wenn das Fenster im Fokus ist) werden erst dann effektiv oder schnell angezeigt, wenn das JavaScript auf ihren Servern in einer verzögerten Warteschlange entfaltet wird (englisch). Aus Googles Sicht sind Texte und Bilder, die auf diese Weise versteckt werden, weniger wichtig als das, was direkt nach dem Laden der Seite sichtbar ist. Außerdem: Das zusätzliche JavaScript, das für die Interaktion nötig ist, addiert sich zur gesamten benötigten Nutzlast der Seite und verlangsamt deren Ladezeit. Daher ist Inhalt hinter versteckten Tabs üblicherweise kein gutes Suchmaschinen-relevantes (SEO) Vorgehen.
Die Größe von Seiten[]
Seiten jeder Größe können als vollständig betrachtet werden. Der Schlüssel ist, Leser interessiert zu halten und sie die Antworten finden zu lassen, die sie suchen. Ob du die Größe deiner Seite durch Tabs oder andere Dinge reduzierst, sicherzustellen, dass die Seiten vollständig bleiben, ist der Weg zu einer guten Wiki-Gesundheit. Tabs und Tabber sollten vorsichtig genutzt werden, es gibt Alternativen, die deinen großartigen Inhalt besser zur Schau stellen können.
- Exhibit in the Sanada Treasure Museum, 4-1 Matsushiromachi, Matsushiro, Nagano, Japan. by Daderot via Wikimedia Commons, CC0
- Starship Troopers - Popular meme animation, Fair Use
- Mossy stump, Daniel Kraft / CC BY-SA (https://creativecommons.org/licenses/by-sa/3.0)