Some special collections libraries and archives have multiple reading rooms. Some institutions have multiple special collections and archives in different buildings. Some institutions participate in a consortium that may wish to provide its users with a common means of accessing the various special collections and archives held by the consortial partners. Because it is highly customizable and scalable, Aeon can be configured to meet the user access and staff workflow needs of any situation.
Aeon offers two distinct installation options:
- Multiple Service Points: several service locations/reading rooms share an Aeon web server and installation of the Aeon database software.
- Common User Database: each service location/reading room has its own Aeon web server and transaction database configured to its specific workflow needs.
A multi-site implementation can include any combination of these installation options. Atlas will work with you to determine the configuration that will best meet your specific operational needs.
Option 1: Multiple Service Points
Institutions that want to integrate the operations of multiple special collections and archives reading rooms or service locations might find that a shared Aeon web and database server installation offers certain functional advantages at a lower cost and lesser need for local IT support. With a Multiple Service Points installation, users log in to submit and monitor their requests through a common web interface. The staff at the respective service locations view and manage only those requests that pertain to their collections while sharing common workflow options.
Advantages
- Lower annual maintenance cost
- One annual software licensing subscription and implementation fee covers all service locations.
- If Atlas server hosting is selected, only one hosting fee is required. If the institution chooses to host the Aeon software locally, it only needs to provide hardware and IT administration to support a single Aeon web server and database instance.
- The need for local IT support is minimized because customization options are more limited.
- Patrons can enjoy the convenience of being able to submit and monitor their requests through a single web account, regardless of whether they place requests with one service location or several.
- Although many configurations and customizations are shared, each service location can maintain its own electronic visitor log.
Limitations
- All service locations share a common set of user registration forms.
- Separate web request forms can be created for each service location, but they must be integrated into a common web interface that is shared by all locations. Because the web interface is shared by all sites, all sites share the same web styling and a common set of web form validation rules, default values, status and error messages and automated session timeout setting. In addition, there can be only one set of “web alert” messages and RSS feeds.
- Certain settings in the Aeon Customization Manager must be shared by all sites; these include:
- Outgoing email server (i.e., there can be only one outgoing and “reply-to” email address)
- Default local contact information
- Remote and local authentication configuration options
- User expiration settings
- User request limits
- Other settings in the Aeon Customization Manager can be configured to include customized settings and forms for individual sites, however, all options will appear in the Aeon Staff Client and so must be labeled accordingly in order to distinguish their application; these include:
- Custom queues and routing rules
- Callslip and other printed form templates
- Email templates
- Cancellation reasons
- EAD/XSLT stylesheet transformations and “group by” settings
- Z39.50 catalog connections
- Photoduplication billing contexts and payment gateway
- All collaborative “Activities” will appear in all staff clients (i.e., it is not possible to set up “Activities” that are visible only to individual locations).
- All locations must upgrade Aeon Staff Clients at the same time to keep them properly synchronized when the Aeon database software is upgraded.
Option 2: Common User Database
Institutions and consortia that want to provide each of their special collections and archives site the greatest degree of independence and flexibility might consider licensing and installing the Aeon web and database server software individually for each site. In such cases, it is still possible to enable users to sign into their accounts with the same username and password, and for all sites to share a common user database.
Advantages
- Each site creates and maintains its own patron registration forms and web pages and can establish independent web styling, web form validation rules, default values, status and error messages, and automated session timeout setting. Each site can also create its own set of “web alert” messages and RSS feeds.
- Each site maintains an independent electronic visitor log.
- Each site can create its own unique settings in the Aeon Customization Manager. These customization settings include:
- Outgoing email server (i.e., each site can have its own outgoing and “reply-to” email address)
- Default local contact information
- Remote and local authentication configuration options
- User expiration settings
- User request limits
- Custom queues and routing rules
- Callslip and other printed form templates
- Email templates
- Cancellation reasons
- EAD/XSLT stylesheet transformations and “group by” settings
- Z39.50 catalog connections
- Photoduplication billing contexts and payment gateway
- Each site can create and maintain its own set of collaborative “Activities.”
- Each site can also have multiple service points as described under Option 1.
Limitations
- Higher annual maintenance cost
- An additional annual software licensing subscription priced at the next lowest pricing tier is applied to each additional site until a site license cap is reached; Atlas will determine a licensing cap based on the overall size of the institution or consortium.
- An additional one-time implementation fee is applied to each additional site to cover site-specific configuration and training.
- If Atlas server hosting is selected, an additional hosting fee (equal to one-half of the standard hosting fee) is required for each additional site with no limit or cap. If the institution chooses to host the Aeon software locally, it must provide sufficient hardware and IT administration to support each Aeon instance.
- The potentially greater need for local IT support to create and maintain customization for each individual site; initial configuration of automated OpenURL and EAD requesting may also require more effort to accommodate multiple sites.
- Potentially confusing or burdensome for patrons who may use one or more of the institution’s special collections libraries or archives since they will have to use a separate web account to submit and monitor requests placed at different sites.
- All sites should upgrade their Aeon database servers and Staff Client applications at the same time to ensure that the system overall continues to function properly.
Parent-Child Sites
No matter the installation method selected, Aeon can be configured to accommodate multiple reading rooms as explained above where one Web & Database Server would serve one or more collections. When configured this way, staff have access only the transactions which are requested for their designated collection, even though the requests for multiple reading rooms would exist together on one Database server. This functionality limit is accomplished through the use of Parent and Child Sites.
Conceptually, parent sites can generally be thought of as processing locations (the collections), while child sites can be thought of as their service locations (the reading rooms). There is some flexibility in how this feature is used depending on the specifics of an Aeon site's organization, but generally a parent site represents an organizational scope for requests; staff at site A will be able to see requests for site A or its child sites A1, A2, and A3, but will not be able to see requests for parent site B or its child sites B1 and B2. A simple case would be where all of the reading rooms are interchangeable and are simply a matter of researcher preference, but another case may be that certain items from a collection are restricted to specific reading rooms. In that case, the child site is more significant than simply being the pick-up location that a request is delivered to, but the common theme in both of these examples is that the child sites all share a common request-processing back end. If a collection only has a single reading room available for its collection, then there is not really any need for a child site.