(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:
- Service
- Space
- Building
- Person
- Group
- Policy
- Form
- Collection
- 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:
- Title/Name
- Description
- Contact Email Address (either for an individual or a group)
- Contact Phone Number (either for an individual or a group)
- 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:
- Main Campus Library
- Ambler Campus Library
- Health Sciences Libraries (**will need to verify if Podiatry and Ginsburg should be separate or together)
- Law Library
- Special Collections Research Center
- 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:
- 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.
- LibCal is used for event registration.
- 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.