Wikiup:Verbesserungsvorschläge/Archiv/2022/Januar

aus Wikipedia, der freien Enzyklopädie

Startschuss zur Umfrage Technische Wünsche 2022 – jetzt abstimmen

Datei:Teaser für Umfrage Technische Wünsche 2022.webm Es ist wieder soweit: Seit Montag kann wieder darüber abgestimmt werden, wo der Bedarf für technische Verbesserungen in den Wikis am größten ist. In der Umfrage Technische Wünsche stehen in diesem Jahr 16 Themenschwerpunkte zur Wahl, die anhand von Input aus den deutschsprachigen Wikis entstanden sind, unter anderen sind auch Ideen mit eingeflossen, die hier auf WP:Verbesserungsvorschläge und /Feature-Requests notiert wurden. Mit dem Gewinnerschwerpunkt wird sich das Team Technische Wünsche dann zwei Jahre lang – in engem Austausch mit den deutschsprachigen Communitys – beschäftigen und dort für verschiedene Verbesserungen sorgen.

Wir, das Projektteam Technische Wünsche haben in diesem Jahr zwei Dinge geändert, damit möglichst viele unterschiedliche Perspektiven in die Abstimmung einfließen können:

  1. Das überarbeitete Abstimmungsformular soll es noch einfacher machen, sich zu beteiligen. Wir hoffen, so auch jene zu erreichen, denen es bislang zu umständlich war.
  2. Damit man besser für Themen abstimmen kann, die einem persönlich tatsächlich am wichtigsten sind, und nicht nur für jene, von denen man sich die meisten Erfolgschancen erhofft, wurde die Abstimmungsmethode verändert: Jede/r kann bis zu fünf Favoriten angeben, sortiert nach Präferenz. Ausgewertet wird die Abstimmung dann nach dem Instant-Runoff-Verfahren. Mehr Informationen dazu finden sich auf der Umfrageseite.

Um mitzumachen, braucht man lediglich ein Benutzer*innenkonto, das mindestens seit dem 23.12.2021 existiert. Technische Fähigkeiten oder ein Mindestmaß an Erfahrung im Editieren sind ausdrücklich nicht nötig – die Verbesserungen sollen allen zugutekommen, und daher sollten auch alle abstimmen.

Die Umfrage läuft noch bis zum 6. Februar – bitte weitersagen und natürlich selber abstimmen! Wir freuen uns über Feedback auf der Diskussionsseite der Umfrage.

PS: Wer über Neuigkeiten aus den Technischen Wünschen auf der eigenen Diskussionsseite informiert werden möchte, kann hier den Newsletter abonnieren. -- --Johanna Strodt (WMDE) (Diskussion) 14:06, 26. Jan. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --ɱ 00:02, 8. Feb. 2022 (CET)

Schriftgröße, Links und Barrierefreiheit

Das Layout der Wikipedia ist leider nicht barrierefrei. Es wäre schön, wenn man zumindest optional auch ohne Anmeldung und benutzerdefiniertes CSS auf ein anderes Layout umstellen könnte, was diese Probleme behebt.

Schriftgröße

Das ist sogar in der Wikipedia selber schon thematisiert: https://de.wikipedia.org/wiki/Wikipedia:Technik/Baustellen/Schriftgr%C3%B6%C3%9Fe_100%25

Die Standardschrift ist kleiner als 100% und lediglich 14px groß, was etwa 87% entspricht. Im Bereich der Fußzeile sogar nur noch 12px.

Solche Schriftgrößen waren zu Zeiten von Windows 95 und frühen Apple Macs noch üblich, weil Windows selbst auch nur so kleine Schriften benutzt hat und Apple bei früheren Geräten Bildschirmdarstellungen auf 72 DPI ausgelegt hat. Als Bildschirme lediglich 512*384 (Apple Macintosh Classic), 640*480 (PC VGA) oder 800*600 Pixel hatten, mag das auch sinnvoll gewesen sein. Aber spätestens seit Full HD selbst bei Laptops der Normalzustand ist, sollte man Schriften für Fließtexte auf Websites nicht ohne Not kleiner als 100% machen und die wenigsten Websites tun das heutzutage noch. Eher werden Schriften sogar größer als 100% gesetzt, damit Texte besser lesbar sind.

