Wikipedia:Umfragen/Technische Wünsche 2017/Sonstiges

Umfrage Technische Wünsche 2017

Rubrik „Sonstiges“

Lesen  •   Suchen  •   Bearbeiten  •   Wartung  •   Beobachten & Benachrichtigen  •   Soziales  •   Schwesterprojekte  •   Mediendateien  •   Projekte ehrenamtlicher Entwickler  •   Sonstiges

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

App für Windows 10 (Universal App)

Was ist das Problem?

Es gibt keine richtige Wikipedia-App für Windows, insbesondere Windows 10 Mobile. Die bestehende App in Windows-Store ist noch für Windows 8 geschrieben ehrlich gesagt fürchterlich.

Wen betrifft das Problem besonders?

Alle Windows 10-Nutzer (ca. 500 000 000)

Lösungsvorschlag

Eine Windows-App (auch Mobile)

Vorschlagende Person

Brunolehmann (Diskussion) 19:17, 29. Mai 2017 (CEST)

Diskussion

Es betrifft mitnichten alle Windows-10-Nutzer. Nur ein Bruchteil der Windows-10-mobile-Nutzer würde auf die Idee kommen eine App zu verwenden (aber selbst wenn es alle wären, wäre das bei den Marktanteilen egal) und die Desktop-Benutzer verwenden auch für andere Webseiten fast ausschließlich den Browser, was stark vermuten lässt, dass das bei Wikipedia nicht anders wäre. Deshalb sehe ich hierin keinen Nutzen. – KPFC 💬 21:27, 29. Mai 2017 (CEST)

Hallo Brunolehmann, erstmal Danke für den Wunsch! Zum Titel: Was hältst du von "Wikipedia-App für Windows 10 nutzbar machen" - dann wird Mitlesenden klarer, dass es schon eine App gibt, die aber nicht für Windows 10 optimiert ist. Für die Problembeschreibung wäre zusätzlich hilfreich, wenn du genauer schreibst, was du mit "ehrlich gesagt fürchterlich" genau meinst: Dass die App nicht für aktuellere Betriebssysteme angepasst ist? Oder bestimmte Funktionen in der App (wenn ja, welche)? Vielen Dank, --Birgit Müller (WMDE) (Diskussion) 13:30, 9. Jun. 2017 (CEST)

Wäre es nicht besser, die mobile Seite zu einer Progressive Web App auszubauen, die dann plattformunabhängig auf allen Systemen läuft? So könnte man sich die ganzen Anpassungsaufwände für die verschiedenen Plattformen sparen und stattdessen in eine Optimierung der App und neue Features stecken. // Martin K. (Diskussion) 22:11, 10. Jun. 2017 (CEST)

Eine "echte" Win10 App hätte den Vorteil, dass, wenn sie als Universal-App erstellt wurde, auf allen Windwos 10 OS laufen würde; egal ob Phone, Touchpad oder Desktop. Da lägen wir bei den Zahlen wieder im recht hohen Bereich. Aber, wenn sie einen wirklichen Mehrwert gegenüber dem Browser bieten soll, wäre das heftigst viel Arbeit .... Also IMHO macht das keinen Sinn. Wenn schon ein Programm für Lesen und komfortables Editieren, dann wirklich plattformübergreifend. (btw. Ich nutze auch Win10 Mobil und gehe weiterhin davon aus, dass irgendwann ein Programmierer mal eine brauchbare LeseApp entwickeln wird.) --Sophiston (Diskussion) 14:14, 29. Jun. 2017 (CEST)

Unterstützung

1.  Pro Brunolehmann (Einreichende Person)
2.  Pro Aerdnas 13:16, 21. Jun. 2017‎ (CEST)
3.  Pro Conny 14:01, 21. Jun. 2017 (CEST).
4.  Pro --Thomas Obermair 4 (Diskussion) 17:29, 28. Jun. 2017 (CEST)
5.  Neutral --Sophiston (Diskussion) 14:14, 29. Jun. 2017 (CEST)
6.  Kontra Die passende App für Wikipedia ist der Browser -gpf- (Diskussion) 10:00, 30. Jun. 2017 (CEST)
7.  Kontra Wie Gpf: Als Verfechter freien Wissens sollte sich Wikimedia den Walled Garden-Spielereien der verschiedenen Plattformanbieter soweit wie möglich verweigern und stattdessen eine gute plattformunabhängige Progressive Web App anbieten, die dann natürlich ebenfalls über die verschiedenen AppStores beworben werden könnte, aber eben nicht an diese gebunden ist. // Martin K. (Diskussion) 10:51, 30. Jun. 2017 (CEST)
8.  Kontra Per Gpf & Martin K. --Fixuture (Diskussion) 23:51, 1. Jul. 2017 (CEST)
9.  Kontra es sollte nicht für jede Plattform eine eigene App geben sondern eine universal App --Neigschmeckter (Diskussion) 13:10, 2. Jul. 2017 (CEST)
10.  Kontra Per Gpf & Martin K. Shaddim (Diskussion) 12:34, 9. Jul. 2017 (CEST)
    
    

Verbessertes Auffinden und Handling von Tools und Skripten

Was ist das Problem?

Es gibt zahlreiche, sicherlich schon jetzt vorhandene nützliche Tools und Skripte, die derzeit über benutzerdefiniertes css und .js eingebunden werden müssen. Diese Tools zu finden und zu aktivieren ist für nicht-Programmierer eine echte Herausforderung. Wer kein javascript oder css beherrscht, ist bei der Einbindung auf stumpfes Kopieren oder fremde RL-/ Admin-Hilfe angewiesen. Wenn die Einbindung so nicht klappt, ist man komplett aufgeschmissen oder doch auf fremde Hilfe angewiesen.

Wen betrifft das Problem besonders?

alle Poweruser ohne Programmierkenntnisse

Lösungsvorschlag

Wünschenswert wäre eine Art inhaltlich strukturierter "App-Store" für Tools und Skripte, wo Tools einfach aufzufinden und mit einem Klick, An/Aus-Schalter (ähnlich wie bei den Helferlein) zu aktivieren sind. Dabei sollte nicht nur das Basisskript installiert werden, sondern auch die Konfiguration des Skripts visuell möglich sein. Beispiel statt var zeigehilfe = true >> ein An/Aus-Schalter für Hilfetexte an/aus

Anmerkungen

Ich habe einen Vorschlag eingereicht der auch auf dieses Problem kurz eingegangen ist, als Lösungsansatz schreibe ich:

Wünsche, die aber schon irgendwie realisiert worden sind. Nur ist es dem Autor dies nicht bekannt. Dies ist ein Kommunikationsproblem. Wie mache ich den breiten Publikum, dem Leser und den Autor die diversen Hilfsmittel bekannt?

