concrete5 vs. drupal
Permalink 3 users found helpful
Okay. Andrew and I get asked this all the time, and to be blunt - I don't know or care. I stopped paying attention after Mambo because I was building earlier versions of concrete.. I've watched the admin/editing process on drupal sites over shoulders - but that's about where my expertise ends.
So I need your help ex-drupal-ites.. how does it compare?
What's easier about either?
What's different about building for them?
How could you help someone else with the learning curve?
How would you compare the core feature set?
So I need your help ex-drupal-ites.. how does it compare?
What's easier about either?
What's different about building for them?
How could you help someone else with the learning curve?
How would you compare the core feature set?
You get flare.
You speak mighty fine for a man on meds.
You speak mighty fine for a man on meds.
:::response from a non-programmer:::
You asked: What's easier about either?
c5 is easier for: getting into admin; adding pages; adding blocks; adding text/content; adding themes; making themes; setting preferences; modifying; customizing; navigating; understanding it; (let me think for a few more minutes)
I was first interested in using drupal because it was supposed to do the things i needed it to do, but i couldn't ever get it to do them.
You asked: What's different about building for them?
Prob can't really answer this one; i didn't build for drupal and prob won't do much that would qualify as building for c5 beyond my elementary attempts at templating.
You asked: How could you help someone else with the learning curve?
Write tutorials -- lots of them. Maybe even some videos. um, assuming you mean the learning curve in switching to or using c5 - if you meant learning curve for drupal, well...i guess i'd just recommend switching to c5 and reading the c5 website.
You asked: How would you compare the core feature set?
Not sure.
drupal probably could do everything i'm looking for, but i couldn't do it myself.
with c5, i can probably do everything myself. as jereme mentioned, it took me all of about 30 minutes to figure out how to make a restricted area on my site. i'm sure drupal has this capability, but i never got far enough to figure it out.
i had a hard time getting some of drupal's extensions to work, but there's none of that going on in c5.
i would have to compare c5 more to wordpress in terms of usability, ease of modification, and just plain fun to use. i like to play with the stuff i like to play with, but i don't want to have to waste my time on getting things to function correctly.
In terms of accessibility, c5 wins hands down. no contest.
You asked: What's easier about either?
c5 is easier for: getting into admin; adding pages; adding blocks; adding text/content; adding themes; making themes; setting preferences; modifying; customizing; navigating; understanding it; (let me think for a few more minutes)
I was first interested in using drupal because it was supposed to do the things i needed it to do, but i couldn't ever get it to do them.
You asked: What's different about building for them?
Prob can't really answer this one; i didn't build for drupal and prob won't do much that would qualify as building for c5 beyond my elementary attempts at templating.
You asked: How could you help someone else with the learning curve?
Write tutorials -- lots of them. Maybe even some videos. um, assuming you mean the learning curve in switching to or using c5 - if you meant learning curve for drupal, well...i guess i'd just recommend switching to c5 and reading the c5 website.
You asked: How would you compare the core feature set?
Not sure.
drupal probably could do everything i'm looking for, but i couldn't do it myself.
with c5, i can probably do everything myself. as jereme mentioned, it took me all of about 30 minutes to figure out how to make a restricted area on my site. i'm sure drupal has this capability, but i never got far enough to figure it out.
i had a hard time getting some of drupal's extensions to work, but there's none of that going on in c5.
i would have to compare c5 more to wordpress in terms of usability, ease of modification, and just plain fun to use. i like to play with the stuff i like to play with, but i don't want to have to waste my time on getting things to function correctly.
In terms of accessibility, c5 wins hands down. no contest.
I’ve been in web development for nearly 10 years. In the last 2 years, I’ve started to work within open source content management systems. In the past, I had created my own CMS, more as a learning tool than anything, but soon realized the inherent drawbacks to having to custom created CMS for each client.
The company I worked for realized the mundane task of updated text and images on sites wasn’t really bringing us much money. It always seemed to take us away from the larger projects at hand. We also wanted our clients to feel empowered to make changes, and only need us for feature changes. This also meant that – like our managed web server – we didn’t want to have to manage the day to day of security updates.
Drupal – I was intrigued with the amazing amount of plugins available, readymade themes, promise of free (forums) and paid support (Acquia). To date I have created 6 websites using Drupal as the CMS. These sites range from fairly static portfolio pages, to somewhat intricate multiple user level corporate sites.
Concrete5 – C5… A coworker suggested I take a look at c5 about a few months ago. At first glance it felt a lot like silverstripe. If you haven’t tried out silverstripe, I think it compares to C5 more than Drupal or Joomla! (http://silverstripe.org/) at first glance. Note – I felt that silverstripe was a great framework – with a beautiful backend, but just didn’t seem ready for primetime compared to the competition. So that’s all I’ll mention about that. I’ve completed one site in C5, but have tinkered for a few months or so.
What's easier about either?
Drupal: When you need some seriously advanced functionality – there always seems to be a module that can handle that. If you need a template changed based on a user’s profile field – you can do that. If you need to redirect users after logging in based on their group – you can do that. You can make fairly complicated themes and customize them very heavily. If you need to have a block on every page, but not part of the template, you can do that. Drupal is deep, but there is the disadvantage. It is not out of the box ready for a website that expects clients to make changes. The taxonomy model is great, unless your client needs to update / change the vocabulary. I wouldn’t say it is easier – but in a way it is, since you can usually find a solution already made for what you want to do. And honestly – the documentation is huuuge. It’s everywhere online… which can sometimes be a problem, but you can pretty much hire Google as your tech support!
Concrete5: Anyone can update the site. Anyone can add a page. Anyone can modify the menu system. If you are comfortable with MS Office, then C5 will be easy to use. Blocks – it’s such a great system. Being able to drag and drop to move content. And the blocks that are standard pretty much cover 90% of what I’ll need. And the big one – updating modules and the core. Drupal requires you to backup your database, put your site into maintenance mode, delete your core, upload the new core, and run an update (multiple times possibly). Module are even less fun as you are supposed to disable them, backup database, put Drupal into maintenance mode, remove old module, add new module, enable module, run update… pray. Concrete5 is still not as good as Wordpress, but close. I would love my clients never to have to FTP… ever.
What's different about building for them?
Drupal: Drupal’s theming can be quite laborious. Once your theme is “perfect” a module that you add on will break it. As a previous poster noted – Drupal is not ready to go out of the box. This is both a blessing and a hinderance. I tend to use the same dozen or so module, so I pretty much have a base install that I use. With that said – I have to constantly update a dozen separate installs to make sure it is secure. Also – there can be three module (ie rich text editor) that all are very good, but work better for some users than others. You really have to know a lot of the module to know which work well with each other and which will be best for your client. Integrating module is also somewhat of a headache. Sometimes you have to add a module to integrate two others. Sometimes you have to install two modules so one will work.
Concrete5: Within 10 minutes I can have a website up and running. I can have the “architecture” (skeleton pages with lorum ipsem) and have a content person fill in the rest. If a client wants to have his form block below his navigation block, I drag and drop. With Drupal I would have to go into the block admin and move the block. Also – the standard themes with Concrete5 seem to be more realistic. I can actually use them and simply add content to start. I can tweak them with minimal effort. Also – converting a static HTML site to work with Concrete5 really seems to be straightforward. I never felt like I could go that direction with Drupal – so many tpl files everywhere. If I needed a two column page, I had to create a new theme, unless I wanted to code it into the RTE, but then that defeats the purpose.
How could you help someone else with the learning curve?
Drupal: I think everywhere you look; nobody is denying the learning curve is steep with Drupal. But – there are a ton of tutorials and a lot of people who are very willing to help you. There are also a lot of great books by actual publishers on the CMS.
Concrete5: Maybe it doesn’t really need as much documentation because it really is very intuitive. I would love a book on the CMS – I always like having something I can refer to while traveling or when I don’t feel like being in front of a computer. I’ve found the forums to be pretty responsive and most questions I had I was able to find an answer through Google or the forums. The biggest thing about Concrete5 is that I can use the base core and build a site that I can handoff to a client without any additional modules.
How would you compare the core feature set?
Drupal: limited! That’s pretty much it. Drupal has so many modules that make Drupal great, but I won’t even touch a standard install until I’ve put in about a dozen modules. But – once I’ve got those in place – it’s a contender.
Concrete5: Out of the box this thing is ready to go. I think that’s what I like so much – it just works.
Final words:
Drupal is a really great system, but takes some time to really get tweaked to work well. It has a very nice way of editing content, similar to Concrete5, but is still confusing for the end user. It has a lot of features, but you really have to dig in there to enable them, or install them.
For me – I like using Drupal for highly complex sites that I do not expect my clients to do much with (navigation / adding pages / adding functionality etc.).
I love Concrete5 for clients. There’s no question in my mind that my clients will feel more comfortable in Concrete5 vs. Drupal backend.
I haven’t had a chance to really see Concrete5 in a large “enterprise” environment, but from the OOP MVC code – and the minimal SQL queries per page (compared to Drupal’s), I envision it working very well.
Overall, if I wasn’t locked into Drupal, I would definitely put Concrete5 in my top three list of CMS offerings to my client.
The company I worked for realized the mundane task of updated text and images on sites wasn’t really bringing us much money. It always seemed to take us away from the larger projects at hand. We also wanted our clients to feel empowered to make changes, and only need us for feature changes. This also meant that – like our managed web server – we didn’t want to have to manage the day to day of security updates.
Drupal – I was intrigued with the amazing amount of plugins available, readymade themes, promise of free (forums) and paid support (Acquia). To date I have created 6 websites using Drupal as the CMS. These sites range from fairly static portfolio pages, to somewhat intricate multiple user level corporate sites.
Concrete5 – C5… A coworker suggested I take a look at c5 about a few months ago. At first glance it felt a lot like silverstripe. If you haven’t tried out silverstripe, I think it compares to C5 more than Drupal or Joomla! (http://silverstripe.org/) at first glance. Note – I felt that silverstripe was a great framework – with a beautiful backend, but just didn’t seem ready for primetime compared to the competition. So that’s all I’ll mention about that. I’ve completed one site in C5, but have tinkered for a few months or so.
What's easier about either?
Drupal: When you need some seriously advanced functionality – there always seems to be a module that can handle that. If you need a template changed based on a user’s profile field – you can do that. If you need to redirect users after logging in based on their group – you can do that. You can make fairly complicated themes and customize them very heavily. If you need to have a block on every page, but not part of the template, you can do that. Drupal is deep, but there is the disadvantage. It is not out of the box ready for a website that expects clients to make changes. The taxonomy model is great, unless your client needs to update / change the vocabulary. I wouldn’t say it is easier – but in a way it is, since you can usually find a solution already made for what you want to do. And honestly – the documentation is huuuge. It’s everywhere online… which can sometimes be a problem, but you can pretty much hire Google as your tech support!
Concrete5: Anyone can update the site. Anyone can add a page. Anyone can modify the menu system. If you are comfortable with MS Office, then C5 will be easy to use. Blocks – it’s such a great system. Being able to drag and drop to move content. And the blocks that are standard pretty much cover 90% of what I’ll need. And the big one – updating modules and the core. Drupal requires you to backup your database, put your site into maintenance mode, delete your core, upload the new core, and run an update (multiple times possibly). Module are even less fun as you are supposed to disable them, backup database, put Drupal into maintenance mode, remove old module, add new module, enable module, run update… pray. Concrete5 is still not as good as Wordpress, but close. I would love my clients never to have to FTP… ever.
What's different about building for them?
Drupal: Drupal’s theming can be quite laborious. Once your theme is “perfect” a module that you add on will break it. As a previous poster noted – Drupal is not ready to go out of the box. This is both a blessing and a hinderance. I tend to use the same dozen or so module, so I pretty much have a base install that I use. With that said – I have to constantly update a dozen separate installs to make sure it is secure. Also – there can be three module (ie rich text editor) that all are very good, but work better for some users than others. You really have to know a lot of the module to know which work well with each other and which will be best for your client. Integrating module is also somewhat of a headache. Sometimes you have to add a module to integrate two others. Sometimes you have to install two modules so one will work.
Concrete5: Within 10 minutes I can have a website up and running. I can have the “architecture” (skeleton pages with lorum ipsem) and have a content person fill in the rest. If a client wants to have his form block below his navigation block, I drag and drop. With Drupal I would have to go into the block admin and move the block. Also – the standard themes with Concrete5 seem to be more realistic. I can actually use them and simply add content to start. I can tweak them with minimal effort. Also – converting a static HTML site to work with Concrete5 really seems to be straightforward. I never felt like I could go that direction with Drupal – so many tpl files everywhere. If I needed a two column page, I had to create a new theme, unless I wanted to code it into the RTE, but then that defeats the purpose.
How could you help someone else with the learning curve?
Drupal: I think everywhere you look; nobody is denying the learning curve is steep with Drupal. But – there are a ton of tutorials and a lot of people who are very willing to help you. There are also a lot of great books by actual publishers on the CMS.
Concrete5: Maybe it doesn’t really need as much documentation because it really is very intuitive. I would love a book on the CMS – I always like having something I can refer to while traveling or when I don’t feel like being in front of a computer. I’ve found the forums to be pretty responsive and most questions I had I was able to find an answer through Google or the forums. The biggest thing about Concrete5 is that I can use the base core and build a site that I can handoff to a client without any additional modules.
How would you compare the core feature set?
Drupal: limited! That’s pretty much it. Drupal has so many modules that make Drupal great, but I won’t even touch a standard install until I’ve put in about a dozen modules. But – once I’ve got those in place – it’s a contender.
Concrete5: Out of the box this thing is ready to go. I think that’s what I like so much – it just works.
Final words:
Drupal is a really great system, but takes some time to really get tweaked to work well. It has a very nice way of editing content, similar to Concrete5, but is still confusing for the end user. It has a lot of features, but you really have to dig in there to enable them, or install them.
For me – I like using Drupal for highly complex sites that I do not expect my clients to do much with (navigation / adding pages / adding functionality etc.).
I love Concrete5 for clients. There’s no question in my mind that my clients will feel more comfortable in Concrete5 vs. Drupal backend.
I haven’t had a chance to really see Concrete5 in a large “enterprise” environment, but from the OOP MVC code – and the minimal SQL queries per page (compared to Drupal’s), I envision it working very well.
Overall, if I wasn’t locked into Drupal, I would definitely put Concrete5 in my top three list of CMS offerings to my client.
Wow thanks for the detailed post. I'd love it if you posted this to a blog or some entity NOT on concrete5.org. ;)
BTW: everything you mentioned drupal being able to do, concrete5 can as well.. change theme based on a custom attribute? no problem, you just gotta make it do that..
hopefully as we grow and the plethora of how-tos show up everywhere that youd expect, people will see this.
thanks again!
BTW: everything you mentioned drupal being able to do, concrete5 can as well.. change theme based on a custom attribute? no problem, you just gotta make it do that..
hopefully as we grow and the plethora of how-tos show up everywhere that youd expect, people will see this.
thanks again!
One of the things I love about Concrete is that you *can* override core code, but placing an identical file in the "/" file structure rather than the "/concrete/" file structure. This is perfect for when you need to do something truly advanced, but it preserves the core for when you're ready to upgrade. You can update and still have your customizations preserved, then you can check to see if your custom files need to be updated.
Almost anything you would ever need to do can be handled through the block/package system, but even if you really have to get down into the internals, you're never stuck with a possibly broken install that won't upgrade and won't work.
On the other hand, the attribute system is also so powerful, there practically isn't anything that you would want to do that you shouldn't be doing through your theme or a custom block or block template anyway :)
Almost anything you would ever need to do can be handled through the block/package system, but even if you really have to get down into the internals, you're never stuck with a possibly broken install that won't upgrade and won't work.
On the other hand, the attribute system is also so powerful, there practically isn't anything that you would want to do that you shouldn't be doing through your theme or a custom block or block template anyway :)
I created some Drupal sites a few times as well as Joomla sites but I wound up switching over to Concrete 5 because it was simpler all the way around, for myself and my clients.
I actually took an expensive workshop given by one of the guys who "wrote the book on Drupal". It was hosted by someone who had just finished doing multiple sites on Drupal for a Fortune 100 company which was expected to get millions of users. We had a book reviewer there as well who had extensive experience with Drupal. All were great, knowledgeable guys. We spent at least 20-30 minutes trying to figure out why the alternate language option didn't work on a fresh install of Drupal. Then we tried to do an upgrade using the upgrade tool Drush. This worked but had to be done multiple times to do a clean upgrade and was very complex in places.
Did I mention that Drupal constantly rolls out fixes to its core? This is a good and bad thing (see above experience with upgrading, lol).
I thought to myself, that if people who have years of experience with this CMS are having difficulty with things that are fairly standard, what will my long-term experience be like? In a word, frustrating.
This isn't to say that Drupal can't work well. I believe it can. It has a strong community, many free add-ons, an interesting and useful taxonomy structure available (I personally find it obtuse though) and it's good for a webmonkey to know professionally, since many design houses and companies are Drupal based.
I also have mixed feelings about the free add-ons. They're great because they're free for the most part, but then there's no real incentive for devs to keep them up to date with the latest versions of the core; which roll out quite often I might add...
With that said, I believe it's a CMS by IT people for IT people, and not so much for your average user.
EDIT: one of the reasons I created an install video tutorial for Concrete5 was that drupal.org had an install video which really helped me get started.
I actually took an expensive workshop given by one of the guys who "wrote the book on Drupal". It was hosted by someone who had just finished doing multiple sites on Drupal for a Fortune 100 company which was expected to get millions of users. We had a book reviewer there as well who had extensive experience with Drupal. All were great, knowledgeable guys. We spent at least 20-30 minutes trying to figure out why the alternate language option didn't work on a fresh install of Drupal. Then we tried to do an upgrade using the upgrade tool Drush. This worked but had to be done multiple times to do a clean upgrade and was very complex in places.
Did I mention that Drupal constantly rolls out fixes to its core? This is a good and bad thing (see above experience with upgrading, lol).
I thought to myself, that if people who have years of experience with this CMS are having difficulty with things that are fairly standard, what will my long-term experience be like? In a word, frustrating.
This isn't to say that Drupal can't work well. I believe it can. It has a strong community, many free add-ons, an interesting and useful taxonomy structure available (I personally find it obtuse though) and it's good for a webmonkey to know professionally, since many design houses and companies are Drupal based.
I also have mixed feelings about the free add-ons. They're great because they're free for the most part, but then there's no real incentive for devs to keep them up to date with the latest versions of the core; which roll out quite often I might add...
With that said, I believe it's a CMS by IT people for IT people, and not so much for your average user.
EDIT: one of the reasons I created an install video tutorial for Concrete5 was that drupal.org had an install video which really helped me get started.
Both are Great, but some things are missing on C5.
1. CCK.
Think of creating custom 'modules' on browser. e.g.
A portfolio module is same as news module, with some different fields. A blog module is same as portfolio, and on and on.
Forms module does perfect job, it was never that easy to create any custom form. What if you have something that easy to create custom content. Just like you create a form and you name it, you create a custom content block like:
Add new custom block
Name it Portfolio
Add fields that you need
Save it
Add page,
Add block to Main
Choose portfolio item
fill the fields, add images or videos
save it.
Boom that's it.
This could really be killer feature, and will let designers to create whatever they want without even seeing the code. Even wordpress has a good one, check this video:http://vimeo.com/10187055
2.ACL
If I want let a journalist to be able to add news only on Tech, normally I would go to ACL and check only that Category for that user. Drupal has done this right. Every module has access control.
In c5 thats is not possible because c5 doesnt work like that. I dont know if it can be tweaked but for now its hard to achieve that.
With those features C5 will be for any type of website, because depends of what website you create you choose what cms to use.
1. CCK.
Think of creating custom 'modules' on browser. e.g.
A portfolio module is same as news module, with some different fields. A blog module is same as portfolio, and on and on.
Forms module does perfect job, it was never that easy to create any custom form. What if you have something that easy to create custom content. Just like you create a form and you name it, you create a custom content block like:
Add new custom block
Name it Portfolio
Add fields that you need
Save it
Add page,
Add block to Main
Choose portfolio item
fill the fields, add images or videos
save it.
Boom that's it.
This could really be killer feature, and will let designers to create whatever they want without even seeing the code. Even wordpress has a good one, check this video:http://vimeo.com/10187055
2.ACL
If I want let a journalist to be able to add news only on Tech, normally I would go to ACL and check only that Category for that user. Drupal has done this right. Every module has access control.
In c5 thats is not possible because c5 doesnt work like that. I dont know if it can be tweaked but for now its hard to achieve that.
With those features C5 will be for any type of website, because depends of what website you create you choose what cms to use.
I like working with concrete5 more because it is so straightforward. For example, you mention that having something like CCK would be useful because you could create an arbitrary grouping of content -- but this seems unnecessary to me in many situations -- why not just add a page, add a content block, add an image block, and add a video block?
If you do need your content to be more structured, you can create your own block that requires certain fields and interacts with the search index in certain ways.
Drupal is a powerful system but I believe that concrete5's strength is that it conforms to the mental model that most non-technical users have about their website -- that everything revolves around the page, and you just add different content to each page -- not setting up a database.
As for point #2, concrete5 does have an "advanced permissions" mode which I believe lets you set access permissions for any group to any page/block/function, etc.
If you do need your content to be more structured, you can create your own block that requires certain fields and interacts with the search index in certain ways.
Drupal is a powerful system but I believe that concrete5's strength is that it conforms to the mental model that most non-technical users have about their website -- that everything revolves around the page, and you just add different content to each page -- not setting up a database.
As for point #2, concrete5 does have an "advanced permissions" mode which I believe lets you set access permissions for any group to any page/block/function, etc.
Check out custom attributes, I think they solve much of the same problem that CCK does..
And yeah, advanced permissions.
And yeah, advanced permissions.
How does C5 compare to D7's rdfa, web semantics, html5 (with modules) integration into core? This is imo the future of relevant content on the web. From my playing around with C5, the cms is powerful and easy to use. It's just not as powerful as Drupal...yet. One plus Drupal over C5 is every module made for Drupal is free!
Hmm. Well I'm no Drupal expert, I'd love to hear from one. ;)
You actually can build quite a lot of beefy stuff with concrete5 pretty easily. I'd certainly agree that not as many people know how to do it right as should, but I think thats a communication issue more than an architectural one.
I don't see keeping your marketplace non-monitized and forced GPL as an advantage. It strikes me as more advantageous to give our 3rd party developers some real motivation to provide great support. I'm a firm believer in not welding the car's hood shut, but I live in reality so the whole "everything in life should always cost nuthing" thing kinda falls flat. Freemium? Sure.
I am happy to see that drupal7 has some take on in-context editing. From what I've gathered its really feels more like a redirect to help you get to the right spot in the backend from the front end, but still, that's the right idea. It seems like not having in-context editing as a fundamental approach is akin to arguing for a typesetting machine over a word processor.. Why force someone to use one tool for reading and another for writing unless you absolutely have to.
Really IMHO any CMS comes down to the relationship between a site editor/owner and a site developer. If you don't serve both parties interests well, in the end you're not really providing that valuable of a long term solution. It's my belief concrete5 today does a better job of sitting in the middle of that balance than drupal does or ever will. I've never heard a site owner who wasn't a developer fawn over how much they love editing their site with drupal, but I do hear from designers, developers, and complete technophobe site owners how much concrete5 has made their lives easier..
I feel like if we keep on the path we're on, and simply continue to show people how much power really is available under the hood, we'll do just fine..
All that high level junk out of the way, I would love to hear from someone who has more of a technical understanding of both.
You actually can build quite a lot of beefy stuff with concrete5 pretty easily. I'd certainly agree that not as many people know how to do it right as should, but I think thats a communication issue more than an architectural one.
I don't see keeping your marketplace non-monitized and forced GPL as an advantage. It strikes me as more advantageous to give our 3rd party developers some real motivation to provide great support. I'm a firm believer in not welding the car's hood shut, but I live in reality so the whole "everything in life should always cost nuthing" thing kinda falls flat. Freemium? Sure.
I am happy to see that drupal7 has some take on in-context editing. From what I've gathered its really feels more like a redirect to help you get to the right spot in the backend from the front end, but still, that's the right idea. It seems like not having in-context editing as a fundamental approach is akin to arguing for a typesetting machine over a word processor.. Why force someone to use one tool for reading and another for writing unless you absolutely have to.
Really IMHO any CMS comes down to the relationship between a site editor/owner and a site developer. If you don't serve both parties interests well, in the end you're not really providing that valuable of a long term solution. It's my belief concrete5 today does a better job of sitting in the middle of that balance than drupal does or ever will. I've never heard a site owner who wasn't a developer fawn over how much they love editing their site with drupal, but I do hear from designers, developers, and complete technophobe site owners how much concrete5 has made their lives easier..
I feel like if we keep on the path we're on, and simply continue to show people how much power really is available under the hood, we'll do just fine..
All that high level junk out of the way, I would love to hear from someone who has more of a technical understanding of both.
I find drupal hard to learn from a beginners point of view (maybe it's changed, I don't really know) but at the end of the day I rather hand over a CMS to my non-geek clients and say call me if you need help, and they never call...
So maybe there are some advantages over drupal but the one thing is the MP, I've was trying to use one app that was developed but the developer left and it broke my site. In the long run if its paid it's going to work and to fix a broken site isn't that fun especially when it's 3am on a Sunday.
But its all personal preference in the end. But c5 is better :P
So maybe there are some advantages over drupal but the one thing is the MP, I've was trying to use one app that was developed but the developer left and it broke my site. In the long run if its paid it's going to work and to fix a broken site isn't that fun especially when it's 3am on a Sunday.
But its all personal preference in the end. But c5 is better :P
I would like to point out that there is a huge difference in what Drupal's marketplace offers (and how) and Concrete5's.
The first point - not every module is free. I have had to pay for modules for Drupal (and especially Joomla), and the support was horrific, the payment processing was sketchy, and it has been over a year without any update to the module. The module is completely incompatible with drupal 7, and so there is no option for future upgrade. With Concrete5, if I'm buying a module, I know there is support, I trust the buying process, and there is a single unified area for support. If the developer doesn't give support, I feel confident that the Concrete5 team will do what they can to help.
CCK - As Frz wrote about - you can use attributes, or if you want the CCK style - use something like the data display module:http://www.concrete5.org/marketplace/addons/data-display/...
However, you could always make a page type using your existing template, and simply modify and limit the types of blocks... In my opinion, it's a much cleaner and more straightforward approach. CCK always felt clunky to me, and never felt like a true end user tool, but a shortcut for developing out content for a data entry employee.
I spent a few years developing in Drupal, it took one Concrete5 site to draw me away.
-Phil
The first point - not every module is free. I have had to pay for modules for Drupal (and especially Joomla), and the support was horrific, the payment processing was sketchy, and it has been over a year without any update to the module. The module is completely incompatible with drupal 7, and so there is no option for future upgrade. With Concrete5, if I'm buying a module, I know there is support, I trust the buying process, and there is a single unified area for support. If the developer doesn't give support, I feel confident that the Concrete5 team will do what they can to help.
CCK - As Frz wrote about - you can use attributes, or if you want the CCK style - use something like the data display module:http://www.concrete5.org/marketplace/addons/data-display/...
However, you could always make a page type using your existing template, and simply modify and limit the types of blocks... In my opinion, it's a much cleaner and more straightforward approach. CCK always felt clunky to me, and never felt like a true end user tool, but a shortcut for developing out content for a data entry employee.
I spent a few years developing in Drupal, it took one Concrete5 site to draw me away.
-Phil
I'm quite new with C5 (refugee from CMS Made Simple) and really like the community and support which I receive. (I bought ecommerce add-on and today we'll buy some more...)
Although I'm open-source supporter and mostly use free software (I bought VueScan), I do not have against buying some add-ons and getting nice support instead of being treated as 3rd class citizen (by some devs in some other community) who are arrogant due to providing some free modules for their beloved CMS.
As far as Drupal, it's really bloated while working in C5 one has a feeling like swimming smoothly in a refreshing water.
We'll buy blog module and then write more about our excitement with C5. ;)
Although I'm open-source supporter and mostly use free software (I bought VueScan), I do not have against buying some add-ons and getting nice support instead of being treated as 3rd class citizen (by some devs in some other community) who are arrogant due to providing some free modules for their beloved CMS.
As far as Drupal, it's really bloated while working in C5 one has a feeling like swimming smoothly in a refreshing water.
We'll buy blog module and then write more about our excitement with C5. ;)
Strange - I've been using Drupal for years and never had to pay for a module. I've paid bounties to have modifications made to an existing module that I needed for a specific project, or for a new one to be built that didn't exist and I didn't want to build myself, but never for an existing module. It's true that support for a module is different for every module and ranges from instant response to nonexistant, but I figure I can't complain when I get it for free. Any time I've paid bounties the support has been good. Different experience I guess.
This isn't entirely relevant but I came across this while trying to come to terms with Drupal 7 .. in the Drupal overview it states:
'To make the contrast between Drupal and other CMS's more concrete' ..
No pun intended hey? =) Honestly I don't think it's hard to see which CMS had the biggest influence on Drupal 7 .. congratulations frz !
'To make the contrast between Drupal and other CMS's more concrete' ..
No pun intended hey? =) Honestly I don't think it's hard to see which CMS had the biggest influence on Drupal 7 .. congratulations frz !
Interesting post, thanks for this. I currently solely develop for Drupal and have for years (versions 5, 6 and 7 in the past, 6 and 7 only now). I am about to finish a site someone else abandoned in Concrete 5 - I will be using this project to evaluate whether there are times it would be beneficial to build in this system, and will post my evaluation here soon - hopefully it will be helpful to have a response from someone that develops primarily in Drupal as the people that responded so far either develop exclusively or mostly in C5.
@sandermartijn : I'd love to hear an honest compare and contrast with someone who's been pretty happy with drupal. please post after you've given things a try. :)
Will do for sure. What I can do right now is explain my commitment to Drupal. To me there is nothing worse than saying no to a client halfway through a project. Saying "it can't be done" or "it will cost you more" at the start isn't that much better. With Drupal these things almost never happen - if it can be done, it can be done in drupal - and by building every site in it I run across the same issues on every site I build so I know what to do right away instead of hacking through it. A good example is that 2 days ago a client asked me to add a second language to the site within 2 weeks. I got a bit nervous as I hadn't done an i18n site in drupal yet, but said sure, it can be done. It's done, and works flawlessly. That said, it's not a perfect CMS and many of the complaints on this page are valid - for a list of my personal drupal gripes, check out this post I wrote back in July on a day I was more frustrated than others:http://thoughts.sander-martijn.com/2011/03/drupal-gripes.html...
I'll be eager to hear your thoughts when your done. Please do share
questions as you go - we approach problems quite differently with
concrete5 so I'd hate to see you spin your gears.
For you and any other drupal experts who are listening. I've got lots
of karma points and perhaps even some cash for anyone who wants to
help write a concrete5 for Drupal developers document. Just PM me.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
questions as you go - we approach problems quite differently with
concrete5 so I'd hate to see you spin your gears.
For you and any other drupal experts who are listening. I've got lots
of karma points and perhaps even some cash for anyone who wants to
help write a concrete5 for Drupal developers document. Just PM me.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Thanks for the input sander! I'm interested in this since I'm leading a meetup group topic in the next few weeks where I'm going to be comparing and contrasting the major open source CMS's with various people. Of course, Concrete 5 is getting a strong mention among a few others....
I've done a tiny bit of Drupal work and even taken a workshop in it and the biggest challenge seems to be maintaining compatibility with updates to the core with 3rd party modules. Drush seems to help, yes? Of course, that was a few years ago and I know this is actually always a challenge with whatever CMS you choose. It just seems to take some hardcore PHP teams to maintain or the ability to write your own custom modules and keep up with upgrades.
I've had a enterprise site Drupal product manager describe to me that it's more of a robust content framework than a content management system. Is that an accurate depiction?
It does sound like it can be an excellent choice for corporate enterprise sites. Is there a minimum team number you think that needs to maintain a [ EDIT: large ] site or can an individual get away with doing most upgrades? Just trying to get a feel for how viable a choice it is for a single developer with moderate PHP skills.
I've done a tiny bit of Drupal work and even taken a workshop in it and the biggest challenge seems to be maintaining compatibility with updates to the core with 3rd party modules. Drush seems to help, yes? Of course, that was a few years ago and I know this is actually always a challenge with whatever CMS you choose. It just seems to take some hardcore PHP teams to maintain or the ability to write your own custom modules and keep up with upgrades.
I've had a enterprise site Drupal product manager describe to me that it's more of a robust content framework than a content management system. Is that an accurate depiction?
It does sound like it can be an excellent choice for corporate enterprise sites. Is there a minimum team number you think that needs to maintain a [ EDIT: large ] site or can an individual get away with doing most upgrades? Just trying to get a feel for how viable a choice it is for a single developer with moderate PHP skills.
I don't really see how "robust content framework" is all that different from CMS - sounds like smart martketing to me.
I'm generally of the mindset that if it's not broken, don't fix it. Therefore unless there's a major security problem (something which has plagued Drupal much less frequently than other systems I've worked with), once I launch the site I pretty much spin it off to the client and only get involved if something is broken or they want a new feature.
I can build even large sites by myself in a short time. Occasionally I'll outsource parts to another developer to meet deadlines or simply because I need a module developed and I don't like building them - but it's rare enough and small enough bits that the client generally doesn't even know I did it. 99% of the time it's just me and a designer though. How many people it takes on the client side to maintain content updates is up to them and depends on frequency of change.
I do have a standard set of modules I install on every site I build to get me started, and that helps speed things up - but there have been fairly sizable sites that I've been able to build out in 3 days and then hand it off to the client for content entry.
I'm generally of the mindset that if it's not broken, don't fix it. Therefore unless there's a major security problem (something which has plagued Drupal much less frequently than other systems I've worked with), once I launch the site I pretty much spin it off to the client and only get involved if something is broken or they want a new feature.
I can build even large sites by myself in a short time. Occasionally I'll outsource parts to another developer to meet deadlines or simply because I need a module developed and I don't like building them - but it's rare enough and small enough bits that the client generally doesn't even know I did it. 99% of the time it's just me and a designer though. How many people it takes on the client side to maintain content updates is up to them and depends on frequency of change.
I do have a standard set of modules I install on every site I build to get me started, and that helps speed things up - but there have been fairly sizable sites that I've been able to build out in 3 days and then hand it off to the client for content entry.
Well, I'm tardy to the party, but I'll just echo the point that, when I show clients (especially those who have never used a CMS before) C5 versus Drupal or Wordpress, they just "get it" right away.
It's a bonus to me that C5 features things like MVC architecture, OOP, easy/sane theming and an intuitive Admin/Dashboard UI.
It's a bonus to me that C5 features things like MVC architecture, OOP, easy/sane theming and an intuitive Admin/Dashboard UI.
Two things about Drupal I loved:
1) Drupal has an awesome developer's module which helps with displaying messages, etc during development.
2) There is a strong separation between the theming and modules. I've noticed with C5 that there is often code, like forms, embedded directly into a view.
I have recently switched to C5 and love it. It's backend is much easier for clients, handles media well, and its a breath of fresh air working with an OO platform.
1) Drupal has an awesome developer's module which helps with displaying messages, etc during development.
2) There is a strong separation between the theming and modules. I've noticed with C5 that there is often code, like forms, embedded directly into a view.
I have recently switched to C5 and love it. It's backend is much easier for clients, handles media well, and its a breath of fresh air working with an OO platform.
I dabbled with Drupal and Wordpress for a while until I found Concrete 5.
For me and my clients, Concrete 5 is hands down the easiest to use. My clients love it. The site I built for Gaia Wind was originally done in Drupal and when we re-designed it and used C5, my client was overjoyed. The changes they make on a daily basis take a fraction of the time it used too. The learning curve is just so much smaller for site owners.
I have yet to meet a client who has not complained about Drupal or Wordpress in some way, but I have yet to hear a bad word about C5 from them.
Client is king, and if the majority love it then thats what we will use.
From my point of view, when working with Drupal or Wordpress you have to design a site to work with them. With C5 I can design what the hell I want and C5 just slots in with ease.
For me and my clients, Concrete 5 is hands down the easiest to use. My clients love it. The site I built for Gaia Wind was originally done in Drupal and when we re-designed it and used C5, my client was overjoyed. The changes they make on a daily basis take a fraction of the time it used too. The learning curve is just so much smaller for site owners.
I have yet to meet a client who has not complained about Drupal or Wordpress in some way, but I have yet to hear a bad word about C5 from them.
Client is king, and if the majority love it then thats what we will use.
From my point of view, when working with Drupal or Wordpress you have to design a site to work with them. With C5 I can design what the hell I want and C5 just slots in with ease.
I'd love to see this conversation get a bit more technical. I think we all get why concrete5 rocks, I'm really interested in someone who canhelp us write a 10 page PDF - "concrete5 for drupal devs".
Best wishes
Pecked out on an iPhone
Best wishes
Pecked out on an iPhone
I have been developing in Drupal for the past six months for my job. It is great for its powerfully functionality. It is not considered a CMS as C5 or Joomla even though it was considered to be a competitor. If we could compare Drupal Gardens to C5, I feel that is a better comparision.
The benchmarks that I have ran, Drupal can parse large amounts of data rather quickly. I personally think that it has been more of a pain then anything. I am a programmer and designer. As a programmer, it is greater for building applications more than a stand alone CMS. The basic CMS functionality that it does do, takes some diving into and the modules tend to repeat the cores functionality but it makes it more user friendly. So to use Drupal, basically you do have to know PHP and then Drupal has its on API to do something simple like adding javascript to a page.
If someone knows an editor that supports Drupal API, I would love to know because I could use it!
That is my take on Drupal. It is a good developing tool but not a CMS like C5 that we can pass off to our clients and its really easy to use. I tried programming a contextual menu in drupal for our clients and it has been nothing but difficult. What should have taken an hour or two, took two days but that is when I first started in Drupal.
I don't know if that was technical enough but C5 is relatively close to Drupal. Just some minor algorithm changes and you could catch it but as even for loading times, C5 is faster when there is no extra db's involved. So if you address the speeds in parsing data from other databases, you will pass Drupal all around.
I do like C5 better and we are pushing for this at my work! So keep up the great work!
The benchmarks that I have ran, Drupal can parse large amounts of data rather quickly. I personally think that it has been more of a pain then anything. I am a programmer and designer. As a programmer, it is greater for building applications more than a stand alone CMS. The basic CMS functionality that it does do, takes some diving into and the modules tend to repeat the cores functionality but it makes it more user friendly. So to use Drupal, basically you do have to know PHP and then Drupal has its on API to do something simple like adding javascript to a page.
//Standard JQuery and how it should work: $(document).ready(function(){ //Do SOME AMAZING STUFF }); //Drupal's way: drupal_add_js('(function($){//Do some something amazing});','inline');
If someone knows an editor that supports Drupal API, I would love to know because I could use it!
That is my take on Drupal. It is a good developing tool but not a CMS like C5 that we can pass off to our clients and its really easy to use. I tried programming a contextual menu in drupal for our clients and it has been nothing but difficult. What should have taken an hour or two, took two days but that is when I first started in Drupal.
I don't know if that was technical enough but C5 is relatively close to Drupal. Just some minor algorithm changes and you could catch it but as even for loading times, C5 is faster when there is no extra db's involved. So if you address the speeds in parsing data from other databases, you will pass Drupal all around.
I do like C5 better and we are pushing for this at my work! So keep up the great work!
Thanks!
There's a lot of performance cleanup going on under the hood in the
next version, along with an even more friendly UI, so keep tuned! ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
There's a lot of performance cleanup going on under the hood in the
next version, along with an even more friendly UI, so keep tuned! ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Well this is a big topic so realistically I think even a summary version is going to run more in the range of 100 pages then 10. Maybe that is partly because Drupal is "big", and it has a lot of features.
Here is one technical point I'll focus on. In Drupal everything is a module. It is modular to the core. Drupal system itself is a module named system. And then the core modules, are just regular modules the same as any custom module. So Drupal starts with 1 module, adds required core modules (such as User, Taxonomy), then optional core modules, and finally custom and contributed modules.
Drupal modules build on each other, and in many cases a large module will contain sub-modules. For instance Drupal Ubercart is the most popular eCommerce module, and it is a set of several modules. And dozens of developers have built additional sub-modules that add to or change the base functionality of Ubercart.
C5 Packages are roughly equivalent to a Drupal Module. They serve a similar purpose of providing functionality that can be reused. The difference though is not everything in the C5 system is run by Packages. In fact at install there are 0 Packages in use. So you can run a site without Packages. Hence the use of the term "add-ons" in the C5 Marketplace. They really are add-ons that you use only if needed. Further it appears to me that Packages aim to be "complete" in solving a specific problem or providing a set of functionality. This differs from the approach in Drupal where many modules are like jigsaw pieces which can fit in with other pieces.
It is this jigsaw piece effect that we see in Drupal that is a blessing and a curse. On one hand it sounds great that there is such strong collaboration that hundreds of developers produce dozens of modules to do something. The problem however is that this approach tends to lead to the "30 modules and none of them work" scenario.
Here is an example of Drupal modular hell. Suppose you want to send monthly HTML emails from your site. Drupal supports mailing, and maybe you want to even send some of your site content in that mailer. Great idea, and there are about 20+ modules that aim to support that category. The problem is, none of them actually does the full job from A-Z. There are about 6 modules that create HTML email sending support, but don't actually send mail... they do various technical things like preparing headers and checking formats and such. Then there is SimpleNews, which gives management options for newsletters, but doesn't actually send them. Then there are various modules for management of subscribers, which don't send mail either because they only handle users. Then there are modules that provide forms for signing up for newsletters. And then there are about a dozen modules that just adjust/extend/change how these other modules work. Bottom line is you need about 12 modules to create a fully working HTML mailing system. Inevitably there is no chance of these 12 modules playing nicely together and fully meeting requirements, so you're certain to need at least a week for configuration/debugging, and another week or more for customization. In most real projects, you'll probably end up wondering why you didn't just build a fully custom mailing system because it might have been faster. But that wouldn't be modular or Drupalish.
Of course not every functional category is like this in Drupal. There are highs and lows in coverage depending on what you're trying to do. One thing I can say though, is I've installed over 500 modules in Drupal, and 0 of them actually did 100% of what was needed on any project with any level of requirements. So it's never possible to expect that you can install/configure/launch, you are certain to need to extend/debug/program most modules you use in Drupal.
What about in C5? How often, realistically, do Packages serve to fit a real set of requirements without significant coding or adaptation?
Here is one technical point I'll focus on. In Drupal everything is a module. It is modular to the core. Drupal system itself is a module named system. And then the core modules, are just regular modules the same as any custom module. So Drupal starts with 1 module, adds required core modules (such as User, Taxonomy), then optional core modules, and finally custom and contributed modules.
Drupal modules build on each other, and in many cases a large module will contain sub-modules. For instance Drupal Ubercart is the most popular eCommerce module, and it is a set of several modules. And dozens of developers have built additional sub-modules that add to or change the base functionality of Ubercart.
C5 Packages are roughly equivalent to a Drupal Module. They serve a similar purpose of providing functionality that can be reused. The difference though is not everything in the C5 system is run by Packages. In fact at install there are 0 Packages in use. So you can run a site without Packages. Hence the use of the term "add-ons" in the C5 Marketplace. They really are add-ons that you use only if needed. Further it appears to me that Packages aim to be "complete" in solving a specific problem or providing a set of functionality. This differs from the approach in Drupal where many modules are like jigsaw pieces which can fit in with other pieces.
It is this jigsaw piece effect that we see in Drupal that is a blessing and a curse. On one hand it sounds great that there is such strong collaboration that hundreds of developers produce dozens of modules to do something. The problem however is that this approach tends to lead to the "30 modules and none of them work" scenario.
Here is an example of Drupal modular hell. Suppose you want to send monthly HTML emails from your site. Drupal supports mailing, and maybe you want to even send some of your site content in that mailer. Great idea, and there are about 20+ modules that aim to support that category. The problem is, none of them actually does the full job from A-Z. There are about 6 modules that create HTML email sending support, but don't actually send mail... they do various technical things like preparing headers and checking formats and such. Then there is SimpleNews, which gives management options for newsletters, but doesn't actually send them. Then there are various modules for management of subscribers, which don't send mail either because they only handle users. Then there are modules that provide forms for signing up for newsletters. And then there are about a dozen modules that just adjust/extend/change how these other modules work. Bottom line is you need about 12 modules to create a fully working HTML mailing system. Inevitably there is no chance of these 12 modules playing nicely together and fully meeting requirements, so you're certain to need at least a week for configuration/debugging, and another week or more for customization. In most real projects, you'll probably end up wondering why you didn't just build a fully custom mailing system because it might have been faster. But that wouldn't be modular or Drupalish.
Of course not every functional category is like this in Drupal. There are highs and lows in coverage depending on what you're trying to do. One thing I can say though, is I've installed over 500 modules in Drupal, and 0 of them actually did 100% of what was needed on any project with any level of requirements. So it's never possible to expect that you can install/configure/launch, you are certain to need to extend/debug/program most modules you use in Drupal.
What about in C5? How often, realistically, do Packages serve to fit a real set of requirements without significant coding or adaptation?
I found this really interesting, cheers.
I've not ever used Drupal for a proper project, but from playing around with it I do remember the concepts of modules and 'nodes' (I think) - these terms seemed very broad and meaningless, making it hard to understand their context. The word Taxonomy seemed really out of place. It put me off.
Terminology is something that I think is absolutely critical to get right in a CMS, in particular because non-programmers are going to use it. If I'm talking a client through a system over the phone, the concepts of pages and blocks makes perfect sense to them, they 'get' the terms. This is something I think that Concrete5 has done very well. Thinking about common terms concrete5 uses:
Pages - people understand this straight away, and when looking at a sitemap, they understand it. When I've used Wordpress, I've had trouble explaining that some pages are posts, while others are pages. Concrete5 treats nearly all website pages as, well, pages.
Blocks - the blocks you add to a page are actually rectangular... like a physical object, they are shape of a block. It works as a concept. I REALLY dislike how Joomla for example calls the same kind of thing 'Modules'. The word module is something I've seen government groups overuse because they are too lazy to come up with a more descriptive term. It's so generic, I'm very glad c5 doesn't use it.
Areas, - no problems here. Same with the word 'Global'.
Packages - a package is wrapped up, containing one or more things, yes, this makes sense to me, as a package is something that can have a theme, block or other stuff in it.
Add-on - I've noticed that concrete5 uses this term over plug-in or extensions. These words are all pretty interchangeable I guess.
Page Types - This seems descriptive enough. The term categories isn't used in concrete5, instead using page types and the placement of pages to categorise pages.
Attributes - Non-programmers seem to understand this pretty quickly, some extra detail about something, whether a page, user or something like a product. The only thing I could see a little confusing is that attributes are located within Properties in the interface. You've got Page Properties but then Custom Attributes. In some ways it should be 'Standard Attributes', as it's all metadata about a page in the end. Maybe.
File Sets - I think some people might have trouble with this because they're not familiar with the term from more of the mathematical point of view. I see the term 'label' in something like gmail as very similar.
Dashboard - This uses perhaps the car metaphor, something that displays information. A car's dash has controls to change settings. So this makes sense. What I also like is that it's a noun. I can tell a client 'go to the Dashboard', instead of 'go to the Administration' - administration is more of a task than a place.
The more abstract programming concepts (like 'collection' objects) are very much hidden from the interface.
So I've liked concrete5's naming conventions from the start, they're not too abstract and generic.
Just some thoughts!
I've not ever used Drupal for a proper project, but from playing around with it I do remember the concepts of modules and 'nodes' (I think) - these terms seemed very broad and meaningless, making it hard to understand their context. The word Taxonomy seemed really out of place. It put me off.
Terminology is something that I think is absolutely critical to get right in a CMS, in particular because non-programmers are going to use it. If I'm talking a client through a system over the phone, the concepts of pages and blocks makes perfect sense to them, they 'get' the terms. This is something I think that Concrete5 has done very well. Thinking about common terms concrete5 uses:
Pages - people understand this straight away, and when looking at a sitemap, they understand it. When I've used Wordpress, I've had trouble explaining that some pages are posts, while others are pages. Concrete5 treats nearly all website pages as, well, pages.
Blocks - the blocks you add to a page are actually rectangular... like a physical object, they are shape of a block. It works as a concept. I REALLY dislike how Joomla for example calls the same kind of thing 'Modules'. The word module is something I've seen government groups overuse because they are too lazy to come up with a more descriptive term. It's so generic, I'm very glad c5 doesn't use it.
Areas, - no problems here. Same with the word 'Global'.
Packages - a package is wrapped up, containing one or more things, yes, this makes sense to me, as a package is something that can have a theme, block or other stuff in it.
Add-on - I've noticed that concrete5 uses this term over plug-in or extensions. These words are all pretty interchangeable I guess.
Page Types - This seems descriptive enough. The term categories isn't used in concrete5, instead using page types and the placement of pages to categorise pages.
Attributes - Non-programmers seem to understand this pretty quickly, some extra detail about something, whether a page, user or something like a product. The only thing I could see a little confusing is that attributes are located within Properties in the interface. You've got Page Properties but then Custom Attributes. In some ways it should be 'Standard Attributes', as it's all metadata about a page in the end. Maybe.
File Sets - I think some people might have trouble with this because they're not familiar with the term from more of the mathematical point of view. I see the term 'label' in something like gmail as very similar.
Dashboard - This uses perhaps the car metaphor, something that displays information. A car's dash has controls to change settings. So this makes sense. What I also like is that it's a noun. I can tell a client 'go to the Dashboard', instead of 'go to the Administration' - administration is more of a task than a place.
The more abstract programming concepts (like 'collection' objects) are very much hidden from the interface.
So I've liked concrete5's naming conventions from the start, they're not too abstract and generic.
Just some thoughts!
I do believe the things that drew me to Concrete5 and repelled me from Drupal fall into the same category.
1. ACL - Concrete5 makes access control as complex or as simple as you want it. On the surface layer it is very easy to create a group, give that group access to interact with a certain page hierarchy or individual page, and then add users to that group.
I never was able to lock down a specific user to a specific area in Drupal. That's not to say it is or isn't possible. It's just that I, an accomplished software developer (whatever that is worth), could not figure it out in a reasonable amount of time. In Concrete5 I had it figured out in about 10 minutes
2. Templating - Concrete5 is very accomdating. You can prototype and HTML your site just like it's flat, and then easily define the content areas with your design. The rest takes place within the Concrete5 UI, which means almost anyone who can edit a word doc can get in and edit the site from there.
With Drupal you must understand Drupal's concepts of templates deeply. Nothing is intuitive. You are practically forced to reverse engineer existing templates to get anywhere. Simple modifications wind up being anything but simple.
3. Speed to launch - There's an awful lot of front-work you have to do for drupal just to prepare an install to accept a site. I'm sure the regular Drupal developer preconfigures an installation to their taste and then just uses that each time.
Once Concrete5 is installed, you're only a step away from adding content to your site. That step is to convert your HTML templates to a theme. The curve is very short. I've taken PSD's all the way to working Concrete5 install+theme in a matter of 2 hours. (http://boostfoundation.org).
4. Extendability - I have to admit I never got this far with Drupal. However, I can praise Concrete5's concept of blocks, and a fairly solid and simple MVC framework to build them in. I completed and installed my first Concrete5 Block in less than half a day. Perhaps the most experienced Drupal developer could compete, but I'll be dollars to donuts that my user experience feels much better, and I didn't have years of Concrete5 development under my belt to get there. I'm not even a PHP developer normally (Mostly Ruby & Perl here).
5. Useability - This is the bread and butter. Concrete5 is so usable that my clients can save their budget and come to me with the high profile projects that I enjoy instead of the tedious tasks of changing a word here or an image there. Even better, they can do it with the confidence that if they fail, they are protected by Concrete5's amazing version control.
6. Design concept - Drupal is a portal that can function as a CMS. Joomla! is a portal that can function as a CMS. Wordpress is a blog that can hobble as a CMS. Notice a pattern?
Concrete5 is a CMS from the ground up. It can be made to do other things, or can be easily interfaced with prexisting systems. It can actually function quite well as a portal, and does OK as a blog. However as a CMS it excels light years beyond the competition.
So as you read this, you need to ask yourself what kind of tool you're wanting to pull out when you reach into the toolbag. If Content Management is your goal, you couldn't do better.
Next time someone shows you an awesome Drupal site, ask them how long it took them to get there. Ask them if they had a marinated Drupal install they started with. I think you'll be shocked about how much time it really took.