About the Project

The task: Compile five of the agency’s websites into one mammoth redesigned CMS-driven website.

The previous dot-com website had a CMS managing a few small portions of it that allowed the Communications team to make minimal updates, but it was viewed as cumbersome to use and too restrictive. The desire was for all responsible administrators to be able to update their portions of the site easily, for the page structures and the content items to be infinitely flexible, the design to be fully responsive, and new site pages (for case studies primarily) to be easily added.

My goal: make the website as easy as possible for a non-developer to maintain in order to keep my development team from having to perform any site maintenance.

The Process

Because this was the largest project my team had ever worked on collectively, I decided to introduce the Agile planning methodologies to keep everyone engaged with the project. Once I received the wireframes, I broke down the project into epics, began to write stories, and started scheduling planning sessions. Before each two-week sprint I held planning meetings where the team would go over the stories, break it down into the individual tasks, identify the qualifications for completion and the automated testing rules, and then the team estimated the story points with a session of planning poker. We had our daily scrums where we identified yesterday’s accomplishments, today’s goals, and any roadblocks we had. And we used Atlassian’s Agile plugin to JIRA to keep everything digital.

The Final Product

Since WordPress is the most well-known CMS within the agency (and maybe the planet), and because it could easily fulfill all of the project requirements, WordPress was chosen as the CMS environment we used.

Because the site was so incredibly customized and each module had so many requirements in order to maintain ultimate flexibility, we didn’t use a theme. We started with the bare WordPress install and built it from the ground up. No third-party WordPress plugins were used in the making of the site.

The final web site did not have a piece of content on it that wasn’t maintained through the CMS. Each page could have as many or as few modules as the administrator wanted to add and in any given order. If the administrator wanted to add a link in the footer or reorder the main navigation, they could. There were approximately 20 modules built that the user could choose from to display on a page including image and text slideshows, Twitter feeds, video galleries, and site page promotions. Each individual module had an array of settings to choose from including various color options, selectors to change the number of grid columns by media query, if videos should loop or stop at the end, checkboxes to add/remove vertical padding between content items, etc. The list goes on and on.

In addition to the standard content types, custom content types were created to manage:

• clients — logos, some about information, ordering sequence for the logo grid display
• individual content modules — these are what would get added to the pages
• news articles — content from one of the original four sites
• event postings — content from another one of the original four sites
• the annual poster series — yet another one of the original four sites

The user section was customized to manage employees’:

• Instagram information including who can contribute to the site’s Instagram feed
• client associations
• headshots for blog posts
• animated employee gifs displayed on the site

Help documentation was written and implemented on each wp-admin screen under the “help” tab providing:

• dimensions and file type requirements for each of the different media assets
• instructions for how to create and update each element of the site

Summary

It was a huge undertaking, but one that my team enjoyed as they were introduced to knew processes and new coding challenges, and my goal of creating a complicated site that could be maintained by a non-developer was achieved.