5 ms·

Content management is very definitely NOT a solved problem. Even if you restrict the domain to just blogging software, there are a ton of unsatisfied people (m

Content management is very definitely NOT a solved problem. Even if you restrict the domain to just blogging software, there are a ton of unsatisfied people (myself included). Blogging software is still bad enough that a bunch of people are still writing their own. A possible solution is something that's more than a framework but less than a fully functioning software package. I think that's the general idea behind drupal, but during the limited time I spent with it I wasn't very impressed.

netcan 18y ago
I agree. There are also constant give/take issues attacking it: Simplicity vs This feature, Power vs Eas of Use, Good tools for non technical people vs Fexibility etc etc. None seem to have gotten it down yet. Basically I agree. Content management is a lot less solved then spreadsheets or word processing.
- mschwar99 18y ago
  "Good tools for non technical people vs Flexibility" Depending on the group of people using the installation I think this is huge. For user groups that include a big slice of non-technical people web interfaces still have a ways to go. Lots of businesses have spent big rolls on CMS deployments only to continue farming out the maintenance of content to web techs because the interface "wasn't enough like Word." Whichever companies develop platforms that Mom and Dad can use reliably will make a mint.
- narag 18y ago
  There are also constant give/take issues attacking it: Simplicity vs This feature, The obvious solution is to divide the software in two parts: a "framework" that takes care of storage, authentication, etc. and modules that implement features using the other part's API.
dasil003 18y ago
I've used Drupal for a few projects as well as having written more than a few CMS solutions from scratch in PHP and Rails. I share your dislike for Drupal, but I wouldn't go so far as to say it's unimpressive. My gut instinct is that Drupal is about as good a hybrid framework/CMS as you can get. That's not to say other approaches might not hit your or my sweet spots better, but fundamentally I think it's operating at the wrong level of abstraction. The problem is to give you anything that works out of the box a CMS has to make a ton of assumptions. Drupal goes to great lengths to make everything configurable and hookable. It's hard to come up with a use-case that can't be coded using Drupal hooks. The problem is you face the crushing weight of a system designed to meet the needs of any and all potential websites. Even though deep knowledge of the system allows you to do amazing things with very few lines of code, the system itself is a straitjacket where the cost of seemingly trivial customizations can be crippling. If you find yourself with a scalability problem that can't be solved with naive caching you may well be totally fucked. Contrast to web frameworks like Rails. The goal here is to give you a set of raw tools to make it easier to handle the trivial yet repetitive tasks that come up over and over again in web development. Unused features in Rails don't introduce cognitive load on the developer. If you've spent any time writing CGI scripts before then you can see the reason for almost every feature and design decision. It's possible to build a career on top of Drupal. Becoming expert in it will allow you to "solve" a wider range of client problems faster than any other CMS or Framework. The problem is that you have to embrace compromise at all levels. You will never create an amazing design in Drupal. You will never create a successful startup in Drupal. You will never write a lean and scalable site in Drupal. If you are willing to compromise you will find a huge swath of potential clients who think $1000 is a lot to pay for an e-commerce site or want a do-it-yourself solution with a little hand-holding.
- aasarava 18y ago
  "You will never create an amazing design in Drupal. You will never create a successful startup in Drupal. You will never write a lean and scalable site in Drupal." Can you substantiate these claims? It sounds a bit as if you're generalizing based on a bad experience in trying to use Drupal. And to be fair, Drupal does take a while to get used to -- you won't build an awesome site in the first week after untarring the package on your server. However, all of the following sites were built on Drupal -- and there is nothing intrinsically fixed about their designs or their ability to scale, etc.: -The Onion: http://www.theonion.com/ http://www.theonion.com/ -MTV UK: http://mtv.co.uk http://mtv.co.uk -Yahoo Research: http://research.yahoo.com/ http://research.yahoo.com/ -Ozzy Osbourne: http://www.ozzy.com/ http://www.ozzy.com/ -Moby: http://moby.com/ http://moby.com/
  - dasil003 18y ago
    I was a professional PHP developer for 4 years before picking up Drupal. I studied it. I read books on it. I built a half dozen sites with it. I participated in the forums. I submitted a couple patches. One thing I never did is "untar the package on the server" because I'm a real developer and of course I have my dev environment set up locally. Deployments are pulled from source control. My closing statements were definitely hyperbole, but I fundamentally stand by them, both as a web designer and a developer. My opinion comes from experience, which I believe is more informed than looking at a bunch of sites without knowing what went in to each one. The thing with Drupal is that it caters to generic needs very well. It will get you 95% of the way on any project with moderately standard functionality. However the last 5% includes fine design and usability touches that I take as a point of professional pride. I had one project where I built the whole thing in Drupal in about 20 hours. After crossing the finish line, the client was unhappy with the checkout flow from the e-commerce section. I wasn't happy with it either, but it was just the way the module worked. Although there was no reason we couldn't re-work the e-commerce module, there was no modularity or unit tests to help with this kind of refactoring. I estimated the rewrite to be somewhere in the 20-80 hour range given the potential for massive breakage. In the end we decided to cut our losses and spend 40 hours rewriting in Rails. We fixed a lot of other design details along the way, and we have a lean 2000-line code base that we could extend in any reasonable fashion. Sure we couldn't drop in a forum/gallery/blog/library at the drop of a hat, but is it more important to have a million pieces of generic functionality at the tip of your fingers or to get the core user experience correct? It's bad enough when you have to fight with the client to get the UI right, but what I find truly unbearable is when everyone's on the same page, the ideal UI is clear, the logic is simple, yet you're encumbered by technology that's designed to solve 1000 extra problems you don't have at all.

netcan 18y ago

I agree. There are also constant give/take issues attacking it: Simplicity vs This feature, Power vs Eas of Use, Good tools for non technical people vs Fexibility etc etc. None seem to have gotten it down yet. Basically I agree. Content management is a lot less solved then spreadsheets or word processing.

mschwar99 18y ago
"Good tools for non technical people vs Flexibility" Depending on the group of people using the installation I think this is huge. For user groups that include a big slice of non-technical people web interfaces still have a ways to go. Lots of businesses have spent big rolls on CMS deployments only to continue farming out the maintenance of content to web techs because the interface "wasn't enough like Word." Whichever companies develop platforms that Mom and Dad can use reliably will make a mint.
narag 18y ago
There are also constant give/take issues attacking it: Simplicity vs This feature, The obvious solution is to divide the software in two parts: a "framework" that takes care of storage, authentication, etc. and modules that implement features using the other part's API.

dasil003 18y ago

I've used Drupal for a few projects as well as having written more than a few CMS solutions from scratch in PHP and Rails. I share your dislike for Drupal, but I wouldn't go so far as to say it's unimpressive. My gut instinct is that Drupal is about as good a hybrid framework/CMS as you can get. That's not to say other approaches might not hit your or my sweet spots better, but fundamentally I think it's operating at the wrong level of abstraction. The problem is to give you anything that works out of the box a CMS has to make a ton of assumptions. Drupal goes to great lengths to make everything configurable and hookable. It's hard to come up with a use-case that can't be coded using Drupal hooks. The problem is you face the crushing weight of a system designed to meet the needs of any and all potential websites. Even though deep knowledge of the system allows you to do amazing things with very few lines of code, the system itself is a straitjacket where the cost of seemingly trivial customizations can be crippling. If you find yourself with a scalability problem that can't be solved with naive caching you may well be totally fucked. Contrast to web frameworks like Rails. The goal here is to give you a set of raw tools to make it easier to handle the trivial yet repetitive tasks that come up over and over again in web development. Unused features in Rails don't introduce cognitive load on the developer. If you've spent any time writing CGI scripts before then you can see the reason for almost every feature and design decision. It's possible to build a career on top of Drupal. Becoming expert in it will allow you to "solve" a wider range of client problems faster than any other CMS or Framework. The problem is that you have to embrace compromise at all levels. You will never create an amazing design in Drupal. You will never create a successful startup in Drupal. You will never write a lean and scalable site in Drupal. If you are willing to compromise you will find a huge swath of potential clients who think $1000 is a lot to pay for an e-commerce site or want a do-it-yourself solution with a little hand-holding.

aasarava 18y ago
"You will never create an amazing design in Drupal. You will never create a successful startup in Drupal. You will never write a lean and scalable site in Drupal." Can you substantiate these claims? It sounds a bit as if you're generalizing based on a bad experience in trying to use Drupal. And to be fair, Drupal does take a while to get used to -- you won't build an awesome site in the first week after untarring the package on your server. However, all of the following sites were built on Drupal -- and there is nothing intrinsically fixed about their designs or their ability to scale, etc.: -The Onion: http://www.theonion.com/ http://www.theonion.com/ -MTV UK: http://mtv.co.uk http://mtv.co.uk -Yahoo Research: http://research.yahoo.com/ http://research.yahoo.com/ -Ozzy Osbourne: http://www.ozzy.com/ http://www.ozzy.com/ -Moby: http://moby.com/ http://moby.com/
- dasil003 18y ago
  I was a professional PHP developer for 4 years before picking up Drupal. I studied it. I read books on it. I built a half dozen sites with it. I participated in the forums. I submitted a couple patches. One thing I never did is "untar the package on the server" because I'm a real developer and of course I have my dev environment set up locally. Deployments are pulled from source control. My closing statements were definitely hyperbole, but I fundamentally stand by them, both as a web designer and a developer. My opinion comes from experience, which I believe is more informed than looking at a bunch of sites without knowing what went in to each one. The thing with Drupal is that it caters to generic needs very well. It will get you 95% of the way on any project with moderately standard functionality. However the last 5% includes fine design and usability touches that I take as a point of professional pride. I had one project where I built the whole thing in Drupal in about 20 hours. After crossing the finish line, the client was unhappy with the checkout flow from the e-commerce section. I wasn't happy with it either, but it was just the way the module worked. Although there was no reason we couldn't re-work the e-commerce module, there was no modularity or unit tests to help with this kind of refactoring. I estimated the rewrite to be somewhere in the 20-80 hour range given the potential for massive breakage. In the end we decided to cut our losses and spend 40 hours rewriting in Rails. We fixed a lot of other design details along the way, and we have a lean 2000-line code base that we could extend in any reasonable fashion. Sure we couldn't drop in a forum/gallery/blog/library at the drop of a hat, but is it more important to have a million pieces of generic functionality at the tip of your fingers or to get the core user experience correct? It's bad enough when you have to fight with the client to get the UI right, but what I find truly unbearable is when everyone's on the same page, the ideal UI is clear, the logic is simple, yet you're encumbered by technology that's designed to solve 1000 extra problems you don't have at all.