Over to you @alexhollender - added some notes. Prioritise as necessary!

In T201954#4502632, @Jdlrobson wrote:

Prioritise as necessary!

Understanding that:

• The deployment of the Proton service is blocked for at least the next week and probably for the next two weeks; and
• Page Issues is the current top priority.

There are mocks and an Invision-mabob in the description of T163472: [EPIC] Provide a way to download articles in PDF on the mobile website. AIUI that task is out of date and probably needs a pass from both @ovasileva and @alexhollender once they've synced.

Agreed. @alexhollender - if you do get a chance to look this week, for the latest version we decided not to include the file size. So flow should roughly be button click -> spinner -> done. I'll add more notes when I'm back.

I like the idea of having a confirmation step here. Perhaps we could limit it to the first 5 downloads or something?

Before moving forward with any design I think we need to play around in staging a bit to see how various browsers/devices react to the download action. I can think of at least three browser reactions:

1. download begins immediately. Browser will give some indication that download started
   • this is currently what happens in Chrome/Android if you click a link that leads to a PDF file
2. user is prompted to choose a location to save the download (in which case it will be obvious to them what's happening)
   • this is what happens if you use the Print > Save to PDF flow in Chrome/Android, or do the Save PDF > Save to My Files flow in Safari/iOS
3. PDF file opens in a new browser window, unclear to user whether or not it has been "downloaded" to the phone (i.e. can they quit the browser, go offline, and still access the PDF somewhere?)
   • this is what happens in Chrome & Safari on iOS when you click a link that leads to a PDF file

Moving this to blocked until we have the eng resources to add the button on staging so we can play around with a few different browsers/devices

There is also an opportunity here to promote the share API where available to directly wire this to other apps/send functionality: https://www.youtube.com/watch?v=eY9uLyzIKCE&feature=youtu.be

The Share API in an interesting feature to consider. It looks like it only has Android Chrome support, but it's a widely understood feature of mobile apps, and the native Android and iOS Wikipedia apps have it as well.

The only question I have would we, do we link to the mobile page, or the pdf from the share screen?

@Jdlrobson - is this blocked on anything browser wise or is it simply a matter of putting it on staging and testing?

I think we just need to make the button link to the PDF e.g. https://en.wikipedia.org/api/rest_v1/page/pdf/Spain ?

This is only blocked on design (for instance we may want to confirm the download and use a drawer to avoid accidental PDF generation)

It's possible to add the print button to Firefox now thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=1414935 - although note older Firefox browsers with no update path would show a non-functional button.

Mozilla reached out to us about this bug https://github.com/webcompat/web-bugs/issues/80978
Probably worth prioritizing from a technical point of view if not a product point of view as it's easier to test our site when it appears consistently across browsers.