MediaWiki

Lesen/Web/Desktop-Verbesserungen/Häufig gestellte Fragen

< Reading | Web | Desktop Improvements
This page is a translated version of the page Reading/Web/Desktop Improvements/Frequently asked questions and the translation is 47% complete.
Outdated translations are marked like this.
Languages:
Ändern
Kontakt und Grundlagen
Design und Zielgruppen
Einzelne Merkmale


Vector 2022 de-/aktivieren

Wie kann ich den Skin für mich auf einem oder allen Wikimedia-Wikis aktivieren oder deaktivieren?

Überprüfe zunächst, ob du angemeldet bist. Unangemeldeten Benutzern ist das Ändern des Skins nicht möglich.

Einzelnes Wiki Alle Wikis
Deaktivieren
  1. Öffne die Globalen Einstellungen
  2. Öffne den Tab Aussehen
  3. Aktiviere das Auswahlfeld am linken Rand
  4. Aktiviere "Vector alt (2010)"
Aktivieren
  1. Öffne die Einstellungen
  2. Öffne den Tab Aussehen
  3. Aktiviere "Vector (2022)"
  1. Öffne die Globalen Einstellungen
  2. Öffne den Tab Aussehen
  3. Aktiviere das Auswahlfeld am linken Rand
  4. Aktiviere "Vector (2022)"
  •  
    Die Einstellung zum De-/Aktivieren des alten Vector-Skins (ohne unsere Verbesserungen)
  •  
    Die Einstellung zum Opt-Out in der Seitenleiste links
  •  
    Link zum Opt-Out im Detail

Siehe auch:

Grund dafür sind beschränkte Kapazitäten unserer Server. Nicht angemeldete Benutzer können die Oberfläche über Browsererweiterungen anpassen oder ein Benutzerkonto anlegen.

Siehe auch:

Wie kann Vector 2022 der Standardskin für mein Heimatwiki werden?

Nimm Kontakt mit uns auf. Wir werden eurer Community das Projekt vorstellen und die Diskussion beginnen.

Wie kann ich den Skin auf einem eigenen/persönlichen Wiki aktivieren?

Wenn du unsere Veränderungen nutzen möchtest, dann:

  1. Stell sicher, dass du MediaWiki 1.39 heruntergeladen hast
  2. Ergänze die folgende Zeile in deiner LocalSettings.php :
$wgDefaultSkin = 'vector-2022';

Es freut uns, zu hören, dass du unsere Verbesserungen zu schätzen weißt!

Vector 2022 anpassen

Warum gibt es keine Einstellmöglichkeit, um zwischen verschiedenen Versionen einer Funktion wählen zu können?

Die Entwicklung und Wartung wäre zu kompliziert.

Jede Einstellmöglichkeit ist wie eine Weggabelung, an der Benutzer sich zwischen verschiedenen Optionen entscheiden können. Durch zahlreiche Optionen entstehen viele mögliche Kombinationen. Mit Einstellmöglichkeiten wären wir auch verantwortlich für alle diese Kombinationen. Wir müssten diese warten und sicherstellen, dass neue Funktionen mit jeder der Kombinationen fehlerfrei zusammenarbeiten. Das schaffen wir nicht.

Stattdessen können Communitys Gadgets, Benutzerskripte und individuelle Einstellungen erstellen und festlegen. Wie immer bieten wir diesbezüglich Raum für aus den Projekten kommende Kreativität und helfen Entwicklern aus der Community beim Warten ihrer Codes.

Siehe auch:

Warum gibt es keine Einstellungen für nicht angemeldete Benutzer?

Dies war von 2019 bis 2023 unsere Antwort. 2023 haben wir an Einstellungsmöglichkeiten für nicht angemeldete Benutzer gearbeitet. Dabei haben wir diese Möglichkeit innerhalb der nachfolgend beschriebenen Beschränkungen geschaffen.

Einstellungsmöglichkeiten für nicht angemeldete Benutzer würden zu einer zu langen Ladezeit führen.

