Developer for Archives Public User Interface

Description

Request for Proposals

Project Title: Archives Public User Interface and Digital Object Viewer 

Hauser & Wirth Institute requests proposals from developers to build a custom public user interface that extends the capabilities of the ArchivesSpace PUI. 

Purpose and Objectives of the Project

As part of its program to process artists’ archives and make them accessible, the Institute is undertaking a project to develop a public user interface to deliver digitized archival content to the public. As part of its processing of artists’ archives, HWI plans to make an initial 18,000 image files, as well as streaming media, accessible to researchers, and allow for ongoing future access to online content as the HWI program grows. The Institute plans to make the descriptive metadata and the digitized images accessible for use both by researchers familiar with archival finding aids, and by a general audience more familiar with a typical digital library application (e.g., Google Books).

HWI uses the web-based archives information management system ArchivesSpace, hosted by Lyrasis, to describe the collection using standard practices. The Institute digitizes archival materials corresponding primarily to folder-level “archival object” records in ArchivesSpace, and is committed to repurposing this archival metadata as a practical and efficient approach to publishing large amounts of images online for the broader public. Digitized content follows filename conventions that will allow them to be matched to the ArchivesSpace records we create. 

Our expectation is that both experienced scholars who rely on standard finding aids, and a general public more used to a typical “digital library”, may be served by a single public user interface. To achieve this, we are looking for a developer to 1) create an ArchivesSpace plugin that extends the built-in ArchivesSpace public user interface and search index, as well as 2) an ancillary digital object rendering service that can provide an image-viewer (which will be embedded in the public user interface). We will favor proposals that provide a solution that will allow us to store and serve large format image files with minimal maintenance; a hosting plan is not required but will make a proposal stronger.

About Hauser & Wirth Institute 

Hauser & Wirth Institute is a nonprofit, 501(c)(3) private operating foundation dedicated to art historical scholarship and to the preservation and accessibility of artists’ archives.

Under the guidance of its Board of Directors and Advisory Board, the Institute was established to:

• build a public study center for artists’ archival materials in New York City and make these resources available for primary document research and digitally online
• nurture innovation and substance in art historical research primarily through the funding of fellowships in partnership with academic and archive-based institutions
• produce online catalogues raisonnés and print publications that advance the highest academic standards to strengthen the field of art history
• initiate programs to inform a public conversation about the obligations and opportunities inherent in archive stewardship

Project Requirements

1. Customized public user interface for viewing archival data and digital objects. 
   1. The interface must support research by presenting the collection as a structured tree of metadata and inline visual representations ("embedded digital objects") - i.e., as an online "finding aid" allowing researchers to go up and down a hierarchy and view / expand object representations in the context of this intellectual arrangement. This should be achievable through customizations of the ArchivesSpace public user interface, most significantly with the addition of expandable embedded digital object players (see below).
      1. User can peruse the entire archival collection using the scrolling idiom and structure of traditional EAD finding aids, as with the current ArchivesSpace public user interface. Scrolling may be replaced with collapsing / expanding navigation - see Smithsonian Archives of American Art site.
   2. The interface should also support browsing by generalists and researchers who are unaccustomed to archival arrangement and primarily interested in viewing digitized material. In other words, the interface should function as a "digital library" of digital objects that can be browsed, searched, and viewed ("play", "rewind", "turn page", etc.). It is expected that the search functionality can be powered by the existing ArchivesSpace Solr index with minimal customization, and that "Digital Objects" would be added to the top-level navigation in the public user interface. A user clicking on "Digital Objects" would see a grid of visual and text search results (thumbnail image, title, etc) and would be able to search / filter these. Customizations to the ArchivesSpace indexer may be required to enable searching on these digital objects using folder and item-level metadata.
   3. Digital object viewer(s) requirements
      1. Digital objects must be viewable inline in the "research view" (1.1) and as individual objects (pages) in the "digital library view" (1.2).
      2. Viewer must support a variety of digital objects: photographs, notebooks, videos.
      3. User can page back and forth between sequential images within a digital object representation of a bound item (e.g., a notebook).
      4. User can use zoom and pan controls to examine individual high resolution images. True zooming will require an image server which can dynamically serve “tiles” of an image at different resolutions as the user pans and zooms. An IIIF-compliant server and client library are recommended.
      5. User can play / stop digital object representations of moving image objects (e.g., video).
