Show help and configuration links when modules are enabled.

I've always wanted something like this.

Even if your module doesn't have need of a hook_install function, it's nice to display a note confirming that the module is installed and ready for action. The hook_install function belongs in your module's .install file.

/**
* Implementation of hook_install().
*/
function mymodule_install() {
  drupal_set_message(st("YourModule settings are available under !link",
    array( '!link' => l('Administer > Site configuration > Your Module ',  'admin/settings/yourmodule/settings' ) )
  ));
}

Looks good to me. I'm not a big fan of putting things between round brackets. I'd rather see it flow like natural text. For example by writing: "See [instructions] for how to configure this module."

We discussed something like this with the usability team but that's a lot , lot bigger. What I would like to see is a reasonable implementation of yoroy's fun swf: provide a block which lists your recent activities and then a More link which goes to a page which lists these activites and consequences. Someone from the usability team even recommended moving the welcome screen to this model which would a) make it unavailable for anonymous users which is good (let's redirect to 'user' instead if there is no content) v) makes sure it's always available and does not go away. It would help the "node orphan problem" a bit, too. Some code is at http://drupalbin.com/8490 . Oh and we totally should split up the admin/by-modules into per modules screen and the very title of the activity could link there while consequences would come from the _install

By the way, we have a hook_modules_installed(), hook_modules_enabled(), hook_modules_disabled(). That would probably be most appropriate for this code.

After discussion with beeradb I now call the consequences available tasks. We still need More link, the page listing activities/available tasks, split up the admin/by-modules page and link that page as the available task for a module enable. Dont hesitate to work on this patch, just let me know if you do. I now go to sleep, see you guys later.

I did move the welcome patch to the activities screen which is not yet written so after install you get a nice, informative white screen.

another largely untested patch. i moved everything to a new module.

Here is a patch. I bet the testing bot will freak out because of the changed welcome page. I need to add doxygen and tests and I know there is a debate whether this is an optional module or required and I guess if optional then I will need to change the module weight to something big and move the node_save parts to nodeapi. But, for now, here is a patch.

That patch got some backup files in it, removed. Adding a screenshot of a freshly installed Drupal. Do we want to move the Recent Activities block up?

I think if we do this, it should replace a lot of drupal_set_message() calls - i.e. if you create nodes, terms etc. - that'll go in your activity log instead of a dsm() - this will make drupal_set_message() used more for actual messages. If the messages are annoying, then they get moved simply to admin/reports/admin_activity. With that in mind I'm leaning towards it being a required module rather than optional - and make the exposure to the UI via a block and/or the theme layer optional.

As a replacement for the welcome screen - it'd allow profiles, and modules installed as part of profiles, to add to that screen, which is a very handy thing indeed, removes the magical disappearance of that message, and taking people to an admin page to welcome them to their newly installed site would help with initial orientation I think - if I need to know what to do next, or forgot a step enabling a module admin/reports/admin_activity provides a one-stop place to get a reminder.

As long as we are talking about "guiding" site administrators to potential places, we should call this "Admin guide" or similar.

Displaying a log of recent changes and/or recently visited pages where a change was made quite overlaps with http://drupal.org/project/journal

Journal is a team helping and si form based instead of a code base, uid bound guidance system, i do not feel a lot of overlap. Also, I am perfectly aware that this guidance system is practically a log of what we need to work on usability wise, but then again, this is here and UX iwll always be a problem... so I think a crutch is good and we can throw away the crutches on the pieces where a smooth gliding car is built.

Quick discussion in IRC revealed that there is no overlap with Journal module, because this thingy just displays hard-coded events and based on those events, a guide to point administrative users to relevant pages.

Thus, the proposal was to rename to "admin_guide". The block title, menu item, and page title may still be called "Recent activity". Not sure about the page title though, because the page is rather about pointing to further resources based on recent events.

That said, I wondered whether anyone thought about using triggers/actions for this. After all, we're talking about events, and this thingy would introduce a parallel event system. What if I want to send an e-mail whenever a module is installed? ;)

So having spoken with chx about this a bit on IRC, I would like to give some feedback on how viable this is for a administrator spectrum. This patch does one great thing it learns other developers that there are "next steps" in ones process of doing something in Drupal, a certain workflow that we need to look far more closley at (forcing them to think about this, might force them into fixing their UI)

Complex, not simple
I think it should be a guidance for hard and complex problems, we are unable to solve in the interface (for now) - this means that rather simple tasks such as installing modules and installing drupal should not be handled by this module as the way is portrait but rather when you setup something that conflicts or when you forgot to do something crucial after a specific period (UX things we can't solve right now)

The idea of a log is always something more for expert users, as Windows might be able to tell us (purely in placement - and mass of information). So this will not solve any usability issues, unless its part of the users "moment" - something people like to call contextual help. If you can provide some screenshots of that happening, I could probably easier evaluate where we could apply this and if it's needed at all.

Drupal 7
The Admin activity log page, to me almost looks like a "things you can/should do" page. Pretty interesting from a exploratory perspective but I don't think anyone would use this page, you're building your website towards a certain goal - anything that gets in the way or is far away from your working space is annoying - in this case that is /admin and then just the modules your working with.

Obviously this functionality does not have enough weight, to be made a default block. Let's keep that experience as clean as possible, so people can just muddle around - before we tell them what they did (they know that already!), or can do.

So I think looking at Drupal 7, we don't need this - its a quick fix to a larger problem, where as the quick fix might not even be seen by anyone or able to process the complexer usability issues - we want to solve like this. So shift focus towards difficult problems and issues, not the install modules/install Drupal ones, those really can't be solved by a log.

I feel bad saying "no" to which is conceptually a good move, to start thinking about - but truthfully I don't think it will be used as we envision it here.

Ok then let's revert to JacobSingh's idea mixed with a small piece of mine: let's split up the by-module admin screen by modules and link there once you enable a module.

Hum. I have to disagree (although not having participated in this usability discussion). Users of my modules are steadily creating support request issues that just ask for clarification on this question.

Currently, the usual practice is to add the clarification to the README.txt (that no one reads), or display an annoying message (that vanishes) after doing something. That's unacceptable. This patch surely is a step in the right direction. Also, it is something that only Drupal core can provide, because a contrib module would be too "weak" (unknown) to introduce this paradigm.

Instead of ditching this approach, I'd like to advance on it:

Build a registry of events and actions

Some (if not most) of the potential actions are the same for each certain activity.

You created a content-type? Then you want to ensure that you grant proper permissions for it.

Add flexibility

Allow modules to extend the potential actions for a certain activity. Add weights to actions.

You created a text format? Then you want to
1) Add filters
2) Configure filters [weight]
3) Optionally associate a client-side editor to it. [contrib]

