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.
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 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.
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 been playing with their ruby-kit, so far so good, really liking this approach and plan to see awesome things ahead.
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.
So it worked for me as a editor gone code-writer as well as a editor gone conceptual project-lead.
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.
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 :-)
A link to one of your apps/sites using this would be great.
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 :-)
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.
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.
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.
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.
Replace YAML with XML and you've just described every enterprise software library I've ever used ever.
The right tool for the right job.
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/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.
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! :-)
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.
Jekyll would disagree.
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.
From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.
I think this pretty neatly summarizes my experience working with Drupal.
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.
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.
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.
- 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
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.
> 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).