Das Argument, dass man die Ansicht im Browser größer machen kann, ist wenig zielführend, da so auch Bilder vergrößert werden und nicht nur der Text. Auch steht diese Möglichkeit nicht immer zur Verfügung und die Einstellung gilt u.U. dann für alle Websites und nicht nur Wikipedia.

Darstellung von Links

In Artiken werden Links nicht unterstrichen, sondern nur farbig dargestellt. Blau oder lila statt schwarz erkennt man aber nicht sehr gut und für manche Menschen sind Unterstreichungen absolut essentiell. WCAG 2.0 fordert deshalb ebenfalls aus gutem Grund, Links nicht nur durch Farbe zu kennzeichnen.

Siehe dazu auch:

https://webaim.org/techniques/hypertext/link_text#appearance

https://at3centerblog.com/2019/07/24/link-accessibility-no-nos-that-may-surprise-you/

https://www.barrierefreies-webdesign.de/knowhow/links-unterstreichen/#:~:text=Die%20Unterstreichung%20von%20Links%20wird,nach%20einem%20Link%20im%20Flie%C3%9Ftext.

Das Argument, dass Texte mit unterstrichenen Links im Hinblick auf Design "hässlich" oder "unruhig" sind, ist nicht zielführend - es geht bei Texten nicht primär um "Schönheit", sondern Lesbarkeit und Zugänglichkeit. Man kann mit CSS die Unterstreichung auch so gestalten, dass sie als Rahmen unterhalb des Wortes erscheint und weniger störend wirkt.

Auch große Online-Publikationen setzen Links im Text unterstrichen, damit man sie auch erkennen kann - Beispiele:

https://www.heise.de/hintergrund/Verhaltensforschung-Kommt-ein-Goldfisch-die-Strasse-entlang-6320113.html

https://www.welt.de/kaufberatung/technik/article207969619/Nintendo-Switch-Lite-vs-Switch-Welches-Modell-und-Zubehoer-lohnt-sich.html

https://www.sueddeutsche.de/muenchen/muenchen-messerschmiede-dummer-schleiferei-traditionsgeschaeft-1.5496950

Zeilenlängen

Texte sind schwer lesbar, wenn die Zeilenlängen deutlich über 100-120 Zeichen pro Zeile sind. Deshalb verwenden Zeitungen auch Spaltensatz, um die Texte lesbar zu gestalten.

Texte sollen sich natürlich auch an die Fensterbreite anpassen, damit man Text z.B. auch auf mobilen Geräten noch gut lesen kann. Aber er sollte eine sinnvolle, maximale Breite haben, was man per CSS (max-width) leicht festlegen kann.

In der Wikipedia ist die Breite aber unbegrenzt, d.h. wenn man einen Browser auf voller Bildschirmgröße benutzt, sind die Texte viel zu breit. Sich ständig den Browser für die Wikipedia kleiner zu machen, damit man die Texte noch gut lesen kann, ist aber auch sehr umständlich. Die genannten Beispiele zur Link-Darstellung zeigen auch, wie man das besser lösen kann. Auch Software wie Confluence nutzt standardmäßig keine unbegrenzt breite Darstellung, sondern begrenzt den Inhalt auf etwa 44em Breite, wobei man auf Wunsch für Tabellen auch breiter darstellen lassen kann, wenn das nötig ist.

Siehe dazu auch:

https://webaim.org/techniques/textlayout/

https://barrierefreies.design/barrierefreiheit-interaktiv-testen/checkliste-fur-webseiten#:~:text=Die%20Zeilenl%C3%A4nge%20betr%C3%A4gt%20nicht%20mehr,so%20gro%C3%9F%20wie%20der%20Zeilenabstand.

--Silicon Gandalf (Diskussion) 22:17, 7. Jan. 2022 (CET)

Das sind durchaus brauchbare Verbesserungsvorschläge, ja! Was die Zeilenlänge angeht, wurde bereits Abhilfe geschaffen (wenn es auch viele Proteste dagegen gibt), der neue Vector-Skin hat das Feature. Diesen kannst du angemeldet schon in den Einstellungen aktivieren, ansonsten pro Seite durch den URL-Zusatz ?useskinversion=2. Bei bspw. der französischen WP ist er bereits Standard für alle. Änderungen von Linkgestaltung und Schriftgröße sind wohl eher nicht vorgesehen. Mit Browsererweiterungen ist es aber auch unangemeldet relativ unkompliziert, entsprechende CSS-Regeln für Wikipedia vorzugeben und das Erscheinungsbild anzupassen. Gruß—XanonymusX (Diskussion) 23:15, 12. Jan. 2022 (CET)

Sandbox link on German Wikipedia

Apologies for writing in English. I don't speak any German. Please feel free to translate my text.

I'm holding a global RFC regarding Sandbox link (example) at Meta: m:Requests for comment/Enable sandbox for all Wikipedias. I was told by User:Lucas Werkmeister that German Wikipedia as a large project does not have Sandbox link enabled.

  • Does German Wikipedia want the Sandbox link enabled?

If there is consensus for enabling that on German Wikipedia, I will do that as part of the global settings. But if German Wikipedia does not want that, I can simply omit the German Wikipedia from my proposal. No hard feelings at all :) I have personally not found Sandbox links harmful in any way, shape, or form. Thanks 4nn1l2 (Diskussion) 17:38, 12. Jan. 2022 (CET)

This was briefly discussed in 2018 already, when Benutzer:UweRohwedder suggested the addition of this link in Wikipedia:Fragen_zur_Wikipedia/Archiv/2018/Woche_50#User-Sandbox. His suggestion was met with... reluctance, to say the least. So I wouldn't introduce it without getting some kind of community consensus first. --Tkarcher (Diskussion) 00:36, 13. Jan. 2022 (CET)
There were just 1 user who was really against it, some more rather neutral. I remember the introduction of the visual editor, there was similar resistance, but today no one is crowing about it any more. I am still convinced that the sandbox is a good thing for newcomers, as was confirmed to me just the other day by a newcomer who knows it from enwiki and misses it here. Maybe we should set up a WP:Umfrage or WP:Meinungsbild on this? --Uwe Rohwedder (Diskussion) 10:28, 13. Jan. 2022 (CET)
@UweRohwedder: I don't know which forum is best to raise such issues, but maybe you could start a new poll about this. I believe raising the issue again after 3 or 4 years in completely reasonable. 4nn1l2 (Diskussion) 20:57, 13. Jan. 2022 (CET)

Beobachtungsliste: „Änderungen seit … anzeigen“ mit Mitteilungs-Refresh

Beim Updaten der Bearbeitungsliste mit der Funktion „Änderungen seit … anzeigen“ werden die Meldungs- und Mitteilungs-Icons nicht upgedatet – ob man eine Nachricht bekommen hat oder erwähnt wurde, erfährt man nur, wenn man die Beo insgesamt neu lädt oder eine andere WP-Seite öffnet oder neu lädt. Wäre es möglich, auch beim Aufrufen der Änderungen in der Beo die Icons zu refreshen? Oder gibt es dafür schon eine Option oder ein Helferlein?
Troubled @sset     09:59, 15. Jan. 2022 (CET)

Zu meinem richtigen Verständnis: Es ginge dir nicht um die beobachteten Seiten, sondern nur um rote und blaue und orange persönliche Nachrichten?
Das hätte aber nichts mit Beo zu tun; könnte man auf jeder Seite organisieren, aber vielleicht zur Vermeidung von Ressourcenvergeudung auf eine user defined Auswahl einschränken.
Technisch ist sowas lösbar, vielleicht hat in der enWP sowas bereits jemand programmiert.
Die Konzeption wäre:
  • Immer, wenn im Browser ein anderer Tab mit Wiki sichtbar wird (womöglich nicht von innerhalb der Wiki-Seite festzustellen, sondern nur über ein Add-On); oder
  • alle 1, 3, 5 Minuten auf bestimmten Seiten …
  • soll die API angefragt werden, ob es ungelesene Nachrichten gäbe, und falls ja zumindest etwas einblenden, etwa ein Info-PopUp drüberlegen.
  • Ob man es mit vernünftigem Aufwand hinbekommt, in den verschiedensten Skins und mobil im Original-Design die Dingse darzustellen, ist eine andere Sache, aber in dem Info-PopUp kann man eigene nachempfundene bunte Icon-Felder und Anzahlen darstellen und anklickbar machen.
  • Programmierer können für das aktuelle oder konfigurierbar andere Wikis den Benachrichtigungsstand abfragen wenn sie es können.
  • Problem: Es kommt halt alle paar Minuten zu Netzwerktraffic und Browser-Arbeit; muss man wollen.
