Ich habe einen Fehler auf der Hauptseite entdeckt. Was kann ich tun?
Schau zuerst im Artikel, ob der Fehler auch dort vorhanden ist, und korrigiere ihn wenn möglich. Melde ihn bitte in jedem Fall auf dieser Seite oder korrigiere ihn selbst, falls du dazu berechtigt bist (siehe Wer kann die Rubriken bearbeiten?). Falls sich hier nichts tut, kannst du zusätzlich einen Hinweis bei den Administratoren-Anfragen hinterlassen.
Hauptseiten-Archiv (seit 1. Januar 2014; ggfs. Rekonstruktionen älterer Hauptseiten)
Warum sind auf der Hauptseite noch die Einträge des Vortags?
Möglicherweise wurde der serverseitige Cache der Seite noch nicht aktualisiert: dazu bitte auf Hauptseite aktualisieren klicken und dies mit „OK“ bestätigen. Bei unveränderter Anzeige ist der Browsercache neu zu laden, bei den verbreitetsten Browsern mit der Tastenkombination Strg+F5. Sollten die Inhalte noch älter sein, wurden sie noch nicht für das aktuelle Datum angepasst. Dies erfolgt dann möglichst rasch nach Mitternacht durch einen Administrator.
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 7 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.
Letzter Kommentar: vor 4 Jahren121 Kommentare26 Personen sind an der Diskussion beteiligt
TL;DR: Es gibt eine neue Umsetzung der Hauptseite hier zu erproben (per WP:BETA – Rotlinks sind dort völlig normal und die Inhalte fiktiv).
Auf normalem Desktop oder Mobilgerät müsste es praktisch wie bisher aussehen.
Dann mal mit Strg+- → Strg+- → Strg+- → Strg+- einen HD-Bildschirm mit 5000 Pixeln Breite simulieren (diese Tasten bewirken bei vielen Browsern eine Verkleinerung von Schrift- und Bildgrößen).
Oder mal mit Strg++ → Strg++ → Strg++ → Strg++ jemanden mit nicht so guten Augen, bzw. ein Mobilgerät.
Hintergrund ist eine Umstellung der globalen Wiki-Software, die mindestens für die mobile Darstellung Eingriffe erforderlich macht: phab:T254287
Das muss bis zum 13. Juli 2020 passiert sein.
Als ich mir daraufhin die Umsetzung der Hauptseite genauer ansah, fand ich eine Vielzahl von Techniken, die nicht mehr zeitgemäß sind.
Ich habe die HTML-CSS-Realisierung deshalb bei Null beginnend neu geschrieben.
Am organisatorischen Management der Vorschläge ändert sich im Wesentlichen nichts; vielleicht werden einige Aspekte komfortabler oder es kommen neue Möglichkeiten hinzu.
Die nachstehenden Gesichtspunkte waren Anlass für den Neuaufbau:
Anpassung an Gerät und Schriftgröße der Leser (Hauptaspekt)
Wir kennen bisher nur zwei Modi – ein Desktop, wo immer grad zwei Spalten draufpassen, und eine Mobildarstellung. Es gibt aber auch Leser mit schlechten Augen und solche mit HD-Bildschirmen, für die die derzeitige Umsetzung nicht sinnvoll lesbar ist.
Barrierefreiheit (Hauptaspekt)
Eine Reihe von Strukturen war für blinde Benutzer nicht hilfreich, teilweise eine vermeidbare Barriere, anderes überflüssig und irritierend.
Multilingual (Nebenaspekt)
Als kleine Aufmerksamkeit sollte wenigstens der Einleitungsabschnitt „Willkommen“ in gängigen Weltsprachen erscheinen, zumindest die Überschrift der Box und der erste Satz, sowie die DACH-Dialekte gewürdigt werden.
Die Überschriften der Boxen zumindest auf Englisch, wie hier zu sehen.
Den täglichen Teaser nun auch noch auf Englisch und Latein abzuliefern ist hingegen nicht geplant.
Performance bei den Lesern (Nebenaspekt)
Bisher lassen wir alles CSS in jeder beim Leser dargestellten Seite, mit jeder URL anzeigen. Auf jeder Beo, in jedem Artikel wird nach den Elementen der Hauptseite gesucht. Vergeblich, natürlich. Kostet nicht viel Zeit, aber ein klitzekleinwenig. Auf jeder Seite.
Zukünftig wird das CSS erst ausgeliefert, wenn ein Leser die Hauptseite ansehen möchte, und nur auf dieser (plus interner organisatorischer Seiten für Vorschläge usw.) für die Darstellung angefasst.
Die bisherigen HS-Archivseiten wären durch eine Kopie des CSS vor dem Stichtag zu versorgen.
Seitenorganisation (Nebenaspekt)
Ich habe drei Vorlagen gefunden, bei denen mir nicht klar ist, warum das Vorlagen sein sollten, weil sie ausschließlich in diesem Kontext vorkommen.
Alle beteiligten spezifischen Seiten sollten beieinander als Projektseiten stehen, wenn wir jetzt schon einen klaren Schnitt machen würden.
Sie können dann auch en bloc besser durchsucht werden.
Wahrscheinlich stammt das aus der Zeit bis 2008, als die Hauptseite noch im ANR stand.
Auf dieser Seite sind Einzelheiten zu den technischen Hintergründen zusammengestellt.
Wem noch was auffällt, das nicht beabsichtigt oder unvermeidlich ist, der möge es bitte anmerken. Einige Details sind allerdings bewusst nicht in die Dynamik übernommen worden, um die Leser nicht kirre zu machen.
Ansonsten möge man befürwortend oder begründet ablehnend hier Kommentare hinterlassen.
In den ersten Julitagen müsste dann ein Resümée gezogen werden, und dann ein generalstabsmäßig geplanter ruckelfreier Umzug, den letzten Baustein in den frühen Morgenstunden.
Häme am Rande: en:Main Page ist eine nicht barrierefreie Layout-Tabelle nur für historischen Desktop, hihi. Wir wären denen eine Nasenlänge voraus.
Eine Hauptseite ist Visitenkarte für den Rest des Projekts; sie sollte vorbildlich sein und keine vermeidbaren Nachteile für Gruppen von Benutzern bewirken.
Credits:XanonymusX hat an der Erarbeitung mitgewirkt, Wurgl zusammen mit hgzh kommentiert und erprobt, FriedhelmW unbeteiligt den vorläufigen Abschlusstest.
Strg+- funktioniert bei mir gut und gefällt. Fänd ich gut, würde das umgesetzt.
Bei Strg++ vermisse ich, dass sich das Design ab einem gewissen Zoomfaktor in die mobile Version umschaltet. Das klappt nur im Monobook-Skin (und zwar in der "echten WP" genauso wie im Beta-Wiki). Bug oder Feature?
warum soll ich einen Bildschirm mit 5000 Pixeln simulieren, wenn ich einfach 2 4K-Monitore nebeneinander betreiben kann? Das sind jetzt hier knapp 8000 Pixel. Die 3 Kästen in der Mitte sind alle unterschiedlich breit. Ist nicht ideal. Aber so extrem breit mit kleiner Schrift benutzt es vermutlich niemand. Also alles gut aus meiner Sicht. --Steffen2 (Diskussion) 14:58, 24. Jun. 2020 (CEST)Beantworten
@Man77: Welche mobile Version meinst du? Ich hab Monobook nie verwendet; aber ja, dort gibt es scheinbar eine „eingebaute“ Mobilversion, im Gegensatz zu den anderen Skins mit Minerva als Mobilversion. Und diese ist offenbar unabhängig von der m-Domain. Na ja, das ist definitiv nicht zukunftssicher und könnte so oder so nicht über eine einzelne Seite, sondern nur softwareseitig gelöst werden.
Ansonsten: Bin jetzt grundsätzlich sehr zufrieden. Hat sich sicher gelohnt, ambitioniert zu sein! ;) Einziger Wermutstropfen bleibt für mich die fehlende Zentrierung von „Willkommen bei Wikipedia“ und „Schwesterprojekte“ in der Desktop-Ansicht, eine in meinen Augen unnötige und unästhetische Änderung; daran sollte es aber für mich nicht scheitern. Und noch eine Anmerkung: Die Trenner (middots) in den Fußzeilen der Kästen sind mit 0.9ex doch etwas arg hoch platziert, 0.5 sähe bei mir deutlich natürlicher aus. Gruß–XanonymusX (Diskussion) 15:47, 24. Jun. 2020 (CEST)Beantworten
Ja, das meinte ich oben mit „,eingebaute‘ Mobilversion“. In Monobook ist die m-Domain offenbar gegenüber der klassischen unverändert, da der Skin selbst auf die Breite reagiert (wie gesagt, das ist über einzelne Seiten nicht steuerbar, und hängt außerdem strikt mit der 720-px-Schwelle zusammen, was auf die neue Hauptseite nicht mehr zutrifft). Bei den anderen Skins schaltet die m-Domain auf Minerva um (eine reduzierte Version davon, strenggenommen), weshalb der Skin selbst nicht weiter responsiv ist. Gut möglich, dass der neue Vector wieder weiter mit Minerva verschmilzt und diese Trennung irgendwann aufgegeben wird, aber das liegt außerhalb unseres Einflussbereichs. Gruß–XanonymusX (Diskussion) 16:42, 24. Jun. 2020 (CEST)Beantworten
Danke für die ersten Reaktionen.
Es gibt kein mobil und Desktop und Skin und Pixel mehr (für die Hauptseite) sondern nur noch die Frage: Wie viele Buchstaben passen in eine Zeile?
Sind es zu wenige, dann wird eine Spalte weniger genommen, falls wir nicht schon bei einspaltig sind.
Werden es zu viele Buchstaben, wird die Zeile irgendwann wegen zu vielen Buchstaben (mehr als ungefähr 100) schlecht lesbar, dann wird eine neue Spalte aufgemacht, bis wir bei fünf sind.
Die Position des Aufzählungs-Trenners ist für meinen Geschmack gerade optimal eingestellt und soll ja auch kein Buchstabe sein oder damit verwechselt werden und auch an Icons passen, ob nun 0.9ex oder 0.7ex kann auch im Juli oder nächstes Jahr noch justiert werden.
Dann sehe ich ja schon mal der italienischen Übersetzung von benvenuto und erstem Satz entgegen. Dieses BETA-Mobil-Begrüßungsdings habe ich übrigens hoffentlich wirksam abgeschaltet, wie gewünscht.
Danke für Deine Mühe, das alles so hinzubiegen! Aber in dem einen Punkt stimme ich XanonymusX zu, die Middots passen nicht. In der Kopfzeile von "In den Nachrichten" ist es ok, in den Fußzeilen (AdT, Was geschah, SG) nicht. So weit ich sehen kann, ist das auch nicht von den Anzeigeeinstellungen abhängig, sondern (zumindest bei Monobook) immer der Fall.--Mabschaaf18:04, 24. Jun. 2020 (CEST)Beantworten
Ich hätte auch noch an sicherem Unicode U+2605 ★ BLACK STAR, U+2726 ✦ BLACK FOUR POINTED STAR, U+2731 ✱ HEAVY ASTERISK. Jemand für Blümchen, U+2740 ❀ WHITE FLORETTE? Verkleinerung und vertikale Position sind mir relativ wumpe; aber zwischen Icons und jeweiligen Schriftgrößen empfindet die jeder etwas anders. Die Kuller habe ich wegen irritierender Verwechslung mit Aufzählungszeichen ausgeschlossen. Kann auch hier in dieser Disk ausgewürfelt werden. VG --PerfektesChaos19:13, 24. Jun. 2020 (CEST)Beantworten
Die Form finde ich jetzt in der Tat besser, der Knödel vorher war mir zu aufdringlich. Höher als 0.7ex würde ich jedenfalls auf keinen Fall gehen, ich hatte bei mir im Browser mit den Werten 0.7–0.5ex gespielt.
Italienische Übersetzungen hab ich eingebaut, wo möglich. Übrigens hast du die kryptischen id=mf- noch alle drin stehen, die werden aber ab dem 13. Juli obsolet (sofern ich das richtig verstanden habe) und können demnach verlustfrei raus! Die Hauptseiten-Begrüßung ist auf Beta für die deutsche Oberfläche verschwunden, aber offenbar ist das Teil sprachabhängig. Eventuell muss doch noch eine Alternativlösung per phab:T255682 her. Gruß–XanonymusX (Diskussion) 22:01, 24. Jun. 2020 (CEST)Beantworten
Ich habe nicht die leiseste Ahnung, was diese id=mf- sein sollen und wer die wozu braucht; aber bis Herbst sollten sie erstmal drin bleiben.
Mob-Begrüßung: Die kommt, so nicht lokal definiert, aus dem translatewiki, und müssen, wie hier zu sehen, einzeln lokal deaktiviert werden.
Hallo, grundsätzlich finde ich die Betaversion viel besser als die jetzige Version, da die Kästen auf der linken und der rechten Seite weiter voneinander stehen und somit – wenn die eine Seite deutlich länger ist – nicht mehr eine so auffällige Weißfläche unten entsteht. Allerdings würde ich es mir wünschen, wenn der Adt-Kasten mit dem Was-Geschah-Am-Kasten getauscht werden würde, da der Fokus auf den AdT und nicht auf die Jahrestage gelegt werden sollte. Wie seht ihr das? --TheAmerikaner (Diskussion) 23:45, 24. Jun. 2020 (CEST)Beantworten
Achso, und wenn ich das richtig gelesen haben sollte, dass weder Icons noch Bilder auf der Beta-Hauptseite erlaubt sein sollten, wehre ich mich dagegen. Kann man diese nicht auch für Screenreader „unsichtbar“ werden lassen? Denn für jeden, der selbstständig lesen kann, sind Bilder ansprechend und visualisieren die ganze Hauptseite – denn sonst ist man mit dem Text überfordert und liest diesen nicht. Korrigiert mich, falls ich falsch liegen sollte: Aber Bilder sind ein Muss auf der Hauptseite (Hier die Quelle: Bei Barrierefreiheit der zweite Stichpunkt). Beste Grüße --TheAmerikaner (Diskussion) 00:01, 25. Jun. 2020 (CEST)Beantworten
Komisch, bei mir funktioniert das Aufteilen in Spalten nicht, hat das sonst keiner? In Edge stehen alle Boxen untereinander und rechts ist ein weißer Streifen. Mit Opera gibt es drei Spalten, in der Mitte ist Was geschah am (aber vielleicht soll das so sein und ich hab's nur überlesen).--Berita (Diskussion) 11:31, 25. Jun. 2020 (CEST)Beantworten
es sind dynamisch 1 bis 5 Spalten. Also ist 3 je nach Bildschirmbreite und Zoomfaktor eine Variante die absichtlich ist. Kannst du einen Screenshot von dem mit viel Leer-Raum rechts machen? --Steffen2 (Diskussion) 11:42, 25. Jun. 2020 (CEST)Beantworten
Machen schon, aber hochladen nicht wegen URV. Ist doch aber auch so verständlich oder? Jetzt wo du das mit Zoomen schreibst: wenn ich kleiner zoome, verteilt er sich im Edge auch auf mehrere Spalten. Naja, gewöhnungsbedürftig.--Berita (Diskussion) 11:49, 25. Jun. 2020 (CEST)Beantworten
Doch noch mal näher erklärt: der weiße Streifen nimmt bei Edge in der ein-spaltigen Anzeige nahezu die Hälfte des Bildschirms ein, nur die unterste und oberste Box gehen über die ganze Seite bzw. sind zentriert. Bei Opera dagegen geht die eine Spalte über den ganzen Bildschirm, wenn man so gross zoomt, das ist dann wohl richtig. Noch seltsamer bei Edge ist, dass - wenn ich schrittweise größer zoome - bei manchen Schritten eine zweite Spalte erscheint und beim nächsten dann wieder verschwindet.--Berita (Diskussion) 12:14, 25. Jun. 2020 (CEST)Beantworten
Was die Box "Was geschah am" im Drei-Spalten-Modus angeht, schließe ich mich TheAmerikaner an, es wäre besser, wenn der AdT im Zentrum stehen würde. Allerdings sollte die Reihenfolge im Zwei-Spalten-Modus wie bisher bleiben, weiß nicht, ob das technisch so einfach umsetzbar ist.--Berita (Diskussion) 12:57, 25. Jun. 2020 (CEST)Beantworten
@Reihenfolge: Es ist immer die gleiche Reihenfolge, egal ob 1- oder 2- oder 3- oder 4- oder 5-spaltig oder Screenreader.
Das ist wie mit einer klassischen Zeitung, oder einem zweispaltigen Lexikon: Erst wird die linke Spalte von oben nach unten gelesen, danach die rechte.
Es würde sehr viele Leser sehr verwirren, wenn nun plötzlich bei Verbreiterung und Verkleinerung des Bildschirms oder auf einem anderen Gerät die Blöcke plötzlich an unerwarteter Stelle stünden; es passiert ohnehin schon genug Unerwartetes, wenn man seinen Bildschirm sehr breit macht, an das man sich gewöhnen müsste.
Technisch umzusetzen wäre es ohnehin nur sehr kompliziert und nicht für alle Leser lösbar.
@Edge etc.
Bitte Skin, Browserversion und die Domain (mobil/klassisch).
Es könnte ein edge case sein: Die Boxen im mittleren (inhaltlichen) Bereich haben eine Breitenbegrenzung, damit die Zeilen nicht so lang werden, dass Menschen mit begrenzter Sprach-/Lesekompetenz sie nicht mehr entziffern können. Die oberste und unterste box, in der im Wesentlichen Aufzählungen stehen, haben diese Beschränkung nicht; bis auf den allerersten Fließtext-Absatz. Vielleicht hast du in deinem Edge auch seltsame Schriftgrößen eingestellt.
Mitleser mit gleichen Browsern bitte HTML/CSS analysieren.
Beim Wechsel auf drei Spalten sieht die Seite nicht mehr gut aus. Könnte man nicht die Breite der einzelnen Spalten so variieren, dass sie immer alle etwa gleich hoch sind? Außerdem sollte der oberste Kasten sich wie bisher über die ganze Breite erstrecken. --Megalogastor (Diskussion) 14:51, 25. Jun. 2020 (CEST)Beantworten
Nein, denn die Menge an Inhalten wechselt permanent.
Von der linken Spalte werden „oben“ und „unten“ jetzt nebeneinander dargestellt.
Die bisherige rechte Spalte bleibt erhalten.
Hier stehen nur Aufzählungen. Diese Spalte wird breiter dargestellt als die ersten beiden, die jeweils meist nur eine Box enthalten, weil hier weiterhin drei Boxen untergebracht werden müssen. Zu hoffen ist, dass die Aufzählungspunkte jeweils in eine bis zwei Zeilen passen, wodurch diese breiten Boxen jetzt vertikal weniger Platz benötigen und die drei Boxen übereinander nicht allzuviel höher ausfallen als die beiden Boxen der ersten Spalte.
Ohne die Teilung in drei Spalten sehen die bisherigen zwei Spalten in lesbarer Schriftgröße und Zeilenlänge auf einem entsprechend breiten Bildschirmfenster aber noch schlimmer aus. Es kann sich also nur verbessern.
Aber gibt es denn keine Möglichkeit, die Spaltenhöhe konstant zu halten, und dafür die Spaltenbreite an den Platzbedarf des Inhaltes anzupassen? Oder müßen die Spalten aus technischen Gründen gleich breit sein? --Megalogastor (Diskussion) 17:16, 25. Jun. 2020 (CEST)Beantworten
Nein, gibt es nicht; wir können nur anhand der Breite des Bildschrms (-fensters) die Anzahl der Spalten steuern, aber wir wissen nicht, wie hoch ein Browser bei einem Leser einen heute aktuellen Inhalt darstellt und können erst recht nicht danach hinterher feststellen, dass das aber alles ganz anders ein soll, und dann plötzlich den schon fertigen Bildschirm nochmal umschmeißen und es jetzt anders darstellen. VG --PerfektesChaos18:02, 25. Jun. 2020 (CEST)Beantworten
Könnte man denn nicht einfach eine maximale Breite festlegen, so dass sich die Seite nicht weiter an die Fenstergröße anpasst, anstatt eine dritte (bzw. vierte oder fünfte) Spalte zu eröffnen? --Megalogastor (Diskussion) 18:33, 25. Jun. 2020 (CEST)Beantworten
Ach ja – „Außerdem sollte der oberste Kasten sich wie bisher über die ganze Breite erstrecken.“
Das kann sehr sehr sehr sehr breit sein.
Er wird nicht breiter als benötigt wird, um die längste Auflistung (die Themenportale) in einer einzigen Zeile anzuzeigen.
Würde er immer über die volle Bildschirmbreite gehen, dann stünden innerhalb der Box riesige weiße Flächen unmotiviert herum. Das sähe noch schlimmer aus.
Das halte ich, mit Verlaub, für eine private Einzelmeinung. Mindestens meine stünde dagegen, und wenn ich das richtig überblicke auch bereits die mehrerer anderer Beteiligter. VG --PerfektesChaos18:02, 25. Jun. 2020 (CEST)Beantworten
Warum macht man bei einem zentrierten Kasten einen linksbündigen Kastentitel? Mein Vorschlag mit dem Kasten bis an beide Ränder läuft ja eigentlich darauf hinaus, dass es so aussieht wie bisher, also werden wohl viele von denen, die mit dem jetzigen Erscheinungsbild der Hauptseite zufrieden sind, die neue Gestaltung weniger gelungen finden, wenn sie sie dann zu Gesicht bekommen. --Megalogastor (Diskussion) 18:46, 25. Jun. 2020 (CEST)Beantworten
In dem Punkt bin ich ganz bei dir, siehe weiter oben: „eine in meinen Augen unnötige und unästhetische Änderung“. Bei einer 100%-Breite wäre das eine optische Katastrophe, so mag es aber noch vertretbar sein.–XanonymusX (Diskussion) 19:08, 25. Jun. 2020 (CEST)Beantworten
Zu den Fragen oben, ich sehe grade, dass meine Edge Version sehr veraltet ist (44..). Ich will aber im Moment nicht updaten, vielleicht kann das mal jemand anders mit der aktuellen Version testen. An den Schriften habe ich nichts geändert. Ansonsten benutze ich Vector, klassisch.--Berita (Diskussion) 16:00, 25. Jun. 2020 (CEST)Beantworten
Das von mir verwendete HTML/CSS ist, wenn ich das richtig überblicke, weitgehend auf dem Stand von 1998. Zumindest kein aktuellerer Stand als 2009 für irgendein Detail erforderlich. Es gibt aber Browser mit Bugs, und die Begriffe „Edge“ und „Bug“ assoziiere ich. VG --PerfektesChaos16:33, 25. Jun. 2020 (CEST)Beantworten
Argh, Edge macht seinem Ruf wieder mal alle Ehre, hab es nun auch nachvollzogen. Es gibt dort in der Tat einen Zustand zwischen dem einspaltigen und dem zweispaltigen Layout (sowohl klassisch als auch m., aber in jeweils unterschiedlichen Zoomstufen), in dem zwar zwei Spalten gebildet werden, die Kästen aber alle untereinander in der ersten Spalte stehen. Da scheinen die Breakpoints irgendwo nicht ganz smooth zu wechseln. Aber: In der aktuellen Browserversion, die ich soeben installiert habe, ist der Fehler verschwunden, das war also wohl ein Bug aus der Kinderstube (wobei die V44 jetzt nicht gar so alt ist, dürfte durchaus noch in Gebrauch sein).–XanonymusX (Diskussion) 17:48, 25. Jun. 2020 (CEST)Beantworten
Naja, die rem-Schwellen sind so gewählt, dass die neue Spalte eingeführt wird, wenn die Zeilenlänge (Buchstaben-Anzahl) der bisherigen Spalten recht lang wird, und jedoch genug rem vorhanden sind, um eine neue Spalte zu beginnen.
Mag sein, dass da irgendwo noch ein paar rem nachzujustieren wären.
@rechts und links sind weiße Streifen + Drei Spalten überlappen sich teilweise
Das kenne ich insofern, als es dann in irgendeiner Skin ein (MediaWiki-)Element für den content gibt, das von MediaWiki mit einer starren Maximalbreite festgelegt wurde; wir aber inzwischen die gesamte für den Leser verfügbare Bildschirmbreite abfragen und auf der gesamten Breite die Spalten anordnen.
Auf Minerva (das ist mobil) und Timeless sind deshalb diese Elemente identifiziert und diese Breitenbeschränkung für die Hauptseite wieder aufgehoben worden.
Mag jemand von den Kundigen herausfinden, welches Element die volle Ausdehnung einschränkt, und das hier mit Angabe von Skin und Situation und Selektor mitteilen?
Die Herrschaften, die einen dieser Effekte beobachten, müssten bitte präzise mitteilen (und dazu das HTML-DOM analysieren):
Rahmenbedingungen (Skin, Domain, wie viele Spalten, Browser)
Bei Überlappung, und „rechts und links sind weiße Streifen“: Welches Element hindert den Inhaltsbereich, sich über die ganze Bildschirmbreite auzudehnen? Wo sind ggf. Ränder?
Bei „Seitenleiste und AdT laufen ineinander“: Wie viele Spalten nebeneinander? Welches Element umfasst den Inhaltsbereich, wie breit ist dieses, ist dafür eine Beschränkung definiert, wie breit ist die Sidebar, wo sind ggf. Ränder?
Ach so, halb so schlimm: IE scheint schlicht allergisch auf den neuen Vector zu reagieren, alle Seiten auf Beta (zumindest der Inhaltsbereich) werden dort so breit dargestellt, als ob die Sidebar gar nicht da wäre (margin-left fehlt). Betrifft ausschließlich Vector, unabhängig von der Domain. Sofern es nicht an einer Bastelei in Vector.css liegt, müssen sie das in MediaWiki noch besser lösen, bevor der Skin generell eingeführt wird, sofern eine IE-Kompatibilität überhaupt noch gewünscht ist. Uns betrifft das hier nicht. Sonstiges unerwünschtes Verhalten kann ich in keiner Skin-Domain-Zoom-Kombination mehr feststellen. Gruß–XanonymusX (Diskussion) 23:39, 25. Jun. 2020 (CEST)Beantworten
Erfreulich zu sehen, dass es dann offenbar keine technischen Probleme gibt.
Was die Befürchtungen betreffend neuem Vector, BETA, und Microsoft angeht:
Das ist den Entwicklern sehr wohl bekannt.
Diejenigen Browser, die diese HTML5-Elemente nicht unterstützen, haben einen verschwindenden Anteil unter den Abrufen durch unsere Leser.
Ab einem bestimmten Minimum werden Browserversionen und ihre Features dann als nicht mehr unterstützt erklärt.
Das hindert aber nicht daran, jetzt schon mit der modernen und der Zukunft zugewandten Semantik den neuen Vector zu entwckeln.
Wobei eine andere Variante wäre, in der zunächst ausgerollten Vector-Version noch beim bisherigen div zu bleiben und erst später auf nav und main umzurüsten. Allerdings hat man bereits in Vorbereitung begonnen, alle CSS in den Projekten, die in den Selektoren ein redundantes explizites div verwenden, auf die unspezifische Variante umzurüsten.
<main> wurde in einem Standard von 2014 spezifiziert und ist vom IE9, Edge aber erst ab 11 umgesetzt. Oder so.
Wobei sich MediaWiki erneut selbst ins Bein geschossen hat: Obwohl es schon im HTML5 vorgezeichnet war, wurde <section> für ein internes MediaWiki-Element neu vergeben. Das gehört zur gleichen Familie wie nav und main. Bereits beim veralteten <source> gab es einen Namenskonflikt mit gleichnamigem HTML, wobei wir da aber unschuldig waren weil älter als das HTML; außerdem ein Element, das in unseren Inhalten verboten ist.
Hallo zusammen! PerfektesChaos und XanonymusX haben viel Zeit und Know-how eingebracht, die Hauptseite neu aufzubauen und dabei eine Reihe zusätzlicher Aspekte zu berücksichtigen. Mit vielem bin ich einverstanden (wie prinzipielle Anpassung an Schriftgröße und Mehrsprachigkeit), mit einigem nicht. Es ist leichter und zielführender, letztere aufzuführen, angefangen mit den kleineren Dingen.
#spalten
#links
#links-oben
[Wikipedia aktuell]
[Artikel des Tages]
#links-unten
[Was geschah am …?]
#rechts
#rechts-oben
[In den Nachrichten]
#rechts-unten
#rechts-unten-1
[Kürzlich Verstorbene]
#rechts-unten-2
[Schon gewusst?]
Die horizontalen Innenabstände in Überschriftsbalken sollten mit denen der Inhaltskästen, wie bei der derzeitigen Hauptseite (hier 0.8em), übereinstimmen.
Die Trennsymbole in den horizontalen Aufzählungen sollten symmetrisch platziert sein (und nach meinem Geschmack lieber rund als spitz). Dafür ist zu berücksichtigen, dass sich Zeilenumbrüche im Quelltext als Leerraum in der Ausgabe auswirken.
Die Kästen der Hauptseite besitzen zurzeit eigene id-Attribute, die mit dem letzten großen Umbau im April 2006 eingeführt wurden (ursprüngliche Anregung wohl gelöscht), damit Benutzer (wie ich) sie individuell gestalten können. Das würde ich gerne beibehalten sehen. Dies geht zwar auch anders, aber umständlicher.
Die Kästen im Hauptteil (außer oben und unten) sind in einer aufwändigen und unsymmetrischen Baumstruktur angeordnet, siehe rechts. Ist es noch zeitgemäß, eine solche Konstruktion aus Elementen (mit float-Eigenschaften) aufzubauen anstatt von der moderneren flex-Technik Gebrauch zu machen? Ich bin darin kein Experte, aber so weit ich weiß, lassen sich damit Strukturen flacher aufbauen, Leerräume vermeiden und sogar die Reihenfolge der Elemente beeinflussen.
Die Vollbildansicht der Seite (1920 Pixel Breite, unangemeldet mit aktuellem Firefox und Standardschriftgröße) finde ich überraschend bis abstoßend. Die acht Kästen nehmen dabei vier verschiedene Breiten ein, die im Hauptteil verteilt auf drei Spalten (28%, 28%, 38%) mit einer klaffenden Lücke in der unteren Mitte. Diese Darstellung wurde schon oben angesprochen und dazu würde ich gerne mal die Meinung von Mediengestaltern wie Martin Kraft erfahren. Als Alternative schlage ich vor, dass alle Kästen von einem Element umgeben werden, das den gesamten Inhalt auf eine maximale Breite (die Maßeinheit darf em sein) mit höchstens zwei Spalten einschränkt und gerne zentriert platziert wird. Ich habe mich umgesehen und keine andere Sprachversion gefunden, deren Hauptseite auf ein geschlossenes Erscheinungsbild verzichtet. Jedenfalls möchte ich die derzeit vorgeschlagene Darstellung für breite Fenster nicht umgesetzt sehen, bevor eine Umfrage dazu stattgefunden und sich eine Mehrheit dafür ausgesprochen hat. (Der letzten nennenswerten Umgestaltung gingen Meinungsbilder voraus.)
Es gab noch die Frage, warum einzelne Bestandteile in Vorlagen ausgelagert sind. Wenn ich mich richtig erinnere, sollte damit einmal die kaskadierende Seitensperrung für Unterseiten der Hauptseite umgangen werden, was inzwischen anscheinend mit individuellen Seiteneinstellungen gelöst werden kann.
Wer jetzt welche Spitzen und Stenchen haben will, kann auch Monate später umgeschaltet werden. Auch noch weitere Symbole aus sicheren Unicode-Bereichen mögen erörtert werden.
Das gleiche gilt, welche Höhe über der Grundlinie und des Symbols zwischen Text und einem RSS-Icon jetzt genau wer für den Rest der Welt am allersuperoptimalsten halten würde.
Abzulehnen ist unter den runden Varianten der beliebte · (middot), dessen Existenz sehr viele Menschen optisch überhaupt nicht wahrnehmen können.
Abzulehnen ist weiterhin eine größere Kuller-Form als hoizontales Trennzeichen, weil unsere Weiteres-Aufzählung rechtsbündig steht und es dazu kommen kann, dass alle Kuller am rechten Rand genau untereinander stehen, und da dies die gleichen Kuller sind, die wir überall linksbündig wie in dieser Stellungnahme als Aufzählungszeichen verwenden, entsteht der irritierende Eindruck einer gespiegelten Aufzählung mit den Aufzählungszeichen am rechten Rand.
Zeilenumbrüche im Quelltext sind wikisyntaktisch erforderlich, falls du die zwischen den <li> meinen solltest. Sonst macht MediaWiki einen Paragraphen draus.
CSS_Selektoren
Der von dir momentan verwendete Klassenbezeichner .inhalt ist nicht überlebensfähig.
Der ist so ungenau, dass er mit konfligierender Bedeutung bei allen möglichen Gelegenheiten mit allen möglichen Erwartungen zu irgendwas verwendet werden kann.
Klassenbezeichner verwenden wir nur noch mit global voraussichtlich kollisionsfreiem Präfix; hier: .hauptseite-.
Das Wort .inhalt könnte auch den gesamten Inhaltsbereich (content) oder nur die Spalten oder ein TOC meinen; es ist unklar und ich sehe auch in der bisherigen Umsetzung nirgendwo eine Dokumentation der Interpretation wie für die neuen Selektoren vorgelegt.
Vgl. hgzh zur grundsätzlichen Vergabe projektweit/global eindeutiger Klassenbezeichner.
Die ID sind auch als Sprungziele vorgesehen und deshalb möglichst kurz für die URL und Bookmarks gehalten; Dekoration wird über Klassenbezeichner umgesetzt.
Die 2006 mal eingeführten Selektoren hatten einen der vielen Denkfehler oder besser Kurzsichtigkeiten der Kindergartenphase: Nur für wenige Seiten mit nur wenigen Vorlagen und nur ganz wenig CSS vorgesehen; Skalierung auf globale Software mit zigtausenden von Bezeichern auf zweieinhalb Millionen Artikeln mit über zehn Millionen Meta- und BNR-Seiten und über 70.000 Vorlagen im ANR nicht unterstützbar.
Es scheint extrem wenige noch aktive Benutzer zu geben, die eine auf den momentan gültigen Selektoren wirksame persönliche CSS-Spezifikation unterhalten. Ob sie auch mit der fraglichen Skin arbeiten ist unklar.
Ob diese Handvoll Benutzer das tatsächlich zum Arbeiten benötigt oder sich einfach nur von jemand anders mal zum Spielen eine komplette CSS-Seite von jemand anders mit allem Drum und Dran abkopiert hatten, ist nicht ersichtlich. Ich erkenne mehrere Klone der kompletten Wiegels-Spezifikationen wieder.
Die CSS-Designkonzepte von 2006 haben keinen Anspruch auf ewige Unterstützung, erst recht nicht wenn sich das Designkonzept fundamental wandelt und inkompatibel wird.
Es gibt bisher und wohl schon seit einem Jahrzehnt für einzelne Themen individuelle ID wie #mf-tfa (das bedeutet: AdT) oder #mf-nec (seltsames Denglisch?), die bislang noch unterstützt werden, aber nach Ansicht von XanonymusX im Lauf des Jahres eigentlich wegfallen können.
Wenn du eine konkrete Begründung hast, warum es wichtig ist, jedes Thema mit einem besonderen Design zu versehen, dann können die gern verbleiben.
Du, gerade du, bist technisch so versiert, dass du die CSS-Regeln, die du wirklich benötigst, mit Leichtigkeit migrieren kannst.
Sollte für jemand anders sein ganz individuelles Design wirklich weiterhin erforderlich sein, können die zwei oder drei weiteren Benutzer gerne hier oder auf FZW oder in der VWS anfragen; dann kann das wunschgemäß angepasst werden.
flex
Das setze ich durchaus ein, etwa bei der AdT-Wochenverwaltung, die bisher ein starres, unflexibles Layout hatte.
Ich hatte diesen Weg in der Konzeptionsphase durchdacht und erprobt, jedoch verworfen.
Es delegiert die volle Variabilität an den Browser der Leser, und dadurch geht die bisher aufrechterhaltene Abfolge der Inhalte an die bisherigen Gewohnheiten der Zwei-Spalten-Desktopversion und der einspaltigen Mobildarstellung verloren.
Gerade auf der verlinkten Seite lässt sich aber gut das Problem des flex-Designs für die gefühlte Reihenfolge der Inhalte erleben.
Oben (Punkt 1) sollen die Innenabstände mit der derzeitigen Hauptseite übereinstimmen. Es darf sich nirgendwo nichts ändern. Jetzt soll sich auf einmal alles beliebig ändern.
Die schließlich von mir ausgewählte float -Lösung behält die Abfolge und Anordnung auch von einem Tag auf den anderen bei.
Die flex -Variante gestaltet die optische und inhaltliche Reihenfolge von Tag zu Tag anders; je nach den Mengen der Inhalte, die an diesem Tag gerade in den Boxen stehen.
Kann man machen, kann man wollen. Muss man dann aber auch wirklich wollen, und alle hier Mitlesenden müssen sich vorher über die Konsequenzen deines Vorschlags vollumfänglich bewusst sein. Ein Hin und Her und Strategie- und Konzeptionswechsel alle paar Wochen wird es nicht geben, jedenfalls nicht mehr mit mir.
Wenn man jedoch die inhaltliche Reihenfolge beibehalten will, dann kommt, nachdem dem flex ganz viele neue Einschränkungen auferlegt und es gebührend gefesselt wurde, mit viel zusätzlicher Unübersichtlichkeit und mangelnder Robustheit genau das heraus, was die float-Lösung jetzt sehr viel offenkundiger und nachvollziehbar erreicht.
Mein Eindruck ist, dass die Community sehr konservativ ist, und es darf sich nichts nirgends für niemand ändern, und die CSS-Selektoren von 2006 müssen aber auch auf ewig kompatibel bleiben, aber jetzt auf einmal willst du die traditionelle Reihenfolge der Blöcke komplett umschmeißen und bei jedem Leser den Zufällen des Browsers und täglicher Inhaltsmenge überlassen?
Layout und Boxen allgemein
Vollbildansicht der Seite 1920 Pixel Breite überraschend
Bei 1920px Vollbreite würde dir das dreispaltige Layout nicht gefallen. Okay, aber das bisher starre zweispaltige Layout ist unter fairen gleichen Bedingungen noch viel viel schlimmer, und die Textzeilen mit Hunderten von Buchstaben werden völlig unverständlich.
Wie genau du diese Situation nun auflösen möchtest, dass sie auch noch konsistent mit vier- und fünfspaltig wird, erklärst du uns nicht.
Die acht Kästen nehmen dabei vier verschiedene Breiten ein, die im Hauptteil verteilt auf drei Spalten (28%, 28%, 38%) mit einer klaffenden Lücke in der unteren Mitte.
Leser sollen mehrmals täglich das Gerät wechseln können; Desktop 2-spaltig → mobil → Desktop 3-spaltig → mobil → Desktop 2-spaltig → mobil
Dabei darf sich nicht jedes Mal eine andere und unvorhersagbare Reihenfolge ergeben (POLS); es soll zumindest die zweispaltige Vérsion immer genauso aussehen wie sie immer™ schon war, und die dreispaltige Vérsion dann die gleiche Reihenfolge der Inhalte beibehalten.
Genau dieses Prinzip würde jedoch verlassen werden, wenn du die Gestaltung der Seite per flex an den Browser entsprechend des Tagesgeschehens und der momentanen Textmenge delegierst, und dynamisch alle Lücken mit irgendwelchen Inhalten füllst. Kannst du gerne wollen und dir dafür eine breite Zustimmung einholen.
Dass es unterschiedliche Breiten gibt, ist primär unvermeidlich. Die oberste und unterste zentrierte Box definieren sich durch die Menge an Themenportalen und die Menge an Schwesterprojekten, wodurch sich bei maximal verfügbarem Platz je eine Zeile dafür ergibt. Die ist nunmal unterschiedlich, und es sähe noch viel viel viel schlimmer aus, wenn du jetzt diese Boxen auf einem HD-Bildschirm auf 100 % Fensterbreite ziehst – dann ergeben sich riesige weiße Felder innerhalb der Boxen, und du hättest mich als ersten erbitterten Gegner in der Schlange.
Wenn schon, dann kann man diese Frage ganz anders lösen: Weder die oberste noch die unterste Box bekommt noch Titelleiste und Rahmen drumherum; weder zwei- noch drei- noch vier oder fünfspaltig. Die bisher oberste Box ist dann ein Einleitungsabschnitt, wie man das auch aus den Artikeln kennt, und das Willkommen müsste dann am Anfang des Fließtextes integriert werden. Unten genauso; die Schwesterprojekte werden eine Art Fußzeile, die Überschrift der Box wird in eine kleine erläuternde Fließtext-Zeile integriert, und es gibt die Frage der Boxen oben und unten nicht mehr, weder zwei- noch drei- noch vierspaltig. Gerne.
Die hiesige Community ist aber generell ablehnend gegenüber jeglicher Veränderung; deshalb soll das Zwei-Spalten-Layout bei konventioneller Desktop-Situation sich auch nicht erkennbar ändern.
die im Hauptteil verteilt auf drei Spalten (28%, 28%, 38%) mit einer klaffenden Lücke in der unteren Mitte.
Das ist eine Konsequenz aus den Forderungen, dass sich die Reihenfolge der Inhalte nicht ändern soll.
Die linke Spalte, die meist aus zwei Boxen übereinander besteht, wird aufgeteilt in zwei nebeneinander.
Die rechte Spalte mit drei Boxen übereinander bleibt erstmal so wie sie ist.
Weil sie nun aber drei Boxen übereinander enthält, wird sie breiter gemacht, damit sie möglichst wenig Höhe beansprucht. Weil in diesen drei Boxen nur Aufzählungen stehen, bedarf hoffentlich irgendwann jeder Aufzählungspunkt nur eine, veilleicht zwei Zeilen.
Wenn du die klaffende Lücke in der unteren Mitte füllen möchtest, kannst du das ja gern tun, und den Browser je nach Textumfang des Tagesgeschehens beliebig irgendwelche Boxen hinzaubern und den Raum füllen lassen. Dann stimmt aber die gefühlte inhaltliche Reihenfolge nicht mehr, und das wird dann auch wieder sehr vielen Leuten nicht gefallen.
Als Alternative schlage ich vor, dass alle Kästen von einem Element umgeben werden, das den gesamten Inhalt auf eine maximale Breite (die Maßeinheit darf em sein) mit höchstens zwei Spalten einschränkt
Das ist genau die Fortsetzung der bisherigen ausschließlich auf zwei Spalten beschränkten Darstellung; nur zentriert.
Das vernachlässigt jedoch die Bedürfnisse der Leser mit HD-Bildschirmen.
Diese haben gern einen auf 16:9-Kinofilme breitgezogenen aber nicht hohen oberen Bildschirmanteil, und darunter einen Nicht-Internet-Browser-Bereich mit anderen Anwendungen, anklickbaren Icons, Chat-Fenster, aktuelles Fernsehbild.
Die bleiben bei deinem Vorschlag genauso angeschmiert wie bisher auch; den unteren Bereich der HS können sie nicht sehen, links und rechts der begrenzten zweispaltigen Darstellungen bleiben riesige ungenutzte (verschwendete) Flächen, zum Lesen des unteren Bereichs muss erst gescrollt werden.
Genau diese Abkehr von der althergebrachten immer nur zweispaltigen Darstellung, wie man sie auf den Desktops zu Beginn des Jahrhunderts als einzige Möglichkeit sah, unternimmt ja gerade die Neugestaltung.
Generell sind deine Änderungswünsche sehr wolkig. Du beanstandest, dass dir irgendwie was nicht gefallen würde, aber du stellst keine Gesamtkonzeption vor, die konsistent über alle ein-, zwei-, drei-, vier-, fünfspaltigen Erscheinungen nachvollziehbarer wäre und konkret und präzise zeigt, wie genau du dann mit genau welcher Situation umgehen möchtest.
Du müsstest eigentlich einen realitätsnahen Prototyp vorlegen, an dem man interaktiv deine Designwünsche auf verschiedenen Geräten durchspielen kann.
Ich habe mich umgesehen und keine andere Sprachversion gefunden
Es ist mir absolut wurschtschnurzpiepegal, was irgendein anderes Wiki-Projekt macht, und ich sehe mich nicht im allergeringsten daran gebunden, aus diesem Grund irgendwas genauso machen zu müssen.
Allenfalls betreibe ich ein wenig Industriespionage und gucke, was andere auf der Pfanne haben.
Die enWP-Desktopversion ist da ja leuchtendes Beispiel; starre Zwei-Spalten-Aufteilung für jegliche Schriftgröße und Fensterbreite, in unbegrenzter Breite, seit zwei Jahrzehnten verpönte blindenfeindliche Layout-Tabelle.
Wenn du als Vorbedingung stellst, dass es zuerst andere Wiki-Projekte geben müsse, bevor wir HD-Bildschirme unterstützen dürfen, dann kann es niemals irgendeinen Fortschritt geben. Diese Argumentation ist absolut nicht nachvollziehbar.
Jedenfalls möchte ich die derzeit vorgeschlagene Darstellung für breite Fenster nicht umgesetzt sehen
Es steht jedem Leser frei, welche Bildschirme welcher Breite er auf dem Schreibtisch zu stehen oder an der Wand zu hängen hat.
Wer keinen HD-Bildschirm hat und keine extrem breiten Browser-Fenster verwendet, mit dem dann sowieso anschließend die einzelnen Artikel völlig unlesbar in 300 Buchstaben langen Textzeilen dargestellt werden, der bekommt eine drei- oder mehrspaltige Darstellung niemals zu sehen.
Gegenüber dem Status quo kann es für Leser mit sehr breitem Browser-Fenster nur besser werden.
Wir haben beim rem-Schwellenwert in gewissen Grenzen eine Steuerungsmöglichkeit für die dreispaltige Umstellung; darüber lässt sich verhandeln.
bevor eine Umfrage dazu stattgefunden und sich eine Mehrheit dafür ausgesprochen hat. Der letzten nennenswerten Umgestaltung gingen Meinungsbilder voraus
Die Ankündigung in phab:T173379 ist vom 15. August 2017. Die für die HS Verantwortlichen hatten drei Jahre Zeit gehabt, das mit Meinungsbild und Wettbewerb und allem Trara zu organisieren. Null ist passiert.
Es sind komplexe Umstellungen auch des AdT-Vorschlagswesens und diverser anderer Seiten im Hintergrund und für die Organisation erforderlich.
Damit das geschmeidig und ohne Störungen im Betriebsablauf vor sich gehen kann, sind konkrtete Vereinbarungen und auch Absprachen mit Admins zu einem konkreten Zeitfenster in den Nachtstunden erforderlich.
Weil sowas auch schiefgehen kann, ist ein Tag für einen Rollback und eine erneute Nachtschicht einzuplanen.
Damit das fristgerecht sicher fertig wird, und der Prozess geplant werden kann, muss mit Ende der ersten Juliwoche eine definitve Entscheidung vorliegen, um die nächsten Schritte zu starten.
Ich bin erst durch die Ankündigung auf WD:NEU aufmerksam geworden und habe mir das erst (nach TWS) am 16. Juni 2020 näher angeguckt.
Seit 18. Juni sitze ich an einer konkreten Umsetzung, habe dafür vier volle Wiki-Arbeitstage benötigt und bin dann am 24. Juni hier auf dieser zuständigen Seite aufgeschlagen.
Deine Vorstellungen zu Meinungsbildern und Erörterungen von kompletten Alternativlösungen hättest du sehr viel früher einbringen müssen; du liest ja offenkundig WD:NEU mit, kommentiertetetetest das schon am 20. Juni 2020 und hättest dich dort frühzeitiger äußern können.
Insgesamt ist das eine Wasch-mir-den-Pelz-aber-mach-mich-nicht-nass-Problematik.
Es soll überall alles so bleiben wie es immer schon war, und zweispaltig, und nichts darf sich ändern.
Gleichzeitig gehen wir aber jetzt auch auf Menschen mit anderen Geräten, mit schlechten Augen jedoch nicht blind, mit Mobilgeräten oder HD-Fernsehern ein.
Das „früher war alles besser“ setzte voraus, dass alle Leute ganz gute Augen hatten, an einem Schreibtisch vor einem klassischen Desktop-PC saßen, und zum Durchlesen der Hauptseite scrollen mussten.
Für diesen Leserkreis ändert sich doch überhaupt nichts, zumindest wäre mir nichts aufgefallen.
Aber es kamen zunächst die Leutchen mit den Smartphones hinzu, und jetzt die HD-Bildschirme. Und die haben nunmal andere Verhältnisse auf ihren Geräten, und andere Bedürfnisse, und für die ist diese früher-war-alles-besser-es-soll-immer-alles-so-bleiben-wie-es-immer-schon-war einfach nur schlecht und unlesbar oder Platzverschwendung auf dem Bildschirm. Und das sogenannte responsive Design nimmt auf deren Erfordernisse Rücksicht, aber das macht es halt auch unumgänglich, dass dann nicht alles genauso aussehen kann wie es zur Jahrhundertwende war. Es gibt eben auch andere Verhältnisse zwischen Bildschirm(fenster)breite und Bildschirm(fenster)höhe und Bildschirmauflösungen als das, worauf momentan unsere und die enWP-Hauptseite ausschließlich ausgelegt sind.
Über die Middots haben wir ja schon ein Weilchen diskutiert. Ich stimme zu, dass weder der kleine Punkt (wie bisher) noch der Aufzählungs-Knödel optimal sind; ich würde vermutlich das Quadrat wählen (wenn es so mittig positioniert wird, wie aktuell), alles andere ist mir etwas zu auffällig.
IDs: Genau, die mf-Konstrukte haben einzig und allein die Aufgabe, für die nur noch zwei Wochen aktive Skript-Notlösung zur Mobilfreundlichkeit die Inhaltsbereiche auszuweisen; danach haben sie keinerlei Bedeutung mehr und ich hoffe, dass niemand in der Zwischenzeit irgendetwas anderes davon abhängig gemacht hat.
Flex: Das war der erste Ansatz. Mein Entwurf WP:Hauptseite/Neu basiert auf einem ersten Kompromiss, wobei die zwei Grundspalten beibehalten werden und die zwei bis drei Elemente innerhalb als flex gesetzt sind (hat im Grundzustand den großen Vorteil, dass wir mit justify-content arbeiten können). Damit gibt es allerdings lediglich die Optionen einspaltig, zweispaltig und fünfspaltig (die Breite der Kästen wird dabei von den beiden Grundspalten fixiert). Ordentliche Übergänge zwischen diesen Zuständen, bei denen gleichzeitig die Reihenfolge und die grundsätzliche Größe der Kästen nicht unkontrollierbar wird, lassen sich mit Flexboxen leider nicht umsetzen. Die Float-Variante ist nicht ungefährlich, da unerwartete Browser-Skin-Zoom-Kombinationen immer noch böse Überraschungen bescheren können (derzeit wohl nur noch Edge V44), aber einigermaßen kontrollierbar. Wenn wir nicht das Hauptseiten-Layout insgesamt komplett umstoßen wollen (und dazu bräuchte es in der Tat ein Meinungsbild), sehe ich keine bessere Lösung.
Zweck und Kern der Änderung ist eigentlich die verbesserte Mobilversion, und die halte ich jedenfalls für vorbildlich.
Details wie Abstände im Pixelbereich lassen sich noch leicht zeitnah abklären.
Inzwischen habe ich die horizontalen Innenabstände selbst angeglichen, nämlich an die bisherigen Werte, weil die vertikalen padding-Werte auch nicht verändert wurden, und auch die horizontalen Listen (wieder) daran ausgerichtet. Die Trennsymbole, auch die Striche im normalerweise unsichtbaren Inhaltsverzeichnis, sind jetzt symmetrisch platziert, worum es mir eigentlich ging.
Ich sprach von den id-Attributen der Kästen, nicht der Inhalte. Letztere („mf-…“) wurden später für die Mobilversion eingeführt und können hoffentlich ohne Nebeneffekte weggelassen werden. Ich fände es aber schade, wenn man die Kästen nicht mehr durch sprechende Namen wie „#hauptseite-nachrichten“ selektieren könnte, sondern nur per Himmelsrichtung (hier #rechts-oben .hauptseite-box) oder durch Abzählen (hier .hauptseite-box:eq(-4)). Das ist auch sicher nicht im Sinne der Barrierefreiheit.
Die Anpassung für die künftige Nutzung auf Mobilgeräten scheint prima gelungen zu sein und sollte so umgesetzt werden.
Größere gestalterische Änderungen, speziell die Erhöhung der Spaltenzahl für breite Fenster/Bildschirme lehne ich gar nicht grundsätzlich ab, bitte ich aber dringend zurückzustellen, damit ein größerer Kreis von Mitarbeitern Zeit und Gelegenheit findet, den vorgelegten Entwurf zu begutachten, möglicherweise alternative Vorschläge zu machen und sich auf ein Konzept zu einigen, das dann mit Rückhalt umgesetzt werden kann. Ich kann jedenfalls nicht erkennen, warum eine bevorstehende technisch notwendige Anpassung in der Kürze der Zeit um eine Umgestaltung erweitert werden müsste, für die eine Einigekit in der Community nicht sicher scheint. --Wiegels„…“03:59, 29. Jun. 2020 (CEST)Beantworten
id-Attributen der Kästen, nicht der Inhalte. Letztere („mf-…“) wurden später für die Mobilversion eingeführt und können hoffentlich ohne Nebeneffekte weggelassen werden.
In dem Moment, in dem diese ID durch die momentane Neuprogrammierung nicht mehr benötigt werden, sind ihre Zuordnungen zum <div> ja wieder frei, und dann mag irgenwer der sich damit auskennt sie durch sprechende Bezeichner ersetzen. Das ist momentan akut nicht mein Problem.
Wir haben täglich eine Drittelmillion Mobil-Abrufe der HS, die sind mir erheblich wichtiger als ob drei Benutzer ein paar Tage lang ihr privates Styling irgendwelcher einzelner Boxen nicht sehen würden.
Einen Effekt bemerken höchstens diejenigen Anwender vollbreiter oder HD-breiter Bildschirme, bei denen die momentane Darstellung in voller Bildschirmbreite dann erst recht beschissen und unlesbar aussieht, und wenn versucht würde von dort aus einen Artikel zu lesen die Texte bei 500 Buchstaben in einer Zeile schon ausgesprochen guter Lesekompetenz bedürften.
Auf Fäkalsprache pflege ich normalerweise nicht zu antworten, aber die genannte Buchstabenzahl kann ich nicht stehen lassen. Die Darstellung der derzeitigen Hauptseite auf einem 1920 Pixel breiten Monitor (Vollbildansicht mit gängigem Browser und Standardschriftgröße, unangemeldet) ist wunderbar und angenehm zu lesen. Die längste Zeile ist die isoliert stehende Begrüßungszeile mit reichlich unter 200 Zeichen (inklusive Leer- und Satzzeichen) und nur die längste Textzeile im Kernbereich erreicht gerade mal ein Drittel der behaupteten 500 Zeichen. Schamlose Übertreibung hinterlässt keinen gewissenhaften Eindruck. --Wiegels„…“21:27, 29. Jun. 2020 (CEST)Beantworten
Ich hab mir jetzt die Diskussion nicht durchgelesen (ich bin über die Beteiligen-Vorlage hier gelandet). Ich finde diesen Entwurf leider nicht so gelungen. Die Responsivität ist super und funktioniert gut. In meiner Standardauflösung 1920x1200 sieht es aber nicht so toll aus (in der üblicheren Auflösung 1920x1080 sieht es fast identisch aus). Die Jahrestage-Box hängt verloren in der mittleren Spalte herum. Es ist viel weiße Fläche unter dieser Box und auch in der linken Spalte unter der AdT-Box. Außerdem ist die obere Box "Willkommen bei Wikipedia" irgendwie "unrund", weil sie nicht über die gesamte Bildschirmbreite reicht und dementsprechend links und rechts weiße Flächen sind. Außerdem sollten die Jahrestage in der Jahrestage-Box wie bisher in chronologischer Reihenfolge sein (nicht in umgekehrt chronologischer Reihenfolge). -- Chaddy · D16:15, 28. Jun. 2020 (CEST)Beantworten
Die Inhalte sind rein fiktiv; das betrifft auch die Jahreszahlen, verstorbene Personen und angebliche Ereignisse. Es geht lediglich um blindes, bewusst nicht-reales Füllmaterial von vergleichbarem Textumfang.
Die Bildschirmbreite kann auch 2500 Pixel, 3000 Pixel, 3500 oder 5000 Pixel betragen. Und du fändest es schön, wenn auch dann die oberste und unterste Box von ganz links bis ganz rechts außen reicht?
Bei der von dir benannten Breite sieht unser momentanes zweispaltiges Design dann aber auch schlecht aus; die Textzeilen haben viel zu viele Buchstaben pro Zeile, und sind nicht mehr lesbar. Wären diese beiden Spalten jedoch so begrenzt, dass die Anzahl der Buchstaben in jeder Zeile auch für ein breites Publikum gut verständlich sind, dann wird viel zu viel Platz auf dem Bildschirm verschenkt, und die sogenannten HD-Benutzer beschweren sich, dass sie zu viel scrollen müssen und der sichtbare Bereich nicht ausgenutzt wurde. Dies ist bereits weiter oben umfassend thematisiert worden.
@Aufzählungstrenner
Die Umrissformen wie U+25CB ○ scheiden aus, weil sie als Buchstaben (O Tannenbaum) gelesen würden; werden dann auch zu mager und trennen nichts mehr.
Zeichen mit politisch-religiös-gender-Konnotation verbieten sich von selbst.
Bleiben eigentlich nur einige ausgefüllte geometrische Grundformen übrig, die intuitiv als Trennzeichen verstanden würden; mit zwei, drei, vier, fünf Ecken oder Spitzen.
An CSD und Valentinstag könnte ich noch U+2665 ♥ anbieten.
Zunächst möchte ich euch einmal für eure Arbeit danken, es ist ja schon mehrfach der Wunsch aufgetaucht die HS zu verändern. Ich hätte mir allerdings gewünscht dass ihr die HS-Mitarbeiter ein wenig mehr mit eingebunden hättet und vor allem es auch in einfachen Worten erklärt hättet. Ich hab's versucht zu lesen, aber verstehe nicht mal die Hälfte.
Ich beteilige mich bei AdT, dabei verstehe ich den Satz nicht: Es sind komplexe Umstellungen auch des AdT-Vorschlagswesens und diverser anderer Seiten im Hintergrund und für die Organisation erforderlich. Was genau bedeutet das? Habt ihr auf der AdT-Seite auch mal was dazu geschrieben?
Auf meinem Laptop sah die Seite unglücklich aus, mit einem geringeren Zoom war's Layout grundsätzlich besser, aber dann kann ich es nicht mehr lesen. Aber meine persönlichen Probleme sind mir nicht so wichtig.
Was mir aber noch wichtig ist: Bei WGA am habt ihr (soweit ich das sehe), immer 6 Punkte, dort erscheinen aber immer 5.
Wie am Anfang geschrieben, ich schätze eure Mühe, aber so wie ihr das ganze aufbaut ist es vielen unmöglich dem zu folgen und gerade diejenigen sind die wichtige, weil HS-Mitarbeiter (oder Rubrik-Mitareiter). (nicht signierter Beitrag vonSophie Elisabeth (Diskussion | Beiträge) 00:16, 29. Jun. 2020 (CEST))Beantworten
Die Programmierung der Seiten, die das AdT-Vorschlagswesen kanalisieren, wird sich durch die Reorganisation massiv ändern.
Was sich nicht ändert, sind die organisatorischen Abläufe der AdT; die bekommén davon entweder nichts oder allenfalls zusätzliche Features mit.
Deshalb war auf der AdT-Seite auch nichts zu schreiben.
Im allersten Posting steht deshalb auch: „Am organisatorischen Management der Vorschläge ändert sich im Wesentlichen nichts“
Die Inhalte der Boxen sind rein fiktiv und haben nur die Aufgabe, einen ungefähr ähnlichen Textumfang zu erzeugen, damit die übliche Größe der Boxen verglichen werden kann. Mit wie vielen Punkten und in welcher zeitlichen Reihenfolge die nicht existenten Nicht-Ereignisse aufgezählt werden, ist irrelevant.
Im Übrigen erinnere ich daran, dass hier keine Absicht von mir ausgeht, sondern dass die für die Hauptseite Verantwortlichen es seit August 2017 versäumt haben, die angekündigte Einstellung der formatierten Mobil-Hauptseite umzusetzen.
Es ist denke ich vollkommen klar, dass das hier erstmal nur ein privater Entwurf ist. Wenn tatsächlich eine Änderung der Hauptseite geplant ist, ist es denke ich selbstverständlich, dass bereits in den Ausarbeitungsprozess selbst eine breite Basis der Community eingebunden ist. Und am Ende muss natürlich per MB darüber abgestimmt werden.
Und doch, es ist sehr wohl wichtig, wie es bei dir aussieht. Wenn es bei dir unglücklich aussieht, dann ist dieser Entwurf noch nicht gut genug und es muss nachgebessert werden. Es ist aber denke ich selbstverständlich, dass das auch noch geschehen wird. Zumal du ja nicht die einzige bist, bei der der Entwurf optisch eher unglücklich aussieht. -- Chaddy · D04:43, 29. Jun. 2020 (CEST)Beantworten
Hier ist keine „Änderung der Hauptseite geplant“; vielmehr wurde mit viel Aufwand versucht, für die Verwender normalbreiter Desktop-Bildschirme mit zweispaltiger Darstellung diese unverändert zu erhalten.
Einen Effekt bemerken höchstens diejenigen Anwender vollbreiter oder HD-breiter Bildschirme, bei denen die momentane Darstellung in voller Bildschirmbreite erst recht beschissen und unlesbar aussieht, und wenn versucht würde von dort aus einen Artikel zu lesen die Texte bei 500 Buchstaben in einer Zeile schon ausgesprochen guter Lesekompetenz bedürften.
Im Übrigen erinnere ich daran, dass hier keine Absicht von mir ausgeht, sondern dass die für die Hauptseite Verantwortlichen und ach so sehr um die Gestaltung besorgten Diskutanten es seit August 2017 versäumt haben, die angekündigte Einstellung der formatierten Mobil-Hauptseite in Meinungsbilder und Design-Wettbewerbe umzusetzen. Ich wurde erst durch die letzte Warnung der WMF vor bevorstehender Abschaltung auf die Angelegenheit aufmerksam. Auf dieser Disku hier hat man es erst durch meine Abschnittseröffnung vom 24. Juni mitbekommen.
Nebenbei wird die HS zu rund einem Drittel über Mobilgeräte abgerufen, über eine Drittelmillion jeden Tag. Die willst du also lieber zerschossen sehen, als auf dein geliebtes MB zu verzichten?
Nein, ich will eben gerade nicht zerschossen sehen und bin deshalb dagegen, dass der Entwurf so wie er aktuell ist, umgesetzt wird. Wie ich schon geschrieben habe und wie die IP weiter unten auch nochmal schreibt ist die dreispaltige Ansicht zerschossen. Da muss nochmal nachgebessert werden.
Die aktuelle Hauptseite sieht auf einem HD-Bildschirm übrigens nicht so schlecht aus, besser jedenfalls als der zerschossene Entwurf auf einem HD-Bildschirm aussieht.
Das 1- und 2-spaltige Layout sieht gut aus, und auch der Umschaltpunkt passt für meinen Geschmack. Was ich aber furchtbar finde, ist der unterschiedliche Spaltenabstand je nach Spaltenzahl. Was soll das? Technisch sehe ich da jedenfalls keinen Grund, das ist doch einfach die margin-right-Eigenschaft der Boxen. Wenn die width jeweils dazu angepasst wird, ist das doch kein Problem das einheitlich zu machen. Wenn man beides in % angibt ist die Rechnung auch nicht schwer. --Wickie3711:31, 29. Jun. 2020 (CEST)Beantworten
Habs jetzt mit dem Quelltext-Inspektor von Firefox ausprobiert. Mit einheitlich 1% oder 1.2% margin-right wirkt vor allem das Umschalten zwischen den verschiedenen Spaltenzahlen auf mich deutlich angenehmer. --Wickie3711:54, 29. Jun. 2020 (CEST)Beantworten
Oh prima, dann lege uns doch bitte deine Berechnungen exakt und in codierter Form vor und demonstriere die Funktionaliät an deiner eigenen Demonstratonsseite. Wenn das alles so einfach ist.
Die Geschmäcker sind verschieden, und auf realen HD-Bildschirmen („Kinoleinwand“) ist der Gesamteindruck ein deutlich anderer als bei Simulation mittels Zoom-Funktion auf einem normalgroßen Bildschirm; auch was die Wirkung der Abstände betrifft. Deine auf einem kleinen Bildschirm, mutmaßlich mit nicht lesbarer Schrift, simulierte Darstellung sieht auf einem Breitbild-Fernseher mit 100 Zoll Bildschirmdiagonale dann doch wieder ganz anders aus.
Bedenke bitte auch, dass kaum ein Benutzer die unterschiedlichen mehrspaltigen Darstellungen nacheinander in der gleichen Stunde mitbekommt; wenn, dann ist es ein Wechsel Smartphone → Schreibtisch → Smartphone → Wohnzimmercouch → Smartphone.
Normale Leser praktizieren kein „Umschalten“ zu Testzwecken, sondern sie lesen am Schreibtisch oder auf ihrem HD-Bildschirm, und sehen jeweils immer die gleiche Darstellung.
Ein gleicher Abstand in % ist auf der Kinoleinwand trotzdem noch breiter, als auf dem PC-Bildschirm. Und das Umschalten zwischen 3 und 2 spaltig hat man mit einem 1920-Pixel-Monitor jedes mal, wenn man zwischen Vollbild-Anzeige und zwei Fenster nebeneinander wechselt. --Wickie3712:49, 29. Jun. 2020 (CEST)Beantworten
Wobei mir gerade auffällt, dass mein Vorschlag für den Fall gar nichts bringt, weil % natürlich abhängig von der Fensterbreite sind. Ok, da muss ich nochmal überlegen, wie man das am besten umsetzt. --Wickie3712:55, 29. Jun. 2020 (CEST)Beantworten
Alternativvorschlag: margin-right einheitlich auf 1em festlegen und width jeweils über calc(...) berechnen, wie Du das beim 2-spaltigen sowieso schon benutzt. Mit vom Sofa lesbarer Schriftgröße sollte der Abstand dann auch auf der Leinwand angemessen sein und bei konstanter Schriftgröße bleibt der Abstand erhalten unabhängig wie groß man das Fenster zieht. --Wickie3713:18, 29. Jun. 2020 (CEST)Beantworten
Hier hab ich das mal umgesetzt. Das lädt Deine Demo und fügt diesen zusätzlichen CSS-Code hinzu. Evtl. muss man die width bei 4-5 Spalten noch um 0,1% verringern, um Rundungsfehler zu verhindern. Bitte wer Zeit hat mal ausprobieren, wie das auf sehr großen Bildschirmen aussieht, ich hab hier leider keinen zur Verfügung. --Wickie3714:33, 29. Jun. 2020 (CEST)Beantworten
Zunächst einmal danke für die Arbeit, die in die Neugestaltung hineingeflossen ist, und danke auch für die umfangreichen Erläuterungen, die ich zumindest teilweise verstehe. Technisch ist soweit alles in Ordnung. Was mich aber (auch als aktuell Nur-Leser) wirklich stört, ist die Aufteilung der Kästen bei breiten Bildschirmen, also in der dreispaltigen Ansicht. Dann rutscht das "Was geschah am XXX?" aus der ersten in die zweite Zeile und die dritte Zeile kriegt mit "In den Nachrichten", "Kürzlich Verstorbene" und (ganz unten) "Schon gewusst?" Überlänge. Das sorgt einerseits für eine Marginalisierung von "Schon gewusst?", in meinen Augen mit die wichtigste Rubrik der Hauptseite und eine wichtige Anerkennung für aktive Wikipedia-Autoren. Bei meinem Bildschirm wird es die einzige Rubrik, für die man erst nach unten scrollen muss, während einem alles andere direkt präsentiert wird. Andererseits erhält dafür die denkbar unkreative und irgendwie beliebige Rubrik "Was geschah am XXX?" ganz oben in der mittleren Spalte eine völlig neue Prominenz, als wäre WP ein Geschichtslexikon. Anscheinend resultiert diese Aufteilung wohl einfach aus der aktuellen Anordnung der Boxen in der zweispaltigen Fassung und war keine bewusste Entscheidung. Trotzdem sollte man darüber nachdenken. (Wenn ich mich recht erinnere, war bei einem früheren Ansatz zur Neugestaltung der Hauptseite sogar erwogen worden, die Rubrik "Was geschah am ...?" völlig zu streichen, um die Hauptseite übersichtlicher zu gestalten.) Viele Grüße, 77.180.187.1013:08, 29. Jun. 2020 (CEST)Beantworten
Die Breite der Spalten in der dreispaltigen Ansicht muss man sicherlich nochmal anpassen, wenn da noch die Bilder reinkommen, wie es auf der derzeitigen Hauptseite ist, wird der Unterschied der Spaltenlängen noch größer.Mein Adblock war zu scharf und hat mir die Bilder verborgen --Wickie3713:22, 29. Jun. 2020 (CEST)Beantworten
Die Jahrestage-Rubrik sollte schon beibehalten werden. Das ist meistens recht interessant. Und ja, Wikipedia ist schon auch ein "Geschichslexikon". Geschichte ist ein besonders wesentlicher Teil der Menschheit und sollte daher schon einen besonderen Platz auf der Hauptseite finden. Wenn, dann würde ich eher auf die IdN-Box verzichten. Wikipedia ist nämlich tatsächlich kein Nachrichtenportal. Und diese Rubrik sorgt auch immer wieder für Streit und verleitet erst Recht zum newstickern. -- Chaddy · D14:34, 29. Jun. 2020 (CEST)Beantworten
Hallo PerfektesChaos, danke für deine bzw. eure Arbeit, das Problem kurzfristig und gleichzeitig fundiert zu lösen! Allerdings habe ich, wie auch einige Vorredner, mit dem dreispaltigen Layout bei 1920px Bildschirmbreite gewisse Bauchschmerzen. Du schreibst oben: "Für diesen Leserkreis ändert sich doch überhaupt nichts, zumindest wäre mir nichts aufgefallen." Wenn man sich die Abrufstatistiken anschaut, erfolgen immer noch mehr als 60% der Hauptseitenaufrufe vom Desktop aus. Ich würde einfach einmal behaupten, dass eine (relative) Mehrheit dieser User einen Full HD-Bildschirm besitzt, und auf diesem gibt es nun im Entwurf drei statt zwei Spalten mit suboptimaler inhaltlicher (Jahrestage in der Mitte) und layouttechnischer (rechte Spalte deutlich länger) Anordnung. Ich muss zugeben, dass ich mich mit modernem CSS nicht besonders gut auskenne (meine CSS-Kenntnisse datieren eher aus der Ära, in der auch die "alte" Hauptseite entstand ;) ), hoffe aber, dass es (als "Quick fix") kein Problem ist, die Schwelle für den Übergang von zwei- zu dreispaltigem Layout zumindest ein wenig höher zu setzen, sodass das Layout auf den Full-HD-Bildschirmen weiterhin zweispaltig ist.
Noch ein kleiner Punkt: In der einspaltigen Ansicht haben mich die "Nach oben"-Dreiecke anfangs ein wenig verwirrt, da ich sie in der mobilen Ansicht eher mit der Funktion Ein-/Ausklappen assoziiert hätte. Außerdem finde ich die ausgefüllten Dreiecke etwas aufdringlich, aber das ist nun wirklich Geschmacksache (vielleicht könnte man sie aber auch ganz weglassen?). Grüße, --Földhegy (Diskussion) 14:27, 29. Jun. 2020 (CEST)Beantworten
Die Grenze sollte definitiv geändert werden. Denn bei Standardschriftgröße liegt die Grenze exakt bei 1920px. Das bedeutet auf einem 1920px-Bildschirm hat man bei einem maximierten Fenster 3 Spalten, bei einem auf Bildschirmgröße aufgezogenen Fenster aber nur 2 Spalten. Das könnte für viele Nutzer sehr verwirrend sein. --Wickie3715:27, 29. Jun. 2020 (CEST)Beantworten
+1 Breakpoints stellen im Responsive Webdesign die Extrema und nicht die Optima dar und sollten deshalb möglichts zwischen den Standardauflösungen liegen und nie genau auf diesen. // Martin K. (Diskussion) 21:47, 29. Jun. 2020 (CEST)Beantworten
Es gibt keinerlei Abmessungen in Pixeln (allenfalls die Strichbreite der Rahmen).
Alle Schwellenwerte richten sich nach der Anzahl der Buchstaben in einer Zeile, und damit davon abhängig, welche Schriftgröße und ggf. Schriftcharakteristik sich Leser eingestellt haben.
Heißt: Wer nicht gut gucken kann und sich ggf. große Buchstaben eingestellt hat, bekäme einspaltig, und damit richtige Zeilen und nicht nur drei Wörter nebeneinander in einer Spalte.
Wie viele Pixel das sind, ob das Mobilgerät oder Desktop wäre, ob eine Kinoleinwand aber auch passend riesige Buchstaben zeigt und wieder zweispaltig würde – alles das hat nichts mit der Hardware-Auflösung zu tun.
@PerfektesChaos: Das wäre schön, wenn (r)ems tatsächlich der Anzahl der Buchstaben entsprechen würden. Zumindest bei nicht-proportionalen Schriften ist das aber nicht der Fall, sondern 1 (r)em entspricht schlicht der Schriftgröße in pt. Standard in allen mir zur Verfügung stehenden Browsern sind 16 pt. Bei Standard-Bildschirmeinstellungen mit 1pt=1px ergibt sich damit für 1920px-Bildschirme 1920 / 16 = 120 rem = genau der Wert, den Du für die Umschaltung zwischen 2 und 3 Spalten gewählt hast. Und ich gehe davon aus, dass eine große Mehrheit der Leser alles mit Standardeinstellung benutzt, daher sollten diese auf jeden Fall berücksichtigt werden. --Wickie3719:58, 30. Jun. 2020 (CEST)Beantworten
Auch von mir danke an alle, die hier die Initiative ergriffen und eine technische Anpassung der Hauptseit angestoßen haben. Angesichts der kurzen Zeitraums ist es sicher sinnvoll ein solches rein technisches Refitting kurzfrsitig live zu schalten.
Die Hauptseite ist aber nicht nur technisch sondern auch gestalterisch gewaltig in die Jahre gekommen. Das Layout mit den abgesoften Boxen und Pixellinienrändern kann seine Herkunft aus dem vorletzten Jahrzehnt kaum leugnen.
Da das Webdesign und CSS heute wesentlich mehr Möglichkeiten bietet und auch dei Nutzerbedürfnisse sich gewaltige geändert, würde ich dafür plädieren, das Layout und die Inhalte der Hauptseite mittelfristig noch mal grundlegend zu überarbeiten. Hierfür braucht es dann aber mehr Zeit als gerade möglich ist und eine offene Konzeption und Diskussion von Layout-Alternativen bevor diese in Code und Doku festgezurrt werden. An einem solchen Prozess würde ich mich gerne beteiligen. // Martin K. (Diskussion) 22:11, 29. Jun. 2020 (CEST)Beantworten
Absolut. Ich habe mir in den letzten Wochen sowohl die hier in der Vergangenheit abgehaltenen MBs und Umfragen zum Thema zu Gemüte geführt als auch Hauptseiten anderer Sprachversionen verglichen. Da könnte man wirklich viel machen. Kein Thema für jetzt, das muss uns allen klar sein, aber sicher eine Initiative für die nähere Zukunft.–XanonymusX (Diskussion) 22:37, 29. Jun. 2020 (CEST)Beantworten
Zuerst vielen Dank für die kurzfristige Entwicklungsarbeit! Folgende Anmerkungen habe ich (wobei ich das nicht mit großem Monitor testen konnte)
Die Besucher in Zukunft auch im mobilen Layout zu begrüßen finde ich sehr gut!
Die Anordnung der Kästen ist gut. Es entspricht unseren Lesegewohnheiten von oben nach unten und von links nach rechts.
Wie oben schon von anderen kundgetan, würde ich einen zentrierten Einleitungs- und Schlusskasten mit voller Breite bevorzugen, möglicherweise erst ab einer bestimmten Auflösung? Weiß nicht, ob das so einfach möglich ist …
Die obige Ergänzung von Wickie37 für konstante (kleinere) Spaltenabstände sieht mMn auf den ersten Blick besser aus
Die Trennbullets (✦) gefallen mir (vielleicht die Abstände noch etwas verringern, z. B. analog zum Abstand Aufzählungsbullet – Text)
Die Trennbullets könnte möglicherweise man für mehr Einheitlichkeit auch in der Willkommenbox nutzen
RSS-Feed-Icon ist raus. Finde ich gut, war zu prominent.
Im mobilen Layout entfallen die Links zu den Portalen und zum Archiv: ist das so gewollt?
In der einspaltigen Version fehlen bei mir die Icons zu den Schwesterprojekten: Warum?
Die Hochdreiecke im mobilen Layout sollten mMn entfernt werden, die Seite ist nicht so übermäßig lang und das Scrollen sollte Aufgabe des Browsers sein. Außerdem habe ich beim Klick auf das Dreieck erwartet, das der Kasten dann eingeklappt wird.
Übrigens gefällt mir die kaputte, aber aufgeräumtere Version ohne Boxen und mit standardisierten Überschriften hier fast noch mehr und ich könnte mir vorstellen, dass die Hauptseite in Zukunft so ähnlich aussehen könnte (mit Responsive Design für verschiedene Geräte), aber das sollte dann tatsächlich in einem gesonderten Meinungsbild diskutiert werden.
Vorweg: Alles, was mit Pixel – rem – Art von Trennzeichen – Größe und Position und Abstände zu Trennzeichen – Prozent usw. usw. zu tun haben, kann hinterher immer noch nach Allgemeingeschmack justiert werden, und man mag zur Bestimmung von Prozentbruchteilen auch Meinungsbilder veranstalten und Mediane berechnen.
Ich hatte jetzt Werte genommen, die mir und XanonymusX und weiteren konvenierten, und die sinnvoll erscheinen.
Die Geschmäcker sind jedoch verschieden, und innerhalb einiger objektiver NoGo gibt es eine ziemliche Bandbreite an möglichen Justierungen.
Es musst jedoch irgendeine sinnvolle mutmaßlich einen breiten Volksgeschmack treffende Auswahl getroffen werden.
Manche Menschen brauchen auffallende, massive Trennzeichen, um sie zu verstehen und ihre Funktion im Text zuzuordnen. Wikipedianer kommen mit winzigen Zeichen aus, weil sie die Seite ja schon kennen und dafür votieren, dass die möglichst klein sein sollen.
Zu 7.) „RSS-Feed-Icon ist raus. Finde ich gut, war zu prominent.“
Zu früh gefreut. Fällt wegen Platzmangel aus der einspaltigen Version heraus, ab zweispaltig nach wie vor drin, weil bei zweispaltig war es immer schon drin gewesen, und die zweispaltige Darstellung darf sich nicht um ein μ ändern gegenüber dem Zustand wie es immer schon gewesen ist.
Zu 8.) „Im mobilen Layout entfallen die Links zu den Portalen und zum Archiv: ist das so gewollt?“
Ja.
Es muss mit Platzmangel gerechnet werden, und Leser sollen auf den ersten Blick auf ihr Smartphone bereits möglichst schon zum Wesentlichen und Neuen kommen.
Themenportale wären genauso über die Artikel-Kategorien erreichbar. Es navigiert aber niemand über Geo → Kontinente → Staaten → Städte → Zürich, sondern gibt das ins Suchfeld ein.
Zu 9.) „einspaltigen Version fehlen die Icons zu den Schwesterprojekten: Warum?“
Wie vor: Platzreduktion, Fokussierung auf das Wesentliche.
Man muss schon wissen, was die darstellen sollen. Wikipedianer kennen die, Außenstehenden sind sie keine Hilfe. Wer kennt und weiß auswendig aus dem Icon für Wikiversity, Wikiquote und selbst dem zigmal aufgesuchten rätselhaften Commons-Medienarchiv-Icon auf Anhieb Sinn und Wirkung zuzuordnen?
Einen Punkt hast du neu aufgebracht: Wenn die nicht erkennbaren Icons in der „Mobilversion“ rausfallen, dann sollten die durch die allgeminen kleineren Trennzeichen ersetzt werden.
Momentan lautet die Regel: Breiten Abstand, wo Icons stehen.
Ist aber ziemliche Tüftelei, und die gibt es wenn dann erst im Nachgang.
Zu 10.) „Hochdreiecke im mobilen Layout sollten mMn entfernt werden“
Mir wurde auch schon berichtet, dass das mobil nicht so ganz einfach wäre.
Beachte übrigens, dass „einspaltig“ nicht notwendigerweise „mobiles Layout“ bedeutet, dazu unten mehr.
Dieses Dreieck ist die in commons:OOUI icons vorgesehene Darstellung; expandieren/kollabieren ist bzw. – aber deren Stern ist sowieso grad im Sinken.
ist eigentlich gemeint, ich habe das jetzt erstmal ersetzt, sollte aber ggf. nochmal etwas anders gezeichnet werden.
Bedenke, dass diese einspaltige Darstellung nicht nur auf Mobilgeräten zu sehen ist, sondern auch für Menschen mit sehr schlechten Augen.
Stell dir vor, jemand hat die Schriftgröße so eingestellt, dass jeder Buchstabe so groß ist wie dein Fingernagel.
Die Umschaltung soll zukünftig nichts mit der Anzahl der Pixel eines Gerätes zu tun haben, sondern damit, wie viele Buchstaben in eine Zeile passen. Momentan zeigen wir auf dem Desktop immer zweispaltig an, auch wenn Menschen mit schlechten Augen dann zurzeit nur zwei oder drei Wörter in jeder Zeile dargestellt bekämen.
Nun ist da jemand, der in irgendeinem Alter keine guten Augen hat; wie gut mag es mit der Feinmotorik bestellt sein, wie gut Schieberregler an einem Browser zu treffen, wenn Augen und Finger nicht mehr so wollen?
In der Titel-Leiste ist hinreichend Platz für das verbesserte Dreieck; das wird die Jungspunde nicht umbringen.
Ganz glücklich war ich mit dem etwas rustikalen Dreieckspfeil ja auch nicht, aber den neuen finde ich noch ungünstiger, speziell weil er bei mir jetzt am unteren Rand der Überschriftszeile klebt.—XanonymusX (Diskussion) 02:03, 1. Jul. 2020 (CEST)Beantworten
@Morten Haan: Mit Safari teste ich auch. Könntest du deinen zweiten Satz noch einmal genauer ausführen? Welche Mobilansicht meinst du, die m-Domain? Und was genau ist das Problem, die Spalten sollen ja jeweils die Hälfte des Browsers einnehmen, wenn es zwei sind? Gruß—XanonymusX (Diskussion) 02:03, 1. Jul. 2020 (CEST)Beantworten
Ach so. Ja, auf die Sidebar haben wir so oder so keinen Einfluss. Und wer zoomt schon (außer eben zu Testzwecken) regelmäßig am Desktop so weit rein? Ich lasse mir die Sidebar übrigens auch heute schon per Skript ausblenden.—XanonymusX (Diskussion) 20:22, 2. Jul. 2020 (CEST)Beantworten
Keine der beiden Boxen tut das, vielmehr richten sich beide nach der Maximalbreite ihres Inhalts aus. Für meinen Geschmack könnte man der oberen aber durchaus ein bisschen mehr Spielraum mitgeben. —XanonymusX (Diskussion) 10:52, 2. Jul. 2020 (CEST)Beantworten
Auf der derzeitigen Hauptseite gehen "Willkommen bei Wikipedia" und "Schwesterprojekte" bei mir mit Firefox und voller Bildschirmgröße (1920 Pixel) über die volle Breite. Auf der Beta-Seite ist das für "Schwesterprojekte" immer noch der Fall, für "Willkommen bei Wikipedia" aber nicht mehr. Das ist für mich schon eine signifikante Verschlechterung im Aussehen, da es unsymmetrisch wirkt. -- 2001:A61:3522:7101:7534:DD66:9356:54B712:19, 3. Jul. 2020 (CEST)Beantworten
Kurzer Feedback: Kann von mir aus so freigegeben werden. Nur: Die Darstellung auf dem Internet Explorer 11 (sowie IE 8-10 zumindest "grundlegend") müsste noch angeschaut werden. Auf dem Beta-Wiki überlappt der Content mit der Seitenleiste, aber das betrifft nicht nur den neuen Hauptseiten-Entwurf sondern das ganze Beta-Wiki (ein margin-left von geschätzt 12em (also Seitenleisten-Breite) direkt auf dem Body-Element (nicht .mw-body) löst unter IE11 das Problem). Man müsste das auch noch auf dem "echten" Wikipedia anschauen, da das Beta-WP hier auf grund des generellen Darstellungsproblems unter IE11 keine Referenz sein kann (vorausgesetzt, im Zuge des Hauptseiten-Entwurfs ging da nicht was kaputt, nachdem es vorher ok war). Frühe auf EdgeHTML aufbauende Edge-Versionen hingegen würde ich vernachlässigen (d.h. nur Chromium/Blink-basierende berücksichtigen, vgl. auch [2]: Nur aktuelle und die Vorversion). --Filzstift (Diskussion) 10:14, 2. Jul. 2020 (CEST)Beantworten
Der Explorer ist in der Tat kein Problem in der echten WP; die Entwickler werden den neuen Vector dann hoffentlich noch entsprechend nachrüsten, bevor sie ihn großflächig freischalten. Für Edge wollte ich mir noch einmal anschauen, ob eine kleine Änderung an den Breakpoints die Ansicht auch noch retten könnte, aber wenn nicht, kann man das vermutlich wirklich vernachlässigen. —XanonymusX (Diskussion) 10:52, 2. Jul. 2020 (CEST)Beantworten
@Filzstift:
Schönen Dank.
Auf dem BETA-Wiki wird der neue Vector und ggf. auch weitere Skin-Entwicklung erprobt.
Deshalb kann sich das dort von Tag zu Tag ändern, weil dort die zehn Sekunden alten noch nicht durch den Review gegangenen Programmierungsexperimente getestet werden.
Wir dürfen unsererseits zurzeit nicht in die Fundamentalkonfiguration eingreifen, und irgendwie solch einem Effekt entgegenwirken, weil sonst ein Programmierer vorbeikäme und sehen würde, dass mit seiner Programmierung alles in Ordnung sei (wobei die eher in die enWP@BETA gucken würden), und das Problem nicht beseitigen kann.
Die Erprobung zukünftiger Software erfolgt auf BETA, basierend auf den in der Zukunft erwarteten Browsern.
Ohne Microsoft-Versionen jetzt genauer untersucht zu haben, dürfte deine Schilderung auf die von mir oben unter #Microsoft zu nav beschriebene Situation zurückgehen. Wie sich deren Einsatz auf zeitgemäße Browser auswirkt (wurde wohl schon vor 2010 in HTML5 definiert und wird seit den früheren 2010ern etwa durch Firefox unterstützt), ist Ziel der BETA-Erprobung. Sobald man den neuen Vector produktiv schaltet, und die Microsoft-Produkte in den Abrufzahlen noch relevant sind, wird man diese vorläufig auf div zurückhalten.
Bisher wurde das Problem leider nicht behoben, deshalb möchte ich nochmal darauf hinweisen: Auf Full-HD-Displays ist dieser Entwurf völlig zerschossen. Das sollte dringend repariert werden, andernfalls bin ich entschieden gegen eine Veröffentlichung dieses Entwurfs. -- Chaddy · D14:14, 2. Jul. 2020 (CEST)Beantworten
Rückfragen:
Was genau hat die „neue“ Hauptseite damit zu tun?
Wie sähe unter identischen Bedingungen die bisherige Hauptseite denn aus?
Unter was für Bedingungen (Skin, physische Auflösung, ggf. Zoom-Faktor, Vollbild-Modus, Browser, -Version, Domain) ist denn dieser Screenshot entstanden?
Was genau ist daran „völlig zerschossen“, falls das irgendein Ausschnitt aus dem Gesamt-Bildschirm wäre?
Wenn ich die Diskussion hier richtig verstanden habe, soll dieser Entwurf die aktuelle Hauptseite der deutschsprachigen Wikipedia ersetzen (natürlich nur in technischer, nicht in inhaltlicher Hinsicht).
Die bisherige Hauptseite sieht unter denselben Bedingungen so aus, wie sie sollte: Sie hat das ganz normale zweispaltige Design, nichts ist irgendwohin verrutscht und die obere Box folgt der Breite des Seiteninhalts.
Dieser Screenshot des Entwurfs im Beta-Wiki entstand unter den dort vorgegebenen Standard-Bedingungen für unangemeldete Leser. Die Auflösung meines Desktops ist wie bereits geschrieben 1920x1200, ich habe keinen Zoom eingestellt. Browser ist Firefox 78.0.1.
Dein Screenshot lässt den Kopfbereich der Skin aus.
Damit hat die Programmierung der neuen Hauptseite nichts, aber so absolut rein gar nichts zu tun.
Es gibt keinerlei Möglichkeiten für den Inhaltsbereich, den Kopfbereich der Skin zu beeinflussen.
Auf BETA wird der zukünftige Vector-Skin erprobt; dabei kann es täglich zu allerlei Artefakten kommen, die ein paar Stunden später auch wieder weg sind.
Besser mal mit &useskin=monobook ausprobieren.
Das ginge auch für unangemeldete Benutzer.
Der Screenshot, wie sich die normale Hauptseite auf BETA unter völlig identischen Bedingungen verhalten würde (es ist strukturell unsere bisherige), wurde trotz Rückfrage nicht mitgeliefert.
Vielleicht können sich einige der Mitleser der Frage annehmen und die Darlegungen erforschen.
Der Kopfbereich ist vollkommen egal, es geht um das Durcheinanderrutschen der Boxen und dass die obere Box nicht mehr über die gesamte Breite des Inhalts reicht. Und das Problem taucht auch nicht jetzt erst zufällig auf, sondern wurde hier in der Diskussion nun schon mehrfach von verschiedenen Personen berichtet (mit irgendwelchen Tests am Vector-Skin hat es also nichts zu tun, sondern wirklich speziell mit eurem Hauptseiten-Entwurf). Mit dem Mobobook-Skin sieht es ähnlich aus (siehe neuer Screenshot). Und von welcher Hauptseite auf Beta möchtest du denn einen Screenshot haben? Die Beta-Hauptseite?
Ich habe leider den Eindruck, dass du hier um das Problem herum schreibst, statt einzusehen, dass dieses auf meinem Screenshot deutlich zu erkennende Verhalten absolut nicht gut ist. -- Chaddy · D15:52, 2. Jul. 2020 (CEST)Beantworten
Nun ja, das mag ein beiderseitiges Missverständnis sein. Wenn du dir Doku und die einleitenden Worte hier durchliest, wirst du sehen, dass das eben keine „zerschossene“ Ansicht ist, sondern genau der erwünschte Effekt auf der Grundlage präziser Layoutüberlegungen. Der wurde zwar von einigen anderen Benutzern als zumindest gewöhnungsbedürftig beschrieben, aber ein zerschossenes oder „absolut nicht gut[es]“ Layout kann ich beim besten Willen nicht erkennen. Meinetwegen könnte man auch auf die dreispaltige Version verzichten und danach gleich auf vier Spalten springen, aber das ist durch die Zeilenlänge-Abhängigkeiten eher kompliziert zu realisieren.—XanonymusX (Diskussion) 20:22, 2. Jul. 2020 (CEST)Beantworten
Der „Effekt“ scheint mir bisher nur von den beiden Erstellern „erwünscht“ zu sein. Der Wechsel zur mindestens dreispaltigen („zersprengten“) Darstellung ab Full-HD-Breite unter Standardbedingungen, wie schon früher beschrieben und hier illustriert, ist eine gravierende Änderung des Hauptseiten-Layouts, für die wir den Rückhalt der Community brauchen. Ich appeliere nochmal an die Initiatoren, das neue mehrspaltige Erscheinungsbild der Allgemeinheit vorzustellen, sie zu befragen und deren Meinungsäußerungen (auch mal unkommentiert) zu sammeln, bevor es unter Berücksichtigung von Einwänden umgesetzt wird.
Die in Kürze anstehende technisch notwendige Anpassung der Mobilansicht wurde mehrfach abgesegnet und kann meiner Einschätzung nach unabhängig von den Änderungen der Darstellung für breite Fenster durchgeführt werden. --Wiegels„…“03:29, 3. Jul. 2020 (CEST)Beantworten
+1 Ich fühle mich halt allmählich etwas verarscht. Um meine Kritik wird bloß herumgeredet, statt einzusehen, dass das so echt bescheuert aussieht. -- Chaddy · D13:24, 3. Jul. 2020 (CEST)Beantworten
Es gibt hier drüber sehr viele positive Rückmeldungen zum Entwurf in seiner Gesamtheit; dass nur zwei Benutzer ihn befürworten würden, ist Unsinn. Im Übrigen kennt „mein“ Entwurf lediglich eine ein-, zwei- und fünfspaltige Ansicht, aber das ist wohl nebensächlich. Hier drunter jetzt mein neuer Vorschlag.–XanonymusX (Diskussion) 20:24, 3. Jul. 2020 (CEST)Beantworten
Dass der Gesamtentwurf nur von zwei Benutzern befürwortet würde, habe ich nicht gesagt. Das bezog sich klar auf die als „gewünschter Effekt“ dargestellte dreispaltige Ansicht. Und mit meinem Zitat wollte ich eigentlich nicht deinen Entwurf ins Spiel bringen, um den es hier die ganze Zeit nicht ging, sondern beispielhaft der mit „gewöhnungsbedürftig“ zusammengefassten Beurteilung eine woanders geäußerte und hier auch zutreffende Bezeichnung entgegensetzen. --Wiegels„…“00:10, 4. Jul. 2020 (CEST)Beantworten
Kompromissvorschlag: Setzt die Zahl minimal höher, die pro Spalte erlaubt ist. Dann ist es bei 1920 noch gleich wie bei 1915 Pixel 2-spaltig. Und erst bei ca 1922 Pixel spingt es auf 3-Spaltig. --Steffen2 (Diskussion) 18:45, 2. Jul. 2020 (CEST)Beantworten
Bitte die Grenze 2->3 vorerst auf 125rem hochsetzen. Damit ist die maximale Zeichenanzahl bei 2 Spalten immer noch geringer als bei 3 Spalten. --Wickie3712:26, 3. Jul. 2020 (CEST)Beantworten
Da wir langsam einen Fahrplan brauchen, was wann wie umgesetzt wird, hätte ich noch einen Kompromissvorschlag zu bieten, in dem einige der Kritikpunkte (auch meine eigenen) nach meinen Vorstellungen behoben werden, siehe Hauptseite2020+. Die dreispaltige Ansicht fällt ganz weg, die vierspaltige setzt etwas früher ein (genaue Breakpoints können wie immer nachjustiert werden). Außerdem verhalten sich die Kästen oben und unten jetzt anders. Mobil bleibt natürlich alles wie gehabt. Gruß–XanonymusX (Diskussion) 20:24, 3. Jul. 2020 (CEST)Beantworten
Hallo XanonymusX, danke erstmal für die Suche nach einem Kompromiss! Der neue Entwurf gefällt mir deutlich besser. Als Fortschritt bewerte ich die Beibehaltung der gewohnten Ansicht im Vollbildmodus in Full-HD-Auflösung (unter Standardbedingungen), den gänzlichen Verzicht auf die (unausgewogen erscheinende) dreispaltige Darstellung und die (wieder) zentrierten Überschriften bei den Kästen mit zentrierten Inhalten.
Eine Anregung (keine Forderung) zur 4- bzw. 5-Spalten-Ansicht, die wohl nur wenige Nutzer betrifft, hätte ich noch. Ich finde, wenn man den horizontalen Freiraum um die zentralen Kästen beidseitig und symmetrisch verteilt statt nur dazwischen, macht das Ganze einen noch ausgewogeneren Eindruck, besonders am linken Rand (Aufteilung jeweils 1% + 23% + 1% bzw. 1% + 18% + 1%). Wenn du erlaubst, setze ich das gerne mal an deinem Entwurf um, es ließe sich ja wieder zurücksetzen.
An Zahlenwerten darf gern geschraubt werden! Dein Vorschlag klingt ja ein bisschen nach dem von mir bevorzugten justify-content des Flexbox-Layouts, sollte gut ausschauen. —XanonymusX (Diskussion) 11:13, 4. Jul. 2020 (CEST)Beantworten
Witzigerweise scheint mein Entwurf ungewollt auch einen seltsamen Fehler behoben zu haben, aufgrunddessen in der einspaltigen Darstellung die Bulletpoints bei „Was geschah am“ halbiert wurden. Muss ich noch analysieren, aber umso besser. Ansonsten: Mir scheint, der (neue) Gesamtentwurf wurde hier nun wirklich ausreichend begutachtet und für okay befunden, daher würde ich in den nächsten Tagen alles für einen möglichst glatten Übergang vorbereiten. Ich habe die ganzen Unterseitenverschachtelungen noch nicht restlos durchblickt, aber dafür werde ich mich noch absprechen. Gruß—XanonymusX (Diskussion) 17:05, 5. Jul. 2020 (CEST)Beantworten
Mir der Darstellung bin ich jetzt rundum einverstanden. Einzelne Nachbesserungen (bei vertikalen Abständen oder Trennern) lassen sich später leicht punktuell ausführen, ohne dass mehrere Stellen aufeineinder abgestimmt werden müssen. Den von dir beobachteten Fehler konnte ich nicht nachvollziehen, umso besser, wenn er bei dir nicht mehr erscheint.
Mit den Namen für class- und id-Attibute bin ich noch nicht glücklich. Während die Klasse „hauptseite-hauptseite-item“ im Quelltext der Hauptseite mehr als 40-mal auftaucht, fürchte ich, dass es bei IDs wie „wikipedia“ oder „links“ mal Konflikte geben könnte. Wie wäre es, allen Klassen ein gekürztes Präfix „hs-“ zu verpassen und dasselbe für die IDs der Hauptseite einzuführen (analog zu „mw-“)? Das machte auch die Herkunft der Definitionen am Verwendungsort deutlicher. Wenn gewünscht, könnte ich die Anpassung übernehmen. --Wiegels„…“10:51, 6. Jul. 2020 (CEST)Beantworten
Grundsätzlich einverstanden, auch deshalb, weil bisher die gesamte HS in ein div#hauptseite eingeschlossen war, das aber nun wegfällt, wodurch das gezielte Ansteuern in der Tat erschwert wird. Von Abkürzungen würde ich allerdings abraten, das aktuelle kryptische mf- finde ich abschreckend genug; vor allem bei den Klassen sollte hauptseite- unbedingt erhalten bleiben. Dann besser auch gleich einheitlich so bei den IDs. Also von mir aus gern!—XanonymusX (Diskussion) 13:29, 6. Jul. 2020 (CEST)Beantworten
Es scheinen ja nur die id-Fragmente ohne Präfix zu sein, da halte ich das nicht unbedingt für nötig. Aber dagegen hätte ich auch nichts. Schöner Entwurf übrigens, gefällt mir gut. -- hgzh19:58, 6. Jul. 2020 (CEST)Beantworten
Nachdem ich gestern lange Klassennamen gekürzt hatte, habe ich jetzt die id-Bezeichner verlängert (und hiermit leider das Inhaltsverzeichnis des oberen Entwurfs „beschädigt“). Alle Namen besitzen jetzt das Präfix hauptseite-, außer die Klassen center und breadcrumb-nav-…. Was haltet ihr von der Idee, letztere drei CSS-Klassen in hauptseite-nav-… umzubenennen? --Wiegels„…“03:43, 8. Jul. 2020 (CEST)Beantworten
Eine Enzyklopädie, zumindest eine, die gegenwärtiges abbildet, ist per definitionem nie fertig. Von daher ist das eine redundante Information und kann weg. Also: "Wikipedia ist eine Enzyklopädie ..."
Das ist schon immer so gewesen, das darf man nie ändern, wenn jemand da einen Buchstaben ändert dann ist das nicht mehr meine Wikipedia, wie ich sie 2006 kennengelernt hatte.
Im Ernst: Die Formulierung war 2005 völlig okay gewesen, auch 2010 noch, ist aber heutzutage anachronistisch.
Auch eine Vokabel „Ausbau“ sähe ich lieber noch inhaltlich ergänzt durch etwas wie „Aktualisierung und Pflege“ aut idem – die alleinige Ausrichtung auf „immer mehr neue Artikel anlegen, immer mehr neue Artikel, immer mehr“ hatte auch vor einem Jahrzehnt ihre Berechtigung gehabt, aber wir müssten heutzutage dreiviertel der Arbeitskraft auf die Nachbesserung der Qualität im Bestand, die Aktualiserung, die Transformation veralteter Praktiken in zukunftssichere Quelltexte legen. Aber an ollen Artikeln anderer Leute nachzupolieren ist nicht so sexy wie sein eigenes Ding zu machen. Wie man jüngst in einer AK nachlesen konnte, leben diverse Leutchen aber noch in der Gedankenwelt der SchNuller-Jahre.
Mir würden auch noch Vokabeln wie Entwicklung, Betreuung, Bereitstellung einfallen, aber so spontan fällt mir noch nichts richtig prickelnd ein, und außerdem ist es zu heiß und schwül und ich bin müde.
Falls sich von „ist ein Projekt zum“ verabschiedet werden soll, fehlt mir an „Wikipedia ist eine Enzyklopädie“ aber die Attribuierung – eine „nichtkommerzielle“, eine, zu der alle beitragen können („Mitmachen“-Verdeutlichung, „Neue Autoren“).
Zu der Zeit, als diese Selbstbeschreibung mal formuliert wurde, war Wikipedia ein seltsames Projekt von ein paar Verrückten, das sowieso keine Zukunft haben wird und in ein paar Jahren keiner mehr kennt. Heute wird es in breiter Bevölkerung als zuverlässiges Qualitätsmedium aufgefasst, in dem Fake News und Propaganda keinen Platz haben.
+1. Ein äußerst wichtiger Punkt. Ich zitiere mich ausnahmsweise mal selber (aus der oben verlinkten Disk vom Dez. 2019): "Ich hatte genau diesen Punkt in dieser Umfrage zur Sprache gebracht [...] Die "Aufbauphase" ist seit vielen Jahren beendet, sogar die Ausbauphase ist es. [...] Gerade für neue User wäre der Einstieg viel problemloser, wenn sie nicht gleich zur Artikelanlage, sondern erst einmal zur Wartung ermutigt würden, weil dabei mit Sicherheit weniger Fehler und Konflikte entstünden, die sie dann gleich wieder vertreiben. Noch immer werden User danach beurteilt, wie viele Artikel sie erstellt, und nicht danach, wie viele sie überarbeitet und aktualisiert haben". Selbstzitat nicht, weil ich meine Beiträge so toll finde, sondern weil es perfekt zu den Ausführungen des Vorredners passt.--Altaripensis (Diskussion) 16:01, 2. Jul. 2020 (CEST)Beantworten
Ich finde einerseits verständlich, dass direkt hier diskutiert wird, da es um die HS geht, andererseits mindestens unglücklich, dass die Diskussion an zwei Stellen geführt wird, zumal gleich im Eingangsposting auf FzW verlinkt ist. – Zur Sache: Im Thread auf FzW wird auf die Diskussion vor einem halben Jahr verwiesen. Dort wiederum hatte ich rausgekramt, dass der Text keineswegs von Anfang an „Projekt zum Aufbau“ hieß, sondern die WP bis Januar 2006 schon mal eine Enzyklopädie war ;-) – Vielleicht sollten wir die Diskussion aber erstmal an eine Stelle zusammenführen. eryakaas • D17:53, 2. Jul. 2020 (CEST)Beantworten
Da das Ergebnis, egal ob hier oder auf WP:FZW oder auch schon letzten Dezember, eine deutliche Mehrheit für eine Änderung ist, habe ich das jetzt umgesetzt. NNW20:17, 2. Jul. 2020 (CEST)Beantworten
Schade dass auf der HS-Disk erst heute darauf aufmerksam gemacht wurde. Ich hätte mich gerne früher beteiligt, mir fehlte aber die letzten Tage die Zeit um auf FzW alles nachzulesen. Ein Mittelweg wäre mir deutlich lieber gewesen.
Als Antwort auf die Frage: "Wann soll es dann weg?" IMHO nie, voraussichtlich wird die Wiki nie fertig. Deswegen ist ja auch des Logo nicht fertig, sondern es fehlt (immer noch, wie überraschend) ein Teil. Gruß Sophietalk00:12, 3. Jul. 2020 (CEST)Beantworten
Fertig wird Wikipedia unter Garantie nie, aber fertig wurden bzw. werden auch ein Brockhaus oder eine Encyclopædia Britannica nicht und „fertig“ ist auch gar nicht Teil der Definition einer Enzyklopädie. Ich denke, „umfassendes Nachschlagewerk“ ist die Wikipedia allemal und wenn wir von außen so wahrgenommen werden (z.B. hier oder hier), dann ist es doch irgendwann albern, das nicht anzuerkennen und uns so auch selbst zu benennen. NNW09:51, 3. Jul. 2020 (CEST)Beantworten
Ich habe den Edit rückgängig gemacht. Diese Änderung bedarf imho schon eines deutlich breiteren Konsens als nur einer knappen Absprache auf dieser Diskussionsseite. Als Beitragender arbeite ich selbst an diesem Projekt zum Aufbau einer Enzyklopädie mit - sollte es sich tatsächlich mittlerweile um eine fertige Enzyklopädie handelt, werden ich und viele andere Mitarbeiter wohl nciht mehr gebraucht. -- Achim Raschka (Diskussion) 12:07, 3. Jul. 2020 (CEST)Beantworten
Ich könnte natürlich zum x-ten Mal schreiben, dass „fertig“ keine Definition von „Enzyklopädie“ ist, aber aus irgendeinem Grund scheint das nicht durchzudringen. NNW12:14, 3. Jul. 2020 (CEST)Beantworten
Die Wikipedia hat ein Instrument namens „Meinungsbild“, das wäre in diesem Fall anzuwenden. Auch eine „Umfrage“ wäre ein mögliches Tool, um einen Eindruck über die Position einer Mehrheit im Projekt zu gewinnen. Nichts zu danken, ich helfe gern -- Achim Raschka (Diskussion) 12:20, 3. Jul. 2020 (CEST)Beantworten
Reichlich säuerlich, der Ton. Nehme ich zur Kenntnis, halte ich aber für unnötig. Handstreich? Nun ja. Wir sollten Logo und natürlich alle Artikel zum Themenfeld Wikipedia dringend überarbeiten. Und auch die fremdsprachigen Kollegen darauf aufmerksam machen, dass sie einem Denkfehler aufgesessen sind. NNW12:31, 3. Jul. 2020 (CEST)Beantworten
Aber das sage ich doch gar nicht. Wir werden alle weiterhin gebraucht, für neue Artikel, für die Wartung der Wikipedia, für lange, tolle, schreckliche, nötige und unnötige Diskussionen, um sie noch besser zu machen. Die Welt nennt Wikipedia eine Enzyklopädie, und würden wir hier vorgehen wie in der Artikelarbeit, nämlich quellenbasiert, dann würden wir vermutlich große Mühe haben, auch nur irgendeine Quelle zu finden, die Wikipedia „Projekt zur Erstellung einer Enzyklopädie“ bezeichnet. Das finde ich nicht schlimm, das ist wie erwachsen werden. Anders als früher, aber es geht, irgendwie. NNW12:49, 3. Jul. 2020 (CEST)Beantworten
Wie ich schon auf FzW erwähnt habe, halte ich einen Mittelweg für sinnvoll. Wenn auch das Wort "Projekt" vorkommen soll, dann vielleicht eine Formulierung wie "Wikipedia ist eine laufend erweiterte und aktualisierte Enzyklopädie aus freien Inhalten, zu diesem Projekt kannst auch du sehr gern beitragen." lg --Invisigoth67(Disk.)12:34, 3. Jul. 2020 (CEST)Beantworten
Ich bitte darum ein Meinungsbild oder eine Umfrage zu erstellen um die Veränderung (oder auch Nicht-Veränderung, je nachdem)auf eine breitere Basis zu stellen. --Siesta (Diskussion) 14:33, 3. Jul. 2020 (CEST)Beantworten
Auch wenn ich NNW's Vorstoß inhaltlich absolut teile, fand ich die Änderung ebenfalls vorschnell. Aber ein Meinungsbild um zwei Wörter zu veranstalten, halte ich für ABM. Es sind genug Vorschläge gekommen, hier und auf derFzW-Seite, auf die man sich in Ruhe und ohne großes Trara verständigen kann.--Altaripensis (Diskussion) 16:45, 3. Jul. 2020 (CEST)Beantworten
Ich weiß nicht ob es ein Meinungsbild oder eine Umfrage sein muss, aber wie schnell hier gehandelt wurde, fand ich einfach unschön; und vor allem das hier erst so spät kundzutun. Jetzt kommt das Beste: Ich hab keine gute Lösung. Gruß Sophietalk00:14, 4. Jul. 2020 (CEST)Beantworten
Also wenn Wikipedia "ein Projekt zum Aufbau einer Enzyklopädie" ist, dann ist
Mozilla Firefox ein Projekt zu Erstellung eines Webbrowsers (schließlich gibt es mindestens monatlich Updates mit neuen Funktionen; und die Liste der Funktionswünsche im Bugtracker ist etliche Seiten lang)
das Volkswagen Werk in Wolfsburg ein Projekt zum Aufbau einer Fahrzeugfabrik (schließlich wird das Werk durchgängig aus- und umgebaut)
der Kölner Dom ein Projekt zur Errichtung eines Gotteshauses („Wenn der Dom fertig wird, geht die Welt unter“ sagt man in Köln)
etc., weitere Beispiele sind ja oben schon genannt worden.
Ich halte es sogar für möglich, dass der Satz manche Leser davon abhält hier mitzumachen, weil sie uns danach für perfektionistsche Nerds halten (was auf einen wesentlichen Teil der Wikipedianer sogar zutreffen mag, aber das muss man ja nicht gleich jedem erzählen).
Wer der Meinung ist, dass "Projekt zum Aufbau..." die korrektere Bezeichnung ist, müsste konsequenterweise aber auch zu einer Änderung in "Die deutschsprachige Wikipedia ist ein Projekt zum Aufbau..." drängen, denn in allen anderen Sprachen ist der Aufbau offenbar abgeschlossen (stichprobenartig geprüft). Und natürlich darauf, das Logo zu ändern, wo das dann auch falsch steht. Oder? -- Thoroe (Diskussion) 14:29, 4. Jul. 2020 (CEST)Beantworten
Da hast du offenbar vor allem die großen Sprachversionen angeguckt. In vielen kleinen wurde leider noch nicht wirklich mit dem Aufbau angefangen. Da gibt es viele Einzeiler und maschinenübersetzte Artikel. Von einer Autorenschaft ganz zu schweigen. Groete. -- SpesBona23:00, 4. Jul. 2020 (CEST)Beantworten
Es ging mir nicht um den tatsächlichen Zustand/Ausbaustand, sondern darum, wie sich die Versionen auf ihren Startseiten selbst benennen, und das ist in den meisten Fällen eben: "Wikipedia ist eine Enzyklopädie". Und ja: ich habe bei den umfangreicheren Versionen nachgesehen. -- Thoroe (Diskussion) 11:59, 5. Jul. 2020 (CEST)Beantworten
Auf der Startseite der Alemannischen Wikipedia stand schon am Tag ihrer Gründung am 13. November 2003 frei übersetzt Wilkommen in der elsässischen Wikipedia, einer freien und allgemeinen Enzyklopädie. Damals hatte die alswiki exakt 0 Artikel. Wenn ich das gewusst hätte, dass damit ausgedrückt werden sollte, dass das Projekt bereits abgeschlossen war und wir alle niemals gebraucht wurden ... --Holder (Diskussion) 18:12, 7. Jul. 2020 (CEST)Beantworten
Der Initiator der damaligen Diskussion schrieb von "den Passus ... vorläufig ... zu ändern". Also vorläufig. Demnach kann man den "Aufbau"-Passus wieder "revertieren". Damals stiess das auch nicht auf helle Begeisterung. Und da das nur für eine vorläufige Zeit gedacht gewesen war, brauchts zum revertieren kein MB. Eher eins, falls wir das mit dem Aufbau beibehalten wollen. Streng genommen. --Filzstift (Diskussion) 13:14, 8. Jul. 2020 (CEST)Beantworten
Und auf dieser Basis habe ich den Passus wieder entfernt, die Diskussion ist eh mehr oder weniger klar. Und da das damals, 2006, also als die WP schon aus den Kinderschuhen entwichen war, schon eine Hinterhofdiskussion war, brauchts nicht plötzlich eine gross angelegte Umfrage oder gar MB. --Filzstift (Diskussion) 13:20, 8. Jul. 2020 (CEST)Beantworten
Ich wünsche euch dann noch viel Spaß mit eurer fertigen Wikipedia, Aufbauhelfer werden ja nicht mehr benötigt. Wird Zeit, sich ein anderes Hobby zu suchen nach fast 20 Jahren WP. -- Achim Raschka (Diskussion) 13:47, 8. Jul. 2020 (CEST)Beantworten
Auch wenn ich Achims Ärger nicht ganz verstehen kann, so sehe ich hier eher die fortgesetzte Gefahr einer "feindlichen Übernahme" durch Leute, welche natürlich in einem Freiwilligenprojekt immer wieder dazukommen, aber denen der Respekt und die Erfahrung fehlt. Daraus resultiert nicht etwa der Schutz des Vorhandenen, vermeintlich Fertigen, sondern man versucht nun mit Regulierung, Löschen und Beeinflussen das Wesen des Projektes grundsätzlich zu ändern. Häufig mit Zeitgeist, was einer auf Dauer angelegten Enzyklopädie nicht gut tut. Bestenfalls haben wir ein Drittel der relevanten Themen beschrieben, häufig fehlen selbst wesentliche Basisartikel. Egal ob es um die Großstädte der Welt, erfolgreiche ostasiatische Schauspieler der 60er Jahre oder die Arten der Botanik geht. Erst wenn diese Arbeit getan ist, kann man über das Ende des Aufbaus sprechen. Das hier soll eine Kathedrale des Wissens werden, zur Zeit sind wir vorne Hui mit hinten ganz viel Pfui, was durch den Wartungsrückstau eben Umbau ist, aber was bei einer kleinen Basis eben größer ausfallen kann als ein erster Aufbau.Oliver S.Y. (Diskussion) 13:56, 8. Jul. 2020 (CEST)Beantworten
Unabhängig von der Frage, für was man die Wikipedia hält und für was nicht, ist die jetzige Form nicht akzeptabel. Man erfährt jetzt zwar, woraus die Wikipedia besteht, aber was sie ist oder sein soll, fehlt völlig. Oder, um in unserer Diktion zu sprechen: Es gibt gar keine Definition. Das ist – bei allem gebotenen Respekt – nichts anderes als dilettantisch. Ich weiß sehr gut, was zu diesem Schritt geführt hat, aber es ist wie so oft im Leben: gut gemeint ist das Gegenteil von gut gemacht. Kolleginnen und Kollegen, so kann das nicht bleiben. Wir machen uns lächerlich.-- Matthias v.d. Elbe (Benutzer- und Diskussionsseite) 14:59, 8. Jul. 2020 (CEST)Beantworten
Ich respektiere deine starke Emotionalität, teile sie aber nicht, aus verschiedenen Gründen: so ist Wikipedia verlinkt, einer Definition bedarf es also gar nicht, zudem ist Wikipedia zumindest im DACH-Raum inzwischen mit 85% ausreichend bekannt. Wenn mir keine*r zuvorkommt, werde das MB die nächsten Tage mit der einfachen Frage bzw 3-4 Lösungen entwerfen. Grüße −Sargoth15:21, 8. Jul. 2020 (CEST)Beantworten
Der Aspekt, der hervorgehoben wird, ist, dass die Inhalte frei sind. Damit wird die Möglichkeit der Kommerzialisierung in den Mittelpunkt gestellt. Ist es das wirklich, was wir als wichtigsten Aspekt darstellen wollen? Im übrigen hat Benutzer- vollkommen recht. --BelladonnaElixierschmiede15:16, 8. Jul. 2020 (CEST)Beantworten
Also, wenn das schon „starke Emotionalität“ sein soll, dann hält dieses Land am Ende nicht viel aus... Sargoths Begründung kann ich auch so umschreiben: „Ich sag Dir nicht, was das ist, denn Du weißt es ja ohnehin...“ Das ist abwegig. Mit dieser Argumentation könnten wir in den Artikeln zu Auto, Michael Wendler, Hausschwein und Regen gleichermaßen jede Definition streichen: All das ist ebenfalls bereits jetzt „ausreichend bekannt“. Ich habe gar nichts gegen das angekündigte Meinungsbild; ganz im Gegenteil. Und wenn es zu dem Ergebnis kommen sollte, dass wir ungeachtet dieser noch nicht abgearbeiteten Liste tatsächlich schon fertig sein sollten, dann werde ich mich zwar wundern, aber ich werde das Ergebnis akzeptieren. Und damit auch eine Anpassung der Formulierung auf der Hauptseite. Aber bis es soweit ist, lasst bitte den bisherigen Definitionsversuch auf der Hauptseite stehen. Er ist in jedem Fall besser als gar keine Definition. Ganz daohne wirkt es wie ein unfertiger Grundschulaufsatz. Eben dilettantisch. Sorry. -- Matthias v.d. Elbe (Benutzer- und Diskussionsseite) 15:50, 8. Jul. 2020 (CEST)Beantworten
Ich finde es ja dilettantisch, zum xten Mal mit „nicht fertig“ zu argumentieren, wenn „fertig“ gar nicht Teil der Definition von „Enzyklopädie“ ist (siehe z.B. hier, damit es nicht allzu selbstreferenziell wird), weil „fertig“ auch gar keinen Sinn ergeben würde. Ich weiß nicht, wie oft ich das jetzt schon geschrieben habe, aber ich werde es notfalls auch nochmal im Meinungsbild machen, falls es bis dahin wieder vergessen wird. NNW16:36, 8. Jul. 2020 (CEST)Beantworten
Natürlich ist fertig ein Teil der Definition herkömmlicher Enzyklopädien, die eben auf ganz andere Art in anderen Medien entstanden sind. Oder zeige mir eine fortlaufende Enzyklopädie, die immer weiter aufgebaut wird ohne ein Abschlußziel zu haben. Das unterscheidet Wikipedia von jeder bisherigen Enzyklopädie. Ich halte deine Änderung ähnlich wie Achim für falsch. -- Marcus CyronTell me lies, Tell me sweet little lies16:43, 8. Jul. 2020 (CEST)Beantworten
Ich denke nicht, dass die erste Auflage des Brockhaus aus heutiger Sicht als fertig anzusehen ist. Sahen die Macher auch nicht und haben eine Ausgabe nach der anderen gemacht, jede anders, jede größer, jede aktualisiert. Wie soll denn das Ziel aussehen, wenn sich das Universum ständig wandelt? NNW16:46, 8. Jul. 2020 (CEST)Beantworten
Nach der ersten haben sie von Grund auf eine neue Zweite geschaffen. Und dann eine neue Dritte. Und so weiter. Wikipedia ist ständig Work in Progress. Ein Brockhausleser im Jahr 1910 hat in seinem Brockhaus in einem Artikel am Folgetag immer dasselbe gelesen wie am Vortag. Da hat sich nichts geändert. Bei Wikipedia kann der Artikel Abends ein anderer sein als am Morgen. Du misst Wikipedia heute mit einem völlig anderen Medium. Das halte ich nicht für statthaft. -- Marcus CyronTell me lies, Tell me sweet little lies18:53, 8. Jul. 2020 (CEST)Beantworten
Was mir besonders gefällt, ist, dass unser Willkommens-Einleitungs-Selbstpräsentationssatz jetzt so formuliert ist, dass es keinen Grund zur Annahme mehr gibt, dass ein Werbeflyer und vieles andere mehr hier falsch sein könnte. Wikipedia ist nun nichts mehr, sondern besteht nur noch. … «« Man77 »»Alle Angaben ohne Gewehr.16:43, 8. Jul. 2020 (CEST)Beantworten
Cool, endlich fertig und nur noch: "Wikipedia besteht aus freien Inhalten"; bevor demnächst alle enzyklopädischen Inhalte durch freie ersetzt werden, drucke ich mir die anscheinend seit heute fertige Version mal eben aus. Danke für den Hinweis und Grüße --Thomas Wozniak (Diskussion) 16:45, 8. Jul. 2020 (CEST)Beantworten
Ich sitze seit 17 Uhr an der Telefonberatungshotline. Seitdem sind ausnahmslos alle Anrufer verwirrt und rufen nicht wegen enzyklopädischer Fragen oder Beihilfe zum Aufbau an, sondern z.B. wegen ihrer Illustriertenabos oder ihres Motorradlacks. --Seewolf (Diskussion) 18:25, 8. Jul. 2020 (CEST)Beantworten
Unsere Wikipedia:Grundprinzipien sagen: "Wikipedia ist ein gemeinschaftliches Projekt mit dem Ziel, eine Enzyklopädie von bestmöglicher Qualität zu schaffen." "Wikipedia dient dazu, eine Enzyklopädie aufzubauen." Dies ist meines Wissens nicht einfach so änderbar. Habitator terrae19:47, 8. Jul. 2020 (CEST)Beantworten
Ist das ironisch gemeint?/ Der fett gedruckte Titel des Absatzes - der Titel des obersten Grundsatzes - sagt wortwörtlich das Gegenteil davon aus. ----21:30, 8. Jul. 2020 (CEST)~
In den Nachrichten: Edouard Philippe
Letzter Kommentar: vor 4 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Ah, jetzt verstehe ich: Das eigentliche Problem ist, dass natürlich auch Castex nicht allein regiert, es aber in der deutschen Wikipedia verständlicherweise noch keinen Artikel zum Kabinett Castex gibt, weil ja die neuen Kabinettsmitglieder noch nicht feststehen. Die französische Wikipedia hat dennoch schon einen Artikel fr:Gouvernement Jean Castex angelegt, aus dem zumindest hervorgeht, dass neben Castex auch die Verteidigungsministerin als Premier im Gespräch war. 2A00:20:9006:E30B:28D4:95E7:5BFB:BFCF15:14, 3. Jul. 2020 (CEST)Beantworten
Das halte ich für eine steile These. Rosel Zech ist auf ihrem Gebiet eine der zentralen Akteurinnen überhaupt, eine wirklich verdienstvolle Schauspielerin. In aller Regel haben wir hier nur einen Todesfall, da müssen andere, die auch Nennung verdient hätten (Ringo gehört sicher dazu), einmal zurückstehen; es wird neue Gelegenheiten geben. --Happolati (Diskussion) 20:51, 7. Jul. 2020 (CEST)Beantworten
Oh Gott, jetzt habe ich Ringo schon zum Todesfall erklärt. ;-) Möge er noch lange leben! Und IP 2001:16B8 etc.: Du hast ja vollkommen recht mit deiner Erinnerung an Ringo Starr, aber die Bearbeiterin des heutigen Tages hat sich für Rosel Zech entscheiden - was mE auch ok ist. --Happolati (Diskussion) 21:09, 7. Jul. 2020 (CEST)Beantworten
Danke für den Hinweis, das hatte ich zu verkürzt eingetragen. Ist jetzt zwar noch ein wenig komplizierter, aber dafür korrekt, so soll es ja auch sein. --Tsui (Diskussion) 16:26, 8. Jul. 2020 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. TheAmerikaner (Diskussion) 20:26, 8. Jul. 2020 (CEST)
USA treten offiziell aus der WHO aus
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Wir hatten das Thema bereits bei den ersten Ankündigungen Trumps. Man kann es noch mal aufnehmen, aber ich halte es nicht für ein sehr dringendes Thema. Vielleicht kommen noch andere Meinungen. Danke für den Vorschlag. --Happolati (Diskussion) 17:47, 8. Jul. 2020 (CEST)Beantworten
Danke für diese freundliche Rückmeldung. Ich halte diese Meldung deshalb für so wichtig, WEIL Mr. Trump seine "Androhung" wahrgemacht hat und sie sicherlich weitreichende (mMn katastrophale) Folgen, besonders für die USA und die WHO, haben wird. LG;--Dr.Lantis (Diskussion) 17:51, 8. Jul. 2020 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. TheAmerikaner (Diskussion) 20:26, 8. Jul. 2020 (CEST)
Vierter Band von Harry Potter
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ich möchte nun nicht Harry Potter und/oder seine Autorin schlecht machen, dennoch finde ich es bemerkenswert, dass die Ersterscheinung des vierten Teils der Reihe hier prominent erscheint. Wenn das der erste Teil gewesen wäre, wäre das klar aber der vierte? Und zudem nicht im deutschsprachigen Raum, sondern in englischsprachigen Ausland? Was ist das Alleinstellungsmerkmal dieses Werkes? (An der Stelle gebe ich zu, dass ich die Bücher nicht gelesen, dagegen die Filme gesehen habe) Grüße, --Urgelein (Diskussion) 17:49, 8. Jul. 2020 (CEST)Beantworten
War das, als die Buchläden nachts öffneten und die Teenies dort Schlange standen? Ich hab nie eine Zeile davon gelesen, aber daran kann ich mich erinnern. Ansonsten hatte ich mir die gleiche Frage gestellt wie Urgelein; insofern wäre es schön gewesen, das Marketing irgendwie noch in die Nachricht zu quetschen. Für die letzten paar Stunden geht es aber bestimmt auch so. eryakaas • D20:15, 8. Jul. 2020 (CEST)Beantworten
Änderungswünsche zu Teasern der Rubrik Schon gewusst? bitte hier besprechen.
16:15, 28. Jun. 2020 (CEST)
21:41, 28. Jun. 2020 (CEST)
bzw. 
– aber deren Stern ist sowieso grad im Sinken.
ist eigentlich gemeint, ich habe das jetzt erstmal ersetzt, sollte aber ggf. nochmal etwas anders gezeichnet werden.
SpesBona 18:55, 3. Jul. 2020 (CEST)
SpesBona 23:00, 4. Jul. 2020 (CEST)
Matthias v.d. Elbe (Benutzer- und Diskussionsseite) 14:59, 8. Jul. 2020 (CEST)
19:47, 8. Jul. 2020 (CEST)