National Baseball Hall of Fame and Museum

The overall aim was to create a site that allowed BHoF to tell compelling narratives about the vast number of artifacts in their collection.

By providing meaningful connections between different objects and stories, they hoped to increase user engagement and encourage a deeper journey through the site -- and hoped to inspire more people to visit the Hall of Fame itself as well.

Digital Asset Management System (DAMS)

The BHoF has a very large archive, and is currently in the profess of digitizing it. Part of the brief for this project was to provide a Digital Asset Management System (DAMS) for long-term storage of these digitized assets.

After some investigation, the DAMS BHoF and Cogapp selected was Islandora. This combines Fedora Repository -- a best-of-breed digital object store -- with a management interface that is fully integrated into Drupal. Using Islandora allows the BHoF to administrate digital assets and web content from within the system, and stores those assets according to archival best practices.

Islandora gives the National Baseball Hall of Fame and Museum the opportunity to store and publish over 100 years of history in images.

Deliver content (Paragraphs)

With such a vast amount of content, BHoF needed a less conventional way to capture and present their pages. A typical approach would have involved numerous different content types and fields, with large amounts of body content entered to a WYSIWYG editor. Cogapp instead chose to use Paragraphs, another great contrib module that provides a better way to deliver content.

What this enabled us to do was create pages that can be built up out of a variety of smaller structures (the paragraph types or *bundles*), each of which has a predefined set of fields. For example, a page might be built out of a mixture of paragraphs containing generic items like text and images, as well as more particular items like a Hall of Fame inductee.

Building pages in this way gives them a freeform feel, but the data remains structured for full control over presentation. To this end, each paragraph item can use its own theming template, which is defined as paragraphs-item--PARAGRAPH-ITEM-NAME.tpl.php. More generally, all paragraphs are Drupal entities, so they can be administrated, manipulated, and presented using all the power that this allows. When constructing a page using paragraphs, users are presented with the option to add a paragraph of a particular type:



This example shows instances of two paragraph types: a subtitle and a reference to a Hall of Famer's profile.

In summary, the Paragraphs module offers us:

• An extendable content area
• The ability to add complex (but structured) content
• Fully rearrangeable layout using drag-and-drop
• Finer control over output than just using WYSIWYG

Reach content (Entity references)

Drupal has excellent content support, with associations between content defined using the entity reference module. By combining entity reference fields with paragraphs, we created a way to pull in content from inside paragraphs. This allows us to:

• Reach content regardless of source (locally added images vs DAMS assets)
• Support user onward journeys (reach other content)
• Support social media sharing (assets and content)

A major advantage of our approach was the use of individual preprocessors for each content type. We used this to create a seamless experience on content viewing by our users. By individually preprocessing each content type we are able to:

• Interchangeably use locally hosted images and DAMS assets:
• As hero images
• As sidebar images
• As full size images on content
• As slideshows
• Have finer control on content (e.g. automatically generate an inline table of contents)
• Create different Twitter cards based on content type
• Integrate other sources of content from the CMS.

Present content (Entity view modes)

View modes provide entities with a mechanism to select which fields to display, and a way to display them, through templates. We use view modes to gain even finer control on HTML output on the referenced entities in much the same way we did with paragraph type templates. Drupal comes with two default view modes per content type, 'full mode' and 'teaser'. To add additional view modes we used hook_entity_info_alter.

View modes are administrated from the 'Manage Display' tab of a content type:

Each view mode:

• Has its own display fields
• Has its own template file
• Applies its own mode-specific logic (e.g. for slideshows, full images, etc)
• Allows front-end work with templates rather than the Drupal theming system.

Engage users (Extra fields)

The ability to share pages over social media with Drupal is straightforward, and there are several proven modules for doing this. In this case, however, we had slightly different requirements.

We wanted to engage users and facilitate discussions through social media integration. When a user is visiting a page in BHoF she is not just viewing a single item: she is reading text, seeing images that may be coming from the DAMS, interacting with slideshows, viewing Hall of Famers' profiles, and so on.

We wanted to provide a way to share a page as well as any other asset that was appearing in that page. Our approach was to use hook_field_extra_fields to add extra (pseudo) fields. Next, hook_node_view is used to create the logic within each extra field. In this scenario, each extra field contains a social media share link (e.g. https://developers.facebook.com/docs/plugins/share-button).

Extra fields act as any other field in a entity with its own display settings. This allowed us to re-use our previous approach, making share links available through view mode templates, for each individual item. Also, preprocessing each content type made it possible to provide relevant information on different twitter cards depending on the asset being shared (e.g. twitter card large image or article).