Last revision: June 13, 2017, JHT DRAFT FOR WIKI
NOTE: This document is being supplemented with a spreadsheet that lists each "gap" or "feature" that needs prioritization. See: https://docs.google.com/a/harvard.edu/spreadsheets/d/1jyQAaNQ3oKVw4qbuMfysxoJPMXDAvEDL2b3HgPkHypY/edit?usp=sharing... The spreadsheet is a bit easier to digest, though the information below may provide more context or explanations for why the gaps/features were requested by stakeholders.
Image Delivery Service
Page Delivery Service or
Harvard Library Viewer
An important theme to come from discussions with stakeholders is that patrons need a consistent user experience across IDS and PDS because they do not differentiate between the item types such that they would expect images and ordered images to be delivered in different systems. Following that logic, below is an evaluation of the content and functions that Mirador would and would not provide if used as an IDS replacement.
In DRS2, the image files are part of the larger context of a still image object content model. The new IDS should take advantage of the additional features potentially made possible through the relationship of the image file and its object, especially the existence of descriptive metadata. Configurable display of metadata would be desirable. The image delivery API syntax should allow the repository to choose which fields to display and or not. If it is flexible enough, that should address the potential problem of a metadata mismatch (where IDS displays metadata in a larger context of a system that draws on metadata sources other than DRS). Some specific settings would include whether or not to display a METS label or MODS-based label as well as some technical metadata fields. Mirador provides opportunities to display metadata, but not all identified use cases need or want metadata from the DRS. The display of metadata should be configurable.
In the upper menu of PDS, the Print/Save menu item opens a modal window that provides printing options including converting pages to PDF for printing – the current page, a user specified range of pages, or the entire document. The user can also display the current page as an image with the full caption. Maybe the PDS modal could be adapted for use by IDS and provide options for downloading the IDS image, including information that would help the user make informed decisions about which option to choose.
Question: what options are currently available and what options should be available?
For example, Universal Viewer has a menu that displays all available versions of an image for download, including the file format and file size:
Image format can be an issue for download, because many users cannot open a JP2 or even a TIFF. Repositories are having to send out instructions or they save the image as a JPEG before sending it to the requester. If IDS provides downloading, it should include a format that can be opened without special software.
When printing an image from IDS, the citation should be appended as it is in PDS. Note: PDS has a repository and local identifier, not a citation. Which is preferable?
...the stakeholders agreed that some sort of scale indicator is important in the delivery system. While the descriptive metadata can, not always, provide accurate dimensions of the original analog item, it is insufficient when viewing a digital surrogate, particularly with zoom functionality.
Your note about pixel dimensions may refer to one approach to providing a scale to the user. All images have technical information regarding the number of pixels and the capture resolution, which can be used to calculate the original size of the item.
Ex. Image has 2282 x 2925 Pixels, divided by a capture resolution of 300, yields an original size of 7.61 in. x 9.75 in. So the user would know the actual size of the analog item no matter whether he/she is zooming in or out
This may not be possible with any of current option, but should be considered in the future.
Other options should be considered, including a dynamic % magnification when zooming, a ruler, etc., so that the image viewer provides the user with the scale/size rather than resorting to some workarounds that have been implemented over the years. For example some repositories have required a ruler in the image capture to provide context of size, but by doing so, it does complicate other uses of the image where you would not want this ruler to appear (i.e. printing)
I noted this specific need from Project Mirador Roadmap