2. Auto-Populating Digital Object Records
   1. In addition to developing the public user interface and digital object viewer, the contractor will need to auto-populate digital object records in ArchivesSpace, and auto-link digital objects to archival object records (either folder or item level, depending on the object type and the granularity of description).
      1. Photographs / documents. There will be 1 digital object record for each digitized photograph or document (approx 18,000). A digital object record representing a document may correspond to an item-level node in the intellectual hierarchy, or several may correspond to a single folder. (I.e., some items will be individually cataloged, while most will be cataloged at the less granular "folder" level.)  Both scenarios should be supported. A search in the "digital library" on metadata from a folder-level description should return all the photographs in the folder. In the "finding aid" view, it should be possible to expand or overlay a viewer showing all the photographs in a folder.
      2. Notebooks. There will be 1 digital object record for each digitized notebook (currently approximately 15 notebooks, 800 pages total). A digital object representing a notebook may correspond to a folder or item-level node in the intellectual hierarchy. A notebook should appear as a single item in the digital library view, and as an expandable or modal overlay in the finding aid view.
      3. Video / audio. There will be 1 digital object record for each digitized video or audio file (number of files TBD). As above, the video should be playable from the finding aid view, and should appear as a single object in the library view. 
3. Ongoing digitization
   1. Responses should include a plan that will allow for future digitization and publication of additional digital objects. At a minimum, project deliverables should include documentation clearly explaining how additional batches of content can be processed into digital objects and digital object records.
4. User Interface and Graphic Design
   1. Responses should include wireframe sketches showing the basic page layout for the finding aid view with expandable embedded digital objects, for the digital library search results, and for digital objects as stand-alone resources within the digital library view.
   2. Responses including graphic design treatments (color palette, fonts, etc.) are welcome, but separate responses for design and development are expected and acceptable.
5. Non-functional Requirements
   1. The viewer should be built using open-source tools and software libraries, and a language (e.g., Ruby, Python) and framework (e.g., Ruby on Rails, Django) should be chosen with consideration for breadth of adoption, ease of maintenance, and alignment with best practices and patterns within the cultural heritage community. All things being equal, a framework written in Ruby, Python, Javascript, or PHP would be typical. Given the choice of Ruby and Javascript by ArchivesSpace, these languages ought to be preferred if possible.
   2. The viewer should be easy to deploy on a commercial application hosting service - or, alternatively, embeddable in the ArchivesSpace plugin.
6. Project management and plan of work
   1. Responses should include a high-level plan of work and project timeline.
   2. Responses should include a project management plan which includes multiple iterations based on client feedback.

Timeline

September 20: Proposals are due

October 4: Developer is selected and notified

October 15: Work begins

December 15: Delivery and demonstration of working code meeting all project requirements

Hard Finish: March 15, 2019 

Instructions

RFP Contact Person: Lisa Darms, Senior Archivist

info@hauserwirthinstitute.org

All inquiries questions should be sent via email to the RFP contact --  no phone calls will be accepted.

The deadline for proposal is 11:00 P.M. Eastern Time on September 20, 2019. Proposals must be submitted electronically to the RFP contact person listed above with a subject line of “RFP – 2019”. Proposals must be Adobe PDF or Microsoft Word documents.

Proposal Requirements

Proposals should include the following

1. Relevant experience with ArchivesSpace, Solr, and online finding aids.
2. Wireframes showing 1) collection of digital objects presented as a digital library 2) presentation of a digital object with controls for IIIF image interactivity 3) presentation of digital object inline as part of the finding aid view
3. Proposed technologies (language, framework, etc.)
4. Strategy for serving digital objects, esp. tile-based hi-res images. 
5. Project management plan. 
6. Work plan and cost.
7. Itemized list of deliverables.
8. Separate / optional maintenance plan and cost, including cost of hosting and serving digital objects.
9. Examples of relevant former projects and/or references from former clients.

Conditions of the Project

Vendor is responsible for the contents of its proposal and for satisfying the requirements set forth in the RFP. The vendor is expected to comply with the true intention of this RFP and shall not take advantage of any errors or omissions in the description of the requested services. The successful vendor and all subcontractors hired by them must comply with all applicable laws. 

Cost of Preparing Proposal 

The cost of developing and submitting the proposal is entirely the responsibility of the vendor, including costs related to preparing and submitting the proposal, negotiating a contract, and other costs associated with the RFP.

Preparation of Proposal

HWI has the right to rely on any information and price quotes provided by vendors. The vendor shall be responsible for any errors in quotes.