Die Tools die vorhanden sind sollten möglichst alle zentral erfasst werden. Mit einem Ampelsystem sollte die Nutzbarkeit für den Profi und Anfänger bewertet werden. Das ordnungsgemäße Funktionieren soll zeitnah "überwacht" werden. Der Hauptansprechpartner (also Entwickler) sollte benannt sein. Eine zentrale Anlaufstelle für Bugmeldungen sollte existieren (ich habe schon oft Bugmeldungen geschrieben, bei denen ich bis heute keine Rückmeldung bekommen habe). Die Seite Einstellungen/Helferlein sollte gepflegt werden (nicht funktionierende oder schlecht beschriebene Tools können entfernt werden). Auch sollten hilfreiche Tools (auch einfachste css-scripte) mit der Seite Einstellungen/Helferlein realisiert werden. --Atamari (Diskussion) 13:36, 11. Jun. 2017 (CEST)

Vorschlagende Person

Geolina ^{mente et malleo} ✎ 21:47, 29. Mai 2017 (CEST), Atamari (Diskussion) 13:36, 11. Jun. 2017 (CEST)

Diskussion

Und zwar nicht nur Skripte aus der deutschen Wikipedia. Ich dachte mir zum Beispiel bei der letzten WMF-Umfrage zu technischen Wünschen diverse Male „Mann, das gibt’s doch schon, wenn auch als Skript und dieses nicht im Enwiki.“ Oder siehe auch die Vorschau der Einzelnachweise: Das gab es schon längst als Skript von Schnark, wurde dann (völlig unabhängig?) vom WMDE-Team neu programmiert. Schnarks Skript ist immer noch ein wenig besser und zum Glück weiterhin benutzbar. — Speravir – 02:34, 30. Mai 2017 (CEST)

Volle Zustimmung. Die Aufteilung von Wikipedia:Tools ist zwar technisch erklärbar, für den Tool-Suchenden aber ziemlich unhandlich. --Flominator 08:33, 30. Mai 2017 (CEST)

Ich werfe mal den Link Wikipedia:Technik/Skin/Benutzerskripte in den Raum, quasi eine Fundgrube um mal zu schauen, was es schon alles gibt. Grundsätzlich wäre es aber schön, wenn Scripte a) benutzerfreundlich b) dokumentiert und c) einfach individuell konfigurierbar sind. Da nehme ich mich selbst nicht von aus *hust* Ein gutes Beispiel, wie es sein sollte, scheint mir Benutzer:Schnark/js/fliegelflagel.

Gruß --Schniggendiller Diskussion 18:13, 30. Mai 2017 (CEST)

Eigentlich wäre das Meta-Wiki für eine allgemeine Sammlung prädestiniert. Der Ort müsste dann halt popularisiert werden. — Speravir – 19:57, 30. Mai 2017 (CEST)

siehe auch Wikipedia:Umfragen/Technische_Wünsche_2017/Wartung#Besseres_Auffinden_UND_Nutzerfreundlichkeit_der_Tools -- ^Thomas 14:32, 31. Mai 2017 (CEST)

1. Anzahl: Es gibt mehrere Tausend Tools und Skripte und Gadgets, wenn man das mal auf Ebene des Meta-Projekts ansiedelt.
2. Wikipedia:Technik/Werkzeuge liefert einen ersten Überblick.
   • Die für uns wichtigsten und gebräuchlichsten sind dort dokumentiert (deutschsprachig).
3. Benutzerfreundlichkeit einzelner Werkzeuge: Jedes ist von in der Regel freiwilligen und außerdem lauter verschiedenen Leuten entwickelt worden.
   • Ob die angesichts der permanent erforderlichen Pflege überhaupt noch funktionieren würden, weiß niemand.
   • Ob die Leutchen sich die Mühe machten, das zu dokumentieren, ist sehr unterschiedlich.
   • Für das Meta-Projekt müssten auch alle Dokumentationen englischsprachig vorliegen.
   • Ob du hingegen auch eine deutschsprachige Doku erhältst, wage ich zu bezweifeln.
   • Ob die benutzerfreundlich, gar „visuell“ (interaktiv) konfigurierbar wären, steht dahin. Meine Peilung: benutzerfreundlich interaktiv konfigurierbar sind definitiv weniger als ein Prozent.
   • Es obliegt jedem einzelnen Entwickler, sowas zu realisieren; und ich bekomme weltweit nicht mal die Finger einer Hand abgezählt an Mädels und Jungs, die sowas können.
4. Internationalisierung
   • Das bedeutet, dass im Werkzeug die sprachspezifischen und auch projektspezifischen Textbausteine an einer zentralen und ggf. unabhängigen Stelle gesammelt sind, damit eine Veränderung am prozeduralen Teil (der eigentlichen Programmierung) ohne nachträgliches Einflicken der örtlichen Übersetzungen an einem Dutzend Stellen möglich ist. Insbesondere soll leicht ein neues Sprachprofil hinzugefügt werden können.
   • Damit kann es sich an die Projekt- oder gar Benutzersprache anpassen; idealerweise sogar spontan die Oberflächensprache im Rahmen der bekannten Übersetzungen wechseln.
   • Ein einstelliger Prozentsatz unserer externen Dingse sind lokalisierbar; eher ein Prozent denn fünf Prozent.
   • Was in der englischsprachigen Wikipedia entsteht, ist praktisch nie auf fremde Sprachen vorbereitet; es können alle Benutzer Englisch, wer es nicht kann muss es halt lernen, zu viel Arbeit mit so Gedöns. Die deutsch- und sonstwiesprachigen Entwickler sind aber meist auch sehr bequem; sie bieten das in ihrer Muttersprache an, ohne auch nur eine englischsprachige Version vorzusehen, und ein rein portugiesisches, französisches, polnisches Werkzeug ist für einen globalen AppStore im Meta-Wiki völlig unbrauchbar. Die Dokus gibt es natürlich auch nur in der Muttersprache.
5. Es gibt keine Sicherheitskontrolle oder Qualitätssicherung für private Werkzeuge.
   • Würde man die an einen AppStore der WMF anzulegenden Maßstäbe hinsichtlich Dokumentation, Funktionalität, Sicherheit, Benutzungsfreundlichkeit durchsetzen, dann reduziert sich die vierstellige Zahl der Tools auf zweistellig, ist dafür schön übersichtlich, aber kaum noch was dabei, das du brauchen könntest.
   • WMDE wird hier wenig dran programmieren können.

VG --PerfektesChaos 10:30, 1. Jun. 2017 (CEST)

Unterstützung

