Re: [development] Being noisy on installation...
On Apr 11, 2008, at 1:37 AM, Earl Miles wrote:
I'm not sure Views originated this technique; but then again, I'm not sure it didn't.
i'm pretty sure i was the first person to do this. which either makes me a visionary or a bastard depending on how you look at it... ;) my personal opinion is that core should be more informative about what happens for something as important as a module installation. without the messages i currently hack into my own modules, the only way a user knows anything happened at all is by scrolling down the mile long list of checkboxes, and making sure that their module is now marked as enabled -- lame.
Chad Phillips -- Apartment Lines wrote:
On Apr 11, 2008, at 1:37 AM, Earl Miles wrote:
I'm not sure Views originated this technique; but then again, I'm not sure it didn't.
i'm pretty sure i was the first person to do this. which either makes me a visionary or a bastard depending on how you look at it... ;)
Are the two really that mutually exclusive? How about both ;).
my personal opinion is that core should be more informative about what happens for something as important as a module installation. without the messages i currently hack into my own modules, the only way a user knows anything happened at all is by scrolling down the mile long list of checkboxes, and making sure that their module is now marked as enabled -- lame. Agreed. At the core of this discussion is the desire to determine the types of message communications that drupal has to communicate and how they should be handled. Here is my list of suggestions off the cuff:
1. Errors - these are php generated warnings and problems (e.g. mysql errors, missing directories/files, and foreach warnings) that have been caught by modules and forwarded to the msg queue system. 2. Status - These are regular messages that reflect or confirm the success of operations on users, content and settings in the system. (e.g. "Post created", and "setting set") 3. Information/instruction - The could be instructions for further inspection or for future consideration regarding operations like having installed a module (e.g. "You can configure this module <a>here</a>") or created a content type (e.g. "Add some fields by clicking on the add fields tab") 4. Extended/Debug - While many of us prefer debuggers sometimes it is nice to see an extended log of the operations that are important for quick diagnosis of the probelm or just to shepherd the process with al ittle more mental certainty that all went well. This wouldnt be a recreation of the devel module query log or anythign similar and would only show those "debug" messages that have been output by the modules that fired. (e.g. "Required tables created", "Imagecache tables and files purged") These are the 4 main types of messages i can think of that i would like to get from drupal. I may have missed some, please correct if i have. Following PHP's bitwise comparison operator and assigning these different message types simple integers that are able to be compared in a bitwise fashion opens up a number of opportunities for setting "site wide" (Admin > site information"), role wide (access permission?) or user specific (user edit page) output preferences for system messages. define("DRUPAL_MESSAGE_ERROR" 1); define("DRUPAL_MESSAGE_STATUS" 2); define("DRUPAL_MESSAGE_INFORMATION" 4); define("DRUPAL_MESSAGE_DEBUG" 8); The line isnt always black and white and in the end it would be up to the developer of the module to decide what type of message one should be. This is only a slight extension of the existing system and a formalization of the status types into constants but i think it solves a number of the issues if we implement the bitwise comparison operator message settings properly for users or roles if those are desired characteristics. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
the messages i currently hack into my own modules, the only way a user knows anything happened at all is by scrolling down the mile long list of checkboxes, and making sure that their module is now marked as
Erm. What about the "The configuration options have been saved." msg? -- Morbus Iff ( there is no morbus, there is only zuul! ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
Morbus Iff wrote:
the messages i currently hack into my own modules, the only way a user knows anything happened at all is by scrolling down the mile long list of checkboxes, and making sure that their module is now marked as
Erm. What about the "The configuration options have been saved." msg?
That doesn't tell me much if I checked 3 modules. It certainly doesn't tell me that I failed to check the 4th module that I thought I did. =)
Erm. What about the "The configuration options have been saved." msg?
That doesn't tell me much if I checked 3 modules. It certainly doesn't tell me that I failed to check the 4th module that I thought I did. =)
So, what would you want it to say? Let's work with the assumption that someone is installing 4 modules. Two of them have standard admin settings to configure, one requires a taxonomy first, then an admin screen, and one has no settings at all. What happens next? -- Morbus Iff ( and i twirled my hair and i popped my gum ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Fri, Apr 11, 2008 at 8:13 PM, Morbus Iff <morbus@disobey.com> wrote:
Erm. What about the "The configuration options have been saved." msg?
That doesn't tell me much if I checked 3 modules. It certainly doesn't tell me that I failed to check the 4th module that I thought I did. =)
So, what would you want it to say? Let's work with the assumption that someone is installing 4 modules. Two of them have standard admin settings to configure, one requires a taxonomy first, then an admin screen, and one has no settings at all. What happens next?
How about something like this? Modules foo and bar have been enabled. Module baz has been disabled. Configure settings for newly enabled modules (per Senpai's e-mail).
I suggest that everyone who wants to participate in this discussion should do so at the relevant issue: http://drupal.org/node/230059. In other words, stop posting to this 1000+ person list. Thanks.
On Fri, Apr 11, 2008 at 4:47 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
I suggest that everyone who wants to participate in this discussion should do so at the relevant issue: http://drupal.org/node/230059. In other words, stop posting to this 1000+ person list. Thanks.
1. It is not immediately nor magically apparent that #230059 is the "relevant issue", although possibly, now that you have drawn it to our attention in your inimitable fashion, a good solution to it in and of itself. 2. Why can't 1000+ persons, interested in discussing Drupal development, discuss this? 3. Is it clear to you what kind of an atmosphere you create with comments such as the one you have just made? Sincerely, Victor Kane http://awebfactory.com.ar
Victor, the issue is the right place to discuss a particular feature for Drupal. Information that is posted to this list might be missing in the issue (where it is badly needed). IMHO, Moshe's message was not offensive and wasn't meant to be offensive for sure. It's just that not everyone on this list has the same development focus at the same time. Thus, posting to this list regarding a particular issue is not appropriate if there is already an issue filed at d.o. cheers, Daniel ________________________________ From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Victor Kane Sent: Friday, April 11, 2008 10:34 PM To: development@drupal.org Subject: Re: [development] Being noisy on installation... On Fri, Apr 11, 2008 at 4:47 PM, Moshe Weitzman <weitzman@tejasa.com> wrote: I suggest that everyone who wants to participate in this discussion should do so at the relevant issue: http://drupal.org/node/230059. In other words, stop posting to this 1000+ person list. Thanks. 1. It is not immediately nor magically apparent that #230059 is the "relevant issue", although possibly, now that you have drawn it to our attention in your inimitable fashion, a good solution to it in and of itself. 2. Why can't 1000+ persons, interested in discussing Drupal development, discuss this? 3. Is it clear to you what kind of an atmosphere you create with comments such as the one you have just made? Sincerely, Victor Kane http://awebfactory.com.ar
No nothing personal, that's for sure. And you almost had me convinced except for the last sentence: "In other words, stop posting to this 1000+ person list" Hierarchical and territorial attitudes are out of place in a community, even in a meritocracy. No reason to accept it. Get enough of that from the bosses. Victor On Fri, Apr 11, 2008 at 6:07 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Victor,
the issue is the right place to discuss a particular feature for Drupal. Information that is posted to this list might be missing in the issue (where it is badly needed). IMHO, Moshe's message was not offensive and wasn't meant to be offensive for sure. It's just that not everyone on this list has the same development focus at the same time. Thus, posting to this list regarding a particular issue is not appropriate if there is already an issue filed at d.o.
cheers, Daniel
________________________________
From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Victor Kane Sent: Friday, April 11, 2008 10:34 PM To: development@drupal.org Subject: Re: [development] Being noisy on installation...
On Fri, Apr 11, 2008 at 4:47 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
I suggest that everyone who wants to participate in this discussion should do so at the relevant issue: http://drupal.org/node/230059. In other words, stop posting to this 1000+ person list. Thanks.
1. It is not immediately nor magically apparent that #230059 is the "relevant issue", although possibly, now that you have drawn it to our attention in your inimitable fashion, a good solution to it in and of itself.
2. Why can't 1000+ persons, interested in discussing Drupal development, discuss this?
3. Is it clear to you what kind of an atmosphere you create with comments such as the one you have just made?
Sincerely,
Victor Kane http://awebfactory.com.ar
Victor Kane wrote:
No nothing personal, that's for sure. And you almost had me convinced except for the last sentence: "In other words, stop posting to this 1000+ person list"
While i agree that im not sure the issue he highlighted is the correct issue to rally around for this diverse topic, i *DO* agree that the list shouldnt be used for prolonged discussion over implementations, etc. It should be used to highlight issues that pop up from time to time and to point to the organized and structured conversations to the resources (issue queues and group discussions) that are meant for that express purpose. I think that we can all agree that the decentralized nature of email make its use as a storage and organizational mechanism less than optimal to this task. Im sure nobody meant to step on anyone else. Its Friday, lets cheer up, move the conversation on and develop a solution to the problem. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
It should be used to highlight issues that pop up from time to time and to point to the organized and structured conversations to the resources (issue queues and group discussions) that are meant for that express
If you think that the issue queue, which lacks automatic quoting capability, inline previews, spell checking, threading, and a dozen other capabilities that email clients still excel at, is an "organized and structured conversation", then I respectfully disagree ;)
I think that we can all agree that the decentralized nature of email make its use as a storage and organizational mechanism less than optimal to this task.
No, I disagree entirely. But, with that said, I also agree that the issue posted has nothing to do with what /my/ main goal was (dsm() vs. no dsm()), and stated that privately to Moshe, all with one keycommand (as opposed to 2+ clicks and the same "lack of" capabilities that applies to the contact form). -- Morbus Iff ( i've no more shoulders, only chips ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Fri, 11 Apr 2008 12:00:38 -0500, Michael Favia <michael@favias.org> wrote: *snip*
Following PHP's bitwise comparison operator and assigning these different message types simple integers that are able to be compared in a bitwise fashion opens up a number of opportunities for setting "site wide" (Admin > site information"), role wide (access permission?) or user specific (user edit page) output preferences for system messages.
define("DRUPAL_MESSAGE_ERROR" 1); define("DRUPAL_MESSAGE_STATUS" 2); define("DRUPAL_MESSAGE_INFORMATION" 4); define("DRUPAL_MESSAGE_DEBUG" 8);
The line isnt always black and white and in the end it would be up to the developer of the module to decide what type of message one should be.
This is only a slight extension of the existing system and a formalization of the status types into constants but i think it solves a number of the issues if we implement the bitwise comparison operator message settings properly for users or roles if those are desired characteristics.
There actually is an RFC-defined standard for such message levels, which the watchdog system now uses as of Drupal 6. If we are going to introduce more fine-grained message levels for drupal_set_message(), it should use the same standard. (I'm not against the concept; it's interesting, but if we do it then as always it should be done right.) In Boston, DmitriG and I were talking about install-profile-as-module and he suggested making the modules page into a multi-step form. That is, after you select your new 3 modules, the next page you see is the permissions page for all roles but just for the modules you enabled. That lets you do the initial permission set up immediately, before you get back to the modules page. (You can, of course, still go to the permissions page at any time.) He also suggested letting modules add their own config pages to a form that gets shown immediately after that, which would replace profile configuration. That could also be useful for initial configuration for at least some modules. (I make no claim to the above ideas; I am just relaying them.) --Larry Garfield
This issue is from Senpai, but discusses some options (including DimitriG's idea) http://drupal.org/node/230059 -Mike On Apr 11, 2008, at 11:26 AM, Larry Garfield wrote:
In Boston, DmitriG and I were talking about install-profile-as- module and he suggested making the modules page into a multi-step form. That is, after you select your new 3 modules, the next page you see is the permissions page for all roles but just for the modules you enabled. That lets you do the initial permission set up immediately, before you get back to the modules page. (You can, of course, still go to the permissions page at any time.) He also suggested letting modules add their own config pages to a form that gets shown immediately after that, which would replace profile configuration. That could also be useful for initial configuration for at least some modules.
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 949.200.7595 714.356.0168 cell 949.200.7670 fax
On Fri Apr 11 2008 9:21:05 am Chad Phillips -- Apartment Lines wrote:
my personal opinion is that core should be more informative about what happens for something as important as a module installation. without the messages i currently hack into my own modules, the only way a user knows anything happened at all is by scrolling down the mile long list of checkboxes, and making sure that their module is now marked as enabled -- lame.
As the situation currently stands, that is actually no better. When I enable, say, ten modules at one time and get three "Your module was enabled." messages, that does not improve the situation. I would rather scroll down the list and get that visual confirmation. If this changes so that all modules display that message, then having ten "Your module was enabled." messages won't really be much more help, though I could then at least count the messages. Having "The $module module was enabled." (or something similar) would be better. -- Jason Flatt http://www.oadaeh.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; Travis, 11; Angela; Harry, 7; and William, 2) Linux User: http://www.kubuntu.org/ Drupal Fanatic: http://drupal.org/
participants (11)
-
catch -
Chad Phillips -- Apartment Lines -
Daniel F. Kudwien -
Earl Miles -
Jason Flatt -
Larry Garfield -
Michael Favia -
Michael Prasuhn -
Morbus Iff -
Moshe Weitzman -
Victor Kane