User:SGrabarczuk (WMF)/faq



FAQ in nutshell

How can I disable it?
If you would like to disable it on one wiki:


 * Check if you're logged in. Logged-out users are not able to disable the skin
 * Either click on the Switch to old look link in the sidebar
 * Or go to the user preferences
 * Open the Appearance tab
 * Check "Vector legacy (2010)"

If you would like to disable it on all wikis:


 * 1) Go to the global preferences
 * 2) Open the Appearance tab
 * 3) Check the box to the left
 * 4) Check "Vector legacy (2010)"

Showing the setting to enable/disable Legacy Vector (the interface without our improvements)

Showing the opt-out button in the left sidebar

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

Why is the opt-out link not available for logged-out users?
This is because of the limited capability of our servers. The logged-out users can use browser extensions allowing them to personalize their interface, or they can create an account.

How can I enable it just for me on a Wikimedia wiki?

 * 1) Go to the user preferences
 * 2) Open the Appearance tab
 * 3) Check "Vector (2022)"

How can Vector 2022 become the default for all on my home Wikimedia wiki?
Contact us. We'll present the project to your community and start the discussion.

How can I enable it on my own/personal wiki?
If would like to see our changes,


 * 1) Make sure you have downloaded MediaWiki 1.39
 * 2) Add following lines in your LocalSettings.php:

We are glad to learn that you appreciate our improvements!

Why don't you provide preferences to choose between different versions of the features?
That would be too complicated to maintain and develop.

Each preference is like a crossroad where users can choose between options. Many choices indicate many combinations. Preferences would make us responsible for all the combinations. We would have to maintain them, and also, in the case of building new features, check if the features are compatible with each of the combinations. We can't afford that.

Instead, we give the communities the option to create gadgets, user scripts, and individual settings. As always, we provide the space for bottom-up creativity, and help technical users to maintain their code.

See also:


 * Just make it a user preference

What do you do for editors who need specific tools and features?

 * We contact volunteers with technical skills to ensure backward compatibility. We ask them to check the code they have written, and offer help if the code needs changes.
 * We make it possible to configure and personalize our changes. We are happy to work with volunteers with technical skills who would like to create new gadgets and user scripts.
 * We do not replace the work of volunteers with technical skills. In principle, we do not make edits to templates or create new gadgets, but can advise when necessary.

Will you fix gadgets which aren't working with your changes?
It depends.

We help volunteers fix gadgets and user scripts. Sometimes, we fix these ourselves. But in general, we work on MediaWiki itself. Gadgets and user scripts are written and maintained by volunteers. By the nature, these are always less stable and predictable.

If you are unsure on how to fix an issue with a script or gadget - contact us! We'll do our best to give advice on potential fixes.

See also
 * Tech - here you can ask for technical support as well
 * User:Jdlrobson/Extension:Gadget/Policy - a proposed policy on the roles and responsibilities related to gadgets and user scripts

Why don't you make Vector 2022 a beta feature?
Beta features are available for registered users only, and the improvements are intended to serve the 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.

What CSS classes should be used to customize Vector 2022?

 * skin-vector for both skins
 * skin-vector-legacy for Legacy Vector
 * skin-vector-2022 for Vector 2022

How to restore the full width?
We have prepared a gadget for you. In order to use it,


 * 1) Go to your custom JavaScript page and edit it
 * 2) In a new line, add
 * 3) Save the change.

How to disable the sticky elements?
Add the following CSS code to your global.css:


 * Header - add
 * ToC- add

How to restore the old table of contents?
Use the following JavaScript code:

How to make the button with language links appear at the top of the main page?

 * 1) Ask your community to agree to set up the main page heading. (See our explanation why this is a good idea.)
 * 2) The heading will be displayed in Vector 2010, Minerva, Timeless, and Vector 2022. It will not be visible in Monobook.
 * 3) The heading can be configured by edits to MediaWiki:Mainpage-title-loggedin for logged in users and MediaWiki:Mainpage-title for logged out users. For mobile logged in users, MediaWiki:wikimedia-mobile-mainpage-title-loggedin is used. See the details about the main page heading settings.
 * 4) Test what the main page looks like and work with the button at the top by adding the ?vectorlanguageinmainpageheader=1 parameter to the URL. See the example on the Icelandic-language Wikipedia. Note that the Icelandic-language Wikipedia hasn't the heading set up, so only the button appears.
 * 5) Contact us and ask us to move the button to the top.
 * 6) We will change the settings for your wiki.
 * 7) When we do this, the button will be visible at the top of the page in Vector 2022. In other skins, the list with language links will be displayed in the standard place which varies by skin.

