Change Details

## Background As part of the [[ https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019/Brand_awareness | Wikimedia Foundation’s Medium term plan ]], the Readers Web team will be making significant improvements to the desktop experience of Wikimedia projects. Although Wikimedia desktop sites have evolved over time, their visual appearance has not changed significantly since the Vector skin was introduced almost a decade ago. There have been many efforts to improve the desktop interface through extensions, gadgets and templates, but the now antiquated appearance of the Vector skin has always stood in sharp contrast to these modernization efforts. This is why we feel that in order to provide a consistent and unified experience on desktop, we have to improve the underlying appearance of the skin itself. #### Project Goals The goal of the [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements | Desktop Improvements project ]] is to make Wikimedia wikis more welcoming to new readers and new editors while not disrupting the workflows of our most engaged community members. By overhauling the visual appearance of Wikimedia projects, we hope to strengthen the identity of the Wikimedia movement as a whole for current and future generations of Wikimedians. #### Project Scope Although ongoing research, design and [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Wikimania_Stockholm_research_report | community consultations ]] will ultimately determine the final shape of the Desktop Improvements project, we expect to make significant changes to the visual appearance the desktop UI (preliminary designs were shared at Wikimania and [[ https://www.mediawiki.org/w/index.php?title=File:Wikimania_-_desktop_improvements_session_final_version.pdf&page=1 | are publically available ]]). We will not be modifying content in any way. Also, we will be ensuring that customization features such as system messages, gadgets, user scripts/styles all continue to function. ------- ## Problem statement #### Project Requirements The Desktop Improvements project by nature affects everyone who interacts with Wikimedia projects so we must account for a multitude of stakeholders with a range of requirements. The current list of requirements is as follows: - The ability to make incremental change. Users shouldn’t experience an abrupt change to their workflows. - The ability for users to opt out of the new experience. - The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki. - The ability to run multivariate tests on the UI changes. - UI customizations are not restricted. This includes users styles/script and per-wiki customization of menus and other UI elements via system messages. - Templates continue to function as they currently do. - Gadgets continue to function. - Extensions deployed by the WMF should continue to function. - There shouldn’t be any negative performance impact from the new desktop experience. The broad range of stakeholders, from our global community of editors and template/gadget/skin authors to teams at the Wikimedia foundation maintaining the hundreds of extensions currently deployed on Wikimedia sites, along with the technical limitations of the MediaWiki platform, make this a [[ https://en.wikipedia.org/wiki/Cynefin_framework | complex/chaotic ]] problem space to consider. #### Main question Given the requirements and constraints mentioned above, the Readers Web team must decide the baseline upon which to implement such broad UI changes to the desktop interface of the Wikimedia projects. We are seeking input on this decision in order to uncover any concerns or alternative approaches that may have been overlooked or not thoroughly considered. ------- ## Proposals When considering how to implement broad UI changes to the desktop versions of Wikimedia projects, the engineers on the Readers Web team considered the following three options as possible foundations for the Desktop Improvements project. Each option has many pros and cons, but only the top three of each have been highlighted below. ### Proposal 1: Adapt the MinervaNeue skin for desktop Minerva is used as the foundation for the Desktop Improvements project. It becomes the default desktop skin for Wikimedia projects, replacing Vector. To meet the project requirement of incremental change, it will first become “vector-like” and gradually changes into whatever the new designs are from there on. **Pros** - Already mobile optimized. - Brings us closer towards a unified skin for mobile and desktop. - Under active development by the Readers Web team. **Cons** - Minvera depends heavily on the MobileFrontend extension. - Re-implements many core features such as sidebar and menus. - Would take considerable effort to achieve feature parity and visual parity with the current desktop experience. ### Proposal 2: Add improvements inside the Vector skin Vector remains the default skin on desktop and new improvements are made within the skin, with the current experience maintained in parallel. The new UI is feature-flagged and enabled on a per-component basis. **Pros** - Changes could start being made without the startup cost of changing the default skin. - A feature flagging system could give the flexibility to enable/disable individual UI components. - Compatibility with Vector-specific code is maintained, such as Vector.js/css and hard-coded “vector” strings. **Cons** - Requires developing a feature flagging system - Increased QA burden of ensuring we don’t break current Vector functionality. - A new user opt-in/out mechanism would have to be developed. ### Proposal 3: Fork Vector and create a new skin Vector is forked and a new skin is created. This new skin becomes the default for Wikimedia projects. Being a fork, it starts off as Vector but gradually changes as the Desktop Improvements project progresses. **Pros** - Changes can be made without the risk of introducing regressions into an existing skin. - Maintains near parity with desktop features (save for code that checks for string “vector”). - Opt-in/out mechanism is straightforward (i.e. switching skins). **Cons** - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 4: Create a new skin based on ExampleSkin that looks like Vector Suggested by @Isarra we could **Pros** - Using ExampleSkin would remove a lot of Vector's technical baggage - Can be made to look like Vector - Opt-in/out mechanism is straightforward (i.e. switching skins). - Inherits only technical debt from mediawiki core. **Cons** - Additional initial setup cost in tidying up HTML and CSS to mirror Vector - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential risk to parity with Vector - The PHP code for the new skin would be different from Vector so there may be a lot of undocumented differences that need to be accounted for, before the skin becomes viable/usable. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 5: … ------- ## Recommendation After much deliberation **the Readers Web team is proposing forking Vector and building a new skin** for Wikimedia projects on desktop. Every solution has its pros and cons, but ultimately the ability to build upon an established foundation without the risk of introducing regressions into either the current desktop or mobile experience make forking Vector a practical yet promising baseline for the Desktop Improvements project. The biggest argument against building a new skin may be the shortcomings of the current skin system itself. The responsibility of skins has not been clearly defined in MediaWiki, leading to unclear boundaries between skins and MediaWiki Core and extensions. However, by starting from a Vector fork we will be facing these problems head-on, and by addressing these issues at their core, we hope to make changes that will benefit the wider MediaWiki ecosystem wherever possible.

