Reading/Web/Desktop Improvements/Frequently asked questions/de

Lesbarkeit
Unser Hauptgrund für die Begrenzung der Breite des Inhalts ist die Verbesserung der Lesbarkeit all der erstaunlichen Inhalte in unseren Wikis. Effizientes Lesen von Text ist für die große Mehrheit aller Lese- und Bearbeitungsvorgänge in unseren Projekten entscheidend. Es gibt zwar mehrere Faktoren, die sich auf die Lesbarkeit auswirken - z. B. Schriftgröße, Kontrast, Schriftart und Zeilenlänge -, aber wir haben beschlossen, uns zunächst auf die Zeilenlänge zu konzentrieren. Die formative Zeilenlängenforschung zum Lesen von gedruckten Texten empfiehlt Zeilenlängen zwischen 45 und 90 Zeichen pro Zeile (cpl). Jüngste Untersuchungen über das Lesen von Website-Texten konzentrieren sich hauptsächlich auf den Bereich von 35 bis 100 cpl, wobei die meisten Empfehlungen in den unteren Bereich dieses Bereichs fallen. Ohne eine Breitenbeschränkung für den Inhalt der Artikel kann es jedoch vorkommen, dass die Zeilenlänge weit über dem empfohlenen Bereich liegt. Eine Studie aus dem Jahr 2005 fasst die neuesten Forschungsergebnisse gut zusammen: "Kurze Zeilenlängen sind leichter zu lesen", und was das Lernen und das Behalten von Informationen betrifft, "hatten die Probanden, die die schmalen Absätze lasen, ein besseres Behalten als die, die die breiten Absätze lasen".

Auch wenn es für uns immer wichtig ist, unsere eigenen Nachforschungen anzustellen und unsere eigenen Schlussfolgerungen zu ziehen, halten wir es für sinnvoll, auf die überwältigende Zahl der großen Websites hinzuweisen, die ähnliche Beschränkungen für die Breite der Inhalte haben. Zum Beispiel: wissenschaftliche Zeitschriften wie Nature, Nachrichten-Websites wie The New York Times, staatliche und zwischenstaatliche Websites wie die UN, wissenschaftliche Dokumente wie LaTeX und Textverarbeitungsprogramme wie Google Docs und Etherpad. Diese Beispiele in Verbindung mit der umfangreichen Forschung geben uns Vertrauen in diese Entscheidung.

Kurz gesagt, eine Begrenzung der Breite des Inhalts ermöglicht eine bessere Lesbarkeit, eine geringere Belastung der Augen und ein besseres Behalten der Informationen selbst.

Aber was ist mit all dem weißen Raum?
Wir haben von etwa 30 Redakteuren (vor allem von Leuten mit großen Bildschirmen) gehört, dass sie sich über den vielen weißen Platz an den Seitenrändern ärgern, obwohl einige von ihnen der Meinung sind, dass die Breitenbegrenzung besser zum Lesen ist. Es scheint zwei Hauptursachen für diese Frustration zu geben: Unser Ziel ist es, das bestmögliche Leseerlebnis zu schaffen, und nicht, jeden Pixel des Bildschirms mit Inhalten zu füllen. Und in diesem Fall ist weniger tatsächlich mehr - die Menschen können bei kürzeren Zeilenlängen leichter lesen und sich ohne die Ablenkung durch Seitenleisten oder andere Elemente besser konzentrieren. Wenn das beste Layout ein Layout ist, das Leerraum enthält, ist das in Ordnung - an sich ist an Leerraum nichts auszusetzen.
 * 1) Der weiße Raum fühlt sich wie verschwendeter Platz an
 * 2) Der weiße Raum ist hell und lenkt ab

Darüber hinaus hoffen wir, mit dem Fortschreiten des Projekts einen Teil dieses Raums für andere Funktionen nutzen zu können. Wir haben begonnen, damit zu experimentieren, dass die Seitenleiste auf der linken Seite der Seite verbleibt (link to prototype). Im weiteren Verlauf des Projekts wollen wir damit experimentieren, ein Inhaltsverzeichnis und/oder Seitentools neben den Inhalt zu stellen. Wie, eröffnet die Begrenzung der Inhaltsbreite neue Möglichkeiten für das Layout des Inhalts, z. B. eine rechte Spalte für Infoboxen und Bilder.

