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.
The CMS Comes First Method
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.
The All-At-Once 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 CMS Comes Last Method
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.
Weighing the Options
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.
I tend to use the “Front End First” method. If I know where content needs to go, with an understanding that I’ll be able to funnel it with a CMS, then it makes sense for me to get the front end in working order first. From there it’s just a matter of replacing the dummy data with things from the CMS.
I tend to use the “Front End First” method. If I know where content needs to go, with an understanding that I’ll be able to funnel it with a CMS, then it makes sense for me to get the front end in working order first. From there it’s just a matter of replacing the dummy data with things from the CMS.
I’ve also come around to doing the frontend first. Wireframes in Illustrator, then build them up to full mockups. From there it’s just a case of writing the HTML, CSS and JS. Once that’s in place, you know exaclty what needs to be pulled from the database, and before that even, it helps with the database structure itself.
I find it’s much easier this way that going from the backend, then realising you need some extra data, which could result in the database being restructured, queries re-written etc. But then again, I’m only working on smaller projects usually by myself or in a very small team. So this methodology may not apply on larger projects with a bigger team.
I’m not really sure where my process fits in. I’ve always built an IA to outline where the pages are and then built content decks which follow the IA in terms of what goes on each page. There is a loose enough format that you can do custom pages easily while still following the content decks.
By doing this ahead of time, even if there is no CMS at the moment, we know exactly what each page will have, how to structure it, and what variables there are, if any.
I’ve usually been lucky enough to have copy-writers who are capable enough to put copy in, so that is usually happening at the same time as I am building the templates out, we first install WordPress, use bulk page creator, to make the pages, dupe the DB, and then set up a staging site, all the content goes into the staging site, and is pulled down when needed.
I start with the CMS, but it becomes more like the “All at once” towards the end. As a solo shop, my process usually goes like this:
Meeting with the client to map out the content strategy and architecture. Wireframe general layouts.
Use Google docs to start collecting content – everything from long-form page content to specifically formatted taglines (e.g. <15 word salesy tagline).
While they do that, I build the backend with ACF and Timber and document the fields to match the Google doc guidelines.
They enter content into WordPress to an unstyled theme while I do some initial design – style tiles, etc.
Iterate on DB structure and build out front-end and design.
Pretty linear from there to launch.
I’ve found getting content into the CMS as early as possible streamlines the process a lot down the road, plus you get the client thinking more intentionally about copy/media and they’ll have more time to get it together. Always a good thing.
Lara, that is an AMAZING approach! All too often the owner has a site with no content, or worse the copy that didn’t work from before, that they want transferred over for reasons I’ll say I struggle to support; and you have to gradually impress upon them the importance of great content, testing content etc.
totally agree with her too. this is by far the most efficient way for a small team or solo dev to strategize. the point of cmd today is to keep content the central core of our work. i build with grunt and custom yeoman gems to wire up angularjs and wordpress for an spa feel and directives on top of wordpress and its own perks. makes for a great rapid process once u get past the ugliness of making the stack useful.
Also start with the CMS first. However, I’m a PHP and Drupal developer and projects I work on are designed with the CMS in mind. In the past, I would have built front end first and fit the CMS into an HTML template, however these days I tend to build the functionality of the site initially, ignoring how it looks and then integrate the design or HTML template (if one has been provided by the designer) into the CMS. That works pretty well for me. It means the content drives the design, to an extent.
My preference is always Frontend-first. I find having a skeleton of a site put together before involving a CMS helps smooth the build process. It allows me to better identify the common/shared elements, figure out what needs to be dynamic Vs static, start thinking about caching rules and identify any potential pain-points/risks early on. Then it’s a case of choosing the best CMS for the job, and plugging things in piece by piece. As long as you have a decent grasp of the content of the site, much of this can be done without any final designs. I find it a pretty fluid process.
I’ve started to prefer building out the frontend/backend parts of my webpages as specific reusable components, working everything out with each one, then making the last step integrating all the components together on each page. It has a lot of benefits with scoping but it does take a little longer.
Laura, your approach is definitely similar but with Webydo’s built-in CMS, clients have the ability to update the site’s content resulting in a completely collaborative experience between you and your client. It essentially eliminates this chicken-or-egg dilemma of which comes first and to kick, you have absolute creative control.
I always write the entire front-end on my machine then try to cram parts and pieces into the CMS right before launch. Ideally, if a change comes down (say a CSS change) I’d update my local SASS, compile and upload to the CMS. In reality, of course, I end up writing quick fixes right on the CMS immediately antiquating my local copy. It’s a sucky way of doing things. I’d rather have a CMS where I can write compile files locally and stage them up to the server; so, never touch the server manually… forces you to make sure local and server match all the time. I dunno, in an ideal world…
I usually prefer front end first, but with all the project creep, and people not having their act together, it ends up being an all at once, which also leads to a nasty spiderweb of code.
Seriously, I need to get people to start thinking in terms of components instead of entire page layouts…
I find your articles awesome. However, I use WordPress on Tech Legends. But,I love to play with the CSS codes by going through some your articles :-)
And, specifically I loved fixing the database! The previous article I guess….
Do the options, preferences, or processes change if we are talking about retooling and redesigning an existing site? Operating under the assumption that redesign will also include changes to content, content types, and IA.
Using ImpressPages CMS you can work on the All-At-Once Method. Drag and Drop widgets, Edit in place content.
“Website management made easy with true inline editing and drag&drop interface. Edit pages as you see them, not from somewhere under the hood. Drag and drop pictures, videos, polls, menus, whatever you like. Copy&paste and they will always match your current styles.”
https://www.impresspages.org/
Recently I was able to work with the CMS first method because my client knew exactly what data she wanted to publish.
It was great. Being able to build the CMS Content model (With CraftCMS). and then create the frontend with real date was a joy to work with. And it was a very fast process.
But if the client doesn’t know what to display on the page yet. There is no real option apart from the frontend-first approach
The Answer is it depends. What are the goals of the project?
How much of the project goals can be met by existing code (frontend and backend), and what has to be developed custom? Whatever part is going to be more expensive should likely lead, and try to reduce its costs. Building some crazy new js widgets — go frontend first. Integrating with a CRM and form framework — let the backend lead.
How much code are you going to get from elsewhere? If the answer is a ton, then doing development at arms length from that critical code is a recipe for disaster, effort wise.
I also think there is a difference between folks that think frontend means just HTML, CSS, and Javascript, and those that also mean doing the work to make templates that can be useful in a CMS context. Because if not, there needs to be another “frontend-backend” phase to integrate the two.
I think Lara above has a great process. My current kick is to recommend content (CMS) first, but that is more about my desire to increase success of NGO clients by putting the emphasis on what they need more help with.
Ryan, I agree that the goals of the project are important to keep in mind when determining if CMS should be the first step of the process. It is great to try new approaches to methods as a way to try to be more efficient, but ultimately it comes down to what you are most comfortable with. I’ll be sure to give Lara’s process a try and hopefully will be able to integrate it into my current workflow. http://www.quicksilk.com