= 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.
{F11188481}
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
{F11188493}
Enable the features with a checkmark and opacity when the toggleswitch is tapped
{F11188537}
= Acceptance criteria
[X] Before even coding - a meeting is needed to determine and agree on the architecture. Make sure that happens.
[X] 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
= 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
{F12250045}
{F12250046}