1.  Pro Geolina163 (Einreichende Person)
2.  Pro Atamari (Einreichende Person)
3.  Pro -- ^Thomas 10:24, 20. Jun. 2017 (CEST) (als auch vorschlagender mit einem ähnlichem Wunsch [1])
4.  Pro --FNDE 11:29, 20. Jun. 2017 (CEST) sehr schöne Idee
5.  Pro --Wilhelm Zimmerling PAR (Diskussion) 14:37, 20. Jun. 2017 (CEST)
6.  Pro --Krokodilgemüse (Diskussion) 15:49, 20. Jun. 2017 (CEST)
7.  Pro --Noobius2 (Diskussion) 16:21, 20. Jun. 2017 (CEST)
8.  Pro // Martin K. (Diskussion) 16:43, 20. Jun. 2017 (CEST)
9.  Pro --Claell (Diskussion) 19:39, 20. Jun. 2017 (CEST)
10.  Pro --Till.niermann (Diskussion) 21:01, 20. Jun. 2017 (CEST)
11.  Pro --  Sir Gawain Disk. 21:17, 20. Jun. 2017 (CEST)
12.  Pro -- Silke (Diskussion) 15:43, 21. Jun. 2017 (CEST)
13.  Pro -- Michi 19:54, 21. Jun. 2017 (CEST)
14.  Pro Mike Krüger, ?! 09:32, 22. Jun. 2017 (CEST)
15.  Pro --Jossi (Diskussion) 14:10, 22. Jun. 2017 (CEST)
16.  Pro --MGChecker – (📞| 📝| ) 16:40, 22. Jun. 2017 (CEST)
17.  Pro --GodeNehler (Diskussion) 23:20, 22. Jun. 2017 (CEST)
18.  Pro --Nichtich (Diskussion) 22:23, 23. Jun. 2017 (CEST)
19.  Pro --Chiborg (Diskussion) 23:15, 23. Jun. 2017 (CEST)
20.  Pro --Flominator 10:55, 24. Jun. 2017 (CEST)
21.  Pro --DianeAnna (Diskussion) 20:09, 25. Jun. 2017 (CEST)
22.  Pro -- Michael (Diskussion) 12:37, 27. Jun. 2017 (CEST)
23.  Pro --Uwe Rohwedder (Diskussion) 17:30, 27. Jun. 2017 (CEST)
24.  Pro --Incabell (Diskussion) 18:06, 27. Jun. 2017 (CEST)
25.  Pro --Kein Einstein (Diskussion) 16:00, 28. Jun. 2017 (CEST)
26.  Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)
27.  Pro --Ak ccm (Diskussion) 10:19, 29. Jun. 2017 (CEST)
28.  Pro --1971markus ^{⇒ Laberkasten ...} 23:31, 29. Jun. 2017 (CEST)
29.  Pro —SDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)
30.  Pro --Sebastian Wallroth 13:48, 30. Jun. 2017 (CEST)
31.  Pro — Marcus Cyron Reden 02:13, 1. Jul. 2017 (CEST)
32.  Pro —DerHexer (Disk., Bew.) 23:06, 1. Jul. 2017 (CEST)
33.  Pro --Mabschaaf 23:09, 1. Jul. 2017 (CEST)
34.  Pro Ein wenig Meta, da man über Umfragen wie diese häufig viele neue Tools/Scripts findet. Jedenfalls wäre das wirklich sehr nützlich. Das war auch das Ziel meines Posts hier (derzeit archiviert; werde den aber wohl irgendwann demnächst mal reviven und versuchen mich etwas mehr darum zu kümmern...zumindest sofern es niemand anderes tut): "Please create documentary pages for your scripts and categorize them". Der Lösungsvorschlag hier ist natürlich die bessere Lösung als bloße, indexierte Dokumentationen und Kategorisierung etc. Allerdings könnte er darauf aufbauen. Das vorgeschlagene, gestreamlinte Toolsystem könnte es anderen Nutzern dann auch erleichtern T/S weiterzuentwickeln, Derivate zu erstellen, Dokumentationen und Statistiken auf einheitlichem Weg zu featuren, Betatesting zu betreiben, Nutzerdiskussionen und -umfragen zu erstellen, T/S zu "vererben" bzw an andere zu übergeben, Tools/Scripts in Wikimedia einzubauen, T/S bekannter zu machen und anderweitig zu fördern, Anwendungsmöglichkeiten zu erweitern, Updates zu checken/verifizieren, T/S auffindbar zu machen, etc etc. (Und wie bei vielen Wikimedia Features könnte dieses System oder zumindest dessen Aufbau dann später auch auf andere Bereiche ausgeweitet bzw. angewendet werden − zB auf FOSS im allgemeinen) --Fixuture (Diskussion) 00:38, 2. Jul. 2017 (CEST)
35.  Pro --Sitacuisses (Diskussion) 15:20, 2. Jul. 2017 (CEST)
36.  Pro --Varina (Diskussion) 16:35, 2. Jul. 2017 (CEST)
37.  Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:31, 2. Jul. 2017 (CEST)
38.  Pro --Zaccarias (Diskussion) 20:10, 2. Jul. 2017 (CEST)
39.  Pro -- Mr N (Diskussion) 23:59, 2. Jul. 2017 (CEST)
40.  Pro ーGhilt (Diskussion) 09:52, 4. Jul. 2017 (CEST)
41.  Pro --Haplochromis (Diskussion) 19:46, 11. Jul. 2017 (CEST)
    
    

Konsistenz der Koordinaten auf der OSM-Karte

Was ist das Problem?

• Ruft man beispielsweise den Artikel Sellapass auf und lässt sich durch Klick auf das grüne Icon oben rechts im Artikel die OSM-Karte anzeigen, sieht man westlich vom Pass einen See und etwa 500 m nordwestlich vom See einen roten Marker in der Landschaft. Dieser Marker verwendet Koordinaten aus der Liste der Kulturgüter in Guttannen, die schon vor Monaten korrigiert worden sind, aber der Marker steht immer noch am falschen Ort und verwendet die alten Koordinaten. Die Staumauer befindet sich nicht dort, wo sie angezeigt wird, und hat auch nichts mit dem See daneben zu tun.

Wen betrifft das Problem besonders?

Betroffen sind alle Benutzer, die sich Karten anzeigen lassen und dabei die Marker am richtigen Ort sehen wollen.

Lösungsvorschlag

• Scheint ein Problem mit irgendeinem Cache zu sein.
  Vorschlagende Person

2A02:1206:4585:1120:4DB8:626C:6B5B:D800 07:39, 30. Mai 2017 (CEST)

Diskussion

Der Wunsch ergänzt gewissermaßen diesen hier. … «« Man77 »» (A) wie Autor 20:11, 3. Jun. 2017 (CEST)

