Show unconfigurable settings in mobile beta
Closed, ResolvedPublic8 Story Points

Description

Background

We want to show all the features that a user will opt into when switching from stable to beta so they know what they are gaining by doing so.

Proposal

  • Split the settings into stable features and beta features.
  • Present the stable features.
  • Present the beta features. When the group toggle switch is enabled, honor the individual switch settings which default to on. When the group toggle switch is disabled, disable all beta features regardless of individual switch state and present the individual switches as disabled.

  1. Show user what features will get enabled when Beta is enabled.
  2. show toggleswitch for beta feature
  3. activate the said features if the toggle switches are turned on

Mocks

Here's a click through prototype
https://wikimedia.invisionapp.com/share/BMCCQ3OYQ#/screens/241120755

Show lock icons when the features are not enabled

Enable the features with a checkmark and opacity when the toggleswitch is tapped

Acceptance criteria

  • Before even coding - a meeting is needed to determine and agree on the architecture. Make sure that happens.
  • This should be done inside the specialpages feature branch
  • If user toggles beta, the features becomes enabled with green tick mark
  • With beta features with individual setting, the setting will go in the place of the tick mark

note: Currently, all beta features listed above will be included. We will be promoting them separately after the change.

Sign off steps

  • Summarise the approach and share with team members not involved in refactoring.
  • Create QA task for all settings/beta work

@phuedx: See T184742: QA of 'specialpages' feature branch (settings page).

Developer notes

Ideal this would be implemented by formalising our feature management. Doing so would be much cleaner and require less maintenance.
Features that are enabled in beta but not stable are config variables which are arrays and have stable and beta keys where stable is false and beta is true. As part of this we might want to consider something like

wgMFFeatures = [
  "MFEnableFontChanger": {
           "base": false,
         "beta": true
    },
]

to provide easy lookup.

There is one exception to the rule: MFDisplayWikibaseDescriptions, the logic for which lives in MobileContext::shouldShowWikibaseDescriptions and the config looks like

"MFDisplayWikibaseDescriptions": {
            "search": false,
            "nearby": false,
            "watchlist": false,
            "tagline": false
    },

We may want to rethink the logic there if using wgMFFeatures.

When rendering the MobileOptions page we'll want to:

  1. Obtain variables with beta/stable switches that we haven't already rendered (and thus assume are unconfigurable)
  2. Print these rows in the UI with appropriate opacity. We'd need to generate message keys from config variables e.g "mobile-frontend-option-MFDisplayWikibaseDescriptions-description", "mobile-frontend-option-MFDisplayWikibaseDescriptions-title" and print these in MobileOptions

The feature-like config variables...

Inside MobileFrontend extension.json:

   "MFEnableFontChanger": {
            "base": false,
            "beta": true
    },
   "MFShowFirstParagraphBeforeInfobox": {
            "base": true,
            "beta": true
    },
    "MFLazyLoadImages": {
            "base": true,
            "beta": true
    },
    "MFLazyLoadReferences": {
            "base": false,
            "beta": true
    },
   "MFExpandAllSectionsUserOption": {
            "base": false,
            "beta": true
    },
"MFDisplayWikibaseDescriptions": {
            "search": false,
            "nearby": false,
            "watchlist": false,
            "tagline": false
    },

Inside Minerva skin.json:

"MinervaShowCategoriesButton": {
        "base": false,
        "beta": true
},
"MinervaEnableBackToTop": {
        "base": false,
        "beta": true
}

assets

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson updated the task description. (Show Details)Dec 12 2017, 5:41 PM
ovasileva set the point value for this task to 8.Dec 12 2017, 5:42 PM

a meeting will be schedules to discuss the best way to do this, estimate may fluctuate afterwards

blocked on meeting with all engineers

Darkminds3113 set Security to Software security bug.Dec 22 2017, 3:57 AM
Darkminds3113 added a project: Security.
Darkminds3113 changed the visibility from "Public (No Login Required)" to "Custom Policy".
Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".Dec 22 2017, 5:32 AM
Bawolff removed a project: Security.
Bawolff added a subscriber: Bawolff.

[Rv make bug security because bug does not appear sensitive]

Restricted Application added a project: Security. · View Herald TranscriptDec 22 2017, 5:32 AM

Meeting has been setup for Thursday. @Niedzielski @pmiazga @Jhernandez @Jdrewniak would be great if you could become familiar with the task and patch during the course of Wednesday.