Warum können die Leser ihre Browserfenster nicht einfach kleiner machen?
Mehrere Personen haben darauf hingewiesen, dass sie ihr Browserfenster verkleinern oder auf den Link "Mobile Ansicht" am unteren Rand der Seite klicken können, wenn sie den Inhalt schmaler dargestellt haben möchten. Wie bereits erwähnt: Da wir wissen, dass die meisten Leute zum Lesen von Artikeln kommen, sollten wir das Layout für diesen Anwendungsfall optimieren. Wir haben nur eine Chance, einen ersten Eindruck zu hinterlassen, und wir sollten uns bemühen, den Menschen schon bei ihrer Ankunft ein tolles Erlebnis zu bieten, ohne dass sie sich umstellen müssen.

Tabellen und andere Vorlagen passen nicht in die begrenzte Breite, ist das nicht schlecht?
Wir haben mehrere Berichte über Tabellen mit langen horizontalen Bildlaufleisten oder über Vorlagen erhalten, die sich über die begrenzte Breite hinaus ausdehnen. Wir möchten darauf hinweisen, dass ein großer Prozentsatz unserer Nutzer, die keine großen Bildschirme haben und von ihren Laptops aus auf Wikipedia zugreifen, bereits vor der Änderung Probleme mit Tabellen und Vorlagen hatten. Wir sollten darauf hinarbeiten, dass alle unsere Inhalte so responsiv wie möglich sind, um allen Besuchern gerecht zu werden.

Warum machen wir es nicht einfach zu einer Einstellung?
Einer der besten Aspekte der MediaWiki-Schnittstelle ist ihre Konfigurierbarkeit. Und während wir einen Rahmen für die Breite der Inhalte schaffen könnten, fragen wir uns, ob es nicht von Vorteil wäre, eine gemeinsame Erfahrung zu fördern, die Redakteure und Leser teilen. Dies könnte für Redakteure hilfreich sein, wenn sie Entscheidungen über das Seitenlayout treffen (Anmerkung: 1024px wird im English Wikipedia Manual of Style als zu berücksichtigende Mindestgröße genannt, obwohl das nicht ganz dasselbe ist). Derzeit kann ein Redakteur eine Seite mit einer Breite von 1500px bearbeiten, während ein Leser sie mit einer Breite von 1200px liest. Durch die Einführung einer Maximalbreite wird diese Diskrepanz nicht vollständig beseitigt (da es immer noch Abweichungen unterhalb der Maximalbreite für Menschen mit schmaleren Bildschirmen geben würde), aber wir würden die Variationsbreite stark einschränken.

Dennoch sind wir nicht grundsätzlich gegen Konfigurierbarkeit. Wenn Sie die neue Version des Vector-Skins ohne die eingeschränkte Breite weiter verwenden möchten, können Sie dazu ein lokales Benutzerskript oder ein Gadget verwenden. Wir können das empfehlen.

Wie sind wir auf 960px für die Breite gekommen?
Bitte lesen Sie diese Seite, um mehr darüber zu erfahren, wie wir diese Entscheidung getroffen haben:

Wann werden diese Änderungen in den größten Wikis verfügbar sein?
Wir hoffen, dass die Änderungen im Laufe des Jahres als Standard für alle Wikis festgelegt werden. Jede Gemeinschaft ist willkommen, sich den Erstanwendern anzuschließen.

Sollen die Verbesserungen auch in Schwesterprojekten und in Wikis, die nicht in lateinischer Schrift geschrieben sind, umgesetzt werden?
Ja. Wir haben bereits eine Liste von "Early Adopter"-Wikis erstellt, die verschiedene Größen und Skripte repräsentieren. Wir wollten auch sicherstellen, dass mindestens ein Nicht-Wikipedia-Projekt ausgewählt wird.

Bei welchen Wikis sind diese Änderungen standardmäßig aktiviert?
Derzeit sind dies:


 * Schwesterprojekte:
 * 
 * 
 * 


 * Wikis mit nicht-lateinischer Schrift:
 * bn:
 * he:
 * fa:
 * ko:
 * sr:


 * Wikipedias mit lateinischer Schrift:
 * eu:
 * fr:
 * pt:
 * sr:
 * tr:
 * vec:


 * zusätzlich:
 * Office Wiki
 * 

Wir sind offen für die Aufnahme weiterer Wikis in diese Liste!

