Background
In the fall of 2022, a new iastate22 theme was released for campus-wide use with the goal of providing a consistent user experience across all university websites and an expectation that units would transition to the new theme ecosystem.
The theme project team provided many resources to support this, including front-end "base" components, PHP code, and WordPress theme downloads, virtual training sessions, a style guide with best practices for content creators, and a collaborative discussion forum for questions and continued support.
Challenge
Web support teams across campus were challenged with implementing the provided look and feel of the iastate22 theme components to our clients through our corresponding managed website service platform.
For the CALS/LAS web team, that meant implementing the new code into our Sites+ platform based on the Drupal content management system. While the resources provided gave our team a place to start (or rather end, as we knew what the finished product should look like), we were still challenged with breaking down each aspect of the theme ecosystem and coding it into our website platform.
Many questions had to be addressed in the process of this build beyond just "how we make these components work," including:
- How to make the theme components intuitive for our content editors?
- How to handle the scope of an entirely new content strategy focusing on the president's stated goal of student recruitment?
- What should be prioritized with a rapidly approaching July 2023 targeted go-live date?
Approach
Building a pipeline migration solution
One of the first blockers our team had to address was the timeline for ab individual website migration. Our preexisting process for site migrations involved migration code that would make a one-time copy of the content from the live site onto a new working site with the latest theme. This allows our content strategists and clients to work on an unpublished website until the revamped site is ready to be launched. At that point, the working website is swapped out with the live website for all to see. A typical timeline for this is about one to two weeks, where the content workers manually build any new pages needed and update old content and theme components. With a new content strategy and all-new building components needing implementation for the iastate22 theme, that timeline was no longer achievable. For medium to larger sites, it would take more than two weeks to build and launch a new website, and in that time, all of the work clients were putting into their live websites would be lost if not also tediously duplicated to the revamped site.
Knowing this, our team consulted outside firms on the best approach to a longer migration timeline. We determined that in order to extend our timeline, a pipeline solution was needed to look at any content changes made to the live website and pull those changes to the working unpublished website at the beginning of each day. This allowed the clients to continue progressing on their new working site while keeping end users updated on their live sites.
As back-end developers chipped away at making this code work, our front-end developer worked to prioritize aspects of the new theme build into two phases. Phase I included building theme components that clients could not launch without (i.e., the menu structure, header and footer changes, new text heading styles, etc.), and Phase II included less essential components, such as a video hero block, an accordion feature for body text, image carousels, and other flashy block components.
Creating reusable, flexible components that follow the "iastate22" theme rules
New custom block types were needed for each new iastate22 component. Due to the differences between website platforms, existing code could not be re-used. Instead, the components were rebuilt by our front-end developer, who referenced the resources the project theme team provided (style guide, Fractal component library, GitHub repository, etc.).
These custom blocks are structured similarly to the way a form works. We provide a place for content editors to fill in their custom content in several form fields. The first step to building a block was to determine what fields were needed.
Breaking down the “Call to Action - Large,” the fields needed are:
- Title (required)
- Caption
- Button (only one)
- Image (2160 x 807 px)
With the field requirements settled, a new local site was created for building and testing. On the local site, the developer roughed-out the Drupal custom block type by adding the required fields, laying out the form for the content creator, adjusting the display settings, hiding unnecessary labels, and configuring the image style.
Once the content fields were established, work began on building the needed HTML structure and CSS to make the component look correct across all devices, again referencing the code in the Fractal component library. Our developer referenced all resources during this iterative process, so our implementation matched as closely as possible with the provided design.
When the component worked well on the local site, all the code (block configuration, templates, CSS, etc.) was committed to our theme repository. More of the team was brought in for thorough testing at this point until we were all satisfied with the block.
With the block committed to our Drupal theme, content editors on the team were able to use the block in real time and suggest improvements or catch any bugs that were missed in the first round of testing. This process was repeated for each aspect of the new theme you see on your website!
Execution
Content strategy and review
Phase I theme components committed to our theme repository meant the team could start building working sites. Our first real test was the College of Agriculture and Life Sciences (CALS) website. We began with content strategy, asking questions such as: what is the main goal for conversions on your website, and what sort of menu structure would most support the primary audience for this? Which pages on the live site attract the most visitors? Which pages on the live site are people linking to the most, and were there any features the live site didn’t have that the new site could support?
The client created an optimized navigation structure from these answers that promoted the most important content to their target audience. They included a strong emphasis on academics and worked to provide the best experience for potential students of CALS including featured information for life at CALS and the hands-on opportunities available for learning.
The homepage was built to act as a secondary navigational hub for visitors searching through the website. It highlights the learning opportunities available for students while featuring real-life success stories in all areas a student's path might take: extension, research, or continued learning.
Multiple content drafts were reviewed and iterated on until the client and team were satisfied it was ready to be launched.
Launch and postlaunch
We launched the new site on Thursday, July 13. After launch, we kept a close eye on visitors to the site. Even though many URL redirects were in place to ensure that people who had pages bookmarked would still reach their goal, some became apparent only after launch.
As people began to encounter the site, a few changes and corrections have come our way.
Result
A workable iastate22 theme for our CALS/LAS clients and their websites and a consistent user experience for end users across the Iowa State University web-verse.