Added more details @JTannerWMF to the task’s description, assigned you, and moved it to “Ready for PM signoff”. Thanks for reviewing it.

Thanks for this great breakdown of options and helpful wireframes, @scblr! I can definitely see pluses and minuses for both file format approaches, but do think that the overall flow looks good!

The generic (.csv) example is interesting because I imagine that it might be helpful for sharing a list with folks who don't/can't use either of the apps -- I'm a bit curious if we want a 'download list' option that exports to a .csv file as a share menu option even if we go with a custom file type (maybe this is too much of an ask though) but I could potentially see some utility to exporting structure files of articles URLs.

I have a slight preference for the custom file type due to the differences between how common the notion of 'files' are on iOS and Android. I'm a bit worried that iOS users will have a harder time understanding and working through the downloading and accessing of a generic file on their device. While the 'files' app does help with this (and more research would be necessary, perhaps some testing too!) accessing files is much less common for apps on iOS than on Android.

So excited to see this coming together! Some notes below:

🅱️ VARIANT B: Generic file format (e.g. .csv)

Out of curiosity, what's the intent behind CSV over say, JSON? Is it just here for illustrative purposes as a possible generic file format, or are you all exploring CSV as a potential data format to use? On the iOS side, regardless of what file extension we choose, it's preferable if the actual underlying data in the file is JSON.

🅰️ VARIANT A: Wikipedia file format (e.g. .wikipedia)

I haven't yet researched it on the iOS side, but I have a higher degree of confidence that a custom file extension (e.g. .wikilist) will be more straightforward to associate with our mobile client apps than a generic extension (e.g. .csv).

Contains a link to MediaWiki, in case the recipient does not have the app installed (see chapter 2. App not installed)

Apologies as this gently breaks the no external services/landing pages condition, but I'd recommend that instead of directing the user to the mediawiki.org/WikipediaApps page (https://phab.wmfusercontent.org/file/data/ge6xnu5uwdicgxs7e3vf/PHID-FILE-crjjjrbrpqbs7kajh6jl/image.png) first, we direct them to an intermediate page that automatically and silently a) does its best to detect if their device is Android or iOS based b) directs them to the device specific App Store based on that if possible or c) directs them to that originally proposed MediaWiki page if not possible. Much less friction to get them to exactly what they want (the app on their platform) this way.

Definitely agree with @Dmantena about JSON instead of CSV, as well as a custom file extension (.wikilist) over a generic extension.

The question of what kind of landing page to use is a tricky one. Having a static page expressly for this purpose would be extremely irregular (i.e. "everything must be a wiki page"), and would be a tough sell.
However, do we know whether it's possible to get the user-agent from within a wiki page itself? If so, we might be able to create a template that displays different links conditionally based on user-agent.

This is exciting stuff, thanks for this writeup @scblr !

As a Wikipedia Android app user and student in Morocco, I want to export my reading lists, so that I can use it at the Mohammed V University school library

@Dbrant @Dmantena I think for the user story of someone that wants to export their reading lists, but not necessarily share it to another Android/iOS device, .csv or something similar is preferable to .json. If the user wanted to export a list of 1000 articles to use on a library computer - I feel like .csv would allow them to quickly visualize the articles & manipulate the list further. Then again, they could also probably find a way to import .json into a spreadsheet if they're motivated enough.

Agreed that the custom file extension would be a smoother flow for the users sharing with other Android/iOS devices, and I can see how .json would be easier for us engineers to import. I'm not familiar yet with how to share and traverse .csv files on iOS. So tacking onto @cmadeo 's thoughts, perhaps we should treat this as two different (but similar) features - one for sharing/importing with other Android/iOS devices, and another just for exporting.

One other piece of feedback - I could see the average user getting a bit confused on which tappable area does what (MediaWiki link vs file) in the text message. I know this says copy is TBD, but I just wanted to point out that we should pay close attention to how we word that shared text to prevent confusion.

In T313740#8148577, @Tsevener wrote:

I think for the user story of someone that wants to export their reading lists, but not necessarily share it to another Android/iOS device, .csv or something similar is preferable to .json. If the user wanted to export a list of 1000 articles to use on a library computer - I feel like .csv would allow them to quickly visualize the articles & manipulate the list further. Then again, they could also probably find a way to import .json into a spreadsheet if they're motivated enough.

Definitely agree with @Tsevener on preferring .csv for a 'data download' for use outside of the apps.

It is true that csv is more human-readable than json (although not too much), it comes at the cost of not being nearly as extensible.
A fully structured format like json would let us support further use cases like:

• Exporting more than one list at a time (in a single file)
• Backing-up the user's entire collection of reading lists
• Storing additional metadata, as well as future data, while remaining compatible across different versions of the app.

@scblr Thank you for putting this together!
The wireframe designs look good to me!
+1 to Variant A being more straightforward for iOS users to avoid downloading files separately.
+1 to @Tsevener comment to

treat this as two different (but similar) features - one for sharing/importing with other Android/iOS devices, and another just for exporting.

FYI, it's looking like iOS won't be able to pass through a simple App Store url parameter and detect that upon the first app launch, so keep that mind as you flesh out the Android experience. We likely won't be able to know the state when someone downloaded the app from some shared text but hasn't tapped the .wikipedia file yet.

Hi @scblr
Per discussion on today's apps stand up:
Maybe we can use the advantage of showing a preview from the MediaWiki page URL, which can create more attractive preview content for the users to open the link to download the apps.
We can first contain the MediaWiki page URL so that the messaging app will try to capture the URL preview instead of the .wikipedia extension.

Another thought:
We can include JavaScript in the wiki page to capture the user agent and introduce the corresponding app store URL for the user. Or another extreme method: create a MediaWiki extension for the wiki page.

Moving this back to RObin's column for him to adjust some flows

In T313740#8165430, @JTannerWMF wrote:

Moving this back to RObin's column for him to adjust some flows

I adjusted the flows + moving this to “Needs analytics”.

This is blocked on T316048. When we know what the flow will be we can proceed with analytics review or make adjustments to the wireframes

Unfortunately these designs aren't relevant anymore so I made T316822