Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2021

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2021#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests/Archiv/2021#Thema_1

Flood flag

Neulich sah ich, dass Benutzer:Cirdan die "Einladung zur Wikipedia-Geburtstagsfeier" an recht viele Benutzer verteilt hat. Bearbeitungen wie diese haben den Nachteil, dass sie die letzten Änderungen überfluten, sodass das überwachen anderer Artikel sehr schwierig wird. Daher würde ich vorschlagen, dass in der dewiki eine 'Flood Flag' eingeführt wird. Diese Benutzergruppe würde die bot Berechtigung enthalten, sodass die Bearbeitungen dann nicht mehr in den letzten Änderungen zu sehen sind. Eine solche Berechtigung wird (logischerweise) nur temporär vergeben und muss wieder entfernt werden, wenn die Person mit ihren Bearbeitungen durch ist. Für die Vergabe der Gruppe hätte ich folgende Vorschläge:

1. Bürokraten dürfen Benutzer zu dieser Gruppe hinzufügen und auch wieder entfernen.
2. Admins dürfen nur sich selbst zu dieser Gruppe hinzufügen und auch wieder entfernen.
3. Personen mit der 'Flood flag' dürfen diese wieder von ihrem eigenen Account entfernen, sodass sie dafür nicht einen Bürokraten kontaktieren müssen.

Grüße --ZabeMath (Diskussion) 18:46, 5. Mär. 2021 (CET)

Ich fände es sinnvoller, in solchen Fällen eine Massennachricht abzusetzen. Die wird dann von Benutzer:MediaWiki message delivery versandt, der bereits Botrechte hat. Über Spezial:Massennachrichten kann jeder Admin eine Massennachricht auf Wunsch/Antrag veranlassen. Da braucht es eigentlich keine eigene Gruppe. XenonX3 – (☎) 18:55, 5. Mär. 2021 (CET)

Ich sehe auch keinen Nutzen darin. Das mit den Massennachrichten funktioniert doch ganz gut (auch wenn man vielleicht immer mal wieder daran erinnern sollte, dass es diese gibt). --Reinhard Kraasch (Diskussion) 01:08, 6. Mär. 2021 (CET)

Ich finde die Idee nicht schlecht (auch wenn in diesen zusammenhang Massennachricht besser ist). Flood kann auch bei Adminaktionen verwendet werden, wie Massenlöschungen oder ähnliches. Da wäre es gut wenn die letzten Änderungen nicht geflutet werden würden.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 16:24, 7. Mär. 2021 (CET)

Der völlig identische Effekt wäre zu erzielen, indem in einem solchen Fall Bürokraten ein Bot-Flag setzen würden.

Admins können ganz grundsätzlich niemand zu einer solch wirkmächtigen Gruppe hinzufügen oder entfernen; auf eine solche Änderung wird sich das globale Software- und Sicherheitsmanagement niemals einlassen.

Damit sind die Punkte 2 und 3 hinfällig.

Unter dem Radar der Beo hindurchfliegen zu dürfen bedarf global immer einer Bestätigung durch Bürokraten; weil genau deswegen gibt es diese. Admins dürfen weder sich selbst noch sonstwem eine Berechtigung für Beo-freie Aktionen erteilen.

Das war jetzt eine einmalige Aktion eines Benutzers, der manuell etwas gemacht hatte, wofür wir mit den Massennachrichten bereits eine hinreichende Funktion haben.

Nun haben ein paar Dutzend Power-User jeder eine Handvoll Bearbeitungen auf Benutzerdiskussionen anderer Benutzer gesehen, die sie zufällig auf der Beo haben. Und welcher Schaden ist jetzt entstanden?

Für eine solche Veränderung wäre ohnehin ein 2/3-MB zur Definition einer derartigen Gruppe und die Erstellung von Richtlinien erforderlich, in denen geregelt werden müsste, wer unter welchen Bedingungen sowas für wie lange erhalten solle.

Diese einmalige Aktion mit einem riesig-verzwickten Programmier- und Verwaltungsaufwand zu begleiten, und in die möglichst einfache und übersichtliche Sicherheitsarchitektur lauter komplizierte Ausnahmeregeln einzubasteln, die am Ende niemand mehr überblickt, wird sicher das globale Entwicklungsmanagement nicht dazu bringen, dafür man months für einen Entwicklungsprozess zu bewilligen und im Gegenzug andere Softwareprojekte aufzuschieben und zurückzustellen, zumal man dort auch sehr gut weiß, dass genau dafür die Massennachricht eingerichtet wurde.

Und unbeobachtete Massenlöschungen gehen nun gleich gar nicht, das dürfen noch nicht einmal Bots.

VG --PerfektesChaos 22:23, 7. Mär. 2021 (CET)

@PerfektesChaos: In Wikidata und Metawiki und ein paar anderen Projekten gibt es die Gruppe so wie Vorgeschlagen und hier es funktioniert Problemlos. Zitat:"unbeobachtete Massenlöschungen" Auch Bots verursachen Logbucheinträge. Die Fluten nur nicht die "Letzten Änderungen". Die Rechtevergabe ist auch in den "Letzten Änderungen" sichtbar. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 11:10, 8. Mär. 2021 (CET)

Dort können sich Admins dieses Recht übrigens selbst geben, siehe m:Meta:Flood flag/de, d:Wikidata:Flooders/de. --Ameisenigel (Diskussion) ^LI 18:27, 8. Mär. 2021 (CET)