Die meisten Aufrufe kommen durch nicht angemeldete Benutzer. Um das Aufrufvolumen zu bewältigen, haben wir einige "Caching-Server", die lediglich "Schnappschüsse" unserer Webseiten speichern und ausliefern. Diese "Schnappschüsse" können bis zu sieben Tage alt sein, ersetzen das Generieren der Webseite bei jedem Aufruf und sind für alle nicht angemeldeten Benutzer gleich. Damit ist es uns möglich, die Seiten schnell auszuliefern.

Mit Einstellmöglichkeiten wäre es erforderlich, verschiedene Versionen einer Webseite zu generieren. Dies für nicht angemeldete Benutzer anzubieten, würde unsere Server überlasten. Wir möchten dies außerdem vermeiden, um die Fragmentierung des Caches zu reduzieren.

Die einzige Möglichkeit, Einstellungen für nicht angemeldete Benutzer bereitzustellen, ist, diese immer nach dem Seitenaufbau zu laden. Das benötigt deutlich mehr Ladezeit und kann zu einer seltsamen Darstellung führen. Wenn ein Benutzer beispielsweise eine Seite im Darkmode sehen möchte, würden alle Seiten direkt nach dem Laden zunächst für kurze Zeit hell erscheinen und erst danach in das dunkle Farbschema umschalten.

Zum Verständnis: dass wir Einstellungsmöglichkeiten für angemeldete Benutzer haben können, liegt daran, dass diese keine "Schnappschüsse" der Seiten erhalten. Und das ist deshalb möglich, weil das Aufrufvolumen von angemeldeten Benutzern klein ist.

Siehe auch:

Was tut ihr für Autoren, die bestimmte Werkzeuge und Funktionen benötigen?

  • Wir setzen uns mit den Freiwilligen mit technischem Sachverstand in Verbindung, um Rückwärtskompatibilität zu gewährleisten. Wir bitten sie, von ihnen geschriebenen Code zu überprüfen und helfen, wenn Anpassungen nötig sind.
  • Wir ermöglichen die Konfiguration und Anpassung unserer Änderungen. Wir arbeiten gern mit technisch Beitragenden zusammen, die neue Gadgets und Benutzerskripte entwickeln wollen.
  • Wir ersetzen die Arbeit Freiwilliger nicht. Wir bearbeiten grundsätzlich keine Vorlagen und erstellen keine neuen Gadgets, können aber bei Bedarf Ratschläge geben.

Werden Gadgets, die nach den Änderungen nicht mehr funktionieren, repariert?

Es kommt darauf an.

Wir helfen Freiwilligen dabei, Gadgets und Benutzerskripte zu reparieren. Manchmal machen wir das selbst. Aber im Allgemeinen arbeiten wir an MediaWiki selbst. Gadgets und Benutzerskripte werden von Freiwilligen erstellt und gewartet. Es liegt dabei in der Natur der Sache, dass sie immer weniger stabil und vorhersagbar laufen.

Wenn du unsicher bist, wie ein Problem mit einem Skript oder Gadget zu beheben wäre - sprich uns an. Wir werden versuchen, Ratschläge für mögliche Lösungen zu geben.

Siehe auch:

Welche CSS-Klassen sollten für die Anpassung von Vector 2022 genutzt werden?

  • skin-vector-legacy für den alten Vector
  • skin-vector-2022 für Vector 2022

Siehe auch:

Wiederherstellen der vollen Seitenbreite

If your screen is at least 1400px wide, in the bottom corner, you should see a button  . Click it, and the full width will be restored.

Du kannst außerdem:

Einzelnes Wiki Alle Wikis
  1. Öffne die Einstellungen
  2. Öffne den Tab Aussehen
  3. Deaktiviere "Modus für begrenzte Breite aktivieren"
  1. Öffne die Globalen Einstellungen
  2. Öffne den Tab Aussehen
  3. Aktiviere das Auswahlfeld am linken Rand
  4. Deaktiviere "Modus für begrenzte Breite aktivieren"


Um weiteren Leerraum an den Seitenrändern zu nutzen, kannst du folgendes CSS in deiner global.css ergänzen: 

.mw-page-container {
  padding-left: 2.25em;
  padding-right: 1.25em;
}

#siteNotice {
    margin:0
}

Siehe auch:

Fixierte Elemente deaktivieren

Ergänze deine global.css um das folgende CSS:

  • Kopfbereich - ergänze 
    .vector-sticky-header {display:none;}
  • Inhaltsverzeichnis – ergänze 
    .sidebar-toc {position: static;}

Inhaltsverzeichnis im Seitentext wiederherstellen

Nutze folgenden JavaScript-Code: 

document.querySelector('meta[property="mw:PageProp/toc"]').replaceWith(
    $('#vector-toc, .mw-table-of-contents-container')
    .removeClass('mw-sticky-header-element' ).removeClass( 'vector-toc.vector-pinnable-element' ).removeAttr('id')
    .removeClass('mw-table-of-contents-container')[0].querySelector( 'ul' ).cloneNode( true )
)
    
$('#vector-toc-pinned-container,#vector-page-titlebar-toc,#vector-sticky-header-toc').remove();

Dabei ist zu beachten, dass das Inhaltsverzeichnis nicht wie althergebracht aussehen wird. Dafür würde bei Bedarf zusätzliches CSS benötigt werden.

Abschnittsnummerierung im Inhaltsverzeichnis wiederherstellen

Ergänze folgenden CSS-Code in deiner global.css:

User:Jdlrobson/vector-2022/tocNumbering.css

Sprachauswahl oben auf der Hauptseite anzeigen

  1. Finde einen Konsens in deiner Community, eine Überschriftszeile auf der Hauptseite anzuzeigen. (Siehe auch unsere Erklärung, warum das eine gute Idee ist.)
    1. Die Überschriftszeile wird in Vector 2010, Minerva, Timeless udn Vector 2022 angezeigt werden. Unter Monobook wird sie nicht angezeigt.
    2. Die Überschriftszeile kann mit MediaWiki:Mainpage-title-loggedin für angemeldete und MediaWiki:Mainpage-title für nicht angemeldete Benutzer konfiguriert werden. Für angemeldete Benutzer in der Mobilversion wird MediaWiki:wikimedia-mobile-mainpage-title-loggedin genutzt. Beachte die Details zu den Einstellungen der Hauptseiten-Überschriftszeile.
    3. Überprüfe das Aussehen der Hauptseite und teste die Sprachauswahl durch Ergänzen von ?vectorlanguageinmainpageheader=1 in der URL. Siehe auch das Beispiel Isländische Wikipedia. Hinweis: die isländische Wikipedia hat keine Überschriftenzeile definiert, also erscheint lediglich die Sprachauswahl.
  2. Tritt mit uns in Kontakt und bitte um das Verschieben der Sprachauswahl.
    1. Wir werden die Einstellung für dein Wiki anpassen.
    2. Dadurch wird die Auswahl unter Vector 2022 am Seitenbeginn erscheinen. Unter anderen Skins verbleiben die Sprachlinks an ihrem jeweiligen althergebrachten Platz.

Wiederherstellen des bisherigen Benutzermenüs

Dies ist derzeit nicht möglich.

Logo temporär ändern

Das Logo besteht unter Vector 2022 aus drei Elementen, die unabhängig voneinander mit CSS geändert werden können.

  • Ändern des Icons (z. B. der Wikipedia-Globus): 
    .mw-logo-icon { content: url("INSERT NEW IMAGE URL HERE") };
  • Ändern der Wortmarke (z. B. das Wort "Wikipedia"): 
    .mw-logo-wordmark { content: url("INSERT NEW IMAGE URL HERE") };
  • Ändern des Untertitels (z. B. "Die freie Enzyklopädie"): 
    .mw-logo-tagline { content: url("INSERT NEW IMAGE URL HERE") };

Kontakt

Wie kann ich das Team konaktieren?

Folgende Möglichkeiten stehen dir zur Verfügung:

Wie kann ich eure Arbeit verfolgen?

Haltet ihr Online-Meetings ab oder nehmt daran teil?

Ja!

Wir organisieren offene Onlinetreffen für Communitys. Auf diesen Treffen hält Olga (unsere Produktmanagerin) Vorträge über die jüngsten Entwicklungen. Anschließend kann die Community Fragen zum Projekt stellen.

