User:SGrabarczuk (WMF)/faq

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
 * Go to the user preferences or click on the Switch to old look link in the sidebar
 * Open the Appearance tab
 * Check "Vector legacy (2010)"

If you would like to disable it on all wikis:


 * Go to the global preferences
 * Open the Appearance tab
 * Check the box to the left
 * 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

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

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

How can the changes be made on my home Wikimedia wiki?
If you are interested to see Vector 2022 as the default on your home wiki,


 * 1) ask your community and reach the consensus,
 * 2) contact us.

After you reach consensus and contact us, we will need at least two weeks before we make the changes. We ask technical users to check how key gadgets and tools work in the meantime.

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 is the opt-out link not available for logged-out users?
This is because of the limited capability of our servers. We are not able to offer our readers (logged-out users) the opportunity to change the layout. They should either use browser extensions allowing them to personalize their interface, or create an account.

Will you remove the link that allows opt-out?
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.

Is this a redesign?
No.

A redesign would be a single major change. In the case of this project, we don't know what the interface will look like when we finish. What we do is a series of changes. Each feature is a separate small project.

When we finish building the last feature, we will work again on all of them as a whole. We will make them consistent and improve the styling.

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

We measure what change each of the new features brings. At the beginning of the work on the Desktop Improvements, we decided that if a given change is not positive, we will resign from it.

The features we are making public on early adopter wikis are first repetitions. There is a professional term "iterations". This is why we tolerate some imperfection.

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

Why do you use this naming: Vector 2022 and legacy Vector?
It's because the changes are the only development of the old Vector, now labeled as legacy. Our intention was to make our changes part of the default Vector, and maintain the technical continuity. Everything built and meant for legacy Vector should be working with our changes.

The version built in 2010 and developed until 2019 has been frozen. In other words, it is and will not be developed. We will keep and maintain it, though.

See also:


 * What CSS classes should be used?

What is the timeline of this project?
We have been working on them since 2019. The deadline is the end of August 2022. By then, we would like to ask the communities to adopt Desktop Improvements as the default.

Each community is welcome to ask to make the change sooner. For more information, skip to the "How can this be deployed on my home Wikimedia wiki?"

See also


 * How can the changes be made on my home Wikimedia 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.

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 community during the Community Wishlist Survey
 * Editing - working on the discussion tools
 * Growth - working on tools for mentors and newbies
 * Moderator Tools - focusing on the moderation needs of medium-sized Wikimedia projects
 * Anti-Harassment Tools - working on tools for administrators, anti-vandalism patrollers

How do you know what the "voiceless" users (including readers) think?

 * 1) Prior to introducing the changes on wikis, we performed user research. See the Repository page for more details.
 * 2) Shortly after the deployment of each feature improvement, we collect usage data via API for each early adopter wiki. We compare before and after. Unfortunately, we are not able to perform A/B tests on logged-out users.

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. Pages which require special adjustments are, for instance, main pages and pages specific to some sister projects.

At the same time, we don't only build for Wikipedia.

Do you remember about sister projects?
Yes!

We aim to change the basic elements of the interface. Most features will work on the sister projects just as well as they improve Wikipedia.

Over the course of the project, and not just at the end, we make necessary adjustments for sister projects. For example, on Wikisource, the limited width does not apply to the Page namespace provided by the Proofread extension.

We have already made a list of early adopter wikis which represent various sizes and scripts. We also wanted to ensure that at least one non-Wikipedia project is selected.

Are you focused on English Wikipedia?
No.

We take into account the needs of various communities. 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?

 * Research we make is relevant to all wikis.
 * 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?
Based on data we collect, we are convinced that our changes are improvements already. Also, we make tweaks both before and after we introduce the changes on wikis.

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.

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 or create new gadgets.

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 principle, we work on MediaWiki itself, and gadgets and user scripts are written and maintained by volunteers.

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
 * Email sgrabarczukwikimedia.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-ctr@wikimedia.org

How can I suggest improvements?
Add a section on the talk page of the main page of the project (in any language). You can also contact SGrabarczuk (WMF), email: sgrabarczukwikimedia.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.
 * Follow our Updates page.

Do you host or attend online meetings?
Yes!