VG --PerfektesChaos 11:02, 15. Jan. 2022 (CET)
„nur um rote und blaue und orange persönliche Nachrichten“ – genau. Mir würde das zumindest in einem ersten Schritt sogar auf der Beo genügen, wenn man die „Änderungen seit …“ aufruft.
Wenn man die ganze Beo-Seite refresht, werden – wie auf jeder Seite – auch die persönlichen Nachrichten refresht, aber die Information „seit …“ geht verloren. Könnte man nicht auch bei Aufruf von „Änderungen seit … anzeigen“ auch den Status der persönlichen Nachrichten abrufen und anzeigen?
Möglicherweise fehlt mir noch ein ausreichendes Verständnis, wie diese „Änderungen seit …-Funktion umgesetzt ist. Wird dabei im Hintergrund trotzdem die gesamte Seite neu geladen und lediglich im Browser dann nur die Darstellung upgedatet? Dann müsste auch der aktuelle Status der Nachrichten in der gelieferten Seite enthalten sein, und man müsste dann lediglich auch diese Information in der Darstellung refreshen, was „lokal“ gemacht werden könnte. Wenn allerdings nur die geänderten Seiten für die Liste geliefert werden, würde dies wohl eine Änderung auf dem Server erfordern, der dann zusätzlich auch den aktualisierten Status der Nachrichten mitliefern müsste … wie genau läuft das denn aktuell?
Grüße und danke, Troubled @sset     12:11, 15. Jan. 2022 (CET)
Also jetzt habe ich Schwierigkeiten, dir zu folgen, wann du auf genau welcher Seite mit welcher Option unterwegs bist.
Standard-Wiki-Software hat eine von dir angedeutete Funktion „Änderungen seit …“ irgendwie nicht.
Klingt nach einem Gadget; sowas in der Art kenne ich mindestens für „Letzte Änderungen“.
Es gibt verschiedene Werkzeuge, die das HTML-Dokument als solches konstant lassen, aber nur Inhaltsbereiche aktualisieren.
  • VisualEditor macht auch sowas: Wenn du in einem Absatz einige Wörter veränderst und „publizierst“, dann wird ein normaler Edit an den Server gefunkt, und in deinem HTML-Dokument wird der Absatz herausgeschnitten und vom VE durch den veränderten ersetzt.
  • So ähnlich machen das auch diverse Hilfsmittel; wenn du auf deinen Knopf drückst, werden per WP:JS/API die aktuellen Inhalte abgefragt und der momentane Seitenbereich durch die entsprechend formatierten aktuellen Informationen ersetzt. „LiveUpdate“ hieß das mal.
Wenn es da schon einen Button gibt, können Programmixe auf diesen Button den Start einer weiteren Funktion legen und deine Nachrichtenaktualisierungsabfrage starten.
Ich rate dazu, sich durch die Gadgets und Benutzerskripte der enWP zu wühlen, ob es da schon sowas gibt, an der technischen Dorfpumpe nachzufragen ob jemand was weiß, oder Bock hätte, sowas vielseitig konfigurierbar zu programmieren.
VG --PerfektesChaos 12:45, 15. Jan. 2022 (CET)

Nennung Filmbranche: Szenenbild, Kostümbild, Maskenbild

Gerne würde ich darüber sprechen, warum das Art Department (Szenenbild, Kostümbild, Maskenbild) nicht in audiovisuellen Werken auf Wikipedia genannt wird. Dieses Department ist nicht nur aus finanzieller Sicht (Budget), sondern auch im zeitlichen Rahmen und im Aufwand mit unter das größte Gewerk in der Film-, Fernseh- und Werbebranche. Szenenbild (engl. Production Design) ist ein in gleichem Masse bildgestalterisches Gewerk wie die Kamera-Arbeit. (nicht signierter Beitrag von 2A02:810D:8400:E54:B405:A6A:59F4:B076 (Diskussion) 20:18, 20. Jan. 2022 (CET))

