Die richtigen Design-Entscheidungen treffen

Alles verändert sich. Manche Dinge bleiben klassisch und zeitlos, andere kommen aus der Mode, sind plötzlich angesagt, oder entwickeln sich weiter. Wenn wir Wiki-Communitys aufbauen, ist eine der größten Herausforderungen, diese am Leser auszurichten. Das Publikum hier auf FANDOM hat sich über die Zeit zu einer mobilen und „Second Screen“-Leserschaft gemausert. Egal ob auf dem Smartphone oder dem Tablet, Leser wollen mehr darüber erfahren, was gerade auf ihrem Fernseher, Monitor, Kopfhörer (oder im Print-Medium 😉 ) stattfindet. Fans sind auf der Suche nach weiterem Kontext und Hintergrundinfos, Walkthroughs, Lösungen und Tipps, Theorien und Diskussionen – und einige suchen sogar gezielt Spoiler! Wir können nicht ignorieren, dass die meisten Communitys über eine erhebliche Anzahl an mobilen Lesern verfügen – diese machen nicht selten 60% oder mehr der gesamten Seitenaufrufe aus.

Aber was genau kannst du tun, um den Lesern und Autoren deiner Community das bestmögliche Wiki-Erlebnis zu garantieren und damit auch deiner Wiki-Community eine möglichst lange und aktive Existenz zu garantieren? Orientiere dich an ein paar Design-Regeln, mit denen du Nutzer von mobilen Browsern anziehst und nicht vergraulst. Jedem, der versucht, die Desktop-Ansicht objektiv zu betrachten, leuchtet in der Regel sofort ein, dass dieses Layout für kleine Bildschirme ungeeignet ist. Deshalb ist auch ein Verweis „in die Desktop-Ansicht zu wechseln“ alles andere als eine gute Idee. Werfen wir deshalb einen Blick auf einige alte Gewohnheiten, die auf FANDOM noch häufig Anwendung finden, den Lesern allerdings nicht vernachlässigbare Schwierigkeiten bereiten können.

Navigation

Ein typisches Überbleibsel der Wikipedia und anderen frühen Wikis sind die sogenannten „Navbox“-Vorlagen, die meist am Ende einer Seite zu finden sind und Links zu ähnlichen Seiten beinhalten.

Eine typische Navbox.

Diese oft in eine Tabelle gepresste Linksammlung ist alles andere als mobilfreundlich. Bis vor kurzem wurden z. B. auch in den mobilen Versionen der Wikipedia diese Navboxen nicht angezeigt – unter anderem auch aus ästhetischen Gründen. Es gibt mehrere bessere Möglichkeiten, die Navigation zu Artikelseiten anzugehen, wie ein gutes Kategoriensystem oder die mobile Hauptseite; außerdem kann hierfür auch der <navigation>-Tag in den Infoboxen herangezogen werden.

Derzeit gibt es keine einheitliche Lösung, was die Verwendung von horizontalen Listen anbelangt – teils weil unterschiedliche Communitys diese unterschiedlich designen – was nicht selten zu sehr, sehr langen Navboxen führt. Dazu kommt, dass in der mobilen Ansicht das Styling entfernt wird. Weil dadurch in der mobilen Ansicht vergleichsweise viel Platz für Navboxen verschwendet würde, und weil es gute Alternativen gibt, werden als Navboxen klassifizierte Vorlagen in der mobilen Ansicht nicht dargestellt.

Hier ein paar Faustregeln:

• Ist ein Artikel Teil einer Artikelgruppe, bei der die Reihenfolge keine Rolle spielt, könnte eine Kategorie die bessere Lösung sein. Kategorien funktionieren sowohl in der mobilen Ansicht als auch auf mobilen Hauptseiten wunderbar. Außerdem können sie mit Wikitext verlinkt werden und weitere Informationen enthalten, genauso wie eine Artikelseite, und so weiteren Kontext für den Leser und auch Suchmaschinen liefern.
• Ist ein Artikel Teil einer geordneten Gruppe von Artikeln, bei denen die Reihenfolge relevant ist (z. B. welche Episode vorher und welche danach kommt), sollte diese Art Navigation idealerweise über die <data>-Felder der Infoboxen erfolgen.
• Verfügt ein Artikel über eine hierarchische Beziehung zu anderen Artikeln (bspw. eine Galerie-Seite oder andere Unterseiten, die zu einem Hauptartikel gehören), bietet sich das <navigation>-Feld in Infoboxen an.

