Page MenuHomePhabricator

Notify users of Wikipedia app earlier than v6.6 of planned end-of-life
Closed, ResolvedPublic

Description

Job story

As someone who is currently using an early version of the app (prior to v6.6) I need to be able to know that my version of the app will no longer be able to load articles in the near future, so that I can be sure to update my app if possible, or learn about alternative ways to access Wikipedia on my mobile device.

Why are we doing this?

At some soon future date tbd versions of the apps prior to v6.6 will stop being able to load articles due to their dependency on the MobileView API which is deprecated and planned for shutdown.

QA steps

As of 2021/07/01 this represents roughly ~1.5% of our sessions per day according to Apple's analytics, and we'd like to notify these users about the imminent shut down and encourage them to upgrade if possible. To do this we'll insert a persistent notice in each article for a period prior to shutdown.

See parent task for additional context.

Design criteria

Design solution should:

  • Appear on the article view
  • Be platform agnostic (eg. work on Android as well as iOS)
  • Be actionable and specific (eg. individuals should know that the notification applies to them, and we should help them to resolve this issue)

Nice to haves:

  • A way to communicate to individuals what alternatives they have if they cannot upgrade their version of the app (eg. use mobile web)

Considerations:

  • Do we want the notification to be dismissible?
  • Do we want to utilize a preexisting alert design?
  • Do we want an initial modal with information followed by a persistent alert?
Design solution

You can find the designs in Figma here.

The proposed solution: The alert will be present on the top of the article pages inline with the text (under the title of the article).

Inline message.png (669×381 px, 201 KB)

Copy and links

The current content of the alert "Please update your Wikipedia app by [date], as you are currently using the old version of the app. Without the update, articles will stop loading. Click here to learn more."

  • Click here will be a link that takes the user to a media wiki page that explains the need for the update, talks about using the mobile version of Wikipedia if they can't update the app & has an email if someone has further questions or concerns.

Potential designs to build off of

Overlays
Donation banner: https://phabricator.wikimedia.org/T235539
Language variant update banner: https://phabricator.wikimedia.org/T270210

Toasts
Data cannot be shown error: https://phabricator.wikimedia.org/T257595
General toasts: https://phabricator.wikimedia.org/T212320

QA Results - Beta

ACStatusDetails
1T286836#7837034

QA Results - Prod

ACStatusDetails
1T286836#7839730

Event Timeline

Remember that Android users will also see this - Android has far fewer users than iOS currently using this. But message should be generic enough to work for iOS and Android users, and include a mailto link to give us feedback if they can't upgrade.

As of now, planning on inserting a section at the top of every article regarding this API - explaining it will be turned off starting on [insert date], please upgrade your app, and to get in touch w/ us (via a provided email address) if you have concerns. The nice thing is this works for both iOS and Android.

How are we going to handle translation for this? Something we need to consider.

Also adding @Johan to this ticket, so he's aware.

Assuming inside the API endpoint response is where the message will be rendered, we can use the PHP msg function and translation can happen via translate wiki. Can help provide a code sample if that's helpful.

LGoto added a subscriber: OTichonova.

@JMinor any updates here? I'd really like to get this code removed before June. Sam has now left my team so it's really just me maintaining it and I have no interest in doing that. I am happy to help code review or provide the patch to do this, if someone from apps team is willing to test it.

Jdlrobson raised the priority of this task from Low to High.Jan 27 2022, 9:02 PM

Hey sorry for the slow follow through. We have a design and plan but
haven't prioritized the implementation. Let me check on capacity and get
back to you with timing or plan for getting it done.

While looking into this, I found that PCS uses the MobileView API for all requests for Chinese Wikipedia (zh.wikipedia.org). I'm not sure the history of this, but it complicates the retirement of this system. I'm adding Content Transformers to this ticket, as we're going to need their support to figure out how to remove this dependency.

