== Background
See https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading
To enable the distribution of knowledge worldwide, the interface must be easily accessible and readable for all. This includes both the majority as well as individuals with specific needs. As a part of making our interfaces more accessible, we would like to explore allowing users to set their preferred setting for typography and page density.
== Scope
This Goal task will include all work required for introducing a setting for typography for logged-in and logged-out users on the mobile and desktop sites
== User story
As a reader, I want to change my font size to allow for better accessibility
- Logged in
- Logged out
- Desktop
- Mobile
# Sequencing
## Phase 1 - ship to beta
[] The controls are added in a dropdown in the top right of the screen on desktop (logged in users) T350195
[] it's possible to render in the sidebar. T350417 load codex-styles instead of codex-search-styles.
[] It should be possible to pin and persist the user settings menu to the right hand side of the screen,
## Phase 2 - ship to production
Blocked on T289208 and T335317.
[] Implement feature for anonymous users
[] Optimize Codex bundle for all users (Blocked on code splitting from DST)
[] Upstream the Vector client preferences library to MediaWiki core.
[] Render the user settings control in the mobile settings page.
== Background
See https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading. We would like to improve the default typography of the site to improve readability and accessibility for readers and editors.
== Scope
This Goal task will include all work required for improving the default typography of the mobile and desktop sites
== Background
We would like to audit all existing font sizes across the Vector 2022 and Minerva skins. This audit will help us in determining how to apply future typographical changes.
== Pre-work
from {T313828}
## Pre-reading
### How this will impact VisualEditor
T315596#8167345
### Catalogue of font sizes in Vector 2022
Computed font sizes based on the browser default 16px font size. //Starting from the smallest.//
| 11.76px |
| -- | --
| {F35473499} | {F35473504}
|12px| |
|--|--|
| {F35340911} | {F35340926}
| sidebar | footer
| 12.888px | |
|--|--
| {F35342947} | {F35342952}
| sitesub | mw-notify
|13px| |
|--|--|
| {F35340953} | {F35340967}
| Page toolbar | Page toolbar dropdowns
|14px| | | | | |
|--|--|--|--|--|--|
| {F35340985} | {F35340994} | {F35341023} | {F35341034} | {F35341050} | {F35341196}
| Search | Header dropdowns | language button | Table of contents | Sticky header dropdown | content `<H4>`
|16px|
|--|
| {F35341041}
| sticky header language button
#### Larger font sizes
|16.8px|21px| 24px|28.88px|
|--|--|--|--|
| {F35341208} | {F35341235}| {F35341259}| {F35341261}
| content `<H3>` | content `<H2>`| Sticky header page title| content `<H1>`
## Goal
- Define consistent font sizes for UI elements (preferably just two: small and normal)
- Define a consistent typographic scale for wiki content
- Convert font sizes and applicable sizes to rem's instead of em's (T261334).
## Proposal
TBD
This epic will contain tickets related to explorations around dark mode and other palette customizations for desktop and mobile web. The hypothesis is that persistently introducing palette customizations will lead to a significant improvement in the quality of the reading experience across the desktop and mobile web, especially for users with visual impairment and sensitivity (see {T341631})
# Sequencing
The following sequence assumes that as part of font size we have **built the control for user's to modify their preferences** and **instrumentation is in place**. When implementing the dark mode feature flag, the control will appear in the interface and be fully instrumented without any further work.
The following milestones needs to be done in the following sequence to ship a beta feature:
[] Kick off community consultation 1 to get input about content. This will include results of performance analysis of dark mode (T349308). [Szymon and Jon]
[] Add dark mode feature flag/user (client) preference.
[] Add instrumentation to detect article problems in dark mode so that we can assess whether dark mode is "ready" and guide community members on high priority issues to fix (T350030 spike and implementation follow up).
[] Express skin background color and color variables in CSS custom properties
[] Several theming colors are defined in MediaWiki core - make
[] Update key components from other teams to work in dark mode ULS (T340255 ), Codex, Echo [This could involve expressing these in CSS custom properties or could involve applying a temporary solution e.g. invert hack)
[] Close out community consultation 1. Implement content dark mode policy taking into account feedback from community consultation. This may involve additional configuration.
[] Ship to beta features on all projects.
[] Community consultation 2 - identify broken templates and work with editors to fix them.
[] Ship to production.
**Annual Plan Objective**
WE2.1: Ensure a quality reading experience for all users by adapting the default experience for 15% of pageviews, based on the individual needs and constraints of the user.
**Proposed Hypothesis**
Persistently introducing typographic and palette customizations will lead to a significant improvement in the quality of the reading experience across the desktop and mobile web, especially for users with visual impairment and sensitivity.
**This is the parent ticket to track all data analysis and instrumentation related to anonymous user preference persistence.**
---
Potential metrics to track:
# Participation rates of anon users who set and update their preferences.
# Top features users are updating
# Number of users clearing or reseting preferences
---
[[ https://docs.google.com/document/d/1ZkzBtAbKheOO74DSxTIzmSCHeAx_6ys1zIOnCw-40m0/edit#bookmark=id.6wf5f3bef1lj | Additional metrics that we requested support for from #data-engineering
]]
We need to set performance regression alerts for a number of SLOs. We want to detect performance regressions at the time a patch is merged.
**SLOs:**
- Time to First Byte
-- Goal: <= 800ms on average hardware
-- Budget: < Goal on average hardware or the highest time in the last two weeks
- First Contentful Paint:
-- Goal:: <= 1.8 seconds on average hardware
-- Budget: Goal on average hardware or the highest time in the last two weeks
- Largest Contentful Paint:
-- Goal: <= 2.5 seconds on average hardware
-- Budget: < Goal on average hardware or the highest time in the last two weeks
- Total Blocking Time:
-- Goal: < 200ms on average mobile hardware
-- Budget: < Goal on average hardware or the highest time in the last two weeks
- Cumulative Layout Shift:
-- Goal: <= 0.1
-- Budget: < Goal on average hardware or the highest time in the last two weeks
For more context and references please check this document https://docs.google.com/document/d/1sqRMjG8NqF7sLZoiNtcHI09oYAyeVSAx7LHSSCbqUL4/edit#heading=h.q4s6y6l2cibx
**We need to:**
- Define the fault tolerance.
- Capture current number and compare it against the average of past 2 weeks to 2 months.
- Set Gerrit CI steps to flag regressions
- Create Mail alerts for regressions that appears on live deployment as fail safe
In T321746, we implemented the instrumentation required to measure who is using the new "Contribute" menu T286466 implements.
This task involves the work with analyzing who has been using the new "Contribute" menu, and how they've been using it, at the initial set of wikis where it's been made available on mobile (T319362) and desktop (T327868).
=== Decision(s) to be made
//We're answering the "Research questions" documented below in an effort to decide the following...//
- [ ] 1. What – if any – further investigations and/or work needs to be done before we feel confident that offering the new "Contribute" menu at all Wikipedia (T327874) will //not// cause disruption/confusion/etc.?
=== Research questions
|ID|Question|Evaluation metric(s)
|---|---|---
|1.|When people open the "Contribute" menu, do they find what they expect?|
|2.|When people tap on something within the "Contribute" menu, does it do what they expected?|
| 3.| Who is accessing/using the new "Contribute" menu?|
|4.| Are people using this menu to publish edits that wikis value?|
|5.| //[optional] How does the rate at which people complete edits through the "Contribute" menu compare to the rates of other entry points? [i]//|
NOTE: //Draft// evaluation metrics documented here: [Edit Discovery (Minutes) > Proposal: Contribute Menu Deployment ](https://docs.google.com/document/d/1JNpPF2ARLgGArCVw9NyS0BONdHJ50f6w2apwlAWaEew/edit#heading=h.ktdejbvq27bi).
=== Open questions
- [ ] 1. What "Evaluation metric(s)" will we use to answer each of the questions listed in `=== Research questions` above?
=== Findings/Report
=== Done
- [ ] Answers to all "Open questions" are documented
- [ ] All "Evaluation metric(s)" are documented in the `=== Research questions` section above
- [ ] Each of the research questions is answered and documented in the `=== Findings/Report` section above
- [ ] Answer(s) to the `Decision(s) to be made` are documented above
---
i. We will answer question `5.` to the extent that instrumentation that has //already// be implemented enables us to. //Said another way: we will not invest any effort into instrumenting other editing entry points in order to answer this question.//
== Background
In {T301780}, we completed the necessary visual refinements to further deploy the Vector 2022 skin. However, we hope to improve the skin in an ongoing manner. This task contains additional visual refinements that will improve the readability and look and feel of the new experience
## Problem
There is a multitude of different //small// font sizes in the Vector 2022 skin ( a few large ones are inconsistent as well). From a design perspective, this undesirable because it affects the visual hierarchy of the page and adds to ambiguity in the design language.
From a technical perspective, this is undesirable because font-size units are used in other properties such as padding, heights etc, leading to inconsistencies across not just font-size, but spacing in general. This also makes it hard to calculate relative values like em's because of how font-sizes are inherited across elements.
## MVP
**Default and settings/variable font options**
Changes must be applied at the least to:
- Main (article) namespace content area
- Main page
Optional
- Font size variation for navigation
- Font size variation across other content-style pages (Help namespace, Wikipedia namespace, etc)
No change
- Special pages
- History pages
## Pre-reading
### How this will impact VisualEditor
T315596#8167345
### Catalogue of font sizes in Vector 2022
Computed font sizes based on the browser default 16px font size. //Starting from the smallest.//
| 11.76px |
| -- | --
| {F35473499} | {F35473504}
|12px| |
|--|--|
| {F35340911} | {F35340926}
| sidebar | footer
| 12.888px | |
|--|--
| {F35342947} | {F35342952}
| sitesub | mw-notify
|13px| |
|--|--|
| {F35340953} | {F35340967}
| Page toolbar | Page toolbar dropdowns
|14px| | | | | |
|--|--|--|--|--|--|
| {F35340985} | {F35340994} | {F35341023} | {F35341034} | {F35341050} | {F35341196}
| Search | Header dropdowns | language button | Table of contents | Sticky header dropdown | content `<H4>`
|16px|
|--|
| {F35341041}
| sticky header language button
#### Larger font sizes
|16.8px|21px| 24px|28.88px|
|--|--|--|--|
| {F35341208} | {F35341235}| {F35341259}| {F35341261}
| content `<H3>` | content `<H2>`| Sticky header page title| content `<H1>`
## Goal
- Define consistent font sizes for UI elements (preferably just two: small and normal)
- Define a consistent typographic scale for wiki content
- Convert font sizes and applicable sizes to rem's instead of em's (T261334).
## Proposal
TBD
**List of steps to reproduce** (step by step, including full links if applicable):
* Visit any page with SITEBANNER (https://eu.wikipedia.org/wiki/Txikipedia:Munduko_zazpi_mirariak or https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Lehiaketak/2022/04 will work)
* Navigate to the bottom, till the sticky header shows
*
**What happens?**: Two different results: at Txikipedia namespace the sticky header simply doesn't show. At portal namespace the search button appears but the title is absent.
**What should have happened instead?**: it should have the same behaviour.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
== Background
{T293946} will make it so people who are logged out visiting English Wikipedia on a mobile device will see a link to talk pages on the articles they're viewing.
This task is about identifying what metrics we would like to calculate in order to evaluate the impacts said change is having on talk pages and the people who depend on them.
== Metrics definition
[x] Review metrics and research questions proposed in https://docs.google.com/spreadsheets/d/1wCI5SxwlTt0GTFzCW3H3wMFx_-FiTtBuW4WlNbQU9_M/edit?usp=chrome_omnibox&ouid=111587476130020861920 and identify the following:
* are we currently instrumenting this
* does the current instrumentation allow for the following dimensions:
** logged-in status
** namespace
** (nice to have) page
[x] Use the above to begin draft of instrumentation spec
== Questions we want to answer
- How does this change affect the amount of vandalism and other non-relevant content on talk pages?
- How does this change affect the communication between anonymous and logged-in editors?
-- Does this change affect the overall number of IP editors blocked from editing?
-- Does this change affect the number of unreverted edits made by IP editors (split by namespace)?
- Does exposing readers to talk pages decrease their overall trust in Wikipedia?
- Do readers understand the purpose of the talk page and how to interact with it?
-- Do they spend any substantial amount of time on talk pages (definition of substantial TBD)?
-- Do they leave the site entirely after visiting the talk page?
**From initial description:**
//This section will contain the metrics we would like to calculate and what – if any – new instrumentation would need to be implemented to do so.//
|ID|Metric|New Instrumentation Required (Y/N)|Notes
|---|---|---|---
== Done
[[ https://docs.google.com/spreadsheets/d/11o7ZBtFff2Bi2L0kD-qC1c4XS82QqVs8fjcms824aO0/edit?usp=sharing | Web team Instrumentation Spec ]]
== Background
This epic will contain the last stages of the desktop improvements project, focused on visual and functional cohesion and clearing out technical debt.
== Developer / technical debt payoff checklist
[] Have use of skinStyles inside Vector being minimized? Ideally styles should live in the extensions that introduce them rather than localized to Vector. During development of desktop improvements we may have added some to Vector to make sure of local variables or closely couple ourselves to classes introduced by feature flags.
[] Did we address all FIXMES?
[] Did we remove all temporary feature flags and their corresponding CSS?
[] Is the critical path of CSS as small as it can be. Are there any simplifications that can be made at the end of the project?
The MobileFrontend codebase is not well understood even by its maintainers. Following on the work from the [[ https://m.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture#Review_and_refactor_components | mobilefrontend investment project ]] we should aim to gradually port the code inside MobileFrontend to Vue.js and eventually the #wvui library.
I suggest this work begins by making use of the search widget built for the #desktop_improvements project and removing the existing SearchOverlay.
This is a placeholder, and an epic, so we should look to pull out subtasks as and when we have time to schedule this work.
The [[ https://www.mediawiki.org/wiki/Extension:Popups | popup extensions ]] contains [[ https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/ui/renderer.js$151-158 | different popup types ]]. Some elements (like the settings icon) are used (or could be used) in more than one type.
All shared elements should also be shared in the code and not copy pasted (like currently in T234205).
Advantages: simplified maintenance, easy reuse of elements and addition of new types
Current types: reference preview, page preview, disambiguation, empty
{F34112417}
Elements (all optional):
* header: icon & title
* content: text & image
* footer: text/link & cogwheel
##Possible implementations
# Extend existing function `renderPreview()` to include needed options like cogwheel and title icon.
# Create structure of the popup in html and fill data with shared js functions. Example in html and pseudocode:
``` lang=html
<title>
<img class="icon"></img
</title>
<div class="content"></div>
<footer>
<div class="settings"></div>
</footer>
```
``` lang=php
...
if($(.settings)) addSettingsCogwheel()
...
```
Scrolling doesn't work as expected in mobile. Due to several issues here, we likely want to rethink how it works.
# Issue 1: Mobile: Section links jump to wrong spot when a section is open
I happened to notice that the section links in the Safari mobile view navigated to a seemingly random place within the article if the page had already been loaded and one or more preceding sections had previously been opened. In the preceding case, trying the "Australia" links immediately after the "sight vocabulary" links caused this behavior (e.g., by clicking on one of the "sight vocabulary" links, then clicking the "back" button twice [once to return to the top of the page and once to go back to the sandbox] and then immediately clicking on one of the Australia links). I'm wondering if may be because the section's physical location is being calculated assuming that all sections are collapsed. Once I collapsed all above sections and tried again, the section link sent me to the correct place.
# Issue 2
From OTRS
//Ticket: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=10866024 //
> Hello,
>
> I have a technical question concerning the mobile version of Wikipedia, using the Chrome browser for Android Oreo: when I click on a hyperlink on a Wikipedia page to go on a new page (that opens in the same browser window), and then use the back button of the phone (lower right), I often don't get back to the same location of the Wikipedia page where the hyperlink is located, but higher up or lower down on the page. Why is this? Is there a remedy for this?
>
> Many thanks for your help,
> Max
>
> Chrome for Android ... hyperlink and then go back don't get back to the exact location of the hyperlink but higher up in the page ...
>
>
>
= Replication steps
This one seems easy to replicate in an emulated Chrome window or Android
* Visit https://en.m.wikipedia.org/wiki/Ozone_layer?oldid=871775124
* Expand section "Depletion"
* Scroll to "Regulation" and click "Hydrochlorofluorocarbon"
* Click back button
* Expect: To see the link "Hydrochlorofluorocarbon"
* Actual: No sign of the link "Hydrochlorofluorocarbon"
= Developer notes
This doesn't appear to be related to any tinkering with window.scrollTop but is to do with the fact that sections are collapsed by default. In fact if I disable JS this works just as expected.
The method expandStoredSections inside Toggler ensures that the section that contains the link is opened, but it opens after the browser has restored the scroll position of the page.
The only way to solve this and retain the toggle behaviour would be to capture the scroll position on every link click and ensure that expandStoredSection restores the scroll position.
There is a good opportunity here to refactor Toggler to not have the responsibility of scroll position. This code should live in Minerva as Minerva should be responsible for the scroll position at all times.
The mobile share-a-fact feature linked [[ https://www.mediawiki.org/wiki/Wikimedia_Apps/Share_a_fact | here ]] is very elegant and useful. I believe this functionality would translate well to the desktop as well.
When browsing a Wikipedia article in a browser like Firefox or Chrome, a sidebar button for "Sharing" can allow a user to download a pre-made image card for sharing.
When a user selects text, the pre-made card may be replaced by the selected text.
User Story -
"As a user, I open a Wikipedia article in any browser and want to share either the entire article or some snippet of the same with a friend, or post it to social media. Instead of simply sharing the URL, I click a link on the page, which produces a custom image card similar to the one I get from the wikipedia apps. This card is easily sharable and helpful and clearly states that the source of my content is wikipedia."
Browser -
Firefox, Chrome
Platform -
Web
Page previews have demonstrated great success on Wikipedia where it is loved by many. It may not work perfectly for _all_ projects but the fantastic impact on Wikipedia and the expectation that it kind-of sort-of works most places makes it an excellent candidate for at least a beta feature. For example, on the Commons and Wiktionary projects. This stub task tracks the discussion to enable both page and reference previews as a beta feature on all projects where it's not already in production.
Related: T111231, T203981, T222017 (and probably others!)
==== Background
Google Chrome is changing the way it shares user-agents for increased privacy of users. You can read more about it here: https://www.chromestatus.com/feature/5704553745874944
Google Chrome has released [[https://wicg.github.io/ua-client-hints/|Client Hints]] to provide device information. This first release “is intended to allow for developers to experiment and provide feedback”: https://groups.google.com/a/chromium.org/g/blink-dev/c/-2JIRNMWJ7s/m/u-YzXjZ8BAAJ
==== Technical practicalities
**How it works (simple overview)**
* A user sends a request to our site via their browser (e.g. “show me an article”)
* Our server sends a response that includes the article and a header that asks the browser to send some user data on the next request
* If the user makes subsequent requests (e.g. “show me another article” or “show me the editor so I can edit this article”) they will also include this user data
**Differences from receiving the user agent string**
* The site asks explicitly for the information, meaning that this can be flagged up to the user
* The site specifies which information it needs, out of [[ https://wicg.github.io/ua-client-hints/#http-ua-hints | this list ]]
* Browsers may legitimately decline to send the information (e.g. if considered [[ https://wicg.github.io/ua-client-hints/#access | unnecessary ]] or if the site is asking for [[ https://github.com/bslassey/privacy-budget | too much ]])
* If the user only ever sends one request, we will not receive any extra data
==== [Rollout plan](https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html)
Client hints is an experimental feature on Chrome 84, meaning that the browser will only send client hint data if the user has enabled Experimental Web Platform features (disabled by default).
| Google Chrome Stable Version | Stable promotion | What happens then? |
|----|----|----|
|Chrome 84| July 14, 2020| [[ https://www.chromestatus.com/feature/5995832180473856 | Sec-CH-UA Client Hints ]]
|Chrome 92| October 6, 2020|Audit site to understand where migration may be necessary|
|Chrome 95| October 19, 2020|[Origin trial](https://developer.chrome.com/blog/user-agent-reduction-origin-trial/) to experiment with Client Hints and provide feedback|
|Chrome 100|March 29, 2022|Deprecation trial (opt-in)|
|Chrome 101|April 26, 2022|Reduced Chrome version number rollout|
|Chrome 107|October 25, 2022|Reduced Desktop User-agent string rollout|
|Chrome 110|Feb 7, 2023|Reduced Mobile User-agent string rollout|
|Chrome 115|May 2, 2023|Deprecation trial ends. Everyone receives reduced user-agents|
[Chrome versions release schedule](https://chromiumdash.appspot.com/schedule)
==== Implications on CheckUser
User-agent strings are important pieces of information for checkusers and stewards in their work of detecting and blocking sock accounts. To continue to get that important data, we should implement support for client-hints on our end.
Even with client hints, the fingerprinting data may become unavailable to CheckUser in ways beyond our control (see **Differences from receiving the user agent string**). This should be discussed with checkusers.
==== Implications on privacy awareness
By actively asking for data, we expose Wikimedia to scrutiny over when/why we're asking for it. Anti-vandalism is an important reason. The vast majority of requests to our site don't result in making changes stored in CheckUser.
Fingerprinting for fighting vandalism is considered a legitimate but unfortunate use case, and may not always be supported in the future: https://github.com/WICG/ua-client-hints#fingerprinting
==== Investigations
* {T258591}
* {T258592}
==== Further reading
* https://github.com/WICG/ua-client-hints
* https://web.dev/user-agent-client-hints/
* https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
* https://developer.chrome.com/origintrials/#/view_trial/-7123568710593282047
* https://blog.chromium.org/2021/05/update-on-user-agent-string-reduction.html
* https://www.chromium.org/updates/ua-reduction
NOTE: none of the things listed here are critical issues
= Acceptance criteria
[] All subtasks are closed
= Fixed (please confirm) ?
# Issue 1
**Namespaces and Tags buttons are taking up full lines**
Previously the Namespaces and Tags were sitting side-by-side, but currently they are each taking up their own line
| current | desired
| {F30046553} | {F30046551}
This appears to be fixed on the beta cluster:
{F30069293}
[x] Confirmed by Jon Robson
[] Confirmed by Alex
# Issue 2
[] **Filter menu list items are top aligned**
Just looks off
| {F30046535} | {F30046534} | {F30046533}
@jdlrobson: I cannot replicate this.. this is what I see:
{F30069537}
Progress is measured here: [[ https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture/Progress?useskin=vector#Removing_inheritance | mediawiki.org ]]
This begins our refactoring effort and aims to minimise the use of inheritance in MobileFrontend. We will reduce components to classes that extend the View class to minimise confusion in navigating through files to understand how the inheritance change impacts our component.
Per T206036#4832740 (MFA: [Spike, 8hrs] Views: You Gotta Keep 'em Separated) and similar discussions in T209647 our main focus will be the Overlay's. We will limit efforts to separating the content of overlays from the overlay itself.
= How?
We can replace many of our classes with factory functions that create Overlays and append child components via jQuery.
The LoadingOverlay probably provides the most simple to explain example: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/468187/14/src/mobile.startup/loadingOverlay.js
We will look to generate many of our View's in this way, resorting to using existing components with different options (think React-like props). Where needed, we will add functionality/flexibility to View and Overlay classes to generalise different component needs - for example in the LoadingOverlay example a will described property `noHeader` was added.
= Outcomes
The outcomes of this epic will be:
- More granularity in our components and more reuse
- The DRYing up of many template and template partials
- Easier to read code.
- The ability to remove the LoadingOverlay - instead, Overlay factories will be able to limit the spinner/async loader indicator to the Overlay content
- We have documented a best practice for how to make new overlay's / components going forward
= When is it done?
This EPIC can be resolved when the following classes either do not exist (replaced with factory functions or removed)
1) Documentation on how to make View's has been written
2) The following query should return 0 results in Minerva and MobileFrontend.
> ag "extends Overlay"
> ag "extends Drawer"
> ag "extends Icon"
> ag "extends PageList"
## Icons
[x] DownloadIcon extends Icon -> is Icon (https://gerrit.wikimedia.org/r/472371)
[x] ShareIcon extends Icon -> is Icon (T205592)
## Drawers and Panels
[x] BetaOptinPanel extends Panel -> extends View T217298
[x] BlockMessage extends Drawer -> is Drawer
[x] Drawer extends Panel -> is View
[x] CtaDrawer extends Drawer -> is Drawer (red links + watchstar when anon!)
[x] ReferencesDrawer extends Drawer -> is Drawer (T217295)
## Categories
[x] CategoryAddOverlay extends Overlay -> is Overlay (T246049)
[x] CategoryOverlay extends Overlay -> is Overlay (https://gerrit.wikimedia.org/r/469145)
## MediaViewer
[x] ImageOverlay extends Overlay -> is Overlay (T216198)
## Languages
[x] LanguageOverlay extends Overlay -> is Overlay
## Notifications
[x] NotificationsFilterOverlay extends Overlay -> is Overlay (T217296)
[x] NotificationsOverlay extends Overlay -> is Overlay (T217296)
## Page issues
[x] PageIssuesOverlay extends Overlay -> is Overlay (https://gerrit.wikimedia.org/r/475576)
## Talk
[x] TalkOverlay extends Overlay (T215370)
[x] TalkSectionAddOverlay extends Overlay (T217102, T278590)
[x] TalkSectionOverlay extends Overlay (T217810, T278590)
## Page lists
[] SearchOverlay extends Overlay
[] WatchstarPageList extends PageList -> is PageList
[x] Nearby extends WatchstarPageList extends PageList (T217814)
[] WatchList extends WatchstarPageList extends PageList -> is PageList
## Editor
[] AbuseFilterOverlay extends Overlay -> is Overlay
[] VisualEditorOverlay extends EditorOverlayBase extends Overlay -> is Overlay
[] EditorOverlayBase extends Overlay -> devnull
[] EditorOverlay extends EditorOverlayBase -> is Overlay
## Misc
[x] LoadingOverlay extends Overlay (https://gerrit.wikimedia.org/r/468187)
[] Remove the loadingOverlay factory function (replaced by promisedView pattern)
= What happens after this epic?
We'll review the newly created components and with a spike evaluate how we can break them down further.
As part of this we may decide to target one specific overlay and refactor until completion to show/prove to ourselves this will result in more manageable and testable code.
= Do we write new tests?
This will be decided by the team as and when we work on this. We'll talk about our commitment to code coverage and how it will change during this refactor.
= What will code look like in future?
All Overlay's will be Overlay's with widgets inside them
e.g.
```
var overlay = new Overlay( {
title: 'Editing Spain article'
} );
overlay.append(
new EditorSurface()
);
```
Talk:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/471334/7/src/mobile.talk.overlays/talkOverlay.js
= Sign off steps
[] Take a look at T214641 and determine whether the issue has been solved. If not adjust/rewrite
== Background
Currently page previews are not available in wiktionary. We would like to account for page previews within wiktionary by providing the primary definition from the wiktionary entry.
== Acceptance Criteria
Previews on wiktionary must contain the following:
- wiktionary definition (if available)
-- for pages that do not contain a definition, the generic card must not display
-- Image (if available) - we can still have the default to "any" image
-- If a page has no description and no image, the generic card will display
- Descriptions will be on by default for all logged-in and logged-out users
- Logged-in users may turn off descriptions within their user preferences
Mobile readers ~~now see~~ previously saw a Wikidata description when searching the English Wikipedia (T152743). Concern (https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Hard_to_detect_mobile_vandalism) has been raised that it is hard for editors to know if this description has been vandalised (potentially introducing serious - libellous - errors); on desktop Wikipedia the wikidata descriptions can only be seen by manually clicking through to the Wikidata item.
== Possible solutions
=== Wikidata descriptions in desktop
One solution might be to show the Wikidata description at the top of articles, under the title, to logged in editors, with an Edit button to quickly take them to Wikidata to fix any errors (which was explained in more detail in T141230).
**Pros:**
* Editors are on desktop
**Cons:**
?
=== Providing editing experience on mobile
**Stage 1**
Let editors know where they can edit the description
{F4354480}
{F7060802}
**Stage 2**
Let editors edit the description on mobilefrontend
{F7060806}
For more info please check the [[https://www.mediawiki.org/wiki/User:Melamrawy_(WMF)/WikidataDesc | draft ]]. I didn't list this as a blocking task, the ticket is to triage, asses complexity and dev time required.
**Pros:**
* There is an easy path to editing from mobile
**Cons:**
* Most of our editors are not on mobile
* Could actually increase vandalism by making editing easier
=== Wikidata edits in Wikipedia watchlist
Another would be to show relevant Wikidata edits in the Watchlist. I notice I have a "Wikidata" checkbox there, but editing a Wikidata description doesn't show up on the watchlist even if it's checked.
**Cons:**
* Complex problem. Part of a bigger problem which is showing foreign project edits in your home project watchlist.
A few comments on the Talk page for Page Previews (Hovercards as it is known in beta) have suggested user-customizable options for the display of the previews.
* Allow users to adjust the length of text presented in a preview ([[ https://www.mediawiki.org/wiki/Topic:Tmo93beg3e1rpuiq | discussion ]])
* Allow users to omit images from appearing T148995
** Another suggestion is allowing users to define the size of the image
* Show metadata in previews ([[ https://www.mediawiki.org/wiki/Topic:Tg8m178nj6doq7k3 | discussion ]])
==Background==
[mediawiki-extensions-Popups](https://github.com/wikimedia/mediawiki-extensions-Popups/) currently uses a compilation step (`npm run build`) to pull together front-end assets and process them before pointing ResourceLoader at them for serving.
Currently...
* Compiled front-end assets are generated by developers and added to the git source tree under [`resources/dist`](https://github.com/wikimedia/mediawiki-extensions-Popups/tree/master/resources/dist) on every patch that touches front-end sources.
* We [run a script](https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/package.json#L8) on the npm job that verifies that the compiled assets are up to date, and bails if they weren't properly committed.
This allows us to:
* Keep master updated with the deploy assets
* Ensure that latest sources will have the latest deploy assets on master (with the CI step)
==Cons==
=== Rebase hell
Because of how it is set up, every pending patch on gerrit that touches the frontend assets, needs to be rebased every time master is updated, to get rid of the merge conflict and regenerate the compiled assets on top of it.
This can get very annoying for pending changes as any change merged will force a rebase on all pending changes.
It's so annoying we made a bot to do this for us (see T167181 Create bot that automatically rebases and rebuilds patches to master)
Example:
1. There are changes A, B and C posted on gerrit based off master. They touch front-end assets and as such generate assets into `resources/dist` with `npm run build`
2. Reviewer goes and +2s patch A.
3. Goes to review B, wants to +2, but because A is merged to master and changed the `resources/dist` files, B now //Cannot merge//.
* B and C now need to be rebased on top of master, run the build step, and re-submitted with updated compiled assets.
=== Cannot configure per wiki
When working on T173491 it was raised that because $wgScriptPath is configurable map files compiled from this process cannot be changed on a per wiki basis. A formal build step could potentially allow us to build on deploy and thus provide debugging on these wikis
==What do we need==
To not submit compiled assets with the patches, but keep the deploy branch (master currently) updated with the compiled assets.
==Solutions considered==
1. **Keep doing what we are doing**
* Pros: Works, nothing to change
* Cons: Pretty painful if there is churn in the repo because of the merge conflicts
2. **Don't submit the compiled assets on every patch**
* Manually build and release to the master branch
* Pros
* No merge conflicts because of stale compiled assets
* Control over the front-end source releases
* Cons
* Backend and front-end source could be out of sync on a release if assets not compiled appropriately
* Front-end not auto updated in staging and beta cluster environments
* Manual step, bound to fail because humans
3. **Make CI run the build step and merge compiled assets**
* With the pros of what we are doing currently, but without the cons
* Pros
* Simpler workflow compared to the current one as there's no need to remember to add the compiled assets to the change.
* Keeps master updated with the deploy assets
* Ensure that latest sources will have the latest deploy assets on deploy branch (master)
* Cons
* Needs work with RelEng team to help us automate this
* Seems to be a dirty solution, having a separate deploy branch/repo seems to be preferred
* There are jobs that need change to learn how to build assets, like the selenium jobs, otherwise their results will be moot
---
Ideally after chatting, option **3. Make CI run the build step and merge compiled assets** would be our preferred choice if RelEng deems it feasible and not problematic. We had an initial chat with @hashar about different ways this could be accomplished.
==Questions==
* Is this feasible? (amount of work to get it set up)
* How often do we run the job/script to generate assets and merge to the deploy branch (master)? (hourly? daily? after each commit?)
* Other repositories under wmf keep the deployable version of the project under a `project/deploy` branch. Is it worth it to have a separate deploy branch and sync it/submit compiled assets there? (Given this is a mediawiki extension) Or is it better to keep master as the deployable branch and push the assets there?
* Is this a good chance to define a general CI process to trigger a build step on projects? (for bundling frontend assets, pre-compiling templates, optimizing static assets like images, etc)
== Background
When there are long pages, it takes a longer time to get back to the top. ~~A circular button in the bottom right corner with the label "Top" would be good, which could appear a few seconds after scrolling away from the top.~~ The [[ https://en.m.wikipedia.org/wiki/Special:MobileOptions | mobile beta site ]] solves this by showing a fixed position button in the bottom right corner.
~~The size is important, where it should be big enough that it could be pressable (48x48 is the suggestion by the [[https://material.google.com/components/buttons.html#buttons-style|Material Design Google Specs]], and 44x44 by the old Apple iOS Human Interface Guidelines, but can't seem to find that anymore), but not too big that it could be accidentally pressed by accident (this defeats the purpose of the button by making it harder to scroll through pages). ~~
We should work out what to do with this feature.
== Current status
After a round of user testing of a number of different designs {T193772}, we have decided to go forward with promoting the sticky header prototype for in-article navigation
== Design & prototype
https://in-article-navigation.firebaseapp.com/sticky-headers.html
== Timeline
1. Build and test sticky headers (Q1 2018)
2. Deploy to beta (remove back to top button) (Q1 2018)
3. Build instrumentation and test feature (Q1-Q2 2018)
4. Discuss changes with communities (Q1-Q2 2018)
5. Promote out of beta (Q2-Q3 2018)
[This is a placeholder card]
After the success of https://blog.wikimedia.org/2016/09/19/mobile-web-improvements/ we should explore making the same changes in core (feature flagged of course) as the savings to be had are equally big (if not larger - there is an opportunity to save the cost of running Wikipedia if the bytes savings are significant).
Most of the code can easily be upstreamed with the exception of the MobileFormatter logic which would now be able to run in the parser.
Blocked on upstreams:
* Chromium: <https://bugs.chromium.org/p/chromium/issues/detail?id=875403>
* WebKit: <https://bugs.webkit.org/show_bug.cgi?id=224547>
The `MobileContext` and `MobileFrontendHooks` classes are fundamental to how MobileFrontend works but they do a lot of things, which makes them expensive to exercise and to maintain. By breaking these classes apart and testing those parts in isolation with a comprehensive suite of unit tests, we can reduce this cost and make changes with increased confidence.
==Why are they expensive to exercise and maintain?
Both classes access and manipulate global state, which make them hard to isolate and, consequently, unit test. Instead, we test these classes via integration and acceptance tests, automating a UA browsing a running instance of MediaWiki, which are sluggish and, in my experience, flaky. Moreover, we don't run our entire suite of acceptance tests against each commit and I'd be willing to bet that our acceptance tests don't all of the above.
==What will this cost?
I expect that the many steps of this migration will be hard to review and validate. Designing our code so that it can be unit tested will require increased discipline while making changes (and reviewing changes!). We'll have to get better at communicating and critiquing our designs. If I'm correct and there are methods of these classes that aren't covered by our acceptance tests, then there'll likely be regressions. We'll have to be disciplined in making changes small enough to balance minimising risk and maximising feedback so that we can move forward.
An often unexpected side effect of rigorously breaking apart a large object into a system of increasingly smaller objects is that, unlike a 20 line function in `$yourFavouriteImperativeLanguage`, it's hard to immediately see how those objects interact. High-level documentation, small interfaces, and unit tests help with this.
---
==TODONE
[x] Introduce MediaWikiServices to MobileFrontend (819064d)
[] Add coverage coverage to split out functions
[] Replace all MobileContext::singleton() in the code base to the MobileFrontend.Context service
[] Per 95629c2, MobileContext::singleton() was moved to a MobileFrontend MW service (MobileFrontend.Context), we want to break this class into small services
==Nebulous thoughts that may eventually become sub-tasks (read: TODO)
* Extract:
[] the `MobileFrontendRequest` object
[] Discuss action/controller terminology with the team (@Jhernandez)
…
= Problem
The MobileFrontend extension currently tries to mimic the watchlist in core but fails due to the fact the special watchlist class mixes rendering with model generation. Ideally it should be possible to skin the data by creating this separation.
Recreating the watchlist for mobile is very wasteful.
It causes additional work for other teams (see T159793).
The Watchlist special page also handles various user preferences which are currently overlooked by the mobile version.
== Differences between mobile and desktop skinning
{F8635058}
{F8635060}
As you can be seen the positions of elements are extremely different. Touch areas are different. It's impossible to use the same HTML for both designs without a fundamental change to the design.
== Solution 1
Use api.
Construct an ApiMain with a derived RequestContext
Hit the API to source the data for rendering.
Being driven by the API would also help resolve T111074 and T70368
Note: Use of FauxRequest seems to be frowned upon... see T169266
== Solution 2
We do the separation in [[ https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialWatchlist.php#L405 | SpecialWatchlist ]]. There should be a simple method render which is passed data or a model and renders it.
Make use of [[ https://github.com/wikimedia/mediawiki/blob/master/includes/WatchedItemQueryService.php | WatchedItemQueryService.php ]]
Tangential:
It would be useful if SpecialWatchlist::outputChangesList in core was refactored to use this. It would make skinning a lot easier....
= acceptance criteria
The following user preferences should be honoured
[] Mobile watchlist should follow the same Show/Hide preferences as the desktop watchlist (see T69799 for more details)
[] Mobile Watchlist does not take into account preference value of expand/aggregation into account (see T70367)
[] Hide bot edits from the watch list not taken into account (see T70365)
[] No logic for unseen notifications
[] Pagination should be mor (was T111074)
= todo
[] add screenshots showing desktop watchlist skinned in Minerva and mobile watchlist
[] suggest architecture diagram
[] tag with mediawiki core team
[] rfc?
Responsive Vector is now on test.wikipedia.org and all mobile domains when using the Vector skin
e.g. https://test.m.wikipedia.org/wiki/Main_Page?useskinversion=2&useskin=vector
The Responsive Vector configuration flag does 2 things:
1) enables a viewport
2) disables the min-widt
It can be disabled by user preference
This however exposes many underlying problems..
# challenges
* Many special pages are not responsive. MobileFrontend/Minerva have solved many of these but in some cases, only in the context of the Minerva skin. These fixes would need to be upstreamed.
* Many main pages of projects are not responsive.
# Suggested steps
- [] new Vector should always set the responsive flag
- [ ] fix the bugs
- [ ] change the default behavior
{F204715}
{F204721}
# Eternally stalled. Would need input from the SRE Infrastructure, Traffic, and Observability teams, the Web team, the Performance team, and others.
{T69703} suggests that we change the default wiki thumbnail size to 300px width, based on user settings data, for all Wikimedia wikis as well as for the MediaWiki software itself. Copying here for that part of the change.
Desktop and mobile use different implementations for displaying a lightbox when images are clicked.
There is lots of user value e.g. performance/functionality to consolidating these two experiences.
# Pros of desktop version compared to mobile
- Has support for 3d images
# Cons of desktop version compare
- ~100KB of code (minified, decompressed). Mobile uses ~5KB
# Cons of both
- Desktop built in OOUI library (rather than Codex)
- Mobile uses non-standard MobileFrontend library (rather than Codex)
# Benefits of consolidating the two experiences
[] One less unmaintained extension in our deployed servers
[] More functionality to mobile users
[] better frontend performance for desktop users
Currently, screen reader users who navigate by headings constantly hear the word "edit" at the end of each heading because section edit links are part of the <h#> elements. It should be changed so that the <h#> elements contain only the heading text, with the section edit links separated out.
This was originally a bug for the link coming before the heading text, which has since been changed. The original description is preserved below:
**Author:** `rene.kijewski`
**Description:**
Proposed change
For users of screenreaders (and textbrowsers) it takes quite long to walk throught the headlines. At every single headline they hear "[edit]" first instead of the real section title. This could easily be changed by let the edit-section-link come second in the rendered page and let the section title come first. There would not even be visual changes for seeing users and users of graphical browsers.
=== Done
- [ ] Editing Team to draft announcement for Tech/News that includes link to documentation explaining:
-- Reason for change
-- Change
-- Instructions for how to cope with change
-- Who is likely to be impacted by change