This was my first custom project when I started working at BigWing. I came on board with the development already having begun but I was hired to fill in due to all but one developer on the project having left the company. The wireframes had already been approved, a staging environment had been setup for development, and a basic scaffolding for the theme was built using WP-Rig. The other developer had also already figured out that the navigation menu would be built using the UberMenu plugin and he’d already built pieces for their custom post types, their relations to each other, and the site’s unique search functionality (including filtering the results). My job was to take our mostly barebones scaffolding and make it match the wireframes.
WP-Rig’s pre-packaged dev libraries were already familiar to me, leveraging Node modules, gulp tasks, pre- and post-processors, linting and tree-shaking. One thing that was not familiar to me yet at the time however was BigWing’s custom coding standards ruleset. The other developer on the project was a longtime veteran and core contributor to WordPress itself, so having an opinionated code standards check built into the build scripts meant any bad habits I might have had would now be caught even before code review. So, while I was in charge of figuring out how best to complete the look of the site it would also need to meet the agency’s established standards.
There were some development challenges during the build. The first was that the wireframes had been made by our team graphic designer who, though a rockstar of visual fluency such as use of whitespace and good typography rules, did not have a background in web. This meant that some of the things, as designed, would have been easier to implement if done slightly different.
One small example is on the Grooper Features page having an image placed just above the heading on a media block. At the time of this project only plain text could be placed in a media block (this project coincided with the initial release of WordPress 5.0, and so Gutenberg was still a new concept). This meant needing to track down some third party block ecosystems to complement and expand this functionality. The same went for the use of styled tabs and accordions as content tools. Both of these design concepts were solved by using Kadence and Stackable, respectfully.
Another example not so easily solved was the extra navbar just below the hero on the Grooper Features page which included horizontal scrolling links that would jump to the named anchors on the page. No such off-the-shelf product had this functionality, and so this became my very first custom block (built using BlockLab). You could add links by filling in the link text and the name of the anchor, rearrange the links as needed, but when viewed they’d fill out a horizontal row with chevrons for scrolling.
One example where concessions needed to be made was the terms filter that would be used on landing pages and the search results page to allow a viewer to sort or filter the page’s contents to show only ones of certain custom post types. The functionality wasn’t the problem, but the design was. In the wireframes this was a heavily styled form select field with colored headings followed by the results. While it looked great it’s generally a bad UI/UX practice to style a select because the operating system (or the browser) should have control over this in case of accessibility concerns. Also, the only way to style a select would involve JavaScript, so complexity versus payoff was a consideration.
Other things of course came up during the content phase of the project, particularly because Gutenberg was such a new ecosystem and we were learning its limitations. Since the client intended on taking full ownership of the site at time of completion I worked to document any editorial considerations they’d need to be aware of when it came time for them to manage and edit their own content, such as which blocks would be best for which circumstances, how to customize page headings with backgrounds and even videos, how some blocks performed (or could be customized to perform certain ways) on mobile, how our custom blocks worked, how to modify their UberMenu navigation, and more.
At the end of the project they also forked our Git repo and we showed one of their developers around our code base and also had all-hands training meetings with the staff that they intended to be working on their theme and content going forward.