How to restore the previous user menu?
It's not possible to do that currently.

How to change the logo to a temporary one?
[...]

How can I contact your team?
Choose one of the following options:


 * Talk page of the main page of the project (you can write in any language)
 * Phabricator task with the Desktop Improvements project tag
 * Contact our Community Relations Specialist: SGrabarczuk (WMF) sgrabarczuk@wikimedia.org
 * Contact one of our ambassadors:
 * French and Italian ambassador: Patafisik (WMF) patafisik-ctr@wikimedia.org
 * Spanish ambassador: Zapipedia (WMF) izapico-ctr@wikimedia.org
 * Vietnamese ambassador: Bluetpp (WMF) ppham-ctr@wikimedia.org
 * Farsi ambassador Mehran (WMF) mehran@wikimedia.org

How can I report a bug?
Check the following page to see if your bug is a known issue: Reading/Web/Desktop Improvements/Breaking changes.

If it's not recorded there, use the options listed above.

How can I follow your activities?

 * Subscribe to our newsletter. Instead of messages on your talk page, you will be receiving notifications about the updates.
 * Watch our Updates and Talk to Web pages.

Do you host or attend online meetings?
Yes!

We organize open online meetings for the communities (office hours). At these meetings, Olga (our product manager) makes presentations about the recent developments. Next, community members can ask any questions about the project.

We are also open to invitation to any community event online. These may be local, country-wide, or international meetings.



Is this a redesign?
No.

A redesign would be a single major change which affects how the site works. In the case of this project we are making a series of changes that do not remove any of the currently available tools. Each feature is a separate small project, joined together by a cohesive visual design.

What is the timeline of this project?
We have been working on Vector 2022 (originally known as modern Vector) since 2019. The deadline to build everything we've planned so far is August/September 2022. Currently, we inform about our intention to introduce Vector 2022 on more wikis. Vector 2022 isn't "beta" anymore. It's more like a bit less than a Good Article. We ask the communities what should be done to make the skin better.

See also:


 * How can the changes be made on my home Wikimedia wiki?

Why do you use the word Improvements?
Because we have data indicating that the changes are for the better.

The features we are making public on early adopter wikis have been tested and will continue to be improved as we learn more.

See also:


 * An encyclopedic article: Iterative and incremental development
 * Answers to the question: Why is my wiki an early adopter wiki?
 * A blog post: The iterative design of the Vector interface: the case of moving interlingual links

How do you know if the changes are for the better?

 * 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. (Example)
 * 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 is the "beta" phase. On these wikis, we perform quantitative tests for whether each feature works as expected.
 * 5) We perform 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.
 * 6) When we have the test results, we compare the results with the criteria of success we have previously defined. If we get negative results from our test, we change the feature and test again.
 * 7) During this phase, we also monitor usage across all wikis, where many account holders are already using Vector 2022.

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.

See also:


 * What CSS classes should be used?

Will you remove legacy Vector?
No.

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.