• Das sind technisch ganz normale Bot-Accounts.
• Der einzige Unterschied ist, dass hier die Mitglieder der Gruppe das Recht haben, sich selbst aus der Gruppe zu entfernen.
  • Das ist uralt-bekannt und kein Problem.
  • Die obige Beschreibung und der Vorschlag hier unterstellte etwas völlig anderes. Hier las es sich so, als ob nur Mitglieder einer bestimmten Gruppe solche Rechte erhalten sollen.
  • Dazu schrieb ich oben als erster Satz: „Der völlig identische Effekt wäre zu erzielen, indem in einem solchen Fall Bürokraten ein Bot-Flag setzen würden.“
  • Und nichts anderes ist das hier.
• Der Vorschlag läuft jedoch darauf hinaus, dass ausnahmslos alle Admins Bot-Rechte erhalten sollen.
• Die Gruppe heißt etwa auf Wikidata „Pseudobots“.
• Der einzige Unterschied zu einem normalen Bot ist, dass die Mitglieder dieser Gruppe sich das Recht selbst entziehen können.
  • Ansonsten ist Wikidata so konfiguriert, dass ausnahmslos alle Benutzer mit Admin-Rechten sich jederzeit selbst auch Bot-Rechte wieder erteilen dürfen.
  • Das wird die hiesige Community schlicht nicht mitmachen.
  • Die in Punkt 2 oben vorgetragene Darstellung suggerierte, dass nur die Mitglieder einer solchen Gruppe solche Rechte hätten. Tatsächlich ist aber gemeint: Ausnahmslos alle Admins zuzüglich weitere Benutzer einmalig.

Diese Seite hier ist für Veränderungen der globalen Software vorgesehen.

• Eine solche Veränderung, die an die Entwickler weitergeleitet werden solle, wird gar nicht vorgeschlagen.
• Der Vorschlag, allen Admins Bot-Rechte zu geben, kann gern in einem MB vorgetragen werden. Hier falsch.

VG --PerfektesChaos 20:53, 8. Mär. 2021 (CET)

Folgendes möchte ich noch einmal erklären:

1. Es war nicht Ziel des Vorschlags, dass alle Admins Bot-Rechte erhalten. Ich habe das eher so wie WikiBayer gesehen, dass so eine Berechtigung eine nützliche Ergänzung (insbesonders als Admin) sein kann, auch wenn das von mir genannte "Beispiel" unpassend ist.
2. Ich persönlich gehe davon aus, dass Admins verantwortungsvoll mit der Möglichkeit umgehen, sich eine solche Berechtigung zu geben. Wenn ich bei einer Person nicht glauben, dass sie mit solchen Berechtigungen verantwortungsbewusst umgehen könnte, wähle ich sie nicht zum Admin.
3. Ich habe den Vorschlag auf dieser Seite erstellt, da für das Einführen einer solchen Gruppe eine Änderung in der InitialiseSettings.php notwendig wäre. Auch wenn das nicht wirklich eine Software-Änderung ist, dachte ich trotzdem, da hierfür ein Phabricator Task notwendig wäre, das hier der angebrachteste Platz ist, um einen solchen Vorschlag zu machen.

Ich schließe das hier aber mal, da es scheinbar kein bzw. nur ein sehr kleines Interesse für den Vorschlag gibt. Grüße --ZabeMath (Diskussion) 17:06, 10. Mär. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --ZabeMath (Diskussion) 17:06, 10. Mär. 2021 (CET)

Einstellung für die Wunsch-Beobachtungszeit

Es wäre schön, wenn man in den Einstellungen auch wählen könnte, wie lange man einen Artikel auf der Beobachtungsliste haben möchte. --FF-11 (Diskussion | Bewertung | Beiträge) • Mitglied der Jungwikipedianer 16:21, 12. Feb. 2021 (CET)

Ja, finde ich auch: Phabricator – Bug/Feature: 265716

Die personellen Ressourcen für diese Entwicklung sind jedoch aufgebraucht; du wirst dich längere Zeit gedulden müssen, bis das jemand umsetzen kann.

VG --PerfektesChaos 16:59, 12. Feb. 2021 (CET)

Das irritiert mich jetzt. Wenn ich eine Seite auf meine Beobachtungliste nehmen möchte, werde ich gefragt, ob Dauerhaft, eine Woche, einen Monat, 3 Monate oder 6 Monate. --Diwas (Diskussion) 02:08, 13. Feb. 2021 (CET)

Ja, aber ich möchte, dass man nicht mehr dieses Menü aufzurufen braucht. In den Einstellungen gibt es eine Option, die jeden bearbeiteten Artikel automatisch dauerhaft auf die Beobachtungsliste setzt. Dadurch kann die Beobachtunsliste mit der Zeit unübersichtlich werden. Daher sollte man einstellen können, dass Seiten automatisch nur für eine Woche beobachtet werden, um einen guten Kompromiss zwischen Übersichtlichkeit und Informiertheit zu haben. --FF-11 (Diskussion | Bewertung | Beiträge) • Mitglied der Jungwikipedianer 08:32, 13. Feb. 2021 (CET)

Ach stimmt ja, du hattes geschrieben: „in den Einstellungen“. --Diwas (Diskussion) 12:34, 13. Feb. 2021 (CET)

Ich fände so eine Möglichkeit auch sehr wünschenswert. --Bernd Bergmann (Diskussion) 16:09, 13. Feb. 2021 (CET)

Nur Diskussionsseite auf die Beobachtungsliste setzen / Nur einzelne Abschnitte beobachten