Bitte suche mit deinem Anliegen WP:RFF auf und diskutiere dort weiter. VG --PerfektesChaos 20:46, 20. Jan. 2022 (CET)

Kein Vorschlag, sondern ein Lob

Danke für die Einführung der „Abonnieren“-Funktion! Endlich muss man seine Beobachtungsliste nicht mehr mit der Lupe durchsuchen, damit man nichts verpasst, sondern wird bei Änderungen bzw. neuen Antworten im entsprechenden Abschnitt direkt benachrichtigt. Ungemein praktisch und eine echte Zeitersparnis! Viele Grüße --Brettchenweber (Diskussion) 13:33, 22. Jan. 2022 (CET)

Anzeigen der Diskussionsseite in der mobilen Version

Wer die deutschsprachige Wikipedia unangemeldet und auf einem Mobilgerät anschaut (vermutlich die Mehrheit), sieht bei den Artikeln keinen Link zur Diskussionsseite. Wer editieren darf, braucht aber auch Zugang zu den Diskussionsseiten.

Mal ganz abgesehen davon, dass man damit manchmal auch die Zuverlässigkeit der Informationen im Artikel besser einschätzen kann oder gar überhaupt erst darauf stösst, dass hier normale Menschen editieren und zusammen etwas aufbauen.

Der Grund für diese Situation ist anscheinend, dass die Mobilversion das früher gar nicht konnte: phab:T54165. Inzwischen kann sie es aber und es braucht nur eine winzige Konfigurationsänderung pro Sprachversion. Die Schwedische Wikipedia hat es ab 2020 mal ausprobiert, und da es keine Probleme gab, hat die englischsprachige das Feature ab letztem November auch aktiviert. "Wir" brauchen das auch, finde ich. --2A02:AA10:5580:6500:2B:7863:D714:C14D 19:04, 24. Jan. 2022 (CET)

Dem kann ich mich nur anschließen. Der Umweg über "Desktop-Ansicht" bzw manuelles Ergänzen in der Adressleiste um die Diskussionsseit aufzurufen könnte gerne der Vergangenheit angehören. Gruß, -Ani--46.114.152.6 12:13, 11. Feb. 2022 (CET)
Da für derartige Konfigurationsänderungen immer ein gewisser Konsens nachgewiesen werden muss, sollte eine kleine Umfrage auf FZW der nächste Schritt sein. Gruß, -- hgzh 13:04, 11. Feb. 2022 (CET)
Wenn es nach mir ginge, würde sowieso die erweiterte mobile Ansicht zum Standard werden, aber das kann vermutlich nicht bloß lokal geregelt werden.—XanonymusX (Diskussion) 13:08, 11. Feb. 2022 (CET)
Für die Vollständigkeit: phab:T293946 ist ein Beispiel für die Konfigurationsänderung zur Aktivierung des Diskussionsseiten-Buttons, sollte relativ einfach umzusetzen sein, wenn hier ansatzweise ein Konsens vorhanden ist (ich denke, schon); phab:T290812 ist ein Beispiel für die Standard-Aktivierung der erweiterten mobilen Version (scheint noch nicht viele Fortschritte gemacht zu haben).–XanonymusX (Diskussion) 14:15, 11. Feb. 2022 (CET)
Hatte mich vertan, auch die enWP hat natürlich die „modernere“ Lösung mit den Tabs eingeführt, das geht also problemlos. Dann schlage ich das mal eben bei FzW vor! –XanonymusX (Diskussion) 19:17, 11. Feb. 2022 (CET)

Wie bereits richtig dargestellt: Als Grundlage für ein Begehren ist ein straw poll (Mini-MB) auf village pump (FZW) über eine Woche mit allgemeinverständlicher kurzer Beschreibung sowie präziser Spezifikation der begehrten Änderungen deutsch+englisch erforderlich. VG --PerfektesChaos 14:28, 11. Feb. 2022 (CET)

Weiter unter WP:Fragen zur Wikipedia #Diskussionsseitenlink für unangemeldete User (nicht signierter Beitrag von XanonymusX (Diskussion | Beiträge) 20:01, 11. Feb. 2022 (CET))
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Verbesserungsvorschläge/Archiv/2022/Januar&oldid=223089244“