Wie kann dies in meinem Wikimedia-Wiki eingesetzt werden?
Wenn Sie daran interessiert sind, die Desktop-Verbesserungen als Standard in Ihrem Wiki zu sehen,
 * 1) fragen Sie Ihre Community und erzielen Sie einen Konsens,
 * 2) kontaktieren Sie SGrabarczuk (WMF), E-Mail: sgrabarczuk@wikimedia.org wenn Sie Unterstützung benötigen.

Wie kann ich es in meinem eigenen (fremden) Wiki aktivieren?
Stellen Sie zunächst sicher, dass Sie heruntergeladen haben. Bitte beachten Sie, dass die stabile Version Mitte 2021 veröffentlicht wird. Wenn Sie das Risiko akzeptieren und unsere Änderungen trotzdem sehen möchten, fügen Sie folgende Zeilen in Ihren :

Es freut uns zu hören, dass Sie unsere Verbesserungen zu schätzen wissen!

Werden Monobook oder Timeless davon betroffen sein?
Nein. Diese Änderungen werden nur auf Vector angewendet. [ Vector] ist seit 2010 die Standardoberfläche auf Wikimedia-Wikis. Andere Skins sind nicht betroffen, einschließlich [ Monobook], [ Timeless], [ Minerva] oder [ Modern].

Werden Sie Diagramme, Karten, a-/f-/o-/tmboxen, Infoboxen, Navboxen und andere Vorlagen verbessern?
Nein. Wir werden nichts ändern, was sich innerhalb des hellgrauen Bereichs "Artikelinhalt" befindet (mit Ausnahme des Inhaltsverzeichnisses):



Wie kann ich Verbesserungen vorschlagen?
Add a section on the [ talk page of the main page of the project] or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

How do you work with the communities?

 * 1) Prior to the deployments:
 * 2) We performed user research, and reviewed gadgets and user scripts. See the  for more details.
 * 3) We have been reaching out to various wikis asking to join the early adopters.
 * 4) We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * 5) We have run two prototype testing rounds. Editors could gain an understanding of our ideas, and share what they appreciate or find confusing.
 * 6) Shortly after the deployment of each feature improvement, we collect usage data via  for each early adopter wiki.
 * 7) We run A/B tests for logged-in users. A half of them can experience the changed interface, and a half does not see any difference. Next, we compare the statistics. In the case of negative results, we improve the change or roll it back.
 * 8) For logged-out, we compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.
 * 9) We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * 10) Our  make it easier for us to work with a few communities more closely, react more quickly and effectively.

How can I disable it?
It's possible to turn the improvements on and off within user preferences. We have also provided an opt-out button in the left sidebar (accessible on each page): 

Will you remove the link that allows to opt-out?
We will not remove the opt-out link. Legacy Vector will continue to be available through that link, similar to other skins that have been default in the past, such as Monobook.

How can I report a bug?
Check the following page to see if your bug is a know issue.

You can add a task on Phabricator and add Desktop Improvements project tag or contact SGrabarczuk (WMF), email: sgrabarczuk@wikimedia.org.

Why not make a new skin? What will happen to Legacy Vector?
It would be an excellent idea to make a new skin, but in the case of Wikimedia skins, it's easier to change an existing one than to create a new one from scratch. There are various reasons:


 * it would be too complex to make the existing extensions, gadgets, and user scripts compatible with yet another skin, and too costly to maintain their compatibility,
 * it would be too challenging to build and maintain yet another skin (as a total replacement is not an option),
 * it would be less likely for the communities to collaborate effectively in the process of building a new skin.

Technically, Desktop Improvements are similar to previous features or projects such as or. The only difference is that this time, there will be more of them. Vector documentation should remain relevant.

We will keep and maintain the Legacy Vector. There is no intention of its removal.

Why not use beta features only?
Beta features are available for registered users only, and the improvements are intended to serve our readers and unregistered users as well. Therefore, using beta features only would give us feedback from a very specific type of user that is not representative of our entire base of users. And moreover, we wish to receive the readers' and anonymous users' feedback from the earliest deployments.

What are the feature's success metrics?
Increase utility among our existing audiences, proxied by:


 * Interactions
 * Increase searches per session by 5% over the course of the project
 * Increase language switching per project by 5% over the course of the project


 * Affinity
 * Increase in positive and welcoming sentiments towards the site (via surveys and user testing)
 * Increase in sentiments of trust and credibility (measured via surveys and user testing)

As we define the changes we want to make with more specificity, we will expand and iterate on this list.