Wikipedia:Umfragen/Technische Wünsche 2017/Sonstiges

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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)

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Brunolehmann (Einreichende Person)
  2. Pro Aerdnas 13:16, 21. Jun. 2017‎ (CEST)[Beantworten]
  3. Pro Conny 14:01, 21. Jun. 2017 (CEST).[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 17:29, 28. Jun. 2017 (CEST)[Beantworten]
  5. Neutral --Sophiston (Diskussion) 14:14, 29. Jun. 2017 (CEST)[Beantworten]
  6. Kontra Die passende App für Wikipedia ist der Browser -gpf- (Diskussion) 10:00, 30. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  8. Kontra Per Gpf & Martin K. --Fixuture (Diskussion) 23:51, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  10. Kontra Per Gpf & Martin K. Shaddim (Diskussion) 12:34, 9. Jul. 2017 (CEST)[Beantworten]

Verbessertes Auffinden und Handling von Tools und Skripten

[Quelltext bearbeiten]
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)[Beantworten]
Vorschlagende Person

Geolina mente et malleo 21:47, 29. Mai 2017 (CEST), Atamari (Diskussion) 13:36, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Geolina163 (Einreichende Person)
  2. Pro Atamari (Einreichende Person)
  3. Pro --Z thomas Thomas 10:24, 20. Jun. 2017 (CEST) (als auch vorschlagender mit einem ähnlichem Wunsch [1])[Beantworten]
  4. Pro --FNDE 11:29, 20. Jun. 2017 (CEST) sehr schöne Idee[Beantworten]
  5. Pro --Wilhelm Zimmerling PAR (Diskussion) 14:37, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Krokodilgemüse (Diskussion) 15:49, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Noobius2 (Diskussion) 16:21, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro // Martin K. (Diskussion) 16:43, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Claell (Diskussion) 19:39, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Till.niermann (Diskussion) 21:01, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --  Sir Gawain Disk. 21:17, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro -- Silke (Diskussion) 15:43, 21. Jun. 2017 (CEST)[Beantworten]
  13. Pro -- Michi 19:54, 21. Jun. 2017 (CEST)[Beantworten]
  14. Pro Mike Krüger, ?! 09:32, 22. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Jossi (Diskussion) 14:10, 22. Jun. 2017 (CEST)[Beantworten]
  16. Pro --MGChecker – (📞| 📝| Bewertung) 16:40, 22. Jun. 2017 (CEST)[Beantworten]
  17. Pro --GodeNehler (Diskussion) 23:20, 22. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Nichtich (Diskussion) 22:23, 23. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Chiborg (Diskussion) 23:15, 23. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Flominator 10:55, 24. Jun. 2017 (CEST)[Beantworten]
  21. Pro --DianeAnna (Diskussion) 20:09, 25. Jun. 2017 (CEST)[Beantworten]
  22. Pro -- Michael (Diskussion) 12:37, 27. Jun. 2017 (CEST)[Beantworten]
  23. Pro --Uwe Rohwedder (Diskussion) 17:30, 27. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Incabell (Diskussion) 18:06, 27. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Kein Einstein (Diskussion) 16:00, 28. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)[Beantworten]
  27. Pro --Ak ccm (Diskussion) 10:19, 29. Jun. 2017 (CEST)[Beantworten]
  28. Pro --1971markus ⇒ Laberkasten ... 23:31, 29. Jun. 2017 (CEST)[Beantworten]
  29. ProSDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)[Beantworten]
  30. Pro --Sebastian Wallroth 13:48, 30. Jun. 2017 (CEST)[Beantworten]
  31. ProMarcus Cyron Reden 02:13, 1. Jul. 2017 (CEST)[Beantworten]
  32. ProDerHexer (Disk.Bew.) 23:06, 1. Jul. 2017 (CEST)[Beantworten]
  33. Pro --Mabschaaf 23:09, 1. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  35. Pro --Sitacuisses (Diskussion) 15:20, 2. Jul. 2017 (CEST)[Beantworten]
  36. Pro --Varina (Diskussion) 16:35, 2. Jul. 2017 (CEST)[Beantworten]
  37. Pro --C₂₁H₂₂N₂O₂ (Diskussion) 22:31, 2. Jul. 2017 (CEST)[Beantworten]
  38. Pro --Zaccarias (Diskussion) 20:10, 2. Jul. 2017 (CEST)[Beantworten]
  39. Pro -- Mr N (Diskussion) 23:59, 2. Jul. 2017 (CEST)[Beantworten]
  40. ProGhilt (Diskussion) 09:52, 4. Jul. 2017 (CEST)[Beantworten]
  41. Pro --Haplochromis (Diskussion) 19:46, 11. Jul. 2017 (CEST)[Beantworten]

Konsistenz der Koordinaten auf der OSM-Karte

[Quelltext bearbeiten]
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)[Beantworten]

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)[Beantworten]
  3. Pro тнояsтеn 11:13, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Bungert55 (Diskussion) 11:37, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --XPosition (Diskussion) 13:57, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Wilhelm Zimmerling PAR (Diskussion) 14:34, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro -- «« Man77 »» (A) wie Autor 14:53, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro DCB (DiskussionBewertung) 15:52, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --HerrAdams (D) 18:45, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro Hermannh (Diskussion) 22:17, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Bluemel1 (Diskussion) 14:00, 21. Jun. 2017 (CEST)[Beantworten]
  12. Pro Mike Krüger, ?! 14:04, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Atamari (Diskussion) 23:05, 23. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Michi Baer (Diskussion) 06:10, 24. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Abubiju (Diskussion) 12:20, 24. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  17. Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Ak ccm (Diskussion) 10:20, 29. Jun. 2017 (CEST)[Beantworten]
  19. Pro --alexrk (Diskussion) 16:10, 26. Jul. 2017 (CEST)[Beantworten]