Wir nehmen auch gern Einladungen zu anderen Online-Communityveranstaltungen an. Das können regionale, landesweite oder internationale Meetings sein.

 

Was sind Vector 2022 und die Desktop-Verbesserungen?

Handelt es sich um ein Redesign?

Nein.

Ein Redesign wäre eine einzelne grundlegende Änderung, die die Benutzung der Website ändert. In diesem Projekt haben wir mehrere einzelne Änderungen vorgenommen. Jedes Funktion war ein eigenes kleines Projekt. Am Ende wurden diese Funktionen durch ein gemeinsames visuelles Design zusammengefasst.

Was ist die Zeitschiene des Projektes?

Wir haben seit 2019 an Vector 2022 (ursprünglich moderner Vector benannt) gearbeitet. Zwischen dem Jahresbeginn 2020 und Jahresmitte 2022 haben wir verschiedene Funktionen für Wikis eingeführt, die sich frühzeitig am Prozess beteiligt haben ("early adopter"). (Mehr dazu erfährst du in der Antwort zur untenstehenden Frage, Punkte 2 bis 4)

Dieser Teil ist abgeschlossen. Vector 2022 ist nicht mehr im "Beta"-Status. Derzeit beabsichtigen wir die Einführung von Vector 2022 in allen Wikis.

Warum nennt ihr es Verbesserungen?

 
Der Begriff early adopter ist im Wikipedia-Artikel erklärt.

Weil unsere Erhebungen zeigen, dass Verbesserungen eingetreten sind:

  1. We identified problems through research with both readers and editors. During this phase, in 2019, we studied the way people used the sites and identified the largest usability issues. We also identified issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries, locations, and languages. See: Research and design: Phase 1, Research and design: Phase 2.
  2. We built and tested prototypes. We built out the ideas of each feature and began showing them to the users. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. For testing with editors, we used central notice banners. We displayed them across multiple language and Wikimedia projects so that we can get a wide and diverse audience. Each prototype was tested by approximately 200 editors on average. (Beispiel)
  3. We refined and built our features. We took the feedback from the prototype testing and refined or changed the prototypes accordingly. In some cases, we asked for additional feedback to ensure we're making the right decisions.
  4. We contacted various wikis asking to join the early adopters ("pilot wikis"). This was the "beta" phase. On these wikis, we performed quantitative tests for whether each feature worked as expected.
    1. We performed A/B testing on logged-in users. Unfortunately, we are not able to perform these on logged-out users. This is why we make before and after comparisons.
    2. When we had the test results, we compared the results with the criteria of success we had previously defined. When we got negative results from our test, we changed the feature and test again.
    3. Since this phase, we have also monitored usage across all wikis, where many account holders have already been using Vector 2022.

Siehe auch:

On which wikis have you tested these changes?

The pilot wikis where we have been testing Vector 2022 have been:

* Wikipedias mit lateinischer Schrift: * Wikis mit nicht-lateinischer Schrift: * Schwesterprojekte:
Arabischsprachiges Wikisource Ja Ja
Moroccan Arabic Wikipedia Ja
Bengalische Wikipedia Ja
Katalanischsprachige Wikipedia Ja
Deutschsprachige Wikivoyage Ja
Baskische Wikipedia Ja
Persische Wikipedia Ja
Französischsprachige Wikipedia Ja
Französischsprachiges Wikiquote Ja
Französischsprachiges Wiktionary Ja
Indonesische Wikipedia Ja
Hebräische Wikipedia Ja
Koreanischsprachige Wikipedia Ja
Polnischsprachige Wikinews Ja
Polnischsprachige Wikisource Ja
Portuguese Wikinews Ja
Portugiesischsprachige Wikipedia Ja
Portugiesischsprachiges Wiktionary Ja
Serbischsprachige Wikipedia Ja Ja
Thailändischsprachige Wikipedia Ja
Türkischsprachige Wikipedia Ja
Venetian Wikipedia Ja
Vietnamesischsprachige Wikibooks Ja
Vietnamesischsprachige Wikipedia Ja

Why do you use this naming: Vector 2022 and legacy Vector?