Remove "admin_" prefix

The entire functionality depends on user permissions, not whether someone is called "admin". Custom modules could provide custom actions to guide their regular users through a process. Think of a online shop or any Drupal site that implements a complex process.

Integrate with new help system

Potential actions should be able to reference (link to) a certain help topics. The text of the action itself links to the relevant page. But next to each action, one or more help links may appear.

Add dependencies for each action

Allow actions to be dependent on other actions in the same context. Display them as disabled (greyed out), informing the user that a certain other action has to come first. Think of the Drupal installer, which is more or less the same:

"Welcome to Drupal. [You copied Drupal files.]" (Activity) =>
1) "Setup database" (action)
2) "Configure profile" (action)
3) etc.

If this was in core, I could start tinkering about how admin_menu could expose those activities and actions in a way that does not interfere with the site's design and provide fast access to the resources.

OK so to clarify what I wanted to do here: a very simple system (there is very little that's not coded, a checkbox or a link to allow dismissing activities you are done with, adding module enable to the log and the split by-module page) which guides the users. It is not intended to solve usability concerns it is intended to make a small progress. Again, if a usability problem becomes a nonproblem, we simply remove the guidance-add from the code. Remember: "Small moves".

I think this would be a nice step forward - there is no good system now to indicate to users (admins) what to do once a module is enabled. It's not a compete solution, and hopefully we will also have a better help system in the end which might make this less relevant, but let's stop sacrificing doable improvements in the name of perfection.

Larger proposals for an "Admin activity log" should go elsewhere - let's focus this issue on something small and simple along the lines of the original proposal.

Split the wider discussion to #411414: Module enabling / task workflow design

Jacob, I still think we should think split up the by-modules page and link there. Thanks for your work here.

I think this is still relevant, particularly because of #1168082: Module configuration links are easily missed after a module install. (That issue describes the problem, and this issue represents one of the possible solutions.)

Therefore, reopening for now.

This issue is old and its purpose has been shifted from the original report and back to it. I think it'd be better if we kept this closed and followed on #1168082: Module configuration links are easily missed after a module install or #1851128: Leave the details of just-enabled modules expanded in modules UI.

For the record: I like where this issue was going up to #5 and then from #26 onwards again.

Closed #1168082: Module configuration links are easily missed after a module install as a duplicate.