From mobile-html.js, line 87 (router.get('/page/mobile-html/:title/:revision?/:tid?', (req, res)):

if (!mobileviewHtml.shouldUseMobileview(req)) {
			return getMobileHtmlFromParsoid(req, res);
		} else {
			return getMobileHtmlFromMobileview(req, res);
		}

and

function shouldUseMobileview(req) {
	return wikiLanguage.getLanguageCode(req.params.domain) === 'zh';
}

The code has another path that uses Mobileview for main pages, but that code is only called from the /mobile-sections/ API, which doesn’t seem to be used by Android or iOS anymore.

@JMinor @JTannerWMF @schoenbaechler @OTichonova @cmadeo - I've started a mediawiki page that this message will link to. Please feel free to edit it or build it out: https://www.mediawiki.org/wiki/Wikimedia_Apps/Sunsetting_MobileView

I'll aim to get the relevant change for the API ready for next Wednesday so you can test it with apps.

Change 762545 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Show a warning message to clients using the old mobile view API

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

Test wiki created on Patch demo by MCleinman (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/7cb36f9e5e/w/

I finally got an old version of the app to compile and send just some requests to the patch demo server. (If all requests go there, the iOS app breaks in horrible ways.)

This is what we see:

Screenshot 6.png (1×864 px, 342 KB)

The app does some work to hoist the move paragraph of content above Infoboxes, so it makes sense that it also pushes the first paragraph content above this message. I think that's okay. However, the only CSS that the app has (at least, for this old version of the app) for warningbox gives some padding. Since this is a temporary thing that is about to be killed, maybe we could manually add some background color here in the HTML we're adding in? (Also open to better ways, but I think a quick and dirty solution is probably fine here.) Maybe something like medium orange? (We need it to be readable on dark and light themes.)

Since this is a temporary thing that is about to be killed, maybe we could manually add some background color here in the HTML we're adding in?

The updated patch adds some inline styles to do exactly this. Can you take a look?

Test wiki created on Patch demo by MCleinman (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/bf0a905b9b/w/

Test wiki created on Patch demo by MCleinman (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/bf0c890466/w/

Looks great to me, thanks @Jdlrobson!

This is screenshots of the message. It appears after the first paragraph of the intro. (Ignore junk on top - that's from the test wiki.) @JMinor / @JTannerWMF does this look okay to you?

Screenshot 6.png (1×828 px, 309 KB)
Screenshot 9.png (1×830 px, 412 KB)
Screenshot 7.png (1×842 px, 458 KB)
Screenshot 8.png (1×862 px, 532 KB)

Yes, looks good. Thanks for picking this up and sticking with it @MattCleinman

Thanks @JMinor ! Just wanting to check in on the Android side:
@JTannerWMF @Dbrant does Android have any older clients that use the MobileView API that would see these banners?

On Android the number of installs that still use mobileview is virtually nonexistent. Even the oldest versions of the app that aren't using the modern mobile-html (around 0.7% of installs) are using the mobile-sections-lead and mobile-sections-remaining endpoints, which are parsoid-based. (Matt correctly noted that those endpoints do indeed touch mobileview in the case of Main pages, but that can also be removed and replaced by parsoid, since that was just for styling purposes.)

Nevertheless we will be prepared to field any support questions from any impacted users, should they come up.

We're still waiting for this to be deployed to production, right? Is there anything we can do to assist with it's deployment?

I figured this was blocked on T236733: mobile-html: Remove mobile view API dependency when parsoid supports language variants on zhwiki

Otherwise chinese apps would show banner for all page views.

Am I mistaken?

No, you're 100% correct. Thanks, total Friday brainfart over here.

Change 762545 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Show a warning message to clients using the old mobile view API

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=mobileview&format=json&page=Conflict-title-0.7231249569571601-I%C3%B1t%C3%ABrn%C3%A2ti%C3%B4n%C3%A0liz%C3%A6ti%C3%B8n&sections=all&prop=text%7Csections
✅ AC1: Confirm the message "Please upgrade your app." appears in the response

Screen Shot 2022-04-06 at 5.53.59 PM.png (954×1 px, 190 KB)

Edtadros added a subscriber: Edtadros.

Test Result - Prod

Status: ✅ PASS
Environment: enwiki
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Visit https://en.wikipedia.org/wiki/Special:ApiSandbox#action=mobileview&format=json&page=Langler&sections=all&prop=text%7Csections
✅ AC1: Confirm the message "Please upgrade your app." appears in the response

Screen Shot 2022-04-07 at 3.20.56 PM.png (1×1 px, 463 KB)