Page MenuHomePhabricator

Provide a feature flagged way for logged in users to disable mobile optimisations
Closed, ResolvedPublic3 Estimated Story Points

Description

NOTE: This task is for testing and demo purposes only. We will not be deploying this to production for the time being.

I had a conversation with @JKatzWMF around giving editors more control of their mobile experience.

Many users have expressed a desire to use a more feature rich skin on mobile.
With little work we can provide a preference that helps them achive this goal.

Editors would be able to disable mobile friendly versions of pages such as special pages for example desktop watchlist:

I believe giving editors more control over their mobile experience would be welcomed and increase understanding of the challenges with a "responsive Vector" and making desktop interfaces MediaWiki mobile friendly.

QA steps

  • After setting up the wgMFEnableMobilePreferences to 1 there should be visible a new option in the user preferences - appearance section.
  • logged in users can enable/disable the option. The option preference stays after logging out/logging in
  • when the option is checked - the desktop version of Watchlist and History pages should be accessible when browsing Wikipedia on mobile

Acceptance criteria

  • A new preference shows up in Special:Preferences allowing logged in users to disable optimisations
  • Pages are optimised by default.
  • Feature flag (disabled by default) and deploy this to staging

Developer notes

Per @Tgr

... I think the cleanest approach is to declare the SpecialPage_initList hook as something that needs to be mindful of potentially running in a no-session context (as it's one of a relatively small number of hooks that can be triggered from pretty much any endpoint) and needs to call User::isSafeToLoad() when appropriate.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 7 2018, 10:20 PM

Change 408938 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Add mobile preferences

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

^ @JKatzWMF per our lunch time conversation last week this is what I would suggest doing as a first step to collect data on what editors want from a mobile Vector experience. Let me know if you would like a demo.

@Jdlrobson interesting data collection approach and I like the framing you're using. Pinging @ovasileva and @CKoerner_WMF who are considering prelim information gathering options now.

Are we open to merging the patch? According to @Sniedzielski the patch is good to go, if we want it, so really this becomes a question to product. I do think this will give us an interesting insight into how our editors want to use the mobile site, so the sooner the better the data we'll have. What thinks you, @Nirzar @ovasileva ?

I think we should eventually over the next month or so, but not yet. I'd like our plans on vector, etc to be a bit more settled first before we do this.

Kizule moved this task from Backlog to Doing on the good first task board.May 17 2018, 4:35 PM

@ovasileva we talked about revealing the special page feature but not the skin choice as a first iteration to provide a way for editors at Wikimania to provide feedback. Still okay to do that?

@Jdlrobson - yes - still think it's a good idea so long as we can keep it on the user preferences page. A question from my side - if we want to use it mostly for demo purposes should we put it in production? Perhaps it's something that can live on staging?

ovasileva triaged this task as Medium priority.Jun 22 2018, 10:52 AM
Jdlrobson updated the task description. (Show Details)Jun 26 2018, 11:02 PM

There's no harm in putting in production and little benefit to having it only on staging. If anything putting this on production would be an advantage, given it will raise awareness/discoverability; more people will try it out and experience and report problems to us... which is what we want right?

There's no harm in putting in production and little benefit to having it only on staging. If anything putting this on production would be an advantage, given it will raise awareness/discoverability; more people will try it out and experience and report problems to us... which is what we want right?

Not necessarily. Our goal would be to fix at least the main issues with the pages up before we show it to users. Exposing this currently would have the benefit of having something that we can user test and demo with, so staging seems like a good option. I think there's some fixes we need to do before we're ready for production. My main question is - do we have any concerns around putting it in staging only in terms of functionality?

My main question is - do we have any concerns around putting it in staging only in terms of functionality?

No. That's fine.

Change 408938 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add special pages preferences

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

ovasileva updated the task description. (Show Details)Jul 3 2018, 4:31 PM

This patch was reverted so let's investigate why and if that makes this more complicated.
We'd like it for Wikimania in 2.5 weeks if possible

^ @JKatzWMF per our lunch time conversation last week this is what I would suggest doing as a first step to collect data on what editors want from a mobile Vector experience. [...]

What is the concrete plan for collecting this data? (I assume it's not quantitative data that we're after, but qualitative user feedback?)

^ @JKatzWMF per our lunch time conversation last week this is what I would suggest doing as a first step to collect data on what editors want from a mobile Vector experience. [...]

What is the concrete plan for collecting this data? (I assume it's not quantitative data that we're after, but qualitative user feedback?)

What we're thinking currently is something fairly open-ended. Showing users the pages, asking open-ended questions around what they think, use it to demo within a presentation, etc. For more formalized user testing, I think we'll probably use a separate prototype.

This is interesting. Do you have plans to allow disabling the mobile editor as well? (Here's an example of someone wishing to use the desktop editor on mobile: T195528)

This patch was reverted so let's investigate why and if that makes this more complicated.
We'd like it for Wikimania in 2.5 weeks if possible

Quick ideas for alternative approaches for your patch (all untested):

  • Just don't do the replacement (or always do it) if defined( 'MW_NO_SESSION' ) (similar to T135445)
  • Use the SpecialPageBeforeExecute hook to replace the original watchlist etc. with the mobile one conditionally
  • Have SpecialMobileWatchlist check the condition and if it determines it shouldn't be replaced, call the original watchlist with new SpecialWatchlist()->run() or something

Change 443679 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Add special pages preferences""

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

(I assume it's not quantitative data that we're after, but qualitative user feedback?

No this was in reference to user feedback. If user's can use special pages on mobile, they can tell us specifically what's broken in their workflow.

This is interesting. Do you have plans to allow disabling the mobile editor as well? (Here's an example of someone wishing to use the desktop editor on mobile: T195528)

No concrete plans but yes this would be in the spirit of the idea - more power to editors and flexibility over their experience.

Jdlrobson renamed this task from Allow logged in users to disable mobile optimisations to Provide a feature flagged way for llogged in users to disable mobile optimisations.Jul 3 2018, 7:18 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Tgr.

Use the SpecialPageBeforeExecute hook to replace the original watchlist etc. with the mobile one conditionally
Have SpecialMobileWatchlist check the condition and if it determines it shouldn't be replaced, call the original watchlist with new SpecialWatchlist()->run() or something

It's not just watchlist... it replaces Contributions/History and various others. I think https://gerrit.wikimedia.org/r/443679 takes care of this?

MBinder_WMF renamed this task from Provide a feature flagged way for llogged in users to disable mobile optimisations to Provide a feature flagged way for logged in users to disable mobile optimisations.Jul 4 2018, 4:06 PM
ovasileva updated the task description. (Show Details)Jul 4 2018, 4:14 PM
pmiazga added a subscriber: pmiazga.Jul 5 2018, 2:57 PM

I have a few questions regarding this task.

a) As this feature is required to demo the new behaviour, do we need to merge it to master and push live?
b) how long do we want to keep it? is it month/quarter/half a year?
c) pages are optimised by default -> what does that mean?
d) which features do we want to disable? All special pages?
e) is there any style-removal involved? or do we want only to restore orignal special pages when browsing on mobile?
f) looks like this is a proof-of-concept work, can we do it quick&dirty (no tests, no merging to master)?