Niedzielski updated the task description. (Show Details)Jan 3 2018, 6:54 PM

I like the idea of the base configuration since this allows us for nonboolean options. e.g., a background color state could could be "DARK", "LIGHT", or "BLACK".

Nirzar added a comment.Jan 4 2018, 6:34 PM

is this still blocked?

We chatted about this today.

We're going to:

  • add an interface for registering features and checking if a feature is enabled and listing all features.
  • There will be a hook that allows extensions/skins to register new features
  • Extensions/skins will use the new service and isFeatureEnabled mode to tell whether they should turn on/off features.
  • We think we should be able to retain the existing code by instead calling FeatureManager->registerFeature('wgConfigName')
  • MobileContext getConfiguration code will be removed as soon as this is all up and running

I'm going to focus on the UI changes (with some smoke and mirrors) and @pmiazga will pick up the backend portion tomorrow.

Change 402126 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@specialpages] Feature flag Wikidata Descriptions

https://gerrit.wikimedia.org/r/402126

Change 402127 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@specialpages] List all the features in beta (UI)

https://gerrit.wikimedia.org/r/402127

I made as much progress as I could on this today. I am blocked on Piotr and Nirzar now.

Note the list of features will not be comprehensive until we create the feature flagging infrastructure (@pmiazga will take care of that tomorrow)
@Nirzar I need icons for the tick and the lock icons that go to the right of the features and I need some guidance on the feedback link - is that still needed? Is it going to be configurable? Some feedback on the design so far at
http://reading-web-staging.wmflabs.org/wiki/Special:MobileOptions?useskin=minerva would also be useful.

Nirzar updated the task description. (Show Details)Jan 4 2018, 10:15 PM

Shower thought: Would it make sense to link the beta features to the associated bug numbers? e.g. references might link to T123328

Jdlrobson assigned this task to pmiazga.Jan 5 2018, 8:17 PM
Jdlrobson moved this task from Blocked on Others to Doing on the Readers-Web-Kanbanana-Board board.

Okay, worked out issues with @Nirzar. Since the current UI is smoke and mirrors we now need the server side component for FeatureManagement that Piotr is working on so re-assigning.

ovasileva raised the priority of this task from Normal to High.Jan 8 2018, 5:01 PM

Change 402938 had a related patch set uploaded (by Pmiazga; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@specialpages] Mobile Frontend feature management system

https://gerrit.wikimedia.org/r/402938

Change 402126 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Feature flag Wikidata Descriptions

https://gerrit.wikimedia.org/r/402126

Change 403065 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@specialpages] Minerva should use FeatureManagers class

https://gerrit.wikimedia.org/r/403065

Change 402938 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Mobile Frontend feature management system

https://gerrit.wikimedia.org/r/402938

Change 403071 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@specialpages] Improvements to existing feature management system

https://gerrit.wikimedia.org/r/403071

Change 403073 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@master] Improvements to existing feature management system

https://gerrit.wikimedia.org/r/403073

Change 403073 abandoned by Pmiazga:
Improvements to existing feature management system

https://gerrit.wikimedia.org/r/403073

Change 402127 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] List all the features in beta (UI)

https://gerrit.wikimedia.org/r/402127

Change 403078 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@specialpages] MobileFrontendFeaturesRegistration hook should be called earlier in stack

https://gerrit.wikimedia.org/r/403078

Change 403071 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Improvements to existing feature management system

https://gerrit.wikimedia.org/r/403071

Piotr's changes are merged. Latest and greatest code is on staging.

Almost there. Two minor changes outstanding needing code review:

  1. MobileFrontendFeaturesRegistration hook should be called earlier in stack
  2. Minerva should use FeatureManagers class

See also opportunistic refactoring:
https://gerrit.wikimedia.org/r/402422

phuedx added a comment.Jan 9 2018, 9:17 AM

@Jdlrobson, @pmiazga: Make sure you share the refactoring that you've done (maybe reading-web-team@ first?)! 🙂

Jdlrobson updated the task description. (Show Details)Jan 9 2018, 4:57 PM

Change 403078 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] MobileFrontendFeaturesRegistration hook should be called earlier in stack

https://gerrit.wikimedia.org/r/403078

Change 403221 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@master] Hygiene: Introduce a isFeatureAvailableInContext() method

https://gerrit.wikimedia.org/r/403221

Change 403225 had a related patch set uploaded (by Jdlrobson; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@specialpages] Hygiene: Introduce a isFeatureAvailableInContext() method

