replace downloads

[jo-pol]

Problems

• Downloads of diagrams and Inkscape templates are OK for desktop/laptop devices, but of no use for tablets.
• Resizing panels is cumbersome for touch devices.

Potential solution

Show the content of the download on a new page, probably in a new tab.

• Tablet users have maximum real estate for diagrams in one tap action.
• Desktop/laptop users can still download using file - save page as or perhaps right-click and save link as to edit the diagram with a third party tool.
• Not sure other measurements are needed for tablet users to load the diagrams into third party tools.

Note that currently a right-click on a download link and open link in new tab still works in Chrome (with a security warning) but no longer in FireFox. Data URLs may be discontinued in the future. Older browsers may have size limits.

A related subject.

The context menu of a browser lets you view the image as a stand alone page for PNG and JPG images. It doesn't for the SVG objects. I tried to assign the data-URI to the src attribute of an <img>, the image appeared in both browsers. Using the context menu of the browser had the same effects as open link in new tab: it worked with a security warning on Chrome, not at all in FireFox.

Current implementation

https://github.com/d-bl/GroundForge/blob/5a9910a62b7fb8a0e65078e5ebbf48c852db6217/docs/tiles.html#L115-L118 https://github.com/d-bl/GroundForge/blob/5a9910a62b7fb8a0e65078e5ebbf48c852db6217/docs/tiles.html#L132-L135 https://github.com/d-bl/GroundForge/blob/4c38bc71b915cc2c9da6f40b2640d6ebc9eec225/docs/js/tiles.js#L190-L200 Note that getDownloadContent filters invisible objects and interaction components from the diagrams.

[jo-pol]

The problem for touch devices is the href being set and cleared dynamically at onfocus and onblur. When set permanently it works as desired.

A Droste pair diagram can easily use several MBs. Not sure having all diagrams permanently twice on the page requires too many resources. However, that is not the worst problem.

During a slow animation a download currently produces a snapshot of the actual animation phase. Try for example gw-A2 and click the last wand (you can skip the first level). You might have to tell your browser several times to continue the script before even the first animation step is shown.

A by-catch of this test: the animation stops too early, the pattern has not unfolded enough. We might also need a wand per diagram, rather than per Droste level.

Updating the href at each step would slow down the process even more. Updating only at the last step however, would cause not expected behavior for the user: empty downloads. A third party demo shows the end result appears much faster when not rendering the steps. However, it would also take much longer to see the diagram appear at all, making users turning away. Rendering every n-th step could be a compromise. This approach is actually applied for mobile devices, as far as recognized, assuming they have less computational power.

@d-bl/gf opinions or other suggestions?

[jo-pol]

What about a two-stage process? Clicking the icon prepares the link which is then made visible like the legends. When that link is clicked you get the actual download.

Perhaps this two-stage process should only kick in with a tap event while a mouse-click event directly starts the download. Not sure I can find the tricks that doesn't mix up these events (technical details)