Dieser Wunsch besteht bereits seit der 2015er Umfrage und gehört zu den Topwünschen (er hat die höchste Punktzahl der noch nicht in Arbeit befindlichen Wünsche). Wie auf der Seite des Wunsches zu lesen ist, ist seine Bearbeitung von der Zusammenarbeit mit dem Wart des/der entsprechenden Tools, Benutzer Kolossos abhängig. Wenn ich die entsprechenden Seite in der Technik-Rubrik richtig verstehe, basiert WIWOSM (Eigenbeschreibung hier) und damit auch das Unterprojekt OpenStreetMap des WikiProjektes Georeferenzierung bei Punktkoordinaten auf der – in den Wikimedia Tool Labs gehosteten – Anwendung (dem Tool) Wikipedia-World (Anwendungsbeschreibung, zu den einzelnen Untertools siehe hier, Listeneintrag in Wikimedia Tool Labs). Gemäß der zuvor verlinkten Beschreibung von Wikipedia-World soll die Extraktion der Koordinaten an andere Benutzer ausgelagert sein (Benutzer Dispenser oder Benutzer Dschwen und früher Benutzer Stefan Kühn). Wenn ich das richtig verstehe erfolgt die Weiterverarbeitung der Daten im Tool Wikipedia-World durch dessen Warte, Benutzer Kolossos und wikitech:User:Retsam – dies scheint seit November 2015 nicht mehr erfolgt zu sein. Die Beschreibung besagt weiter, dass jeder mit einem WMFLAbs-Benutzerkonto die Datenbank u_kolossos auf dem osmdb-Datenbankserver lesen und nutzen können soll. Leider sind die Links auf die Quelltexte in der Anwendungsbeschreibung für Wikipedia-World defekt (bis auf den Link zu en:MediaWiki:Gadget-OSM.js). Wenn sich das für die Aktualisierung des Wikipedia-Overlays für OpenStreetMap (Tool wp-world/umkreis) und von WIWOSM erforderliche Prozedere irgendwie automatisieren ließe, wäre das wohl am besten. Wenn es nicht anders geht, wäre dieser Wunsch ein erstrangiger Kandidat für die Anwendung der Right to fork policy der Wikimedia Tool Labs (siehe auch „Punkt #3“ des Wunsches 7 „Digitales Erbe“ (in dieser Rubrik)). --X:: black ::X (Diskussion) 15:14, 10. Jun. 2017 (CEST), aktualisiert 23:37, 10. Jun. 2017 (CEST), 13:24, 11. Jun. 2017 (CEST) und 12:25, 12. Jun. 2017 (CEST)

Unterstützung

1.  Pro 2A02:1206:4585:1120:4DB8:626C:6B5B:D800 (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 10:53, 19. Jun. 2017 (CEST)
3.  Pro тнояsтеn ⇔ 11:13, 20. Jun. 2017 (CEST)
4.  Pro --Bungert55 (Diskussion) 11:37, 20. Jun. 2017 (CEST)
5.  Pro --XPosition (Diskussion) 13:57, 20. Jun. 2017 (CEST)
6.  Pro --Wilhelm Zimmerling PAR (Diskussion) 14:34, 20. Jun. 2017 (CEST)
7.  Pro -- «« Man77 »» (A) wie Autor 14:53, 20. Jun. 2017 (CEST)
8.  Pro DCB (Diskussion • Bewertung) 15:52, 20. Jun. 2017 (CEST)
9.  Pro --HerrAdams (D) 18:45, 20. Jun. 2017 (CEST)
10.  Pro Hermannh (Diskussion) 22:17, 20. Jun. 2017 (CEST)
11.  Pro --Bluemel1 (Diskussion) 14:00, 21. Jun. 2017 (CEST)
12.  Pro Mike Krüger, ?! 14:04, 22. Jun. 2017 (CEST)
13.  Pro --Atamari (Diskussion) 23:05, 23. Jun. 2017 (CEST)
14.  Pro --Michi Baer (Diskussion) 06:10, 24. Jun. 2017 (CEST)
15.  Pro --Abubiju (Diskussion) 12:20, 24. Jun. 2017 (CEST)
16.  Pro --@Mtthshe: (unvollständig signierter Beitrag von Mtthshe (Diskussion | Beiträge) 15:20, 25. Jun. 2017 (CEST)) Mtthshe 15:20, 25. Jun. 2017 (CEST)
17.  Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)
18.  Pro --Ak ccm (Diskussion) 10:20, 29. Jun. 2017 (CEST)
19.  Pro --alexrk (Diskussion) 16:10, 26. Jul. 2017 (CEST)
    
    

Eigene Top-Level-Domain für alle Wikipedias

Was ist das Problem?

Die Wikipedia URLs sind ja grundsätzlich recht lang (xx.wiki.x.io/wiki/)). Es wäre sinnvoll eine Top-Level-Domain (z.B. .wp) als forwarder (nicht als shortener) für Wikipedias zu betreiben.

de.wp/Top-Level-Domain

wäre ja viel kürzer als :

de.wiki.x.io/wiki/Top-Level-Domain

Das wichtigste wäre dass man die kurze URL noch selber lesen (was mit bitly und co nicht möglich ist) und die URL, ähnlich wie ein hashtag oder einem interwiki, in den Satz einbauen kann, anstatt eine (short)-URL anzuhängen (egal ob auf twitter oder einer mail)

> Der Legende nach ist unter dem #Grabhügel https://de.wp/Raknehaugen ein König zwischen zwei weißen Pferden begraben worden.

anstatt :

> Der Legende nach ist unter dem #Grabhügel Raknehaugen ein König zwischen zwei weißen Pferden begraben worden. https://de.wiki.x.io/wiki/Raknehaugen

Wen betrifft das Problem besonders?

Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.

Lösungsvorschlag

Betreiben müsste diese TLD vermutlich die Wikimedia Foundation, ich denke technisch wäre das möglich.

Die ICANN will anscheinend 185.000 $ für eine sponsored TLD, aber vielleicht gibt es die TLD für ein nonprofit günstiger.

Ich bin darauf hingewiesen worden das die ICANN 2-stellige TLDs nur an Länder und die EU (.eu) vergibt, aber vielleicht bekommt man für eine sooo große "Webseite" und zentrale Ressource im Netz eine Ausnahme;)

Diese kurzen URLs sollen nicht die klassische URL (de.wiki.x.io/wiki/Top-Level-Domain) als canonical URL ersetzen, sondern nur darauf weiterleiten.

Anmerkungen

Ich habe diesen Vorschlag schon einmal auf der VereinDE-l gestellt.

Auf mediawiki.org gibt es einen RFC für einen URL shortener, dieser würde aber "unlesbare", wenn auch kurze, shortlinks erzeugen (wi.ki/a4Kd anstatt de.wp/Raknehaugen).

Vorschlagende Person

vanGore 10:33, 4. Jun. 2017 (CEST)

Diskussion

Siehe auch Wikipedia:Fragen zur Wikipedia/Archiv/2015/Woche 27#dewp.org als Linkkürzungsdienst? samt der zahlreichen dortigen Links. — Speravir – 00:31, 16. Jun. 2017 (CEST) Egal, ob zwei oder dreistellig. Die WIKI sollte eine eigene TLD erhalten ! Das gibt dem Laden wieder mal ein kleinen Schub.

Unterstützung

