Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add download links for current canvas #983

Closed
10 tasks done
ggeisler opened this issue May 16, 2019 · 9 comments
Closed
10 tasks done

Add download links for current canvas #983

ggeisler opened this issue May 16, 2019 · 9 comments
Assignees
Labels

Comments

@ggeisler
Copy link
Contributor

ggeisler commented May 16, 2019

Part of #981. Assumes the work in #982 to create the dialog is done.

  • Assuming the current canvas has an image associated with it, the first heading under the "Download" heading should be the label of the current canvas, truncated if necessary to keep it to a single line. It should use h3 typography.
  • The actual download options under the canvas label heading are links that use body1 typography.
  • Links should open in a new window (or start a download in the background, depending on browser behavior for the resource type; key is that nothing about the viewer context changes when the user selects a link).
  • If the current canvas is zoomed beyond 100% of full-size, display a "Zoomed region (xxxx by yyyy)" link with the zoomed region pixel dimensions (width by height).
  • The first "Whole image (xxxx x yyyy)" is the full-size canvas image listed by its pixel dimensions (width by height).
  • The next "Whole image (xxxx x yyyy)" is the image resized proportionally to have a width of 1000px. Only display this link if the full-size image is more than 1000px wide.
  • Separate each link with a divider, similar to the bottom border used in the annotation and ToC panels. The first link in each section also needs a top border to match the layout in the mockups.

Example: Canvas open with no zoom

Screen Shot 2019-05-16 at 1 27 48 PM

Example: Canvas open and zoomed

Screen Shot 2019-05-16 at 1 08 17 PM

Example: No-download object

I think we're already doing this with the current SUL-embed, but just as an example of another variation, if the object is a no-download object we'll need to adjust the links so that we only offer options that are 400px on the long side:

Screen Shot 2019-05-16 at 3 34 39 PM

(There might be other implications based on the authentication UI design that is TBD.)

Book view

In book view there are usually two images displayed side-by-side, so when in book view, the download dialog should follow the same approach as with the single canvas view described above, but should do so for each of the two canvases show in the view.

  • First display the left canvas label as an h3, and then include links for zoomed region, full-size whole image, and 1000px width version of the image, as applicable.
  • Display the right canvas label as the next h3, and follow the same guidelines as above for the other links.

Example: Two canvases shown in book view, not zoomed

Screen Shot 2019-05-16 at 1 32 45 PM

Example: Two canvases shown in book view and zoomed

Screen Shot 2019-05-16 at 1 33 00 PM

Gallery view

Only one item can be the current item in gallery view, so the download action should treat that item as the canvas image to download.

  • Follow the same guidelines as in the the first section of this ticket for the first and second "Whole image (xxxx x yyyy)" links; the "Zoomed region (xxxx by yyyy)" link is not applicable in gallery view.

Example: First canvas of object selected in gallery view

Screen Shot 2019-05-16 at 1 41 42 PM

@cbeer
Copy link
Member

cbeer commented Jun 3, 2019

The next "Whole image (xxxx x yyyy)" is the image resized proportionally to have a width of 1000px. Only display this link if the full-size image is more than 1000px wide.

The goal here is to provide a reasonable sized version of the image? I wonder if we should also constrain the height (thinking of things like piano rolls or other items with extreme aspect ratios..).

@ggeisler
Copy link
Contributor Author

ggeisler commented Jun 3, 2019

@cbeer:

The goal here is to provide a reasonable sized version of the image?

Yep, exactly.

I wonder if we should also constrain the height (thinking of things like piano rolls or other items with extreme aspect ratios..).

Yeah, if we can also constrain the height to a max value, that would be great. An example piano roll at 1000px wide is still 95537px high, which is four times smaller than the original but still not really a practical improvement.

I'm a bit unsure of what to suggest for the max value, though. Something like 5000px max height seems good for the piano roll example; it would produce a roughly 50px wide image, I believe, which seems potentially wide enough to be useful, and I think a 50px x 5000px file might be small enough in file size to be reasonable to download?

But you could have a worst case of 1000px by 5000px. Not sure how big a file that would produce. What do you think? Something in the range of 3000px to 5000px as a max height seems okay to me, especially given this situation is not going to happen very often.

@jkeck
Copy link
Contributor

jkeck commented Jun 3, 2019

@ggeisler: I feel like Zoomed region for Book mode is going to be problematic. I could be zoomed into the page on the left (and not see the page on the right) yet need to generate a link to the visible area of a canvas that isn't actually visible at all...

@ggeisler
Copy link
Contributor Author

ggeisler commented Jun 3, 2019

@jkeck You mean problematic in the sense that in the scenario you gave (user is zoomed in on left page but sees zoomed links for both pages in their download options) the user will see a link to a zoomed image not currently in view, correct (as opposed to problematic in terms of generating the correct links)?

@jkeck
Copy link
Contributor

jkeck commented Jun 3, 2019

Both could be potentially problematic. I'm not sure what the expected behavior should be for various book scenarios.

  • If I'm zoomed into the binding, should I be getting the visible parts of both pages as the links (e.g. I could stitch together the same image I see in the viewer with both images).
  • If I'm zoomed into something on the left of the left image (and the right isn't visible), should I be getting no link for the right-hand section, should I be getting a region that matches what I'm seeing on the left side, but on the right side (which would seem to be at odds w/ the point above if that was the case).

In either case, I think the maths may get tricky, but I won't know how tricky until I know what the desired behavior is.

@ggeisler
Copy link
Contributor Author

ggeisler commented Jun 3, 2019

Okay, let's see if we can settle on a desired behavior and then you can evaluate if it is technically feasible or not.

Based on this part of your response above:

If I'm zoomed into the binding, should I be getting the visible parts of both pages as the links (e.g. I could stitch together the same image I see in the viewer with both images).

I'm wondering: is it potentially feasible to always provide one download link to what's visible in the zoomed area if book view, regardless of whether the zoomed area includes part of the left page, part of the right page, or as in your example, parts of both pages? In other words, could you stitch together a single image even though the canvas contains zoomed portions of two separate images?

If so, I think this might be the ideal behavior when zoomed in book view. I believe our main concern is supporting the user who might have zoomed into a view, using book view, where there is relevant information on both pages that that user wants to save (e.g., some sort of illustration or marking that spans both pages), and forcing the user to replicate the zoom level for both pages individually in single-page view would mean more (somewhat tedious) effort. So if it is potentially feasible to create a single downloadable image of whatever is visible in book view, I think that would be a fine alternative to the original proposal for separate download links for each page in book view.

@jkeck
Copy link
Contributor

jkeck commented Jun 3, 2019

Hmmm, I don't know of a good way off the top of my head, and I don't know how robust/performant a client-side library would be for this sort of thing. Perhaps that's worth spinning out into a separate issue? (and I could remove the link in Book view for the time being)

@ggeisler
Copy link
Contributor Author

ggeisler commented Jun 4, 2019

Sure, sounds good to me. Do you mind creating a new issue to track this, since you could probably toss in some technical details to help us remember the potential technical concerns?

@jkeck
Copy link
Contributor

jkeck commented Jun 8, 2019

Other tasks spun out into separate issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants