His discussion of editors' thought process about CMS tools and making site parts from apps sounds suspiciously like the reasoning over at the Lawrence Journal-World newspaper. I'm curious why their solution wasn't mentioned.
The CMS Is Broken.
31–40 of 57 posts
Re: The CMS Is Broken.
#32Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint…
> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.
I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either:
1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time?
2. He was just indicating that headline in position X be 20px, communicating with the layout.
3. He was hard-setting it to 20px.
It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.
Re: The CMS Is Broken.
#33The most complex piece of software I've worked on was a CMS. I spent a lot of time doing competitor evaluations, and, without fail, the only successful implementations were using small products in small workgroups. Trying to solve the "enterprise" problem always failed, both because the software became stupid complex and the processes became even worse.
I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.
Re: The CMS Is Broken.
#34Earlier quoted context omitted.
> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.
I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either: 1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time? 2. He was just indicating that headline i…
The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'.
BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3]
[1] http://www.youtube.com/watch?v=qjgQHzYcxIQ
Re: The CMS Is Broken.
#35The world of Content Management Systems is definitely an awkward place to be in, However, I don't think that the notion "The CMS Is Broken" is really justified.
I think the first major problem with CMS' is that people expect them to be the end all be-all solution to their site and content needs. Clients expect them to be an intuitive cheap publishing platform that will magically format, organize and display an endless array of content and content types, while developers expect them to be fast, easy to extend, scaleable, lightweight and fit a theoretical "goldilocks zone" of adhering to conventions but still being flexible.
To fix the client problem, clients need to understand software does not create good content for you. Content needs to be curated and software is there to help with the heavy lifting. Instead of forking out X amount of money on software, spend half that and spend the remaining half on writers, photographers and people to make your content great.
As for the software/development problem, each specific case can require a different platform. Just like one specific programming language is only one tool in the box, one CMS follows the same pattern. Educate yourself about all your tools and explain the pros/cons to the client before making a decision, but in the end, isn't that what were being paid to do?
Sorry if my comment is a little more about the business side of things and not necessarily about the CMS itself, but I feel its a pretty important point on this issue
Re: The CMS Is Broken.
#36Holy shit people still use Moveable Type?
NPR.org still uses it. And it's a great example of MT's potential.
Re: The CMS Is Broken.
#37Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint…
Hey Joel, I remember seeing this post on HN ages ago and tried to find the link recently :) I wanted to show this "api first" approach to someone who was building an XML API for Flash sites. I showed him the Decal API [1] but wanted to give him this as an example a well, thanks for reminding me!
[1] http://www.decalcms.com/page/Decal_API_Quick_Start_Guide
Re: The CMS Is Broken.
#38"Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren’t designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of prog…
Let me present the case of Ubercart as a counterpoint. It was the upcoming, loved by many e-commerce system built on top of Drupal. When I first looked at it in 2008, it was still in alpha. But it looked like having solid devs and good community behind it. So I jumped on it, built my site around it and even developed custom modules for it.
Fast forward to 2010. The project has forked and the main dev has gove over to develop the next generation of Drupal e-commerce system which is a completely separate project. It is only being developed for Drupal 7 and has no migration path from UC. I heard that someone from the original team is still continuing to work on Ubercart but the site has had no updates for about a year.
To put it in perspective, this leaves me with 2 options. One is to live with the old UC (which still lacked a lot of stuff since it was pretty much work in progress) and keep investing further in developing on it while knowing that underlying platform is dead. Or I can jump over to Drupal Commerce which would mean I would need to move to Drupal 7 which would mean porting all the rest of my custom development (which has nothing to do with e-commerce part) over to D7 which I had no need to! For those who do not know, Drupal does not maintain backward compatibility between major version upgrades.
Having said that, I don't have any gripes with UC devs. I have benefited from their hard work and thank them for that. I am just pointing out that even Drupal ecosystem is vulnerable to what the original article said.
Re: The CMS Is Broken.
#39"Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren’t designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of prog…
I was once tasked with upgrading a Drupal instance and while I surely don't have the experience you do I have opposing feelings about this. Some of Drupal's more popular plugins are certainly well maintained, but for this case (and I imaging somewhat commonly in the industry) they used numerous obscure plugins, some of which were only in "beta" stage. In checking the repo logs of these plugins it seemed as though some hadn't been maintained for years.
There is also no database restrictions placed on the plugins, so they could literally modify any database schema. Not only do plugin A and plugin B know about each other, they are required to know about each other to function correctly; and I see that as a problem. While it can be argued that this is part of what gives Drupal its power and flexibility, I see this power as a very dangerous thing in a community of its size. It almost requires developers to put out quality plugins which is often not the case (for Drupal as well as any other community driven software products).
Re: The CMS Is Broken.
#40Wasn't this exactly the problem that Django was originally trying to solve?
Indeed, Django was made for news rooms!
Certainly the whole "homepage is an app" concept maps perfectly onto Django's ontology of projects and applications.
The API, however, is not something that's built in. They might want to take a look at Ellington (http://www.ellingtoncms.com/).