Wow. This should be a must-read for developers, especially ones working in the content field.
I've made a few complex apps that use Google Spreadsheets as the backend...that is, to hold the public facing data and not, obviously, any proprietary data. This makes it very easy for those who have to maintain the app to enter in data. The downside is, of course, the inability to strongly enforce business rules and to denormalize things...but that forces me to reduce the data design to a bare minimum, which is often the best strategy in the first place.
I hope I never have to be in a situation where I'm building a CMS-type system for a client. People who haven't dealt with data-modeling or relational-databases don't appreciate simplicity...in the end, most people want something that they can type a headline, some text, and attach a photo or two (i.e. a Tumblr). But if you give them reins to design the system, they will inevitably want you to build them something Drupal like. In my experience, I've found that all these different content-relations end up being unused, and the client ends up hacking around them just to get a simple post up.
This is basically the same phenomenon that happens with frameworks. At first, the framework gives you a ton of functionality for the (initially) low price of living with its abstractions. As you want more custom functionality, you find yourself either fighting the framework with increasing levels of desperation, or simply coding around it. I'd argue that the best frameworks are such that you can code around them without causing huge overhead or resorting to objectionable tricks.
The same goes for CMSes. Many CMS customers would probably be better off if they took the CMS editor interface as a separate component and wrote the actual page renderer as a custom development separately. The trouble is of course, content systems make it very hard to do that. Having to make things work with the native mechanisms (and the often horrific underlying data model) is what makes huge CMS projects fail or at least perform miserably for everyone involved.
On the very top of the list of abhorrently convolute CMSes would probably have to be Typo3, followed after some distance by Drupal. But the more you work with the initially-liberal Wordpress the more you discover it's not that far behind either.
This reminds me of a bygone era: my startup (now long gone) had its own CMS. Sadly, that wasn't our actual product as we were a pure service company and the CMS was only a tool for us. In hindsight, we should have done it the other way around. Our CMS wasn't perfect, but it shone in a few areas that made the life of both developers and content editors very easy: a simple, accessible data model and an easily extensible page renderer. Unlike many other solutions it was designed to get things done, not to bill a lot of consultant hours. I've yet to come across an open source (or commercial for that matter) CMS that works equally well.
@rudyrigot and the team @prismicio http://prismic.io really have a handle on this problem.
They believe a github-esq content management system makes the most sense for content creators, and a content API makes most sense for engineers to distribute that content inside of a variety of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails meetup this month, it was a very good presentation (I am not affiliated with Prismic).
I've been playing with their ruby-kit, so far so good, really liking this approach and plan to see awesome things ahead.
The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?
From an architecture point of view, I'm convinced that the CMS is better treated as a service, and not as part of your web application. This is especially true in a larger organization where content needs to be collected and managed in different ways (via import, or where people edit or curate content).
At the start of this year, the company I work at had about six different CMS platforms. Many of the applications that used them were built on top of CMSs, and were tightly coupled to them. As for static content generators, we tried that. It really didn't scale, especially for dynamic content. Too many hacks, deploys, and hard to train people.
As of today, our team has switched nearly all public content for our company to LocomotiveCMS (http://www.locomotivecms.com/), and deployed a centralized multi-tenant system. In many cases, we use our Locomotive instances as an API, pushing content via the API or the command-line tool, wagon. The CMS then renders HTML templates (or even JSON), which are consumed by our applications via HTTP. Sometimes it's just a tiny part of a page, or sometimes entire mini-sites. As a result, most of our apps don't need to know about a database.
Whenever there's a change that requires a new model, or the addition of a field, it can be done quickly through the LCMS back-office UI (or the wagon CLI tool). We update the application(s) affected, and re-deploy. Non-techies can edit the content using the admin web UI in a familiar way.
In any case, it's been working really well for us. The CMS has become an API, a service, and a separate app, shared by many applications. We've become more flexible and efficient as a result, our web applications are no longer burdened by CMS frameworks or admin interfaces of their own. And we dont have to struggle with Sharepoint or Wordpress or any other nonsense.
It's been a fundamental shift in how we think about the CMS, and has scaled well across multiple projects.
I had LocomotiveCMS on my radar for quite a while as it looked very promising, but lost track as development staggered for a year or so.
Do you use their hosted solution or do you host it on your own servers? Do you have any information if the version on Github[1] differs in significant ways from the hosted solution?
It seems like they are really pushing the hosted solution now, their website doesn't make it very clear that you can install it by yourself too.
I wrote an app for my company to extract data from the database and form xml feeds for various e-commerce services. I took the opportunity to learn OO principles and read through Object Oriented Design in Ruby.
What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant.
I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears.
I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code.
Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.
But the piece was not about using CMSs where code would be more appropriate. It was about turning your bespoke application into something like a CMS by architecting for maximum flexibility and configurability everywhere, building complex "admin" interfaces, and implementing data-driven runtime behavior before any of that is really necessary.
You can do all of these things with 100% test coverage, but that doesn't relieve you from dealing with the weight of the architecture and extra work when you try to add or change functionality later.
Agreed. I've almost given up on using a CMS. Developing on the Drupal platform (as mentioned by the author) was really painful. I've only found a few CMS' that get the heck out of my way and just let me write code.
This days if I have a static site around 10 pages, I just use .Net MVC project and use partial views to store the content. Much easier than using a CMS and I still retain all the control I want.
Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part.
If you're making PPC pages, host them statically somewhere.
I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating.
BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #1 to a different creative in a few days have been worth, guesstimating a number here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For the last couple of weeks, most teachers have been in the market for Thanksgiving bingo cards. This will not be true in a few days. The #1 URL, which I use for many of my campaigns, uses some really dead simple heuristics to guess which creative to show people. The heuristic was worth > 10% lift in conversions versus alternatives like "Pick our most popular activity ever", "Pick an activity at random", and "Pick Patrick's guess at what would convert best."
I took this a step further for a recent client with a low budget and used separate social sites to manage the content. I'm certainly not the first to do this, but it's worth mentioning as a viable alternative for a lot of smaller sites.
This particular client produces television advertisements. Videos are pulled in from Vimeo, photos and text updates are pulled from Tumblr. The API data is cached locally with serialized objects to keep it speedy.
Since they already had active accounts on both services, initial content population was minimal. We were even able to use categorization strategies already present on Vimeo to organize content.
Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.
Oh, c'mon. I was currently doing the exact same thing the blog post advices against.
I was designing, centralizing, decoupling. Then some changes came about. I implemented them, then watched them fluently rippling throughout the system. "How cool is that?".
It was some time ago when I was an OOP-design junkie (I think it's analogous to puberty: exaggerating). I think I passed that, as I frequently wonder if I'm over-designing and get back to using plain strings, constants etc.
I once read that, designing a plugin (be it a pattern or an actual plugin), try no less than 3 different implementations.
He's right, though. I work with Magento. Try adding a new backend form in that beast.
Imagine a code editor (probably embedded in some online where the developers would also work/code) that would show all the application code.
For developers, everything would be editable, so they could change logic, add logic, database calls, anything. On the other hand, for content editors, only strings (and arrays and numbers) would be editable. So the whole page would be freezed except for the parts between quotes. The developer could then hard-code these possibly-editable-values at code time (or leave them blank) and the non-developers edit them: categories, text content, values.
Hmm, there's those cases in which, to make use of database data, the code has to run into loops, checking and getting data from fields in which it was stored. This can be a problem, as developers using this metodology I'm describing would have to organize their code to handle static values just as if the values were being fetched from a database, but this problem must have a solution. I'll think about it.
You're talking out of my soul! I see this behavior many many times in the last 10 Years, i admit, i do the same long time ago ;-)
The problem for the mass of developers is, that they "fall in love" with their CMS and that make them blind for obvious things.
We shift away from CMS as central point for web and web-application. CMS is only a tool to maintain simple static data in various languages for many people.
For everything else (like shops) we use other systems, that are NOT a integrated part of a CMS.
If interaction between CMS and ohter systems is needed, implement a separate and clean API.
If there is a reasonable need for content editors to be able to update content in web site allowing them to do so in a quick and easy manner is a good idea.
Seeing this as easy, and building a custom application to handle it, will quickly become a bad idea, and an artifact of
"not build by me, I can build better" mentality.
Being able to leverage a tool that is both proven and easily available to solve this problem makes sense.
Expecting the cms to solve every problem and be the only tool used is also a big problem.
As to whether to provide the users with a means to define new pricing models and change current models, depends on how frequently it needs to get done, how much dev resources are needed to keep up with demand, and what the release process is like.
If you are in an enterprisy place. First an issue must be created to update the pricing model or create a new one.
This probably goes under change control, and it will be addressed in the next meeting of the governance committee.
If all is approved there it will be passed on to the project manager who will create a backlog item for it.
Then once the current sprint is completed, a new prioritized list of tasks are distributed and in the best scenario the issue is handed off to a developer with a high priority.
The developer will analyze what changes are needed, design the new pricing model, implement it, create and run unit tests, ensure it goes through CI. Then he will write the test cases for the new functionality and move on to the next issue in the back loc.
In 2-4 weeks when the sprint is over the worst case is that the dev branch is promoted and the test team is assigned an issue to test and regression test everything.
Once their sprint is done, it will be promoted to Staging
and more tests and sign offs and then after a month or two the new pricing model will hit the shelfs and the executive who requested it might already have forgotten why it was an issue to begin with, or the client he created it for has long gone with a different company
All of that to say sometimes it makes very good sense to create a decent way for the end users to be allowed to modify and create new pricing models.
Just like its easier to allow the end users to edit the content of web pages.
It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
I agree, what you are describing sounds like what I pointed out about bigger companies in the article. They not only can afford this, but they pursue this intentionally.
> It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
This I disagree with. An e-commerce system that deals with limited number of products (like a printing shop) could easily start with hardcoded base prices, it will be months of growth and rare pricing tweaks in code before this starts becoming an issue (based on my own experience).
[+] [-] danso|12 years ago|reply
I've made a few complex apps that use Google Spreadsheets as the backend...that is, to hold the public facing data and not, obviously, any proprietary data. This makes it very easy for those who have to maintain the app to enter in data. The downside is, of course, the inability to strongly enforce business rules and to denormalize things...but that forces me to reduce the data design to a bare minimum, which is often the best strategy in the first place.
I hope I never have to be in a situation where I'm building a CMS-type system for a client. People who haven't dealt with data-modeling or relational-databases don't appreciate simplicity...in the end, most people want something that they can type a headline, some text, and attach a photo or two (i.e. a Tumblr). But if you give them reins to design the system, they will inevitably want you to build them something Drupal like. In my experience, I've found that all these different content-relations end up being unused, and the client ends up hacking around them just to get a simple post up.
[+] [-] Udo|12 years ago|reply
The same goes for CMSes. Many CMS customers would probably be better off if they took the CMS editor interface as a separate component and wrote the actual page renderer as a custom development separately. The trouble is of course, content systems make it very hard to do that. Having to make things work with the native mechanisms (and the often horrific underlying data model) is what makes huge CMS projects fail or at least perform miserably for everyone involved.
On the very top of the list of abhorrently convolute CMSes would probably have to be Typo3, followed after some distance by Drupal. But the more you work with the initially-liberal Wordpress the more you discover it's not that far behind either.
This reminds me of a bygone era: my startup (now long gone) had its own CMS. Sadly, that wasn't our actual product as we were a pure service company and the CMS was only a tool for us. In hindsight, we should have done it the other way around. Our CMS wasn't perfect, but it shone in a few areas that made the life of both developers and content editors very easy: a simple, accessible data model and an easily extensible page renderer. Unlike many other solutions it was designed to get things done, not to bill a lot of consultant hours. I've yet to come across an open source (or commercial for that matter) CMS that works equally well.
[+] [-] brazzy|12 years ago|reply
It's about starting to build a specialized system and ending up building a generic CMS because of an urge to make everything runtime-configurable.
[+] [-] sygma|12 years ago|reply
[+] [-] Breefield|12 years ago|reply
I've been playing with their ruby-kit, so far so good, really liking this approach and plan to see awesome things ahead.
[+] [-] icedog|12 years ago|reply
[+] [-] foz|12 years ago|reply
At the start of this year, the company I work at had about six different CMS platforms. Many of the applications that used them were built on top of CMSs, and were tightly coupled to them. As for static content generators, we tried that. It really didn't scale, especially for dynamic content. Too many hacks, deploys, and hard to train people.
As of today, our team has switched nearly all public content for our company to LocomotiveCMS (http://www.locomotivecms.com/), and deployed a centralized multi-tenant system. In many cases, we use our Locomotive instances as an API, pushing content via the API or the command-line tool, wagon. The CMS then renders HTML templates (or even JSON), which are consumed by our applications via HTTP. Sometimes it's just a tiny part of a page, or sometimes entire mini-sites. As a result, most of our apps don't need to know about a database.
Whenever there's a change that requires a new model, or the addition of a field, it can be done quickly through the LCMS back-office UI (or the wagon CLI tool). We update the application(s) affected, and re-deploy. Non-techies can edit the content using the admin web UI in a familiar way.
In any case, it's been working really well for us. The CMS has become an API, a service, and a separate app, shared by many applications. We've become more flexible and efficient as a result, our web applications are no longer burdened by CMS frameworks or admin interfaces of their own. And we dont have to struggle with Sharepoint or Wordpress or any other nonsense.
It's been a fundamental shift in how we think about the CMS, and has scaled well across multiple projects.
[+] [-] cseelus|12 years ago|reply
[1] https://github.com/locomotivecms/engine
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] creativestuff|12 years ago|reply
A link to one of your apps/sites using this would be great.
[+] [-] did|12 years ago|reply
[+] [-] Kiro|12 years ago|reply
[+] [-] vinceguidry|12 years ago|reply
What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant.
I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears.
I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code.
Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.
[+] [-] bct|12 years ago|reply
[+] [-] jsdalton|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] gizzlon|12 years ago|reply
http://en.wikipedia.org/wiki/KISS_principle
[+] [-] maxk42|12 years ago|reply
Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file.
[+] [-] ams6110|12 years ago|reply
You can do all of these things with 100% test coverage, but that doesn't relieve you from dealing with the weight of the architecture and extra work when you try to add or change functionality later.
[+] [-] at-fates-hands|12 years ago|reply
This days if I have a static site around 10 pages, I just use .Net MVC project and use partial views to store the content. Much easier than using a CMS and I still retain all the control I want.
[+] [-] Pxtl|12 years ago|reply
Replace YAML with XML and you've just described every enterprise software library I've ever used ever.
[+] [-] Domenic_S|12 years ago|reply
The right tool for the right job.
[+] [-] patio11|12 years ago|reply
I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating.
BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #1 to a different creative in a few days have been worth, guesstimating a number here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For the last couple of weeks, most teachers have been in the market for Thanksgiving bingo cards. This will not be true in a few days. The #1 URL, which I use for many of my campaigns, uses some really dead simple heuristics to guess which creative to show people. The heuristic was worth > 10% lift in conversions versus alternatives like "Pick our most popular activity ever", "Pick an activity at random", and "Pick Patrick's guess at what would convert best."
http://www.bingocardcreator.com/lp/try_online
http://www.bingocardcreator.com/lpc/thanksgiving <-- There are actually about ~900 landing pages like this, which is a trick that few people manage if they do them in static HTML.
[+] [-] tcdent|12 years ago|reply
This particular client produces television advertisements. Videos are pulled in from Vimeo, photos and text updates are pulled from Tumblr. The API data is cached locally with serialized objects to keep it speedy.
Since they already had active accounts on both services, initial content population was minimal. We were even able to use categorization strategies already present on Vimeo to organize content.
[+] [-] outworlder|12 years ago|reply
Jekyll would disagree.
[+] [-] na85|12 years ago|reply
I think this pretty neatly summarizes my experience working with Drupal.
[+] [-] SolarUpNote|12 years ago|reply
[+] [-] dreamfactory|12 years ago|reply
[+] [-] kenster07|12 years ago|reply
[+] [-] AsymetricCom|12 years ago|reply
[+] [-] paulftw|12 years ago|reply
[+] [-] nevvvermind|12 years ago|reply
I was designing, centralizing, decoupling. Then some changes came about. I implemented them, then watched them fluently rippling throughout the system. "How cool is that?".
It was some time ago when I was an OOP-design junkie (I think it's analogous to puberty: exaggerating). I think I passed that, as I frequently wonder if I'm over-designing and get back to using plain strings, constants etc.
I once read that, designing a plugin (be it a pattern or an actual plugin), try no less than 3 different implementations.
He's right, though. I work with Magento. Try adding a new backend form in that beast.
[+] [-] fiatjaf|12 years ago|reply
Imagine a code editor (probably embedded in some online where the developers would also work/code) that would show all the application code.
For developers, everything would be editable, so they could change logic, add logic, database calls, anything. On the other hand, for content editors, only strings (and arrays and numbers) would be editable. So the whole page would be freezed except for the parts between quotes. The developer could then hard-code these possibly-editable-values at code time (or leave them blank) and the non-developers edit them: categories, text content, values.
[+] [-] fiatjaf|12 years ago|reply
[+] [-] prottmann|12 years ago|reply
The problem for the mass of developers is, that they "fall in love" with their CMS and that make them blind for obvious things.
We shift away from CMS as central point for web and web-application. CMS is only a tool to maintain simple static data in various languages for many people. For everything else (like shops) we use other systems, that are NOT a integrated part of a CMS.
If interaction between CMS and ohter systems is needed, implement a separate and clean API.
[+] [-] lifeisstillgood|12 years ago|reply
- all content served as json through a REST interface
- all content created in best way possible and reduced to either static json or Dbase backed templates
- content has metadata to keep it indexed
[+] [-] ThinkBeat|12 years ago|reply
Seeing this as easy, and building a custom application to handle it, will quickly become a bad idea, and an artifact of "not build by me, I can build better" mentality.
Being able to leverage a tool that is both proven and easily available to solve this problem makes sense.
Expecting the cms to solve every problem and be the only tool used is also a big problem.
As to whether to provide the users with a means to define new pricing models and change current models, depends on how frequently it needs to get done, how much dev resources are needed to keep up with demand, and what the release process is like.
If you are in an enterprisy place. First an issue must be created to update the pricing model or create a new one. This probably goes under change control, and it will be addressed in the next meeting of the governance committee.
If all is approved there it will be passed on to the project manager who will create a backlog item for it.
Then once the current sprint is completed, a new prioritized list of tasks are distributed and in the best scenario the issue is handed off to a developer with a high priority.
The developer will analyze what changes are needed, design the new pricing model, implement it, create and run unit tests, ensure it goes through CI. Then he will write the test cases for the new functionality and move on to the next issue in the back loc.
In 2-4 weeks when the sprint is over the worst case is that the dev branch is promoted and the test team is assigned an issue to test and regression test everything.
Once their sprint is done, it will be promoted to Staging and more tests and sign offs and then after a month or two the new pricing model will hit the shelfs and the executive who requested it might already have forgotten why it was an issue to begin with, or the client he created it for has long gone with a different company
All of that to say sometimes it makes very good sense to create a decent way for the end users to be allowed to modify and create new pricing models.
Just like its easier to allow the end users to edit the content of web pages.
It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
[+] [-] hakunin|12 years ago|reply
> It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
This I disagree with. An e-commerce system that deals with limited number of products (like a printing shop) could easily start with hardcoded base prices, it will be months of growth and rare pricing tweaks in code before this starts becoming an issue (based on my own experience).
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mavhc|12 years ago|reply