1.  Pro VanGore (Einreichende Person)
2.  Pro  _hugarheimur 09:02, 20. Jun. 2017 (CEST) das entspricht meinem Vorschlag von 2015
3.  Pro --FNDE 11:31, 20. Jun. 2017 (CEST)
4.  Pro Mit der Gewährleistung, dass NUR zum jeweiligen WP-Angebot/Artikel weitergeleitet werden kann: ja! --emha ^d℩^b 13:54, 20. Jun. 2017 (CEST)
5.  Pro Zellmer (Diskussion) 15:42, 20. Jun. 2017 (CEST)
6.  Pro --Bluemel1 (Diskussion) 14:01, 21. Jun. 2017 (CEST)
7.  Pro sk (Diskussion) 17:15, 21. Jun. 2017 (CEST)
8.  Pro -- Michi 19:54, 21. Jun. 2017 (CEST)
9.  Pro --@Bwilke: (unvollständig signierter Beitrag von Bwilke (Diskussion | Beiträge) 20:07 Uhr, 21. Juni 2017) Bwilke
10.  Pro --Kenny McFly (Diskussion) 20:00, 21. Jun. 2017 (CEST)
11.  Pro --Avonsoda 20:45, 21. Jun. 2017 (CEST)
12.  Pro --Jossi (Diskussion) 14:11, 22. Jun. 2017 (CEST)
13.  Pro --MGChecker – (📞| 📝| ) 16:56, 22. Jun. 2017 (CEST)
14.  Pro --Eriom (Diskussion) 12:19, 23. Jun. 2017 (CEST)
15.  Pro -- Freddy2001 ^DISK 12:27, 24. Jun. 2017 (CEST)
16.  Pro --RotWeisserHai (Diskussion) 14:05, 24. Jun. 2017 (CEST)
17.  Pro --Chstdu (Diskussion) 15:26, 26. Jun. 2017 (CEST)
18.  Pro --Ak ccm (Diskussion) 15:16, 28. Jun. 2017 (CEST)
19.  Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)
20.  Pro --Ak ccm (Diskussion) 10:22, 29. Jun. 2017 (CEST)
21.  Pro --Sophiston (Diskussion) 14:21, 29. Jun. 2017 (CEST)
22.  Pro KPFC 💬 23:14, 29. Jun. 2017 (CEST)
23.  Pro —SDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)
24.  Pro --Sebastian Wallroth 13:51, 30. Jun. 2017 (CEST)
25.  Pro --Fixuture (Diskussion) 23:56, 1. Jul. 2017 (CEST)
26.  Pro --Linopolus (Diskussion) 11:12, 2. Jul. 2017 (CEST)
27.  Kontra -- Der Nutzen ist doch eher sehr gering... PAB (Diskussion) 20:49, 2. Jul. 2017 (CEST)
28.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:57, 2. Jul. 2017 (CEST)
    
    

Keine Darstellungsprobleme bei Vorlagen ab einer bestimmten Datengröße

Was ist das Problem?

Viele vorlagenbasierte Listen müssen aufgeteilt werden, weil ab einer bestimmten Größe nicht mehr alle Vorlagen angezeigt werden. Hier noch ein Beispiel wie eine vorlagenbasierte Tabelle vor der Teilung aussieht (siehe Ende der Liste)

Wen betrifft das Problem besonders?

Autoren die vorlagenbasierte Tabellen erstellen

Lösungsvorschlag

Erweiterung der Datengröße

Anmerkungen

diskussion auf nutzerseite von Hgzh zu dem Thema

Vorschlagende Person

 ^Thomas 22:57, 4. Jun. 2017 (CEST)

Diskussion

Lieber Z thomas, könntest du unter „Was ist das Problem?“ noch ein Beispiel für eine solche vorlagenbasierte Liste anbringen? Danke und schöne Grüße -- Johanna Strodt (WMDE) (Diskussion) 12:03, 7. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): hast recht :-) erledigt. ich hab vorlagenbasiertes beispiel eingefügt mit der nicht funktionierenden Darstellung -- ^Thomas 13:01, 7. Jun. 2017 (CEST)

Hallo Z thomas, sehr anschaulich. :) Vielen Dank! -- Johanna Strodt (WMDE) (Diskussion) 19:38, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 10:58, 19. Jun. 2017 (CEST)
3.  Pro --Geolina ^{mente et malleo} ✎ 17:50, 19. Jun. 2017 (CEST)
4.  Pro  _hugarheimur 09:03, 20. Jun. 2017 (CEST)
5.  Pro --FNDE 11:31, 20. Jun. 2017 (CEST)
6.  Pro DCB (Diskussion • Bewertung) 15:55, 20. Jun. 2017 (CEST)
7.  Pro --Wilhelm Zimmerling PAR (Diskussion) 16:16, 20. Jun. 2017 (CEST)
8.  Pro --Atamari (Diskussion) 23:07, 23. Jun. 2017 (CEST)
9.  Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)
10.  Pro —DerHexer (Disk., Bew.) 23:10, 1. Jul. 2017 (CEST) Weiteres Beispiel.
    
    

Umwandeln von strukturierten Daten in Wikitabellensyntax

Was ist das Problem?

Zahlreiche Datenquellen sind in Tabellenform vorhanden, z. B. Denkmallisten. In de WP werden diese Inhalte oft in Tabellenform in Wikisyntax dargestellt. Dabei werden Tabelleninhalte aus einzelne Zellen der Datenquelle zusammengefasst oder nach bestimmten Regeln getrennt. Dies ist oft einfache zeitintensive Kopierarbeit ohne Schöpfungshöhe, die aber fehleranfällig ist, z. T. kann man dies mit Skripten in Excel vereinfachen.

Wen betrifft das Problem besonders?

Autoren

Lösungsvorschlag

Ein Hilfsmittel mit dem beliebig strukturiert aufgebaute Datenquellen in Wikitabellensyntax (Vorlagen oder Wikitable) umgewandelt werden. Der Nutzer gibt vor, welcher Tabelleninhalt der Datenquelle zu welchem Tabelleneintrag in der Wikisyntax werden soll. Es muss möglich sein, Datenfelder zu kombinieren und Tabelleninhalte zu trennen (z. B. nach Steuerzeichen wie Semikolon)

Anmerkungen

Ich habe dies für die Technischen Denkmallisten in Sachsen (z. B. Liste der technischen Denkmale im Landkreis Nordsachsen) und den Großteil der Kulturdenkmallisten in den Landkreisen Bautzen und Görlitz (z. b. Liste der Kulturdenkmale in Oppach) per Skript aus Exceltabellen umwandeln lassen

Vorschlagende Person

 ^Thomas 10:45, 9. Jun. 2017 (CEST)

Diskussion

Also einen Import-Export-Filter für gängige Formate (CSV und andere). Wie könnte das Ablaufen? Ein Gadget öffnet einen Filerequester zum Laden der Tabellendatei und wandelt in Wikitext um. Oder gar zusätzlich mit Drag&Drop, Tabelle aus dem Excel in der Zwischenablage und in einem Import-Feld abgelegt. Dann wird die Wikitext-Tabellenstruktur eingebunden. --Atamari (Diskussion) 13:49, 11. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 14:50, 19. Jun. 2017 (CEST)
3.  Pro --FNDE 11:34, 20. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 15:57, 20. Jun. 2017 (CEST)
5.  Pro --Wilhelm Zimmerling PAR (Diskussion) 16:17, 20. Jun. 2017 (CEST)
6.  Pro --Bluemel1 (Diskussion) 14:02, 21. Jun. 2017 (CEST) (vor allem Tabs in .txt- oder .rtf-Dateien auslesen)
7.  Pro --Thingol (Diskussion) 16:12, 21. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)
9.  Pro --Sebastian Wallroth 13:52, 30. Jun. 2017 (CEST)
10.  Pro --Fixuture (Diskussion) 23:59, 1. Jul. 2017 (CEST)
11.  Pro hätte ich schon mehrfach brauchen können Shaddim (Diskussion) 12:32, 9. Jul. 2017 (CEST)
    
    

Einträge in Wikidata vornehmen: Aufheben der unterschiedlichen Verhaltens der Anwendung bei gleichen Abläufen