https://gerrit.wikimedia.org/r/403225

Change 403221 abandoned by Jdlrobson:
Hygiene: Introduce a isFeatureAvailableInContext() method

https://gerrit.wikimedia.org/r/403221

Change 403225 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Hygiene: Introduce a isFeatureAvailableInContext() method

https://gerrit.wikimedia.org/r/403225

Change 396485 abandoned by Jdlrobson:
POC: List everything that's in beta (feature management FTW)

https://gerrit.wikimedia.org/r/396485

@ovasileva @Nirzar
Okay new code is live: http://reading-web-staging.wmflabs.org/wiki/Special:MobileOptions
One patch left to be merged but it's +2ed.

Any further changes needed, or are we ready to start QAing this thing?!

Jdlrobson reassigned this task from Jdlrobson to ovasileva.Jan 9 2018, 9:33 PM

Change 403304 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/MobileFrontend@specialpages] Run MobileFrontendFeaturesRegistration only once

https://gerrit.wikimedia.org/r/403304

Change 403304 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Run MobileFrontendFeaturesRegistration only once

https://gerrit.wikimedia.org/r/403304

Change 403065 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@specialpages] Minerva should use FeatureManagers class

https://gerrit.wikimedia.org/r/403065

Jdlrobson added a comment.EditedJan 9 2018, 10:55 PM

(take 2)
@ovasileva @Nirzar
Okay new code is live: http://reading-web-staging.wmflabs.org/wiki/Special:MobileOptions

Any further changes needed, or are we ready to start QAing this thing?!

Looks good! What happened to "expand all sections" though?

Looks good! What happened to "expand all sections" though?

we removed it on tablets and desktops because the feature did not work on tablets/desktops

Mybad. Just tested on my phone - looks good - onwards to QA. The QA task will be separate though

Jdlrobson updated the task description. (Show Details)Jan 10 2018, 12:13 AM

Looks good! What happened to "expand all sections" though?

we removed it on tablets and desktops because the feature did not work on tablets/desktops

See T169257: Promote expand all sections feature from beta (in feature branch) IIRC.

Projects should not normally be subscribers to a task as it can cause people to erroneously receive email notifications (like I have for the past few months), so I removed Readers-Web-Backlog as a subscriber here. This task is still tagged with the Readers-Web-Backlog project, so this change is not disruptive to people subscribed to the project. Sorry for the intrusion.

Deskana removed a subscriber: Deskana.Jan 10 2018, 11:44 AM
ovasileva updated the task description. (Show Details)Jan 10 2018, 6:05 PM
ovasileva updated the task description. (Show Details)
ovasileva updated the task description. (Show Details)Jan 10 2018, 6:08 PM

took a second look today - it seems the font changer is missing (it was there yesterday)

I turned it off for nirzar who was curious about something. Will restore it tomorrow.

(should be updated now so you can begin QA).

ovasileva closed this task as Resolved.Jan 12 2018, 12:25 AM

looks good, thanks @Jdlrobson

phuedx updated the task description. (Show Details)Jan 12 2018, 7:52 AM
ovasileva updated the task description. (Show Details)Jan 12 2018, 3:46 PM

@Nirzar, @Jdlrobson - just to confirm, "With beta features with individual setting, the setting will go in the place of the tick mark" was tested by @Nirzar, right?

@ovasileva we did test this, but nope this behaviour does not happen. The option will appear above the "Wikipedia βeta" heading as currently designed.
When talking to @Nirzar I suggested we could rectify this when we build a new beta feature with settings e.g. dark mode for example (as currently no beta features have individual settings). We could do this now (if we do it might be worth creating a subtask to capture as mocks don't show how this should work), but it will drag back the release and the only major benefit would be in the unlikely event we disable fontchanger/expand all sections in stable post-release. What do you both think?

@ovasileva we did test this, but nope this behaviour does not happen. The option will appear above the "Wikipedia βeta" heading as currently designed.
When talking to @Nirzar I suggested we could rectify this when we build a new beta feature with settings e.g. dark mode for example (as currently no beta features have individual settings). We could do this now (if we do it might be worth creating a subtask to capture as mocks don't show how this should work), but it will drag back the release and the only major benefit would be in the unlikely event we disable fontchanger/expand all sections in stable post-release. What do you both think?

I think it's fine to do it later. I'd say let's set up a task anyhow, just as a reminder for the future.