Furever Memorials on Morris Animal Foundation

The pet memorial modernization project began with establishing a cross-functional team across the Foundation’s departments: Marketing and Brand Strategy, Fundraising, Accounting, and Information Systems. Over time some groups were more or less involved depending on the needs of the project. This project team analyzed the existing product and reviewed features of online memorials more broadly. At the end of the discovery phase the team had created several artifacts that guided the project throughout its life:

• Personas: descriptions of stakeholders to help anchor the project in the humans who will be using it to honor their lost pets.
• Use cases: explanations of the features the personas would need from the product to be successful.
• Goals and metrics: the set of key performance indicators that would be used to determine the project’s success.

With discovery complete, the team narrowed down to two software engineers, stakeholders from fundraising, a designer, and marketing expert working together refining features, making wireframes, and working on designs. That team was Leo Kacenjar and Kelly Molumby, Dan Stencel, Elizabeth Morgan, Jozy Klupar, and Lindsey Washington. As they worked, they gathered feedback from the broader project team. Once there were enough designs to begin work, more of the Information Systems’ software engineers began building the features with assistance from Matt Glaman acting as a contractor on the project. Hiring an experienced commerce consultant with deep experience in Drupal core helped the team make progress while balancing the other needs of the foundation. We were thankful we had Matt’s help while he was available for projects like this.

The use cases were grouped into logical sets of work that could be released iteratively.

Phase 1 - memorial gallery feature parity:

• Creating the custom entity to store the photos and descriptions with all the fields we anticipated needing (in the end we had to adjust the fields, often using techniques described in this help guide).
• Migration code that connected to the WordPress database to import the data and image files. We maintained the same URL to make redirecting easier for better SEO and usability.
• A basic gallery with the most important features of the old gallery.
• A basic memorial page that had most of the features of the old page.

We chose to build a custom entity instead of configuring a node to store this data. We have used that approach on several other sites so we’re comfortable with using the drush generator to efficiently create custom entities (See a Drupalize.me tutorial on the idea). We appreciate that custom entities have better database table structure for more straightforward querying and provide a solid location to build business rules into the entity code.

We launched this phase and did some usability testing with internal staff members who were not working on the project. This validated the ideas and implementation of the project so far and helped highlight areas that needed more work.

Phase 2: rich online memorial experience

• A memorial creation multi-step form including donation details.
• Some configuration of the memorial such as whether it appears in search results.
• Transactional email notifications for certain events like the creation of a memorial.
• We provided a special style for the memorials associated with dogs in our Golden Retriever Lifetime Study.
• Styling for all the features.

At this point we used permissions to control visibility of certain features, avoiding site visitors using any additions before they were ready. This also allowed us to easily grant our internal user testers access to a different set of features than the public.

Phase 3: memorial community, accounting, monitoring, and refinements

• The ability to comment on a memorial and associated styling.
• Refinement from feedback in earlier phases and usability tests.
• Adjustments to CSV reports to ensure data about donations flows through properly to our accounting and donor management system.
• Creation of a dashboard using Google Looker Studio.

We did further usability testing after phase 3 and then one last round of refinements before launching the site. The usability tests were conducted by our product manager, Patrick Collins, who walked participants through the process. Each usability tester was compensated for their time with a gift card.

By this point we had a multi-step wizard for creating the memorial, adjusting the settings, and taking an optional donation. The first step is shown in its mobile rendering below.

Launch and celebration

By launching the phase 1 code and running the migration we were able to set up redirects from our old site to the new site and then turn off the old site. Maintaining the urls keeps our promise to the people who created a memorial that, while their animal has passed away, the memorial will live on into the future. We then held facilitated usability sessions to gather about the updated gallery design from our internal testers. The notes from the usability sessions and feedback from reviewers were turned into tasks for refinement of the product in future phases.

As we launched the phase 2 and 3 code, opening permissions so that trusted testers could create memorials, we got further feedback to incorporate into the system. We invited new audiences to participate in a few rounds:

• Staff and our Board of Trustees were invited first via email and on Zoom meetings. Their feedback helped catch a few bugs and identify opportunities for improvement.
• We sent invitation emails to volunteers in the Golden Retriever Lifetime Study, some amazing supporters of the Foundation’s mission who have a strong connection. We hoped they would appreciated the extra recognition their dogs get in the online memorials.
• As we gained more memorials and confidence, we incorporated focus pieces or tie-ins to the feature in our ongoing emails and social media posts.
• We are experimenting with additional channels to draw in people who may not have heard of the Foundation previously.

The technology behind the memorials

Memorial dashboarding and metrics:

