Diese Diskussionsseite dient dazu, Verbesserungen an der Projektseite „Meinungsbilder/Darstellung der Seiten-Koordinaten“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.
Was da inhaltlich steht, ist mir bei einer halben Million Gebilden rechts oben auf irgendwelchen Seiten eher egal. Hier geht es erstmal um die Technik der Seite.
Schönen Dank dafür – aber da bist du statistisch keine Hilfe. Du müsstest eins tiefer rücken, zu den Unterstützern.
dass man etwas tun muss, ist klar. Das unterstütze ich auch. Aber 100% fertig ist das noch nicht. Somit soll man da nicht unterschreiben. Das verstehe ich nicht ganz. --Steffen2 (Diskussion) 15:31, 1. Feb. 2021 (CET)Beantworten
So wie ich das Meinungsbild verstehe, geht es dabei "nur" um die Position der Koordinate und Icons? (was aber, um zukunftsträchtig zu sein, grössere Umbauten erfordert). Mir - und vielleicht anderen - würden ein paar Sreenshots zu den Varianten helfen, um die Unterschiede der Position zu verstehen (aktuell / neu), ergänzt mit einer detaillierteren Beschreibung der Auswikungen auf andere Bereiche (damit es auch für nicht-Insider vertändlich ist). Das derzeitige System a) Koordinate anzeigen (schlecht kopierbar, besser wäre Rechtsklick mit Auswahl des Formates), b) Geohack (verwirrender Katalog) c) Mini-Atlas (verdeckt Artikel, lässt sich nicht verschieben, schlechte Karte), d) eingeblendete Karte im Artikelkopf incl. hervorgehobene Linien, Punkte, Flächen (finde ich gut) ist nicht Inhalt des MB?
Das MB ist nur ein kleiner Teil der möglichen Entwicklungsschritte, wenn man denn WP und OSM stärker verbinden würde. Noch nicht verstanden habe ich auch, wie sich das MB auf die einzelnen Geo-Projekte/-Gruppen/-Mitarbeiter auswirkt? (und ja, ich würde das MB sachlicher formulieren). Gruss, --Markus (Diskussion) 18:41, 1. Feb. 2021 (CET)Beantworten
(Nach BK) Es verändert sich aber etwas Wesentliches: die Koordinaten selbst werden oben rechts nicht mehr angezeigt – übrigens auch im Gegensatz zur ggw. Praxis auf enwiki, die weiter oben als "Vorbild" bezeichnet wird, was als missverständlich empfunden werden kann. Dass die Koordinaten selbst oben rechts verschwinden, könnte man unter "Kontra" beim Vorschlag "Icon im Seitenkopf" präzisieren, indem man den lapidaren Satz "Es verändert sich etwas" entsprechend ersetzt. Den Titel des Vorschlags ("Icon im Seitenkopf") würde ich nicht ändern, denn "Zusätzliches..." ist unnötig länger und stimmt bei den meisten Artikeln auch nicht, nämlich bei all jenen, die ansonsten gar kein Icon haben. --Yen Zotto (Diskussion) 18:51, 1. Feb. 2021 (CET)Beantworten
Dieser vorgeschlagene Icon soll ja gerade der Nachfolger der externen Kartendienst-Verlinkungen im Seitenkopf werden: „Icon soll die Tradition der historischen Seiten-Koordinaten rechts oben fortführen“
Es heißt ja an jeder Stelle: „Dies setzt die Akzeptanz des ersten Vorschlags voraus.“
Der Icon ist also nicht völlig neu und zusätzlich, sondern der Ersatz für die bisher dort zu findenden Werkzeuglinks.
Später im Abstimmungsteil heißt es dann ja auch: „Vorschlag zu 2: Zusätzlich Icon im Seitenkopf“
@ Inhalte & Screenshots:
Es ist völlig egal, was für Texte oder externe Verlinkungen dort zurzeit angegeben sind oder zukünftig einmal werden.
Umseitig hatte ich als Beispiel 0-km-Stein angegeben. Wenn du das anklickst, dann siehst du es live, und brauchst keinen Screenshot.
Bei KW Sagittarii siehst du dort momentan Datenbanklinks zu KW Sagittarii und ein Icon.
Es ist völlig unerheblich, was für OSM-Links oder Icons oder Geohack oder Mini-Atlas oder sonstige externe Verlinkungen jetzt oder zukünftig einmal angeboten werden.
Es geht hier ausschließlich um die Technologie innerhalb der Wiki-Seite, nicht um den Inhalt.
@ Vorbild enwiki:
Unsere Spielkinder hatten sich die Technik tatsächlich aus der enWP kopiert gehabt.
Aber in der enWP hatte man entweder von Anfang an oder aber sehr bald immer an der Stelle der Einbindung sichtbar die Informationen angezeigt, und die im Interface dargestellten gleichartigen Infos immer nur als Duplikat betrachtet. Weshalb es auf Mobilgeräten immer eine funktionierende Darstellung gab, und es dort auch kein Drama wäre, wenn das auch auf Desktop abgeschaltet werden müsste.
Unsere Herzchen hatten jedoch bewusst die sichtbare Präsentation unterdrückt und das ausschließlich im Seitenkopf angezeigt.
Letzter Kommentar: vor 3 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Erst einmal vielen Dank für den MB-Entwurf, den ich sehr gut finde, wenn auch vielleicht etwas Feinschliff und stellenweise mehr Diplomatie in der Form (nicht im Inhalt) ihm noch guttäte. Zum Vorschlag 1 ("Vorlageneinbindungen direkt sichtbar") wäre es vielleicht nützlich, zu erfahren, ob die Funktionen der ggw. Lösung, die beim Klick auf die jetzt rechts neben der Koordinateneinblendung plazierten Icons eine Karte einblenden bzw. eine Karte in einem Popup-Fenster erscheinen lassen, in dem gemäß Vorschlag unten auf der Seite erscheinenden Kasten beibehalten werden können und sollen. Gruß, --Yen Zotto (Diskussion) 19:00, 1. Feb. 2021 (CET)Beantworten
Nachtrag: gerade sehe ich, dass dazu ja schon was dasteht, nämlich "ggf. auch mehrere Direktverlinkungen, falls gewünscht". Das hatte ich zunächst überlesen. Nichts für ungut. Frage mich aber, ob man das noch deutlicher erläutern sollte. --Yen Zotto (Diskussion) 19:06, 1. Feb. 2021 (CET)Beantworten
Unter #Thematische Abgrenzung schrub ich bereits: „Nicht von diesem MB betroffen sind die Fälle, wo im laufenden Fließtext oder an anderen Stellen in normaler Schriftgröße weitere Einzelkoordinaten eingebettet sind.“
Wenn also irgendwo eine Lagekarte angeboten wird, und in diesem Zusammenhang auch Koordinaten genannt werden, und externe Verlinkungen angeboten werden, dann ist das nicht Thema.
Allerdings könnte ein zukünftiger Icon direkt auf die Stelle im Artikel verlinken, wo diese Informationen repräsentativ für die gesamte Seite dargestellt werden.
Hier geht es ausschließlich um die Situation, dass die Vorlageneinbindung an der Stelle, wo sie eingebunden ist, zurzeit völlig unsichtbar wäre.
Was genau das Problem ist: Deshalb kann diese Vorlageneinbindung überall und nirgends auftauchen, und deshalb gibt es keine triviale Lösung, sie mal schnell eben sichtbar zu schalten.
Du hast mich nicht verstanden. Ich meinte nicht eventuell im Artikel vorhandene Lagekarten, auch nicht Koordinaten, die im Fließtext oder sonstwo im Artikel eingebunden sind, sondern die Ausklappkarte sowie die Popup-Karte, die im derzeitigen Hack verfügbar sind, wenn man auf eins der beiden Icons oben rechts an der z. Z. verwendeten "illegalen" Stelle klickt. Diese Karten finden vermutlich viele Benutzer sinnvoll, und es wäre daher m. E. opportun, explizit klarzustellen, ob sie in dem künftig (hoffentlich) unten im Artikel erscheinenden Kasten auch in ähnlicher Form verfügbar wären wie jetzt an der "unerlaubten" Stelle. --Yen Zotto (Diskussion) 10:25, 2. Feb. 2021 (CET)Beantworten
Das habe ich auch nicht verstanden.
Es ist völlig egal, um was für Inhalte es ginge, und ob die irgendwas direkt anzeigen oder ausklappen oder sonstwas.
Es geht ausschließlich um die Technologie, mit der die Inhalte von der Stelle, wo die generierende Vorlage eingebunden ist, in die Ecke oben rechts verschoben werden, unabhängig davon was auch immer das für Inhalte sein mögen.
Jegliche Inhalte funktionieren an der physischen Einbindungsstelle natürlich genauso wie da rechts oben; im Zweifelsfall sogar besser.
Letzter Kommentar: vor 3 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Ich sehe den Vorschlag durchaus positiv, nachhaltige Lösungen sind immer besser als unsystematisches Gewurschtel. Trotzdem habe ich ganz viele Fragen. Falls eine Frage überflüssig sein sollte, weil es schon dasteht und ich nur zu doof zum Finden war, bitte ich um kurzen Hinweis.
1. War die Bastelei von 2005 ein deutscher Alleingang und ist das aktuelle Problem somit ein ausschließlich lokales und daher mit ausschließlich lokalen Mitteln zu beheben?
2. Zur Differenzierung der betroffenen Koordinaten: Sehe ich das richtig, dass exakt diejenigen Koordinaten gemeint sind, die eine Anzeige rechts oben erzeugen? Was dort nicht erscheint, ist nicht Gegenstand des MB?
3. Betrachten wir für das MB die Koordinatenanzeige mit Link zu Geohack und die beiden Karteneinblendungen als Einheit?
4. Würde im Fall des zweiten Vorschlags (zusätzliches Icon) dieses Icon ebenfalls wieder im "verbotenen" Bereich landen? Wenn nein: Warum geht es dann anders? Wenn ja: Warum ist es dann kein Problem?
5. Gäbe es eine Möglichkeit, den Koordinatenlink in korrekter Weise nahe der heutigen Position einzubinden? Z. B. rechtsbündig am Artikelanfang (als erste Zeile des Quelltextes), womit er noch oberhalb von Infoboxen und Bildeinbindungen stünde?
6. Keine Frage, eher eine Bitte: Eine Visualisierung des Vorschlags mit vorher/nachher als Screenshots bzw. mit modifiziertem Screenhot wäre für das Verständnis hilfreich. Ein paar Katastrophen-Screenshots von heutigen Fehlanzeigen könnten zudem das Problem veranschaulichen (OK, Links könnten es auch tun). MBxd1 (Diskussion) 21:24, 1. Feb. 2021 (CET)Beantworten
deutscher Alleingang
Es wurde abgeguckt aus der enWP.
Aber in der enWP hatte man entweder von Anfang an oder aber sehr bald immer an der Stelle der Einbindung sichtbar die Informationen angezeigt, und die im Interface dargestellten gleichartigen Infos immer nur als Duplikat betrachtet. Weshalb es auf Mobilgeräten immer eine funktionierende Darstellung gab, und es dort auch kein Drama wäre, wenn das Duplikat auch auf Desktop abgeschaltet werden müsste.
Unsere Herzchen hatten jedoch bewusst die sichtbare Präsentation unterdrückt und das ausschließlich im Seitenkopf angezeigt.
MediaWiki lehnt es bereits seit Jahren ab, im Design ihrer Software auch nur im geringsten auf unsere Jugendsünden Rücksicht zu nehmen, und wird es eines Tages aus Sicherheitsgründen unterbinden, damit nicht irrtümlich oder vorsätzlich vandalierende Elemente des Inhaltsbereichs das Interface lahmlegen und unbenutzbar machen. Die wissen, dass es bei uns und einer Handvoll unter knapp 1000 Wikis noch sowas gibt, und informieren uns immerhin, aber irgendwann ist Sense.
Zur Differenzierung der betroffenen Koordinaten
Es ist das gemeint, was du im angegebenen Beispiel 0-km-Stein rechts oben siehst.
Was dort nicht erscheint, ist nicht Gegenstand des MB: #Thematische Abgrenzung: „Nicht von diesem MB betroffen sind die Fälle, wo im laufenden Fließtext oder an anderen Stellen in normaler Schriftgröße weitere Einzelkoordinaten eingebettet sind.“
Betrachten wir für das MB die Koordinatenanzeige mit Link zu Geohack und die beiden Karteneinblendungen als Einheit?
Ja.
Es ist völlig egal, was für Inhalte mit welchen Links und welchen Icons dort dargestellt werden; es geht nur um die Technologie innerhalb der Wiki-Seite.
Würde im Fall des zweiten Vorschlags (zusätzliches Icon) wieder im "verbotenen" Bereich landen? Wenn nein: Warum geht es dann anders? Wenn ja: Warum ist es dann kein Problem?
Es landet in einem ausdrücklich dafür vorgesehenen Bereich für etwa vier oder fünf Icons, in dem seit 2016 bereits unsere exzellente, lesenswerte Bapperl und die Gesprochene Version dargestellt werden; als Icon mit einer Verlinkung zum unteren Ende der Seite.
Diese Icons werden damit zum Bestandteil des normalen MediaWiki-Interface. Sie werden als völlig normale Elemente dargestellt und verschaffen sich im Rahmen ihres zulässigen Landeplatzes den erforderlichen Platz, rücken also eins weiter wenn noch ein Icon hinzukommt, und überlappen sich nicht.
Gäbe es eine Möglichkeit, den Koordinatenlink in korrekter Weise nahe der heutigen Position einzubinden?
Nur, wenn die Vorlageneinbindung selbst dann nicht wie vorgeschlagen ganz am Ende des Artikels erfolgt, sondern eben ganz oben. Also so wie ein BKH vor dem Einleitungsabschnitt, in ziemlich ähnlicher Ausdehnung. Eine ganz normale Vorlage dann halt, wie alle anderen auch, und in normaler menschenfreundlicher Schriftgröße.
Nicht mein Problem; wenn du meinst, dass dies die Lösung für sämtliche Artikel wäre, und alle anderen Situationen für dich damit zufriedenstellend gelöst wären, kannst du gern parallel eine Umfrage nach neuem Artikel-Design starten.
Der Aufwand für Bot-Läufe und Umtopfung sehr vieler Vorlageneinbindungen ist identisch; ob da nun welche nach ganz unten oberhalb der Navileisten gebeamt werden müssen oder aber zwischen BKH und Einleitungsabschnitt ist einerlei.
Da ich die Community jedoch als eher konservativ einschätze, habe ich lieber die unauffälligere Stelle an den Navileisten vorgeschlagen, zumal sich nicht jeder Leser bei der Lektüre jedes Artikels sofort erstmal ganz doll für Geokoordinaten interessieren wird.
Erstmal vielen Dank für die schnelle und umfassende Antwort. 1., 3., 4. und 6. sind damit auch geklärt.
zu 2.: Koordinaten können auch hinter Symbollinks verborgen werden, wenn die Anzeige sonst zu viel Platz verbrauchen würde. Das wird (in relativ geringem Ausmaß) bei Bahnstreckentabelleninfoboxen gemacht. Demnach dann wohl auch out of scope, weil nicht rechts oben angezeigt.
zu 5.: Der Ansatz bei einer korrekten Anzeige rechts oben wäre, so nah wie möglich am Status quo zu bleiben, aus optischer Perspektive. Es interessiert ja nicht, wo es im Quelltext steht, es geht um das Erscheinungsbild des Artikels. Einen dicken Balken braucht man dafür nicht, den haben wir ja dort, weil wir da einen dicken Balken haben wollen. Meine Vorstellung wäre eine Koordinatenanzeige in gleicher Schriftgröße wie jetzt, nur in einem Textkasten rechts oben, dann eben unter der Titellinie oberhalb des Bilds (so würde es beim 0-km-Stein erscheinen. Etwas auffälliger als bisher, aber insgesamt nahe am Status quo. Sollte als Vorlage doch machbar sein? OK, ich habe verstanden, dass das nicht Deinen Vorstellungen entspricht, aber es käme dem Status quo am nächsten, würde das Icon überflüssig machen und könnte am ehesten zustimmungsfähig sein. MBxd1 (Diskussion) 23:02, 1. Feb. 2021 (CET)Beantworten
Sähe aber zumindest bei Artikeln mit Infobox vmtl. grauslich aus. Und wohin mit so einem Kasten oben "rechts" in der Mobilansicht? Ich finde den umseitigen Vorschlag mit Kasten unten bei den Navileisten (und Icon oben rechts wie "Lesenswert" u.ä.) besser. Damit blieben auch in der Mobilansicht die Infos zu "Lesenswert" u.ä. und die Koordinaten in demselben Seitenbereich kombiniert, was Lesern das Auffinden erleichtern wird. --Yen Zotto (Diskussion) 10:36, 2. Feb. 2021 (CET)Beantworten
Der „Ansatz bei einer korrekten Anzeige“ ist es nicht, die Bastelei von 2005 möglichst originalgetreu auf ewige Zeiten zu konservieren.
Vielmehr erfordert der umseitige Riesenaufwand auch eine Berücksichtigung all dessen, was wir in den letzten anderthalb Jahrzehnten dazugelernt haben.
„in gleicher Schriftgröße wie jetzt“
Das ist heutzutage nicht mehr akzeptabel.
Etwa jeder zehnte unserer Leser hat eingeschränkte Sehfähigkeit.
Die historische Fummelei verwendet deswegen eine sehr kleine Schriftgröße, weil dies teilweise in den Zwischenraum zwischen zwei Zeilen úsw. gequetscht werden musste.
Eine Fortsetzung dieser Vorstellungen verstößt gegen die Barrierefreiheit und ist als Ergebnis einer sehr aufwändigen Komplettsanierung nicht zu verantworten.
Man klatscht auch heutzutage nicht mehr irgendein Blrpsmf in irgendeine Ecke. Nun, Leser, fresst das.
Heutzutage würde man eine kurze Erklärung voranstellen, etwa: „Karte mit allen Objekten dieses Artikels:“ oder „Geokoordinaten:“ und außerdem die möglicherweise unterschiedlichen Angebote an Direktverlinkungen weiter ausbauen, wozu in einem Hinweisbaustein Gelegenheit wäre. Vorstellbar wäre dort auch Paralleldarstellung in Grad-Minute-Sekunde sowie GradKommaDezimal, wenn wir schon den Platz dafür bekämen.
Eine Sanierung muss den Anforderungen der leichten Verständlichkeit, übersichtlichen Artikelgestaltung und Barrierefreiheit genügen.
Du kannst gern parallel eine separate Umfrage starten.
Dort müssten ausdrücklich und fair die sich aus deinen Vorstellungen ergebenden Nachteile dargestellt werden.
Solange sich nicht eine sehr überzeugende Mehrheit der Kommentierenden trotzdem explizit dafür ausspricht, Barrierefreiheit und Verständlichkeit über Bord zu werfen, ist das zur umseitigen Einarbeitung nicht geeignet.
Siehst Du, von all dem steht umseitig nichts. Wir sind hier in der Vorbereitungsphase, und ich bin nicht Opposition gegen den Vorschlag, daher möchte ich auch nicht wie eine solche angesprochen werden. Natürlich kann man sich fragen, wo der Leser am ehesten die Koordinaten erwarten würde, auch unbelastet vom Status quo. Das würde ich erst mal ergebnisoffen sehen. Eine "legale" Anordnung rechts oben ist kein "Konservieren von Bastelei", denn die genannten Kritikpunkte wären bei normalgroßer Schrift komplett behoben. Ich habe auch nicht gesagt, dass ich das so haben will, ich habe gefragt, ob es geht. Damit man unvoreingenommen bewerten kann, wo die Koordinaten denn nun am besten stehen. Ja, es gibt auch Argumente für die Anordnung am Ende, z. B. dass man nicht auf den Punkt genau wissen will, wo etwas ist, bevor man weiß, was es überhaupt ist.
Mal ganz andersrum gesagt: Dieses MB ist alles andere als ein Selbstläufer. Mich musst Du zumindest grundsätzlich nicht mehr überzeugen, aber wir sind doch beide lange genug dabei, um zu wissen, wie so was läuft. Die Wikipedia (ich kann es nur von der deutschen sagen) ist perfekt im Aussitzen und Verdrängen von Problemen. Da kommt dann "Was soll das? Es funktioniert doch alles." und "Spielerei von Technikfreaks" und "Es soll alles aussehen wie immer" und "Lösung sucht Problem". Das kommt sowieso, und trotzdem sollte man so weit wie möglich entgegenkommen. Mit Erklärungen, warum es geändert besser ist. Das muss aufs Argument des technischen KO (das für mich persönlich völlig hinreichender Grund wäre) noch obendrauf. MBxd1 (Diskussion) 23:23, 2. Feb. 2021 (CET)Beantworten
Ich muss dem ganz dringend beipflichten. Meine Pro-Stimmen sind auch sicher, gerade auch weil der Initiator jemand mit umfassender Kenntnis der technischen Hintergründe ist und überdies vermutlich derjenige, der einen Großteil der mit den vorgeschlagenen Änderungen verbundenen Arbeit erledigen wird. Aber wenn das MB eine Chance auf Annahme der Vorschläge haben soll, dann sollte er auf Vorschläge zur besseren Erläuterung weniger patzig reagieren. Und viele der Sachantworten auf die in der Disk gestellten Fragen sollten auch umseitig erwähnt werden. Es reicht nicht, selbst zu wissen, dass der eigene Vorschlag gut ist; man muss auch eine ausreichend breite Mehrheit davon überzeugen. Abkanzelnde und polemische Bemerkungen sind da absolut kontraproduktiv. --Yen Zotto (Diskussion) 11:03, 6. Feb. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Zitat: Dort werden seit langer Zeit immer die Koordinaten in normaler Größe an der regulären Stelle mitten im Artikel angezeigt...
Hm, sehe ich so pauschal nicht. Ganz oft gibt es Einbindungen mit {{coord|...|display=title}}, und dann werden die Koordinaten nicht an der Stelle im Artikel, sondern nur im Seitenkopf angezeigt. In dieser Form kann das auch an beliebiger Stelle im Artikel stehen, ist bloß per Konvention nicht üblich. Das ist so auch als zulässig beschrieben. In dem Fall hat die Mobilversion halt "Pech". (Off-topic: wieso ändert man nicht "einfach" die Mobilversion, sodass die Koordinate auch oben oder aber dann auch bei display=title an Ort und Stelle angezeigt wird?!)
Ich hätte es eigentlich gern, wenn man die Darstellung im Text zumindest optional ausschalten kann. Welche Gründe auch immer man dafür haben mag.
Dann ist mir noch aufgefallen, dass die Koordinaten mit display=title, also das "Duplikat" im Seitenkopf, bspw. in en rechts unterhalb des Seitentitels angezeigt werden, in anderen Sprachversionen aber auf derselben Ebene wie der Titel, also über dessen horizontaler Linie (mit vertikaler Ausrichtung oben), bspw. fr, ru, sv... Ich würde letzteres präferieren - soll/muss das auch hier im MB entschieden werden? Wäre der bisherigen Darstellung zumindest näher. --AMGA(d)23:10, 1. Feb. 2021 (CET)Beantworten
In der Tat zeigen viele WP-Sprachversionen die Koordinaten irgendwie oben rechts an, teilweise auch leserfreundlich in normaler Schriftgröße; siehe zum Beispiel fr:Cologne, ru:Кёльн. Wie zulässig, zukunftssicher und kompatibel mit der Mobilansicht sind denn die dort verwendeten Lösungen? --Yen Zotto (Diskussion) 10:51, 2. Feb. 2021 (CET)Beantworten
Ich blende mal eine Datei ein, die auch bei uns in der Technik-Werkstatt verlinkt ist. Man sieht an der Stelle unserer Koordinaten eine Auswahlbox für andere Sprachen. An dieser geplanten Änderung müssen wir uns orientieren. Klar kann ein Meinungsbild irgendwas anderes bestimmen, dann wird halt bei Einführung dieser Auswahlbox nix funktionieren – entweder wird die Auswahlbox von den Koordinaten überlagert und funktioniert nicht oder die Auswahlbox überlagert die Koordinaten und mach diese unsichtbar. --Wurgl (Diskussion) 15:01, 2. Feb. 2021 (CET)Beantworten
@ Technik-Werkstatt, Auswahlbox für andere Sprachen
Das ist für das umseitige MB relativ belanglos, weil alte Technologie (2005).
Unsere BOA müssen halt mal wieder, wie schon öfters, jetzt ran und eine freie Stelle auf dem Vector-Skin finden, wo sie unsere Altlasten reingequetscht bekommen.
Wenn sie es nicht hinbekommen, gibt es auf dem Vector-Skin halt keine Koordinaten usw. mehr. Fertig; Ende mit Durchsage.
Es ist eine unerwünschte Nutzung, wie du bereits korrekt schreibst.
Die Funktionalität von 2004 ist damit zurzeit noch erreichbar.
Die Programmierer und BOA der enWP werden dies aber eines Tages abschalten, insbesondere sobald ohnehin alles außerhalb des Inhaltsbereichs abgeschnitten wird.
Der vorgesehene Standardfall der enWP ist |display=inline,title für die einmalg zuzuweisende Seitenkoordinate. Meist geschieht das innerhalb einer Infobox; 138 Artikel weisen es außerhalb von Infoboxen usw. zu.
Um 60 % aller Lesezugriffe des enWP-ANR erfolgen mobil, in DACH sind es >40 %. In der enWP ist eine Beschränkung auf Desktopdarstellung ganz sicher nicht akzeptabel.
Es gibt momentan 14 Artikel unter 1,2 Millionen Artikeln mit Koordinaten, die manuell und ohne display=inline ein solches display=title vornehmen. Sie stehen erkennbar weitaus überwiegend in Nähe der Kategorien. Da braucht es nicht mal einen Bot, um die aufzuspüren und geeignet umzustellen. 14 statt 100.000 würd ich mir bei uns auch wünschen. Dass es theoretisch als zulässig beschrieben sein soll macht das trotzdem nicht sichtbarer.
Was genau hilft es uns bei der Lösung des umseitigen Problems, der bei uns Regelfall mit um die 400.000 Artikeln ist, dass du darauf verweist, es wäre in der enWP technisch weiterhin möglich wie 2004 zu agieren, wenngleich per „Konvention nicht üblich“ und faktisch offensichtlich äußerst selten?
Eines Tages wird die enWP mögliche unkonventionelle Fälle zumindest in ihrem ANR per Wartungskat aufspüren, und fehlplatzierte zurzeit unsichtbare Einbindungen notfalls mittels Bot-Einsatz an das Ende der Artikel verschieben, und die historische Option title und damit den kompletten Parameter display= aus der Programmierung entfernen. Genau das was umseitig ansteht. Inwieweit bringt uns hier diese absehbare Anpassung der enWP weiter?
en:WP:ORDER schreibt die Platzierung ganz am Ende der Seite explizit vor; bei uns heißt es: Is wuascht wo, wir zaubern das sowieso nach rechts oben.
@ wieso ändert man nicht "einfach" die Mobilversion
Weil Mobilgeräte einen kleineren, ggf. sehr viel kleineren Bildschirm haben als ein Desktop-Browserfenster.
Da passt einfach nicht soviel in die Benutzeroberfläche.
Die MediaWiki-Designer haben vier, womöglich fünf Icons üblicher Größe vorgesehen. Wenn der Artikel gleichzeitig Gesprochen und Exzellent ist, dann passt da noch ein Icon auf den Kartendienst und vom Breitengrad die Ziffern 54,3 hin. Der Längengrad wird nicht verraten.
@ Ich hätte es eigentlich gern, wenn man die Darstellung im Text zumindest optional ausschalten kann
Dann kannst du gleich einen HTML-Kommentar verwenden, weil langfristig wird es ohnehin niemand sehen können.
@ rechts unterhalb des Seitentitels
Das ist Skin-abhängig und kommt drauf an, was einzelne Sprachversionen sonst noch so in ihrer Gestaltung vorgesehen haben.
Es liegt jedoch alles außerhalb des erlaubten Inhaltsbereichs und kann perspektivisch sowieso keine Inhalte mehr darstellen.
@ viele WP-Sprachversionen
Das sind alles mehr oder weniger glückliche Kopien der enWP-Ideen von 2004.
Wohl schon seit über einem Jahrzehnt ist die enWP jedoch dazu übergegangen, fast alle Vorlageneinbindungen immer auch genau dort anzuzeigen, wo sie eingebunden sind.
Wenn MediaWiki Freitag mittag ankündigt, ab nächstem Donnerstag würde der Inhaltsbereich abgeschnitten, um das Interface zu schützen, dann kann die enWP Freitag abend sämtliche Seiten korrigiert haben, die aus dem Inhaltsbereich rausgreifen, und die Reste der Programmierung von 2004 eliminiert haben.
In enWP ist die Anzeige im Interface Modell „2004“ nur noch folkloristische Remineszenz. So lange das funktioniert und keinen Ärger macht, lässt man es weiterlaufen; wenn es in irgendwelchen Skins stören sollte, kommt es halt weg. Die enWP juckt das nicht. Übrigens sind unter den beteiligten MediaWiki-Entwicklern auch diverse langjährige enWP-Programmierer zugange, die wissen seit langer Zeit sehr genau was da läuft.
@ Wie zulässig, zukunftssicher und kompatibel mit der Mobilansicht sind denn die dort verwendeten Lösungen?
Nullkommanull, absolut chancenlos, weder heute noch zukünftig gibt es dort oben im Mobil-Browser irgendwas zu sehen.
Es gibt nicht nur die HTML-Browser auf Mobilgerät, sondern auch die Mobile App. Das ist kein Browser, sondern dort wird der Inhaltsbereich als Frame in eine Anwendungsumgebung eingebunden; auch hier ist es definitiv ausgeschlossen, dass irgendwas aus dem Inhaltsbereich herauswirken kann.
m.ru:Кёльн zeigt genau wie die enWP das Original in der Infobox, unterhalb von Flagge und Wappen, und nur ein Duplikat im Seitenkopf. Damit haben die uns was voraus. Ob die das genauso konsequent durchhalten wie die enWP weiß ich nicht und habe auch keinen Nerv, es herauszufinden, weil es für uns nicht zielführend ist.
Hm, "14 Artikel unter 1,2 Millionen Artikeln" - stimmt nicht. Entweder Script/Abfrage oder Datengrundlage (Dump?) sind buggy oder unvollständig. Schon beim ersten Artikel, den ich fast wahllos herausgegriffen habe (gleich "neben" dem "0-km-Stein"), nämlich en:Buda, ist das genauso, und der ist nicht in der Liste der 14. --AMGA(d)21:05, 2. Feb. 2021 (CET)Beantworten
Keine Ahnung, warum mein Cirrus-Suchausdruck dein Buda nicht fand, aber die enWP hätte sowas in allerkürzester Zeit per Wartungskat und Botlauf identifiziert, alle Vorlagen nach ganz unten verschoben und den display-Parameter abgeschafft, fertig.
Es löst jedoch unsere Schwierigkeiten nicht, wenn du darüber rasonnierst, ob die enWP eine oder sieben Stunden bräuchte, um alle Altlasten zu beseitigen und display und title zu eliminieren.
Jedenfalls ist en:Buda auch nicht im Interesse der enWP, weil dieser Artikel auf Mobilgeräten zurzeit keine Koordinaten liefert. Derartige Verwendungen der Koordinatenvorlage sind wohl eher private Ausrutscher und noch Altlasten und überholte Methoden vor der Mobilfunkzeit. Nach Buda kamen sie Ende 2010, die Smartphone-Strategien hatten erst um 2012 begonnen. Also müsste man dort mal einen Botlauf zur Aufarbeitung dieser Altlasten starten.
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Es soll Leute geben, die sich in Projekten bzw. in Teams engagieren, ohne alles, was dazugehört, in vollem Umfang verstanden zu haben. Als jemand, der im Geo-Bereich nicht federführend, aber an diversen Stellen immer wieder mal mitarbeitet und vom Coden oder [richtigen fachchinesischen Begriff hier denken] aber so gut wie keine Ahnung hat, fühl ich mich von der Hochmütigkeit des Initiators hier gelinde gesagt sehr massiv auf den Schlips getreten. Das ich (und wie ich vermutlich einige andere) hier keine "realisierbare Gesamtkonzeption" aus dem Ärmel geschüttelt habe(n), liegt nicht in meiner grenzenlosen Bösheit, sondern in meiner grenzenlosen Fehlbesetzung für solche Aufgaben.
Andere haben von arabischer Schrift keinen wirklichen Schimmer und maßen sich deswegen nicht an, da groß herumzupfuschen, da ihnen klar ist, dass die Gefahr, Fehler einzustreuen, realistisch ist. Andere streuen diese Fehler bei ihren realisierten Gesamtkonzepten ein. Ist halt so. Ich sag das lieber einmal und bau damit Druck ab, als dass ich mich wochenlang über das Gewese ärgere. Irgendwann sollten wir halt aus der Frustrationsspirale, dass die anderen einen nicht verstehen wollen, wieder rauskommen. … «« Man77 »»Alle Angaben ohne Gewehr.00:08, 4. Feb. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren12 Kommentare6 Personen sind an der Diskussion beteiligt
ich werde kein eigenes Meinungsbild erstellen. Aber folgende Gedanken habe ich gesammelt wie man es ganz anders formulieren könnte:
Hintergrund: Es gibt in vielen Artikeln oben rechts Koordinaten. Wenn man die anklickt, kommt man zu Karten. Die Technik dahinter wird demnächst (1 bis 2 Jahre) deaktiviert.
Status Quo: knapp 50 Prozent (Tendenz steigend) der Leser sehen diese schon jetzt nicht. Weil sie über Tablet, Handys oder andere Geräte auf die sogenannte Mobile Seite zugreifen.
Vorschlag 1: Die Koordinaten an eine neu Stelle setzen, damit sie in Zukunft überall dauerhaft sichtbar sind.
Vorschlag 2: Zusätzlich ein neues ICON oben. Mit Klick darauf, springt der sichtbare Teil an die Stelle, wo die Koordinaten sind.
Bei Ablehnung wird es in Zukunft dann keine Koordinaten mehr geben.
Das ist alles nachvollziehbar. Aber es ist nicht schlüssig erklärt, wieso man in der Desktop-Version die Koordinaten nicht *trotzdem* rechts oben anzeigen kann (dann halt im "zulässigen Bereich", und von mir aus von der definierten "neuen" Stelle "dupliziert"). Über Icon irgendwo hinspringen wtf? "Warum einfach, wenn es auch kompliziert geht?" --AMGA(d)12:20, 5. Feb. 2021 (CET)Beantworten
Es geht nur entweder-oder. Entweder die Koordinaten unten in einer Leiste anzeigen, dann können die Coordinate-Vorlagen im Quelltext dort bleiben, wo sie sind. Oder die Koordinaten oben rechts anzeigen, dann müssen alle Vorlagen im Artikelquelltext nach oben. Hat beides seine Vor- und Nachteile. -- hgzh13:34, 6. Feb. 2021 (CET)Beantworten
nein, das verstehe ich völlig anders. Es gibt momentan Artikel, die die Koordinate über die Infobox Ort haben. Da steht momentan nirgends eine extra Vorlage. Weder oben noch unten. --Steffen2 (Diskussion) 15:27, 6. Feb. 2021 (CET)Beantworten
Die Coordinate-Vorlagen müssen so oder so angefasst werden, weil sie im aktuellen Zustand überall stehen können. Ob das dann ganz am Anfang oder ganz am Ende ist, ändert nicht viel. Ganz oben wird das momentan auf einigen Funktionsseiten ja schon mit der Vorlage:Shortcut probiert (die im Normalfall genau wie die Koordinaten ein Ergebnis im Außenbereich erzeugt), aber in Kategorie:Wikipedia:Schnelllöschen sieht man, was das wieder für Probleme gibt, wenn Hinweiskästen am Anfang stehen (mit Infoboxen geht das auch nicht immer gut zusammen). Ungefährlicher ist die Anzeige sicher unten.
Das heißt, man kann über Infoboxen auch Inhalte am Ende des Artikels im Inhaltsbereich erzeugen? Warum machen wir das dann nicht SOFORT für mobil? Dazu benötigt es keinerlei Diskussion --Steffen2 (Diskussion) 16:43, 6. Feb. 2021 (CET)Beantworten
Genau das funktioniert eben nicht, deswegen mein entweder-oder oben. Eine Vorlage kann normalerweise nur am Einbindungsort Inhalte ausgeben; die fast einzige Möglichkeit, Vorlageninhalt anderswo darzustellen, ist der derzeitige Mechanismus. Die Koordinaten-Infoboxen sind nochmal ein ganz anderes Problem und ich vermute dort die eigentlichen Schwierigkeiten einer Umstellung, denn wahrscheinlich werden Koordinaten in Infoboxen nicht mehr ohne Weiteres auch als allgemeine Artikelkoordinaten angezeigt werden können. -- hgzh17:47, 6. Feb. 2021 (CET)Beantworten
(BK) Nein. Über Infoboxen kann man lediglich eine Anzeige innerhalb oder in unmittelbarer Nähe derselben erzeugen. Denkbar wäre etwas wie Hilfe:Vorlagen (man denke sich Koordinaten statt des Shortcuts). Damit hängen sie dann aber starr an der Infobox, was in der Mobilversion durch die automatische Verschiebung oder gar Ausblendung (App) der Infobox unschöne Nebeneffekte haben könnte. Die Musterlösung in Infoboxen müsste daher wohl eine Anzeige innerhalb sein. Aber wie gesagt, das bedarf keiner Umstellungen im Artikelquelltext. –XanonymusX (Diskussion) 17:50, 6. Feb. 2021 (CET)Beantworten
Infoboxeinträge können doch auch Kategorieeinträge erzeugen, die dann im Quelltext nicht gesondert sichtbar sind. Ansonsten bliebe, insbesondere wenn wir die Koordinaten am Artikelende haben wollen, noch die rustikale Methode, sie an beiden Stellen einzufügen, d. h. in der Infobox und mit Standardvorlage am Artikelende. MBxd1 (Diskussion) 19:45, 6. Feb. 2021 (CET)Beantworten
Kategorien sind eine eingebaute Funktionalität von MediaWiki, damit lässt sich das nicht vergleichen. Doppelte Einfügung wäre möglich, ja, erschwert halt die Wartung.–XanonymusX (Diskussion) 20:01, 7. Feb. 2021 (CET)Beantworten
@ Infobox: Da wo bereits eine Infobox die Informationen anzeigt, ist alles wunderbar.
Es braucht dann weder ganz unten bei den Navileisten eine zusätzliche Box, noch unmittelbar über der Infobox die gleiche Information, die schon fünf Zentimeter tiefer in der Infobox drinsteht.
Das einzige Problem, das ein Besucher eines ihn fremden Artikels hat: Gibt es denn Seiten-Koordinaten dazu? Wenn ja: Wo stehen die? In der Infobox? Unten bei den Navileisten? Irgendwo bei einer Lagekarte mitten im Artikel? Diese Hilfestellung soll der Icon beim Zusatz-Vorschlag leisten, indem an genau diese Stelle gesprungen werden kann.
@ Inhalte woanders darstellen: Alle Vorlagen-Inhalte müssen immer an der Stelle angezeigt werden, wo sie definiert sind. Die Zauberkunststückchen, die Vorlage ohne sichtbare Wirkung irgendwo einzubinden und darauf zu hoffen dass diese Inhalte dann irgendwo anders aufpoppen sind alle miteinander des Teufels.
Letzter Kommentar: vor 3 Jahren9 Kommentare5 Personen sind an der Diskussion beteiligt
Ich habe mal ein bisschen gekürzt, aber mir scheint, da ginge noch mehr (sprich: weniger). Je länger sich jemand in ein MB einlesen muss, desto geringer ist die Chance, dass er/sie sich ernsthaft Gedanken zum Thema macht, ist leider so. Vielleicht ließen sich Teile noch in Fußnoten auslagern, informativ sind sie ja durchaus. Grundsätzlich unterstütze ich das MB so, die Abstimmungsmodalitäten gefallen mir aber noch nicht ganz: Status Quo und Vorschlag 1 sind doch gegenseitig exklusiv, oder nicht? Entsprechend müsste die inhaltliche Abstimmung mE zweiteilig sein: 1) Vorschlag 1 – Status Quo – Enthaltung; 2) Vorschlag 2, Pro – Contra – Enthaltung (natürlich nur relevant, wenn V1 angenommen wird). Gruß–XanonymusX (Diskussion) 17:27, 5. Feb. 2021 (CET)Beantworten
Ich hatte mir Ende Januar auch längere Zeit Gedanken gemacht, wie das für wenig Involvierte angemessen dargestellt werden kann.
Lässt man zu viel weg, dann wird es sachlich inkonsistent, ist nicht mehr schlüssig, nicht mehr nachvollziehbar.
Wird zu viel geschrieben, dann ist es zu lang.
Ich habe bewusst sämtliche technischen Einzelheiten wie CSS-Code, Erwähnung einzelner Vorlagen oder Site-CSS außen vor gelassen.
Die bald zwei Jahrzehnte bis ins Krabbelalter der Wikipedien zurückreichende Geschichte ist jedoch erforderlich, um zu verstehen, wie die jetzige Situation überhaupt entstanden war.
Das war damals schon klar gewesen („Wer weiterhin solchen Spielkram“) und man hätte diesen Irrweg schon ein, zwei Jahre nach Übernahme aus der enWP wieder beenden sollen, und langjährig in sinnvolle Bahnen lenken müssen. Man ließ es jedoch fünfzehn Jahre untätig laufen; und ich schreibe mir seit fünf Jahren die Finger wund und dagegen an.
Weiter oben hatte jemand ein Ultrakurz-MB vorgeschlagen; ohne alle Erläuterungen. Das würde mit Sicherheit mangels konkreter Darstellung abgelehnt werden.
Formale Reihenfolge Status Quo / Vorschläge:
Ich sehe in der Formatvorlage hierfür kein starres Schema.
Ich kenne nur den Einwand, der Status Quo wäre nicht dargestellt worden, oder es würde keine Abstimmungsmöglichkeit für den Status Quo geben.
Es ist einigermaßen logisch, dass jemand, der für die Beibehaltung des Status Quo stimmt, nicht gleichzeitig einem Vorschlag zustimmen kann, dass der Status Quo verändert werden soll.
Ich habe jetzt erstmal die Überschriftenstruktur gestaffelt und die Auswertung ergänzt.
Ich brauch diesen Status Quo nicht, inhaltlich nicht und nicht im MB-Schema.
So wie es jetzt ist, mit separatem Status quo, bekommst Du Probleme mit der Auswertung - oder auch schon bei der Stimmabgabe. Wenn Du vorschreibst, dass jemand, der schon ganz am Anfang für den Status quo gestimmt hat, bei den Vorschlägen nicht noch mal abstimmen darf, ist das zwar rein logisch gesehen richtig, es wird aber trotzdem formale Kontras hageln. Bei der Auswertung müsstest Du die Kontras bei Vorschlag 1 und 2 jeweils bei den gültigen Stimmen und den Kontras hinzuzählen. Rechnerisch richtig, aber der durchschnittliche Wikipedianer kapiert es nicht oder wittert überall Betrug oder beides. Dieser separate Status quo ist nicht nötig, und das theoretische Ergebnis, wenn nur Vorschlag 2 angenommen wird (die offene Koordinatenanzeige verschwindet komplett - aber wohin verlinkt dann das Icon?) kann man auch ignorieren. Es war schon mal besser: Vorschlag 1, Kontra ist dann Status quo; und Vorschlag 2 wird nur ausgewertet, wenn Vorschlag 1 angenommen wird. MBxd1 (Diskussion) 17:44, 7. Feb. 2021 (CET)Beantworten
Nun gut, dann nehme ich diesen dussligen Status Quo jetzt komplett raus.
Ich hatte ihn nur eingefügt, weil ich mich an formale Beschwerden erinnern kann, man könne nicht für den Status Quo abstimmen und deshalb wäre das MB komplett abzulehnen.
Wenn das dann trotzdem aufkäme, werde ich alles auf dich umlenken.
… als ich über das MB stolperte war, dass berechtigte Hoffnung für ein Verschwinden dieser mich schon seit weit über einem Jahrzehnt nervende Koordinatenanzeige und insbesondere ggf angezeigter Links zu Geohack- und Karteneinblendungen aus der aktuellen Position besteht. Ich habe sie noch so gut wie nie genutzt, bin aber durch Verklicken schon viele Dutzende Male ungewollt dort gelandet. Der Hintergrund ist der, dass ich die sehr hilfreiche [Bearbeiten]-Schalteroption für die Einleitung aktiviert habe und leider aus augenoptischen Gründen darauf angewiesen bin, die Bildschirmlupe mit mindestens 110, oft sogar mit 120 Prozent zu nutzen. Dies führt jedoch dazu, dass sich die Koordinatenanzeige und der [Bearbeiten]-Schalter gegenseitig berühren und sich ggf vorhandene Geohack- und Karteneinblendungs-Icons sogar in den Schalter hinein schieben, was zur Millimeterarbeit mit dem Mauszeiger zwingt um auch tatsächlich die Bearbeiten-Funktion und nix anderes zu aktivieren. Im Eifer des Gefechts oder bei leichtem Verzittern mit der Hand bin ich trotzdem wie schon erwähnt, dutzende Male dort gelandet, wo ich gar nicht hin wollte. Wenn das MB also Aussichten hat, hier Abhilfe zu schaffen, unterstütze ich es gerne. Allerdings kann ich mich da wohl nicht als Unterstützer eintragen, da ich von den formellen Dingen bei Meinungsbildern, genauso wie von den hier speziell beschrieben technischen Hintergründen nicht die geringste Ahnung habe und somit auch nix hilfreiches unterstützend beisteuern kann.--Ciao • Bestoernesto • ✉20:57, 14. Feb. 2021 (CET)Beantworten
@Bestoernesto: Du kannst insofern dazu beitragen, dass du dich als Unterstützer einträgst. Denn nur wenn genug eingetragen sind, geht es weiter. Dein Problem löst sich also schneller, wenn du dich dazu schreibst. Damit unterstützt du, dass das Meinungsbild starten kann. --Steffen2 (Diskussion) 09:13, 15. Feb. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren13 Kommentare6 Personen sind an der Diskussion beteiligt
Mit der umseitig spezifizierten Technik zur Umsetzung, den mw:Help:Page status indicators, müssen wir uns nicht auf ein Icon beschränken, das dann nur einen Link nach unten enthält. Auch Textschnipsel in Form der Koordinaten mit Link auf den Geohack (mit oder ohne Icon) sind möglich. Ganz simples Beispiel ohne Verwendung von Vorlagen: Köler Dom im Betawiki. Ich glaube, diese Lösung würde nur die Anpassung von unseren Vorlagen und Infoboxen bedeuten, aber keinen Botlauf.
Man müsste das ganze mal im Betawiki ausprobieren, wenn man mehrere Icons und die ausgeschriebenen Koordinaten so platziert.
An einen Direktlink im Icon hatte ich auch schon gedacht. Es sollte aus technischer Sicht eigentlich egal sein, ob man ans Seitenende oder direkt zu Geohack springt. Eine Option wäre das aber nur, wenn man das Icon zusätzlich anbringt. Ansonsten würden die Zahlenwerte der Koordinaten fehlen (die man auf Geohack allerdings bekommt) und die Karteneinblendungsoptionen wären weg (zu denen die Nutzerschaft allerdings nie gefragt wurde, ob sie die überhaupt haben will, die wurden einfach so eingebaut). MBxd1 (Diskussion) 10:09, 7. Feb. 2021 (CET)Beantworten
@ Raymond: Yep, es ist als die polnische Zwischen-„Lösung“ bekannt.
Scheitert an absehbarer Begrenzung der Breite auf vier oder fünf Icons, weshalb bei einem Lesenswerten Gesprochenen dann nur noch was wie Koordina zu lesen bleibt.
Nebenbei: Die MW-Seite ist im Wesentlichen von 2014, geistig noch vor Verdauung der Smartphone-Ära, und zielt bislang nur auf Desktop ab; der Screenshot ist enWP-Desktop mit konventioneller 2004er Koordinatendarstellung der enWP und einem Indicator-Bereich und dessen willkürlich angenommener Begrenzung auf einem Desktop.
Siehe momentan auch mobil und in die Leiste mit derzeit vier Icons müssen auf einem schmalen Mobil-Bildschirm (irgendwann auch als Armbanduhr) alle Icons hineinpassen, insgesamt perspektivisch etwa zehn zusammen mit unseren.
Für Bern steht dort: Koordinaten: 46° 56′ 53″ N, 7° 26′ 51″ O; CH1903: 600670 / 199655 | OSM und ein Lesenswert.
@XanonymusX: was sagt denn dein gefürchtetes Mini-Telefon dazu?
Nur eine Webseite zu verlinken, die enzyklopädische Information in unserem Artikel nicht zu erwähnen und wer wenigstens ungefähr Längen- und Breitengrad wissen will müsse dann erst eine fremde Website aufrufen – das ist sicher nicht akzeptabel.
@XanonymusX: Was ich eigentlich wissen wollte: Wenn du eine Minerva-Skin mit der einzeiligen Leiste von vier Icons (der momentan designierte Platz für die Indikatoren-Icons) nimmst und auf deinem Mini-Phone anzeigen lässt und dort in normal lesbarer Schriftgröße die Schweizer Koordinaten vorstellst, abmisst oder per HTML-Dokument-Edit sogar physisch einkopierst – wie viel von dieser enzyklopädischen Information kommt dann an? Und wenn da noch zwei andere Icons davor stehen? VG --PerfektesChaos17:44, 8. Feb. 2021 (CET)Beantworten
Schmale Bildschirme: Es scheitert eher am Skin-Design als am Platz (hab auch extra den neuen Vector probiert). Der Indikator-Bereich lässt sich munter zusammenschieben und nimmt dann einfach mehrere Zeilen ein, aber dank der Reiter ist wohl ungefähr um 450px Schluss, dann würde das Bild rechts rausragen. Immerhin wird nix abgeschnitten. Na ja, Minerva wäre dafür sicher geeigneter, hat halt leider noch überhaupt keinen Indikator-Bereich.–XanonymusX (Diskussion) 20:10, 7. Feb. 2021 (CET)Beantworten
Service, weil schon wieder weg. (Artikel-)Koordinaten sind für alle lokalisierbaren Objekte, also einen großen Teil der Artikel, essentiell. Viel wichtiger als der ganze andere Kram, der da angezeigt wird (oder werden soll). Wenn der "Kram" auch für wichtig gehalten wird - warum dann nicht *zwei* Bereiche, einen extra für Koordinaten? (+ Desktop- und andere Versionen unterschiedlich rendern. Warum soll die Desktopversion unter Problemen der Mobil- und/oder Appversion leiden? Was kommt als nächstes? Kategorien können in der Desktopversion nicht mehr angezeigt werden?) --AMGA(d)09:06, 8. Feb. 2021 (CET)Beantworten
@PC: Wie akut soll denn "Perspektivisch könnte der zur Darstellung innerhalb des Portalrahmens zulässige Bereich seiner Höhe und Breite nach begrenzt werden" sein? Aktuell liest sich das für mich wie eine Hypothese. Eine Notwendigkeit für die Begrenzung sehe ich für den Desktop nämlich nicht. Meine Testseite habe ich nun auf 9 Icons und 2 lange Koordinatenschreibweisen ausgedehnt. Das passt und auch bei schmalen Bildschirmen bricht das ordentlich um. Dass für die mobile Darstellung eine Lösung gefunden werden muss, steht außer Frage, und da gebe ich meinem Vorredner Amga recht: Die Desktop-Anzeige sollte darunter nicht leiden. Ich persönlich brauche die Koordinaten oben rechts sehr häufig und fände es umständlich, wenn sie unten stehen würden. Ob das mehrheitsfähig ist, weiß ich natürlich nicht. — RaymondDisk.09:29, 8. Feb. 2021 (CET)Beantworten
Wir sollten die früheren Experimente [1] und [2] auch miteinbeziehen. Damals gab es natürlich den neuen Vector nicht, an dem wir uns wohl hauptsächlich orientieren sollten. Ich muss damit selbst erst noch ein bisschen experimentieren.
Warum nicht zwei Indikator-Bereiche? Nun ja, das muss man die Entwickler fragen, liegt nicht an uns. Ist aber immer auch ein Problem der Mobilgeräte: Wenn man dort beim Aufrufen einer Seite nur den Indikator-Bereich zu Gesicht bekäme und für den eigentlichen Inhalt erst einmal scrollen muss, widerspricht das sämtlichen Usability-Konzepten des Mobile Web. Ob der Bereich tatsächlich grundsätzlich begrenzt werden wird, keine Ahnung, aber mobil bleibt er ansonsten auf alle Fälle problematisch. Was mich angeht, sperre ich mich sicher nicht gegen das Ausweichen auf den Indikator-Bereich, Hauptsache weg mit der absoluten Positionierung.—XanonymusX (Diskussion) 13:18, 8. Feb. 2021 (CET)Beantworten
Etwa 40–50 % der ANR-Lesezugriffe in DACH und analog etwa 50–60 % in der enWP erfolgen heute mobil. Tendenz leicht steigend.
Eine „Lösung“, die nur die Desktop-Gewohnheiten von 2005 verewigen will ist nicht zukunftsfähig.
Die Mobilbenutzer bleiben bei dem Ersatz der einen wilden Bastelei durch eine andere den Zweck missbrauchende Bastelei dauerhaft außen vor. Auf Mobilgeräten ist grundsätzlich kein Platz, um in der Benutzeroberfläche Inhalte anzuzeigen, die in den Inhaltsbereich gehören.
Die Entwickler werden auch definitiv nicht mitspielen, für die zukunftsfähige Weiterentwicklung der Bedienoberflächen auf ewig Rücksicht auf ein paar obsolete Spielereien in einer Handvoll Wikis zu nehmen, die Sachen gemacht hatten, welche man von vornherein niemals hätte tun dürfen.
Es ist ein Zugeständnis, das seit 2014 zur Lösung ansteht, dass zumindest einige inhaltsdefinierte Icons in das mobile Menü aufgenommen werden sollen. Das wird aber mit ziemlicher Sicherheit begrenzt werden, und dann erfahren die Mobilbenutzer immer noch keinen Längengrad.
Die Mobile-App wird jedoch auch keine Indikatoren anzeigen, so der momentan robust überschaubare Entwicklungsplan. Sie ist gar kein HTML-Browser mehr und blendet sehr rigide nur den HTML-Inhaltsbereich ein und ihre Benutzeroberfläche ist nicht in HTML aufgebaut. Das ist Orientierungspunkt für die Entwicklung.
Die Begrenzung des Indikatorbereichs steht in der Pipeline, womöglich gibt es sogar schon ein nicht reviewtes Patch dafür. Mittelfristig ist damit zu rechnen, schon um des Schutzes der Benutzeroberfläche vor Edit-Unfällen und Vandalismus willen. Erwähnt und eingefordert wurde sie schon vor vielen Jahren.
Und berühmt sieht das Desktop-Design mit missbrauchtem Indikatorfeld ja nicht grad aus, vor allem wenn das Bildschirmfenster noch etwas schmaler gezogen wird:
Modern (suche den Seitennamen, oder denke einen etwas längeren) – Modern hat eine Beschränkung der Höhe des Indikatorbereichs und schneidet Überstehendes bereits ab.
Power-User können gern ein JavaScript-Gadget aktivieren, das ihnen auf Desktop-Oberflächen eine Kopie der Koordinaten aus dem Inhaltsbereich sonstwohin beamt.
Zukünftige Mobil-Oberflächen müssen auch keine Icon-Leiste wie zurzeit in MinervaNeue mehr verwenden, sondern bieten vielleicht ein Ausklapp-Menü an; auch dort wird nicht viel von ausufernden Inhalten zu sehen sein.
Je eher man sich geistig mal von den Gewohnheiten von 2005 und den seinerzeitigen Basteleien löst, desto robuster und sicherer wird unsere Zukunft werden, statt sich dann urplötzlich immer wieder vor plötzlichen Ankündigungen wiederzufinden. Eine Vorlage hat ihre Inhalte an genau derselben Stelle wiederzugeben an der sie eingebunden ist, und sich nicht auf irgendwelche Zaubertricks und Wunderheilungen zu verlassen, dass die Inhalte schon irgendwie irgendwo anders auftauchen werden. Das zu missachten war ein Urfehler der Spielkinder im Krabbelalter der Wikipedien.
Zu oben: Die Frage/Anweisungen habe ich nicht verstanden. In Minerva habe ich keinen Indikator-Bereich; wenn ich mir den von Vektor im HTML rüberkopiere (unter die Werzeuge), kommt alles durcheinander, da die Styles wohl irgendwo anders definiert sind und nichts mehr zusammenpasst. Auf dem Mobilgerät kann ich das (zumindest in Safari) sowieso nicht testen, da werden mir die Nicht-Minerva-Seitendarstellungen alle winzig klein ins Vollbild rausgezoomt.
Ich schätze, die Icons zu Artikelauszeichnungen könnten mobil sowieso direkt aus Wikidata generiert werden, dazu braucht es die Indikatoren gar nicht. Speziell in der App dürfte das der naheliegendere Weg sein. Andere Icons sind in der Gesamtschau deutlich seltener (oder weniger wichtig). Von daher würde ich in der Tat nicht zu viel Hoffnung auf den Indikator-Bereich setzen.–XanonymusX (Diskussion) 18:27, 8. Feb. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren5 Kommentare5 Personen sind an der Diskussion beteiligt
Für mich als in diesen Dingen "dummen" Anwender wäre es hilfreich zu wissen, welche Vorlagen primär betroffen wären. Ich vermute zwar, dass es um alle Koordinatenvorlagen geht, aber das ist nicht ganz klar.
Und ein Nebengedanke: {{All Coordinates}} wird im Kategorien-NR umfangreich eingesetzt (>200.000 Einbindungen); auch dort dürfte es wohl dieselbe Problematik geben? Falls ja, wäre es gut, wenn das umseitig auch auftauchen würde. --jergen?18:21, 8. Feb. 2021 (CET)Beantworten
Als Autor ist das erstmal irrelevant, sofern keine Entscheidung durch das MB vorliegt.
Du könntest allerdings im Rahmen ohnehin erfolgender Bearbeitungen darauf achten, dass die Seiten-Koordinate unmittelbar vor allfälligen Navileisten usw. eingebunden ist.
Der MB-Text ist bereits massiv mit Technik-Kram belastet und sehr umfangreich; damit das überhaupt noch für Normalbenutzer zumutbar bleibt hatte ich umseitig ganz bewusst auf für die Entscheidungsfindung überflüssige Detailfragen verzichtet.
Umseitig wurde eine Größenordnung von 100.000 benannt (ANR). Außerhalb des ANR ist erstmal nachrangig; notfalls machen Bots auch Kats klar, aber die werden von kaum jemandem beobachtet, und haben auch keine komplizierte Versionsgeschichte.
Ich habe bereits an die hundert Arbeitsstunden in diese Problematik investiert und werde keinerlei vermeidbare Aktivitäten entfalten, solange das MB nicht entschieden ist.
Da ich mich bereits seit über fünf Jahren mit der Thematik befasse, habe ich ziemlich konkrete Vorstellungen davon was wie wo umzusetzen sein wird.
Unten skizziere ich meinen groben Aktionsplan, wobei sich aber immer noch an irgendeiner Ecke irgendwelche Überraschungen ergeben könnten. Diese werden aber lösbar sein.
Grundsätzlich sind über die VWS schon ganz andere Migrationsprozesse organisiert worden; hier sind etwas viele Seiten betroffen und Bot-Läufe erforderlich, aber eigentlich normale handwerkliche Routine des VWS-Personals. Sollte ruckelfrei abgewickelt werden können.
Es gibt etwa 48.000 ANR-Einbindungen (ohne |section=, die sichtbar anzeigen und nicht betroffen sind), von denen die große Mehrheit bereits an der richtigen Stelle eingebunden ist.
Bei vielleicht 10.000 müsste aus Gründen der inhaltlichen Logik von hinter den Navileisten nach vor den Navileisten umgetopft werden; ein paar Dutzend werden sich sicher an den unmöglichsten Stellen auffischen lassen. Klärt dann die Dump-Analyse.
Bekäme zu Testzwecken, jedoch nicht im ANR, einen temporären Migrationsschalter.
Es gibt momentan 227.873 Einbindungen von Vorlage:Coordinate ohne |text= und das zeigt das Maximum möglicher anzufassender Artikel.
Ein großer Teil ist in dieser Form bereits an der richtigen Stelle eingebunden.
Ich habe deshalb pauschal mit der knappen Hälfte abgeschätzt, also umseitig eine Größenordnung von 100.000 angegeben.
Ob das am Ende des Tages, genauer des Bot-Lauf-Monats, 87.654 oder 123.456 Artikel gewesen sein würden weiß ich nicht; es ist jedoch für das MB völlig egal, wie die IP bereits richtig angemerkt hatte.
Weil zu unterscheiden ist zwischen Einbindungen mit und ohne |text= und deren Verhältnis zu anderen Elementen im unteren Bereich der Seite, versagen meine Cirrus-RegExp und ich kann keine genaueren Zahlen benennen – sonst hätte ich das bereits getan.
Nach Erkenntnisgewinn aus Vorlage:All Coordinates per Bot-Lauf und späterer Dump-Nachkontrolle zu vereinheitlichen.
Bis auf 256 Artikel werden alle Einbindungen in einer Infobox dargestellt.
Alle anderen scheinen jedoch eine Tabelle im Stil einer selbstgebauten Infobox zu enthalten.
Möglicherweise wäre dies ein Anlass, dort ebenfalls die vorhandenen Infoboxen zu verwenden oder aber neue Infoboxen zu erstellen, die diese Typen astronomischer Objekte abbilden können.
Wenn es offenbar zu allen betroffenen Artikeln eine Infobox oder vergleichbar gibt, die jede Menge physikalischer und geometrischer Daten auflistet, dann ist es eigentlich sinnfrei, immer noch zusätzlich zur übersichtlichen Tabelle in der Infobox nochmals irgendwo in der Bedienoberfläche duplizierte inhaltliche Verlinkungen einzubauen.
Wenn es ohnehin zu jedem astronomischen Objekt eine Infobox gibt, in der die Koordinaten nachgelesen werden können, dann ist auch ein Icon gemäß Vorschlag 2 überflüssig. Dann wiederum muss man sich keinen Kopf machen, ob ein Stern mit der Beobachtungsliste oder Sonne bzw. Halbmond mit dem Nachtmodus verwechselt werden könnten oder eine Kombination aus Halbmond und Stern eine türkische Darstellung nahelegt.
Ist nach Entscheidung über das MB mit den Astros zu klären.
Vorlagenprogrammierung
Infoboxen
Es soll 255 Infoboxen geben, die Koordinaten empfangen.
Nicht alle davon stellen zurzeit die Koordinaten in der Infobox dar, aber die meisten.
Die 255 Infoboxen wären durch VWS-Personal einzeln händisch entsprechend umzukonfigurieren; dabei gleich diverse andere technische Details zu checken und ggf. zu justieren.
Info: Im Frühjahr 2017 hatte ich mutterseelenallein über 700 Infoboxen mit TemplateData-Dokumentationen ausgerüstet und technische Details bereinigt; sowas ist machbar.
Müsste teils temporär, teils permanent neue boolesche Steuerparameter für den Migrationsprozess und die Darstellungsform erhalten.
Eine Wartungskat ist zur Steuerung der Migration zu setzen, bis der Prozess abgeschlossen ist.
Neue Vorlagen – ich plane:
Vorlage:SeitenKoordinate
Gemäß umseitig Vorschlag 2, sofern gewünscht.
Fordert Indikator an und definiert gleichzeitig das zugehörige Sprungziel.
Weitaus überwiegend nur in anderen Vorlagen auftretend, etwa Infobox oder Hinweisbaustein.
Könnte aber auch direkt irgendwo mitten im Artikel benutzt werden, etwa weil eine Landkartengrafik von Lampukistan in den Grenzen von 1397 angezeigt werden soll und zum Vergleich die gleiche Region auf modernen Karten angeboten wird.
Vorlage:CoordinatePage
Identisch Vorlage:Coordinate ausgenommen |text= und bewirkt Hinweisbaustein mit Inhalt und SeitenKoordinate.
Vereinfacht Bot-Läufe und Cirrus-Suche, würde vom Bot im Fall einer notwendigen Artikelveränderung anstelle von Vorlage:Coordinate gesetzt und wäre zukünftig Mittel der Wahl.
Legt explizit einen einzelnen Punkt als Seiten-Koordinate fest.
Perspektivisch sollte eine WL es auch tun.
Vorlage:Hinweis Seiten-Koordinate
Gestaltet sichtbaren Hinweis-Rahmen um einzelne Koordinate oder aber Koordinaten-Wolke, bekommt die dafür notwendigen Inhalte von Vorlage:Coordinate oder Vorlage:All Coordinates und setzt den einheitlichen Dekorations-Icon.
Projektseiten und Portale
Die Seitengestaltung ist äußerst unterschiedlich, und es ist kein einheitliches zentrales Vorgehen möglich.
Die betroffenen Seiten sollen ausfindig gemacht werden, und die der jeweils obersten zugehörige Diskussionsseite soll vom Bot eine Benachrichtigung mit einer Kurzanleitung für die bevorstehende Änderung erhalten.
Das jeweilig zuständige Personal muss dann prüfen, ob schon alles passt oder ob die Einbindung an das Layout angepasst werden müsste.
Notfalls helfen FZW und VWS.
Kategorien
Ich zähle nur 146.054 {{All Coordinates}} auf Kategoriebeschreibungsseiten.
Anders als für den ANR gibt es keine Richtlinien für das Layout einer Kategoriebeschreibungsseite.
Während der ANR von der breiten Öffentlichkeit wahrgenommen wird, tummeln sich hier fast nur WP-Internisten. Dieser Namensraum ist nachrangig gegenüber dem ANR. Nachdem dort alles in trockenen Tüchern ist und Erfahrungen gesammelt wurden kann man sich diesem widmen.
Würde erstmal an der Stelle aufpoppen, an der es eingebunden ist. Der NR 14 lässt sich jedoch verzögert auslösen.
Beispiel: Kategorie:Kairo – relativ typischer Vertreter der direkten Einbindung, All Coordinates steht unmittelbar vor Commonscat, was recht einheitlich so gehandhabt zu werden scheint.
Eine andere relevante Fraktion verwendet Vorlage:Kategorietext Geographisches Objekt und in der würde es dann einheitlich zu Beginn der damit versorgten Kategorien dargestellt werden.
Wenn jemand für seinen Zweig des Kategoriebaums unbedingt eine ganz bestimmte Reihenfolge haben möchte, typischerweise auch unmittelbar vor der ersten Oberkategorie, dann kann man über diesen Bereich einen Bot scheuchen, ggf. auch Vorlage:Kategorietext Geographisches Objekt usw. noch mit einem Darstellungsunterdrückungsparameter nachrüsten oder was immer.
Gibt auch noch Kategorien mit selbsterklärendem Namen (Ort im Distrikt XY) und ohne eigenen Text; dann würde es immer passen weil einziges Element.
Moin PerfektesChaos, vielen Dank für deine Ausführungen, nun wird es für mich mal etwas greifbarer. Bin gerne bereit dabei zu helfen. Sag einfach wie wann und wo. mfg --Crazy188018:41, 9. Feb. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Moin zusammen, es wäre schön, wenn man ein paar Zahlen darstellen könnten, wie viele Artikel betroffen wären bzw. wie viele Artikel automatisiert umgestellt werden könnten. Leider kann man sonst nicht greifen, wie groß die Auswirkungen sind. Vielen Dank schonmal im Voraus. mfg --Crazy188007:32, 9. Feb. 2021 (CET)Beantworten
Moin Moin IP, ich würde nur gerne wissen, welcher Wartungsaufwand entstehen könnte. Auch sollte vllt. mal geklärt sein, wo man vllt. Koordinaten in eine Infobox schieben kann. Und nein, keine Koordinaten sind keine Lösung. Halt Aufwandseinschätzungen. mfg --Crazy188008:06, 9. Feb. 2021 (CET)Beantworten
Siehe eins drüber zuzüglich vielleicht 10.000 All Coordinates. 400.000 Artikel wären zwar von der veränderten Darstellung betroffen, sind jedoch nicht alle einzeln umzustellen, weil teilweise schon an der geeigneten Stelle eingebunden und 150.000 dies aus den Infoboxen beziehen. VG --PerfektesChaos15:39, 9. Feb. 2021 (CET)Beantworten
Ich würde ggf. alle betroffenen Vorlagen (ohne weitere Einbindungen im VNR) mit der Anzahl der Einbindungen umseitig aufführen, damit jedem bewusst ist, worum es geht. Am Ende geht es um alle Artikel mit irgendeiner Geo-Angabe. Auch sollte man die Autoren mit Geo-Bezug ins Boot holen, da diese bei einer Änderung gefühlt die ersten Ansprechpartner sein werden. Hat man deren Zustimmung/Konsens, wird der Rest leichter. Auch wenn vordringlicher Handlungsbedarf besteht, so sollte man auch ein Scheitern des MB bereits jetzt ins Auge fassen und dies gleich mit Absichern, den ein Scheitern wäre keine Option. Das Scheitern eines MB zu Dingen mit technisch bedingten Hintergründen sollte man erwarten, da dies nicht jeder intuitiv verstehen wird. Siehe hierzu auch den Abschnitt #Was gesagt werden muss. --darkking3Թ20:20, 28. Feb. 2021 (CET)Beantworten
Es geht nicht um eine, sondern um mehrere Vorlagen.
Du meinst vermutlich den „Hinweisbaustein“.
Es ist völlig egal, wie der gestaltet wird, oder was für Icons dort hineinkommen, was man von mir aus auch alle drei Wochen wechseln mag. Er darf auch grün auf rosa sein; auch dies ist für das MB völlig absolut belanglos.
Bevor das MB nicht erfolgreich abgeschlossen wurde, werde ich keine Minute in sinnlose Vorarbeiten investieren. Ich werde danach über Monate zusammen mit den Bot-Betreibern reichlich zu tun haben, um die Migration ruckelfrei über die Bühne zu bringen; das langt völlig.
Ich meinte diejenige Vorlage, die im Normalfall die Koordinaten und Koordinatenlinks aufnehmen soll. Das sollte eigentlich nur eine sein. Die Veranschaulichung könnte die Akzeptanz des Vorschlags erhöhen. MBxd1 (Diskussion) 20:05, 2. Mär. 2021 (CET)Beantworten
Das sind ca. 2000 Vorlagen, zumeist Infoboxen zu irgendwelchen Orten, Gegenden, Gebäuden, Gewässern etc. Die Vorlage Coordinate wird von denen gefüttert und selbst diese kann man nicht auswerten, weil die nur betroffen ist, wenn sie selbst die Vorlage CoordinateComplex aufruft. So hab ich das mal verstanden als ich mich da ein wenig durch den Code gegraben hab. --Wurgl (Diskussion) 20:37, 2. Mär. 2021 (CET)Beantworten
Bei den Infoboxen soll doch aber das Erscheinungsbild nicht geändert werden, oder? Bezüglich der Darstellung im Artikel geht es doch nur um Vorlage:Coordinate, oder habe ich das falsch verstanden? MBxd1 (Diskussion) 21:01, 2. Mär. 2021 (CET)Beantworten
Wie bereits ausgeführt, gibt es keinerlei Veranschaulichung, weil die Gestaltung nicht Gegenstand des MB ist, und jederzeit beliebig oft verändert werden kann.
Muster für drei gebräuchliche Vertreter derartiger dezenter Hinweise hatte ich vorstehend bereits angegeben; das ließe sich genauso machen, oder aber völlig anders, und kann nach Belieben welches Design auch immer erhalten.
Es würde die zukünftige Gestaltungsfreiheit gefährlich einschränken, falls eine Verbindung zwischen dem MB und irgendeiner konkreten Ausführung hergeleitet werden könnte.
Die x-1000 beteiligten Vorlagen sind weniger dramatisch, weil sie letztlich nur immer dieselben Basisvorlagen einbinden, die zentral anzupassen wären. Lediglich die Infoboxen bedürfen ob ihrer Tabellengestalt individueller Maßnahmen, was jedoch nur die fachgerechte Programmierung beträfe, nicht aber deren optische Darstellung.
Danke, dann habe ich es wenigstens richtig verstanden. Die Bedenken, dass mit einer Vorlage im Vorschlag wir ein per MB zementiertes Vorlagendesign hätten, kann ich nachvollziehen und waren mir auch durchaus bewusst. Der pragmatische Umgang damit würde u. U. hinterher nicht funktionieren. Bleibt das MB also so, wie es ist. MBxd1 (Diskussion) 22:35, 2. Mär. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren19 Kommentare5 Personen sind an der Diskussion beteiligt
Beispiel dazu: Leuchtturm List Ost – derzeit werden die Koordinaten mit nur einfacher Angabe in den Infoboxparametern sowohl in der Infobox als auch am „Ort, an dem Koordinaten erwartet werden“ (derzeit: Ecke oben rechts), angezeigt. Nach der Umstellung würden Koordinaten nur noch in der Infobox, nicht aber am erwarteten Koordinaten-Ort (dann: Artikelende) dargestellt. Wer also routinemäßig (ohne Beachtung des Icons oben rechts bzw. bei Nichtannahme des Vorschlags 2 umseitig) neu das Artikelende ansteuert, um die Koordinaten des Gegenstands herauszufinden, wird enttäuscht werden. -- hgzh10:15, 3. Mär. 2021 (CET)Beantworten
Als „Kontra“ zu „Vorschlag 1“ heißt es ja schon: „Die Darstellung und Position in Artikeln verändert sich deutlich gegenüber dem Status Quo.“ Das deckt die Thematik bereits umfassend ab, ohne wie hier angeführt in Details zu gehen, welche Nuancen alles als Veränderung aufgezählt werden könnten.
„routinemäßig“ ließe sich nur als Desktop-Benutzer entwickeln. Routinierte Mobil-Benutzer hatten noch niemals „da oben“ Koordinaten gesehen. Wenn keine Infobox, dann überhaupt nirgendwo.
Einen Ausgang „Vorschlag 1“ ja, aber „Vorschlag 2“ nein halte ich für eher unwahrscheinlich. Im Prinzip gehören beide Vorschläge schon zusammen, und sind nur aufgeteilt, um keinen formalen Einwänden Raum zu geben, man hätte keine Gelegenheit gehabt, nur das eine und nicht das andere zu erhalten. Des weiteren sind es zwei gut zu trennende Ausbaustufen, die technisch voneinander unabhängig sind und sich gut separat verständlich darstellen ließen.
Im Übrigen sind derartige Gewöhnungs-Anpassungen durch die Benutzer nach ein, zwei Jahren völlig vergessen. Es gibt jedes Mal zu Beginn einen großen Aufschrei, der Weltuntergang naht, aber bis auf eine Handvoll Unentwegter ist nach ein paar Monaten alles vergessen. Ich verlange die Rückkehr zum Monobook in den Grenzen von 2009.
Prinzipiell wäre es möglich, zukünftig eine Dublette zur Infobox-Koordinate einzubauen, wenn Fachgebiete identifiziert durch eine bestimmte Infobox dies wünschen:
Der Mechanismus „Karte aus allen in der Seite erwähnten Koordinaten“ lässt sich auch darauf anwenden, dass es nur eine einzige und in der Infobox mit numerischen Werten dargestellte Koordinate geben würde.
Damit ließe sich im Nachgang eine Dublette der Infobox-Koordinate-Verlinkung erzeugen, die damit zwar keine konkreten Zahlenwerte benennt, aber die gleiche Stelle zugänglich macht. Das kann dann in die gleiche Optik des alleinstehenden Hinweisbausteins eingefügt werden, mit entsprechend angepasstem Text. Die Icon-Verlinkung geht jedoch immer an die Infobox.
Ich denke, dass es gerade diese Nuancen sein werden, die einen Abstimmer interessieren werden. In dieser Diskussion ist schon vielfach zur Sprache gekommen, dass ein bisschen die Vorstellung fehlt, was die vorgeschlagene Änderung bewirken würde. Dass der Planer dies innerlich gut vor Augen hat und es hier in erster Linie nicht um Detail- und Gestaltungsfragen gehen soll, ist mir klar, aber meiner Ansicht nach kann man es auch nicht völlig ausklammern und sollte daher schon an ein paar wichtigen Stellen konkreter werden. Und den von mir umseitig genannten Aspekt halte ich persönlich für so einen Fall, da sich hier etwas mehr als nur die Position verändert. Dass der Einwand für mobil nicht gilt, sehe ich als lässlich an, denn ein Großteil der Abstimmenden wird sich auf die Desktopdarstellung als eigenen Arbeitsschwerpunkt beziehen. Aber letztendlich sollen du und die Unterstützer das entscheiden. -- hgzh18:13, 3. Mär. 2021 (CET)Beantworten
Sicher, sicher.
Aber die Beschreibung dessen, was geplant ist und wie der durch das MB bezweckte Zustand hinterher aussehen würde, wird weiter oben geleistet. An jener Stelle ist das schon mühsam genug, es Autoren-tauglich zu erklären. Jedoch ist dort Platz und Gelegenheit, um das so gut es geht vorstellbar zu machen.
Hingegen unten, bei Pro+Kontra, soll das nur kondensiert zur Entscheidungsfindung gegenübergestellt werden. Dort nochmals alles auseinanderzudröseln zerstört die Übersichtlichkeit.
Ja, mein Eindruck ist durchaus, dass in vielen Fragen des Projekts die Gewohnheit Desktop-2005-nienixändern in der Lautstärke recht dominant ist. Die Interessen der Leserschaft zählen ohnehin nicht. Aber die Mobilen dürften hier gegenüber dem harten Kern allerdings auch recht deutlich werden. Und ich vermute, dass ein Großteil Zukunftsperspektiven und Argumentation nachvollziehen kann.
Ich bin nicht mal sicher, was ich hier wollen würde. Das umfangreiche Einbinden von Koordinaten in Infoboxen ist möglicherweise auch Konsequenz aus den bisherigen Mängeln. Die sind dann hinfällig, aber so recht glaube ich nicht, dass man die Koordinaten daraufhin aus den Infoboxen entfernen und durch den Standardbalken unten ersetzen würde. Es ist also nur die Frage, ob man in Artikeln mit Koordinaten in der Infobox zusätzlich unten den Kasten setzt, wobei in den Infoboxen üblicherweise keine OSM-Karteneinblendungslinks sind (geht ja auch nicht, wo sollte die Karte da landen?). Die Antwort des MB ist "nein, kein zusätzlicher Koordinatenkasten". Technisch ist da aber kein Hindernis, es sind getrennte Vorlagen, schlimmstenfalls müsste man die Koordinaten zweimal eingeben. Wenn also ein Portal für seine Artikel entscheidet, dass der Koordinatenkasten unten zusätzlich zur Infobox gesetzt wird, dann ist das so und dann steht dem nichts entgegen. MBxd1 (Diskussion) 21:23, 3. Mär. 2021 (CET)Beantworten
Naja, grad eine Infobox mit ihrem Zahlensalat und Einwohnerzahl und Postleitzahl ist der optimale Ort, um auch noch den Geokoordinaten-Kram aufzunehmen.
Nach ein paar Monaten hätten sich fast alle dran gewöhnt.
Von „Koordinaten daraufhin aus den Infoboxen entfernen“ war auch nicht die Rede; wenn, dann ginge es um eine Dublette zur ohnehin immer in der Infobox gegebenen Information.
„wobei in den Infoboxen üblicherweise keine OSM-Karteneinblendungslinks sind (geht ja auch nicht, wo sollte die Karte da landen?)“
Äh, mir zurzeit nicht so bewusst; „Karteneinblendungslink“ ginge ja weder an der überkommenen Stelle im Seitenkopf noch an der bislang ausgeblendeten Irgendwo-Stelle.
Was ich kenne, sind Verlinkungen, mit denen sich (auf dem Desktop: in einem anderen Browser-Tab) eine entsprechende Karte nachladen ließe. Das kann auch in der Infobox zusammen mit den Koordinaten geliefert werden, genau wie bisher im Seitenkopf dargestellt.
Karteneinblendungstechniken kenne ich schon, so von lange her, aber die würden in einem eigenen Abschnitt mitten im Artikel dargestellt werden. Das mag dann auch individueller Zielpunkt des Icon gemäß Vorschlag 2 sein.
Nur kurz zur doppelten Eingabe der Koordinaten: Bei Biografien sind Geburts- und Sterbedaten immer doppelt angegeben: Im Einleitungssatz und dann in der Vorlage Personendaten. Bei Sportlern gibts oft eine Infobox und dort steht das nochmals drinnen (Geburts- und Sterbejahr ist in den Kategorien ebenfalls enthalten, also bis zu vier mal). Eine doppelte Eingabe ist also nichts besonderes. --Wurgl (Diskussion) 15:42, 4. Mär. 2021 (CET)Beantworten
Die Frage, wo die Einbindung erfolgen soll, wenn die Koordinaten nur noch in der Infobox erscheinen und nicht mehr am gewohnten Platz, wurde ja auch bisher nicht diskutiert. Wenn man da ergebnisoffen herangeht, kann man auch die Unterbringung in der Infobox in Frage stellen, zumal die ja nicht alles bietet, sondern nur die Zahlen und den Geohack-Link.
"Karteneinblendungslink" meint in der Desktopansicht das rechte der beiden Symbole. Das linke Symbol öfnnet ein Popup mit OSM-Karte, das rechte blendet sie in den Artikel ein. Genau das würde der Koordinatenlinkkasten auch leisten. Infoboxen könnten das Popup liefern, aber nicht die Karteneinblendung. Tatsächlich können reale Infoboxen beides nicht. MBxd1 (Diskussion) 21:19, 4. Mär. 2021 (CET)Beantworten
Ohne der nicht näher spezifizierten Technik in sämtliche Abgründe gefolgt zu sein: „das rechte blendet sie in den Artikel ein“ – dieses rechte Dingens fügt sich auf den ersten Blick gesehen immer (rechts) oben zwischen die vorhandenen Elemente ein, völlig egal wo auch immer die spezifizierende Koordinatenvorlage sich in der Seite befindet.
Weil, das Dingens „das rechte“ weiß eigentlich überhaupt nicht, wo in der Seite die auslösende Koordinatenvorlage im Wikitext steht, oder an welcher absoluten Position die auslösende Verlinkung dazu dargestellt würde.
So auf den ersten Blick blendet es das immer zu Beginn des Inhaltsbereichs ein, genauer gesagt hinter der Positionid="contentSub", und dabei ist völlig egal an welcher Stelle der Seite und wie viele dieser auslösenden Verlinkungen vorhanden wären.
Heißt: Auch aus einer Infobox heraus ließen sich die beiden Verlinkungen problemlos auslösen. Ist allerdings ein paar Jahre her, dass ich mir sowas mal genauer angeguckt hatte, und bin möglicherweise nicht mehr auf dem allerfrischesten Stand, was ich aber vor einem erfolgreichen Abschluss des MB auch nicht mehr aktualisieren werde. Eine übersichtliche programmierungstechnische Doku zu dem Geraffel konnte ich jetzt so auf die Schnelle nicht aufspüren.
Danke für die Klärung, so weit war das für mich nicht nachvollziehbar. Ob es irgendwelche Infoboxen gibt, die die Option vielleicht sogar nutzen, weiß ich natürlich nicht. Nur wird es wohl gewollt gewesen sein, dass die Karte dort aufgeht, wo das Symbol ist, nämlich oben. In Zukunft ist dann die Vorlage unten, die Karte öffnet aber weiterhin oben. Könnte den Leser verwirren. MBxd1 (Diskussion) 22:39, 5. Mär. 2021 (CET)Beantworten
So ein Ausklapp-Dingens kann technisch auch unterhalb des Bausteins am Seitenende, also direkt darunter und noch oberhalb der Navigationsleisten usw. ausgefahren werden.
Kann genau wie sein Ahn zurzeit nur genau eine solche eingeblendete Karte handhaben. Diese Beschränkung ist jedoch nicht erforderlich; eigentlich kann diese Karteneinblenderei an beliebig vielen Stellen in der Wiki-Seite für beliebig viele unterschiedliche Koordinatenspezifikationen passieren. Aber nicht mehr heute.
Damit wird dann nicht nur die Auslösung am Seitenende für uns möglich; könnte auch unmittelbar oberhalb einer Infobox gestaltet werden.
Weil aber die Infobox nur die Haupt-Infobox sein kann, denn es geht ja nur um die zentrale Seiten-Koordinate für die Gesamt-Seite, würde die konventionelle Anordnung ganz oben bei einer Infobox auch langen. Die schubst den Inhalt aus der halben Fensterhöhe heraus, also müsste die Karte auch noch erscheinen.
Wobei es auch relativ simpel wäre, mit dem Anklicken des Icons aus jeder beliebigen Seitenposition die eingeblendete Karte an die Oberkante des gescrollten Bildschirmausschnitts zu platzieren; genauer gesagt umgekehrt: Die Scroll-Position kann mit einem simplen Statement auf die Oberkante der eingeblendeten Karte flutschen.
Alle diese Detailprobleme sind lösbar, sobald die Zeit gekommen ist.
Für die Entscheidung des umseitigen MB sind diese Detailfragen jedoch völlig irrelevant.
Umseitig geht es nur um die Entscheidung: Soll alles so bleiben, wie es seit 2005 schon ist, weiterhin ohne Mobil, mit Verdeckung der Bedienelemente, mit augenfeindlicher Barriere, und eines Tages völlig ohne Koordinaten?
Oder soll es eine Lösung geben, die auch mobil in normalgroßer Schrift allen Benutzern eine Teilhabe ermöglicht und zukunfstssicher ist?
Das ist hier ein Henne-und-Ei-Problem.
Bevor das MB nicht erfolgreich war, lohnt sich keine Investition in Programmierarbeiten.
Mich hat deine Kommentierung zum MB-Entwurf jetzt einen ganzen Wiki-Tag gekostet, um die Hintergründe zu erforschen.
Das ist vergeudete Zeit. Wenn das in vier, sechs, acht Wochen mal spruchreif werden würde, habe ich das alles längst wieder vergessen und muss mich erneut in diesen ganzen Kram einarbeiten.
Danke. Eigentlich hatte ich auch jetzt keine Antwort mehr erwartet, geschweige denn umfangreiche Recherchen. Für mich persönlich war das so akzeptabel, die grundsätzliche Basis des MB sowieso. Hinsichtlich der Karteneinblendung darf man übrigens auch die Frage stellen, ob die überhaupt gewollt ist. Das hat damals niemand gefragt, das wurde einfach reingebastelt. MBxd1 (Diskussion) 22:20, 7. Mär. 2021 (CET)Beantworten
Ich nutze das zB *nie*, sondern will *immer* zur "richtigen" Karte (meist OSM, Maps oder Earth). Nur der Koordinatenlink muss schnell erreichbar bzw. überhaupt sichtbar sein. OT: Mit der Hauptpunkt, warum ich (sehr geographieaffin) Mobil kaum nutze. Der andere ist: Kategorien. Davon abgesehen, dass einfach *alles* unbequemer ist. Aber das liegt wohl in der Natur der Sache und ist nicht auf Wikipedia beschränkt. *Simple* Sachen - dafür sind Mobilgeräte topp. Komplexe WP-Artikel lesen, geschweige denn bearbeiten gehört nicht dazu. --AMGA(d)09:08, 8. Mär. 2021 (CET)Beantworten
Man sollte sich auch mal von dem Gedanken trennen, dass Mobilgeräte unbedingt Mobilversionen von Internetseiten bräuchten. Zeitgemäße Smartphones haben Bildschirme in einer Größe und Auflösung, die auch die Nutzung der Desktopversionen ermöglichen, u. a. Wikipedia. Stattdessen werden wir noch mit einer hingestümperten Hochformatversion zwangsbeglückt, in der nichts richtig funktioniert.
Ich halte von diesen Karteneinblendungen nichts. Ob die eine Mehrheit der Nutzer haben will (oder überhaupt kennt) wissen wir nicht, die Bastler fragen ja weder vorher noch hinterher. Sie werden jedenfalls in Artikeln mit Koordinaten in Infoboxen bei Annahme des MB nicht mehr verfügbar sein. Tja nun, das ist dann eben so. Wem das nicht passt, der kann ja dagegen stimmen oder hinterher weiterbasteln. MBxd1 (Diskussion) 17:00, 10. Mär. 2021 (CET)Beantworten
Diese Behauptung ist schlicht falsch: „Sie werden jedenfalls in Artikeln mit Koordinaten in Infoboxen bei Annahme des MB nicht mehr verfügbar sein.“
Ich wies bereits 21:41, 7. Mär. 2021 darauf hin, dass ich das Gadget komplett neu geschrieben habe.
Die Neufassung wird beliebig viele Karten innerhalb der Seite einblenden können, sie wird das auch in der mobilen Oberfläche können (anders als heute), sie wird den Ort der Einblendung beliebig auch der Position der Auslösung zuordnen können, die Bildschirmposition wird nach Auslösung erforderlichenfalls so angepasst, dass mindestens die Hälfte der Karte sichtbar ist.
Dann habe ich das missverstanden. Die Alternative ist also, dass Infoboxen die Links zur Karteneinblendung aufnehmen müssen (und können), um weiterhin Karteneinblendung zu ermöglichen. MBxd1 (Diskussion) 18:52, 10. Mär. 2021 (CET)Beantworten
So in der Art, ja.
Das ist damit gemeint wenn es heißt: Das, was bislang in den Desktop-Skins da rechts oben dargestellt wird, soll zukünftig präsentiert werden in der Infobox, in einem Hinweiskasten ganz unten bei den Navileisten, in einem Hinweiskasten sonstwo mitten im Artikel, oder durch Erwähnung der Koordinaten in irgendeinem Abschnitt mittendrin in Verbindung mit einer historischen Karte oder was auch immer.
Im Fall der Infobox, die als Haupt-Infobox ziemlich zu Beginn stehen müsste, weil sonst könnte sie nicht die zentrale Geo-Info über die ganze Seite liefern, schreibt sich das Gadget in die Infobox hinein, wie bisher hinter das statische Koordinaten-Link; nach Anklicken entsteht die Einblendung da wo sie (beim Desktop) immer schon stand, nämlich ganz oben in der Seite. Wenn die Oberkante der Karte dadurch außerhalb des sichtbaren Ausschnitts liegen würde, wird dorthin gescrollt.
Im Fall des Hinweiskastens ganz unten wird die Karte unmittelbar unterhalb des Hinweiskastens eingeblendet (würde ich mal vorschlagen; passiert sonst ganz oben in der Seite). Wenn mehr als die Hälfte der Karte dadurch außerhalb des sichtbaren Ausschnitts liegen würde, wird entsprechend gescrollt, so dass die ganze Karte (aber gleichzeitig auch noch der Hinweiskasten) innerhalb des Ausschnitts liegt.
Die Neufassung des Gadgets ist in der Lage, zu beliebig vielen unterschiedlichen Orten auf der Erde innerhalb desselben Artikels unterschiedliche Verlinkungen und Karteneinblendungen an den jeweils dafür gewünschten Seitenpositionen darzustellen.
Die historische Programmierung, deren Spirit wohl über ein Dutzend Jahre alt ist, kann nur mit einem einzigen Koordinatenlink umgehen, und nur auf Desktop und nur im Seitenkopf anzeigen.
Es ist halt ein Gadget, und das muss vorher wie nachher unterstützt werden. Wenn es dann soweit ist. Obendrein ist es Default-Gadget, also Opt-Out für angemeldete, und damit von allen (Desktop-)IP seit vielen Jahren nutzbar.
Habe die Neufassung jetzt so umgebaut, dass sie beliebig viele Karten innerhalb der Seite einblenden können wird. Auch jeweils in der Nähe zugeordnet, sonst halt ganz oben in der Seite. Falls weniger als die obere Hälfte der Karte sichtbar wird, wird sie am oberen Fensterrand positioniert, also umgekehrt: entsprechend gescrollt.
Mobil ist halt das kleine und handliche. Wenn man unterwegs ist und von einer Sehenswürdigkeit zur andern laufen möchte. Die Leut in meiner Umgebung nutzen das Smartphone, um nicht viel mehr zu einem Begriff zu erfahren als im Einleitungsabschnitt steht, was sehr oft bereits ausreicht um das Wissensproblem zu lösen. 99,8 % der ANR-Abrufe stammen von Nur-Lesern.
Letzter Kommentar: vor 3 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, ich bin der Meinung, dass beim zweiten Punkt noch das Wort „nicht“ eingefügt werden sollte:
Bei Weiterentwicklung der Skins werden die Seitenkoordinaten in absehbarer Zeit auch nicht auf Desktop-Oberflächen und damit überhaupt nicht mehr angezeigt.
Nein, das macht es für mich noch unverständlicher. Ich habe als Vorschlag 2 Komma ergänzt.
Bei Weiterentwicklung der Skins werden die Seitenkoordinaten in absehbarer Zeit auch auf Desktop-Oberflächen, und damit überhaupt, nicht mehr angezeigt.
Oder kürzer. Ohne die 3 Worte
Bei Weiterentwicklung der Skins werden die Seitenkoordinaten in absehbarer Zeit auch auf Desktop-Oberflächen nicht mehr angezeigt.
Oder (umständlich?!) umformuliert. Hinten 2. Teilsatz
Bei Weiterentwicklung der Skins werden die Seitenkoordinaten in absehbarer Zeit auch auf Desktop-Oberflächen nicht mehr angezeigt. Damit sind sie dann überhaupt nicht mehr sichtbar.
Das mit den Kommata ist m. E. auch nicht sofort einleuchtend. Ich finde den letzten Vorschlag von Dir am besten, das ist nicht umständlich sondern verständlicher. --JoeHard (Diskussion) 18:27, 4. Mär. 2021 (CET)Beantworten
Danke für den Hinweis.
Ich werde es mir am Wochenende angucken, wenn ich mal ausgeschlafen bin. Es geht ja nur um eine Formulierung, die niemanden nicht negierend verwirrt, auch durch zwei und dreimal nicht.
Der beabsichtigte Sinn ist unstrittig, insofern hat das noch etwas Zeit, und vielleicht stellt sich eine optimale Lösung heraus. Ggf. durch mehrere kurze Einzelsätze.
+1 für den letzten Vorschlag von Steffen, mit den Einzelsätzen. Für die Annahme und Akzeptanz des Meinungsbildes ist es sehr wichtig, dass auch Normalverbraucher sofort sehen, dass der Status quo hier keine Option ist. A propos Normalverbraucher: M.E. sollte man beim ersten Vorkommen von "Skin" einen Wikilink auf die Hilfeseite setzen. --Appelboim (Diskussion) 09:46, 8. Mär. 2021 (CET)Beantworten
habe es jetzt zu
Bei Weiterentwicklung der Skins werden die Seitenkoordinaten in absehbarer Zeit auch auf Desktop-Oberflächen nicht mehr angezeigt. Damit sind sie dann überhaupt nicht mehr sichtbar.
Die Gegenüberstellung irdisch-himmlisch ist schon durchaus beabsichtigt, soll ein wenig schmunzeln lassen, aber wenn es jemanden zu arg verwirrt muss es halt anders formuliert werden.
Ich werde es mir am Wochenende angucken, wenn ich mal ausgeschlafen bin. Es geht ja nur um eine verständliche Formulierung, der beabsichtigte Sinn ist unstrittig.
Im Nachgang wird dann ja auch die Sache mit „astro“ erläutert. Wobei jemand, der nicht weiß, dass wir neben erdgebundenen Koordinaten auch CoordinateSky haben, die Betonung auf geo-grafische und damit die Einschränkung auf Erde auch nicht wird nachvollziehen können. Dann braucht es die beiden unmittelbar folgenden Punkte „Globus“ und „Astro“ ohnehin, und dann klärt sich auch die Dualität.
Mutmaßlich würde Astro aber völlig aus der Icon-Geschichte herausfallen, weil eigentlich sämtliche Astro-Objekte entweder eine reguläre Infobox oder zurzeit noch eine simulierte Infobox-Tabelle haben. In der gibt es sternhaufenweise geometrische und physikalische Daten, und es ist kaum nachzuvollziehen, warum die Sky-Koordinaten dann in einer anderen Ecke stehen sollen. Wäre aber erst nach dem MB zu klären.
@Hans Koberger: denke dir einfach oben rechts die Anzeige OHNE die Koordinaten. Mehr wird konkret noch nicht entschieden. Wenn das hier abgelehnt wird, gibt es demnächst gar keine Anzeige mehr. Alles andere wird später entwickelt und entschieden. --Steffen2 (Diskussion) 10:09, 15. Mär. 2021 (CET)Beantworten
@Mediatus: wenn du das willst, dann musst du beiden Vorschlägen zustimmen. ansonsten wirst du demnächst nichts mehr sehen. Sobald irgendwann ein Mediawiki-Update kommt. Ob der Termin in 3 Monaten oder 3 Jahren ist, kann niemand vorhersagen. --Steffen2 (Diskussion) 11:42, 15. Mär. 2021 (CET)Beantworten
Wenn Du das sagst. Ich kenne mich da wenig aus, war aber mit dem sichtbaren Status quo sehr zufrieden. Also ändere ich mal meine Meinung : ) --Mediatus12:32, 15. Mär. 2021 (CET)Beantworten
Ich schließe mich Hans Kobergers Bitte an. Bitte gebt mir eine Möglichkeit, dass ich mir das visualisieren kann. Wenn ich nicht weiß, wie das zukünftig aussehen wird, würde ich den Vorschlag eher ablehnen. -- Chaddy · D13:41, 15. Mär. 2021 (CET)Beantworten
Du sollst dir kein Bild machen …
Auf derartige Illustrationen des vorstellbaren zukünftigen Erscheinungsbildes wurde ganz bewusst verzichtet.
Grund: Es hätte eine präjudizierende Wirkung; das heißt in den kommenden Jahren könnten Gestalter in Teufels Küche kommen, wenn sie die konkrete Gestaltung ändern und dann argumentiert würde, das MB habe jedoch genau diese und jene Darstellung suggeriert und nur deshalb habe man dafür gestimmt und wenn da jetzt jemand ein Iota davon abwiche dann müsse ein neues MB gemacht werden.
Deshalb ist nur verbal und abstrahiert der Rahmen vorgegeben.
Die Gestaltung kann alle paar Wochen völlig geändert werden; die ist hier überhaupt nicht das Thema. Es geht ausschließlich um die Beendigung der bisherigen absoluten Positionierung.
Ist wie die Geschichte mit dem unsichtbaren Gott, dem Götzendienst und dem Bilderverbot.
Das ist nicht hilfreich. Wenn ihr etwas vorschlagt, muss man sich auch ein Bild davon machen können, wie es dann ungefähr aussehen wird. -- Chaddy · D23:19, 15. Mär. 2021 (CET)Beantworten
Es geht bei diesem MB jedoch ausschließlich um die Frage, ob die Koordinaten an der Stelle präsentiert werden sollen, an der die Vorlage eingebunden ist.
Wie das im Lauf der Jahre dargestellt wird, bleibt völlig offen, und es wird auch umseitig keinerlei Bindung an irgendein bestimmtes Design unterstellt.
Es gibt deshalb auch kein „Wenn ihr etwas vorschlagt, muss man sich auch ein Bild davon machen können, wie es dann ungefähr aussehen wird“ – es wird nichts derartiges vorgeschlagen.
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Der Vorschlag 2 sieht ja offenbar eine Platzierung der Koordinaten mittels Seitenindikator vor, wie Exzellenz-, lesenswert-usw. Wenn ich die entsprechende Seite richtig verstehe, dann gehören derzeit Geokoordinaten ohnehin zu den Seitenindikatoren. Daraus ergibt sich für mich zum einen die Frage, wo genau der Unterschied ist, und zum anderen, ob letztlich unsere anderen Seitenindikatoren nicht auch von genau dem gleichen Problem betroffen sind? Liebe Grüße--Emergency doc (D) 11:18, 15. Mär. 2021 (CET)Beantworten
Diese Seite spricht wohl den Bereich oben rechts im Allgemeinen an, jedenfalls werden die Koordinaten derzeit nicht im Indikatoren-Bereich angezeigt, sondern, bspw. in Vector-Skin, obendrüber (vgl. Almaty). Der Vorteil am Indikator-Bereich ist, dass a) wir dort von beliebiger Stelle im Artikel aus Icons einblenden können, ohne absolute Positionierung (s. umseitig) zu benutzen und b) dieser Bereich von der Software je Skin direkt an einer passenden Stelle angezeigt werden kann und damit nicht Gefahr läuft, irgendwann von anderen Bedienelementen überdeckt oder komplett abgeschaltet zu werden. -- hgzh11:31, 15. Mär. 2021 (CET)Beantworten
Ich lese durchaus den Zahlenwert und bin gewiss auch derzeit nicht der Einzige, der anhand der Zahlen eine genügend genaue Vorstellung von der Position hat. Sich selbst zum Maßstab des Universums zu nehmen, ist zwar sehr beliebt, führt aber grundsätzlich zu verkehrten Anschauungen.--Trollflöjtenαω14:55, 15. Mär. 2021 (CET)Beantworten
Also, mindestens kann auch ich aus einer 47°/11° noch so ungefähr entnehmen, dass ich mich in Deutschland und welcher Region dort befinden werde, und laufe nicht Gefahr durch eine Verwechslung in Sibirien oder der Sahara gelandet zu sein. Und wer keine Verbindung zu etwas anderem hat, oder die ausgedruckte Version, und jemand anders mündlich etwas übermitteln will, der braucht schon die sichtbaren Daten. Es muss ja nicht bis auf die letzte Bogensekunde und siebte Nachkommastelle eingetippt werden. VG --PerfektesChaos17:39, 15. Mär. 2021 (CET)Beantworten
Davon war (wohl) auch keine Rede. Es gibt aber sehr viele Fragestellungen, die mit einer mehr oder minder groben Einschätzung gemäß der Koordinaten beantwortbar sind. --Trollflöjtenαω14:54, 28. Mär. 2021 (CEST)Beantworten
Letzter Kommentar: vor 3 Jahren9 Kommentare5 Personen sind an der Diskussion beteiligt
Ich möchte, dass die Koordinaten weiterhin rechts oben angezeigt werden, bei allen Artikeln, in denen Koordinaten vorkommen. Das sollte weiterhin so aussehen wie jetzt. Das klappt nicht in Mobilansicht? Dann bastelt etwas, damit man es auch in Handys sehen kann. Wenn das alles durch ein Update wegfällt, dann passt halt das Update an. Beide Varianten kann ich mir optisch nicht vorstellen, dafür sind die Erklärungen zu technisch. --Gereon K. (Diskussion) 23:09, 15. Mär. 2021 (CET)Beantworten
mit anderen Worten. Wenn die WMF das irgendwann (demnächst?) ändert, haben wir keine Chance mehr etwas oberhalb des eigentlichen Textes anzuzeigen. Nur die neuen Icons funktionieren dann dort noch. --Steffen2 (Diskussion) 10:05, 16. Mär. 2021 (CET)Beantworten
Außerdem kommen rechts oben im neuen Vector die Sprachlinks hin; sofern die absolut positionierten Inhalte nicht abgeschnitten werden, könnten sie zu sehr unschönen Überdeckungseffekten führen, die sowohl Koordinaten als auch Sprachlinks unbrauchbar machen würden. Wir können an der Weiterentwicklung der Skins überhaupt nichts ändern.—XanonymusX (Diskussion) 13:42, 16. Mär. 2021 (CET)Beantworten
Kann mir nicht vorstellen, dass in der englischen Wikipedia das alle so wollen. Vielleicht ändert sich das ja alles noch und wir sind etwas zu schnell. Jedenfalls ist es sehr unglücklich die Koordinaten an verschiedenen Positionen suchen zu müssen, auch wenn ein Icon etwas dabei hilft. Ich sehe eigentlich technisch kein Problem, falls der Wille da ist, die Koordinaten oben rechts zu halten. --XPosition (Diskussion) 00:28, 17. Mär. 2021 (CET)Beantworten
Die mw:Recommendations for mobile friendly articles on Wikimedia wikis sind in der Hinsicht schon lange deutlich: „Meta data (including coordinates) should be positioned at the bottom of the article“. Und Mobilgeräte sind mittlerweile das Maß der Dinge. Wenn du technisch kein Problem siehst, bin ich gespannt auf deinen Input, die vorangegangenen Diskussionen (die du auf dieser Seite und umseitig verlinkt findest) haben nichts Brauchbares ergeben.—XanonymusX (Diskussion) 00:49, 17. Mär. 2021 (CET)Beantworten
@XPosition: „Kann mir nicht vorstellen, dass in der englischen Wikipedia“: Auch dort sind in der Mobildarstellung (ANR >50 % Abrufe) keine Koordinaten zu sehen, falls es nicht parallel eine Infobox usw. geben würde. Die sind also eher genauso hinterm Mond wie wir. VG --PerfektesChaos15:53, 19. Mär. 2021 (CET)Beantworten
Die Task ist die in unserer Angelegenheit umfangreichste, die mir bekannt wäre. Gibt wohl noch kurze und Duplikate hier und da, außerdem verstreute Erörterungen auf mw: und meta: – insgesamt ziehen sich Mobil- und Absolutpositionierungs-Diskussionen über fast ein Jahrzehnt, und das war bis Anfang dieses Jahres nicht mein Kernthema gewesen.
Anfang der 2010er war die weitere Entwicklung mit Smartphone und dessen Verbreitung unklar, aber ab 2015 wurden die relativ preiswert, die Netze meist schnell und nicht zu teuer, und die Apps und Mobilbrowser kamen. Inzwischen ist recht klar, worauf wir uns für die Zukunft einstellen müssen.
Letzter Kommentar: vor 3 Jahren5 Kommentare5 Personen sind an der Diskussion beteiligt
Nach Beobachtung des morgen zu Ende gehenden MBs, habe ich den Eindruck, dass es wohl ins Leere läuft und alles beim Alten bleibt. Es war ja leider nicht abzusehen, dass etliche User*innen gleich für beide Vorschläge abstimmen werden und kaum jemand die Contra-Abstimmung für einen der beiden Vorschläge nutzen würde. Im Nachhinein betrachtet wäre es wohl zielführender gewesen, über die beiden Vorschläge als "Entweder/Oder" abstimmen zu lassen. Das hätte ein eindeutiges Ergebnis gegeben. So bleibt jedenfalls alles beim Alten, da ja beide Vorschläge im Prinzip eh schon seit langem parallel umgesetzt werden. Da werden alle augenoptisch beeinträchtigten Leser*innen, die WP per Desktop nutzen möchten, wohl weiterhin mit diesem Problem leben müssen. Für mich habe ich (leider erst jetzt) ja die ultimative Lösung per "Element picker" von uBlock Origin gefunden, der das ganze Koordinatengedöns rechts oben in Zukunft ein für alle Mal von meinem Bildschirm fegt. Wäre für ebenfalls beeinträchtigte User*innen sicherlich auch ein Kandidat für eine CSS-Zauberformel.--Ciao • Bestoernesto • ✉10:07, 27. Mär. 2021 (CET)Beantworten
Kann es sein, dass Du die Vorschläge nicht ganz richtig verstanden hast? Vorschlag 1 ist die Umlagerung der Koordinatendarstellung, Vorschlag 2 ist ein Link darauf. Vorschlag 2 baut daher eigentlich auf Vorschlag 1 auf und wäre ohne Vorschlag 1 kaum umzusetzen. Beide zusammen sind kein Problem und werden auch umgesetzt werden. MBxd1 (Diskussion) 10:54, 27. Mär. 2021 (CET)Beantworten
Dieses MB ist doch ohnehin nur eine Absicherung für die Technik, damit man "HIER BLEIBT ALLES SO WIE ES IST" etwas entgegensetzen kann, was man nicht wegdiskutieren kann. --MGChecker – (📞| 📝| ) 13:01, 27. Mär. 2021 (CET)Beantworten
Nein, schau dir mal das Bild an. Das neue Icon oben erscheint oberhalb des gebastelten alten Eintrags in dem rot markierten Bereich. Gemeinsam mit z.B. Exzellent und anderem was dort möglich ist. Siehe hier. Wo genau ist Skin-Abhängig. Aber immer an einem freien Platz. Es wird nie etwas überdeckt. --Steffen2 (Diskussion) 13:19, 27. Mär. 2021 (CET)Beantworten
Letzter Kommentar: vor 3 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, ich kann mit meinen geringen Kenntnissen zum Thema hier weder zustimmen noch wirklich „konstruktiv dagegen sein“. Mir geht es so, wie denen, die dem Text der Überschrift „Ein Bild sagt mehr als 1000 Worte“ zugestimmt haben. Ich kann mir manches besser vorstellen, wenn ich es sehe. Die Zusammenfassung unter „Formulierungen und Akzeptanz“ ist, glaube ich, ganz gut für einen Überblick.
Insgesamt habe ich das Gefühl, dass dieses Meinungsbild auch die Bemühungen des Teams Technische Wünsche der Wikimedia Deutschland beeinflussen könnte und auch die Frage, inwieweit die deutsche und die englische Wikipedia hinsichtlich ihrer Infrastruktur auseinander driften oder einigermaßen beieinander bleiben können. Es laufen die Themenschwerpunkte „WP:Technische Wünsche/Topwünsche/Leichter mit Vorlagen arbeiten“ und „Wikipedia:Technische Wünsche/Topwünsche/Bessere Unterstützung von Geoinformationen“ und auch dieses Meinungsbild beschäftigt sich mit Vorlagen und Geoinformationen.
Ich bin damit überfordert, mich dem Thema ausreichend auseinander zu setzen und ich hoffe nicht, dass ich mit einer Enthaltung dagegen gestimmt habe, dass sich das Team Technische Wünsche weiter mit den Fragen beschäftigen darf.
Du könntest (aus Deiner Sicht) auch etwas falsch machen, wenn Du nicht dafür stimmst. oder lautet Dein Credo:" Alles ist immer so gut, wie es gerade ist?" Vermutlich nicht ;) Also machst du doch nur etwas falsch, wenn ein Votum abgibst, für dessen Wahl Du nicht ausreichend informiert bist (bei dem doch ziemlich sperrigen Thema nicht unbedingt erstaunlich). Oder mal ganz unfreundlich nach Nuhr:" Wenn man keine Ahnung hat...". Hatte ich auch erst vorgehabt, mir dann aber doch die Zeit genommen, mich wenigstens mit ausreichend Halbwissen zu versorgen. Aus meiner Sicht hast Du es also genau richtig gemacht. Das Ergebnis ist auch viel zu eindeutig, als das hier eine böse Truppe von Manipulatoren genügend Ahnungslose über den Tisch gezogen haben könnten.
Das Team technische Wünsche setzt ja hoffentlich auch nur die Wünsche um und nicht irgendwas, was sie wollen. Also kann ich Deine Bedenken da auch nicht ganz nachvollziehen. Flossenträger08:48, 29. Mär. 2021 (CEST)Beantworten
WMDE hätte aber ohne das umseitige MB auch keine Möglichkeit zu einer robusten Lösung gehabt, weil Eingriffe in den Seitenbestand (insbesondere ANR) erforderlich sind und die Angelegenheit nicht durch eine externe Programmierung lösbar ist.
WMDE hat da noch genug andere offene Aufgaben zum Geo-Abarbeiten, die mit umseitig keine besonderen Berührungspunkte hätten.
Tatsächlich wird im Hintergrund längst in Richtung einer Umstellung gearbeitet.
So werden bereits Einbindungen der auslösenden Vorlagen an die richtige Stelle des Wikitextes geschoben.
Auch andere Vorbereitungen sind in der Schublade.
Dieses MB ist ein Teil davon, weil damit dies und andere Sachen schon mal auf Vorrat eingetütet wurde und zur Umsetzung keine langwierigen Diskussionsprozesse mehr nötig sind.
Wir haben nur eine Handvoll Leutchen, die technisch und organisatorisch in der Lage wären, an Prozessen wie diesen hier mitzuwirken.
Und die drehen nicht gelangweilt Däumchen, sondern haben ellenlange ToDo-Listen und arbeiten andere Hinterlassenschaften unserer schNuller-Jahre ab.
Es werden eine Reihe von Bot-Einsätzen benötigt, die noch gar nicht endgültig definiert sind. Guck dir WP:BA und den viele Jahre zurückreichenden Rückstau an, und es wird klar, dass wir keine unbeschäftigten Kapazitäten haben.
Das Grundproblem ist, dass die bisherigen Einbindungen der Vorlagen an jeder beliebigen Stelle des Wikitextes stehen können, aber über einer bestimmten Stelle der Seite drübergelegt dargestellt werden, wenn überhaupt.
Also auch ganz am Anfang eines Artikels, was manche Leute serienmäßig praktiziert hatten. Oder irgendwo mittendrin.
Mit der umseitigen Umsetzung werden die aber alle genau dort sichtbar, wo die Einbindung steht.
Also müssen jetzt alle Einbindungen im ANR daraufhin geprüft werden, ob dies an der vorgesehenen Stelle (ganz unten, vor Navileisten und Auszeichnungen, aber nach Einzelnachweisen usw.) erfolgte. Nicht-ANR muss selbst zusehen.
Es könnten sich aber noch Einbindungen innerhalb von Vorlagenprogrammierungen herausstellen, von denen wir noch gar nichts wissen, und die dann Infoboxen usw. zum Zerplatzen bringen würden.
Es ist eines von etlichen Überbleibseln unseres Krabbelalters, und wir müssen priorisieren, wann wir welche Aufgaben welcher Komplexität stemmen können.
Man hätte das nie nie nie so machen dürfen. Es ist eine absolute Scheiß-Idee gewesen, und es war damals schon bekannt gewesen, dass dies keine robuste und zukunftsfähige Lösung werden kann und deshalb verboten ist. Aber die Spielkinder hatten das aus der enWP kopiert, weil alles was die macht ist gut und vorbildlich, und haben uns diese instabile Spielerei beschert. Und damals saßen wir in der Buddelkiste und wussten nicht, ob es in drei Jahren noch eine Wikipedia geben würde; heute gehen wir auf drei Millionen Artikel zu und gelten als recht zuverlässiges Qualitätsmedium im Geschnatter der sozialen Hetzwerke.
Vector-2010
Das hat nichts mit Skins zu tun, weil es ja zukünftig ganz normaler Teil des ganz normalen Artikels werden wird, und damit für alle überall sichtbar.
Aber „Vector“ ist ein interessantes Stichwort; kann sein, dass es genau deshalb dieses Jahr einen Booster bekommen muss.
13:41, 15. Mär. 2021 (CET)
23:19, 15. Mär. 2021 (CET)
) 13:01, 27. Mär. 2021 (CET)
.png)
WP:CVU 22:25, 28. Mär. 2021 (CEST)
