Related to T253877: Have a way to know if a newcomer has the Homepage enabled.
This feature would allow communities to integrate Growth features to their workflows, since the control group would not be a concern. Automated activation of the homepage when people visit it avoids the burden to visit preferences for newcomers.
Content Translation has a similar feature: T199725
Question: how would it impact the data we collect, by diminishing the number of users in the control group?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Trizek-WMF | T247507 Scale: deploy Growth features to 100 wikis | |||
| Open | None | T269847 Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]] |
Good idea. I wanted to test the Newcomers homepage feature, spent five minutes searching in my settings how to enable it, didn't found, had to ask to someone else... Would be easier with the feature Trizek suggests.
@Trizek-WMF technically it would be easier to implement a button on Special:Homepage (for users who don't have it already enabled), and pressing this button would reload Special:Homepage with everything enabled. Would that be OK or is it important for the initial load of Special:Homepage to be activated?
The button is an acceptable alternative. My goal is to avoid frustration from newcomers who can't access the Homepage. But since we can't tell them "go to your preferences", we need a workaround. So yes, the button is a cool option!
Plus maybe it would allow us to track how many activations we have.
Automatically enabling isn't easily done with how the code is currently structured. If we wanted to allow showing some version of Special:Homepage to anonymous users, that would require rewriting some parts of code in such a way that automatically enabling for logged-in users would then be much easier.
We could do the button idea probably without much effort, but that needs prioritization (and design / copy) from @MMiller_WMF and @RHo so I'll move to the relevant column.
IMO a button would be preferable from a UX perspective as well. Visiting some special page once and then having an extra tab forever when you visit your user page / user talk page is confusing (worse if the user menu link change is also enabled).
OTOH I wonder if there's any reason to not disable the homepage for people (as opposed to disabling the extra tab, homepage discovery popups etc). If you go there, you go there with the intent to see the homepage modules; hiding them behind a preference doesn't achieve anything useful IMO.
The things we use the "homepage enabled" preference for:
I think 1 is not particularly valuable and should just go away (users visiting the homepage might complicate A/B tests but that's the same with an "enable" button). 9 is questionable (why shouldn't users with the homepage off be mentored?). 2 and 3 are related to A/B tests and should be handled via user variants and T288022: Support multidimensional user variants in GrowthExperiments, not a visible user preference. 4, 5, 6 and 7 are non-obtrusive discovery features and disabling them only makes sense for an A/B test so should likewise be handled via user variants. 8 is a one-time obtrusive discovery feature; we probably want to be able to differentiate it so we can show it only once per central user account, but there's no point in tying it to a visible user preference.
So IMO just show the homepage unconditionally, replace the preference with a user variant for A/B tests which controls whether the homepage is mentioned during registration etc, show mentees on the mentor dashboard unconditionally (maybe somehow note which ones have the homepage enabled, per T253877), and limit discovery notices to (non-auto-) account creation, in which case they could also use the same user variant setting. If we don't want to do T288022 it could be an invisible user preference instead of the current visible one.
We currently have some task set cache-setting logic in the account creation hook, so that by the time the user arrives at Special:Homepage, they get a cached set of tasks and don't have to wait on the search backend to load the page.
There is not an easy workaround for that, although it is less of a problem now that we only ask for 20 tasks at a time instead of 200.