Die Navigation über Tabs am Anfang von Artikelseiten sieht man gelegentlich noch immer in einigen Wikis und werden meist verwendet, um auf Unterseiten zu verweisen. Diese stellen allerdings eine nicht zu unterschätzende Herausforderung für Leser dar, da die Funktionsweise auf mobilen Geräten teils sehr stark eingeschränkt. Auch Suchmaschinenbots haben Schwierigkeiten, diese Struktur zu verstehen. In den meisten Fällen ist es daher besser, diese Art von Navigation in die Infoboxen zu verlegen.

Tabs

Tabs, in Tabs, in Tabs, in Tabs.

Tabs können ein guter Weg sein, um Informationen anzuzeigen und zu organisieren. Meistens ist das Problem allerdings, dass Communitys Tabs nicht richtig einsetzen. Zudem haben einige Wikis eigene, individuelle und spezialisierte Lösungen und Varianten um Tabs darzustellen, die sich oft anders verhalten als die von FANDOM bereitgestellte <tabber>-Erweiterung. Folgende Ratschläge beziehen sich allerdings auf alle Tab-Versionen gleichermaßen.

„Lege dich auf eine Reihe an Tabs fest. Mehrere Reihen können zu umherspringenden Elementen führen, die unser räumliches Erinnerungsvermögen negativ beeinflussen und es Nutzern enorm erschweren zu erkennen, welche Tabs sie bereits besucht haben. Zudem sind mehrere Reihen von Tabs ein sicheres Symptom überbordender Komplexität: Wenn du mehr Tabs brauchst als in eine Reihe passen, musst du dein Design vereinfachen.“

— Jakob Nielsen, Ph.D., anerkannter Experte für Software- und Webdesign-Gebrauchstauglichkeit

„Es ist wichtig, dem Nutzer seine Möglichkeiten aufzuzeigen. Diese sollten sich logisch auf derselben Ebene befinden. Wenn du an Musik denkst, könnten bspw. die Genres als Tabs dargestellt werden. Bei einer Nachrichten-App könnten es die Rubriken oder Themen sein. Vermische auf keinen Fall unterschiedliche Kategorien miteinander. Das verwirrt den Nutzer nur und bietet keine übersichtliche Auswahl.“

— Mobiscroll, eine auf Nutzerschnittstellen in Webkomponenten spezialisierte Firma

„Stelle Tabs als einzelne Reihe über dem Inhalt dar, der zu ihnen gehört. Die Beschriftung der Tabs sollte kurz und knapp aber verständlich den jeweiligen Inhalt beschreiben.“

— Googles Richtlinien für das „Material Design“

Tabs müssen einfach sein, um effizient nutzbar zu sein und sollten niemals ineinander verschachtelt werden. Verwendet dein Wiki außergewöhnlich viele Tabs für Bilder in einer Infobox, solltest du in Erwägung ziehen, diese entweder auf der Seite zu verteilen oder in einer Galerie zusammenzufassen. Mit Galerien erhältst du in der Desktop-Ansicht eine typische Galerie, die du noch speziell stylen kannst. In der mobilen Ansicht erhältst du eine Art Diashow, durch die du wischen kannst und die speziell für geringes Datenvolumen ausgelegt ist. In beiden Fällen kannst du deine Bilder mit Bildunterschriften näher erläutern.

Sollte es aus bestimmten Gründen unausweichlich sein, die Inhalte eines Artikels mit Tabs zu organisieren, dann stelle sicher, dass die Organisation innerhalb der Tabs Sinn ergibt! Auf Geräten, die nicht die Desktop-Ansicht verwenden, werden die Tab-Inhalte untereinander dargestellt, unabhängig davon ob die Tabs beschriftet sind oder nicht. Durch die Verwendung von Überschriften kannst du dem zumindest ein bisschen entgegenwirken. In jedem Fall gilt: Es ist überhaupt nichts verkehrt an langen Artikeln! Du solltest dich immer fragen, ob das Verstecken von Inhalten mithilfe von Tabs überhaupt nötig und sinnvoll ist.

