Page MenuHomePhabricator
Search Advanced Search
    • Task
    **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.**:
    • Task
    == Background We would like to A/B test the completed table of contents feature to identify whether it increases usage and reduces the need to scroll to the top of the page == Notes This ticket will track all blockers for the ToC A/B test
    • Task
    === Description The final stage of the project will be visual design and small layout/spacing refinements. ====== Goals 1) use visual design to further our general project goals (e.g. welcoming experience, content primary, simple/clear/accessible, distinctively Wikipedia) 2) review all the various states of the interface at various screen sizes and make any final decisions that we previously deferred ====== Constraints - We are not changing structural elements of the interface - We are keeping with the legacy of form following function... a visually simple/restrained/minimal interface - We are not creating a radically different look (i.e. should feel evolutionary, not revolutionary) - We are keeping in mind the potential upcoming navigation restructuring work and making sure that whatever we do at this stage sets us up for that ====== Starting point The starting point for this work is the current, minimally styled version of Vector 2022: {F35056918 width=750}
    • Task
    == 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 ]]
    • Task
    == 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?
    • Task
    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.
    • Task
    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() ... ```
    • Task
    === Background A main goal of the Desktop Improvements project is to make frequently used tools more accessible to readers and editors. One of the most crucial of these tools is the table of contents (ToC), which is responsible for providing both contextual insight and navigation. Currently, the ToC is only available at the top of the page, limiting its usefulness. We plan to make it a persistent element, available throughout the page. Our goal is to make it easier for readers and editors to reach the ToC, gain context, and navigate throughout the page without needing to scroll all the way to the top. == Sign off steps When signing off please make sure [] That the styles for the old table of contents are no longer being shipped in production. In particular ResourceLoaderSkinModule should set the toc feature to false (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/753545/4/skin.json) [] A/B test code has been removed. ==== Use Cases As a reader or editor, I want the ability to gain context (content and structure) about the page I am about to read As a reader or editor, I want the ability to reference the next few sections in the page at any location in the page so that I can choose what to read next As a reader or editor, I want the ability know how many sections a page has without having to scroll all the way up ==== Feature description and requirements The table of contents will appear persistently on one side of the page. This table of contents will contain all sections and sub-sections available in previous versions of the ToC. The ToC will contain the following functionality: - Collapsible sub-sections - for users that only want to view the highest level of section heading - Section bolding - the section currently on the page will be displayed as bold. Users will be able to identify where on the page they are currently located by noting the bolding within the ToC - Navigation - selecting a section within the table of contents will navigate to the appropriate section within the page - For screen widths smaller than 1000px, the ToC will collapse and the section titles will be used as a ToC ==== Mediawiki Page https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Table_of_contents === Previous Research Based on the research we conducted ([[ https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Sticky_Header_and_Table_of_Contents_User_Testing | link to research ]]) we plan to implement a persistent table of contents on Article pages (and possibly other namespaces in the future). === Latest prototypes Tall/collapsed ToC: https://di-article-tools-da959.web.app/Humpback_whale Short/expanded ToC: https://di-article-tools-da959.web.app/Cetacean_surfacing_behaviour
    • Task
    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.
    • Task
    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
    • Task
    Once NearbyPages is ready and deployed, MobileFrontend will no longer provide Special:Nearby [[ https://gerrit.wikimedia.org/r/575568 | thanks to this patch ]]. Let's deploy to a single wiki, test extensively and then drop Nearby from MobileFrontend. = Acceptance criteria [x] Team review of NearbyPages Extension (T271251) [x] Security review has occurred (T269291) [X] Enable NearbyPages on beta cluster [[ https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page | beta cluster ]] [x] Check in with Performance team about review prior to production deployment [x] verify wikidata version on wikidata beta cluster [] Fix blocking bugs (see subtasks) [] Migrate to codex [] Enable NearbyPages on test wiki e.g. [[ https://ca.wikipedia.org/wiki/Especial:A_prop | Catalan Wikipedia ]] [] Test NearbyPages is working as expected [] Enable NearbyPages everywhere. [] Remove MobileFrontend code and bump version number. T246494
    • Task
    == Description We'll need new logos for the header that include: - project logo (puzzle globe, etc) - wikipedia - tagline (the free encyclopedia, etc) This epic will include all tasks related to logo creation and documentation. == Open Questions: - three logos for individual pieces or one svg with everything? - can we use mobile logo for the text and add the globe and tagline around it? - are there other complications we have not yet discussed? - can we use a script or should we manually create all of the logos - What happens when logo is undefined in custom MW & Vector 2020 installation == Checklist - complete when all ticked [ ] A decision is made around whether a dashboard would be useful for remaining logos (T252710) == wordmarks [] T142426: All wikipedia's have language wordmarks and these have been deployed [] Add wordmark for incubator {F34148078} == project logo icons [] many of our logos are "pngs". Do we want to Vectorize them (originally T54019) [] Update the projects in the table with the correct icons. | project | expected icon | actual icon | URL | -- | -- | -- | -- | wikitech | {F34148079} | {F34095571} | https://en.wikipedia.org/static/images/project-logos/wikitech.png | meta |{F34148086} | {F34095817} | https://en.wikipedia.org/static/images/project-logos/metawiki.png, https://upload.wikimedia.org/wikipedia/commons/thumb/7/75/Wikimedia_Community_Logo.svg/1920px-Wikimedia_Community_Logo.svg.png | wikimania | {F34148083} | {F34095814} | https://en.wikipedia.org/static/images/project-logos/wikimaniawiki.png | test wiki | {F34184104} | {F34183162} | https://en.wikipedia.org/static/images/project-logos/testwiki.png == taglines - [] T252850 - font-size revisited for Chinese == Next set of logos to update [] Wordmark for incubator: {F34148078} [] ptwikinews [] frwikiquote [] Morroccan Arabic Wikipedia [] We will optimize all logos by running them through svgo. == post deploy [] When all logos have been built make sure all of them have been optimized via svgo (per T276279)
    • Task
    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!)
    • Task
    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}
    • Task
    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) [] TalkSectionAddOverlay extends Overlay (T217102, T278590) [] 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
    • Task
    == 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
    • Task
    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.
    • Task
    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 ]])
    • Task
    ==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)
    • Task
    == 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)
    • Task
    [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. (NOTE) Blocked on upstream Chromium: <https://bugs.chromium.org/p/chromium/issues/detail?id=875403>
    • Task
    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 ==Nebulous thoughts that may eventually become sub-tasks (read: TODO) * Extract: [] the `MobileFrontendRequest` object [] Discuss action/controller terminology with the team (@Jhernandez) …
    • Task
    = 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?
    • Task
    **GOAL** Offer a satisfying user-interface experience to as many people as possible. We have been striving for a one-size-fits-all interface. In contrast this solution offers users with very common disabilities and impairments, which we know the current interface doesn't offer best experience, an easy way to adapt the interface to their needs and to serve them the best we could. **What to offer** We’re talking about flexibility in changing basic settings (still to //clarify needs, define and test//) like - font size, - day/night modes, - photophobia, - grayscale, - … **For whom** For all readers including not-logged-in ones. [[ https://phabricator.wikimedia.org/T72879#750208 | Technical limitation ]] to support it for every user is, that it has to be implemented client-side in JavaScript to avoid cache fragmentation. **Where and how** Some early mockups: | {M17} | {M57} And more recently discussed “reader“ settings (design and location) over at https://www.mediawiki.org/wiki/Beta_Features/Hovercards/preferences Related is question to consolidate important reader preferences (appearance, language, accessibility preferences) into one location, which is also a good part of the discussion on the Hovercards preferences. **Separation to other accessibility improvements** In general, with WMF's [[ https://wikimediafoundation.org/wiki/Vision | vision ]] of ”every single human being”, we try to provide broadest-possible support. But with given technical constraints we need to balance the different needs. At T111117 there are for example tasks collected, that can be baked-in per default into our software products, others like above mentioned **font-size**, **day-night modes** etc. are better built as preferences and decided on a per-user base, as there's not one solution fits all. -------------------------- Relevant discussion on: {T72879} **Version**: 1.24rc
    • Task
    # 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.