By far the biggest website development project I’d ever done, there had already been nearly a year of planning before I’d even started working at BigWing. Much of that time had been spent planning content strategies and ironing out a very rich sitemap featuring more than 300 planned content pages. They hadn’t been in a particular rush for a new website and wanted to make sure they did it right. They had approved the sitemap around the time I joined, so I was tasked with setting up wireframes to begin fleshing out the visual structure of the site.
First, I took a look at the sorts of content they planned to have and what features each sort of page may need. Pages were then categorized so that any special content types or features would have a basic wireframe and we could make sure expectations were established. These were going to be reviewed by a board of directors consisting of health care professionals rather than technology experts, so we catered our wireframing process to be more detailed and inclusive than we normally would so that they wouldn’t be left wondering why certain planned features weren’t shown yet.
Both the homepage and the top-level pages for each section were considered one template as they wanted to have a feature to populate a tile of recommended sub-pages and related content upfront. The ability to search their doctors/providers (their main inspiration for what they wanted out of their new site) was also its own wireframe to show functionality and the custom post types for the individual doctor bios also had a wireframe to show how sections might be arranged. Similar wireframes were done for their office locations custom post type and its directory, and even though some of the features would have their designs determined by plugins rather than theme we still went ahead and included demonstration wireframes for events, the event calendar, and a history timeline. Even basic things like blog post grid, search results, and contact forms were all shown so we could get feedback on them early in the dev process. Another thing done to prevent “surprises” was to show how the structure of each page would change slightly from mobile up to tablet and desktop and everything in between so that we could plan for all sized screens.
We presented the wireframes in-person and for each framed out page we provided them with a list of which pages might use each wireframe (so, for example, they’d know that the Specialties/Services, Research, Education, Clinical Trials, and Giving pages would all look just like the homepage but with different content). We made sure every page of their sitemap matched up with something somewhere, particularly because if one of those pages happened to be the focus of one of the directors reviewing them they’d be pleased to see we were thinking of them. If they could imagine their own content in that context then we’d receive better feedback. They had taken great care with planning their site’s content so we should give it the same attention to detail and consideration.
Basic wireframes tweaked and approved, it was time to fill it with a rich design for full mockups. The color scheme had to match WCAG 2.X and, since their planned font Rotis wasn’t licensed for web use, we also proposed new, similar fonts of Francois One for headings and Lato for all other copy. Now that the dull, lifeless wireframes were filled with colors, fonts, vivid images, and demonstration content the final product was beginning to feel eminent.
At this stage we began to realize one of the most complicated pieces of the plan was their insistence on the sitemap also being the navigation. This would mean an incredibly dense menu with some content stuck several layers deep within sub-menus within other sub-menus. Suggestions were made to use our planned custom “related content” and featured tiles blocks to send visitors to interior pages rather than including each and every sub topic in the navigation. Though this was done to some degree there were still over 200 pages that absolutely had to be in the menu, particularly because some of the doctors on the board of directors insisted on their specialties being included in full. So, the first development hurdle was to design a menu that could contain that many nested categories and still be functional.
The nav was based upon SmartMenus because of its built-in “collision detection” which would help us to ensure that having a sub-menu under another sub-menu would never open off-canvas and instead would detect the edge of the browser window and if necessary would open to the left instead of to the right. It would do the same for the bottom of the window as well so that longer sub-menus would open bottom-up and not be cut off by the viewable area. The fact that it was based upon jQuery meant tweaking parameters and stepping through the DOM for conditional tweaks was easy and not stuck in proprietary technology. We were also able to import it into our theme in Node module form as a dev dependency and include its JS files in our compiled build scripts using ES6 imports so that installing any updates to this component would be handled like any other dev resource.
The locations and providers were done as custom post types each with a different set of default block templates that would appear in the editor to start a content creator in filling out the frontend information. The doctor search capabilities were written using SearchWP as the base but adding in FacetWP in order to setup custom weighting for certain types of results (as partially explained here). This also involved the usage of WP Content Connect to create a system where content could be cross-tagged with a relationship. For example, if a provider worked out of certain location offices then that provider custom post type (CPT) could then tag which location CPTs they were associated with. We did the same with services/specialties (also a CPT rather than just a page). This allowed a doctor’s profile to automatically show their locations and services on their bio while also making it easier for those connections to be searched on the search page.
As we began working on content pages at this point we received some unexpected news. The host of Dean McGee’s existing website (and the maker of their proprietary CMS) had decided to pull the plug with a deadline three months away before it’d all be taken online. So, while the client wasn’t initially in a rush and just wanted it “done right” we were suddenly hit with a firm deadline to have something publicly presentable. We had enough of the basic theme already built, but there were still hundreds of planned site content pages needing to be done. With this in mind, our focus changed from development to content creation, and all hands were now working to put content into the editor. It ended up being a good test for if we’d succeeded in making the editing experience as easy as possible considering all the moving parts that were in play.
There were some things we’d planned to do as built-in theme features but, due to the crunch of needing to meet the new deadline, we left up to blocks until we could revise them. For example, we’d originally planned on having automatically-generated page heading blocks using the featured image as the background, but that feature wasn’t ready yet due to the time it took to setup the provider search and related content types. We also decided to prioritize things such as custom Schema/JSON and content enhancements if we could use blocks to build components in the meantime. It also took a custom importing script to be developed (by our backend developer, not me by the way) just to translate the blog posts from their old proprietary CMS into WordPress and even still many of the posts required manual cleanup of formatting and images.
The final feature implemented under my time on the project was the blocks for related content that would feature a tile of images and overlaid headings to direct visitors to interior pages. This had to be added post-launch since we’d spent much of our remaining time (before the old site shut down) focused upon making sure their content was complete and ready for search engine crawlers. The block would allow an editor to select a page for each tile easily and make adjustments to the shown image (in case they wanted something other than the featured image of the page/post in case of odd cropping).
The website was launched amidst the Covid-19 pandemic and, even with the economy grinding to a halt, Google still immediately preferred the new site over the old one. For May of 2020 Google showed organic growth year over year for the first time in over a year, and it kept trending consistently upward from there. The site was better looking, better performing, more accessible, richer in information and functionality, and easier to maintain.