Die Erweiterung Tab view funktioniert stattdessen etwas anders. Mit ihr werden statt Inhalten auf einer Seite, andere Artikelseiten als Tab eingebunden. Während das auf dem Desktop komfortabel sein kann, wird in der mobilen Version nur eine Liste mit Links zu den entsprechenden Seiten angezeigt. An sich ist das keine schlechte Sache (weil alle Seiten weiterhin zugänglich bleiben), allerdings sollte man auch andere Blickwinkel in Betracht ziehen. Über Suchmaschinen-Ergebnisse können Leser bspw. direkt auf die eingebundene Seite geleitet werden, und nicht zur eigentlichen übergeordneten Seite. Dadurch wird wiederum die Navigation zur übergeordneten Seite und den dort via Tab view eingebundenen Seiten erschwert.

Daten

Es gibt Communitys, die davon überzeugt sind, dass ihre Artikel keine Daten oder Infoboxen beinhalten. Stattdessen legen sie den Fokus auf erzählende Inhalte. Der offizielle Standpunkt von FANDOM allerdings ist, dass ein Element de facto eine Infobox ist (oder ein Artikel eine verdient), wenn dieses über einen Titel und mindestens ein Bild verfügt, sowie das Thema der Artikelseite mit Eigenschaften und Werten beschreibt. Und das vollkommen unabhängig vom Layout. Infoboxen sind in der Regel der direkte und offensichtliche Einstiegspunkt für fast jeden Artikel, weshalb sie auch so prominent in der mobilen Ansicht angezeigt werden.

Was den Wenigsten bewusst ist, ist wie wichtig die einzelnen Daten einer Infobox sind. Dazu gehört im Endeffekt alles, was nicht in einem <navigation>-Tag steckt: Also Titel, Bild, einzelne Werte etc. Und damit die Daten einigermaßen gut organisiert sind, muss man sich ein bisschen Zeit für die Instandhaltung und Wartung der Infoboxen nehmen. Dazu gehört u. a. auch, dass es für unterschiedliche Dinge entsprechende Infoboxen mit spezialisierten Daten gibt. Das kann so einfach sein, wie bspw. Landfahrzeuge von Flugzeugen zu trennen. Wenn dein Wiki wächst und du weiter differenzieren willst oder musst, kann es sinnvoll sein nun z. B. LKWs von Motorrädern, oder Helikopter von Flugzeugen zu unterscheiden.

Idealerweise sollte in den einzelnen <data>-Feldern jeweils nur ein bestimmter Wert zu finden sein und dabei solltest du nach Möglichkeit in einem Feld nie Zahlen mit Wörtern vermischen oder unterschiedliche Datenformate verwenden. Wenn ein Objekt etwa „100 Goldstücke“ kostet, sollte der eingetragene Wert in der Infobox „100“ sein. In der Vorlage selber kann weiterer Kontext (über Text oder Info-Icons) mit dem <format>-Tag hinzugefügt werden.

Oft finden sich in Infoboxen Listen mit Werten. Von einem datenzentrierten Standpunkt aus ist eine Wikitext-Liste meist besser als eine mit Kommas oder Strichpunkten getrennte Aufzählung. Zwar gibt es keine allgemein gültige Methode um horizontale Listen zu erstellen, aber es gibt einige Möglichkeiten, die wir empfehlen. Eine Liste ist auch wesentlich effektiver als mehrere Parameter, wenn die Inhalte gleichwertig sind.

In anderen Worten:

| Gegenstand1 = Apfel
| Gegenstand2 = Banane

sollte vermieden werden zugunsten

| Gegenstand =
* Apfel
* Banane

Es gibt zwar keinen direkt sichtbaren positiven Effekt, aber auf lange Sicht betrachtet erlaubt diese Herangehensweise bei der Erfassung von Daten Scripten und Crawlern eine einfachere Interpretation der Inhalte. Und auch Leser mit Sehbeeinträchtigungen erhalten einen Vorteil, weil Screenreader die Seite besser verstehen können. Zudem erlauben Listen auch einige nette CSS-Spielereien für die Desktop-Enthusiasten. 😉

