Versions Compared

Old Version 7

changes.mady.by.user Cynthia Schwarz

Saved on

compared with

New Version Current

changes.mady.by.user Emily Toner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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

...

Questions

Need to consider both functional and technical requirements and how they interconnect 

Functional requirements – what needs to be decided 

  • What type of editor/formatting options will be required
  • How does data need to be inputted for individual content types
    • This will likely require a set of templates, with descriptions. 
    • We will be starting with Service, Space, Building, Groups, and Persons in thinking about content.
  • How should the metadata content be rendered on the front-end user interface 
    • Need to consider both full and partial views for each entity
    • Need to consider aggregate pages of information (ex. library hours) 
  • What additional workflow management features are required – ex. approval queues, versioning, etc.
    • Distinguish "Must Have" vs. "Nice to Have" – will need to follow up with the Web Advisory group on this
  • What does the admin user interface need to look like

Technical requirements – what needs to be decided

  • How to build relationship between different entities (and support broader data model)
  • How to have consistent styling across content types
    • Ideally, we will reuse as much of Blacklight as possible. 
  • Eventually, how do we incorporate other library systems, such as Springshare products (LibChat, LibAnswers, LibCal) and Wordpress blogs

Requirements (Draft)

Child pages (Children Display)

See also: Library Website Environment Policies and Governance