The new skin is a continuation of many of the ideas in the original Vector skin. It is being built using the code the Vector skin uses. We wanted to maintain functional and visual continuity. Everything built and meant for legacy Vector should be working with our changes, or can be configured to do so fairly easily.

The version built in 2010 and developed until 2019 has been frozen. In other words, we will keep and maintain it, but will not be building new features for it.

We use the name Vector 2022 for purely technical reasons. This name marks when the new Vector was available to third-party wikis as a new skin. (Third parties mean those who install MediaWiki).

On each wiki, the skin name can be overriden by changing MediaWiki:Skinname-vector-2022. However, this may cause confusion since it won't change the associated skin key that is used for site and user styles.

Siehe auch:

Will you remove legacy Vector?

Nein.

Legacy Vector will continue to be available as an option in Preferences, similar to other skins that have been default in the past, such as Monobook.

 

Target audience

Are these changes made for readers, and not for editors?

Not exactly.

Our team (Web) works on the reading (viewing) experience on desktop and mobile browsers. Those who both view and edit, and those who view but do not edit, are one large group of the interface users. We work for all of them, bearing in mind that new and advanced editors have specific needs.

The goal of this project is to improve the reading experience on desktop without making editing more difficult.

That said, our movement strategy recommendations implore us to improve our user experience in an inclusive manner. In this spirit, the project has a specific goal of ensuring the free knowledge grows equitably in the future. When building, we made sure to collect the voices of readers from different demographics and geographies. We also wanted to make their opinions a focus when defining what we were to work on, and evaluating whether a given idea was able to satisfy their needs.

Siehe auch:

What tools are the Foundation building for editors?

At the Foundation, there are other teams working on projects dedicated specifically to editors. Among them, there are:

Do your changes have a negative effect on the editing statistics?

Nein.

We collect statistics of the editing activity on all wikis. Compared to wikis with Vector legacy (2010) as the default, on wikis with Vector 2022 as the default, there are no negative differences.

Do your changes make it more difficult to explore the community side of the wikis?

Nein.

Readers and new editors are intimidated by large numbers of links, options, and ways of exploring the editing (in other words, the community) side of the Wikimedia projects. This is a finding of our research.

We want more users to join the communities. We do this by limiting the number of the unhidden links, and bringing additional focus on the most relevant ones. All this is done in collaboration with the Growth and Editing teams.

Siehe auch:

Are you focused on Wikipedia articles?

Ja.

Wikipedia articles, as a whole, have the most part of the viewership and readership compared to other namespaces on Wikipedia or any other projects. We also make adjustments to pages from other namespaces and special pages. Pages which we have made special adjustments and configurations for include: main pages, pages specific to some sister projects, special pages, the 2010 wikitext editor, the 2017 wikitext editor, and the Visual Editor.

We have also been working with the Editing team to ensure that the work they are doing for talk pages aligns with our work, and that special configurations for talk pages are put in place.

Have you been mindful of sister projects?

Ja!

We aim to change the basic elements of the interface. Most features work on the sister projects just as well as they improve Wikipedia. We have made sure to test and build for different sister projects from the beginning of the project. We still make adjustments to the default features where necessary.

Non-Wikipedia projects, such as French Wiktionary, were also a part of our partner communities since 2020. We ensured we have had direct communication and feedback from them.

Regarding the adjustments, for example, on Wikisource, the limited width does not apply to the Page namespace provided by the Proofread Page extension.

Are you focused on English Wikipedia?

Nein.

We take into account the needs of various communities and test our changes across 30+ languages. We are also inspired by the interface and gadgets built on various wikis, for example Korean and Vietnamese Wikipedias.

What do you do to ensure that the change would work on my wiki?

What do you do to ensure that the change is not half-finished?

We make tweaks both before and after we introduce the changes on wikis to make sure they are up to the needs for individual communities. If you think your community would benefit from more adjustments and gadgets, see:

After making these changes on all wikis, we will work on projects related to Desktop Improvements.

Accessibility

Have your changes been tested on users with disabilities?

Ja. We are working with the American Foundation for the Blind. We are asking various questions related to the accessibility of Vector 2022. See more on Phabricator.