Die plattformunabhängigen Infoboxen zeichnet vor allem ihre Einfachheit im Code aus, von der auch die Servergeschwindigkeit profitiert. Sie fressen wesentlich weniger Ressourcen als Wikitext-Infoboxen, die aus mehreren Vorlagen zusammengebaut werden oder diverse Unter-Vorlagen aufrufen. Jede Vorlage sollte mit dem Grundgedanken entwickelt werden, nur eine ganz bestimmte Sache zu erledigen – die aber dafür richtig gut. Dahingehend sollten Infoboxen auch nie ineinander verschachtelt werden. Eine Infobox sollte immer eine Sache beschreiben. Verwandte oder ähnliche Dinge sind in individuellen Abschnitten oder auf extra Seiten besser aufgehoben.

Zu guter Letzt raten wir davon ab, mehrere Infoboxen auf einer Artikelseite zu verwenden, da das Ergebnis in der mobilen Ansicht schwer für den Leser zu interpretieren ist. Manche Wiki-Communitys fassen mehrere Infoboxen in Tabs oder Drop-down-Menüs zusammen. Es gibt derzeit zwar keine gute Alternative hierfür, doch viele Communitys haben bereits damit angefangen, mehrere Infoboxen zu einer zusammenzufassen und die Inhalte in Gruppen zu strukturieren. Beispiel: Gegner-Werte aus der PC-Version eines Spiels kommen unter den Header „PC“, die Werte aus der PlayStation-Version unter den Header „PlayStation“. Alternative: Umfangreiche Statistiken in Tabellen auslagern.

Bilder

Nicht selten nehmen Leute an: Je mehr Bilder, desto besser! Also stopfen sie jedes einzelne Bild, das sie finden können, in eine einzige Galerie - ohne viel über Organisation, Relevanz oder weiterführende Navigationsmöglichkeiten nachzudenken. Das Ergebnis ist, dass der Leser von einer Lawine an Bildern überrollt wird.

Das sind einfach zu viele Bilder-Tabs in einer Infobox.

Wenn du deinen Bildern ordentliche Dateinamen verpasst, kannst du deine Auffindbarkeit in Suchmaschinen verbessern. Und du willst schließlich mehr Leute für dein Wiki gewinnen, oder? Aber selbst ein guter Dateiname schützt nicht vor einer Reizüberflutung bei über 100 Bildern in einer Galerie. Beste Lösung? Reduziere die Anzahl der Bilder drastisch. Löse Bilder, die im Artikeltext Sinn ergeben, heraus und verteile sie auf der Seite, um zusätzlichen Kontext zu liefern. Das erspart den Lesern endloses Scrollen und die Bilder erfüllen ihren eigentlichen Zweck: Den Text zu illustrieren, anstatt einen Gegenpol zu bilden.

Infoboxen sind außerdem keine Bildergalerien! Nicht einmal theoretisch. Sie sollen dem Leser ermöglichen, leicht zu verdauende Informationen in einem attraktiven und kompakten Format zu konsumieren. Anders gesagt: Eine Infobox ist lediglich der Einstieg ins eigentliche Thema der Seite.

Deswegen sollten in einer Infobox nur ein paar wenige, dafür aber die wichtigsten Bilder des Themas zu finden sein und gleichwertigen Informationsgehalt liefern. Beispiel: Anime- und Manga-Version eines Charakters und keine allumfängliche Kollektion aller Outfits des Charakters.

Weitere Tipps zu Bildern

