@Prtksxna The engineers have discussed that this would be much easier to implement if we prevent users from leaving the page, rather than allowing the download pop-up to continue if they go to another page. What do you think? Is this okay?

In T266262#6572394, @ifried wrote:

@Prtksxna The engineers have discussed that this would be much easier to implement if we prevent users from leaving the page, rather than allowing the download pop-up to continue if they go to another page. What do you think? Is this okay?

Yep that makes sense. I imagine the popup to be on the page you opened it on, if you navigate away you lose the popup. The user can of course open it again by clicking Download.

Great, thanks, @Prtksxna! I'll update the acceptance criteria with this information.

• Investigate if & how we can implement the general idea shared by the auto-download example
  • Investigate if and how we can allow users to pick in settings their auto-download preference

We can add a user preference that will store the default auto-download preference. The default format, it would be for any device that they use (ex computer, mobile or tablet).
This approach would just be a matter of coding a new auto-download preference and reading from it. This can be counter productive if they prefer a different format depending on the device.

Rather than a saved user preference, we can store the last download preference in local storage. This implementation would work for any user (logged in or not).
This local storage solution would also work per device. As long as the browser's cache is not cleared, Wikisource would remember their last download file type for the given device. We can add a "remember last download" checkbox to allow users to turn this future on/off per device.

• Investigate if & how we can implement the general idea shared by the picking the file format example

WS Export download process first creates an epub file, and then it is converted to another format if the eBook requested was a different format from epub. There is no way of identifying how long a book download takes so the progress indicators would not be possible. Adding the pop up should be straight forward, but we would need to determine whether the links would make the download request via JS or regular browser. We should also keep in mind that without a job queue managing the download requests, sending a cancel request to the backend (server) would not be possible.

Handle download request via regular browser request:

• The links in the pop ups can point to the same "Download" links as in the side bar.
• Users would see the same behavior as the one on the side bar. Once a download format link is clicked, the browser would show that it's making a request.
• The browser would show loading while download request is being processed.
• Multiple download request would not be possible to process in parallel.
• Canceling requests would not be possible.

Handle download request via JS:

• If a user makes a download request for any of the ebook formats then the pop up would show loading state and the browser will wait for the response. The user would not be able to navigate away from the page where the download request(s) is being processed.
• We can show a loading indicator next to link while download request is being processed.
• Multiple download requests can be processed in parallel.
• Canceling requests might be possible. Although, the server would not be able to cancel the request without a job queue, the client (browser) would cancel processing the file download request.

• Investigate the main challenges, risks, and dependencies associated with such work (for each proposal)

Programming the download button and popup with the options should not be challenging. There are page status indicators, that are sorted by name, in the area where we want to add the download button. We can add the download button as page status indicator or we can force the indicators to the left of the Download button or the right (in the case of LTR languages) .
The time and effort will differ on whether we make the download request via regular browser or JS.

Handle download request via regular browser request:

• Simplest approach since we would just program the new links to point to the same href as the current download links.

Handle download request via JS:

• We can force a file download using JS, using the download attribute. this attribute is in compliance with the same-origin policy, which means that it only works for same-origin URLs.
• We can implement the download requests like other gadgets (ex. articleinfo) have.
• We can implement a cancel download request since JS has the ability to abort a request that is not yet resolved or rejected. Please note that the request would only be cancelled on the client side, the server would still process it, unless there is a job queue in place to handle the cancellation, but the client (browser) would not handle it anymore.

• Provide a general estimation/rough sense of the level of difficulty of effort required in doing such work (for each proposal)

We reached an agreement within the engineering team that we should tackle this feature in the following steps:

1. We should first create the download button and popup and make regular download requests via the browser.
2. The next step would be to change the requests to be handled via JS, which would enhance usability.
3. Lastly, we should add the Default Download enhancement.
   1. Once we get here, we can figure out if we do the local storage (less effort required) or a user preference (more involved).

This would allow us to better measure our progress and get feedback from the community sooner rather than later.

In T266262#6699798, @HMonroy wrote:

Rather than a saved user preference, we can store the last download preference in a session cookie. This implementation would work for any user (logged in or not).

Yep, this is the behavior we want for logged-out users. But for logged-in users, I was thinking that the Default format setting would have the following options:

• Always ask
• Download last downloaded format
• EPUB
• MOBI
• PDF

By default it could be set to always ask. This would give the users a lot of flexibility. You can see more details in F33945268 and the spec.

This can be counter productive if they prefer a different format depending on the device.

You're right, this could lead to the wrong file being generated on a different device. But, since the user will still see all the other options and can trigger them in parallel this shouldn't be a problem. So it'll be two extra clicks if you're on a device that needs a different format — one to start the other format, and the second for cancelling the incorrect download.

@Prtksxna Looks like badges are in the same place as where the new Download would be in Vector. I found https://en.wikisource.org/wiki/Template:Featured. If so, where would the download button go? Are you aware of any other feature that is displayed in the same Download area? Thank you!!

In T266262#6723153, @HMonroy wrote:

@Prtksxna Looks like badges are in the same place as where the new Download would be in Vector. I found https://en.wikisource.org/wiki/Template:Featured. If so, where would the download button go? Are you aware of any other feature that is displayed in the same Download area? Thank you!!

Yeah, you're right! I remember discussing this with @Samwilson. He mentioned that it might be possible to move the badges to the right (in the case of LTR languages) to make space for the button.

If its possible lets do that, if not we'll need to come up with a different position for the button. (I've updated the spec to show this case)