Chris published a post a little while back on where style guides fit into a team’s process. I enjoyed it so much that I decided to offer my take on where content management systems fit in.
I also wanted to write this because it’s a common point of contention. Different teams I work with prefer to integrate content management systems at different points in the process. There’s nothing inherently wrong with one approach over another, but it is a good conversation to have and decision to make before digging into a project.
This method places the CMS at the very front of the process. For example, let’s say you already know WordPress will be the CMS and you have a baseline theme that recycles a lot of the common functions and templates that you use from project to project, but leaves the design and styling open-ended. Or, let’s say you’ve purchased a premium theme and plan to modify the front-end from there. It’s about having the framework done in advance.
This is fine and dandy. I’ve used a bare-bones baseline WordPress theme before and have seen others do some great work with WordPress child themes. Then again, I honestly have not been a part of any project where integrating the content management system truly comes first in the process where all back end code was fully developed first; there has always been some level of front-end work done up front prior to the integration, which leads us to the next method.
Front end? Back end? Nah, there’s no real distinction here.
For example, we know WordPress requires a number of PHP templates, loops and functions to churn out the content and views of the site. This method builds those alongside the front-end markup.
There are a number of benefits to this approach. For one, it can save a huge chunk of time. Instead of writing all the HTML, CSS and JS then splitting it up into various PHP snippets, we can tackle it all at once and eliminate an entire step in the process. This is hugely ideal if you work on small team and are tasked with a project with a fast turnaround.
But there are pitfalls: Imagine writing a bunch of complex backend code only to have the project change scope and render it obsolete. It certainly depends on your comfort and skill level with more advanced programming languages, but I find it much easier to revise HTML and CSS than something like PHP. That’s where a slip in this method could be a massive time drain.
The difference here is making front end development a mandatory and separate deliverable from back end development. Instead of working on the CMS in advance or marrying the front and back end right out of the gate, they’re separated into distinct deliverables to keep things from getting too messy.
I see this method being extremely useful when working on a project in stages. For example, I like the idea of designing directly in the browser because it gives me the freedom to play and experiment without the constraint of worrying about back-end development while creating comps.
There are potential pitfalls here as well. For one, things can get lost in translation when working in stages. It’s kind of like the age-old game of telephone, where whispering a phrase down a long line of people ends with a different phrase than how it began. There’s also the question of how to maintain the project once it’s launched—do we make changes in our the front-end or the back-end deliverable and how do we keep them synced? The answer there can vary from project to project.
While I stand firmly on the side of choosing the right method for the right project, I do find myself working putting the CMS last more often than not, even if the CMS has already been chosen. I have a boilerplate project I use for WordPress that creates those boxes and uses Grunt to automate the process of transferring assets between them. I’d consider this a shameless plug for a repo, if it wasn’t for the fact that I haven’t touched it in a long while. Please feel free to tear it apart and put it to use, if you find that sort of thing handy.
What say you? Do you have a particular method for integrating content management systems? Does it even matter to you? It seems like the kind of thing that would come up often, but it would be interesting to hear how different people and teams approach it.