• Bilder alleine retten keine SEO. (SEO = Search Engine Optimiziation, also die Optimierung der Seite für Suchmaschien.) Klar, sie helfen. Aber ohne ausreichend Text, der den Informationsgehalt der Seite erhöht, bringt ein Übergewicht an Bildern nicht wirklich viel. Stattdessen können zu viele Bilder die Platzierung in Suchergebnissen sogar negativ beeinflussen.
• Mach eine Galerieseite zu einer qualitativ hochwertigen Seite. Konzentriere Bilder z. B. um ein bestimmtes Thema herum, passenderweise zu einem bestimmten Artikel. Beispielsweise eine „Naruto und Ramen/Bilder“-Galerie die zur „Naruto und Ramen“-Artikelseite verlinkt.
• Verwende eine einfache und klare Sprache bei der Benennung deiner Bilder. Vergiss nicht: Dateinamen sollten so beschreibend wie möglich sein, denn Suchmaschinen sind quasi blind und können die Bilder sonst nicht voneinander unterscheiden. „Spider-Man_hängt_am_Netz.jpg“ ist besser als „img242.jpg“.
• Nimm dir die Zeit, die Dateibeschreibungsseite auszufüllen. Diese sind wichtig, damit Suchmaschinen die Bilder besser verstehen können. Betrachte sie als „Werbetext“ für dein Bild, mit dem du mehr Besucher in dein Wiki locken möchtest.

Layout und Design

Manchmal fällt es sofort auf, dass eine Seite in der mobilen Ansicht nicht so aussieht, wie sie aussehen sollte. In fast allen Fällen reicht es aber, den Code auf der Seite entsprechend zu überarbeiten und responsiv zu gestalten. Nicht vergessen: Lokale Anpassungen im JavaScript und CSS werden in der mobilen Ansicht nicht berücksichtigt, also nicht geladen.

Tabellen sind beliebt auf FANDOM. Richtig eingesetzt, kann man mit ihnen wunderbar Daten sammeln und vergleichen. Auf mobilen Geräten und vor allem meist hochformatig genutzten Smartphones sind sie aufgrund der schmalen Bildschirmgröße aber mit Vorsicht zu genießen.

Checkliste für gute Tabellen:

• Kontrolliere deine Tabellen nach Möglichkeit immer auf einem Smartphone bzw. in der mobilen Ansicht. Hast du kein Smartphone zur Hand, verwende die mobile Vorschau (und verkleinere dein Browserfenster), den URL-Parameter ?useskin=mercury (ebenfalls in Kombination mit einem verkleinerte Browserfenster) oder nutze den Bildschirmgrößen-Check der eingebauten Entwicklertools deines Browsers.
• Setze dir ein Limit von vier Spalten oder rund 600px. Alles, was darüber hinausgeht ist nur durch horizontales Wischen erreichbar, was in manchen Tabellen für den Leser nicht direkt ersichtlich ist und bei langen Tabellen äußerst anstrengend ist. So verliert man schnell den Kontext aus den Augen (im wahrsten Sinne des Wortes).
• Verzichte auf colspan und rowspan.
• Verschachtle keine Tabellen ineinander.
• Verwende Tabellenüberschriften. Sie repräsentieren den „Titel“ der Tabelle.
• Verwende scope="col" oder scope="row" wenn eine Überschrift zu einer Spalte oder Reihe gehört.
• Tabellen sind eine der wenigen Ausnahmen, in denen du Inline-Styling verwenden darfst. Wenn du aber ein einheitliches Styling verwenden willst, empfiehlt es sich, die offiziellen Standard-Klassen auf MediaWiki:Wikia.css anzupassen: article-table, WikiaTable und wikitable.
• Die Anpassung der folgenden CSS-Klassen ist ebenfalls erlaubt: mw-collapsed, mw-collapsible, noprint, nowraplinks, plainlinks und sortable
• Verzichte nach Möglichkeit auf Bilder in einer Tabelle. Text ist oft besser erkennbar für den Leser, vor allem auf kleinen Bildschirmen. Wenn du in einem Videospiele-Wiki aber z. B. zur Illustration Icons aus dem Spiel verwenden willst, stelle sicher, dass diese klein und alle gleich groß sind. Mit einer Größe von bspw. 22px bis 25px bist du auf der sicheren Seite und läufst nicht Gefahr, dass die Bilder in der mobilen Ansicht zu groß angezeigt werden.
• Lege keine neuen Tabellenzeilen mithilfe einer Vorlage an. Der Server braucht sonst mehrere Anläufe, um die Tabelle zu laden und kommt ggf. durcheinander, die Tabelle so an den verwendeten Bildschirm anzupassen.
• Wenn du gegen keine dieser Richtlinien verstößt, solltest du am Ende in der mobilen Ansicht eine zebrastreifenartige Tabelle sehen (stell dir ein bläuliches Zebra vor), mit wechselnder Farbgebung, um die Lesbarkeit zu erhöhen.