Eigene Top-Level-Domain für alle Wikipedias

[Quelltext bearbeiten]
Was ist das Problem?

Die Wikipedia URLs sind ja grundsätzlich recht lang (xx.wikipedia.org/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.wikipedia.org/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.wikipedia.org/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.wikipedia.org/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)[Beantworten]

Unterstützung
  1. Pro VanGore (Einreichende Person)
  2. Pro  hugarheimur 09:02, 20. Jun. 2017 (CEST) das entspricht meinem Vorschlag von 2015[Beantworten]
  3. Pro --FNDE 11:31, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Mit der Gewährleistung, dass NUR zum jeweiligen WP-Angebot/Artikel weitergeleitet werden kann: ja! --emha db 13:54, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Zellmer (Diskussion) 15:42, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Bluemel1 (Diskussion) 14:01, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro sk (Diskussion) 17:15, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro -- Michi 19:54, 21. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  11. Pro --Avonsoda 20:45, 21. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Jossi (Diskussion) 14:11, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro --MGChecker – (📞| 📝| Bewertung) 16:56, 22. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Eriom (Diskussion) 12:19, 23. Jun. 2017 (CEST)[Beantworten]
  15. Pro -- Freddy2001 DISK 12:27, 24. Jun. 2017 (CEST)[Beantworten]
  16. Pro --RotWeisserHai (Diskussion) 14:05, 24. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Chstdu (Diskussion) 15:26, 26. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Ak ccm (Diskussion) 15:16, 28. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Thomas Obermair 4 (Diskussion) 17:30, 28. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Ak ccm (Diskussion) 10:22, 29. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Sophiston (Diskussion) 14:21, 29. Jun. 2017 (CEST)[Beantworten]
  22. Pro KPFC💬 23:14, 29. Jun. 2017 (CEST)[Beantworten]
  23. ProSDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Sebastian Wallroth 13:51, 30. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Fixuture (Diskussion) 23:56, 1. Jul. 2017 (CEST)[Beantworten]
  26. Pro --Linopolus (Diskussion) 11:12, 2. Jul. 2017 (CEST)[Beantworten]
  27. Kontra -- Der Nutzen ist doch eher sehr gering... PAB (Diskussion) 20:49, 2. Jul. 2017 (CEST)[Beantworten]
  28. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:57, 2. Jul. 2017 (CEST)[Beantworten]

Keine Darstellungsprobleme bei Vorlagen ab einer bestimmten Datengröße

[Quelltext bearbeiten]
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

Z thomas Thomas 22:57, 4. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 10:58, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Geolina mente et malleo 17:50, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro  hugarheimur 09:03, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --FNDE 11:31, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro DCB (DiskussionBewertung) 15:55, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Wilhelm Zimmerling PAR (Diskussion) 16:16, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Atamari (Diskussion) 23:07, 23. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)[Beantworten]
  10. ProDerHexer (Disk.Bew.) 23:10, 1. Jul. 2017 (CEST) Weiteres Beispiel.[Beantworten]

Umwandeln von strukturierten Daten in Wikitabellensyntax

[Quelltext bearbeiten]
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

Z thomas Thomas 10:45, 9. Jun. 2017 (CEST)[Beantworten]

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

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

[Quelltext bearbeiten]
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

Z thomas Thomas 11:00, 9. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro --Wilhelm Zimmerling PAR (Diskussion) 14:32, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)[Beantworten]

Share my Edit

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Albinfo (Einreichende Person)
  2. Pro --سلوك Saluk 14:48, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Hermannh (Diskussion) 22:22, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro sk (Diskussion) 17:16, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Avonsoda 20:45, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro --RotWeisserHai (Diskussion) 14:06, 24. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 17:31, 28. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Ak ccm (Diskussion) 10:25, 29. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Sophiston (Diskussion) 14:33, 29. Jun. 2017 (CEST)[Beantworten]
  10. ProSDKmac (Disk., Bew.) 02:15, 30. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Sebastian Wallroth 13:53, 30. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:59, 2. Jul. 2017 (CEST)[Beantworten]
  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)[Beantworten]

Nutzeroberflächen-Bugs beheben

[Quelltext bearbeiten]
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)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)
  2. Pro -- X:: black ::X (Diskussion) 11:08, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro  hugarheimur 09:04, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Wilhelm Zimmerling PAR (Diskussion) 14:30, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro DCB (DiskussionBewertung) 15:57, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --HerrAdams (D) 18:47, 20. Jun. 2017 (CEST)[Beantworten]
  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)[Beantworten]
  9. Pro -- Tilman Kluge 23:55, 25. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 17:32, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Ak ccm (Diskussion) 10:26, 29. Jun. 2017 (CEST)[Beantworten]
  12. Pro KPFC💬 23:16, 29. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Sebastian Wallroth 13:54, 30. Jun. 2017 (CEST)[Beantworten]
  14. ProDerHexer (Disk.Bew.) 23:12, 1. Jul. 2017 (CEST)[Beantworten]
  15. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 23:01, 2. Jul. 2017 (CEST) längst überfällig[Beantworten]

Baukasten Nutzeroberfläche

[Quelltext bearbeiten]
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)[Beantworten]

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