CMS Trap(hakunin.com)
hakunin.com
CMS Trap
http://hakunin.com/cms-trap
19 comments
The article is NOT about building systems on top of a regular CMS.
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.
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.
From the article:
"It’s the passion that makes us lose sight of the danger looming ahead, the trap we’re edging towards thanks to our subjective assumptions and vague speculation, the trap of building a overdesigned and overcomplicated system for its own sake. A CMS trap"
and, to address your objection:
"When you are asked to build an app with something like Drupal, you are in a whole different realm, where the CMS trap is pretty much your perpetual state of being."
As I said I would broaden the discussion even further. Over-design and over-complication is very much the hallmark of pretty much any CMS I have come across. The system becomes the biggest hinderance in respect to the realization of content and functionality. This IS pretty much what the article is about. It deals at length with unsuitable customization decisions.
"It’s the passion that makes us lose sight of the danger looming ahead, the trap we’re edging towards thanks to our subjective assumptions and vague speculation, the trap of building a overdesigned and overcomplicated system for its own sake. A CMS trap"
and, to address your objection:
"When you are asked to build an app with something like Drupal, you are in a whole different realm, where the CMS trap is pretty much your perpetual state of being."
As I said I would broaden the discussion even further. Over-design and over-complication is very much the hallmark of pretty much any CMS I have come across. The system becomes the biggest hinderance in respect to the realization of content and functionality. This IS pretty much what the article is about. It deals at length with unsuitable customization decisions.
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.
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.
[1] https://github.com/locomotivecms/engine
[1] https://github.com/locomotivecms/engine
hey, I'm Didier from LocomotiveCMS.
From a person outside the project, I understand that you may have been under the impression that the CMS did not evolve quicly enough. But believe me, we were working just as hard on it.
Actually, you cannot have a clear look at the project activity just based on the Engine github repository because LocomotiveCMS is relatively a big project, made of many different components (Wagon, CustomFields, Engine). Besides, I even don't include the documentation site which has been greatly improved recently and it takes a long time to write documentation. A lot of work for a very small team :-)
I've been working on this project for years and for free and no project is sustainable in those conditions. That's why I decided to grow the business and to develop the commercial side of LocomotiveCMS. So we launched LocomotiveHosting this summer. And it goes well beyond hosting. It also gives you access to free upgrades and premium support. Moreover, the hosting solution relies on the same version of the engine. The slight difference is that we add maintenance functionalities like site backup on the fly.
LocomotiveHosting is an option. You can still host your sites on your servers, so this should not deter you from using our CMS. But we really appreciate it when our users sign up to LocomotiveHosting because this helps fund the development of new features.
We also provide consultancy for our CMS :-)
From a person outside the project, I understand that you may have been under the impression that the CMS did not evolve quicly enough. But believe me, we were working just as hard on it.
Actually, you cannot have a clear look at the project activity just based on the Engine github repository because LocomotiveCMS is relatively a big project, made of many different components (Wagon, CustomFields, Engine). Besides, I even don't include the documentation site which has been greatly improved recently and it takes a long time to write documentation. A lot of work for a very small team :-)
I've been working on this project for years and for free and no project is sustainable in those conditions. That's why I decided to grow the business and to develop the commercial side of LocomotiveCMS. So we launched LocomotiveHosting this summer. And it goes well beyond hosting. It also gives you access to free upgrades and premium support. Moreover, the hosting solution relies on the same version of the engine. The slight difference is that we add maintenance functionalities like site backup on the fly.
LocomotiveHosting is an option. You can still host your sites on your servers, so this should not deter you from using our CMS. But we really appreciate it when our users sign up to LocomotiveHosting because this helps fund the development of new features.
We also provide consultancy for our CMS :-)
[deleted]
Thanks! Would you please how you handle SEO this way? (I assumed you embed content on the client, but maybe you do it server-side?)
A link to one of your apps/sites using this would be great.
A link to one of your apps/sites using this would be great.
thanks @foz, I could not have explained better than you did ;-)
So you need to re-deploy for a simple typo fix?
hey @kiro, I'm Didier, creator of LocomotiveCMS (www.locomotivecms.com).
You do not need to re-deploy for a simple typo because the structure of your site and the content are definitely separated.
You or your content editor will use the user back-office to fix that typo.
However, if you want to change the layout or tweak the style, you have to use Wagon and its frontend tools (SASS, Compass, Less, Compass), make your changes, test them locally with the embedded web server in Wagon, commit them to git if you version your site structure and then deploy. The redeployment won't touch the live data unless you modified your data structure. Hope my answer was clear :-)
However, if you want to change the layout or tweak the style, you have to use Wagon and its frontend tools (SASS, Compass, Less, Compass), make your changes, test them locally with the embedded web server in Wagon, commit them to git if you version your site structure and then deploy. The redeployment won't touch the live data unless you modified your data structure. Hope my answer was clear :-)
Thanks for the answer! I will give Locomotive a try next time I need to install a new CMS.
No we normally never need to re-deploy the app for new content or edits. We treat Locomotive like a service: it provides us a customizable content API. So only in the case of breaking schema changes would we need to re-deploy.
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.
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.
>A CMS Trap is a state of a web-application in which the development of content management systems is obstructing the development of the content.
I think this pretty neatly summarizes my experience working with Drupal.
I think this pretty neatly summarizes my experience working with Drupal.
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.
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.
Ok. Here's an idea:
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.
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.
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.
I am going to look so silly :
- 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
- 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
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.
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).
> 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).
ie. Don't write a programming language when you're supposed to be writing an application.
Love of complexity is a programming disease.
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.
I optimistically called this Chester's First Law of Complexity:
Then I found out that Larry Wall had beaten me to it with the pithier much pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy Kolmogorov Complexity.
Essential complexity in the problem domain is a conserved quantity.
Then I found out that Larry Wall had beaten me to it with the pithier much pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy Kolmogorov Complexity.
That's why there's a distinction between 'accidental' complexity (poor architecture) and 'intrinsic' complexity (unavoidable)
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.
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.
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.
The right tool for the right job.
The right tool for the right job.
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."
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.
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.
I didn't read the OP as advocating 900 static HTML pages... just using static pages as a first strategy, until reality, not your conjecture, tells you what you need.
Perhaps it would make more sense to say "you don't have to use the same CMS for everything"
Can I check I've understood you right, Patrick?
You have some code that infers from usage that, for instance, civil rights cards are popular in late January (Martin Luther King Day is on January 20th)? Neat! :-)
You have some code that infers from usage that, for instance, civil rights cards are popular in late January (Martin Luther King Day is on January 20th)? Neat! :-)
Right idea, but I'm not sure it would work for your example. MLK Day for the longest time didn't work correctly. I had a string tied around my finger about that bug for 3 years, can't remember if I squashed it in January or not.
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.
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.
> If you're managing content (blog content?) use a CMS.
Jekyll would disagree.
Jekyll would disagree.
Jekyll is a CMS.
Jekyll is a static website generator. It doesn't let you edit and publish content from a central interface. It's not a CMS.
You could even simplify and say that Jekyll is a build script
It depends on what your needs are. If you need a central web interface with multi-stage workflows, multiple authors, image management, future publication, etc, then Jekyll isn't a CMS. But Jekyll focuses on content, handles markdown, reads metadata, and uses templates. For some people, that might be plenty. A pretty web interface isn't a must-have requirement.
> A pretty web interface isn't a must-have requirement.
According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.
According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.
Are there any CMS that have a "pretty web interface" ?
From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.
From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.
I like Plone a lot - it mixes the admin with the site itself.
CQ5 looks better (but isn't).
Oh, you.
@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.
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?
[edit] Apparently we may both be on the wrong page: https://twitter.com/hakunin/status/405874291100901376
Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concentrate on making your app work, not getting into the complexities of building/maintaining a custom CMS.
I mean, that's what the assertion that static is the way to go eludes to, unless I am incorrect about the entire point of the article. It's about not getting dragged into the bog of making a CMS.
The author outlines various scenarios: do it yourself, to building your complex app on a CMS (ugh), or just going back to static because it is the simplest, hardest to fuck up option. I don't think he explored the idea of content management as a service fully, which is why I brought up Prismic—it is another option, and in my opinion, a very good one.
Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concentrate on making your app work, not getting into the complexities of building/maintaining a custom CMS.
I mean, that's what the assertion that static is the way to go eludes to, unless I am incorrect about the entire point of the article. It's about not getting dragged into the bog of making a CMS.
The author outlines various scenarios: do it yourself, to building your complex app on a CMS (ugh), or just going back to static because it is the simplest, hardest to fuck up option. I don't think he explored the idea of content management as a service fully, which is why I brought up Prismic—it is another option, and in my opinion, a very good one.
I should've made it clearer, sorry. When referring to CMS in the article, I refer to the wider meaning of a content management system, the code that you write as a developer of your own site, which happens to manage your content. Not a CMS that one could download and install.
Funny thing. I understood your analogy just great. I just remembered all the situations, where we as a company were/are trapped with the CMS we've got.
So it worked for me as a editor gone code-writer as well as a editor gone conceptual project-lead.
So it worked for me as a editor gone code-writer as well as a editor gone conceptual project-lead.
I think the key question is: At what point is building a user interface more expensive than hiring a full time developer?
or buying a product
Back in the old days (2005) we used to call this Do the Simplest Thing That Could Possibly Work.
Or another way of looking at it: "You Ain't Gonna Need It" (http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
[deleted]
Or KISS: Keep it simple, stupid
http://en.wikipedia.org/wiki/KISS_principle
http://en.wikipedia.org/wiki/KISS_principle
[deleted]
I am SO sick of spending more time configuring the CMS than writing code.
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.
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.
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.
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.
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.
> 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.
Replace YAML with XML and you've just described every enterprise software library I've ever used ever.
Replace YAML with XML and you've just described every enterprise software library I've ever used ever.
Overengineered software systems are like sex - every generation thinks they invented it.
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.