-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Two-up / one-up mode UX issues #338
Comments
@mialondon : the user can also (and probably will) click right on the viewer and "save image" rather than looking for a button that says "save". It will be saved as "download.png". That is standard behaviour for canvas elements in HTML. Try it with two-page view. UV provides IIIF compatible links to slices of one image. IIIF does not have support (yet?) for combining two images. @edsilv : for the current view image, why not simply copying the canvas data, and provide it to download? |
@nicolasfranck yep, we've thought about using the canvas api. This would limit the downloaded image to quite a low resolution though. I asked @tomcrane if he could raise a question with the IIIF editors group regarding whether the image api could support requests for multiple image segments and return a combined response. It would be good to officially rule this out before attempting a client-side solution I think as other viewers may require this functionality. cc @azaroth42 |
@nicolasfranck we suspect that our readers won't typically think to right- or control-click to download an image, which is one reason why a 'download' button is important. |
Combination of multiple images into one (or more) is currently outside of the scope of the Image API. The API is resource based -- there's only one slot for the "identifier" of the image. However ... a "stitching" service would also be very valuable that sat on top of the IIIF Image API, that you could pass a description of the images to, and it would then construct a new Image API endpoint. This seems like an interesting use case for REST/server management, as it doesn't involve sending new image content, just the creation of new identifiers that then do the math on where the image content comes from. Could we take this to iiif-discuss for more brainstorming? |
We'd have to make it clear somewhere in the manifest whether this was available for a viewer to use (a service with a stitching profile at the root level?) Static "level 0" image services should be able to provide a stitching user experience too. This would have to use the canvas API, so maybe it's overkill to expect everyone to implement a stitching service on the server side? |
Does it need to a local service? Couldn't a hosted service handle the work D On Wednesday, 13 July 2016, Edward Silverton notifications@github.com
|
--> iiif-discuss please? :) |
While it's being considered on iiif-discuss, a possible solution discussed at the BL is to trigger two downloads in the browser, one for each image canvas. It might be a bit clunky but it's possibly the last clunky option while stitching is being discussed, and better than asking the user to adapt to the software model and switch between modes. |
You can see a version of this in action at http://universalviewer.io/examples/?manifest=http%3A%2F%2Fapi.bl.uk%2Fmetadata%2Fiiif%2Fark%3A%2F81055%2Fvdc_100022545251.0x000002%2Fmanifest.json&locale=en-GB#?c=0&m=0&s=0&cv=2&z=0%2C-163.2381%2C5004%2C3701.4761 if you click 'download' white in two-page mode - it should open two new tabs, one for each image. Whether people will realise that's how it works is another question! |
Fixed by 44b4ee6 |
So far our usability tests have shown that people expect a 'download' function will result in a file having been downloaded and stored somewhere on their system (downloads folder, desktop, etc). Opening the images in a tab for potential download is good but only gets us part of the way there. I'm re-opening this for discussion, not because further development work is required in the next BL sprints, because triggering the 'open or save as' dialogue might work for single page images, it appears it doesn't easily work for two. In general, there's a tension between the ideal IIIF standard and the reality of implementing software to be used by real people for whatever work or leisure purposes that emerges around issues like download. |
Opening multiple windows in Chrome is disabled by default, so it does not work in that browser. Only the first image opens in a tab, and the second is ignored (it does not even show a warning in the log). |
@DavidWaldock did you see @nicolasfranck 's comment? Something of a spanner in the works! |
It was always a temporary fix, but I'm surprised that hasn't come up before. D On Tuesday, 20 September 2016, Mia notifications@github.com wrote:
|
@edsilv where did we get to with this? There are currently different options in one-up/two-up view on http://bltesters.azurewebsites.net/?manifest=http%3A%2F%2Fapi.bl.uk%2Fmetadata%2Fiiif%2Fark%3A%2F81055%2Fvdc_100022545251.0x000002%2Fmanifest.json&locale=en-GB#?c=0&m=0&s=0&cv=0&z=-1029.8196%2C0%2C4562.6392%2C3375 |
From the last Fluent usability tests: The difference between the download options is not always clear. Consider communicating the differences between resolutions and the ability to select pages for download more clearly |
Please don't forget that there should be a Download TITLE (pdf) link too as this implementation was paid for by NLW. See https://journals.library.wales/view/2104777/2104983/#?xywh=-1582%2C-171%2C5141%2C3391 |
@LlGC-szw Does that service behind that link gather all images in a single Manifest and generate a PDF containing them all? I guess that service is NLW-created, not inherent in the U.V.? I was considering building a similar function as a Flask app that could be called, would love to learn more about the NLW service, if possible |
@LlGC-szw The download menu will keep all of the same options, just with the extra ability to specify which page. |
That's how it works at the British Library. The folk who created it are long gone but I could ask the current team if they could share. |
Yes please @mialondon that would be smashing, though I think I know at least one of those departed folks, if not... |
Hi we generated a pdf for each article on our journals site (https://journals.library.wales/home) and added a link to them in the manifest via the rendering section. This then gets picked up by the UV. "rendering": { |
The user should not have limited functionality re download, print, etc because of the page view style they have chosen.
As @jennpb said on #142 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.
See also @edsilv #142 (comment)
The text was updated successfully, but these errors were encountered: