Early Drupal 6 review from Chris Messina
Hello all, I asked Chris Messina (http://factoryjoe.com/blog/) to fiddle with Drupal 6 and to share his thoughts: http://factoryjoe.pbwiki.com/FeedbackForDrupal6 He has lots of good feedback so I encourage you to _bookmark_ that page. Some of his suggestions we might still be able to incorporate! I also invite you to ask others to write similar write-ups. They are invaluable. Thanks, -- Dries Buytaert :: http://www.buytaert.net/
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far from drupal's modeled form (IE: it suggest to set ajax checks in the installation, even if the site is not inttended to use ajax..) In any case, this review is really something to consider. On Nov 10, 2007 8:57 AM, Dries Buytaert <dries@buytaert.net> wrote:
Hello all,
I asked Chris Messina (http://factoryjoe.com/blog/) to fiddle with Drupal 6 and to share his thoughts:
http://factoryjoe.pbwiki.com/FeedbackForDrupal6
He has lots of good feedback so I encourage you to _bookmark_ that page. Some of his suggestions we might still be able to incorporate! I also invite you to ask others to write similar write-ups. They are invaluable.
Thanks,
-- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iñaki Lopez schrieb:
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far
Thanks for saying that. It is exactly how I felt about it, too.
from drupal's modeled form (IE: it suggest to set ajax checks in the installation, even if the site is not inttended to use ajax..)
In any case, this review is really something to consider.
True. But in some cases, it would maybe make more sense for an installation profile to follow the suggestions. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNbL9fg6TFvELooQRAlF4AKCJrpaw5GMzIyQS9hyREzVkGK0b2gCeLIUm K2OfmHFWHoZHTSBw0FjvLlE= =JGk0 -----END PGP SIGNATURE-----
True. But in some cases, it would maybe make more sense for an installation profile to follow the suggestions.
And thanks to you, because that was I realized after thinking about it. It's valuable information for stressing the installing profiles. I don't need a "more funny and complete" information in 'my account' space by default if I'm using drupal as a fronted only wihtout users. I agree in some of the terms, like "cron" and the mess between taxonomy/categories and vocabulary/topics, but thinking about it, drupal has it's own model, beggining with the so complicated to explain in two lines topic: "The node", so necessarily should have it's own terminology. On Nov 10, 2007 2:32 PM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Iñaki Lopez schrieb:
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far
Thanks for saying that. It is exactly how I felt about it, too.
from drupal's modeled form (IE: it suggest to set ajax checks in the installation, even if the site is not inttended to use ajax..)
In any case, this review is really something to consider.
True. But in some cases, it would maybe make more sense for an installation profile to follow the suggestions.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHNbL9fg6TFvELooQRAlF4AKCJrpaw5GMzIyQS9hyREzVkGK0b2gCeLIUm K2OfmHFWHoZHTSBw0FjvLlE= =JGk0 -----END PGP SIGNATURE-----
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far
Thanks for saying that. It is exactly how I felt about it, too.
- A lot of people come to Drupal from a blogging background. - A lot of what Chris said is valid for non-blogging contexts. Drupal 6 is what will be used in 2008 and possibly part of 2009. A *lot* of people will bump in exactly the issues that Chris highlighted. Let's not classify this feedback as irrelevant -- it's some of the most valuable usability feedback we've had in months. If people with a different background provide us feedback, we should also take that into account. -- Dries Buytaert :: http://buytaert.net/
Hi, I have to say that the feedback was valuable, and I don't feel that any of the posts before dismissed it as irrelevant. I saw your (Dries') presentation at the DrupalCon about the future of Drupal, and one thing is not clear, which I see being reflected here:
- A lot of people come to Drupal from a blogging background.
Whom do we want to make Drupal for? I think you can't provide a good blogging CMS and a generic usage content management system. For example see the popularity of Wordpress vs Joomla, loads of people use the first for blogging, but not for larger websites, and the contrary to Joomla.
- A lot of what Chris said is valid for non-blogging contexts.
Nonetheless what I wrote above, this is true.
Drupal 6 is what will be used in 2008 and possibly part of 2009. A *lot* of people will bump in exactly the issues that Chris highlighted. Let's not classify this feedback as irrelevant -- it's some of the most valuable usability feedback we've had in months.
My question is where do we draw the line for usability issues? When does complexity kneel before usability? For a generic CMS a more complex would be preferred, for blogs a simpler one. Should we start to think in Drupal distributions, targeted at each major audience? cheers, balazs
Quoting Balazs Dianiska <csillagasz@gmail.com>:
Whom do we want to make Drupal for?
Drupal is more than a CMS. It has a wonderful API that I'm using in batch processing with no user interface at all. Also, a CMS is more than blogging. Content is data presented in visual form. Drupal provides easy methods to display all sorts of data (more than just nodes) to the user. You just have to be able to think beyond the usual page and story that are the default uses. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Nov 10, 2007 2:12 PM, Dries Buytaert <dries.buytaert@gmail.com> wrote:
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far
Thanks for saying that. It is exactly how I felt about it, too.
- A lot of people come to Drupal from a blogging background.
- A lot of what Chris said is valid for non-blogging contexts.
Drupal 6 is what will be used in 2008 and possibly part of 2009. A *lot* of people will bump in exactly the issues that Chris highlighted. Let's not classify this feedback as irrelevant -- it's some of the most valuable usability feedback we've had in months.
If people with a different background provide us feedback, we should also take that into account.
I agreed with Chris on most of his points and am amazed at how important some of them are while requiring very little work. Even the changes where I disagreed with his point of view (and there were few) are examples of situations that deserve more attention. For example, he said about taxonomies "Okay, a term is clearly a category... but this is not clear from the labeling." Well, no - Categories contain Terms. But our use of Category/Vocabulary/Taxonomy to mean the container and Term/Tag for the specific label within the container really makes this confusing. His confusion here is a natural reaction and rather than ignoring it we should improve our consistent use of the right terms to prevent confusion. One topic that I'd like to discuss more is his point about the comment settings being a per content type option (search for the string OMGWTFBBQ). I, frankly, love this flexibility in Drupal6. However, I agree with him that the UI is overly complex. We really have to balance complexity of the interface with the desire to add features and flexibility. One thing I've been thinking about is how Firefox balances these two items. There are hundreds (thousands?) of settings in firefox (type about:config into your location bar to see many of them). You only see ~10% of them in the menu structure and dialog boxes while the rest are hidden in about:config or via files (e.g. changing your chrome/*css). most Firefox users will never use about:config or the chrome files. But for the 5% who use them, they are very important! Can and should we adopt this separation in Drupal? We already have some examples of variables which have no UI in core but can be enabled via a contributed module or via settings.php (e.g. dev_query). Should we take this further as a general system? I'm leaning towards yes, but want to know how other people feel. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
One thing I've been thinking about is how Firefox balances these two items. There are hundreds (thousands?) of settings in firefox (type about:config into your location bar to see many of them). You only see ~10% of them in the menu structure and dialog boxes while the rest are hidden in about:config or via files (e.g. changing your chrome/*css). most Firefox users will never use about:config or the chrome files. But for the 5% who use them, they are very important!
Can and should we adopt this separation in Drupal? We already have some examples of variables which have no UI in core but can be enabled via a contributed module or via settings.php (e.g. dev_query). Should we take this further as a general system?
I'm leaning towards yes, but want to know how other people feel.
I've often fantasized about rolling common features from a custom "admin screens" I end up building for clients into a general "Drupal Admin Lite" module. Obviously it would be fantastic to get something like this into core, but with the vast array of use-cases it seems like a ripe opportunity for contrib space to take on. A product-specific admin interface also makes a lot of sense for an install profile. My experience is if you're doing anything interesting, you end up with a custom module doing various API tweaks and workflow glue for your use-case. Even if you're just rolling a "blog" or "wiki" install profile, a key part of making it wildly successful will be giving blog/wiki admins quick and intuitive access to the tools they need... -j ------------------------------------------ Josh Koenig, Partner http://www.chapterthreellc.com AOL IM: chap3josh 1-888-822-4273
On Sat, 10 Nov 2007 13:37:59 -0800 Josh Koenig <joshk@chapterthreellc.com> wrote:
tweaks and workflow glue for your use-case. Even if you're just rolling a "blog" or "wiki" install profile, a key part of making it wildly successful will be giving blog/wiki admins quick and intuitive access to the tools they need...
Can't most of it be achieved with access rules? -- Ivan Sergio Borgonovo http://www.webthatworks.it
tweaks and workflow glue for your use-case. Even if you're just rolling a "blog" or "wiki" install profile, a key part of making it wildly successful will be giving blog/wiki admins quick and intuitive access to the tools they need...
Can't most of it be achieved with access rules?
It really depends on your use-case. In simple instances it may be possible to create an "Admin" role which you grant limited access to Drupal's admin features, reducing the number of choices and potential for confusion. However, the way in which these admin features are laid out will remain generic and not tailored to the intended use of the site. Moreover, you usually want to give the owner of the site user #1, which has root-like powers to see all configuration options exposed by the system, which is important, but puts you back at square one in terms of what the administrative user-experience is all about. cheers -j ------------------------------------------ Josh Koenig, Partner http://www.chapterthreellc.com AOL IM: chap3josh 1-888-822-4273
On Saturday 10 November 2007, Josh Koenig wrote:
tweaks and workflow glue for your use-case. Even if you're just rolling a "blog" or "wiki" install profile, a key part of making it wildly successful will be giving blog/wiki admins quick and intuitive access to the tools they need...
Can't most of it be achieved with access rules?
It really depends on your use-case. In simple instances it may be possible to create an "Admin" role which you grant limited access to Drupal's admin features, reducing the number of choices and potential for confusion. However, the way in which these admin features are laid out will remain generic and not tailored to the intended use of the site.
Another major challenge to that is that permissions in Drupal are still WAY too general. It's too late for Drupal 6 now, but let's make a goal of Drupal 7 to be much more finely-grained permissions. (There were several attempts at doing so for various parts of D6 that were rejected due to it being too late, which I'd love to see revived once HEAD reopens.) I run into this problem constantly when handing sites over to clients, as I can't give them "edit all nodes" permission without also giving them access to various parts of the admin that they really need to stay out of. (Yes I can check off all of the "edit foo" checkboxes, but they still can't access admin/content/node or see unpublished content without the over-broad "administer nodes", which gives them permission to edit node types, which will break the site in all sorts of exciting ways.) Let's make eliminating "administer site configuration" a goal for Drupal 7. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Saturday 10 November 2007, David Strauss wrote:
Larry Garfield wrote:
Let's make eliminating "administer site configuration" a goal for Drupal 7. :-)
Now what am I going to use for all the modules in which I don't want to implement hook_perm()? :-)
Which is exactly the problem. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Saturday 10 November 2007, Dries Buytaert wrote:
This review is quite complete, but it's a 'blogger' review, not a cms.. all the comments are "blog" oriented, and in somehow.. i's far
Thanks for saying that. It is exactly how I felt about it, too.
- A lot of people come to Drupal from a blogging background.
- A lot of what Chris said is valid for non-blogging contexts.
Drupal 6 is what will be used in 2008 and possibly part of 2009. A *lot* of people will bump in exactly the issues that Chris highlighted. Let's not classify this feedback as irrelevant -- it's some of the most valuable usability feedback we've had in months.
If people with a different background provide us feedback, we should also take that into account.
I'd say about a quarter of what he lists is fairly simple usability tweaks that should be easy to do. (String changes, reorder fields, etc.) Unless we're at string freeze, I don't see why we can't do those. Some comments are only useful in the context of being a WordPress clone (eg, enable blogapi and throttle by default); those, honestly, core should ignore and leave to a blogging profile. Some are already in progress. (Any of the drag-and-drop ordering stuff.) Some might be worth considering in 7, but it's too late in D6 for it (in-core calendar picker). Some have a very good reason for being what they are, but honestly the reason is too technical to explain in the UI. (e.g., hyphens aren't allowed in internal names because internal names become function names in the code, and hyphens can't be function names.) Overall I think between a third and a half of his comments can and should be addressed in D6, if we can focus on them. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Nov 10, 2007 7:44 PM, Larry Garfield <larry@garfieldtech.com> wrote:
I'd say about a quarter of what he lists is fairly simple usability tweaks that should be easy to do. (String changes, reorder fields, etc.) Unless we're at string freeze, I don't see why we can't do those.
Strings are not frozen yet. Feel free to submit improval suggestions. I think we accepted most string improvements so far. Gabor
On 11/11/07, Gábor Hojtsy <gabor@hojtsy.hu> wrote: "Strings are not frozen" I'd like to raise an issue Chris Messina didn't mention in his review, though I think the problem is similar to ones he points out. There is inconsistency in the comments module with the way the strings "comment" and "reply" are used. A "comment" is meant to be a row in the comments table with a pid = 0 (it has no "parent", it is a response to the node content). A "reply" refers to a row in the comments table where the pid != 0 (it has a parent, it is a reply to "comment" or another "reply" with the pid = the cid of the parent). In the comment module, the form labels, submit labels and link titles are not consistently applied, adding confusion to the distinction between a "comment" and a "reply". I'm proposing that the "reply" strings be removed and replaced with "comment." The programming that allows for the excellent threading system in the comment module should stay. I just think that it is too confusing to try to describe that threading with one-word terms that seem like synonyms to end users. I have filed an issue in the Drupal issue queue: http://drupal.org/node/189659 I've also brought the issue to to the usability group on g.d.o. http://groups.drupal.org/node/6966 There are positive responses to the idea that we call all comments the same thing. Shai On 11/11/07, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On Nov 10, 2007 7:44 PM, Larry Garfield <larry@garfieldtech.com> wrote:
I'd say about a quarter of what he lists is fairly simple usability tweaks that should be easy to do. (String changes, reorder fields, etc.) Unless we're at string freeze, I don't see why we can't do those.
Strings are not frozen yet. Feel free to submit improval suggestions. I think we accepted most string improvements so far.
Gabor
There are many valuable comments in there, but the review completely butchers vocabularies and terms. It suggests calling both "categories," which would add a whole new level of ambiguity. It makes me want to rename "Categories" to something like "Classification" just to avoid the whole issue of expecting an interface to add categories. Maybe it would be valuable for Drupal to configure a vocabulary called "Tags" out of the box with free tagging that's enabled for all content types. But it should be clear that tagging is a *subset* of what the taxonomy system can do. Including some basic sample content is a nice idea. It could be an option during the installation process. I certainly don't want sample content to be mandatory for new installations. But to be honest, a lot of the suggested changes would be harmful for how I (and my company) use Drupal, which is as a development platform more than a quick-and-easy CMS. I think we'd have to find some way to satisfy the review's concerns without confining more sophisticated use. 'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
would something like having different installation profile (naturally it might need extending i do not how far we can/what should be extened) for use by developer and say normal users not solve some of the suggestions? David Strauss wrote:
There are many valuable comments in there, but the review completely butchers vocabularies and terms. It suggests calling both "categories," which would add a whole new level of ambiguity. It makes me want to rename "Categories" to something like "Classification" just to avoid the whole issue of expecting an interface to add categories.
Maybe it would be valuable for Drupal to configure a vocabulary called "Tags" out of the box with free tagging that's enabled for all content types. But it should be clear that tagging is a *subset* of what the taxonomy system can do.
Including some basic sample content is a nice idea. It could be an option during the installation process. I certainly don't want sample content to be mandatory for new installations.
But to be honest, a lot of the suggested changes would be harmful for how I (and my company) use Drupal, which is as a development platform more than a quick-and-easy CMS. I think we'd have to find some way to satisfy the review's concerns without confining more sophisticated use.
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
Shakur wrote:
would something like having different installation profile (naturally it might need extending i do not how far we can/what should be extened) for use by developer and say normal users not solve some of the suggestions?
It would solve many of the issues.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Strauss schrieb:
There are many valuable comments in there, but the review completely
Yes. I never said that all of it would be irrelevant, btw. But I do think that he is concentrating too much on the needs of a first-time user.
butchers vocabularies and terms. It suggests calling both "categories," which would add a whole new level of ambiguity. It makes me want to rename "Categories" to something like "Classification" just to avoid the whole issue of expecting an interface to add categories.
I never agreed to the renaming of Taxonomy to Categories in the first place. :p I think it was done in the light of a proposal, "Drupal is too complicated, let's dumb it down".
Maybe it would be valuable for Drupal to configure a vocabulary called "Tags" out of the box with free tagging that's enabled for all content types. But it should be clear that tagging is a *subset* of what the taxonomy system can do.
I think this suggestion would be good for a blogging installation profile.
Including some basic sample content is a nice idea. It could be an option during the installation process. I certainly don't want sample content to be mandatory for new installations.
But to be honest, a lot of the suggested changes would be harmful for how I (and my company) use Drupal, which is as a development platform more than a quick-and-easy CMS. I think we'd have to find some way to satisfy the review's concerns without confining more sophisticated use.
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
Well, people actually _can_ (and should!) do that by working on an installation profile. Sadly, there are only very few installation profiles, which indicates that they are somehow incomplete. I wonder what is missing. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNkjdfg6TFvELooQRAmtvAJ0f1FIjNPjjSh1g9HxjeHRyp17J8QCgkAtF 0ObbkFF7M0BPQltai5qN5yQ= =a8Dk -----END PGP SIGNATURE-----
I agree with a lot of what of what has been said here, specifically regarding the Chris's take on taxonomies. From reading his comments I get the feeling that he didn''t 'get' taxonomies. It feels to me as if he had a really narrow idea of what taxonomies were and how they could be used. I think the question we really need to take out of that is whether the the categorization of content is a inherently difficult subject that requires a learning curve, or if we're not being as communicative as possible about what the taxonomy module does and how one might use it. Although I agree that Taxonomy, Vocabulary, and Term and technically precise terms, are they also the most communicative terms? I feel like we should look not only at the fact that he got some things wrong so to speak, but also explore why he got them wrong, and whether or not we can do anything about it for both he and the non technical types without sacrificing functionality. I think we should consider that a lot of us here turn over drupal sites to less technical or non technical users, and the more clarity we can get from a usability standpoint is a major benefit when it comes to long term product support. Best, Brad Bowman
On Saturday 10 November 2007, Brad Bowman wrote:
I agree with a lot of what of what has been said here, specifically regarding the Chris's take on taxonomies. From reading his comments I get the feeling that he didn''t 'get' taxonomies. It feels to me as if he had a really narrow idea of what taxonomies were and how they could be used. I think the question we really need to take out of that is whether the the categorization of content is a inherently difficult subject that requires a learning curve, or if we're not being as communicative as possible about what the taxonomy module does and how one might use it.
I'd say both of those statements are true. Learning curves cannot be eliminated, but we should strive to make them as easy to climb as possible. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Garfield schrieb:
On Saturday 10 November 2007, Brad Bowman wrote:
I agree with a lot of what of what has been said here, specifically regarding the Chris's take on taxonomies. From reading his comments I get the feeling that he didn''t 'get' taxonomies. It feels to me as if he had a really narrow idea of what taxonomies were and how they could be used. I think the question we really need to take out of that is whether the the categorization of content is a inherently difficult subject that requires a learning curve, or if we're not being as communicative as possible about what the taxonomy module does and how one might use it.
I'd say both of those statements are true. Learning curves cannot be eliminated, but we should strive to make them as easy to climb as possible.
Why do you want to rob those poor souls the good feeling of having something accomplished? :p Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNvBOfg6TFvELooQRAhKTAKCXhbrLFizyzjD+nxMs0hDq/Cp0XQCfRWlB l5Xq+kjoJP+w720xOa7hZeM= =9P7l -----END PGP SIGNATURE-----
I'd say both of those statements are true. Learning curves cannot be eliminated, but we should strive to make them as easy to climb as possible.
We could introduce a new concept, beside access rules, this would be "user knowledge level" or something like that. At installation, we could ask the user if he is a newbie or an advanced admin or something in between. Then, the UI could be adapted and some options eliminated for newbies. The important point here is the fact that you are talking about a learning *curve* which means that user knowledge will improve. I don't think an install profile would be a good solution, because it would stuck the user with a dumbed down blogging interface. When you decide to use Drupal for a blog and you are a newbie, it's because you see that there is a lot of room for extension (and in a very clean way). If it was possible to hide the complex stuff and make it available at the change of a user preference, this would ease the job of newbie admins (those with id = 1) At the same time advanced users will be happy with the already available full admin menu. Some software use this kind of adaptive UI, like Azureus bittorent client. See first screen here http://azureus.sourceforge.net/screenshots_v2.php My 0.02 as usual Philippe ps : note that this could be implemented using user roles. A "newbie" role could be added at install time if requested
On Mon, 2007-11-12 at 09:57 +0100, Philippe Jadin wrote:
We could introduce a new concept, beside access rules, this would be "user knowledge level" or something like that. At installation, we could ask the user if he is a newbie or an advanced admin or something in between. Then, the UI could be adapted and some options eliminated for newbies.
I hate those UIs. The "newbie" UI is never sufficient, so you always have to upgrade to the "expert" or "advanced" UI anyway, which is a poor excuse for dropping every possible options together. Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay. Xav
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay.
How about one more option on that list: - Hidden, but configurable by admins I am quite embarrassed by the current pathauto admin settings page.[1] It is _insanely_ long. But many people have begged to have those features added so I can't just drop features. So what else can I do? I don't think there is any way to "detect automatically" on any of these items. Splitting them onto separate pages masks the problem and just requires more clicking and page refreshes. My proposal is to remove the UI for infrequently used features, document them in the readme, and allow people to set them via a general variable editor or via the settings.php For example, in 99% of the cases the punctuation treatment should be "replace by separator". The module can default to that and allow overrides via variables set in the settings.php Any good reasons not to do this? Does anyone besides flk and me like the idea? Thanks, Greg [1] http://drupal.org/files/images/pathauto_settings_5x_2x_expanded.png PS I'll try not to repeat myself every day on this subject but I explained this to flk in #drupal and he said that the first time I mentioned it he didn't understand the value of it. So, given the relevant discussion by Xavier I felt I should raise it again. -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Quoting Greg Knaddison <greg@pingvox.com>:
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay.
How about one more option on that list:
- Hidden, but configurable by admins
I am quite embarrassed by the current pathauto admin settings page.[1]
It is _insanely_ long. But many people have begged to have those features added so I can't just drop features. So what else can I do? I don't think there is any way to "detect automatically" on any of these items. Splitting them onto separate pages masks the problem and just requires more clicking and page refreshes.
My proposal is to remove the UI for infrequently used features, document them in the readme, and allow people to set them via a general variable editor or via the settings.php For example, in 99% of the cases the punctuation treatment should be "replace by separator". The module can default to that and allow overrides via variables set in the settings.php
Any good reasons not to do this? Does anyone besides flk and me like the idea?
I use pathauto so I hope you don't mind if I pick on only one of the settings, Punctuation settings. For this group you could consider one field for the replacement character and another field for a list of characters to replace with that character. One more field for a list of characters to remove and everything else would then be no action. I think the variable editor idea is a bit on the dangerous side. Too prone to errors for the majority of those using it (I want to say 75% but I have no statistics). While good experienced administrators could benefit from it; the inexperienced may well flood the lists. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Knaddison schrieb:
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay.
How about one more option on that list:
- Hidden, but configurable by admins
I am quite embarrassed by the current pathauto admin settings page.[1]
It is _insanely_ long. But many people have begged to have those features added so I can't just drop features.
IMO part of being a module maintainer is the task to say "no" to requested features if they aren't generally useful. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHOFxefg6TFvELooQRAjdsAKDKoupbvnEdWFe2GisXJV14oxsrZQCgvNWr juxS/A3eiEZM/Xmjmf3dYZw= =fk+L -----END PGP SIGNATURE-----
On Mon, 2007-11-12 at 14:59 +0100, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Knaddison schrieb:
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay.
How about one more option on that list:
- Hidden, but configurable by admins
I am quite embarrassed by the current pathauto admin settings page.[1]
It is _insanely_ long. But many people have begged to have those features added so I can't just drop features.
IMO part of being a module maintainer is the task to say "no" to requested features if they aren't generally useful.
Fully agreed with Earnie & you. Also Colin, remove the length settings, or make that hidden somewhere. That's a kind of setting I forgot: the "please don't fail" option. You could also avoid the transliteration options, and always transliterate if you find the i18n-ascii.txt file. All the help stuff should be shown on mouseover or with a click. Just this should already make this settings page way narrower, without having to click everywhere to disclose fields. Then, it's your module so it's your call :) HTH, Xav
On Nov 12, 2007 10:13 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Mon, 2007-11-12 at 14:59 +0100, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Knaddison schrieb:
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay.
How about one more option on that list:
- Hidden, but configurable by admins
I am quite embarrassed by the current pathauto admin settings page.[1]
It is _insanely_ long. But many people have begged to have those features added so I can't just drop features.
IMO part of being a module maintainer is the task to say "no" to requested features if they aren't generally useful.
Based on user feedback and my own feelings, these are useful features.
Fully agreed with Earnie & you.
Also Colin, remove the length settings, or make that hidden somewhere. That's a kind of setting I forgot: the "please don't fail" option.
By Colin I assume you mean Greg ;)
You could also avoid the transliteration options, and always transliterate if you find the i18n-ascii.txt file.
All the help stuff should be shown on mouseover or with a click.
Just this should already make this settings page way narrower, without having to click everywhere to disclose fields.
I wasn't asking for specific feedback on that page (though I appreciate it and will include much of it). I was asking for feedback on an idea and providing an example to help people understand the idea. Earnie responded to the idea and said:
I think the variable editor idea is a bit on the dangerous side. Too prone to errors for the majority of those using it (I want to say 75% but I have no statistics). While good experienced administrators could benefit from it; the inexperienced may well flood the lists.
I agree, but the target user of the variable editor is an advanced admin. The goal is to only put options there that are both uncommonly changed and useful only to admin users. It is how Firefox (one of the few OSS UI Simplicity success stories) balances this problem. Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Mon, 2007-11-12 at 10:37 -0300, Greg Knaddison wrote:
On Nov 12, 2007 10:13 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Also Colin, remove the length settings, or make that hidden somewhere. That's a kind of setting I forgot: the "please don't fail" option.
By Colin I assume you mean Greg ;)
Err .. yes, now I'm confused. Sorry for that Greg :)
I was asking for feedback on an idea and providing an example to help people understand the idea.
To me, that was a good example where clutter can be trimmed off. No offense to you Greg, removing options isn't an easy task, but once it's done it makes life easy for users.
Earnie responded to the idea and said:
I think the variable editor idea is a bit on the dangerous side. Too prone to errors for the majority of those using it (I want to say 75% but I have no statistics). While good experienced administrators could benefit from it; the inexperienced may well flood the lists.
I agree, but the target user of the variable editor is an advanced admin. The goal is to only put options there that are both uncommonly changed and useful only to admin users. It is how Firefox (one of the few OSS UI Simplicity success stories) balances this problem.
On one hand it could be a good way of hinding useless but mandatory settings, but on the other hand care should be taken for that "variables editor" not to become a dumping ground. Xav
Guys, Greg is using the pathauto module as an example of UI that contains to much info whether he should allow things to go allow features or not is really beside the point. What we talked about and the aim of his email was...how does cutting down of interface's by removing rarely used UI's sound e.g. in the comment setting page[1] there is frankly too much info which right allows a use who knows/wants to configure how comments are set to do so, but the truth of the matter is with most users the default setting suffices and all they care about is whether comments should be allow or not (default comment setting)...so why cant we remove those options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on? [1] http://www.flickr.com/photos/factoryjoe/1936557315/in/set-72157603036774024/ Gerhard Killesreiter wrote:
Greg Knaddison schrieb:
On Nov 12, 2007 6:10 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
Options should be: - thrown away if useless (e.g. don't ask me to enable a feature, I have enabled the module already). - detected automatically whenever possible (and thrown away). - rationally grouped together when they must stay. How about one more option on that list:
- Hidden, but configurable by admins
I am quite embarrassed by the current pathauto admin settings page.[1]
It is _insanely_ long. But many people have begged to have those features added so I can't just drop features.
IMO part of being a module maintainer is the task to say "no" to requested features if they aren't generally useful.
Cheers, Gerhard
On Nov 12, 2007 1:49 PM, Shakur <shakur@techarena.co.uk> wrote: ...so why cant we remove those
options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on?
[1] http://www.flickr.com/photos/factoryjoe/1936557315/in/set-72157603036774024/
About 1/5th of that page is taken up by comment control settings - I'm unaware of any drupal site in existence which uses them, and have an issue against D7 to remove them [1], and another one to remove the option for display order [2] - also rarely used, and easy to override in contrib by the time we'd be taking it out, if not already. With taxonomy module - I really think it should be renamed back to taxonomy as Earnie suggests to avoid the "Category, Categories, Vocabularies" confusion, then change the description in the admin page to "Set up tags and categorisation" (which is what it actually does, and provides the 'tags' hint to new users mincing words to do so). Another thing which might help would be some deep links to stuff like "tags configuration" within the /admin page descriptions so users could dive straight in. catch 1. http://drupal.org/node/175841 2. http://drupal.org/node/191499 3. http://drupal.org/node/191502
I have helped several people over the years configure those settings for their sites. People don't always work in the same realm or types of sites. For instance, I don't use forums on my sites. On Nov 12, 2007 6:45 AM, catch libcom <catch56@googlemail.com> wrote:
On Nov 12, 2007 1:49 PM, Shakur <shakur@techarena.co.uk> wrote: ...so why cant we remove those
options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on?
[1] http://www.flickr.com/photos/factoryjoe/1936557315/in/set-72157603036774024/
About 1/5th of that page is taken up by comment control settings - I'm unaware of any drupal site in existence which uses them, and have an issue against D7 to remove them [1], and another one to remove the option for display order [2] - also rarely used, and easy to override in contrib by the time we'd be taking it out, if not already.
With taxonomy module - I really think it should be renamed back to taxonomy as Earnie suggests to avoid the "Category, Categories, Vocabularies" confusion, then change the description in the admin page to "Set up tags and categorisation" (which is what it actually does, and provides the 'tags' hint to new users mincing words to do so). Another thing which might help would be some deep links to stuff like "tags configuration" within the /admin page descriptions so users could dive straight in.
catch
1. http://drupal.org/node/175841 2. http://drupal.org/node/191499 3. http://drupal.org/node/191502
Steven Peck wrote:
I have helped several people over the years configure those settings for their sites. People don't always work in the same realm or types of sites. For instance, I don't use forums on my sites.
I mean the "comment controls" shown to end-users on the node page, not the settings available to the admin, just to be clear. Even if there are examples of sites using these, it wouldn't be a hard thing to support in contrib. Such a module could also do Digg style "these comments are below your threshold" and other nice features, that also have no reason to be in core but might have valid use cases. Display order is a personal gripe though, I'll admit that ;)
On Nov 12, 2007 6:45 AM, catch libcom <catch56@googlemail.com> wrote:
On Nov 12, 2007 1:49 PM, Shakur <shakur@techarena.co.uk> wrote: ...so why cant we remove those
options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on?
[1] http://www.flickr.com/photos/factoryjoe/1936557315/in/set-72157603036774024/
About 1/5th of that page is taken up by comment control settings - I'm unaware of any drupal site in existence which uses them, and have an issue against D7 to remove them [1], and another one to remove the option for display order [2] - also rarely used, and easy to override in contrib by the time we'd be taking it out, if not already.
On Nov 12, 2007 2:49 PM, Shakur <shakur@techarena.co.uk> wrote:
What we talked about and the aim of his email was...how does cutting down of interface's by removing rarely used UI's sound e.g. in the comment setting page[1] there is frankly too much info which right allows a use who knows/wants to configure how comments are set to do so, but the truth of the matter is with most users the default setting suffices and all they care about is whether comments should be allow or not (default comment setting)...so why cant we remove those options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on?
This can be easily moved to a collapsible field set labelled "advanced settings" I made a mockup here : Closed, for casual user : http://www.flickr.com/photos/33669100@N00/1984319199/ Opened if you want the whole settings : http://www.flickr.com/photos/33669100@N00/1985132778/ Or did I miss something ?
On Mon, 12 Nov 2007 13:49:06 +0000, Shakur <shakur@techarena.co.uk> wrote:
Guys, Greg is using the pathauto module as an example of UI that contains to much info whether he should allow things to go allow features or not is really beside the point. What we talked about and the aim of his email was...how does cutting down of interface's by removing rarely used UI's sound e.g. in the comment setting page[1] there is frankly too much info which right allows a use who knows/wants to configure how comments are set to do so, but the truth of the matter is with most users the default setting suffices and all they care about is whether comments should be allow or not (default comment setting)...so why cant we remove those options we think are to detailed and have a variable setting in one place (setting.php?) whereby advance users can turn those on?
An undocumented feature (which anything done manually in settings.php is) is not a feature. Even if we had an about: page somewhere that let people directly edit the variables table (which would depend on the variable-defaults hook that some were working on for D6 but weren't able to finish), we would be remiss if we didn't document all of the settings there. Then we're right back where we started, just on a different, larger page. Bear in mind, the sort of thing that Firefox puts in about: is much more esoteric than what we're talking about. --Larry Garfield
On Nov 12, 2007 1:02 PM, Larry Garfield <larry@garfieldtech.com> wrote:
An undocumented feature (which anything done manually in settings.php is) is not a feature. Even if we had an about: page somewhere that let people directly edit the variables table (which would depend on the variable-defaults hook that some were working on for D6 but weren't able to finish), we would be remiss if we didn't document all of the settings there. Then we're right back where we started, just on a different, larger page.
This seems like a weakness in the plan, not a fatal flaw. Our ability to get query data via the dev_query variable is an existing instance of this idea and of the problem that you cite. Same story with allow_insecure_uploads in upload.module. These are features without UI or documentation.
Bear in mind, the sort of thing that Firefox puts in about: is much more esoteric than what we're talking about.
I don't know, I'd say that "changing the mouse pointer to different styles based on the target using the chrome/*.css" [1] isn't really all that much more esoteric than the "per content type positioning of the the comment display style control." How many people use comment controls, much less change that setting, much less need to change it on a per content type basis? Thanks for your thoughts on the idea. Greg [1] http://lifehacker.com/software/ask-the-readers/best-firefox-userchromecss-tw... -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Mon, 12 Nov 2007 16:06:23 -0300, "Greg Knaddison" <greg@pingvox.com> wrote:
On Nov 12, 2007 1:02 PM, Larry Garfield <larry@garfieldtech.com> wrote:
An undocumented feature (which anything done manually in settings.php
is) is not a feature. Even if we had an about: page somewhere that let people directly edit the variables table (which would depend on the variable-defaults hook that some were working on for D6 but weren't able to finish), we would be remiss if we didn't document all of the settings there. Then we're right back where we started, just on a different, larger page.
This seems like a weakness in the plan, not a fatal flaw. Our ability to get query data via the dev_query variable is an existing instance of this idea and of the problem that you cite.
dev_query is controllable via the UI, just in the devel module. The only reason it's in core is because it's not possible to inject using devel. It's also developer-only. Normal site users should never have that running during production.
Same story with allow_insecure_uploads in upload.module. These are features without UI or documentation.
See, I never even knew that existed. Now I wonder if it would have solved a problem I had 8 months ago had I known about it, but since it was hidden I probably wasted a lot of time because of it. That's an example against an about:Drupal page. :-) --Larry Garfield
On Nov 11, 2007 1:12 AM, Gerhard Killesreiter wrote:
David Strauss schrieb:
butchers vocabularies and terms. It suggests calling both "categories," which would add a whole new level of ambiguity. It makes me want to rename "Categories" to something like "Classification" just to avoid the whole issue of expecting an interface to add categories.
I never agreed to the renaming of Taxonomy to Categories in the first place. :p
I think it was done in the light of a proposal, "Drupal is too complicated, let's dumb it down".
Maybe it would be valuable for Drupal to configure a vocabulary called "Tags" out of the box with free tagging that's enabled for all content types. But it should be clear that tagging is a *subset* of what the taxonomy system can do.
I think this suggestion would be good for a blogging installation profile.
Exactly. I hated the whole taxonomy / vocabulary / terms terminology thing when I first started with Drupal. I hated it so much I went looked at other CMSs and frameworks before I finally had to come back to Drupal because none of the others were as extensible or coded as well. So, I understand how hard it is to learn the Drupal taxonomy feature by newcomers. But now that I do understand it, I realize that calling it just about anything else is misleading, and faulty over-simplification. Categories of content are simply one small subset of what Drupal taxonomies can do. Free tagging is another. It makes much more sense to provide profiles with those things enabled and described, than to screw up the whole coherency of Drupal by renaming taxonomy to something it really isn't. Taxonomies may not be the easiest thing to understand, but we really sell ourselves short to try and dumb them down. Instead, we should write better documentation (yes, I know how much coders love that) and provide profiles for the sets of users not as interested in learning. Of course, my own viewpoint is of Drupal as a CMS framework, as Ivan Sergio Borgonovo so aptly put it earlier in this thread. It's not a blog and it's not a CMS, to me. It's a development tool for building CMS-like sites, social software, collaboration software, etc. Others may reasonably disagree. :-) ..chrisxj
Quoting David Strauss <david@fourkitchens.com>:
But to be honest, a lot of the suggested changes would be harmful for how I (and my company) use Drupal, which is as a development platform more than a quick-and-easy CMS. I think we'd have to find some way to satisfy the review's concerns without confining more sophisticated use.
I've been contemplating a link that adds Profiles to d.o/project/ along with Modules and Themes. So we end up with a Blog profile, a Wiki profile, etc. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Nov 10, 2007, at 9:58 PM, Earnie Boyd wrote:
I've been contemplating a link that adds Profiles to d.o/project/ along with Modules and Themes.
I'm confused. That link exists. Start here: http://drupal.org/project 2nd link on the page: * Installation profiles http://drupal.org/project/Installation+profiles "Installation profiles are a feature in Drupal core that was added in the 5.x series. The new Drupal installer allows you to specify an installation profile which defines which modules should be enabled, and can customize the new installation after they have been installed. This will allow customized "distributions" that enable and configure a set of modules that work together for a specific kind of site (Drupal for bloggers, Drupal for musicians, Drupal for developers, and so on)." ??? -Derek (dww)
Quoting Derek Wright <drupal@dwwright.net>:
On Nov 10, 2007, at 9:58 PM, Earnie Boyd wrote:
I've been contemplating a link that adds Profiles to d.o/project/ along with Modules and Themes.
I'm confused. That link exists. Start here:
Ack. Start here http://drupal.org. See the pretty Green and White striped block on the top right? Needs this:
* Installation profiles http://drupal.org/project/Installation+profiles
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
[as a relatively long-time drupal user and recent deployer on several websites] I would agree that Drupal.org should start distributing at least one additional distribution (aside from bare bones core system) which would be filled with some default content and most basic website parameters set (targeting novice users, bloggers included), that way it would show by example this important option and also solve issue of serving some of the blogging-enthusiasts who did not dived deep enough in Drupal to do it on their own.
Do you volunteer to maintain such a distribution? I do not think you understand how much work it is to maintain Drupal core much less an additional more complex distro. On Nov 12, 2007 6:10 AM, zeljko blace <zblace@gmail.com> wrote:
[as a relatively long-time drupal user and recent deployer on several websites]
I would agree that Drupal.org should start distributing at least one additional distribution (aside from bare bones core system) which would be filled with some default content and most basic website parameters set (targeting novice users, bloggers included), that way it would show by example this important option and also solve issue of serving some of the blogging-enthusiasts who did not dived deep enough in Drupal to do it on their own.
On Nov 12, 2007 7:42 PM, Steven Peck <sepeck@gmail.com> wrote:
Do you volunteer to maintain such a distribution? I do not think you
NO - but willing to join and look for funds, so someone could take on it.
understand how much work it is to maintain Drupal core much less an additional more complex distro.
TRUE - but I am willing to learn and would start working on producing mine ones 6.0 becomes solid... targeting media zines. Already have some work comissioned and will try to reuse as much as possible of that.
On Nov 12, 2007 6:10 AM, zeljko blace <zblace@gmail.com> wrote:
[as a relatively long-time drupal user and recent deployer on several websites]
I would agree that Drupal.org <http://drupal.org/> should start distributing at least one additional distribution (aside from bare bones core system) which would be filled with some default content and most basic website parameters set (targeting novice users, bloggers included), that way it would show by example this important option and also solve issue of serving some of the blogging-enthusiasts who did not dived deep enough in Drupal to do it on their own.
David Strauss wrote:
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
Actually, one of my long term goals is to get Drupal to the point where it can compete with Wordpress. There *is* a benefit to this in terms of marketing and perception.
Earl Miles wrote:
David Strauss wrote:
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
Actually, one of my long term goals is to get Drupal to the point where it can compete with Wordpress. There *is* a benefit to this in terms of marketing and perception.
I agree. I'm working on modules + installation profile to get a valid DrupalMU, a multi-user blogging platform. Wim
On 11 Nov 2007, at 17:48, Wim Mostrey wrote:
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
I don't mind having two or three profiles ship with Drupal core. They could help market install profiles and gives people one or two concrete examples to start from when building their own profiles. I think this would come a long way in helping to promote install profiles. Specifically, I'm willing to accept a dummy.profile that populates your Drupal site with some dummy data and that gives you a kick start by pre-configuring a number of common things (i.e. it could create an about-page at q?=about, and it could setup a contact form that is accessible from the primary navigation). In fact, I wouldn't mind a blog.profile either -- it could also setup 'tags'-vocabulary with a term 'Drupal' or something. If we think this is important, and if they emerge within the next day or two, we could ship those with Drupal 6. These are important usability/strategic improvements, not API changes. -- Dries Buytaert :: http://www.buytaert.net/
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core.
To clarify, you mean some install profiles that ship with core *which only include core modules*, right? So, there's no packaging issue at all, since these profiles cannot have any external dependencies at all. Their only job is to enable/configure core modules and potentially generate some initial content... I just want everyone to be clear so that if someone starts working on these, there's no surprises about what's expected/allowed. I'm clarifying, because I'm soon going to start work to enable contrib install profiles to tell the packaging script what versions of which contribs those profiles depend on, so all of the above can be packaged together (along with core) into a single tarball. That's a much different (and bigger) problem, than what Dries is talking about allowing for D6, since the core install profiles only touch core, and are therefore already packaged with everything they need. ;) Cheers, -Derek (dww)
On Nov 13, 2007, at 11:06 AM, Derek Wright wrote:
Their only job is to enable/configure core modules and potentially generate some initial content...
Furthermore, the point of these additional core profiles is to show people what Drupal can do, and help them climb the learning curve, right? If so, I'd like to propose that each additional core profile include a README.txt file that explains in some (but not overwhelming) detail, exactly what that profile is doing beyond the basic installation. For example, the "blogging" profile's README.txt might look something like this: ============ This profile configures a Drupal installation to be optimized for a multi-user blogging site. It performs the following tasks: * Creates a new content type called "Blog post" (admin/content/types/ add) * Configures this type with the following behaviors: (admin/content/ types/blog-post) -- Display these posts on the front page of your site by default ("Promote to front page") -- Enable comments ... * Creates a system for tagging the blog posts (admin/taxonomy/...) -- Creates a "vocabulary" called "blog tags" -- Configures this to be a "free tagging" vocabulary ... ... ============ Especially if these profiles included a page during the install wizard that displayed the README.txt file (as many install wizards do), this could definitely help people figure this stuff out, or learn how to make these same sorts of changes to an existing site, etc, etc. Cheers, -Derek (dww)
On 13 Nov 2007, at 20:06, Derek Wright wrote:
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core.
To clarify, you mean some install profiles that ship with core *which only include core modules*, right?
Yes. -- Dries Buytaert :: http://www.buytaert.net/
I think a single user blog install profile would be great for core. Here's the existing issue for this: http://drupal.org/node/144355 Matt Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 13 Nov 2007, at 20:06, Derek Wright wrote:
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core.
To clarify, you mean some install profiles that ship with core *which only include core modules*, right?
Yes.
-- Dries Buytaert :: http://www.buytaert.net/
Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 13 Nov 2007, at 20:06, Derek Wright wrote:
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core.
To clarify, you mean some install profiles that ship with core *which only include core modules*, right?
Yes.
-- Dries Buytaert :: http://www.buytaert.net/
If we ship Drupal 6 with additional install profiles, we should also have a designated maintainer for each one of them. Each profile maintainer should be primarily using "his" profile for own sites and she/he should have deep insight into the market the profile deals with. By writing this, I actually think that development speed in core could be too slow for having great install profiles. See: any improvements to a blogging profile would have to wait for D7. Conclusion: I would rather suggest to write detailed documentation about developing install profiles and support Derek in realizing his efforts of pre-packaged install profiles, instead of shipping Drupal with poor "example profiles". Users evaluating Drupal for a blog would not know of contributed install profiles. So they would test that blogging profile in core and probably head over to another blog-ready system, because modules in Drupal core do not provide as much features as other blogging systems. sun
I like this idea, but it's really hard for me to do using only core modules. I don't think I've done a core-only site in three years. ;-) I suspect a lot of other people will have the same problem - certainly anyone of the skill level required to be able to actually write and maintain an install profile. Daniel F. Kudwien wrote:
Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 13 Nov 2007, at 20:06, Derek Wright wrote:
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core. To clarify, you mean some install profiles that ship with core *which only include core modules*, right? Yes.
-- Dries Buytaert :: http://www.buytaert.net/
If we ship Drupal 6 with additional install profiles, we should also have a designated maintainer for each one of them. Each profile maintainer should be primarily using "his" profile for own sites and she/he should have deep insight into the market the profile deals with.
By writing this, I actually think that development speed in core could be too slow for having great install profiles. See: any improvements to a blogging profile would have to wait for D7.
Conclusion: I would rather suggest to write detailed documentation about developing install profiles and support Derek in realizing his efforts of pre-packaged install profiles, instead of shipping Drupal with poor "example profiles". Users evaluating Drupal for a blog would not know of contributed install profiles. So they would test that blogging profile in core and probably head over to another blog-ready system, because modules in Drupal core do not provide as much features as other blogging systems.
sun
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
I've made a single-user blog profile using only core. I'd like to see peoples opinions on it! Where should I upload it? =dmitrig01= On Nov 14, 2007 6:56 AM, Sean Robertson <seanr@ngpsoftware.com> wrote:
I like this idea, but it's really hard for me to do using only core modules. I don't think I've done a core-only site in three years. ;-)
I suspect a lot of other people will have the same problem - certainly anyone of the skill level required to be able to actually write and maintain an install profile.
Daniel F. Kudwien wrote:
Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 13 Nov 2007, at 20:06, Derek Wright wrote:
On Nov 13, 2007, at 12:25 AM, Dries Buytaert wrote:
I don't mind having two or three profiles ship with Drupal core. To clarify, you mean some install profiles that ship with core *which only include core modules*, right? Yes.
-- Dries Buytaert :: http://www.buytaert.net/
If we ship Drupal 6 with additional install profiles, we should also have a designated maintainer for each one of them. Each profile maintainer should be primarily using "his" profile for own sites and she/he should have deep insight into the market the profile deals with.
By writing this, I actually think that development speed in core could be too slow for having great install profiles. See: any improvements to a blogging profile would have to wait for D7.
Conclusion: I would rather suggest to write detailed documentation about developing install profiles and support Derek in realizing his efforts of pre-packaged install profiles, instead of shipping Drupal with poor "example profiles". Users evaluating Drupal for a blog would not know of contributed install profiles. So they would test that blogging profile in core and probably head over to another blog-ready system, because modules in Drupal core do not provide as much features as other blogging systems.
sun
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On Nov 14, 2007, at 9:28 PM, Dmitri G wrote:
I've made a single-user blog profile using only core.
Cool, way to go!
I'd like to see peoples opinions on it!
Where should I upload it?
I'd see if there's an existing core issue about this yet. If so, post it there. Else, create a new core issue about it and upload the file(s) there. Either way, send us an issue nid when you're done. Thanks! -Derek (dww)
I believe work on that is happening here: http://drupal.org/node/144355 On Wednesday 14 November 2007, Dmitri G wrote:
I've made a single-user blog profile using only core.
I'd like to see peoples opinions on it!
Where should I upload it?
=dmitrig01=
On Nov 14, 2007 6:56 AM, Sean Robertson <seanr@ngpsoftware.com> wrote:
I like this idea, but it's really hard for me to do using only core modules. I don't think I've done a core-only site in three years. ;-)
I suspect a lot of other people will have the same problem - certainly anyone of the skill level required to be able to actually write and maintain an install profile.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Nov 14, 2007, at 9:53 PM, Larry Garfield wrote:
I believe work on that is happening here:
Hehe, there you go. Submitted by dmitrig01, in fact. :) Can't wait to test drive you latest effort. Thanks, -Derek (dww) p.s. On Nov 14, 2007, at 9:53 PM, Derek Wright wrote:
Either way, send us an issue nid when you're done.
Apologies for the simultaneous posting -- Larry answered before I even asked. ;)
On 14-Nov-07, at 9:28 PM, Dmitri G wrote:
I've made a single-user blog profile using only core.
I'd like to see peoples opinions on it!
Where should I upload it?
Attach it to the issue mentioned earlier in this thread. BUT I agree with what Dries said ... putting a sub-optimal core-module only install profile in core is probably the wrong thing to do. Making a *great* extra downloadable blog install profile is the right thing to do, so go ahead and make a new "install profile" setting and start rallying support. And fix more of my install_profile_api bugs while you're at it, Dmitri :P As per Adrian's earlier comments, install profiles are going to need some re-working in the D7 time frame, and around about there somewhere DWW will have put cycles into packaging scripts, too, if funding happens as planned and/or lots of people jump in to help. FYI -- Bryght Basic profile includes a "tags" vocabulary out of the box... -- Boris Mann Office 604-682-2889 http://www.bryght.com Jabber boris@bryght.com Skype borismann
On Nov 15, 2007, at 2:12 PM, Boris Mann wrote:
install profiles are going to need some re-working in the D7 time frame, and around about there somewhere DWW will have put cycles into packaging scripts, too, if funding happens as planned and/or lots of people jump in to help.
FYI, so we're all on the same page here... My efforts aren't going to be "around about D7 time". If all goes according to plan (and all the current pledges of funding actually come through), there will be packaged install profiles on d.o in about a month or so. I have every intention to support fully packaged D5 install profiles. Of course, that doesn't rule out other install profile improvements once D7 development opens up. But, people shouldn't consider this functionality something only for the distant future. Cheers, -Derek (dww)
On 16 Nov 2007, at 4:41 AM, Derek Wright wrote:
My efforts aren't going to be "around about D7 time". If all goes according to plan (and all the current pledges of funding actually come through), there will be packaged install profiles on d.o in about a month or so. I have every intention to support fully packaged D5 install profiles. Of course, that doesn't rule out other install profile improvements once D7 development opens up. But, people shouldn't consider this functionality something only for the distant future.
I'm just worried about what happens when D7 comes out. I don't think that the hook_profile_modules is very sensible for install profile module requirements, and I fully intend on introducing .info files for Drupal 7. This would mean that install profile packaging will get broken during the drupal 7 development, and will need to be maintained, in tandem with the old mechanism.
On Nov 15, 2007, at 10:11 PM, adrian rossouw wrote:
I don't think that the hook_profile_modules is very sensible for install profile module requirements,
I don't, either.
and I fully intend on introducing .info files for Drupal 7.
I fully intend to implement my changes by introducing .info files (using the D6 .info syntax parser embedded in the d.o packaging script). So, for D5 and D6, only the packaging script reads it, but we can still include and ship .info files from here on out (using the more powerful D6 .info syntax for dependencies, which is why I helped Steven make that change (.info for themes[1]) in D6 in the first place). In D7, we just expand on what's in them, and the role that the installer and/or the rest of core interacts with them.
This would mean that install profile packaging will get broken during the drupal 7 development, and will need to be maintained, in tandem with the old mechanism.
_Worst_ case is that the syntax for .info files changes again in D7. If that happens at all, hopefully it'll just be adding a superset of the D6 functionality, not breaking it. Either way, modules and themes will be bitten by this if we do it, so I don't care if a few have to update their install_profile.info, too. Cheers, -Derek (dww) [1] http://drupal.org/node/132018 (ugh, that was a painful issue, I almost hate to post a the link).
On Nov 16, 2007, at 12:24 AM, Derek Wright wrote:
I fully intend to implement my changes by introducing .info files
I should qualify this... I _might_ introduce ".pkg" files (or something) specifically for the packaging script to read (using .info syntax). However, I'm leaning towards reusing .info for this to avoid duplication, things ever getting out of sync, and possible confusion. -Derek (dww)
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
As long as core is not architected to be specialized for being a Super WordPress, what's the harm? And how can you say there are no benefits? I can name 2 benefits: (1) super-blog user eventually becomes a contributing member of the Drupal community and (2) super-blog user eventually wants more than a super-blog and can do so by installing / enabling other Drupal modules, instead of having to port her WordPress site to Drupal or some other CMS. ..chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Johnson schrieb:
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
As long as core is not architected to be specialized for being a Super WordPress, what's the harm?
And how can you say there are no benefits? I can name 2 benefits: (1) super-blog user eventually becomes a contributing member of the Drupal community and (2) super-blog user eventually wants more than a super-blog and can do so by installing / enabling other Drupal modules, instead of having to port her WordPress site to Drupal or some other CMS.
You probably haven't heard it (or have had the idea...) but some people even brand WP as a CMS... Cheers, Ger»the horror«hard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHOthNfg6TFvELooQRAqfMAJ9WlqcJJWoIL7b3C44m8lIn3Ho18gCfQ7L2 /1r/8ZamE1EABLMyA+hSQ0c= =pD/s -----END PGP SIGNATURE-----
On Wed, 14 Nov 2007 11:04:33 +0100 "Chris Johnson" <cxjohnson@gmail.com> wrote:
'Cause if someone just wants a blog, we tell them to use WordPress. No one benefits from making Drupal into "Super WordPress."
As long as core is not architected to be specialized for being a Super WordPress, what's the harm?
flexibility, specialisation, fast development Pick 2 ;) Surely you don't actually have to "pick 2", you've to decide where to put your efforts and understand what are the trade-offs. BTW I'm absolutely not neglecting the value of Chris usability suggestions. Making drupal more usable is good... but more usable to whom? Once that is clear you can find the right compromises.
And how can you say there are no benefits? I can name 2 benefits: (1) super-blog user eventually becomes a contributing member of the Drupal community and (2) super-blog user eventually wants more than
What do you mean by "drupal community"? It seems that most of the dev community doesn't really need Chris proposed usability changes... or at least most don't think they are a priority or can be traded for flexibility.[1] Anyway devs have bills to pay and helping people understand that drupal can be a powerful blogging platform can help devs to pay their bills. Showing people that drupal is "easy" for them will help too. Now citing myself: " Drupal is a CMS framework... more than a framework and less than a "prepackaged" CMS. This makes it a tool for developers. And I'm happy with it because there is no other product filling that marketplace. Drupal pays the bills of web designers and developers too, not just the former as other CMS. ... Writing commodity software is OK if your business model is based on providing the infrastructure, selling ads etc... "[2] Now I'll take the risk to comment far from my knowledge boundaries (I don't have scientific statistics, I don't have a MBA and I'm not a sociologist, but if you pay me well I can be <g>). As to my knowledge WP is used for personal blogs mainly. The communities built around WP blogs have few to share with the communities built around drupal and we are in a different market place (market place is a matter of money, demand and offer). Currently I see no competition in drupal market place. It has some overlap with Joomla market place but it is not the same, it has some overlap with WP too but it is not the same. I would keep trying to be the leader in this market place rather than trying to erode other market places that in my point of view are less interesting from a programmer point of view, less lucrative and destined to be doomed. But as Balazs Dianiska wrote: Whom do we want to make Drupal for? *My* answer is: for devs so I would put more weight on flexibility and fast development rather than specialisation. Again... I understand this *may* have an impact on the "marketing" side of the equation that will help to pay my bills. Furthermore... blogs are hot now. By the time we make drupal a super-blog, respecting its architecture something else may be hot or we may miss to understand what a super-blog is/will be. Again... that's not diminishing Liza suggestion that we shouldn't underestimating blog importance. Drupal without a prime class *platform* for blogging would be a pariah. [1] that doesn't mean they can't be followed, adapted etc... without substantial loss to flexibility or fast development... again I refer to Larry Garfield's post and the proposal of profiles. [2] eg. if I were a journalist I'd push to have wonderful blogging support now... no matter if in 1 year that won't be enough or will have nefarious impact on the architecture... I'll have my tool now... and tomorrow I'll still be a journalist. If they want a super-duper-blogging platform now, let them share the risk/cost and ask for paid customisation. And OK... I know this sounds rude, not "communitarian" bla bla... I got out of sugar and time devoted to philosophy ;) -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 10 Nov 2007, at 08:57, Dries Buytaert wrote:
I asked Chris Messina (http://factoryjoe.com/blog/) to fiddle with Drupal 6 and to share his thoughts:
See http://drupal.org/node/191073. Thanks Keith! :-) -- Dries Buytaert :: http://www.buytaert.net/
A wiki page is needed to *act* on this. I have worked most of Chris' comments into http://groups.drupal.org/node/7043 and added my comments. Kind regards, NK
participants (32)
-
adrian rossouw -
Balazs Dianiska -
Boris Mann -
Brad Bowman -
catch -
catch libcom
-
Chris Johnson -
Daniel F. Kudwien -
David Strauss -
Derek Wright -
Dmitri G -
Dries Buytaert -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Greg Knaddison -
Gábor Hojtsy -
Ivan Sergio Borgonovo -
Iñaki Lopez -
Josh Koenig -
Karoly Negyesi -
Larry Garfield -
matt＠mattfarina.com -
Philippe Jadin -
Sean Robertson -
Shai Gluskin -
Shakur -
Steven Peck -
Wim Mostrey -
Xavier Bestel -
zeljko blace