Note: Users being able to receive the reading list is far more important than being able to send it or export, for the purpose of the experiment

@JTannerWMF @JMinor @Dbrant I have a working prototype in the reading-list-import-prototype branch that is able to decode and import when tapping the landing page link mentioned in https://phabricator.wikimedia.org/T316822#8366987. I expect this will take a couple of weeks to finish up once we pick it up. This is to clean up the existing prototype code, implement the modal design, adjust any launch sequence logic (do we show the onboarding modal?), and handle any errors. The app is already set up to intercept any links that go to *.wikipedia.org. If we need to add to that (like mediawiki.org links), it'll increase the time, because we'll need to mess with the server app association file.

The universal link sad paths can make this feel a bit clunky at times. Once a user has ever shown a preference for a browser for Wikipedia links (it's unclear exactly what situations this is triggered, but long pressing the link in Notes and tapping "Open in Safari" will do it), iOS will not automatically open in the app, and instead send them to Safari every time. Safari does have a "Open in App" banner at the top, which will take them back to the app and import. Even worse, if the user has another browser like Chrome as the default, it sends them to the browser but without that banner to tap. If the user has never indicated a preference for opening Wikipedia links in the browser, Chrome does automatically open in the app and import upon link tap.

So we may want to add some Troubleshooting tips on the landing page for iOS:

1. Download the app, then tap the original link.
2. If it's still opening in the browser, look for an "Open in App" banner on Safari and tap that.
3. If it's opening in a different browser, copy the link and instead open in Safari. Then tap the "Open in App" banner.

I'm having trouble uploading videos of this, but I'm happy to demo it next week.

Hi all -

Something else I wanted to mention here - I can't find an easy way to know that they came from the landing page after launching for the first time from an App Store download. This means screenshot 5 in Variant A would not be possible. The closest thing I could find is copying the reading list url to the clipboard when they tap the App Store link on the landing page, then reading that value whenever the app is launched for the first time. The more recent iOS versions have surfaced clipboard activity more to the user, and iOS 16 throws up an alert, asking the user permission to read the clipboard. So it wouldn't be an entirely smooth process. Let me know what you think, thanks!

Source: it looks like this third party SDK took this approach for some of their deferred deep linking. If you load the video at the bottom and go to timestamp 8:05, you'll see it in action.

Hey @Tsevener – thanks for flagging this (T322158#8380327).

• Yeah, the alert is not great, but would it mean that users don’t have to go back and tap the initial link again? So we don’t have to show the dialog telling people to return to the original message. Maybe we could even lead them to reading lists directly and display the import dialog? (see 7) I mean, that’d be the better experience.
• We still need to figure out what would happen if users don’t allow their clipboard to be accessed. Per your info – there’s not much we can do. Maybe we can show some generic card for reading list sharing in the Explore Feed. I’ll think about it a bit – let me know if you can think of something too.

Yeah, the alert is not great, but would it mean that users don’t have to go back and tap the initial link again? So we don’t have to show the dialog telling people to return to the original message.

@scblr Correct, I think if we're able to attach the reading list link to the clipboard, they can deep link straight to mock 7 after opening the app the first time. I haven't tested this out yet though. If the clipboard doesn't work (the user doesn't grant access, etc.), we can't even show the dialog telling people to return to the original message. We have no way of knowing where they came from after an App Store download. I'm curious about how Android shows that dialog if they're able to - maybe they get a referral URL but without the encoded reading list info?

Sorry, I didn't have this additional context (clipboard, new badge, survey dialog) in mind when I originally said a couple of weeks - at the time I was imagining more of a simple import modal with some success or error UI that takes you to the reading list view once dismissed, where they can rename it from something default if they want (many assumptions on my part - apologies!). I think it will take longer than 2 weeks to really get a good experience close to Variant A here, so maybe we should consider Variant B. If we do go with B, we should also say it's not supported on the landing page, so they aren't taken through a flow to the App Store, only to eventually see an error message.

Sync notes from meeting with @JTannerWMF & @Dbrant. Nice-to-haves will be worked on after the initial if there's time.

• To descope, we won't concern ourselves with deferred deep linking, and instead have a clear set of steps on the landing page to click a wikipedia:// scheme link after downloading the app, which should automatically open the app and bypass the system universal link switcheroo.
• After tapping the landing page link, they will go straight to screen 7. We'll show any standard error or internet connection banners on this screen if we have issues importing.
• From screen 7, we'll automatically select the saved tab and go straight to screen 9. Screen 8 and badge is nice-to-have.
• Survey modal pops up after about 5/10 seconds. Popping up on article if they tap through to one quickly is nice-to-have.
• For fresh users, maybe onboarding should appear after the next app launch?

Notes about survey modal from Slack:

• Q: When should the popup show? A: If we have the best case with sucessful import, show dialog after user successfully imports and names
• Q: Do we need server-side show/hide logic? Can we have it all local (i.e. turn off in the next release update)? A: Survey can be pulled in next update. Survey should only display if we implement solution of receiving the list completely. If we opt for showing the failure message and sending an event then no need for a survey
• Q: Any iOS A/B testing? A: No A/B test on iOS

@JTannerWMF @scblr Quick question on mock 10 - typically we show survey modals once per install, so if they saw it once they'll never see it again (say, in case they tap another shared reading list link later on). Is that how you want it to act here, or do you want it to show every time they land on this screen from the import modal?

WIP PR: https://github.com/wikimedia/wikipedia-ios/pull/4398

Note: Per our meeting yesterday, we decided to permanently skip onboarding if the user first enters the app via a shared reading list.

Hey @Tsevener the intent is if someone clicks not now after seeing the survey (which should be triggered after an import) we show it to them again when they return to the reading list page. Let me know if this is challenging or I may be not considering something.

@JTannerWMF I think it wouldn't be too hard to keep track of a flag if they came from the modal, then if they tap Not Now we try again after they back out and return to the Saved tab. Just FYI that there's no guarantee that they will tap back soon though. They may not make their way back to that screen until after a long rabbit hole, or after backgrounding for days.

Another question - If they tap "take survey", then later go through the import flow again on another (different) shared reading list - do you want us to show the survey prompt again? Or does "take survey" prevent it from showing ever again?

Ah ok thanks for this context. I trust your judgement.

We only want one survey completion per unique user

PR addressing some TODOs: https://github.com/wikimedia/wikipedia-ios/pull/4404

1. No longer pre-populating the title/description with the payload. We are pre-populating the title with "My Reading List"
2. Added a persisted flag to never show the survey prompt again after they tapped "Take survey"

Note we aren't going to have time to implement a snooze feature and present the prompt on the Saved tab (https://phabricator.wikimedia.org/T322158#8400754), unfortunately. But if they haven't already tapped "Take survey", the user will see the prompt again on mock 10 if they go through the flow again with another shared reading list link.

@JTannerWMF last remaining thing needed to unblock us is the survey link - thanks!

One more FYI - I reused some footer text that we've used in a previous survey modal. Let us know if this should be changed:

First link goes to https://foundation.m.wikimedia.org/w/index.php?title=Editing_Awareness_and_Trust_Survey_Privacy_Statement.
Second link goes to https://policies.google.com/privacy

@ABorbaWMF This will mostly be in place in TestFlight build 7.0.0 (2010), if you want to get some early testing in. We'll have one more build after that with the updated survey link.

Update survey link PR - https://github.com/wikimedia/wikipedia-ios/pull/4405

Update - we can expect different survey links for different languages. The logic will be based on the recipient's primary language in the app. We'll have survey links for languages listed under "Primary languages" in T313269.

If for some reason the user doesn't have any of those languages as an app primary language, default to the EN link.

WIP PR with translated survey links - https://github.com/wikimedia/wikipedia-ios/pull/4406

@JTannerWMF Do you want a Spanish link and Urdu link in there as well? Also, I notice your links change in format (sometimes https://forms.gle/bKYnrH2rAv6pZ8718, sometimes https://docs.google.com/forms/d/e/1FAIpQLSfS2-gQJtCUnFMJl-C0BdrWNxpb-PeXjoDeCR4z80gSCoA-RA/viewform?usp=sf_link). It's probably fine, but I just wanted to note it.

Hey @Tsevener (and CC: @JTannerWMF) – I added all survey links to the task’s description. Please make sure to use the Receive survey links on iOS. Also, note that most translations have not yet been verified by a second pair of eyes (see checkmark ✓). The links will not change, but there’ll likely be translation updates. Let me know if you have any questions.

Hey @Tsevener – this is great so far 👏 And thanks to @Mazevedo, I could have a look at this on TestFlight today. Here’s some feedback:

1)

@JTannerWMF Do you want a Spanish link and Urdu link in there as well? Also, I notice your links change in format (sometimes https://forms.gle/bKYnrH2rAv6pZ8718, sometimes https://docs.google.com/forms/d/e/1FAIpQLSfS2-gQJtCUnFMJl-C0BdrWNxpb-PeXjoDeCR4z80gSCoA-RA/viewform?usp=sf_link). It's probably fine, but I just wanted to note it.

Yes, I added all the links to the task’s description (also visible in #3 below) and unified all link formats. Note that we’re in the end stage of verifying translations. I will update the surveys' contents at the beginning of next week (48). We currently have issues getting Urdu translations but should figure it out next week.

2)

In T322158#8404056, @Tsevener wrote:

One more FYI - I reused some footer text that we've used in a previous survey modal. Let us know if this should be changed:

First link goes to https://foundation.m.wikimedia.org/w/index.php?title=Editing_Awareness_and_Trust_Survey_Privacy_Statement.
Second link goes to https://policies.google.com/privacy

Yes, the footer text and links should be updated; more info in #3 below.

3) Please update copy and links for the dialog in multiple languages per this spreadsheet

Affected are:

• Dialog title
• Dialog description
• CTA 1 (Take survey) + update survey links
  • English
  • Arabic
  • Bengali
  • French
  • German
  • Hindi
  • Portuguese
  • Spanish
  • Urdu
• CTA 2 (Not now)
• Privacy text + update legal links:
  • English
  • Arabic
  • Bengali
  • French
  • German
  • Hindi
  • Portuguese
  • Spanish
  • Urdu (no translation available, use English)

PR: https://github.com/wikimedia/wikipedia-ios/pull/4406

Thanks @scblr! I believe I have addressed your comments in my latest PR. I think this will wrap up the native side of things, so we'll kick off a release candidate after that PR is merged for final testing.

Here are screenshots of the modal that I took while testing. Translations for this modal are based on the user's primary app language.

EN:

AR:

BN:

FR:

DE:

HI:

PT:

ES:

UR:

Other:

Confirmed with @JTannerWMF that we should remove the footer quotation marks. Here are the new screenshots (UR already had them removed):

AR:

BN:

DE:

ES:

FR:

HI:

PT:

This (and the final RC) will be in TestFlight build 7.0.0 (2013).

This all looks good to me on the screenshots @Tsevener! 👏 I will test again once build 2013 is available on TestFlight.

@scblr Build 2013 should be available - thanks!

@ABorbaWMF this can be tested as part of testing the overall feature on android. Please check that the language specific links are working and survey is shown.

Android testing ticket: https://phabricator.wikimedia.org/T322671

Looking good on 2.7.50425-alpha-2022-12-05