Will the wikis be less accessible for users with slow Internet connection?

Nein.

We want to keep the new skin similarly code-heavy to legacy Vector.

Siehe auch:

Mobile, large screens, and responsiveness

Are the changes inspired by mobile design?

Nein.

These changes are created specifically for desktop interfaces. All research and testing done for this project has been focused on desktop users only. We have, however, considered the experiences of people who use desktop in narrower screens (for example, if you have two tabs open side by side).

At this time, we do not have plans to merge the desktop and mobile experiences.

Will the new interface be responsive?

We've been working towards that goal, but it's not an official goal of the project.

If you want to make the interface responsive now and you're using Wikimedia wikis, add the following to your global.js: 

if

( mw.config.get("skin") === "vector-2022")

{

document.head.innerHTML += '<meta name="viewport" content="width=device-width, initial-scale=0.77, maximum-scale=1.0, user-scalable=0">';

}

If your community would like this to be the default, please start a conversation on your wiki, and contact us when consensus is reached. We can then make the change.


Will you build a dedicated setting for high resolutions?

We don't have plans to build a specific setting at this time. We want the experience to be optimized for the majority of users, while still providing the tools necessary at all resolutions. We believe the current version of the new skin does this successfully. That said, we encourage personal customization!

Siehe auch:

 

Why is the width of the content limited?

Why have you replaced the area used for content by an empty space?

Reading efficiently is crucial to most people using our projects. Our goal here is to improve the readability of the content. There are several factors that affect it – i.e. font size, contrast, font, line length, and empty space.

Kürzere Zeilen
  1. When reading short lines, readers don't move their eyes too much, use the eye's muscles less intensively, thus avoiding eye strain.
  2. Narrow paragraphs allow readers to memorize new information better.
  3. On websites, there should be between 35 and 100 characters per line. Numbers closer to the smaller end are preferred.
  4. The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad.
Empty (white) space
  1. White space is used for the eyes' resting spots. It helps readers over the age of 60 focus on content and increases content comprehension by 20%.[1]
  2. People are able to focus more easily without the distraction of sidebars or other elements.
  3. We are using some of this space for other functionality. We have made the sidebar sticky, and have placed the table of contents next to the content. Also, limiting the content area gives us new options for the more distant future. Community members have suggested to put infoboxes, images, or references there. As a separate project, we will consider ways of using this space.

Siehe auch:

Why can't we leave it for readers to narrow their browser windows down?

Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. What's more, most readers only stay on our websites for about 20 seconds. That's not enough to personalize the website. Wikis should be good-looking immediately, in their basic form.

Some tables and templates don't fit within the limited width

We should make sure that all of our content is as responsive as possible to accommodate all visitors. A large percentage of our users, who don't have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change.

Why don't you just make it a setting?

We want it to be default. We are building a common experience that is shared between editors and readers. This could be helpful to editors when making decisions about page layouts. Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a limited width, we don't remove this discrepancy (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

Note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that's not quite the same thing.

Why did you change the list of language links?

 
Vector 2022 language switcher location

Because from the readers' perspective, the sidebar is not a place for useful links. Most readers focus on the content area. Links in the sidebar are practically hidden from their sight.

Also, we need to promote the variety of language versions of Wikimedia projects.

For more than 15 years, the list has been displayed in the sidebar. The most active users have developed muscle memory to look for that list in that place. This is why in the sidebar, we have placed a box with information about the language button being displayed in a new place.

Yes.

"Links auf Seiten in anderen Sprachen hinzufügen", "Links auf Artikel in anderen Sprachen bearbeiten", and "Wikidata-Datenobjekt" will eventually be part of the menu activated by the language switching button ("language menu"). This is a task for the Language engineering team.