Was ist das Problem?

Die Software verhält sich bei gleichen Abläufen unterschiedlich: Beim Hinzufügen von Sprachlinks zu bestehenden Datenobjekten öffnet sich manchmal ein kleines Fenster in dem der neue Sprachlink eingetragen werden kann, manchmal wird man direkt zum Wikidataobjekt in Wikidata geleitet und muss auf dieser Seite die Stelle suchen, wo der Link eingetragen werden soll (siehe dazu Diskussion auf FzW (Oktober 2015) Diese verschiedenen Abläufe für gleiches sind störend und nicht nutzerfreundlich.

Wen betrifft das Problem besonders?

Autoren

Lösungsvorschlag

Software soll sich einheitlich verhalten

Vorschlagende Person

 ^Thomas 11:00, 9. Jun. 2017 (CEST)

Diskussion

Klingt sehr danach, das JavaScript bei dir nicht korrekt ausgeführt wird oder zu langsam ist (wie von Raymond erklärt) und daher die JavaScript-Funktionen (Klick auf blauen Stern oder das Fenster) nicht funktionieren und die Funktion für Benutzer ohne JavaScript (Extra-Bestätigung oder Bearbeitung auf Wikidata) angeboten werden. Falls es nicht korrekt ausgeführt wird, kann ein Blick in die WP:JS#Fehlerkonsole hier aufschluss geben. Bei den zu langsamen Skripten lässt sich vermutlich nicht viel machen, da es auch von anderen Skripten auf der Seite abhängt. Der Umherirrende 21:59, 12. Jun. 2017 (CEST)

@Z thomas: Danke für diesen Wunsch! Ein erster Blick auf diesen Wunsch im Team hat ergeben, dass er so jetzt zu umfangreich ist. Allerdings sind beide von dir genannten Probleme bereits bekannt. An Beispiel 1 wird auch bereits gearbeitet. Wenn du den Wunsch trotzdem einreichen möchtest, grenze ihn bitte stärker ein, z.B. indem du dich auf Beispiel 2 konzentrierst. Falls sich der Wunsch durch den Kommentar vom Unherirrenden erledigt hat, kannst du ihn natürlich auch verschieben nach Wikipedia:Umfragen/Technische_Wünsche_2017/Bereits_umgesetzte_Wünsche. -- Beste Grüße und vielen Dank! Johanna Strodt (WMDE) (Diskussion) 13:56, 15. Jun. 2017 (CEST)

@Umherirrender, Johanna Strodt (WMDE): danke für den Hinweis. In den meisten Fällen funktioniert die Sternchenvariante. nur manchmal nicht am selben rechner mit dem selben browser. ich weiß nicht, ob mein problem so verstanden wurde, dass es nicht immer auftritt. wenn daran gearbeitet wird, ist gut. dann bleibt nur Punkt 2 bestehen. falls es nciht so verstanden wurde, dann sollte er bestehen bleiben. du kannst dann gern punkt 1 zu den umgesetzten verschieben. viele grüße -- ^Thomas 15:32, 15. Jun. 2017 (CEST)

@Z thomas: Ja, es wurde so verstanden, dass es nicht immer auftritt. Ich habe Beispiel 1 rausgenommen und den Wunschtitel angepasst und hoffe, dass es so okay ist für dich. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 23:14, 18. Jun. 2017 (CEST)

@Johanna Strodt (WMDE):, ja, es tritt nicht immer auf. danke für's anpassen. beispiel 1 ist ja in der lösung. deshalb ist es ok. gruß -- ^Thomas 08:26, 19. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro --Wilhelm Zimmerling PAR (Diskussion) 14:32, 20. Jun. 2017 (CEST)
3.  Pro (nicht signierter Beitrag von Ziko (Diskussion | Beiträge) 16:04, 21. Jun. 2017 (CEST‎)
4.  Pro --Nichtich (Diskussion) 22:23, 23. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)
   
   

Share my Edit

Was ist das Problem?

Wenn man wüsste, dass Freund X, Bekannter Y und Kollege Z auf Wikipedia editiert, würden vielleicht viele ihre Hemmungen abbauen und es auch einmal probieren.

Viele Editoren sind stolz auf ihre neusten Artikel oder auf ihre hochgeladenen Bilder. Einige würden vielleicht gerne ihre Facebook-Freunde oder Twitter-Follower wissen lassen, dass sie auf Wikipedia – oder Commons – einen tollen Beitrag verfasst haben, einen guten Artikel geschrieben haben, ein sehenswertes Bild hochgeladen haben.

Mit einer einfachen Linkfunktion könnte man diese Editoren unterstützen, stolz über ihren letzten Edit auf Social Media zu berichten. Und wenn Editoren in ihrem Umfeld übers Editieren posten, lassen sich wohl neue Editoren gewinnen.

Wen betrifft das Problem besonders?

alle User

Lösungsvorschlag

Gibt wohl viele Ansätze. Natürlich muss die Funktion de-/aktivierbar sein je nach Wunsch. Vielleicht ein Häkchen neben dem Änderungen speichern, dass man in einem nächsten Schritt den Edit noch teilen möchte, so dass mit dem Speichern ein Pop-Up aufgeht mit einem Dialog, der einen durchs Publizieren auf Facebook, Twitter oder wo auch immer führt.

Vorschlagende Person

Lars (User.Albinfo) 22:43, 11. Jun. 2017 (CEST)

Diskussion

Nur um den Schritt des Kopierens der URL zu umgehen ? Wer einen Artikel geschrieben hat, wird ihn auch als Link teilen können. Aber trotzdem gibt es von mir ein Pro. Für Leser wäre es gut, wenn sie sehr schnell "sharen" könnten. Insbesondere um FB-User zu adressieren, die ja nicht so selten sehr viel Informationen aus dem FB-Universum beziehen. Dies wäre vielleicht ein kleiner Schritt zu mehr Nicht-Fake-Wissen im FB-Universum, wenn es gelänge hier eine höhere Informationsdichte zu erreichen. --Sophiston (Diskussion) 17:44, 30. Jun. 2017 (CEST) (gestern sig vergessen, sorry)

Unterstützung

1.  Pro Albinfo (Einreichende Person)
2.  Pro --سلوك Saluk 14:48, 20. Jun. 2017 (CEST)
3.  Pro Hermannh (Diskussion) 22:22, 20. Jun. 2017 (CEST)
4.  Pro sk (Diskussion) 17:16, 21. Jun. 2017 (CEST)
5.  Pro --Avonsoda 20:45, 21. Jun. 2017 (CEST)
6.  Pro --RotWeisserHai (Diskussion) 14:06, 24. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)
8.  Pro --Ak ccm (Diskussion) 10:25, 29. Jun. 2017 (CEST)
9.  Pro --Sophiston (Diskussion) 14:33, 29. Jun. 2017 (CEST)
10.  Pro —SDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth 13:53, 30. Jun. 2017 (CEST)
12.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:59, 2. Jul. 2017 (CEST)
13.  Pro für bessere integration von Wikipedia in das gesamte Internet.  Kontra gegen "Facebookisierung" es soll um den content gehen nicht um die Autoren und die nicht-anynoymen natuerlichen personen. Keine Selkbstdarstellung über Wikipedia! Ein stärkeres Sichtbarmachen der Person & Fokusverschiebung (was ja mit einem share über Facebook passieren würde) würde Diskussionen verunsachlichen & persönlichen stress verursachen & die Ehrgeizlinge kränken: "ein revert meines tollen Beitrags der auf facebook verlinkt ist? GGRRRRRR ...Krieg!!!" Gegenteil: reddit-modell, verstärkte enkopplung von natuerlicher perosn und internet personalie welche als WP-author arbeiten. Reduziert Stress, ernsthaftigkeit wird bei reddit über andere massnahmen erzeugt. Shaddim (Diskussion) 12:32, 9. Jul. 2017 (CEST)
    
    

