Cynthia's Preliminary Notes

Owned by Emily Toner
Last updated: May 08, 2018
3 min read

(Drafted by March 2018) 

Entities

The traditional CMS portion of the library web environment will be built around individual entities. Each entity will have its own page. Additional pages may contain lists of entities. Entities will be categorized with a type. Each entity type will have a similar page template that include visible data fields and invisible metadata fields. 

The entities types to be included are the following: 

  1. Service
  2. Space
  3. Building
  4. Person
  5. Group
  6. Policy
  7. Form
  8. Collection
  9. Document storage

Each library will have it's own "home page" which contains snippets of related entities, but will follow a similar template.

A more detailed list of the data/metadata fields required for each entity is available here: Entity Metadata Descriptions

But, in short, every entity will have the following: 

  1. Title/Name
  2. Description
  3. Contact Email Address (either for an individual or a group)
  4. Contact Phone Number (either for an individual or a group)
  5. Location (building/space) - most entities will also be associated with a specific location, which will include both a space and a building. 

Individual entity types will have additional fields specific to the type. See the Entity Metadata Descriptions document linked above for the full list of the metadata fields. Also, see below for specifications regarding each entity type. 

Form

  • While not an entity in true definition of the term, we will need to have a space on the website for forms.
  • All sort of things use forms, from requesting new book purchases to 3D prints to feedback. 
  • Forms will need to have an email notification component so that the form can be directed to the proper person/group. 
    • Sometimes multiple persons/groups may be a recipient depending on an option checked off by the person completing the form (3D printing is an example of this). 

Document Storage

Also not a true entity, but we need to have a place to store PDF documents that need to be made available to the public. The foremost, and hopefully only, example of this is the annual report. The ideal scenario is to get away from storing PDFs on the website altogether, but I realize that may not be possible. 

Person/Group

Speaking of PDFs, right now, there is of org charts for each department within the library that are all PDFs. In theory, once we have all of the person entities filled out in the website, we would be able to dynamically generate org charts based on metadata. 

Libraries

The libraries are as follows: 

  1. Main Campus Library
  2. Ambler Campus Library
  3. Health Sciences Libraries (**will need to verify if Podiatry and Ginsburg should be separate or together)
  4. Law Library
  5. Special Collections Research Center
  6. Charles L. Blockson Collection

Integrations

The website has a series of integrations that will need to continue.

LibChat

For example, LibChat facilitates the ability of patrons to chat in real time with a librarian.

LibCal

LibCal, a Springshare product is used for a couple of different purposes: 

  1. Individual librarians can have a "Schedule an appointment" button on their profile that allows patrons to schedule an appointment. This is all done through LibCal.
  2. LibCal is used for event registration.
  3. LibCal is used for study room booking.

Social Media

There are also links to or integration with social media, such as Twitter and Instagram that will need to continue. 

Library Blogs

Library blogs are all hosted within the Sites.temple.edu WordPress framework. Eventually, we will want to take the content from WordPress and render within the selected CMS display. However, for now, a link is sufficient. 

LibGuides

Similar to the Blog content, we eventually want to render the content from LibGuides within the CMS display. However, for now, links to LibGuides will be sufficient.

Events

All event information is pulled from the university's central event calendar based on tags and displayed in a page on the CMS. We currently create a Drupal node from the data received from the university feed, not just a reskinning of the data. 

Hours

The library hours are a very popular component of the website and are tied to several of the entity types. Currently, hours are input through a Google Spreadsheet managed by Sheryl. Drupal calls the spreadsheet and displays the hours in predefined spots on the website. Ideally, we would keep the workflow the same with Sheryl continuing to use the Google Spreadsheet.