To monitor usage and success of the product we created some custom dashboards leveraging Google’s Looker Studio. We already have a Jenkins automation server and used that to execute nightly exports of data from our Mysql database into BigQuery. While BigQuery is probably overkill for this purpose it has integration with Looker Studio and price (both products are free at our volume). The technique to get data from Drupal’s database to BigQuery is a low-tech approach in bash, essentially:

# Export data formatted in json.
drush @morrisanimal.prod ev "return \Drupal::database()->query(\"SELECT columns…;\")->fetchAll()" --format=json > orders.json

# Format the json in the way BigQuery expects it.
cat orders.json | jq -c '.[]' > orders_forload.json


bq query --use_legacy_sql=false "TRUNCATE TABLE example.orders;"
bq load --autodetect --source_format=NEWLINE_DELIMITED_JSON example.orders orders_forload.json

Building graphs in Looker Studio is fairly straightforward. They support solid permissions for sharing across teams and can be configured to be emailed to stakeholders periodically. Here is an example dashboard (with some private details purposefully removed) to give a visual sense of what this helps create:

If you’ve got some experience with SQL, shell scripting, and creating graphs in a spreadsheet tool it’s a great option to consider to create up to date, sharable dashboards.

Source code management strategy

In general, the site uses a “main, dev, feature branches” strategy merging new features to dev after a code review and merging the dev branch to the main branch right before a deploy. We use both Gitlab with its integrated Continuous Integration testing and Tugboat (more on that later). The project was the only major feature development occurring on the site, so the team used a long-lived branch for each phase to manage the new code. Periodically we would merge from dev into the long-lived feature branch. That process eventually got a bit slow right about the point it was time to merge and release the code.

The long-lived, phase-associated-branch let us follow our normal workflow for any security updates or bug fixes that needed to be deployed to the site before we were ready to release the memorial related code.

Automated testing:

In addition to manual QA and usability testing we used a mix of automated testing tools to help maintain the reliability and quality of the site. The automated testing included 5 major technologies:

• Behavioral testing using the Behat Drupal Extension for the majority of tests.
• We built some tests using Drupal core’s Functional Test framework for some of the base memorial entity features.
• Code style and deprecation testing with phpstan-drupal. Since this site was an upgraded Drupal 8 codebase that had some deviations from Drupal core style standards we used a “budget” approach: the automated test confirms that there are fewer than a certain level of problems. If a merge request introduces problems detected by phpstan, we either had to fix them, find other style issues to fix, or increase the budget. At the end of the project, the budget was lower than we started, which confirms that this approach is a sustainable way to introduce and improve the developer experience of an existing codebase while maintaining delivery speed.
• Manual testing on a per-branch basis and visual regression testing of the anonymous pages using Tugboat. This was the first project where we used Tugboat, and we are in love with it. Having a place where stakeholders could test out changes on specific feature branches was really helpful, and the visual regression tests saved us from introducing a handful of problems. Thanks, Tugboat!
• Accessibility testing using pa11y-ci, which runs after a deploy and is graphed in Data Studio. Each morning we receive a report about Accessibility and can fix new issues or celebrate our success in reducing problems.

Tests can take a bit more effort in development as you first use them, but are essential for our team to avoid introducing regressions as we maintain 4 different website products across the Foundation.

Memorial gallery search

The memorial gallery has a few features focused on delightful user experiences. It uses dynamic loading in a few places:

• Searching by name will detect when someone has stopped typing and update the results without a full page refresh. It feels like a pretty fast experience which was achieved by dynamically update the memorial gallery based on user input without requiring a full page refresh using Drupal's AJAX API.
• Adjusting the filters, for example selecting Cat as the Animal type will both filter and reveal an additional filter for the breed of cat
• Browsing additional pages of the gallery is achieved with a “Load More” button at the bottom of the gallery which adds more memorial photos to the bottom of the page.

In Summary of the Project

The site has had help from various folks over the years. It was built as a content publishing engine and launched in 2018 with the assistance of Elevated Third. The in-house Information Systems team migrated most donation-related features in 2019 to support many of the features that were available in the old WooCommerce site. In 2022, we were able to turn off that WooCommerce site after the migration of this online pet memorial feature.

Throughout the process, Drupal 9 has proven to be an excellent technology choice for this purpose. It is scalable, extensible, and highly capable. The upgrade process from minor releases and major releases was a small effort considering this project includes updating technology across 5 years.

As a final note, we want to share the feedback we received during a usability test. One of the testers had lost his dog to cancer a few months before helping to test the tool. While it was difficult at times for him to fill out his information, he said, “For people, we have funerals and memorial services, and we don’t have the same rituals around that for our pets, which can be just as important to us as the people in our lives. Having a space like this is super important for people. I think it’s sorely needed, and it’s not something that people think about until it happens.” Feedback like that helps give meaning to the project and reminds us of why we do this kind of work: for the love of animals.