https://www.hotdesign.com/seybold/german/

Einige Wikis und Benutzer verwenden immer noch gerne Tabellen für das Design und Layout einer Seite. Hört auf damit! Tabellen sind für Daten. Und das wissen wir spätestens seit 2004.

Jedes Element mit einer festen Breite größer als 600px wird auf irgendeinem Gerät Probleme verursachen, egal ob das Element von Natur aus plattformunabhängig gestaltet ist oder nicht. Selbst bei einer „portablen Infobox“, die in der Desktop-Ansicht auf die volle zur Verfügung stehende Breite vergrößert wurde, kann es in der mobilen Ansicht zu Problemen kommen. Es ist äußerst schwierig, zeitintensiv – und in vielen Fällen einfach unmöglich – diese Art von Infoboxen für die mobile Ansicht umzuwandeln. Überlege dir, ob dein Wiki wirklich auf Infoboxen mit der vollen Breite angewiesen ist. Wir von FANDOM empfehlen eine maximale Breite von 300px für die Infoboxen, sofern diese überhaupt abweichend von ihrer Standardgröße angepasst werden muss.

Neben <infobox> gibt es aber noch eine Reihe weiterer Elemente, die plattformunabhängig sind und für eine Reihe unterschiedlicher Bildschirmgrößen ausgelegt sind. Eine der vielseitigsten Funktionen wäre zum Beispiel <gallery>. Bildergalerien können nicht nur zum Ausstellen von Bildern, sondern u. a. auch für Navigationsportale verwendet werden - und sehen eigentlich immer gut aus. Und sie belasten Volumentarife nicht unnötig. <references> kann sowohl für Fußnoten, als auch als Tooltip-Ersatz eingesetzt werden. Mit diesen Funktionen bist du immer auf der sicheren Seite, im Gegensatz zu JavaScript-Lösungen oder Wikitext-Workarounds.

Viele alte Vorlagen verwenden Inline-Styling und geben Elementen Platzhalter für Farben vor, die dann pro Artikel definiert werden können. Wir bei FANDOM sind der Meinung, dass es einen besseren Weg gibt, der gleichzeitig die Gefahr von Vandalismus, Hexcode-Tippfehlern und anderen Fallstricken vermindert. Für diese Fälle eigenen sich CSS-Klassen viel besser, nicht nur um einen einheitlichen Stil festlegen. Klassen können zwar nur noch von Admins bearbeitet werden, aber die Sicherheit, Einheitlichkeit und die einfache Anpassung von Designs im gesamten Wiki sind diesen Kompromiss wert.

Farben sind (in Maßen) ein mächtiges Werkzeug. Farben müssen vernünftig eingesetzt werden und nicht wirr und durcheinander. Verwende kein grelles Pink, nur weil du es kannst. Setze Farben so ein, dass sie zum restlichen Erscheinungsbild und Farbschema passen. Mit Farben eine bestimmte Bedeutung auszudrücken (sogenanntes „color coding“ bzw. Farbkennzeichnung), schließt deine farbenblinde Leserschaft direkt aus. Setze stattdessen auf ein einen hohen Farbkontrast (also die Lesbarkeit von Text auf seinem Hintergrund) und eine einfache Farbauswahl, um Rücksicht auf alle Menschen mit Sehbeeinträchtigungen zu nehmen. Auch die Transparenz ist hier ein wichtiger Faktor. Diese sollte stets nur so hoch sein, dass der Hintergrund nicht ständig sichtbar seine Farbe wechselt. Dies macht sonst den Text schwer lesbar.

Achte auf die Farbpalette des Themas, das du in deinem Wiki behandelst. Im Supergirl Wiki bieten sich bspw. rote, gelbe und blaue Farben für das Design an, bei Mass Effect eher Blau, Schwarz und Weiß/Grau. Orientiere dich dafür zum Beispiel an den offiziellen Logos oder Artworks des jeweiligen Themas. Lege dich dabei auf eine handvoll Farben fest, damit die Seite gut lesbar und visuell attraktiv bleibt.

