Wikipedia:Umfragen/Technische Wünsche 2017/Lesen

Bitte nicht mehr abstimmen - diese Umfrage ist abgeschlossen. Herzlichen Dank an alle, die Vorschläge eingereicht, abgestimmt und die Umfrage mit fachlichem Rat begleitet haben.

Vorschau von Einzelnachweisen

Was ist das Problem?

Während des Lesens Einzelnachweise anzusehen, ist oft zu umständlich. Durch das Klicken auf einen Einzelnachweis (EN) an das Ende des Textes springt und dass man nach dem Lesen den richtigen der zum Teil vielen Buchstaben („42. ↑ a b c d e f g“) auswählen muss (oder eben die „Zurück“-Taste des Browsers nutzen muss), wird der Lesefluss unterbrochen. So lässt es sich nicht sinnvoll vereinen, einen Text angenehm zu lesen und währenddessen die Quellen anzusehen.

(10:36, 2. Jun. 2017 (CEST)) Einem Tool (Einstellungen: Fußnoten-Tooltip), das im Sinne des Lösungsvorschlages dies Problem lösen könnte und in den persönlichen Einstellungen aktiviert werden kann, liegt problematischerweise ein Code zugrunde, der „ein modifizierter Fork aus der englischen Wikipedia [ist], der praktisch nicht mehr gepflegt wird. Neben bereits bestehenden Problemen ist daher damit zu rechnen, dass die Funktion sich in Zukunft immer weiter verschlechtert, ohne dass etwas dagegen unternommen wird. Bekannte Probleme sind unter anderem die Schriftgröße, die deutlich kleiner ist als die Einzelnachweise im Normalfall, fehlende Symbole für externe Links, mangelhafte Barrierefreiheit bei einer Kombination von Screenreader und Touchscreen und weitere Kleinigkeiten, die am Ende von Wikipedia:Verbesserungsvorschläge/Archiv/2012/August#MouseOver bei Einzelnachweisen genannt sind. Zudem wurde in Einzelfällen berichtet, dass die Popups entgegen der Konfiguration nur auf Klick erscheinen, bei einem weiteren Klick um den Inhalt zu markieren und kopieren aber wieder verschwinden. Außerdem ist für die Zukunft eine Änderung der HTML-Struktur von Einzelnachweisen geplant, die dazu führen würde, dass das Skript diese in seinem gegenwärtigen Zustand nicht mehr finden würde und damit nicht mehr anzeigen könnte.“ (Schnark in der Diskussion)

Wen betrifft das Problem besonders?

Lesende im Allgemeinen. (10:36, 2. Jun. 2017 (CEST)) Unangemeldete Benutzer sind (siehe oben) noch stärker betroffen.

Lösungsvorschlag

Berührt („hovert“) man Links auf Einzelnachweise („[42]“) ohne zu klicken, so soll der Inhalt des Einzelnachweises (EN) automatisch angezeigt werden. Es soll also, wenn man den EN-Link berührt, eine Art Kasten erscheinen, in dem der EN-Inhalt – das, was zwischen <ref> und </ref> steht – angezeigt wird (inklusive Links etc.). Beispiel sollen die EN der englischsprachigen Wikipedia sein.

(10:36, 2. Jun. 2017 (CEST)) Eine standardmäßige Aktivierung der Einstellung „Fußnoten-Tooltip“ würde dies Problem im Sinne des obigen Abschnittes lösen, ist aber mit weiteren Probelemen (2. Abschnitt „Problem“) verbunden.

Vorschlagende Person

Rübenkopf 10:31, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Rübenkopf (Einreichende Person)


Sortierbare Tabellen in der Mobilversion ermöglichen

Was ist das Problem?
  • mit der Klasse sortable ausgestattete Wikitabellen können in der Desktopansicht per JavaScript sortiert werden.
  • in der Mobilversion ist das nicht möglich
    • mitunter wird im Artikeltext explizit auf das mögliche Sortieren einer Tabelle hingewiesen
    • in der Mobilversion, über die rund 50% aller Zugriffe auf unsere Inhalte erfolgen, gehen diese Hinweise ins Leere und verwirren den Leser
    • die Sortierfunktion stellt gerade bei großen Tabellen ein wichtiges Werkzeug zum Erfassen der Inhalte dar, dieses wird so der Hälfte unserer Leser verwehrt.
Wen betrifft das Problem besonders?
  • Leser und Autoren
Lösungsvorschlag

phab:T49858 behandelt dieses Problem

Vorschlagende Person

hgzh

