Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CMS Trap

hakunin.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: CMS Trap

#51

Post by Udo »

brazzy wrote: post #50
Udo wrote: post #45

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 with…

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.

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.

Re: CMS Trap

#52

Post by sdoering »

hakunin wrote: post #31
Breefield wrote: post #30

Earlier quoted context omitted.

[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 concent…

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.

Re: CMS Trap

#53

Post by did »

cseelus wrote: post #41
foz wrote: post #38

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 th…

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 cle…

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 :-)

Re: CMS Trap

#54

Post by sygma »

Udo wrote: post #45

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 with…

Why not open source your CMS and breathe some new life into it?

Re: CMS Trap

#55

Post by lifeisstillgood »

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

Re: CMS Trap

#56

Post by Udo »

sygma wrote: post #54
Udo wrote: post #45

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 with…

Why not open source your CMS and breathe some new life into it?

I have a history of building stuff that nobody's interested in, so I'm trying to cut down on that... Don't give me ideas ;)

Re: CMS Trap

#57

Post by mavhc »

ie. Don't write a programming language when you're supposed to be writing an application.

Re: CMS Trap

#58

Post by ThinkBeat »

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.

Re: CMS Trap

#59

Post by hakunin »

ThinkBeat wrote: post #58

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 m…

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).

Re: CMS Trap

#60

Post by nevvvermind »

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.

Post reply on HN