Ich wünsche mir als Feature für die Beobachtungsliste, dass der Artikel und die Diskussionsseite separat behandelt werden. Noch besser wäre ein Feature, um nur einen einzelnen Abschnitt zu beobachten. Meist interessieren mich ja nur Änderungen zu meinem erstellten Abschnitt... --Liberealist Disputatio 09:44, 7. Jan. 2021 (CET)

 Pro Habe mich als Neuling bereits gefragt wie man das hinbekommt aber das scheint (weil dieser Feature-Request gestellt wurde) bisher noch garnicht möglich zu sein.?. Insbesondere das "nur Abschnitt beobachten" finde ich Sinnvoll. Vielleicht gibt es jedoch von Erfahrenen Nutzern einen Workaround?--Legi (Diskussion) 09:39, 14. Jan. 2021 (CET)

@ nur Abschnitt beobachten

• Das ist technisch nicht möglich, weil Abschnitte auch ihren Namen ändern können und weil eine Veränderung der gesamten Seite die Beobachtungsaktion ist.
• Ob und welche einzelnen Abschnitte an einer Veränderung beteiligt waren wird die MediaWiki-Software ganz sicher nicht auswerten, und auch nicht über welche Abschnittsüberschriften welche Benutzer gern informiert werden möchten.
• Hinzu kommt, dass sich Abschnittsüberschriften und Abschnittsgliederungen auf vielerlei Weise ändern können und dann diese Aktion sofort ins Leere laufen würde.
• Es mag ja gern irgendwer ein gesondertes Werkzeug programmieren, das sowas auswertet und verfolgt, aber offizielles Angebot wird das mit größter Sicherheit nie werden.

@ Nur Diskussionsseite oder nur Vorderseite beobachten

• Das ist grundsätzlich nicht erwünscht und widerspricht einer millionenfach angewendeten Grundkonzeption tief im Innersten der Software.
• Wenn sich jemand für die Diskussionsseite interessiert, dann ist in der extrem überwiegenden Zahl der Fälle auch die betreffende Seite selbst relevant. Umgekehrt genauso: Wer sich für eine Vorderseite interessiert, sollte grundsätzlich auch verfolgen, was auf der zugehörigen Diskussionsseite erörtert wird.
• Die MediaWiki-Software wird das mit ziemlicher Sicherheit nicht getrennt konfigurieren lassen.
• Du könntest höchstens erreichen, dass du in bestimmten Fällen die Diskussionsseite in der ausgelieferten Version der Beobachtungsliste unsichtbar haben möchtest, oder was immer.
  • Das Benutzerskript listPageOptions@PerfektesChaos ermöglicht das.

VG --PerfektesChaos 17:18, 12. Feb. 2021 (CET)

@Liberealist, Legikajlerni: vielleicht hilft euch als Workaround zu Abschnitts-Beobachtung Benutzer:FNDE/secWatch (auch wenn daran wohl nicht alles ideal ist)? --Johannnes89 (Diskussion) 00:39, 6. Mär. 2021 (CET)

Danke für die Erläuterungen und weiterführenden Hinweise!.--Legi (Diskussion) 01:17, 27. Apr. 2021 (CEST)

Alias für Vorlagen-Namensraum

In Hilfe:Namensräume sind die gegenwärtig exitierenden Namensräume und ihre Aliasse aufgeführt. Da Vorlagen praktisch ständig und überall gebraucht werden, vermisse ich leider einen kurzen, griffigen Alias für Vorlage:. Beispielsweise könnte man V: verwenden, oder auch T:, in Anlehnung an die englische Bezeichnung. Was haltet ihr davon? -- Indoor-Fanatiker (Diskussion) 03:39, 7. Mai 2021 (CEST)

Zu den beiden Vorschlägen:

1. V:3D-Modellierung gibt es schon.
2. t: ist sicher nichts, was deutschsprachigen Wikipedianern den Umgang mit Vorlagenprogrammierungen, der ohnehin für viele Benutzies schwierig ist, weiter erleichtern würde.

Generell sind Abkürzungen eine Barriere für alle, die sie sich nicht selbst ausgedacht haben, und verkomplizieren alle Angelegenheiten und führen zu einem Insider-Dschungel.

• Das war mal vor einem bis anderthalb Jahrzehnten Mode gewesen.
• Inzwischen gibt es so viele Begriffe und Schlagwörter und Seiten, dass für sie keine eindeutigen Abkürzungen mehr möglich sind. Wir haben schon 3000 davon; das kann sich niemand mehr merken.
• Schon lange, auch in der Welt da draußen, geht man in Informationstechnik usw. zu selbsterklärenden Bezeichnungen über. Abkürzerei war mal in den 1960ern notwendig gewesen.

Das verschafft einmalig den manuell Tippenden ein oder zwei Sekunden Vorteil, und kostet in den Jahren danach jedem Nachfolgenden eine Minute Aufwand zur Recherche, bis irgendwann Zehntausende deine Abkürzung gelernt haben. Oder sie geben es ganz auf, weil alles zu unverständlich.

• Intelligente Leute arbeiten mit C&P und haben einen Spickzettel zur Hand, auch auf dem eigenen Rechner, von dem sich alles abkopieren lässt.
• Da steht ggf. auch der volle Name der Vorlage, so dass die Tastatur gar nicht mehr angefasst werden muss.

Ungefähr ein bis zwei Dutzend Abkürzungen für die ganz zentralen ganz häufgen ganz wichtigen Angelegenheiten sind für eine Community zumutbar und sinnvoll erlernbar; was darüber ist das ist von Übel.