Unterstützung
  1. Pro Hgzh (Einreichende Person)
  2. Pro Rewo (Diskussion) 11:06, 19. Jun. 2017 (CEST)[Beantworten]


Was ist das Problem?
  • Derzeit ist es bei einer Mehrfachreferenzierung nahezu unmöglich, aus der Anmerkung mit vielen Link-Buchstaben wieder genau zu der Textstelle zu springen, von der aus die Fußnote angeklickt wurde. Bsp.: Pfullendorf hat in Fußnote 2 die Link-Buchstaben a bis l. Das wird ein Lotteriespiel, wieder in den Text oben zu kommen, und ist kaum zumutbar.
Wen betrifft das Problem besonders?

Alle Leser, die (aus welchen Gründen auch immer) nicht nur die Mouse-over-Mini-Vorschau (s. Vorschlag oben zur Hover-Funktion [die ich aktiviert habe]), benutzen wollen, sondern die Fußnote in voller Schriftgröße betrachten wollen und deshalb die Fußnotenziffer im Text angeklickt haben.

Lösungsvorschlag

Es wäre viel getan, wenn der zutreffende Link-Buchstabe hervorgehoben würde: Fettschreibung, Unterstreichung, Rahmung o. dgl. Danke!

Vorschlagende Person

Wi-luc-ky (Diskussion) 14:57, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Wi-luc-ky (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:15, 19. Jun. 2017 (CEST)[Beantworten]


Einfaches dauerhaftes Abschalten der Werbebanner, die stets auf Sachen hinweisen wie diese, oder aktuell den Fotowettbewerb, die mich nicht interessieren und die wegen springenden Seiteninhalts den Lesefluß stören und seekrank machen.

Was ist das Problem?

Man will in WP etwas nachschlagen und wird mit eingeblendeten Hinweise auf Events davon abgehalten. Und das auf jedem Brower auf jeder Maschine einzeln. <facepalm />

Wen betrifft das Problem besonders?

Alle.

Lösungsvorschlag

Generelles und globales Opt-in.

Vorschlagende Person

AchimP (Diskussion) 18:48, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro AchimP (Einreichende Person)


(automatische) Silbentrennung für lange Wörter

Was ist das Problem?

Mitunter gibt es sehr lange Wörter in den Artikeln, besonders in der Mobilansicht und in Bildunterschriften laufen deshalb manche Wörter aus dem Seiten- /Bildbereich hinaus.

Übertriebenes Beispiel: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz
Wen betrifft das Problem besonders?

Mobilbenutzer und Leser nicht trivialer Artikel

Lösungsvorschlag

Aufbau eines Globalen Wörterbuchs nötig. (Oder Nutzung von https://de.wiktionary.org) Dadurch in der "gerenderten" Textvariante alle möglichen Trennungen der Wörter mit Weichen Trennzeichen versehen.

Anmerkungen

Man kennt dies beispielsweise aus LaTeX.

Vorschlagende Person

ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 20:56, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Flor!an (Einreichende Person)


Bessere Darstellung von Einrückungen in der mobilen Wikipedia

Was ist das Problem?

Bei Diskussionen mit vielen Einrückungen (mit ‚:‘) wird der Text oft auf viele Zeilen aufgeteilt, sodass manchmal pro Zeile nur noch ein Buchstabe steht, was sowohl dazu führt, dass der Lesefluss unterbrochen wird, als auch dazu, dass man ewig scrollen muss.

Wen betrifft das Problem besonders?

Alle Benutzer der mobilen Wikipedia

Lösungsvorschlag

Eine (auch nicht ganz optimale) Möglichkeit wäre, nach zum Beispiel drei Einrückungen eine Linie von rechts nach Links zu ziehen die rechts einen Strich nach oben hat und links einen nach unten, als Verbildlichung des nach links Ziehen des Textes. Dies ist für den Lesefluss gut, nicht unbedingt aber für die Übersichtlichkeit. Man könnte auch die Tiefe der einzelnen Einrückungen vergeringern, sodass eine Einrückung zB nicht mehr 1em, sondern nur noch 0.2em tief ist, wodurch das Problem entschärft, jedoch wahrscheinlich nicht komplett gelöst wird.

Vorschlagende Person

KPFC💬 21:16, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro KPFC (Einreichende Person)


Was ist das Problem?
Wen betrifft das Problem besonders?

Mathematische und naturwissenschaftliche Artikel

Anmerkungen

Seit der letzten Umfrage hat sich zwar schon einiges verbessert, aber dies soll als Motivation dienen, weiterzumachen. Die Darstellung ist abhängig von Browser, Betriebssystem, Schriftarten, Bildschirmauflösung... daher kann ich nur beispielhaft ein paar Dinge nennen, die mutmaßlich auch andere betreffen:

  • Die sollten möglichst so aussehen wie die Buchstaben ohne math, erscheinen aber fett obwohl sie nicht sind. (Betrifft SVG?)
  • Die Baseline und Schriftgröße der sollte passen und sich z.B. für Bildunterschriften der Schriftgröße anpassen . (Betrifft PNG?)
  • Etwas wie ein Pfeil bei einem Vektor sollte (mit \textstyle) keinen zusätzlichen Zeilenabstand erfordern. (Betrifft SVG und PNG?)
  • Zeichen wie ü in oder (Ångström) sollten etwa so aussehen wie für alle oder Å bzw. workaround oder . (Betrifft SVG?)
  • Natürlich müssen Größen und Abstände von Symbolen auch innerhalb von Formeln richtig sein. (Betrifft native MathML mit Firefox-Plugin?)

Nicht alle rendering-Methoden müssen gefixt werden. Eine Methode, die für fast alle Leser funktioniert ist ausreichend. Für mich hat damals MathJax (phab:T99369) recht gut funktioniert.

Vorschlagende Person

Debenben (Diskussion) 23:37, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Debenben (Einreichende Person)


"Seitengröße in Bytes" der Versionen und ihre Veränderung besser vermitteln

  1. In "Versionsgeschichte": Den Erläuterungstext instruktiver gestalten
  2. In "Gewählte Versionen vergleichen": Den Änderungswert auch zur Detailanzeige eines Versionsunterschieds darstellen
  3. Im "Artikel": Am Kopf der Seite die Seitengröße anzeigen
Was ist das Problem?

1. Der Beispielstext zur Erläuterung lautet aktuell:

(123 Bytes) = Größe der Version; (+543)/(-792) =‎ Änderung der Seitengröße in Bytes gegenüber der vorherigen Version

Die Zahl 123 ist dem Betrag nach viel kleiner als (+)543 und (-)792. Das ist nicht plausibel.

Mein Vorschlag daher:

(123 Bytes) = Größe der Version; (+/-45) =‎ Änderung der Seitengröße in Bytes gegenüber der vorherigen Version

... ist kürzer und macht Sinn, denn Veränderungen sind in der Regel kleiner als der aktuelle Größenstand des Artikels ... niedrige Zahlen lassen das Beispiel etwas schneller lesen, wenn auch 1.234 oder 12.345 plausibler für die Artikelgröße wären

2. In der Liste der Versionen ist die "Spalte Änderung der Seitengröße" die kürzeste Information über den Charakter eines Veränderungsschritts durch Redigieren.

Die – ich nenne sie – Größenänderungszahl ist mit dem Vorzeichen und der Größe ihres Zahlenwerts ein guter Anhaltspunkt für den Charakter der Änderung von Version zu Folgeversion.

Ein- bis zweistellige Werte weisen meist auf nur kleine Korrekturen hin. Drei- bis vierstellige (positive) gehören meist zu entsprechend großen Beiträgen, größere negative Werte zu kürzenden Löschungen. Genaue Reverts weisen den ins Negative gekehrten Wert der Vor-Veränderung auf.

Lässt man sich per Gewählte Versionen vergleichen die Änderungen Spalte gegenüber Spalte im Detail anzeigen, verschwindet diese Größenänderungszahl.

Dabei habe ich mir gerade diese kurze Zahlen besser eingeprägt als die ja immer 12-stelligen Datumangaben (hh:mm, dd.monat.jjjj) der Versionen.

Gut wäre also im Kopf der Anzeige Gewählte Versionen vergleichen die Größenänderungszahl (als Bilanz zwischen den zwei verglichenen Versionen, im Kopf der rechten Spalte) anzuzeigen.

Damit lässt auch die Größenänderungszahl zwischen zwei beliebig ausgewählten Versionen bilanzieren.

Beim Durchblättern von unmittelbar aufeinander abfolgenden Versionen erscheinen gut wiedererkennbar die Größenänderungszahlen der Versionsliste.

Zweckmässig ist wohl auch das Anzeigen der Seitengröße (in Byte) im Kopf der zwei Versionen in der Vergleichsansicht.

3. Artikelansicht

Die Seitengröße in kleiner Schriftgröße, eventuell auch das Datum der Version der Version anzeigen.

Im Sinn von "abgerufene Version" für Leser der Wikipedia, die eine Seite ausdrucken.

Wen betrifft das Problem besonders?

Wer sich in die Versionsgeschichte vertieft

Lösungsvorschlag

siehe oben

Anmerkungen

Vorschlagende Person

Helium4 (Diskussion) 06:16, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Helium4 (Einreichende Person)


Einbindung der Beacon-Datei in Personenartikeln

Ich wünsche mir eine prominentere Präsentation der Beacon-Datei in biografischen Artikeln.

Was ist das Problem?

Für die biografische Artikel wird die sogenannte GND eingepflegt (sofern vorhanden), die von der Deutschen Nationalbibliothek vergeben wird. Zweck ist eine eindeutige Identifizierung von Personen über alle beteiligten Projekte, die über das Beacon-Projekt koordiniert wird. Leider wird nicht angemeldeten Nutzern die Verlinkung zu den beteiligten Projekten gar nicht angezeigt und angemeldete Nutzer sehen die Verlinkung ganz unten (über den Kategorien bzw. den Personendaten) und wird damit unterrepräsentiert für den Informationsgehalt, den die Beacon-Datei leisten könnte.

Wen betrifft das Problem besonders?
  • Unangemeldete Nutzer
Lösungsvorschlag

Schön wäre ein ausklappbares Menü ganz oben im Artikel, das sämtliche Verlinkungen der beteiligten Projekte anzeigt, so dass der Umweg über den AKS-Link wegfällt. Der AKS-Link ist jener, der zu einer Übersicht führt, der sämtliche Projekte auflistet, die die GND nutzen und für die eine Beacon-Datei zur Verfügung gestellt wird. Zum Beispiel für Johann Sebastian Bach. Manche Websiten binden die Übersicht direkt ein (z.B. die Sächsische Biografie: Albrecht der Beherzte)

AKS-Link
Vorschlagende Person

Das Robert .... gibs mir! 10:47, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Das Robert (Einreichende Person)


Was ist das Problem?
Beispiel Hochformat
Beispiel Querformat

bei regulärer Nutzung der Hilfe:Galerie sprich z. B.:

<gallery>
Bild1
Bild2
Bild3
</gallery>

werden in der Mobilversion riesige Abstände (Margins) um die einzelnen Bilder angezeigt, die Bilder hingegen sehr klein.

Wen betrifft das Problem besonders?

Mobil Nutzer

Lösungsvorschlag

Margins (vor allem oben und unten) deutlich verkleinern und Bilder größere Anzeigen (auf den Vorschauen erkennt man ja nicht mal was drauf ist). Ggf. je nach Auflösung zwei nebeneinander anzeigen.

Vorschlagende Person

ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 09:49, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Flor!an (Einreichende Person)
  2. Pro Rewo (Diskussion) 11:08, 19. Jun. 2017 (CEST)[Beantworten]


Maschinengesteuertes vorlesen von Wikipedia-Artikeln unter Berücksichtigung der Vorlage Lang

Was ist das Problem?

Ältere Menschen haben oft Probleme mit dem Lesen längerer Texte am Bildschirme, erblindete und sehbehinderte Menschen sind davon grundsätzlich betroffen. Ich kenne derzeit keine Softwarelösung, die Wikipedia-Artikel mit unterschiedlichen Sprachattributen lesen kann.

Wen betrifft das Problem besonders?

Erblindete und sehbehinderte Menschen sowie ältere Menschen

Lösungsvorschlag

Der Sreenreader muss zuerst die Basis-Sprache erkennen und dann Anhand der unterschiedlichen Kürzel in den verwendeten Vorlagen Lang die entsprechenden Sprachmodule laden und dann anschließend beim Lesen des Textes in Abhängigkeit des Sprachkürzels in der Vorlage Lang auf die verschiedenen Sprachmodule zugreifen und sprachbezogen vorlesen.

Vorschlagende Person

Ulanwp (Diskussion) 23:33, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Ulanwp (Einreichende Person)


SVG-Dateien sollten direkt in Artikel und andere Seiten eingebunden werden anstatt Pixelgrafiken einzubinden.

Was ist das Problem?

Derzeit kann man zwar SVG-Dateien hochladen, diese werden allerdings nicht in den Artikeln angezeigt, sondern stattdessen in PNG-Dateien konvertierte Version, obwohl inzwischen moderne Browser SVG darstellen können. Dieses Vorgehen ist gerade beim Zoomen von Nachteil, denn diese konvertierten Grafiken werden nicht detaillierter, lediglich unscharf. Um zur eigentlichen Vektorgrafik zu gelangen, muss man erst auf die Beschreibungsseite und dann auf die Datei. Das sind für jede Grafik, die man sich genauer ansehen will, zwei zusätzliche Klicks.

Wen betrifft das Problem besonders?

Alle Leser, insbesondere solche mit Touchscreens

Lösungsvorschlag

Über eine Benutzereinstellung und/oder eine Browserweiche soll entschieden werden, ob eine konvertierte PNG- oder die SVG-Version in die HTML-Seite eingebunden werden soll. Um bei mehrsprachigen Dateien die richtige Sprache auszuwählen und ggf. Skripte zu entfernen, muss für jede SVG-Datei eine entsprechende Version zum Einbinden erstellt werden, das sollte technisch kein Problem sein.

Vorschlagende Person

Morten Haan 🍱 Wikipedia ist für Leser daSkin-Entwurf 00:41, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Morten Haan (Einreichende Person)


Suche im Volltext bei Mobile Leser

Was ist das Problem?

Länge und Gliederung unserer Artikel sind nicht an kleine Bildschirme angepasst. Deshalb macht schon das Lesen Probleme. Die Anzeige der Kapitelüberschriften lässt oft nicht erkennen, ob und wenn ja in welchem Kapitel eine gesuchte Information enthalten ist.

Wen betrifft das Problem besonders?

Mobile Leser

Lösungsvorschlag

Volltextsuche im Artikel, auch in den eingeklappten Kapiteln

Anmerkungen

Suche im Text gibt es zumindest in der Android-App und der iOS-App, aber nicht in der nativen mobile-Web-Version.

Vorschlagende Person

h-stt !? 21:57, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro H-stt (Einreichende Person)


klassische Tabs als Menu im Mobile Skin

Was ist das Problem?

Zugriff auf Informationen außerhalb des reinen Artikeltexts in der Standardanzeige. Es fehlen einfache Menu-Zugriffe auf Diskussion und History und anderes. Leser, die die Möglichkeiten des Desktop-Skins kennen, vermissen den Zugriff auf viele Inhalte im nativen mobile Skin (in den Apps gibt es manches, aber im mobile Browser eben nicht). Diskseite und Versionsgeschichte sind nicht oder nur umständlich zugänglich.

Wen betrifft das Problem besonders?

Power-Leser auf mobilen Geräten.

Lösungsvorschlag

Änderung der Menu-Struktur im mobile Skin. "Start, Zufall und In der Nähe" sing ganz sicher nicht die wichtigsten Optionen, die man in der Menustruktur suchen würde. Auch das "Beobchatungslisten"-Sternchen ist völlig sinnlos bei nicht angemeldeten Benutzern. Da muss die Disk rein und die History sollte auch nach oben ins Menu.

Vorschlagende Person

h-stt !? 21:58, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro H-stt (Einreichende Person)


Autorenbestimmung eines Artikel (→ WikiHistory)

Was ist das Problem?

Der erfahrende Wikipedianer möchte auf einen Blick erkennen, wer der Hauptautor eines Artikels ist. Damit man bei Problemen jemanden gezielt ansprechen kann.

Wen betrifft das Problem besonders?

Erfahrende Wikipedianer

Lösungsvorschlag

Das Tool Benutzer:APPER/WikiHistory überarbeiten und als allgemeine Funktionalität in die Wikimedia-Software integrieren. Leider ist das Tool seit einem Jahr nicht mehr funktionsfähig. Es geht um die grobe Einschätzung, wer die Handvoll Hauptautoren an diesem Artikel sind. Eine Byte-genaue Auswertung kann nicht (auf den einfachen Weg) erreicht werden und will es gar nicht.

Vorschlagende Person

Atamari (Diskussion) 02:02, 5. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Atamari (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:17, 19. Jun. 2017 (CEST)[Beantworten]


WP-App: Suche in eingeklappten Tabellen

Was ist das Problem?

In der Wikipedia-App sind Tabellen immer eingeklappt. Wenn man die App-eigene Suche nutzt, werden Einträge in den eingeklappten Tabellen nicht gefunden. Erst wenn die Tabelle ausgeklappt ist, werde Tabelleneinträge gefunden

Wen betrifft das Problem besonders?

Nutzer der WP-App, die in Artikel suchen

Lösungsvorschlag

Die Suche auf den Inhalt der Tabellen erweitern.

Vorschlagende Person

Z thomas Thomas 08:14, 6. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)


WP:App: Bei Anker-Nutzung im Artikel bleiben.

Was ist das Problem?

Wenn man in der WP:App auf einen Anker zum Beispiel bei Buchstaben-Navis klickt, wird nicht zum Anker gesprungen, sondern es öffnet sich das Vorschaufenster für den selben Artikel.

Wen betrifft das Problem besonders?

Nutzer der WP-App

Lösungsvorschlag

Beim Anklicken eines Annkers soll innerhalb des Artikels gesprungen werden.

Vorschlagende Person

Z thomas Thomas 08:16, 6. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)


Handhabbarkeit von Spezial:Linkliste verbessern (kleine Statistik)

Was ist das Problem?

Die Spezialseite Spezial:Linkliste listet alle internen Links auf eine bestimmte Seite auf. Dort fehlen wichtige Infos, z.B. eine Zahlenausgabe wie "107 Verlinkungen im Artikelnamensraum". Diese Infos sind vor allem wichtig, wenn das Ergebnis über mehrere Seiten geht.

Beispiel von Sitacuisses: „Bahnhof“ – Links auf diese Seite. Man wird hier als Benutzer völlig im Unklaren darüber gelassen, wie viele Ergebnisseiten und wie viele Tausend Treffer es gibt und wie lange es folglich dauert, diese zu überprüfen, etwa im Umfeld einer Verschiebung. Die Sortierung ist nicht nachvollziehbar und man sieht keine Möglichkeit, über mehrere Ergebnisseiten hinwegzublättern.

Wen betrifft das Problem besonders?
Lösungsvorschlag
  • Beim Benutzen der Funktion Spezial:Linkliste (Beispiel: [2]) könnte am Anfang eine kleine Statistik über Anzahl der Seiten eingeblendet werden. Am Besten aufgeschlüsselt nach Namensrasum.
  • Sinnvoll wäre es auch, die Linkliste nach eigenen Kriterien sortieren zu können, insbesondere nach Alphabet. -- Sitacuisses
  • Neben der Angabe der Trefferzahl wäre bei längeren Trefferlisten dann auch eine Direktnavigation zu bestimmten Seiten der Liste wünschenswert. -- Sitacuisses
    Anmerkungen

Bei Wikidata gibt es ein Helferlein ("Links count: Counts total number of pages linked to a specific page on Special:WhatLinksHere (and transclusion, for templates)"). Ist es aktiviert, erhält man über den Link "count" dann beispielsweise als Ergebnis: "(transclusions: 1, links: 437)". So etwa habe ich mir das vorgestellt.

Vorschlagende Person

Atamari (Diskussion) 12:38, 6. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Atamari (Einreichende Person)


Differenzierte Darstellung von Name und Qualifikator bei Klammerlemmata

Was ist das Problem?

Bei mehrdeutigen Lemmabegriffen wird in Wikipedia ein Klammerzusatz als Qualifikator verwendet. Es gibt jedoch auch Fälle, in denen bereits zum eigentlichen Namen ein solcher Klammerzusatz gehört. Als Beispiele seien Begriffsklärungsseiten wie Feldberg genannt. Da stehen mehr als zehn Artikel der Form „Feldberg (Klammerzusatz)“ in der Liste. Dabei fällt nicht auf, dass Feldberg (Schwarzwald) ein offizieller Gemeindename ist. Ebenso in Halle: Halle (Saale) und Halle (Westf.) sind offizielle Namen, stehen jedoch ohne Unterscheidung zwischen identisch aufgebauten Bezeichnungen wie Halle (Belgien), deren Klammerzusatz nur eine interne Bedeutung hat.

Es besteht einerseits die Gefahr, dass bloß interne Klammerzusätze für offiziell gehalten werden, andererseits werden offizielle Namen nicht als solche erkannt. Indem wir es unnötig schwierig machen den eigentlichen Namen zu erkennen, tragen wir ungewollt zur Verbreitung falscher Varianten bei. Mit der über die Jahre enorm gewachsenen Bedeutung der Wikipedia hat dieses kleine Problem an Brisanz zugenommen.

Wen betrifft das Problem besonders?

Alle Leser, insbesondere diejenigen, die nicht über unseren internen Umgang mit Homonymen Bescheid wissen. Es sind alle Klammerlemmata betroffen, die theoretisch einen Klammerzusatz bereits als Namensbestandteil haben könnten, etwa auch Werktitel.

Lösungsvorschlag

Eine differenzierte Darstellung von Name und Qualifikator. Sowohl in der Hauptüberschrift der Artikel als auch auf Begriffsklärungsseiten und in automatisch erzeugten Seiten wie Suchergebnissen, Kategorie- und Linklisten sollten eigentliche Namensbestandteile und interne Qualifikatoren auf Anhieb unterscheidbar sein. Dies könnte durch einen leicht unterschiedlichen Schriftstil geschehen. Beispiel dafür gibt es viele. So sieht unser undifferenziertes Ca$h (2010) in der IMDb so aus; beachte den Haupttitel. In den Auflistungen der Begriffsklärungen würden Zusätze automatisch durch den Schriftstil gekennzeichnet, ohne dass der Benutzer mit CSS hantieren muss. Das folgende Beispiel soll daher nur ein mögliches Aussehen vorführen, nicht jedoch den genauen Quelltext. Der sollte bereits bei unmaskierter Schreibweise automatisch ein ähnliches Schriftbild erzeugen:

Voraussetzung ist, dass die technische Möglichkeit geschaffen wird, diese Differenzierung innerhalb des Lemmas einzugeben und fest mit dem Lemma zu verbinden. Vom Arbeitsaufwand für die Benutzer her gesehen könnte es sinnvoll sein, die Differenzierung ab öffnender Klammer im Lemma als softwareseitige Default-Einstellung (auch bei Rotlinks) einzuführen und nur bei den wenigen Ausnahmen, wo die Klammer Namensbestandteil ist, einen Marker zu setzen, der die Differenzierung verhindert.

Vorschlagende Person

Sitacuisses (Diskussion) 05:21, 8. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Sitacuisses (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST)[Beantworten]


Sortierschlüssel auch für Spezialseiten

Was ist das Problem?

Mit {{DEFAULTSORT}} kann man eine Standardsortierung für eine Seite angeben, jedoch funktioniert das nur bei Kategorien und nicht bei alphabetisch sortierten Spezialseiten.

Wen betrifft das Problem besonders?

Benutzer bestimmter Spezialseiten

Lösungsvorschlag

Der Sortierschlüssel soll auch für entsprechende Spezialseiten angewendet werden.

Anmerkungen

Vorschlagende Person

Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 17:27, 8. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Morten Haan (Einreichende Person)


Nachtmodus

Was ist das Problem?

Die mobile App bietet bereits einen sehr gut funktionierenden Nachtmodus, dieser könnte doch auch in die Desktop Version übernommen werden. Der weiße Hintergrund ist gerade in der Nacht sehr ermüdend. Bei Desktop PCs kann die Bildschirmhelligkeit oft nicht variiert werden, hier ist es besonders störend.

Wen betrifft das Problem besonders?

Nachtaktive und Vielleser.

Lösungsvorschlag

Den Nachtmodus der mobilen App übernehmen. Dieser könnte sich auch abhängig von der Uhrzeit automatisch selbst aktivieren.

Vorschlagende Person

Chrfwow (Diskussion) 18:27, 2. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Chrfwow (Einreichende Person)


Was ist das Problem?

Wenn sich neben Bildern, die am linken Seitenrand angeordnet sind, rechts entweder eine Liste (Zeilenanfang: *), eine nummerierte Aufzählung (Zeilenanfang: #) oder die Zählung der Einzelnachweise steht, „kleben“ diese direkt am Rahmen des Bildes, der übliche Weißraum fehlt. Beispiel:

Beliebiges Bild
Fließtext

Üblicher Fließtext


Listen
  1. testtext
  2. testtext
  3. testtext
  4. testtext


Einzelnachweise
  1. Ref 1
  2. Ref 2
  3. Ref 3
  4. Ref 4


Die Aufzählungszeichen/-nummern sind gegenüber den Überschriften und dem normalen Fließtext nach links verschoben.

Wen betrifft das Problem besonders?

Alle Leser (es sei denn, dieser Effekt wäre auf spezielle Browser/Skins beschränkt. Bei der Kombination Firefox/Monobook tritt er auf)

Lösungsvorschlag

Gibt bestimmt einen Phab-Task dazu, keine Ahnung, wie ich den finden kann

Vorschlagende Person

Mabschaaf 21:48, 9. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Mabschaaf (Einreichende Person)


Artikel-Lesbarkeit: Zeilenlänge begrenzen

Was ist das Problem?

Da es in der Wikipedia keine Begrenzung der Spaltenbreite gibt, kommt es bei der Darstellung auf großen Monitoren zu sehr langen Zeilen von 200 und mehr Zeichen pro Zeile.

Es gehört zum typographischen Grunderkenntnissen, dass sowohl zu kurze als auch zu lange Zeilen das Lesen von Mengentexte in erheblichem Maße erschweren. Gerade bei viel zu langen Zeile hat man zunehmend Problem nach dem Zeilenende wieder den Anfang der nächsten Zeile zu finden, was insbesonder die Lesegeschwindigkeit deutlich reduziert.

Üblicherweise werden Zeilenlängen zwischen 50 und 75 Zeichen empfohlen. Diese Werte wurden in der Wikipedia nur auf den in der Entstehungszeit üblichen geringen Monitorauflösungen erreicht. Auf aktuellen Desktop- und Notebookmonitoren kommt es fast durchgänig zum beschrieben Problem.

Diese oft nur unterbewusst wahrgenommen Lesbarkeitsdefizite veringern die Attraktivität unserer Plattform und bringen mehr und mehr Leser dazu unsere Inhalte über andere Plattformen (wie die App, mobile Website oder Drittanbieterprogramme wie Wikiwand) zu nutzen, die einen deutlich schlechteren Zugang zum Editieren bieten. Wir verlieren dadurch also auch potentielle Editoren.

Wen betrifft das Problem besonders?
Lösungsvorschlag
  • Responsive Begrenzung der Spaltenbreite für den Fließtext der ANR-Artikel.
  • Responsive Begrenzung der Zeilenlänge der einzelnen Diskussionsabschnitte auf den Diskussionsseiten
    Vorschlagende Person

Martin K. (Diskussion) 15:52, 10. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)


Neuer Standardskin

Was ist das Problem?

Die Skins Vector (derzeitiger Standard) und Monobook (ehemaliger Standard) sind zwar zum Lesen und Bearbeiten geeignet, aber nicht gerade für mobiles Arbeiten. Der mobile Skin Minerva ist zwar zum Lesen geeignet, allerdings weniger zum Bearbeiten. Außerdem hat man die Koexistenz eine klassischen und eines mobiles Aussehens, was gerade für Benutzer störend sein kann, die die sowohl zu Hause als auch unterwegs in der Wikipedia lesen/arbeiten. Die linke Seitenleiste ist vor allem bei breiten Tabellen oder Panoramabildern störend, das derzeitige Inhaltsverzeichnis nimmt ggf. viel Platz ein und erzeugt teilweise viel ungenutzten weißen Raum. Außerdem ist der Fließtext immer einspaltig, was sich gerade bei breiten Fenstern negativ auf den Lesefluss auswirkt. Der mobile Skin ist leider nur eingeschränkt zum Arbeiten geeignet, bspw. fehlt die Funktionalität zum Sichten.

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Ich habe einen neuen Skin entworfen, der sowohl für Desktop als auch für mobile Geräte zum Lesen und Bearbeiten geeignet sein sollte: Skin-Entwurf (Diskussion | Englisch) Dieser Skin soll für alle Geräte und alle Nutzer zum Standard werden.

Anmerkungen
  • Vector und Monobook sowie natürlich die Druckansicht bleiben bestehen und sollen weiterhin gepflegt werden.
  • Mittels __ToC__ kann ein klassisches Inhaltsverzeichnis eingefügt werden.
  • Bei der Titelleiste hab ich mich von Wikivoyage auf Englisch inspirieren lassen: Beispiel
    Vorschlagende Person

Morten Haan 🎲 Wikipedia ist für Leser da 18:25, 10. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Morten Haan (Einreichende Person)


Autorenangaben unter den Artikeln

Was ist das Problem?
  • Vielen Leser der Wikipedia ist nicht bekannt/bewusst, dass die Artikel der Wikipedia von vielen Freiwilligen erstellt werden.
  • CC-BY-SA (die Lizenz der Wikipedia) verlangt ausdrücklich eine Autorenangabe. Dies wird in der Wikipedia zwar mittels der Versionsgeschichte und der Bilddetailseiten gewährleistet, die für die Leser aber weitgehend unsichtbar bleiben.
  • Bei der Nachnutzung von Wikipedia-Inhalten (Texten wie Bildern gleichermaßen) werden immer wieder die Autorenangaben vergessen, wo durch die Lizenz verlicht und einer Urheberrechtsverletzung entsteht. Auf Nachfrage heißt es dann oft, die Wikipedia mache es ja auch nicht. Es scheint also sinnvoll, dass die Wikipedia hier mit gutem Beispiel vorangeht.
Wen betrifft das Problem besonders?

Alle Autoren und alle Leser

Lösungsvorschlag

Unter jedem Artikel sollte (kleingedruckt) eine automatisch generierte Liste aller beteiligten Beitragenden (Autoren, Photographen, Kartographen, usw.) sowie die beteiligten Lizenzen angezeigt werden. So wird einerseits den Lesern bewusst gemacht, wie viele Menschen an dem Artikel mitarbeiten und andererseits könnte man den Artikel 1:1 lizenzsicher kopieren und nachnutzen.

Vorschlagende Person

Martin K. (Diskussion) 12:55, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST)[Beantworten]