I have a few questions regarding this task.

a) As this feature is required to demo the new behaviour, do we need to merge it to master and push live?
b) how long do we want to keep it? is it month/quarter/half a year?

It was my understanding, eventually this would go to production as something of this nature has been much requested from editors I have spoken to. Keyphrase "for the time being".

c) pages are optimised by default -> what does that mean?

Right now if you visit http://en.m.wikipedia.org/wiki/Special:Watchlist you see an optimised version of the default Watchlist page (http://en.wikipedia.org/wiki/Special:Watchlist?useskin=minerva). This would still be the default behaviour but it would now be opt out.

MobileFrontend substitutes out various special pages so that only the optimised version is accessible on mobile, forcing editors to switch to desktop in the footer. This annoys a lot of users, so by turning this off, editors would be exposed to a less mobile friendly but more powerful equivalent.

d) which features do we want to disable? All special pages?
e) is there any style-removal involved? or do we want only to restore orignal special pages when browsing on mobile?
f) looks like this is a proof-of-concept work, can we do it quick&dirty (no tests, no merging to master)?

I'm not sure I follow any of this. Does the above explanation help?

Not clear what needs analysis here. Please when moving to needs analysis, please explain whats needed. This looks well defined to me (see https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-zm75un5g3p6j7z4/)

@pmiazga - let me try address the timing. I also agree with @Jdlrobson that I think there's some confusion here - I'm not sure I understand the last set of questions fully

a) As this feature is required to demo the new behaviour, do we need to merge it to master and push live?
b) how long do we want to keep it? is it month/quarter/half a year?

This would most likely not go to production as-is (this is why we're building an opt-in option to specifically address this, I'm unsure if we would be able to reuse some of this code for that). However, this would be extremely helpful for demo purposes as well as for testing and QA during the length of the project (2+ quarters)

ok 2+ quarters is pretty long, it means we have to merge everything into master. I think that all my questions are answered now. Thank you.

ovasileva raised the priority of this task from Medium to High.Jul 10 2018, 4:28 PM

Change 443679 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add special pages preferences

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

pmiazga updated the task description. (Show Details)Jul 16 2018, 7:00 PM
pmiazga updated the task description. (Show Details)

@Jdlrobson: I don't see this Mobile Preferences option in the user preferences - appearance section on reading-web-staging or on beta cluster, where should I test it?

@Ryasmeen, sorry for the confusion. There are two tests:

  1. Login and visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop)
  2. Ensure the "optimize and simplify special pages when on mobile (recommended)" option isn't present.
  3. Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:EditWatchlist (mobile)
  4. Ensure the watchlist is the modern mobile friendly version shown on prod.

And:

  1. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page (note the HTTPS).
  2. Create an account and login.
  3. Disable "optimize and simplify special pages when on mobile (recommended)" from https://readers-web-master.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop).
  4. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:EditWatchlist&mobileaction=toggle_view_mobile (mobile).
  5. Ensure the watchlist is ugly!

@Ryasmeen, sorry for the confusion. There are two tests:

  1. Login and visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop)
  2. Ensure the "optimize and simplify special pages when on mobile (recommended)" option isn't present.
  3. Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:EditWatchlist (mobile)
  4. Ensure the watchlist is the modern mobile friendly version shown on prod.

And:

  1. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page (note the HTTPS).
  2. Create an account and login.
  3. Disable "optimize and simplify special pages when on mobile (recommended)" from https://readers-web-master.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop).
  4. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:EditWatchlist&mobileaction=toggle_view_mobile (mobile).
  5. Ensure the watchlist is ugly!

Thanks for the clarification @Niedzielski!

Checked the Special:EditWatchlist page with the option for optimization both enabled and disabled. Seems to be working properly.

Niedzielski reassigned this task from Ryasmeen to ovasileva.Jul 24 2018, 5:05 PM
Niedzielski added a subscriber: Ryasmeen.
ovasileva closed this task as Resolved.Jul 25 2018, 8:12 AM

yes! this looks great. Thanks all.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJul 25 2018, 8:12 AM