## Background As part of the [[ https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019/Brand_awareness | Wikimedia Foundation’s Medium term plan ]], the Readers Web team will be making significant improvements to the desktop experience of Wikimedia projects. Although Wikimedia desktop sites have evolved over time, their visual appearance has not changed significantly since the Vector skin was introduced almost a decade ago. There have been many efforts to improve the desktop interface through extensions, gadgets and templates, but the now antiquated appearance of the Vector skin has always stood in sharp contrast to these modernization efforts. This is why we feel that in order to provide a consistent and unified experience on desktop, we have to improve the underlying appearance of the skin itself. #### Project Goals The goal of the [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements | Desktop Improvements project ]] is to make Wikimedia wikis more welcoming to new readers and new editors while not disrupting the workflows of our most engaged community members. By overhauling the visual appearance of Wikimedia projects, we hope to strengthen the identity of the Wikimedia movement as a whole for current and future generations of Wikimedians. #### Project Scope Although ongoing research, design and [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Wikimania_Stockholm_research_report | community consultations ]] will ultimately determine the final shape of the Desktop Improvements project, we expect to make significant changes to the visual appearance the desktop UI (preliminary designs were shared at Wikimania and [[ https://www.mediawiki.org/w/index.php?title=File:Wikimania_-_desktop_improvements_session_final_version.pdf&page=1 | are publically available ]]). We will not be modifying content in any way. Also, we will be ensuring that customization features such as system messages, gadgets, user scripts/styles all continue to function. ------- ## Problem statement #### Project Requirements The Desktop Improvements project by nature affects everyone who interacts with Wikimedia projects so we must account for a multitude of stakeholders with a range of requirements. The current list of requirements is as follows: - The ability to make incremental change. Users shouldn’t experience an abrupt change to their workflows. - The ability for users to opt out of the new experience. - The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki. - The ability to run multivariate tests on the UI changes. - UI customizations are not restricted. This includes users styles/script and per-wiki customization of menus and other UI elements via system messages. - Templates continue to function as they currently do. - Gadgets continue to function. - Extensions deployed by the WMF should continue to function. - There shouldn’t be any negative performance impact from the new desktop experience. The broad range of stakeholders, from our global community of editors and template/gadget/skin authors to teams at the Wikimedia foundation maintaining the hundreds of extensions currently deployed on Wikimedia sites, along with the technical limitations of the MediaWiki platform, make this a [[ https://en.wikipedia.org/wiki/Cynefin_framework | complex/chaotic ]] problem space to consider. #### Main question Given the requirements and constraints mentioned above, the Readers Web team must decide the baseline upon which to implement such broad UI changes to the desktop interface of the Wikimedia projects. We are seeking input on this decision in order to uncover any concerns or alternative approaches that may have been overlooked or not thoroughly considered. ------- ## Proposals When considering how to implement broad UI changes to the desktop versions of Wikimedia projects, the engineers on the Readers Web team considered the following three options as possible foundations for the Desktop Improvements project. Each option has many pros and cons, but only the top three of each have been highlighted below. ### Proposal 1: Adapt the MinervaNeue skin for desktop Minerva is used as the foundation for the Desktop Improvements project. It becomes the default desktop skin for Wikimedia projects, replacing Vector. To meet the project requirement of incremental change, it will first become “vector-like” and gradually changes into whatever the new designs are from there on. **Pros** - Already mobile optimized. - Brings us closer towards a unified skin for mobile and desktop. - Under active development by the Readers Web team. **Cons** - Minvera depends heavily on the MobileFrontend extension. - Re-implements many core features such as sidebar and menus. - Would take considerable effort to achieve feature parity and visual parity with the current desktop experience. ### Proposal 2: Add improvements inside the Vector skin Vector remains the default skin on desktop and new improvements are made within the skin, with the current experience maintained in parallel. The new UI is feature-flagged and enabled on a per-component basis. **Pros** - Changes could start being made without the startup cost of changing the default skin. - A feature flagging system could give the flexibility to enable/disable individual UI components. - Compatibility with Vector-specific code is maintained, such as Vector.js/css and hard-coded “vector” strings. **Cons** - Requires developing a feature flagging system - Increased QA burden of ensuring we don’t break current Vector functionality. - A new user opt-in/out mechanism would have to be developed. ### Proposal 3: Fork Vector and create a new skin Vector is forked and a new skin is created. This new skin becomes the default for Wikimedia projects. Being a fork, it starts off as Vector but gradually changes as the Desktop Improvements project progresses. **Pros** - Changes can be made without the risk of introducing regressions into an existing skin. - Maintains near parity with desktop features (save for code that checks for string “vector”). - Opt-in/out mechanism is straightforward (i.e. switching skins). **Cons** - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 4: Create a new skin based on [[ https://www.mediawiki.org/wiki/Skin:Example | Skin:Example ]] that looks like Vector Suggested by @Isarra we could **Pros** - Using Skin:Example would remove a lot of Vector's technical baggage - Can be made to look like Vector - Opt-in/out mechanism is straightforward (i.e. switching skins). - Inherits only technical debt from mediawiki core. **Cons** - Additional initial setup cost in tidying up HTML and CSS to mirror Vector - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential risk to parity with Vector - The PHP code for the new skin would be different from Vector so there may be a lot of undocumented differences that need to be accounted for, before the skin becomes viable/usable. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 5: … ------- ## Recommendation After much deliberation **the Readers Web team is proposing forking Vector and building a new skin** for Wikimedia projects on desktop. Every solution has its pros and cons, but ultimately the ability to build upon an established foundation without the risk of introducing regressions into either the current desktop or mobile experience make forking Vector a practical yet promising baseline for the Desktop Improvements project. The biggest argument against building a new skin may be the shortcomings of the current skin system itself. The responsibility of skins has not been clearly defined in MediaWiki, leading to unclear boundaries between skins and MediaWiki Core and extensions. However, by starting from a Vector fork we will be facing these problems head-on, and by addressing these issues at their core, we hope to make changes that will benefit the wider MediaWiki ecosystem wherever possible.