Nutzeroberflächen-Bugs beheben

Was ist das Problem?

Es gibt leider immer noch Bugs im Vektor-Skin, die insbesondere bei sich ändernden Bildschirmauflösungen zu seltsamen Verhalten führen und Darstellungsfehler führen. Z.B.: Die Konkretisierung in kursiver Formatierung wurde von Johanna Strodt (WMDE) ergänzt, damit der Wunsch im Rahmen dieses Projekts umgesetzt werden kann:

Behoben werden sollen die folgenden Bugs:

• Die verschiedenen Menu-Leisten oben verhalten sich bei kleineren Bildschirmauflösungen seltsam:
  • Buttons fahren rein und raus (gerne auch mal immer wieder)
  • Die Buttons neben dem Suchfeld brechen um und überlagern die Überschrift.
• Das Bannerfeld oben wird nachgeladen und erst später dann aufgespannt. Dadurch verspringt dann der komplette Inhalte, wodurch man beim Lesen auf die falschen Links klickt.

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Reparatur und responsive Anpassung des Navigationsbereichs im Vector-Skin, Testen

Vorschlagende Person

Martin K. (Diskussion) 12:01, 11. Jun. 2017 (CEST)

Diskussion

@Martin Kraft: Danke für den Wunsch! Alle Bugs werden wir im Rahmen des Projekts Technische Wünsche nicht beheben können, und „einige Bugs beheben“ wäre als Wunsch noch zu vage, weil wir dann nicht sagen könnten, wann der Wunsch abgeschlossen ist. Der Wunsch gehört daher eigentlich in die Rubrik „Wünsche außerhalb des Projektrahmens“. Alternativ kannst du ihn aber konkretisieren, indem die Problembeschreibung auf drei Bugs umformulierst, die deiner Ansicht nach behoben werden müssen. Wenn du das möchtest, wäre dafür noch Zeit bis Sonntagnachmittag, weil die Abstimmung am Montag beginnt. Ich verschiebe diesen Wunsch außerdem erst mal nach „Sonstiges“, wie hier auf der Rückseite angekündigt. -- Danke und viele Grüße, Johanna Strodt (WMDE) (Diskussion) 19:33, 16. Jun. 2017 (CEST)

@Martin Kraft: Nach „Sonstiges“ verschoben. -- Johanna Strodt (WMDE) (Diskussion) 19:35, 16. Jun. 2017 (CEST)

@Martin Kraft: Wenn du noch umformulieren möchtest, dann absolut spätestens bis Montag (19. Juni) um 9.00 Uhr. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 23:05, 18. Jun. 2017 (CEST)