VG --PerfektesChaos 15:55, 7. Mai 2021 (CEST)

Wenn ich hier nach einem Benutzer suche, gebe ich oben der Wikipedia-Suchleiste immer „user:<Benutzername>“ ein, weil erstens „user“ etwas kürzer ist als „benutzer“ und ich mich zweitens bei dem Wort „benutzer“ gerne mal vertippe, weil die Buchstaben E, R, T, Z und U auf der Tastatur direkt nebeneinander liegen.

Dieses Vorgehen über die Suchleiste hat gegenüber copy & paste den Vorteil, dass man den gesuchten Benutzernamen nicht genau zu kennen braucht – nach den ersten Anfangsbuchstaben des Namens bekommt man bereits Suchvorschläge angezeigt.

Ähnlich verhält es sich bei Vorlagen. Man braucht nur „vorlage:l“ einzutippen und schon erscheint auf Platz 1 der Vorschlagsliste Vorlage:Löschantrag und kann durch einfachen Druck auf Enter ausgewählt werden. Wenn man sich nur das lästige Eintippen des langen Wortes „vorlage“ ersparen könnte! Leider führt „temp:Löschantrag“ nicht zum Erfolg, sondern auf die Seite der Suchergebnisse.

Ich wäre sehr dankbar, wenn man auch eine ähnliche Abkürzung für den Vorlagen-Namensraum einführen könnte, analog zu den bereits bestehenden Abkürzungen BD, WP, WD etc. Weiterhin fände ich es sinnvoll, auch für den Namensraum (Artikel-)Diskussion einen Alias einzuführen. -- Indoor-Fanatiker (Diskussion) 17:45, 7. Mai 2021 (CEST)

Mobile Version zum Standard machen - auch am Desktop

Ich frage mich seit längerem schon, ob man nicht die mobile Version der Wiki-Seiten zum Standard machen kann. Denn gerade wenn man einen breiteren Monitor hat, dann ist es echt anstrengend, die Texte zu lesen, da die Laufweite der Zeilen einfach viel zu weit ist. Da spielen die Augen quasi Tischtennis. Man sagt, dass für einen schnellen Lesefluss nicht mehr als 80 Zeichen pro Zeile gesetzt werden sollten. Gut, wenn es ein paar mehr werden, wäre das sicherlich auch nicht strafbar. Die mobile Version der Seiten erfüllt das ganz gut. Unabhängig davon ist sie auch am Desktop einfach moderner, während das eigentliche Desktop-Design ziemlich in die Jahre gekommen aussieht :F (Keine Ahnung, ob der Vorschlag hier richtig platziert ist, aber ich dachte mir, ich versuche es einfach mal) --Durchschnittsperson (Diskussion) 11:41, 5. Jul. 2021 (CEST)

Veto. Aber sowas von. --CC (Diskussion) 11:43, 5. Jul. 2021 (CEST)

Ich würde mich freuen, wenn du dein Veto auch noch mit Argumenten unterlegen könntest. Wie oben beschrieben: Dass so lange Zeilen den Lesefluss behindern, würde ich als allgemein anerkannt ansehen. Deswegen würde mich interessieren, warum du dich bewusst gegen diese Erkenntnis stellen möchtest.--Durchschnittsperson (Diskussion) 13:32, 7. Jul. 2021 (CEST)

Wenn es dich stört kannst du umschalten. Standards werden nicht auf Zuruf geändert. --CC (Diskussion) 13:34, 7. Jul. 2021 (CEST)

"Auf Zuruf" finde ich ziemlich polemisch. Ich habe hier einfach nur einen Vorschlag gemacht und zur Diskussion gestellt - und mich nicht hingestellt und gesagt "Macht das jetzt, weil ich das so sage!". Keine Ahnung, worin das Problem besteht, ein Thema einfach mal sachlich zu diskutieren. Am Ende kann man es ja trotzdem ablehnen. Aber dann bitte mit fundierten Argumenten und nicht mit "Find ich doof, weil isso". --Durchschnittsperson (Diskussion) 20:36, 11. Jul. 2021 (CEST)

Es gab dazu neulich eine Diskussion auf der Diskussionsseite des Kuriers, dort stehen auch Argumente. Was hindert dich daran, dein Browserfenster auf eine schmalere Breite zu ziehen, wenn du eine schmalere Darstellung bevorzugst? "Moderner" ist für mich in diesem Zusammenhang kein maßgebliches Kriterium, denn es geht nicht um Mode. "Funktioneller" wäre wichtiger, und da sehe ich die bisherige Lösung einer vollständig variablen Breite, bei der jeder sich selbst das Fenster auf die von ihm gewünschte und von ihm als optimal eingeschätzte Breite ziehen kann, deutlich im Vorteil. Die Menschen sind halt verschieden, da muss man doch nicht allen nach Prokrustesart einen Durchschnittswert aufzwingen. --109.192.117.216 13:57, 7. Jul. 2021 (CEST)

Also wenn dir "funktioneller" wichtig ist, dann würde das auch für die Mobile Seite sprechen. Die funktioniert auf allen Geräten prächtig, ohne dass man manuell das Browserfenster verschieben müsste. Das ist das Prinzip, nachdem Webdesign im Jahr 2021 funktioniert. Der Status Quo ist, dass Wikipedia eine der wenigen Seiten ist, die nicht nach diesem Prinzip funktionieren. Das heißt, ich muss ausschließlich für meine Wiki-Besuche das Browserfenster verändern (oder eben auf die Mobile Seite umschalten). Das erscheint mir das Gegenteil von Funktional zu sein. --Durchschnittsperson (Diskussion) 20:36, 11. Jul. 2021 (CEST)

Mein Monitor hat eine Auflösung von 1920x1200 Pixel und ich ärger mich auf so vielen Seiten darüber, dass nur gefühlt die Hälfte oder oft noch weniger davon genutzt wird. Das brauch ich hier nicht auch noch. -- Chaddy · D 15:03, 7. Jul. 2021 (CEST)

Hat keine der in den Einstellungen auswählbaren Benutzeroberflächen eine dir genehme Laufweite? -- Discostu (Disk) 15:52, 7. Jul. 2021 (CEST)

Doch, die Mobile Seite hat eine mir genehme Laufweite (: --Durchschnittsperson (Diskussion) 20:36, 11. Jul. 2021 (CEST)

Mmmh, ich versuche es mal diplomatisch auszudrücken: Mein Eindruck ist, dass sich an der Diskussion gerade vorwiegend "Informatiker" beteiligen, die etwas verkopft denken, aber nicht unbedingt UX-Experten, Webdesigner oder Leute, die sich mit Typografie auskennen. Aber Design ist nicht nur subjektives Bling-Bling. In meinen Augen werden die angesprochenen Untersuchungen und Erfahrungswerte zum bestmöglichen Lesefluss viel zu leichtfertig abgetan. Ich würde mir wünschen, dass der ein oder andere noch einmal hinterfragt, ob es nicht doch einen guten Grund haben könnte, warum die große Mehrheit der (modernen) textlastigen Webseiten die Absätze eben nicht über die volle Bildschirmbreite laufen lässt. --Durchschnittsperson (Diskussion) 20:36, 11. Jul. 2021 (CEST)

@Durchschnittsperson Hast du dir in deinen Einstellungen mal die Option "Verwende klassischen Vector" deaktiviert? Damit wird eine modernisierte Vektor-Oberfläche aktiviert, die auch eine geringere Laufweite auf den Bildschirmen hat. Für Autoren halte ich das einen gangbaren Kompromiss. Am Desktop kann ich mit der rein mobilen Ansicht jedenfalls nicht wirklich gut arbeiten. --Raymond ^Disk. 20:58, 11. Jul. 2021 (CEST)

Bitte auf der Hauptseite das Suchfeld voraktivieren (Attribut autofocus)

war ursprünglich unter (Hilfe Diskussion:Suche), auf anraten nach Verbesserungsvorschläge verschoben bzw. dort gelöscht und nun auf Wikipedia:Verbesserungsvorschläge/Feature-Requests verschoben

Hallo,

auf der Hauptseite/Startseite existiert als einziges Eingabefeld das zur Suche. Die wenigsten Nutzer:Innen werden sich über die Inhalte der Hauptseite zu ihrem gesuchten Thema durchklicken und daher immer sofort das Suchfeld nutzen. So ist also davon auszugehen, dass die Mehrzahl beim Aufruf von Wikipedia als erstes in dieses Suchfeld klicken werden und müssen, da eine sofortige Texteingabe bis dato unmöglich ist.

Wie beschrieben, so wäre das nur auf der Haupseite relevant und man würde sich diesen seit ewigen Zeiten lästigen Klick ins Suchfeld ersparen. Auf allen anderen Seiten kann und sollte es so bleiben wie es ist.

Vielleicht kann sich dazu mal jemand erbarmen und das auf der Hauptseite entsprechend umstellen.

Danke --Pseudonym1409 (Diskussion) 17:50, 12. Jul. 2021 (CEST)

@Pseudonym1409: Wir prüfen gern derartige Anregungen.

Wir haben allerdings eine eigene Seite dafür: Wikipedia:Verbesserungsvorschläge

• Bitte schneide deinen Text hier aus und kopiere ihn dorthin.
• Dort sieht ihn auch der richtige Personenkreis.

Meine erste Stellungnahme:

• Lässt sich drüber nachdenken.
• Hauptproblem ist Performance:
  • Bei jedem Besuch jeder Seite, über zehn Millionen statische Seiten und unbegrenzt viele mit spontan kombinierbarer URL, muss ein Script erstmal nachgucken, ob das jetzt die Hauptseite ist.
  • Unter allen Seitenabrufen pro Tag ist das eine recht miese Trefferquote, auch wenn die Hauptseite eine der häufigsten Einzelseiten ist.
• Außerdem machen wir sowas grundsätzlich nur konfigurierbar, also von angemeldeten Benutzies einfach wieder abzuschalten.
• Ob das dann nun blinkt, ist wieder eine andere Frage. Aber Cursor-Positionierung im Suchfeld ist per JavaScript machbar.
• Auf Spezial:Einstellungen #mw-prefsection-gadgets im Abschnitt „Navigation“ kannst du für dich persönlich etwas einschalten, was wohl in etwa das macht was du dir vorstellst.
  • Das für alle und jeden vorzugeben ist ein anderes Geschäft.
• Nebenbei ist es nicht zwingend der Fall, dass alle beim Besuch der nichts anderes tun möchten als etwas in das Suchfeld einzugeben. Vielleicht gilt das Interesse den tagesaktuellen Themen.
• Als Suchfeld und Browser-Lesezeichen würde ich eher Spezial:Suche anempfehlen; die ist kleiner, hat nicht so viel Bildchen und geht flinker zu laden und aufzubauen. Da ist das Eingabefeld auch automatisch fokussiert und aktiv.

VG --PerfektesChaos 21:58, 12. Jul. 2021 (CEST)

@PerfektesChaos: Hm, der Hinweis zur speziellen Suchseite ist OK, aber wer kennt die schon?

Was ich eben an Info noch fand, da ich vom "focus" für Felder auf Webseiten schon mal was gelesen hatte:

Auf vielen Websites muss der Nutzer erst einmal in das Feld mit der Maus klicken, um mit dem Tippen anfangen zu können.
Das ist seit HTML5 und dem Attribut autofocus unnötig.
Jedes beliebige Formularfeld kann mit diesem Attribut versehen werden.
Wird die Seite aufgerufen, wird automatisch vom Browser(!, nicht von irgendwelchen WikiServern) der Fokus auf das Feld gesetzt, das mit autofocus im Quellcode ausgezeichnet ist und der Cursor blinkt im Feld – man kann sofort schreiben.

Das geht somit unanbhängig vom "Script für die Suche", da der Browser den Courser in das Feld setzt, aber nicht die im Suchfeld implementierte Suchfunktion. Die Suchfunktion greift je erst dann, wenn das erste Zeichen geschrieben wurde.

Es sollte ausreichen, wenn auf der Hauptseite im input-tag für das Suchfeld das Attribut autofocus eingefügt wird

<form action="/nn/index.php" id="searchform">
<input type="search" name="search" placeholder="Wikipedia durchsuchen" autofocus/>
</form>

Bei Google sieht es z.B. so aus: autofocus=""
Auf der Seite mit der Spezial:Suche ist es bereits ähnlich gelöst mit "autofocus":true

Wie auch immer es über gängige Standards erreicht werden kann, so ist das Attribut der fehlende Schlüssel.
Eingriffe beim Suchscript sind hierzu ganz sicher nicht erforderlich, sondern nur im Quelltext der Webseite
Best --Pseudonym1409 (Diskussion) 00:59, 13. Jul. 2021 (CEST)

Für angemeldete Benutzer gibt es das schon: Unter Einstellungen/Helferlein/Navigation gibt es die Option "Cursor-Platzierung auf der Hauptseite immer in der Suchbox" -- Perrak (Disk) 01:27, 13. Jul. 2021 (CEST)

Die Programmierung der Webseite müsstest du bei der WMF erwirken.

• Es ist wenig aussichtsreich, dass dort in absehbarer Zeit eine solche Ausnahmeregelung für Hauptseiten eingebaut würde.
• Auswirkungen hat das nicht nur auf etwa 1000 WMF-Wikis, sondern auch Zigtausende Wikis, welche die MediaWiki-Software benutzen. Da ist man bei solchen Änderungen sehr konservativ, und es bedarf vieler Fürsprecher. Es muss immer für alle von Vorteil sein.
• Die JavaScript-Lösung für alle gibt es seit 2005 als Vorschlag per Phabricator – Bug/Feature: 3864 und wurde Anfang 2021 mal wieder abgelehnt.
  • Ein Grund wurde nicht benannt; aber Performance wäre hinreichend.
  • Eine PHP-Lösung, welche das ausgelieferte HTML-Dokument verändert, und nur das einer Hauptseite des Projekts, wurde bislang nicht erörtert.
  • Beachte, dass die Überlegungen mit 2005 bis nach HTML.4 zurückgehen, die erwähnte Eigenschaft und ihre Umsetzung in allen üblichen Browsern jedoch ggf. jüngeren Datums ist.
• Implementiert werden muss PHP für jede Skin, weil in ihr das Suchfeld definiert wird. Vermutlich wärst du bereits mit Vector zufrieden.

VG --PerfektesChaos 09:54, 13. Jul. 2021 (CEST)

Update Das Speichern per Option "Helferlein" im angemeldeten Status ist bekannt, aber keine Lösung, da man auf Webseiten nur dann angemeldet ist, wenn man darin etwas tun will, wozu der Login auch notwendig ist. Dass es für Euch normal ist, ständig angemeldet zu sein, ist für die Masse derjenigen, die nur zum Lesen kommt, sicher nicht der gängige Standard. Und sich erst anzumelden, um dann ein aktiviertes Suchfeld auf der Hauptseite zu erlangen ist doch irgendwie Nonsens, wie Buchbinder Wanninger.

Die, die abwiegeln, die könnten hier doch mal eine Auswertung eines beliebigen Monats über die Hauptseite liefern? Ich wüsste leider nicht, wie das geht. Aber die alten Hasen können da sicher etwas beisteuern?

Von Interesse wäre die Anzahl aller von extern kommenden User innerhalb eines Monats, die die Haupseite als Einstieg nutzen und

• die Hauptseite sofort wieder schließen oder über die Adresszeile oder per Favoriten auf eine andere Domain wechseln
• das Suchfeld mit Texteingabe zum Verlassen der Hauptseite nutzen
• das Suchfeld unter Verwendung des Eingabewerkzeug (auch per gespeicherter Voreinstellung), zum Verlassen der Hauptseite nutzen
• die auf einen Link auf der Haupseite klicken, um diese zu verlassen
• mit Aufruf der Hauptseite direkt auf Anmelden klicken

Bei der Auswertung sollten die User ausgeklammert werden, die von extern kommen und die

• dauerhaft angemeldet sind

da zu erwarten wäre, dass diese beim Einstieg über die Hauptseite ganz anders agieren, als jemand, der etwas lesen/suchen will.

Man las ja vor nicht allzu langer Zeit, dass Wikipedia benutzerfreundlicher sein möchte oder es zumindest versucht zu werden. Eine gesteigerte user experience kann nur erbringen, wer auswertet. Wer es nicht tut oder nur abwinkt, der ist dann eher im Bereich, das machen wir seit 25 Jahren so, zu verorten. Das sind dann die, die auch bei der Deutschen Bundespost für ein längeres Telefonkabel gerne 1 DM mehr Gebühr pro Monat bezahlten, weil es schon immer so war. Änderung ist für die, die es umsetzen, immer Aufwand, aber nur der Wandel führt in die Zukunft.

Ich bín davon überzeugt, dass die Mehrzahl der Nutzer die von extern kommen und mit der Hauptseite einsteigen und die nicht dauerhaft angemeldet sind und auch auf Wikipedia bleiben, nach Aufruf der Hauptseite am häufigsten das Suchfeld nutzen und daher die Hauptseite wie eine Suchmaschine nutzen.

Für den, der auf der Hauptseite das Suchfeld nicht nutzt und etwas anderes anklicken wird, für den hat die Vorauswahl des Suchfeldes keinerlei Auswirkung. Der Autofocus ist ein Mehrwert an Benutzerfreundlichkeit, von dem tausende von Webseiten mit einer erhöhten Benutzerfreundlichkeit und somit von einer erhöhten Benutzerzufriedenheit profitieren werden. Es geht hier um User expirience. Der Autofocus ist garantiert keine Performancefrage, da die Suche erst beim Tippen richtig losschlägt. Zudem stellt sich die Frage, warum ein Courser im Suchfeld per Behauptung ein Problem darstellen könnte, wenn bei jedem der in das Suchfeld klickt, dieses Eingabewerkzeug eingeblendet wird? Das könnte man ja auch neben dem Suchfeld anklickbar einbauen, was aber auch niemand machte, da es in den Standardsettings bei jedem angezeigt wird und das, oh Wunder, ganz ohne Performanceprobleme, obwohls prozentual wohl kaum jemand nutzt.

Es gibt noch mehr solch seltsame altbackenen Dinge, so z.B. warum man immer die ganze Seite eine Artikels editieren muss, wenn man nur die Einleitung bearbeiten will? Das ist auch seit 25 Jahren so und keiner hat es je hinterfragt.

Aber jetzt geht es erst mal nur um die Auswertung, wie die Hauptseite real genutzt wird und bin auf deren Nutzungsstatistik wirklich gespannt. Und wer kann, der liefert gleich den Impact vom Eingabewerkzeug mit (vorher/nachher), denn den Impact auf die Performance beim Eingabewerkzeug wurde ja auch mal begutachtet.

Wie jemand bereits schrieb: Wir prüfen gern derartige Anregungen. Da hilft jetzt nur die Bewertung per Auswertung um damit die Planung der dann zu erfolgenden weitergehenden Prüfung und hoffentlich Umsetzung einzuleiten. Ein "das könnte länger dauern, bis es implementiert wäre, ist keine Ausrede, wenn Wikipedia wie angekündigt eine höhere Benutzerzufriedenheit wirklich erreichen will. Best --Pseudonym1409 (Diskussion) 08:41, 17. Jul. 2021 (CEST)

hiero: Steuerung der Schreibrichtung

Diese Diskussion habe ich von Wikipedia:Verbesserungsvorschläge#hiero: Steuerung der Schreibrichtung hierher verschoben.--Vollbracht (Diskussion) 15:28, 12. Nov. 2021 (CET)

Die Standard-Schreibrichtung für Hieroglyphen war rtl (von rechts nach links). In altägyptischen Texten konnte sich die Schreibrichtung jedoch teilweise mitten in einer Zeile auch mal umkehren. Wir können hier die Hieros nur ltr (von links nach rechts) schreiben. Für rtl müssten auch die einzelnen Glyphen gespiegelt werden. Ohne das können viele Textpassagen nicht richtig abgeschrieben / dargestellt werden. --Vollbracht (Diskussion) 12:08, 10. Nov. 2021 (CET)

Jan Assmann schreibt 2002 in seinem Artikel "Sieben Funktionen der ägyptischen Hieroglyphenschrift" auf Seite 35

„Im Gegensatz zur Kursivschrift, die immer von rechts nach links geschrieben wird, ist bei den Hieroglyphen die Schiftrichtung flexibel. Das geht so weit, das[s] manchmal im Rahmen ein und derselben Schriftzeile die Ausrichtung einzelner Schriftzeichen umgekehrt wird.“

Ich schlage vor,

• <hiero> zunächst als deprecated zu markieren und durch <hiero ltr> zu ersetzen;
• ein <hiero rtl> zu definieren und ggf. nach einer Übergangsphase zum Synonym für <hiero> zu machen;
• ein <rtl> zu definieren, um innerhalb eines <hiero ltr>-Abschnittes die Schriftrichtung zu wechseln;
• ein <ltr> zu definieren, um innerhalb eines <hiero rtl>-Abschnittes die Schriftrichtung zu wechseln;
• die hiero-Icons durch SVG-Grafiken zu ersetzen, ohne die Ausrichtung zu ändern;
• die Darstellung in <hiero rtl>- und <rtl>-Abschnitten automatisch horizontal zu spiegeln, sowohl die einzelnen Zeichen, als auch die horizontale Reihenfolge, nicht aber nicht erkannte Zeichen und deren Reihenfolge. <hiero rtl>X1.oder.X2.und.<ltr>X1.oder.X2</ltr></hiero> würde zu:

oder und oder

also "vorne" (rechts):

und oder

und "hinten" (links):

oder

• Fehler in der Darstellung und ggf. Spiegelung der nicht erkannten Zeichen sind möglicherweise erst mal hinnehmbar.

Ich wäre bereit, auch hierbei einen Beitrag zu leisten, weiß aber noch nicht, wo ich damit anfangen kann.--Vollbracht (Diskussion) 13:08, 10. Nov. 2021 (CET)

Es gibt Unicode und da gibt es auch zwei Blöcke zu Ägyptischen Hieroglyphen. Dieses <hiero> stammt irgendwann aus der Zeit um/vor 2004. in 2004 wurde auch die Kodierung der Wikipedia von Western (ISO 8859-1) auf UTF-8 (Unicode) umgestellt. Unicode selbst enthält laut Unicode ägyptische Hieroglyphen seit Oktober 2009. Jetzt sind 12 Jahre vergangen und die Rechner sollten das auch können. Siehe Unicodeblock Ägyptische Hieroglyphen/13000 bis 131FF und Unicodeblock Ägyptische Hieroglyphen/13200 bis 1342F. Die zweite Spalte sind Unicode-kodierte Zeichen, die sind bei mir ausnahmslos alle darstellbar (leider überschneiden sie sich, weil jemand meinte diese in 4facher Größe darzustellen), die dritte Spalte mit <hiero> zeigt manchmal Buchstaben an, die ist offenbar nicht vollständig. Bevor man das (fast) tote Pferd <hiero> weiter- und zu Tode reitet, sollte man überlegen und untersuchen, ob denn nicht der Unicode-Zeichensatz alle Anforderungen erfüllt und ob man nicht umsteigt und <hiero> in Rente schickt. --Wurgl (Diskussion) 16:49, 10. Nov. 2021 (CET)

Sind gewöhnlich Zeichensätze auf den Nutzerrechnern installiert, die auch die zwei Blöcke umfassen? --Silvicola ^Disk 18:30, 10. Nov. 2021 (CET)

Oh, schlecht! Es wäre ein Leichtes, aus einem solchen (Vektor-)Font Vektorgrafiken zu extrahieren. Aber was wäre dann mit den Rechten? Existiert ein public domain font damit? Und dann bleibt immer noch, dass Vektorgrafiken sich problemlos spiegeln lassen. Buchstaben verhalten sich da weniger berechenbar. Und der Font kennt ja stets nur eine Schreibrichtung. Die Hieroglyphen kennen drei (innerhalb von einem Text!). Zur Verwendung von <hiero... sehe ich auch für die Zukunft keine Alternative. Zumal eine künftige Version auch Formatierungsmuster berücksichtigen kann, die in ihrer Bedeutung zwar unserem Blocksatz entsprechen, aber in keinster Weise damit kompatibel ist, da im Schriftsatz aller Buchstabenschriften zwar eine Variation der Laufweite und sogar der Zeichenbreite, nicht aber der proportionalen Größenanpassung in Abhängigkeit von der zweidimensionalen Anordnung bekannt / vorgesehen ist. --Vollbracht (Diskussion) 13:44, 12. Nov. 2021 (CET)

Wie auch immer. Ich kann nur sagen, dass es die Zeichen im Unicode-Zeichensatz gibt. Nachdem ich hier Linux habe und dieses Linux diese Zeichen darstellen kann, wird es wohl keine Bezahllizenz sein, welche es genau ist … keine Ahnung. --Wurgl (Diskussion) 14:09, 12. Nov. 2021 (CET)

Die Lizenz ist bei mir "SUSE-Permissive". Leider finde ich keine Beschreibung dazu. --Vollbracht (Diskussion) 17:06, 12. Nov. 2021 (CET)

Ich schlage weiterhin vor:

• Ein Bot sollte künftig alle Seiten, die Hieroglyphenfonts verwenden, so bearbeiten, dass entsprechende Textpassagen in <hiero ltr>-Abschnitte umgewandelt werden. Damit werden alle Verwender dieser Fonts unterstützt.
• Eine Rückkonversion sollte bis auf weiteres nicht vorgesehen sein.
• Bei der Vorschau einer Seite, die solche "Buchstaben" enthält, sollte ein Hinweis erscheinen, dass diese Seite bei anderen Benutzern möglicherweise erst nach einem Bot-Durchlauf korrekt dargestellt wird.
• Ein Bot sollte künftig (zeitnah) alle Seiten, die <hiero>-Abschnitte enthalten, so ändern, dass diese in <hiero ltr>-Abschnitte umgewandelt werden. <hiero rtl>-Abschnitte sollten unangetastet bleiben. Derzeit werden rtl und ltr einfach ignoriert.
• Die Vorschau sollte künftig (danach) den Hinweis anzeigen, dass <hiero ltr>-Tags an Stelle von <hiero>-Tags verwendet werden sollten, wann immer die Vorschau einer Seite mit <hiero>-Tags angezeigt werden soll.
• Die am Anfang genannten Vorschläge sollten danach umgesetzt werden.

Wo sollte ich mich bezüglich der Mitarbeit bei der Erstellung von Bots hin wenden?--Vollbracht (Diskussion) 14:37, 12. Nov. 2021 (CET)

hiero: Erweiterung des Parsings

Abschnitte die in <hiero>...</hiero> eingeklammert werden, werden nicht weiter auf Wikitext-Inhalte geparst. Das schränkt die Möglichkeit für Vorlagen extrem ein. --Vollbracht (Diskussion) 22:20, 28. Nov. 2021 (CET)