## Background As part of the [[ https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019/Brand_awareness | Wikimedia Foundation’s Medium term plan ]], the Readers Web team will be making significant improvements to the desktop experience of Wikimedia projects. Although Wikimedia desktop sites have evolved over time, their visual appearance has not changed significantly since the Vector skin was introduced almost a decade ago. There have been many efforts to improve the desktop interface through extensions, gadgets and templates, but the now antiquated appearance of the Vector skin has always stood in sharp contrast to these modernization efforts. This is why we feel that in order to provide a consistent and unified experience on desktop, we have to improve the underlying appearance of the skin itself. #### Project Goals The goal of the [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements | Desktop Improvements project ]] is to make Wikimedia wikis more welcoming to new readers and new editors while not disrupting the workflows of our most engaged community members. By overhauling the visual appearance of Wikimedia projects, we hope to strengthen the identity of the Wikimedia movement as a whole for current and future generations of Wikimedians. #### Project Scope Although ongoing research, design and [[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Wikimania_Stockholm_research_report | community consultations ]] will ultimately determine the final shape of the Desktop Improvements project, we expect to make significant changes to the visual appearance the desktop UI (preliminary designs were shared at Wikimania and [[ https://www.mediawiki.org/w/index.php?title=File:Wikimania_-_desktop_improvements_session_final_version.pdf&page=1 | are publically available ]]). We will not be modifying content in any way. Also, we will be ensuring that customization features such as system messages, gadgets, user scripts/styles all continue to function. ------- ## Problem statement #### Project Requirements The Desktop Improvements project by nature affects everyone who interacts with Wikimedia projects so we must account for a multitude of stakeholders with a range of requirements. The current list of requirements is as follows: - The ability to make incremental change. Users shouldn’t experience an abrupt change to their workflows. - The ability for users to opt out of the new experience. - The ability to differentiate a Wikimedia site (e.g. Wikipedia) from a third-party site running MediaWiki. - The ability to run multivariate tests on the UI changes. - UI customizations are not restricted. This includes users styles/script and per-wiki customization of menus and other UI elements via system messages. - Templates continue to function as they currently do. - Gadgets continue to function. - Extensions deployed by the WMF should continue to function. - There shouldn’t be any negative performance impact from the new desktop experience. The broad range of stakeholders, from our global community of editors and template/gadget/skin authors to teams at the Wikimedia foundation maintaining the hundreds of extensions currently deployed on Wikimedia sites, along with the technical limitations of the MediaWiki platform, make this a [[ https://en.wikipedia.org/wiki/Cynefin_framework | complex/chaotic ]] problem space to consider. #### Main question Given the requirements and constraints mentioned above, the Readers Web team must decide the baseline upon which to implement such broad UI changes to the desktop interface of the Wikimedia projects. We are seeking input on this decision in order to uncover any concerns or alternative approaches that may have been overlooked or not thoroughly considered. ------- ## Proposals When considering how to implement broad UI changes to the desktop versions of Wikimedia projects, the engineers on the Readers Web team considered the following three options as possible foundations for the Desktop Improvements project. Each option has many pros and cons, but only the top three of each have been highlighted below. ### Proposal 1: Adapt the MinervaNeue skin for desktop Minerva is used as the foundation for the Desktop Improvements project. It becomes the default desktop skin for Wikimedia projects, replacing Vector. To meet the project requirement of incremental change, it will first become “vector-like” and gradually changes into whatever the new designs are from there on. **Pros** - Already mobile optimized. - Brings us closer towards a unified skin for mobile and desktop. - Under active development by the Readers Web team. **Cons** - Minvera depends heavily on the MobileFrontend extension. - Re-implements many core features such as sidebar and menus. - Would take considerable effort to achieve feature parity and visual parity with the current desktop experience. ### Proposal 2: Add improvements inside the Vector skin Vector remains the default skin on desktop and new improvements are made within the skin, with the current experience maintained in parallel. The new UI is feature-flagged and enabled on a per-component basis. **Pros** - Changes could start being made without the startup cost of changing the default skin. - A feature flagging system could give the flexibility to enable/disable individual UI components. - Compatibility with Vector-specific code is maintained, such as Vector.js/css and hard-coded “vector” strings. **Cons** - Requires developing a feature flagging system - Increased QA burden of ensuring we don’t break current Vector functionality. - A new user opt-in/out mechanism would have to be developed. ### Proposal 3: Fork Vector and create a new skin Vector is forked and a new skin is created. This new skin becomes the default for Wikimedia projects. Being a fork, it starts off as Vector but gradually changes as the Desktop Improvements project progresses. **Pros** - Changes can be made without the risk of introducing regressions into an existing skin. - Maintains near parity with desktop features (save for code that checks for string “vector”). - Opt-in/out mechanism is straightforward (i.e. switching skins). **Cons** - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 4: Create a new skin based on [[ https://www.mediawiki.org/wiki/Skin:Example | Skin:Example ]] that looks like Vector Suggested by @Isarra we could **Pros** - Using Skin:ExampleSkin would remove a lot of Vector's technical baggage - Can be made to look like Vector - Opt-in/out mechanism is straightforward (i.e. switching skins). - Inherits only technical debt from mediawiki core. **Cons** - Additional initial setup cost in tidying up HTML and CSS to mirror Vector - The technical complexity of deploying a new skin. - The maintenance cost for the development team of maintaining an additional skin. - The maintenance cost for the entire foundation of ensuring extensions work with an additional skin. - Potential risk to parity with Vector - The PHP code for the new skin would be different from Vector so there may be a lot of undocumented differences that need to be accounted for, before the skin becomes viable/usable. - Potential lack of parity with extensions/gadgets that rely on the skin's key ('vector') which would not be present on the new skin ### Proposal 5: … ------- ## Recommendation After much deliberation **the Readers Web team is proposing forking Vector and building a new skin** for Wikimedia projects on desktop. Every solution has its pros and cons, but ultimately the ability to build upon an established foundation without the risk of introducing regressions into either the current desktop or mobile experience make forking Vector a practical yet promising baseline for the Desktop Improvements project. The biggest argument against building a new skin may be the shortcomings of the current skin system itself. The responsibility of skins has not been clearly defined in MediaWiki, leading to unclear boundaries between skins and MediaWiki Core and extensions. However, by starting from a Vector fork we will be facing these problems head-on, and by addressing these issues at their core, we hope to make changes that will benefit the wider MediaWiki ecosystem wherever possible.