Interaktivität

In unserer mobilen Ansicht verzichten wir aus guten Gründen auf die Ausführung von JavaScript. Was wir als „Inhalte“ bezeichnen (Texte, Bilder, Videos etc.) befindet sich normalerweise auf Artikelseiten. Was interaktive Funktionen mit diesen Inhalten angeht, sind diese in der Regel in einer extra App oder einem gesonderten Programm besser aufgehoben, als im Browser.

Manche Communitys vermischen mit JavaScript realisierte, interaktive Elemente (wie z. B. das dynamische Erstellen von Graphen) mit den eigentlichen Inhalten von Artikelseiten. Dabei sollte es immer eine komfortable und elegante Ausweichmöglichkeit für Geräte geben, die kein JavaScript ausführen können, um dem Leser die eigentlichen Inhalte weiterhin zur Verfügung stellen zu können. Wir raten von der Verwendung von CSS-Klassen ab, um Elemente einer Seite in der Desktop- oder Mobil-Ansicht zu verstecken oder die Anzeige zu erzwingen.

Wird für die Anzeige einer kompletten Seite oder deren Inhalt JavaScript benötigt, kann man argumentieren, dass es sich um keine klassischen „Inhalte“ handelt, sondern um eine Funktion. JavaScript, welches eine komplette Wiki-Community betrifft, sollte sich immer im MediaWiki-Namensraum befinden. Die Ausgabe des Codes – wenn es sich nicht um statische Informationen sondern bspw. eine interaktive Funktion wie einen Statistik-Rechner handelt – sollte sich in einem „Nicht-Inhaltsnamensraum“ wie Spezial: oder Projekt befinden und nicht im eigentlich Artikelnamensraum.

Und abschließend gilt auch hier: Überprüfe die Seite in der mobilen Ansicht. Wenn aufgrund des JavaScripts wichtige Informationen nicht angezeigt werden (oder schlimmer: die komplette Seite leer ist), ignorierst du durchschnittlich die Hälfte deiner Leserschaft. Trau dich, FANDOM-Mitarbeiter oder die Portabilitäts-Pioniere anzusprechen und nach Rat zu fragen, wenn du dir nicht sicher bist, was das Problem sein könnte. Wir werden dir so gut wie möglich helfen.

Fazit

Wenn du diese Tipps und Ratschläge beim Auf- und Ausbau deines Wikis im Kopf behältst, ist deine Community langfristig gut aufgestellt. Mit intelligenten Design-Entscheidungen musst du nicht ständig nachjustieren, weil wieder etwas anderes angezeigt wird, als du es dir vorgestellt hast. Darüber hinaus vergraulst du keine Leser, egal wie sie deine Seite entdecken, nur weil sie das Wiki nicht mit genau den Voraussetzungen betreten, die du ihnen möglicherweise vorzugeben versucht. Nutze die Zeit über diese Entscheidungen nachzudenken und du wirst feststellen, dass es gut investierte Zeit ist, wenn es um das dauerhafte Wohlbefinden deiner Community geht.

Was ist deine Meinung zu diesem Thema? Siehst du es genau so, oder im schlimmsten Fall komplett anders? Teile uns deine Erfahrungen in den Kommentaren mit!

Bosso

Der Bosso ist seit 2011 Teil des Community-Development-Teams bei FANDOM Deutschland. Er kümmert sich um inhaltliche und technische Belange aller Communitys, mit einem Fokus auf Gaming und Lifestyle Wikis, bedient die Social-Media-Kanäle und ist „Spezialist für allerlei Dinge“. Der Bosso mag Rollen- und Strategiespiele, gute Geschichten, Musik mit Stil, Bier, Whiskey und Tabakspfeifen. Bereits länger spielt er mit dem Gedanken, sich mal wieder einen reinen Backenbart zu rasieren.

Profil ansehen

Willst du weitere Updates von Fandom erhalten? Klicke hier, um diesen Blog zu verfolgen.