How to fix the coordinates displaying incorrectly near the languages button?

  The recommended option   A different option (not recommended)
  • If on your wiki, the coordinates are placed by a Lua module (for example, on French Wikipedia, there's Module:Coordinates), use the following code:
    titleText = frame:extensionTag( 'indicator', tostring(htmlTitle), { name = 'coordinates' }    )
  • If on your wiki, the coordinates are placed by a template, follow the instructions on Adding page status indicators.

Use the absolute positioning in the MediaWiki:Common.css, for example: 

.skin-vector.skin-vector-legacy #coordinates { top: 0px; }

.skin-vector #coordinates { top: -20px; }

For those who prefer a working example, details on how this was fixed for English Wikipedia can be found here: phab:T281974#8869238.

Consider pages which use page status indicators, pages which have banners or site notices, and the look of the pages at lower resolutions.

We have discovered that readers focus on the content page and ignore the sidebar. They will be more likely to switch between languages if the button with the language links appears at the top of the page, next to the heading.

On many wikis, headings on main pages are hidden. This is why the button with language links isn't displayed next to it. Instead, it's at the bottom of the main pages. It is possible to make it appear at the top, though.

Siehe auch:

Why did you change the table of contents?

Why doesn't the table of contents work well on my mobile device or when I resize the browser?

Users on mobile and resized browsers account for a small fraction of page traffic. Because of this, we chose to build the feature for the majority of our users first. For narrow screens we plan to make the table of contents available as a sticky interface element that's accessible from anywhere in the page.

Note what is displayed to mobile devices differs from what you see when you resize your browser. On mobile devices, the site is currently presented as a zoomed out version of the desktop site.

Is it possible to change the label indicating the top of the page? ("Anfang")

Yes.

This label should be distinct from the content headings. To do that, wikis written in different scripts (for example, Latin and Japanese) and different Wikimedia projects (Wikipedia and Wiktionary) may need to use different words and/or punctuation marks in this label. It is possible for each community to set up a label that would work just for them. This may be done by editing the page MediaWiki:Vector-toc-beginning.

How can I get both the old and the new table of contents?

This isn't possible.

We intentionally do not add the old table of contents in addition to the new sidebar location. It's a trade off. We have taken it to reduce the work involved maintaining the code and keeping the site work as well as possible. The old table of contents displayed in addition to the new one would have important technical disadvantages. It would increase the overall size of HTML, increase the storage requirement for our parser cache, and require additional CSS to render.

See also:

How do magic words work with this feature?

The __TOC__ and __FORCETOC__ magic words do not work as the table of contents is always in the sidebar and this cannot be changed.

However, magic words relating to the presence of the table of contents, such as __NOTOC__, do work. So do templates which then create an alternate ToC. For example, an article can disable the default ToC and apply its own if necessary.

All magic words continue to work for other skins which render the ToC within the article.

My project's logo is incorrect. How do I fix this?

We've done our best to ensure that your project logo is consistent between the Vector legacy and Vector 2022 skin. However, there is a chance we've overlooked something or had to make a hasty decision without consulting your community.

Notably in the case of various Wiktionary, Wikiversity, Wikibooks projects, we show the project default logo. This is because we couldn't derive a logo for Vector 2022 from the existing Vector legacy logo. Customizations that localize the logo to your languages are however available on request. More context on this can be found at T341243.

Any project can update its logo or request a change to its logo. It needs to follow the Site request lifecycle. Please do not comment on any existing task relating to logos.

Was ist der Umfang des Projekts?

Werden Monobook oder Timeless davon betroffen sein?

No.

These changes are applied to Vector only. Vector has been the default interface on Wikimedia wikis since 2010. Any other skins such as Monobook, Timeless, Minerva or Modern are not be changed at all.

While working on Desktop Improvements, we did clean up the old skins' code, though. We made it easier to roll out new changes to old skins, removed never used options, and removed 75% of the PHP code of these skins. All this had no effect on the side users interact with.

See also:

Werden Sie Diagramme, Karten, a-/f-/o-/tmboxen, Infoboxen, Navboxen und andere Vorlagen verbessern?

No.

We do not change anything within the light gray article content area (except for the table of contents):

 

Are you building the dark mode?

Not as part of Desktop Improvements. In 2023, we started a project Accessibility for reading . Building dark mode is part of it.

What are the features' 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.

References

  1. ↑ UI Design Newsletter – December, 2005, Human Factors International
Retrieved from "https://www.mediawiki.org/w/index.php?title=Reading/Web/Desktop_Improvements/Frequently_asked_questions/de&oldid=7241469"