Let's call C5 Packages, well, Packages!
Permalink
I'm never been fond of the word add-on. Is that a word, or is that two words? Is ADD ON grammatically correct? Probably not. If you start a sentence with it, should it have capitalization on the first word or both? Add-on for this, Add-On for that, land of many many addons. Arrrgh.
Where is the add-on folder in C5 anyway? Where might somebody go to find their installed addons?
Is the term add-on ever used inside C5 at all? Doesn't seem to be. So why not call Packages, Packages! I think people would be able to get that a "Package" is an add-on to a site. It would solve the awkwardness of the add-on terminology as well as being more literally correct.
I like the word package, especially in the C5 context. Because unlike Drupal modules or WP plugins, C5 packages really can be a collection of many different parts packaged together.
Does anyone else feel the same way?
Where is the add-on folder in C5 anyway? Where might somebody go to find their installed addons?
Is the term add-on ever used inside C5 at all? Doesn't seem to be. So why not call Packages, Packages! I think people would be able to get that a "Package" is an add-on to a site. It would solve the awkwardness of the add-on terminology as well as being more literally correct.
I like the word package, especially in the C5 context. Because unlike Drupal modules or WP plugins, C5 packages really can be a collection of many different parts packaged together.
Does anyone else feel the same way?
in my experience, customers understand the add-on terminology. it is essentially an add-on. add-on/extensions both mean the same thing and arguably plugin as well. they all describe their purpose. a package only describes that something is isolated.
from a developers perspective though, they come as a package. calling it package in code makes very much sense.
it's not that confusing really. it's not like a developer forgets that an add-on is a package in code and it's not like an editor that is looking for an add-on is ever gonna start coding but decide not to because they can't find the word add-on in code.
many things in different systems are referred to as different things within different contexts. and it makes sense because not everyone is a developer and not everyone is an editor.
from a developers perspective though, they come as a package. calling it package in code makes very much sense.
it's not that confusing really. it's not like a developer forgets that an add-on is a package in code and it's not like an editor that is looking for an add-on is ever gonna start coding but decide not to because they can't find the word add-on in code.
many things in different systems are referred to as different things within different contexts. and it makes sense because not everyone is a developer and not everyone is an editor.
I find it frustrating to have to talk about "add-ons/themes" any time I
want to describe what we sell.
I think the idea that "themes" just skin what exists, and "add-ons" create
new things that might need to be "themed" has merit because it matches what
tends to happen naturally technically.
Lines to become blurred over time however. As wordpress themes include more
customization functionality, as our themes include more blocks and custom
templates for other blocks. If joe-blow could get by without understanding
the difference, it would be great to just have a "marketplace" full of
"packages".
imo.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
want to describe what we sell.
I think the idea that "themes" just skin what exists, and "add-ons" create
new things that might need to be "themed" has merit because it matches what
tends to happen naturally technically.
Lines to become blurred over time however. As wordpress themes include more
customization functionality, as our themes include more blocks and custom
templates for other blocks. If joe-blow could get by without understanding
the difference, it would be great to just have a "marketplace" full of
"packages".
imo.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
I could quite happily be swayed either way on this.
Occasionally we see forum posts where someone has purchased a theme for manual installation and put it into the themes folder instead of the packages folder. I also observe that the usual documentation for many themes appearing in the prb starts by explaining that the theme needs to be installed in 'packages'. It is also common for theme packages to include a few blocks and templates, so encompassing addons.
So maybe fixing the confusion is more relevant to theme developers than addon developers.
If Franz decides that its all going to be 'packages' from now on, I see the main obstacle being the great legacy of existing core and addon/theme documentation that refers to addons and themes. Its a massive legacy of documentation that would need to be brought in line.
Maybe a fist step would be to remove the addon/theme split when you enter the marketplace section of concrete5.org and put them all in one common list with twice as many option filters on the sidebar.
Consider the work involved in making such a change. What other changes could be made for a similar amount of work? Which would provide the most benefit/payback?
If we were starting with a clean sheet, I would definitely say packages 100%. With a large legacy of existing documents, my opinion hovers 50/50 between sticking as we are and making a change.
Occasionally we see forum posts where someone has purchased a theme for manual installation and put it into the themes folder instead of the packages folder. I also observe that the usual documentation for many themes appearing in the prb starts by explaining that the theme needs to be installed in 'packages'. It is also common for theme packages to include a few blocks and templates, so encompassing addons.
So maybe fixing the confusion is more relevant to theme developers than addon developers.
If Franz decides that its all going to be 'packages' from now on, I see the main obstacle being the great legacy of existing core and addon/theme documentation that refers to addons and themes. Its a massive legacy of documentation that would need to be brought in line.
Maybe a fist step would be to remove the addon/theme split when you enter the marketplace section of concrete5.org and put them all in one common list with twice as many option filters on the sidebar.
Consider the work involved in making such a change. What other changes could be made for a similar amount of work? Which would provide the most benefit/payback?
If we were starting with a clean sheet, I would definitely say packages 100%. With a large legacy of existing documents, my opinion hovers 50/50 between sticking as we are and making a change.
Yeah I'm trying to not worry too much about the pain to change at this
point in planning for 5.7. That concern will raise its head later..
I dunno, the original idea was themes never touched content and add-ons
never touched design, but I'm not sure were delivering on that promise.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
point in planning for 5.7. That concern will raise its head later..
I dunno, the original idea was themes never touched content and add-ons
never touched design, but I'm not sure were delivering on that promise.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
To me it's a great selling point of C5 that "everything is in a package". I'm borrowing that phrase from the headline of this C5 Packt book by Remohttp://www.packtpub.com/article/everything-in-package-with-concrete...
That phrase stuck with me because the simplicity and power of packages are one of the great engineering marvels of the CMS world. I feel anybody working with WP or Drupal or many other systems today would be amazed if they could experience it. Overriding in most CMS's is a matter of hoping there is a hook or action somewhere in the code. And even if they puts hooks on every 3 lines of code, there are still times you wish the hook came one line sooner. Plus a CMS site developer might go insane reading the documentation about the endless options for hooks, preprocessors and actions. What a relief to just make a package, and put in whatever you need.
I'm not sure "absolute separation" of theming and function is practical or possible. Plenty of examples from every CMS of the powerful theme engine that breaks the rules but is really popular because it has more functionality, even if it should have that functionality from a technical perspective. The idea of such separation is valid, but the paradox is that you often gain a lot from bending or breaking that rule, if you view it as a rule. For instance I see many C5 themes create custom blocks or provide custom templates for blocks. In my first attempt at making a nice theme, right away I found making a custom autonav template was important to get the look I wanted with doing crazy CSS. And because "everything is in a package" it was simple and easy to do.
One of challenges that CMS's seem to face seems to be that addons/modules/plugins often don't get nicely styled by themes, because they are so "separate". Theme developers try, but cannot really predict what the output from a certain addon (that often hasn't yet been built) will be. And using generic classes to style common HTML, well that helps, but in Drupal that is done pretty consistently and yet most modules you install still need a lot of CSS to be written before you would consider them worthy of launching on a live site. Drupal as a community so much tends to discourage modules from providing any presentation code, it's rare to have any CSS in a module. Personally I'd like to see developers making things that look good on install, which is an idea better embraced in WP and the result is a lot of site owners can install WP plugins and feel good about using them right away.
So to summarize I think being able to bundle everything in a packages is great, because often when you want to create something it's does require both functionality and presentation.
I'll end by adding the suggestion that if you end up with a scenario where every "theme" package actually bundles a lot of stuff other than themes... you could make a rule that in the Themes List only packages that have themes are allowed. So a developer could create 2 versions perhaps, one that is theme-only and one that bundles the theme with other parts. That way we can still have a way to find theme-only packages.
That phrase stuck with me because the simplicity and power of packages are one of the great engineering marvels of the CMS world. I feel anybody working with WP or Drupal or many other systems today would be amazed if they could experience it. Overriding in most CMS's is a matter of hoping there is a hook or action somewhere in the code. And even if they puts hooks on every 3 lines of code, there are still times you wish the hook came one line sooner. Plus a CMS site developer might go insane reading the documentation about the endless options for hooks, preprocessors and actions. What a relief to just make a package, and put in whatever you need.
I'm not sure "absolute separation" of theming and function is practical or possible. Plenty of examples from every CMS of the powerful theme engine that breaks the rules but is really popular because it has more functionality, even if it should have that functionality from a technical perspective. The idea of such separation is valid, but the paradox is that you often gain a lot from bending or breaking that rule, if you view it as a rule. For instance I see many C5 themes create custom blocks or provide custom templates for blocks. In my first attempt at making a nice theme, right away I found making a custom autonav template was important to get the look I wanted with doing crazy CSS. And because "everything is in a package" it was simple and easy to do.
One of challenges that CMS's seem to face seems to be that addons/modules/plugins often don't get nicely styled by themes, because they are so "separate". Theme developers try, but cannot really predict what the output from a certain addon (that often hasn't yet been built) will be. And using generic classes to style common HTML, well that helps, but in Drupal that is done pretty consistently and yet most modules you install still need a lot of CSS to be written before you would consider them worthy of launching on a live site. Drupal as a community so much tends to discourage modules from providing any presentation code, it's rare to have any CSS in a module. Personally I'd like to see developers making things that look good on install, which is an idea better embraced in WP and the result is a lot of site owners can install WP plugins and feel good about using them right away.
So to summarize I think being able to bundle everything in a packages is great, because often when you want to create something it's does require both functionality and presentation.
I'll end by adding the suggestion that if you end up with a scenario where every "theme" package actually bundles a lot of stuff other than themes... you could make a rule that in the Themes List only packages that have themes are allowed. So a developer could create 2 versions perhaps, one that is theme-only and one that bundles the theme with other parts. That way we can still have a way to find theme-only packages.
for instance, if you navigate to Marketplace > Add Ons.... lol
I think the idea is that packages are packages. And there are two kinds of packages. Add-on packages and Theme packages. At least that's the way it is represented in the marketplace.