Larger download menu

[edsilv]

Ability to transition between pages with next/prev buttons. Partition download options into image level and document level?

[edsilv]

https://drive.google.com/file/d/0B64TWB9qdiOMTVp0N1V1d0FvQTQ/view?usp=sharing

[demiankatz]

The mockup looks like a good start to me, though is the intent that we use actual thumbnails in there? Also, it doesn't account for the ability to switch pages noted in the original issue description. I'm also a little concerned that this won't scale well for Villanova's use case, where we have a LOT of options at the page level (OCR, technical metadata, etc.), but maybe that's just a local problem here.

[andyjmaclean]

use canvas api? https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL

[tomcrane]

Hi @mialondon, @davidwaldock, @jennpb

This is relevant to BL and Wellcome UX issues for improving the download menu

2 page version of the download dialogue mentioned above

https://universalviewer.slack.com/files/edsilv/F0A44AL2F/download2.jpg

[tomcrane]

(the top icon in this dialogue would be a visual representation of the current viewport)

[jennpb]

Also relates to #277

Some initial thoughts:

• Download current view as one-page only feels stingy; users shouldn't have to understand why images can/cannot be stitched together to form a 2-page view.
• That said, we don't have enough data to indicate whether a 2-page download is an edge case.
• The icon indicating download hi/lo res doesn't really fit the scenario. It seems a visual indication that I've selected the left-hand page of a 2-page spread
• @mialondon and I haven't resolved the issue of 'high res' 'low res' wording. In early testing we found that users didn't understand the difference (and we definitely shouldn't be shortening the word to 'res'. But this is in config, so no big deal for now.
• Would need to deal with all potential download scenarios, as @demiankatz noted above.

[mialondon]

+1 for @jennpb @demiankatz on dealing with additional download scenarios. Is there value in grouping between text formats (plain text OCR or crowdsourced transcriptions, ALTO files, PDFs, etc) and image formats (current view, whole page, possibly two-page view)?

Also +1 @jennpb on not making people have to understand why two-page view isn't a thing (or not putting the geek horse before the reader cart)

Overall, adding visual cues to the download menu is a positive step.

[mialondon]

For reference, there's also some discussion of download in the document @jennpb and I wrote on UV UX / British Library and Wellcome Library

[edsilv]

The UV's current setup where you have to switch to single-up mode to download current view is because there is no back-end capability at present to support this. It's a technical limitation, and by no means the desired UX - far from it. As discussed yesterday, even if the UV could call a custom back-end script to generate the desired stitched-together image, this is problematic as it's a non-standard use of the IIIF image API. We can't expect all UV-deploying organisations to support it. My feeling is that this use case needs to be "promoted" to a IIIF spec editor discussion. Perhaps @tomcrane could champion this?

Here is my go-to example of maximum download options:

http://universalviewer.io/examples/?manifest=http%3A%2F%2Fdigital.library.villanova.edu%2FItem%2Fvudl%3A30471%2FManifest

We have already done away with the 'high/low res' terminology. Relying instead on the configured confinedImageSize property of the download dialogue for the 'low res' and max image dimensions in the info.json for the 'high res'. If the advertised max dimensions are in fact smaller than the configured confinedImageSize, the 'low res' option is hidden.

As you can see, they are already grouped by type with 'image-level', 'canvas-level', and 'sequence level' options.

Ideally, we'd always just have a 'current view' option regardless of paged mode being enabled. I believe that this requires a technical solution and that any UX solution would not be treating the underlying cause.

It may turn out that we have to implement a technical solution on the client side using the canvas API to generate the image, but I'd like to rule out the back-end solution first, as this may be a desirable capability for other viewers, not just the UV.

[mialondon]

'Screen quality' or 'print quality' might work for some users, but image sizes vary so much that that's probably not accurate enough - testing might help here. 'Smaller' and 'larger' image might be the simplest option? There's an option to include the pixel size (e.g. '2569 x 3543px (jpg)', '1000 x 1379px (jpg)') but I don't expect every reader to be able to translate that into a meaningful measure.

FWIW I asked internally, and people from electronic services suggested labels for 'large' or 'medium' as on Google Images. One problem with this is that large and medium are very relative and liable to assumptions based on particular contexts.

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.

[mialondon]

This issue has had considerable scope drift but some of the UX issues discussed are still relevant. I'd suggest reviewing it and moving outstanding items into their own issues for resolution.

[demiankatz]

Thanks, @mialondon. I suspect that most of this has been addressed by the new download panel, but definitely might be worth reviewing to see if any details still need to be captured.

[mialondon]

Thanks @demiankatz ! Is there somewhere I can see the new download panel in action?

[demiankatz]

@mialondon, yes, just go to https://uv-v4.netlify.app/, put the viewer into "2-up" mode, and go past the first page of the document so that there are two pages displaying on screen at once. Then, when you open the download panel, you can pick which of the visible pages you are downloading.

[mialondon]

Thanks! It looks like download options and their labelling is quite dependent on individual manifests? I love the Villanova options https://uv-v4.netlify.app/#?c=&m=&cv=2&xywh=-97%2C0%2C4513%2C3055&iiifManifestId=https%3A%2F%2Fdigital.library.villanova.edu%2FItem%2Fvudl%3A24299%2FManifest

[demiankatz]

@mialondon, that is correct: many options in the download dialog box are powered by "renderings" specified in the manifest. It gives a lot of flexibility, but at the cost of consistency. (But of course, this approach is a necessity: the Universal Viewer can only know about download options if the manifest tells it they exist). :-)