Between May 2016 – May 2018, I transitioned from an individual contributor to a leader and manager of a team of four developers. Instead of being the primary developer from start to finish on large projects– I was doing more oversight and contributing smaller tactical components of many projects.
My website got to a point where I hadn’t updated it in years. I left it “under construction” for over a year while I tried to figure out which direction to go with it.
I’ve maintained my website as a portfolio and blog since college: from Flash & ActionScript, to Joomla, and finally on WordPress, where it’s seen several iterations. I kept all of my old work throughout the years either as a detailed portfolio item or blog post. Once a portfolio item would no longer represent my current sills, I’d convert it into a blog post. I loved seeing my growth: it was a great way to combat my own imposter syndrome. The downside is that maintaining all of those screenshots, screen capture videos, descriptions, and code bases became a large burden.
Well, you’re looking at the final result. I decided to focus on the balance of being a player-coach by separating my homepage and my sections of content into two: me as a developer and me as a manager/leader/director— and then, of course, the supporting pages and posts.
I conceived & built the BU Landing Pages Plugin around November 2019. For several years prior, we had been using CMB2 and page templates for homepages/landing pages– in order to achieve non-standard layouts including promo boxes, featured news, events, or profiles, and other custom functionality.
Along with the department’s creative director, we identified the most common layouts/components and compiled them into a plugin (still based on CMB2) so that we could stop rebuilding them on a per-project basis. The idea was to keep it as simple as possible with very little configuration needed.
(as of Feb 2020)
Sites using the plugin
Contributors to the repo
Commits on the repo
Features & Goals
Stop-gap between the timing of non-Gutenberg at BU and eventually integrating Gutenberg
We started developing BU’s Responsive Framework in October of 2013.
I was the original developer to contribute to the Responsive Framework, and while my individual contributions have wound down, I remain in charge of overseeing the development.
It was a very slow, deliberate build based off of a lot of institutional knowledge and working knowledge based on the previous framework, called Flexi. We chose to start building the first child theme while the framework was still in development so different team members could provide real-time and “real-world” feedback.
The Responsive Framework, or Responsi as we lovingly call it, has three main avenues of usage:
Enable-and-go for clients.
Options available via the customizer and settings pages.
Menu/layout options, color palettes, content/sidebar settings.
Out-of-the-box Theme + Custom Design & Config
Via custom CSS/Sass
This usually involves a designer/frontend dev also setting up the site and configuring options and content deeply.
A Parent Theme Framework
We build full-scale child theme with custom design and functionality
Customizer options & settings can be set via theme constants so they can’t be changed if the design doesn’t allow for it.