Being noisy on installation...
So, I was reading over: http://drupal.org/node/161085 and saw one of my personal pet peeves jump out: "Even if your module doesn't have need of a hook_install function, it's nice to Display a note confiriming that the module is installed and ready for action." Core doesn't do it at all and, as far as I can tell, it originated with Views (which most folks take as an admonition that It's Right). Thoughts from the peanut gallery? At first blush, I'm horrifically opposed to it, because I think we have enough to worry about then reading /successful/ messages - I'd much rather Drupal interrupt me when something /bad/ has happened, not when something I /expect/ to happen actually happened. But, playing my own devil's advocate, I could say that "well, there's precedence already - we always inform the user when something has been created, updated, or deleted successfully". Whatever we decide, I care about consistency. If we're going to recommend this in our style guides, then /core should do the same thing/. -- Morbus Iff .sig on the other machine
I'm also opposed to this -- vigorously. Having built a number of custom profiles and related solutions for clients, it is a *pain* to have those modules splattering their messages all over during a carefully managed process. chx and I actually tried to get drupal_set_message() moved out of submit handlers as well, so that automated form processing wouldn't do the same thing, but we ran out of time to push through minor features like that. --Jeff On Apr 11, 2008, at 12:28 PM, Morbus Iff wrote:
and saw one of my personal pet peeves jump out: "Even if your module doesn't have need of a hook_install function, it's nice to Display a note confiriming that the module is installed and ready for action." Core doesn't do it at all and, as far as I can tell, it originated with Views (which most folks take as an admonition that It's Right).
Thoughts from the peanut gallery? At first blush, I'm horrifically opposed to it, because I think we have enough to worry about then reading /successful/ messages - I'd much rather Drupal interrupt me when something /bad/ has happened, not when something I /expect/ to happen actually happened. But, playing my own devil's advocate, I could say that "well, there's precedence already - we always inform the user when something has been created, updated, or deleted successfully".
I realize that this is slightly off topic, but having run into situations where I wanted to suppress the messages, I simply called drupal_get_message and reset the message queue. Perhaps these calls could be added to the profiile installations as well as drupal_execute to make sure that these messages don't interfere with the automated processes. Anyway it's worked for me in the past, so I thought I'd mention it incase it just hadn't been thought of yet. Dave On Apr 10, 2008, at 8:06 PM, Jeff Eaton wrote:
I'm also opposed to this -- vigorously. Having built a number of custom profiles and related solutions for clients, it is a *pain* to have those modules splattering their messages all over during a carefully managed process.
chx and I actually tried to get drupal_set_message() moved out of submit handlers as well, so that automated form processing wouldn't do the same thing, but we ran out of time to push through minor features like that.
--Jeff
On Apr 11, 2008, at 12:28 PM, Morbus Iff wrote:
and saw one of my personal pet peeves jump out: "Even if your module doesn't have need of a hook_install function, it's nice to Display a note confiriming that the module is installed and ready for action." Core doesn't do it at all and, as far as I can tell, it originated with Views (which most folks take as an admonition that It's Right).
Thoughts from the peanut gallery? At first blush, I'm horrifically opposed to it, because I think we have enough to worry about then reading /successful/ messages - I'd much rather Drupal interrupt me when something /bad/ has happened, not when something I / expect/ to happen actually happened. But, playing my own devil's advocate, I could say that "well, there's precedence already - we always inform the user when something has been created, updated, or deleted successfully".
David Metzler wrote:
I realize that this is slightly off topic, but having run into situations where I wanted to suppress the messages, I simply called drupal_get_message and reset the message queue. And if you want to make sure that PRE-EXISTING messages were stored and transcribed you could take care to save the state before and restore it after if desired.
-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
Well, we should handle the noise in the same way Linux does: on the one hand there are switches for noisy (-v) and quiet, and on the other, all utilities provide comforting messages for the newbie by default, which more experienced hands, justly horrified by so much need for calming insecurity, know how to send to the bit bucket for automated or cron run processes via a redirect to /dev/null. Since this whole discussion seems to have evolved into a "how to improve the module installation process" or even "what should our module installation process be like", I think it should incorporate this time proven administration pattern: provide switches for noise levels and have the option to send all output to the bit bucket, but for heaven's sake, keep the warm and fuzzies for the newbies! saludos, Victor Kane http://awebfactory.com.ar On Fri, Apr 11, 2008 at 12:06 AM, Jeff Eaton <jeff@viapositiva.net> wrote:
I'm also opposed to this -- vigorously. Having built a number of custom profiles and related solutions for clients, it is a *pain* to have those modules splattering their messages all over during a carefully managed process.
chx and I actually tried to get drupal_set_message() moved out of submit handlers as well, so that automated form processing wouldn't do the same thing, but we ran out of time to push through minor features like that.
--Jeff
On Apr 11, 2008, at 12:28 PM, Morbus Iff wrote:
and saw one of my personal pet peeves jump out: "Even if your module
doesn't have need of a hook_install function, it's nice to Display a note confiriming that the module is installed and ready for action." Core doesn't do it at all and, as far as I can tell, it originated with Views (which most folks take as an admonition that It's Right).
Thoughts from the peanut gallery? At first blush, I'm horrifically opposed to it, because I think we have enough to worry about then reading /successful/ messages - I'd much rather Drupal interrupt me when something /bad/ has happened, not when something I /expect/ to happen actually happened. But, playing my own devil's advocate, I could say that "well, there's precedence already - we always inform the user when something has been created, updated, or deleted successfully".
Victor Kane wrote:
Well, we should handle the noise in the same way Linux does: on the one hand there are switches for noisy (-v) and quiet, and on the other, all utilities provide comforting messages for the newbie by default, which more experienced hands, justly horrified by so much need for calming insecurity, know how to send to the bit bucket for automated or cron run processes via a redirect to /dev/null.
So perhaps we can just let each user decide which level of messages he/she wants to see ('error', 'status', 'warning'), and expand the list of possible types.
Morbus Iff wrote:
So, I was reading over:
and saw one of my personal pet peeves jump out: "Even if your module doesn't have need of a hook_install function, it's nice to Display a note confiriming that the module is installed and ready for action." Core doesn't do it at all and, as far as I can tell, it originated with Views (which most folks take as an admonition that It's Right).
Thoughts from the peanut gallery? At first blush, I'm horrifically opposed to it, because I think we have enough to worry about then reading /successful/ messages - I'd much rather Drupal interrupt me when something /bad/ has happened, not when something I /expect/ to happen actually happened. But, playing my own devil's advocate, I could say that "well, there's precedence already - we always inform the user when something has been created, updated, or deleted successfully".
Whatever we decide, I care about consistency. If we're going to recommend this in our style guides, then /core should do the same thing/.
I'm not sure Views originated this technique; but then again, I'm not sure it didn't. Right now, our module install process is <b>horrible</b> about giving feedback. When installing a new module, <b>I</b> still have trouble figuring out what to do next. This is an area that desperately needs improvement. I agree that splashing up a "this has been installed" message isn't the answer, but some feedback is better than no feedback; but it's not really enough. We need to be telling users what to do next.
On Thu, Apr 10, 2008 at 9:29 PM, Earl Miles <merlin@logrus.com> wrote:
Right now, our module install process is <b>horrible</b> about giving feedback. When installing a new module, <b>I</b> still have trouble figuring out what to do next. This is an area that desperately needs improvement. I agree that splashing up a "this has been installed" message isn't the answer, but some feedback is better than no feedback; but it's not really enough. We need to be telling users what to do next.
The problem is that we use drupal_set_message() with messages of type "status" for anything from notification messages to help text and links supposed to guide the users. The problems with that are: 1. It's impossible to distinguish between them programmatically, forcing developers to use hacks such as calling drupal_get_message() to alter messages by resetting the whole array. 2. Every user gets the same information, no matter of their needs. When my dad installs drupal he will want that help text that chx is trying to get rid of. 3. It's not a good location for help, because users cannot go back to it. Users associate messages with the page they see it on, not the submit handler of the form they just submitted. Some discussions at drupalcon led to the idea of having a tutorial module providing a tutorial hook, with an interface similar to the tutorials in the Eclipse IDE. By defining a sequence of actions, we can walk the user through a specific task (example: create a content type and assign a taxonomy term to it), and display the progress in a block with as much information as is needed. The key difference here is that the verbose help is triggered when the user makes the decision to start a tutorial instead of being directly tied to the actions being executed. I already have a semi-functional prototype sitting on my laptop, and with the help of some people this could really be turned into a killer feature in terms of usability: better help for new users, and a cleaner interface for the others.
Quoting Earl Miles <merlin@logrus.com>:
We need to be telling users what to do next.
Doesn't that belong in admin/logs/status? But we would need a hook_status. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
` Iff wrote:
Whatever we decide, I care about consistency. If we're going to recommend this in our style guides, then /core should do the same thing/.
Consistency is important. When I was younger, my mother always told me to call her when I was away, so she knows everything is fine. I figured out that if I start doing it, she'll get used to the idea, and then, even if something /good/ prevents me from calling - she'd be worried... So I decided to call only if I needed something (which didn't prevent her from worrying :-) ) Based on my own experience, I can tell that *most people expect feedback also for successful operations*, mostly when they are not very technical (95% of the users, no?). I see many users that are literally afraid of doing stuff on the site, because they don't want to break anything. Drupal can be scary to the common user. Having the green messages is a calming thing - as a user I know I did something good, that didn't break the site. it has a great value. On the other hand, there should be a way of selectively not displaying some or all messages, in a comfortable manner. How about a hook_message_alter? Has this ever been discussed? Zohar
On Thu, Apr 10, 2008 at 11:25 PM, Zohar Stolar <z.stolar@gmail.com> wrote:
[...] On the other hand, there should be a way of selectively not displaying some or all messages, in a comfortable manner. How about a hook_message_alter? Has this ever been discussed?
I actually wrote a patch to add a hook_message_alter, but after some investigation it turned out not to be a viable solution. Among other issues, messages do not have a unique identifier that lets you target them individually, and errors in the implementations of the hook_message_alter hook only show up on the next page load.
What's missing from the whole process is something linking you directly to the permissions for the module you just installed and/or the configuration pages. This'd save a massive amount of time. If I'm not already user/1 I almost always forget to enable permissions for myself then hunt around for a menu item, then go to the permissions page and if I'm lucky something's there, and I always forget admin by module exists as well. When what I really want to do is 1-click permissions, 1-click configuration probably 90% of the time. If we can provide that kind of useful information somewhere then the drupal_set_message() is redundant.
WIld idea: Maybe we need a drupal_set_next_task_link() or something. It would persist from page to page until either clicked on or dismissed. ..chris On Fri, Apr 11, 2008 at 9:30 AM, catch <catch56@googlemail.com> wrote:
What's missing from the whole process is something linking you directly to the permissions for the module you just installed and/or the configuration pages. This'd save a massive amount of time.
"Relating to what Earl mentioned before ("When installing a new module, I still have trouble figuring out what to do next"): In the efforts of making Drupal more user-friendly, I also think that the install messages can include a little notice of what to do next. For example: after enabling "blog" - have a link to the admin/content/types/blog after enabling "contact" - have a link to the admin/build/contact, and remind the user to activate the menu item after enabling "comment" - remind the user to check permissions, and configure individual content types settings"
WIld idea: Maybe we need a drupal_set_next_task_link() or something. It would persist from page to page until either clicked on or dismissed.
That's an interesting idea - a flag to dsm('', '', $persistent) that would a) watchdog() the message, b) display the text on every page with a "hide message" that the user could manually click on to hide it later. Persistent messages would be logged in the watchdog log. The potential problem with this, however, is to /whom/ the message is persistent. If five people are admins, and one enables a certain module, dsm() would traditionally persist the message only to the enabler (since they're all stored in $_SESSION, of course). -- Morbus Iff ( for safety's sake, don't humiliate me ) 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 wrote:
That's an interesting idea - a flag to dsm('', '', $persistent) that would a) watchdog() the message, b) display the text on every page with a "hide message" that the user could manually click on to hide it later. Persistent messages would be logged in the watchdog log.
The potential problem with this, however, is to /whom/ the message is persistent. If five people are admins, and one enables a certain module, dsm() would traditionally persist the message only to the enabler (since they're all stored in $_SESSION, of course).
--
I like this, and I don't think it matters if it's stored in $_SESSION and only applies to the admin who enables something. I want a quick link to take me to the next step of a task I'm doing, not a list of all the links some other admin hasn't bothered to follow or switch off. Opened an issue here: http://drupal.org/node/245417
Quoting catch <catch56@googlemail.com>:
What's missing from the whole process is something linking you directly to the permissions for the module you just installed and/or the configuration pages. This'd save a massive amount of time.
If I'm not already user/1 I almost always forget to enable permissions for myself then hunt around for a menu item, then go to the permissions page and if I'm lucky something's there, and I always forget admin by module exists as well. When what I really want to do is 1-click permissions, 1-click configuration probably 90% of the time. If we can provide that kind of useful information somewhere then the drupal_set_message() is redundant.
I always use admin/by-module after installing a new module. It gives the list of administrative actions for the modules. Find your module and take care of the administration from there. Having a menu block for Admin By Module might be nice, then you don't lose the visibility as you do when you click the administrative link on the admin/by-module page. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Florian Loretan wrote:
On Thu, Apr 10, 2008 at 11:25 PM, Zohar Stolar <z.stolar@gmail.com <mailto:z.stolar@gmail.com>> wrote:
[...] On the other hand, there should be a way of selectively not displaying some or all messages, in a comfortable manner. How about a hook_message_alter? Has this ever been discussed?
I actually wrote a patch to add a hook_message_alter, but after some investigation it turned out not to be a viable solution. Among other issues, messages do not have a unique identifier that lets you target them individually, and errors in the implementations of the hook_message_alter hook only show up on the next page load. I guess the patch should include a modification of drupal_set_message, to add a unique message identifier. Such a method is used with drupal_mail, that forces a unique identifier for each out-going mail. However, modules don't usually send mails as often as they present messages, so this solution can be too hard to implement (imagine that you have to track all your messages, and give them unique ids... ). Adding messages to a modules would then become a nightmare. If we want to communicate with the users, then presenting them messages should stay an easy thing to do.
(I notice this thread is loosing contact with its subject... going back to the discussion about install messages:) Relating to what Earl mentioned before ("When installing a new module, I still have trouble figuring out what to do next"): In the efforts of making Drupal more user-friendly, I also think that the install messages can include a little notice of what to do next. For example: after enabling "blog" - have a link to the admin/content/types/blog after enabling "contact" - have a link to the admin/build/contact, and remind the user to activate the menu item after enabling "comment" - remind the user to check permissions, and configure individual content types settings etrc.
In the efforts of making Drupal more user-friendly, I also think that the install messages can include a little notice of what to do next. For after enabling "blog" - have a link to the admin/content/types/blog
But, as someone else mentioned, that's not entirely useful because dsm()'s disappear. If a user has installed five modules, each that gives a link to click on, we're now hoping our users will click each into a new browser tab, otherwise, they'll click one, configure, click the Back button a few times (or else just manually navigate to the modules page) and find that the help is gone. -- Morbus Iff ( est quaedam flere voluptas ) 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
An initial discussion of a hook_message_alter was here, http://drupal.org/node/127262. The ideas of messages identifiers like drupal_mail was knocked around, but no consensus was reached, and then the D6 code freeze kicked in. "..... On the other hand, there should be a way of selectively not displaying some or all messages, in a comfortable manner. How about a hook_message_alter? Has this ever been discussed? Zohar"
Morbus Iff wrote:
saw one of my personal pet peeves jump out we have enough to worry about then reading /successful/ messages Maybe I shouldn't have you review my modules, because I do this and support the practice.
Morbus (et al.) this is not there for someone who knows everything about Drupal; it is there for those who know next to nothing about Drupal and are afraid of it. I maintain a bunch of modules and am constantly amazed at the number of issues that are opened saying, "How do I use this?" And I try to be more helpful in my documentation than many other developers. Anything that helps the user go on to the next step is an improvement. Earl Miles wrote:
installing a new module, I still have trouble figuring out what to do next Exactly, many users don't have a clue. Do they need to run update.php next? Should they immediately go to the settings page (and, BTW, where is it)? Do they need to set up a vocabulary?
Yes, this should all be documented in the README file -- and a handbook page. But there are many users who don't even know that README.txt is a standard and should be present - oh, and this includes many module developers. Jeff Eaton wrote:
custom profiles and related solutions for clients, it is a *pain* to have those modules splattering their messages all over during a carefully managed process. Jeff, I can sympathize with this, but perhaps Florian Loretan is on the right track with the hook_tutorial idea.
Zohar Stolar wrote:
imagine that you have to track all your messages, and give them unique ids It may very well be a PITA for Drupallers, but this is common practice in many mainframe systems so that users can open a book that tells them what to do when they see "IEF123A Invalid option detected: FOO_BAR" (oh, the "A" also tells the user that "action" is required). Even though it means some extra work for me, I am not opposed to this practice.
Catch wrote:
something linking you directly to the permissions for the module you just installed and/or the configuration pages then the drupal_set_message() is redundant Amen. The step-by-step process. But its presence needs to be persistent for those users who need it.
Nancy E. Wichmann, PMP
Maybe I shouldn't have you review my modules, because I do this and support the practice.
Congratulations, you're the first winner of the "We disagree on something, so therefore, everything said must be irrelevant!" award! Really, I'm conflicted about the whole thing: * core doesn't do it * the guides say to do it It's a matter of /which/ is wrong? You'll note that my lament is /solely/ about those modules that say "MODULE has been successfully installed" - I never mentioned, at all, the possibility of including a link to a configuration page. Because of the current *non* persistent nature of a dsm(), yes, I believe that a link to a configuration page is folly, since the user *can never get that suggestion back* if he navigates away from the page. I would be OK, on the other hand, with a link to a Drupal.org handbook page that explains how to use your module. It "solves" a few of the problems inherent in using a non-persistent dsm() as help: * if your module has multiple steps of configuration, or multiple screens of configuration, stuffing them all inside a dsm() is bad. * it centralizes documentation in the Drupal handbook, which is peer-reviewed, and could support multiple guides for multiple versions of your module. people may not know about a README.txt, but they probably know about the docs on drupal.org. * it allows the possibility of screenshots and commenting. Using the dsm(), even for a handbook link, however, does not solve the problem of multiple modules being enabled at the same time (all with their own dsm() pulling at the attention span of the user), or its lack of persistence. I would find the tantalizing suggestion of a module's rabbit hole, lost forever because I happened to click elsewhere, had my browser crashed, or whatever, absolutely infuriating. It's a tease: "I gave you the docs, but you lost them and you'll never get them back." I have absolutely /no/ complaint about increasing the visibility or attentiveness of a module's ease-of-use. Why would I? Come on, I use just as many contrib modules as anyone else, and I have no freaking clue how they operate either. You really think that being a Drupal "expert" gives me any edge on installing and using geshifilter (which, note, I spent an hour failing miserably at getting it to work for Drupal Tough Love, and installed codefilter instead)? I just don't think that using the current dsm() is the right place to do this. What about including an "administer" link on each module's entry on admin/build/modules and it'd take you to admin/by-module#MODULENAME, so you could see all the admin-y menus that it defines? -- Morbus Iff ( is this a cut out bath-poster Morbus, or what? ) 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 6:36:36 am Morbus Iff wrote:
What about including an "administer" link on each module's entry on admin/build/modules and it'd take you to admin/by-module#MODULENAME, so you could see all the admin-y menus that it defines?
http://drupal.org/node/216301#comment-712479 "... Quick access to the configuration area. Usually, after I've installed a module (or theme), the first thing I want to do is check out what configuration options and access controls are available. That is usually a two or three click process (not counting the time it takes to re-find the module). If the module is one of those that puts its settings in a non-standard place, it's many more clicks ("Where is that page?"). Also, along this same vein, indicating that there are no configuration or access control settings, so I don't spend five minutes looking for the non-existent page. ..." -- 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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Flatt schrieb:
On Fri Apr 11 2008 6:36:36 am Morbus Iff wrote:
What about including an "administer" link on each module's entry on admin/build/modules and it'd take you to admin/by-module#MODULENAME, so you could see all the admin-y menus that it defines?
http://drupal.org/node/216301#comment-712479
"... Quick access to the configuration area.
Usually, after I've installed a module (or theme), the first thing I want to do is check out what configuration options and access controls are available. That is usually a two or three click process (not counting the time it takes to re-find the module). If the module is one of those that puts its settings in a non-standard place, it's many more clicks ("Where is that page?"). Also, along this same vein, indicating that there are no configuration or access control settings, so I don't spend five minutes looking for the non-existent page. ..."
I usually check the code for config options/permissions I might need to deal with... I wouldn't mind to give up that habit... Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH/36Bfg6TFvELooQRAvtkAKCkb0fxcnvaugHuIX9hrxOd5MuSfwCgusBW HlevZG2Q1VZJeZU5JBI79pg= =yRTb -----END PGP SIGNATURE-----
Jason Flatt wrote:
On Fri Apr 11 2008 6:36:36 am Morbus Iff wrote:
What about including an "administer" link on each module's entry on admin/build/modules and it'd take you to admin/by-module#MODULENAME, so you could see all the admin-y menus that it defines?
http://drupal.org/node/216301#comment-712479
"... Quick access to the configuration area.
Usually, after I've installed a module (or theme), the first thing I want to do is check out what configuration options and access controls are available. That is usually a two or three click process (not counting the time it takes to re-find the module). If the module is one of those that puts its settings in a non-standard place, it's many more clicks ("Where is that page?"). Also, along this same vein, indicating that there are no configuration or access control settings, so I don't spend five minutes looking for the non-existent page. ..."
This is one of the things that, IMO, is best covered in an accompanying readme -- links to all the places where you need to go to configure the module. This is also one of the uses of the admin/by-module page -- perhaps if we focused on a brief message there that referred users to the readme, the handbook page, the help documentation within the module, etc. This would both reduce the noise on install, and provide a central place that already exists to use as a starting point for this type of (very helpful) info. This brief message could also indicate that a module had no config options.
The thing is, you cannot make assumptions based on a single used case. Both newbie, chronically interactive and power batch pros should be catered for. A power batch pro may want to install a bunch of modules, then run an installation script for configuration, or what have you... Victor On Fri, Apr 11, 2008 at 1:31 PM, Bill Fitzgerald <bill@funnymonkey.com> wrote:
Jason Flatt wrote:
... Usually, after I've installed a module (or theme), the first thing I want to do is check out what configuration options and access controls are available. That is usually a two or three click process (not counting the time it takes to re-find the module). If the module is one of those that puts its settings in a non-standard place, it's many more clicks ("Where is that page?"). Also, along this same vein, indicating that there are no configuration or access control settings, so I don't spend five minutes looking for the non-existent page. ..."
Morbus Iff said:
Congratulations, you're the first winner of the "We disagree on something, so therefore, everything said must be irrelevant!" award! Hooray, I won something!
My statement was somewhat tongue-in-cheek (couldn't you read my smile in that message?). If I followed that tack, I'd have been gone from Drupal long ago. I disagree often with the "Drupal-gods" but I also find that I often come around to their thoughts eventually. Yes, I have included a "module successfully installed" message in some of my modules. This thread is making me rethink that, but with a view to how to improve the message, such as a "RTFM" link. I will probably go back and revisit those modules. Personally, I like the idea of a link to "administer" the module (going to the by-module page). However, this does not cover all the bases all the time. For example, there are taxonomy-based modules for which the first step should be to set up, or modify, a vocabulary - even before going to the settings pages. For me, I find the easiest way to do my Coder reviews is via the module page; it would also be nice to link from there to the translation template extractor. But now I hear the screaming about link bloat. Being an "expert" may or may not help you with a module that simply does not function as you wish (but this could also be part of the problem). However, it does mean that you are more likely to know to go the administer page, and how to find the vocabulary creation page along with it's terms, then how to make sure the permissions are correctly set, ... etc. I've read many posts from people who don't know all these steps (yet). There are many inexperienced Drupallers who haven't even thought of the idea of having multiple browser windows so they can flip from docs to admin pages and back again. I do like the idea that was mentioned of a "step-by-step" add-on of some sort. Perhaps the README.txt could evolve into this. Of course we than have the problem of getting developers to actually use it. Hmm, I just had a frightening thought: if we do things like this, some of us are going to make less money from supporting those inexperienced people... Forget everything! Let's make it even harder to figure out how to maintain Drupal. Nancy E. Wichmann, PMP
participants (16)
-
Bill Fitzgerald -
catch -
Chris Johnson -
David Metzler -
Earl Miles -
Earnie Boyd -
Florian Loretan -
Gerhard Killesreiter -
Greg Holsclaw -
Jason Flatt -
Jeff Eaton -
Michael Favia -
Morbus Iff -
Nancy Wichmann -
Victor Kane -
Zohar Stolar