We organize office hours. At these meetings, Olga (our product manager) makes a presentation about the recent developments, and 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.

How do you work with the communities?

 * Prior to introducing the changes on wikis:
 * We performed user research, and reviewed gadgets and user scripts. See the Repository page for more details.
 * We have been reaching out to various wikis asking to join the early adopters ("pilot wikis").
 * We had a roundtable discussion at Wikimania in 2019 (see the outcomes).
 * We ran four prototype testing rounds. Editors could use these to gain an understanding of our ideas, and share what they appreciate or find confusing.
 * Shortly after making each change, we collect usage data for each early adopter wiki. For logged-in users, we run A/B tests. 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.
 * We watch the project talk page. We also engage in discussions on individual wikis regularly.
 * Our contracted ambassadors make it easier for us to work with a few communities more closely, react more quickly and effectively.

Why is my wiki an early adopter wiki?
We have been asking various wikis to join the early adopters. We are deploying changes with the feedback of your community and our Ambassadors are calling for suggestions.

Early adopter wikis play an altruistic role and are needed to build the better features that will be deployed in all wikis.

We will improve the features with the A/B testing and analysis of quantitative data from users’ behaviours on the early adopter wikis.

Which wikis are these changes turned on by default?
Currently, these are:

We are open to adding more wikis to this list!

Additionally:
 * [ https://office.wikimedia.org/ Office Wiki]
 * 
 * MediaWiki wiki
 * Wikimedia Foundation Governance wiki
 * Collab wiki
 * Strategy wiki

Will the Desktop Improvements be available on mobile devices?
Yes.

If you switch from the mobile view, you will see the Desktop Improvements. However, this is not dedicated to mobile devices. These have their own default browser view. There are also apps.

See also


 * Advanced mobile contributions

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

if

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

{

document.head.innerHTML += '';

}

to your global.js.

Will you build a dedicated setting for high resolutions?
Perhaps in the final phase of the project. The basic versions of our changes should be as widely acceptable as possible.

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 UN, academic documents like LaTeX, and word processors like Google Docs and Etherpad.

What about the white space?
Table of contents next to the content. It's an interesting proposal by a Farsi Wikipedia user SerendiPity. This is well aligned with our intentions.

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 would like to use some of this space for other functionality. We have made the sidebar sticky, and are putting the table of contents and other page tools next to the content. Also, limiting the content width gives us new options for the future, such as a column dedicated to infoboxes and images.

Why can’t readers make their browser windows smaller?
We should optimise the layout around reading and aim to give people a good-looking website without them having to make adjustments.

Tables and some 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 link be closer to the list with language links?
Yes.

This is a task for the Language engineering team. They are working on a better list with language links ("language menu"). So far, one of the improvements was a functionality suggesting that a user may translate the article into more languages.

How to fix the coordinates displaying incorrectly near the languages button?
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: 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.

A different option (not recommended)

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

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

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

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 doesn't 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. We plan to make it possible to collapse the table of contents.

Why doesn't it appear when I complete an edit?
The feature is still in development. This will be fixed with a planned timeline of end of August 2022.

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 magic word will not work in Vector 2022 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 will continue to work. For example, an article can disable the default table of contents and apply its own if necessary.

All magic words will continue to work for other skins which render the table of contents 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 phab:T302073. This change is planned in the latter part of the year (October-December), and further information can be found on the page about Page tools.

What CSS classes should be used?

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

Why don't you provide preferences to choose between?
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.

For more information, read the "Just make it a user preference" essay by Quiddity (WMF).

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  mw.loader.getScript(' https://en.wikipedia.org/w/index.php?title=User:Jdlrobson/vector-max-width-toggle.js&action=raw&ctype=text/javascript' );
 * 3) Save the change.

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


 * Header - add .vector-sticky-header {display:none;}
 * ToC- add .sidebar-toc {display:none;}

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

$('.mw-table-of-contents-container').removeClass('mw-sticky-header-element' ).removeClass('mw-table-of-contents-container').appendTo(document.getElementsByTagName('mw:tocplace')[0])

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.

Will Monobook or Timeless be affected?
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 affected 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.

Will you remove legacy Vector?
No.

Everyone who is technically able to choose between skins can enjoy using Legacy Vector. It will not change.

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