Harvard Wiki has been integrated with Group Services.
Wiki administrators: visit IT Help for an overview of the changes to managing groups in your wikis.
Skip to end of metadata
Go to start of metadata

User Interface Inventory and Prioritization of Gaps

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.  

Technologies

 

IDS

Image Delivery Service

http://ids.lib.harvard.edu/ids/view/2979370?buttons=y

PDS

Page Delivery Service or

Harvard Library Viewer

https://iiif.lib.harvard.edu/manifests/view/drs:7294899$1i

Generic Mirador

IIIF viewer

http://projectmirador.org/demo


Goal

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.  

Quick list of what Mirador provides out of the box

  • ü  Zoom: using icons, the mouse’s scroll wheel, and keyboard commands.  Mobile pinching supported.
  • ü  Pan: using icons, click and drag, and keyboard commands.  Mobile click and drag supported.
  • ü  Rotate: using icons.
  • ü  View: reset to initial view, full screen mode.
  • ü  Interactions: preliminary testing suggests that PDS and Mirador work with different screen sizes and expected interaction methods.
  • ü  Image comparison: ability to place multiple images side by side

Display of descriptive and technical metadata

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.  

PRIORITIZATION

  • USE CASES
    • Use case 1 (separate tab) and 2 (embedded): full interface with all the branding, content, and functions
    • Use case 1 and 2: “full” interface with configurable branding, content, and/or functions
    • Use case 3: image display without controls
    • Use case 3: possible re-envisioning of this use case to include image controls and other configurable elements
    • Use case 4: similar or related content delivered through PDS and IDS (e.g., maps that are presented both as images and as part of atlases)
    • METADATA
      • Descriptive….
      • Technical….

 

Saving, downloading, and printing

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?

PRIORITIZATION (save/download/print)

  • File size
  • Pixel dimensions
  • File type/format
  • Alternative formats
  • Portion of image
  • URL to embed viewer/image

Requested content and functions that not available and are in need of prioritization

  • The color profile needs to be downloaded with the image, this has been an on-going problem for the museums.  After being downloaded, the images display incorrectly because the color profile isn’t available.
  • Currently, DRS only supports the RGB color space for JPEG2000 images.  Some Harvard repositories are using other valid color spaces, such as YCC, so they have to then transform/retrofit the image for deposit into DRS.  DRS needs to support more than just RGB.
  • The Map Collection receives many requests for high resolution versions of images from its collection.  The requests are often for a part of an image rather than the entire image.  Frequently, the requests are for embedding that portion of the image, so being able to specify part of an image and then embed that elsewhere would help Maps.
  • Repositories have different policies regarding the download of full resolution images, even when those images are not restricted.  Some repositories want all requests for those files to go through the DIG.  For other repositories, the occasional requests are easier to handle on a case by case basis – often fulfilling requests locally.  Those repositories may wish to make all or some unrestricted full resolution images available for download by the end user so that the repository does not need to mediate.  There appeared to be agreement on the idea that all unrestricted content should be assigned a single policy and that each repository should be able to change that setting for its images based on their local policies.  For example, we may decide that all unrestricted images are by default downloadable, but the Law Library should be able to mark some or all of its unrestricted images as NOT downloadable.
  • Ability to associate actionable geospatial coordinates is desirable.  Or, at least listing the coordinates associated with a raster image. 
  • The Law Library is working with ALTO (XML) data for simulated highlighting of raster images.
  • IDS needs to provide rights information (I think the implication was also that the information needs to be human readable).  Library of Congress handles this well.  Found these two examples:

Follow-up questions that linger

  • Language support: will IDS and PDS both support Unicode? Also, DRS and delivery systems need to support right to left scripts.  For PDS objects, that includes sequencing in the other direction.  For IDS, if we display metadata and that metadata is in an RTL language, it should display properly.  Randy seemed to believe that this would require a change to the DRS data model that would indicate RTL/LTR. 
  • Original notes from stakeholders meeting included indication of scale, but I needed some clarification.  Here is more information from Todd Bachmann:

    ...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

    • Dynamic ruler. Image and page-turn views will include a virtual ruler. The units of the ruler will be set by size information presented by the IIIF APIs. If no size information is available, the user will be able to enter height, width and units to generate an appropriately scaled ruler. This is similar to Mirador 1.0  https://github.com/ProjectMirador/mirador/wiki/Roadmap

 

  • No labels