@Martin Kraft: Ich habe einen Satz eingefügt, der deinen Wunsch so konretisiert, dass er drin bleiben kann. Ich hoffe, so passt das für dich. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:27, 19. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro -- X:: black ::X (Diskussion) 11:08, 19. Jun. 2017 (CEST)
3.  Pro  _hugarheimur 09:04, 20. Jun. 2017 (CEST)
4.  Pro --Wilhelm Zimmerling PAR (Diskussion) 14:30, 20. Jun. 2017 (CEST)
5.  Pro DCB (Diskussion • Bewertung) 15:57, 20. Jun. 2017 (CEST)
6.  Pro --HerrAdams (D) 18:47, 20. Jun. 2017 (CEST)
7.  Pro (nicht signierter Beitrag von Ziko (Diskussion | Beiträge) 16:03, 21. Jun. 2017 (CEST‎)
8.  Pro -- Freddy2001 ^DISK 12:28, 24. Jun. 2017 (CEST)
9.  Pro -- Tilman Kluge 23:55, 25. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 17:32, 28. Jun. 2017 (CEST)
11.  Pro --Ak ccm (Diskussion) 10:26, 29. Jun. 2017 (CEST)
12.  Pro KPFC 💬 23:16, 29. Jun. 2017 (CEST)
13.  Pro --Sebastian Wallroth 13:54, 30. Jun. 2017 (CEST)
14.  Pro —DerHexer (Disk., Bew.) 23:12, 1. Jul. 2017 (CEST)
15.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 23:01, 2. Jul. 2017 (CEST) längst überfällig
    
    

Baukasten Nutzeroberfläche

Was ist das Problem?

Die Nutzeroberfläche von Vorlagen, Portal- und Metaseiten ist gestalterisch und funktional sehr heterogen und funktioniert oft nicht richtig auf verschiedenen Auflösungen oder mobilen Endgeräten.

MMn liegt das vor allem daran, dass es keinen übersichtlich strukturierten und gut dokumentierten Baukasten von Gui-Elementen gibt, der langfristig gewartet und getestet wird. Stattdessen kopieren sich diejenigen, die solche Seiten erstellen einfach irgendwelche CodeSchnippsel von älteren Seiten, die dann rudimentär und mit viel Inline-Styles angepasst werden. So entstehen z.T. technisch waghalsige Strukturen, die dann z.B. in der Mobilansicht überhaupt nicht mehr funktionieren - was aber nicht oder viel zu spät gemerkt wird, weil die Autoren nicht auf diesen Plattformen testen.

Wen betrifft das Problem besonders?

• Direkt: Alle Autoren, die Meta-Seiten, Vorlagen u.ä. gestalten
• Indirekt: Alle (durch die verbesserte Nutzeroberfläche)

Lösungsvorschlag

• Erstellung eines Wikipedia-spezifischen Frontend-CSS-Frameworks (vgl. Bootstrap, Foundation)
• Erstellung bzw. Einarbeitung dieses Frameworks in ein Set von möglichst einfach zu verwendenden Vorlagen für die wichtigsten Frontendelemente (wie Buttons, Eingabefelder, Tabs / Navigationen, Klapper / Accordions, Lightboxes / Off-Canvas)
• Laienverständliche Dokumentation dieses Baukastens
• Kontinuierliche Pflege und Ergänzung

Natürlich soll die Nutzung dieses Baukasten für die Nutzer nicht verpflichtend sein - das ist ein Angebot. Wenn es dieses einfache Angebot gibt, dürfen aber mehr und mehr Menschen davon Gebrauch machen.

Anmerkungen

Es gibt zwar bereits Ansätze wie MediaWiki-UI. Allerdings sind diese nur sehr rudimentär, untereinander heterogen und vor allem technisch dokumentiert. Es gibt also Grundlagen auf denen man aufbauen kann, aber es gibt viel zu tun.

Im Rahmen dieses Wunsches sollen CSS-Bausteine und ggf. entsprechende WikiText-Vorlagen für die folgenden Komponenten realisiert werden:

1. Responsive Tab-Navigation mit zwei Ebenen für Metaseiten
2. Ein responsives Grid-Layout für Meta- und Portalseiten (optional)

 

Vorschlagende Person

Martin K. (Diskussion) 11:45, 11. Jun. 2017 (CEST)

Diskussion

@Martin Kraft: Danke für deinen Wunsch, den wir im Team „Technische Wünsche“ besprochen haben. So wie er jetzt formuliert ist, ist er sehr groß und geht über den Rahmen des Projekts hinaus, d. h. ich würde ihn in die Rubrik „Wünsche außerhalb des Projektrahmens“ verschieben.

Was du aber machen könntest, wäre es, den Wunsch konkret auf einen Aspekt runterzubrechen, der dir besonders wichtig ist. Beispielsweise könnte ein Wunsch für das Problem „So entstehen z.T. technisch waghalsige Strukturen, die dann z.B. in der Mobilansicht überhaupt nicht mehr funktionieren“ sein, dass man auf dem Desktop direkt beim Editieren eine Vorschau bekommen soll, wie die Seite mobil aussähe (als umschaltbare Vorschau Desktop <-> mobil). Wenn du das machen möchtest, bitte bis Sonntagnachmittag, weil die Abstimmung am Montag beginnt. Ich verschiebe diesen Wunsch außerdem gleich nach „Sonstiges“, wie hier auf der Rückseite angekündigt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 21:18, 16. Jun. 2017 (CEST)

@Martin Kraft: Nach „Sonstiges“ verschoben. -- Johanna Strodt (WMDE) (Diskussion) 21:22, 16. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Naja: Man muss ja nicht gleich von Null auf Bootstrap-Umfang gehen. Aber wenn man mit diesem Thema nicht irgendwann mal anfängt, dann wird das nie was und wir wurschteln bis in alle Ewigkeit mit einem wüssten Sammelsurium irgendwelcher Eigenkonstruktionen unterschiedlichster Qualität und mit einem massiven Komplexitäts-Overhead vor uns hin.

Man kann doch in einem ersten Schritt mal mit den wichtigsten Bausteinen (Buttons, Tabs, Infoboxen) anfangen und das ganze dann nach und nach ergänzen. Ich bin auch überzeugt, dass sich dann, wenn dieses Projekt erstmal läuft diverse Ehrenamliche finden, die an so einen Frontendbaukasten mitarbeiten. Allerdings müssen dafür aber erstmal die Strukturen geschaffen werden. Es birngt nichts, das unstrukturiert irgendwelche Styles in die Commons.css zu kippen, die dann irgendwann in Konkurrenz bzw. Konflikt mit irgendwelchen Media-Wiki eigenen Entwicklungen stehen.

Ich möchte den Vorliegenden Wunsch daher gerne aufrechterhalten und zur Abstimmung stellen. Wie, wann und wer in dann letztlich umsetzt muss man ja eh danach klären.

P.S.: Ein Button zum Öffen einer Mobilvorschau, ist grundsätzlich eine gute Idee, hat aber mit dem hier beschriebenen Ansatz wenig zu tun. Was bringt es denn Nutzer, wenn Sie sehen, dass das, was sie da bauen Mobil suboptimal aussieht, daran aber selbst mangels eigenen Know-Hows und dank der Beschränkung auf Inline-CSS wenig bis nichts ändern können. Das ist also leider keine Lösung für das hier adressierte Problem.

P.P.S.: Sorry, dass ich jetzt erst antworte, aber ich war seit Freitag MV-bedingt leider ziemlich eingebunden. // Martin K. (Diskussion) 18:04, 18. Jun. 2017 (CEST)

@Martin Kraft: Ich verstehe das, aber so wie der Wunsch jetzt formuliert ist, kann er im Rahmen des Projekts leider nicht umgesetzt werden, weil er zu umfangreich ist und kein Ende hat. Es stimmt zwar, dass das „Wie“ der Umsetzung später erst geklärt wird, aber so liest sich der Wunsch eben nach einer sehr großen Sache und würde falsche Hoffnungen wecken. Wenn er also drinbleiben soll, müsstest du ihn eindampfen. Ich glaube aber, wir kommen hier zusammen, denn du schreibst „Man kann doch in einem ersten Schritt mal mit den wichtigsten Bausteinen (Buttons, Tabs, Infoboxen) anfangen und das ganze dann nach und nach ergänzen.“ Daher folgender Vorschlag: Du reduzierst den Wunsch auf etwas, das dir im ersten Schritt besonders wichtig ist:

* Bausteine für ein reaktives Grid-Layout von Portalseiten ODER

* Bausteine für reaktive Seitenstrukturen mit Reitern ODER

* oder etwas anderes, ähnlich Konkretes

Dann hätten wir einen greifbaren Rahmen für diesen Wunsch. Bis morgen (Montag) um 9.00 Uhr könntest du das noch konkretisieren. Dann müsste ich den Wunsch entweder leider verschieben oder drinlassen, wenn er kleiner geworden ist. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 23:03, 18. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Gerne können wir die erste Ausbaustufe konkreter fassen. An der Idee, dass diese keine Insellösungen sondern Teil eines in sich konsistenten Frontendbaukastens sein sollen, würde ich aber gerne festhalten. Von daher sollten wir es auch nicht zu sehr auf einen Anwendungsfall bürsten. Was hälst Du von folgenden beiden Punkten als ersten (und hier abszustimmenden) Ausbauschritt:

• CSS-Bausteine und entsprechende WikiText-Vorlagen für ein reaktives Grid-Layout für Meta- und Portalseiten
• CSS-Bausteine und entsprechende WikiText-Vorlagen für einfache Navigationsstrukturen auf Meta- und Portalseiten (Buttons, Tabs)

Ok? // Martin K. (Diskussion) 23:58, 18. Jun. 2017 (CEST)

@Martin Kraft: Ich hatte ein paar Mini-Textänderungen und finde es jetzt okay. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 09:41, 19. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro --FNDE 11:36, 20. Jun. 2017 (CEST) Gute Sache.
3.  Pro DCB (Diskussion • Bewertung) 15:58, 20. Jun. 2017 (CEST)
4.  Pro --Nichtich (Diskussion) 22:24, 23. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 17:32, 28. Jun. 2017 (CEST)
6.  Pro --Ak ccm (Diskussion) 10:28, 29. Jun. 2017 (CEST)
7.  Pro -- hgzh 19:35, 29. Jun. 2017 (CEST)
8.  Pro KPFC 💬 23:18, 29. Jun. 2017 (CEST)
9.  Pro —SDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)
10.  Pro --Sebastian Wallroth 13:54, 30. Jun. 2017 (CEST)
11.  Pro —DerHexer (Disk., Bew.) 23:12, 1. Jul. 2017 (CEST)
12.  Pro -- Mr N (Diskussion) 00:05, 3. Jul. 2017 (CEST)