Which wikis are these changes turned on by default?
Currently, these are: Additionally:
 * [ https://office.wikimedia.org/ Office Wiki]
 * 
 * MediaWiki wiki
 * Wikimedia Foundation Governance wiki
 * Collab wiki
 * Strategy wiki



Are these changes made for readers, and not for editors?
Not exactly.

Our team (Web, formerly Reading 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 very 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 want 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.

See also:


 * What do you do to ensure that the change is not half-finished?
 * What do you do for editors who need specific tools and features?
 * Past projects of the Web team

What tools is the Foundation building for editors?
At the Foundation, there are other teams working on projects dedicated specifically to editors. Among them, there are:


 * Community Tech - working on projects selected by the communities during the Community Wishlist Survey
 * Editing - working on the discussion tools
 * Growth - working on the Newcomer experience project
 * Moderator Tools - focusing on the moderation needs of medium-sized Wikimedia projects
 * Anti-Harassment Tools - working on tools for administrators, anti-vandalism patrollers

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

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?
No.

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.

See also:
 * Core Experiences

Are you focused on Wikipedia articles?
Yes.

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.

Do you remember about sister projects?
Yes!

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, often making adjustments to the default features where necessary.

Non-Wikipedia projects, such as French Wiktionary, were also a part of our partner communities, ensuring that we have 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 extension.

Are you focused on English Wikipedia?
No.

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.

Why is my wiki an early adopter wiki?
We asked various wikis to join the early adopters. This allows us to...

[We deploy changes with the feedback of these communities.]

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

 * Research we make is relevant to all wikis and includes voices from many different languages and projects.
 * We gather and incorporate feedback from the communities. Most issues are relevant to all wikis.
 * How we adjust our changes to sister projects – go to "Do you remember about sister projects?"
 * What is our approach to gadgets – go "What do you do for editors who need specific tools and features?"

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:


 * What do you do for editors who need specific tools and features?
 * How to customize Vector 2022?

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

Have your changes been tested on users with disabilities?
Yes.

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.

Are the changes inspired by mobile design?
No.

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 to your global.js.

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!

See also:


 * What do you do for editors who need specific tools and features?



Readability
Reading efficiently is crucial to most people using our projects. We are going to improve the readability of the content.

There are several factors that affect readability – i.e. font size, contrast, font, and line length. We have decided to focus on line length initially.


 * 1) When reading short lines, we don't move our 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.

What about the white space?
Our goal is to create the best reading experience we can, not to fill every pixel of the screen with content. People are able to read more easily with shorter line lengths, and focus more easily without the distraction of sidebars or other elements. If the best layout is one that includes empty space that is okay — there is nothing inherently wrong with empty space.

We are also using some of this space for other functionality. We have made the sidebar sticky, and have placed the table of contents and other page tools next to the content. Also, limiting the content width gives us new options for the more distant future. Community members have suggested to put infoboxes, images, or references there.

What can I do if the page is too bright for me due to all the white space?
[...]

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. 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 couldn't the list with language links stay in the sidebar?
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.

Will the Wikidata links be closer to the list with language links?
Yes.

"", "", and "" 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?
1. The recommended option


 * 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:
 * If on your wiki, the coordinates are placed by a template, follow the instructions on Adding page status indicators.

2. A different option (not recommended)

Use the absolute positioning in the MediaWiki:Common.css, for example: Consider pages which use page status indicators, pages which have banners or site notices, and the look of the pages at lower resolutions.

Why the button with language links doesn't appear at the top of the main page?
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.

See also:


 * How to make the button with language links appear at the top of the main page?

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.

Why can't I collapse the table of contents?
The feature is still in development. This will be fixed before we make Vector 2022 the default on more skins.

Why doesn't it appear when I complete an edit?
The feature is still in development. This will be fixed before we make Vector 2022 the default on more skins.

How can I get the old table of contents?
We intentionally do not add the old table of contents to the article in addition to the new sidebar location. It's a trade off we've taken to reduce the work involved maintaining the code and keeping the site optimized. The old table of contents displayed in addition to the new one would increase the overall size of HTML, increase the storage requirement for our parser cache, and require additional CSS to render.

See also:


 * How to restore the old table of contents?

How do magic words work with this feature?
The and  magic words will 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, will continue to work, as will 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 will continue to work for other skins which render the ToC within the article.

I can't see the table of contents when the sidebar is open
This is a known problem. The sidebar should be closed by default unless you opened it, so this issue should only impact logged in users who have opened the sidebar. In the long term, we plan to reduce the size of this menu, and make the sidebar overlay content. Details and a prototype of how that will look can be found in T302073. This change is planned in the latter part of the year (October-December 2022). Further information can be found on the page about Page tools.

Will you change Monobook or Timeless?
No.

These changes will be 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 will not be changed at all.

Will you improve charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, and other templates?
No. We will not change anything within the light gray article content area (except for the table of contents):

Will you build the dark mode?
No, not this time.

We would like to build the dark mode available for logged-out users. This is impossible for technical reasons which are beyond our decision-making.

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.