Here's a small one-line usability fix for all module developers that I think will be a huge help to users.

In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same:

  1. copy to /sites/all/modules
  2. enable at /admin/build/modules
  3. configure all exposed settings
  4. use!

However, sometimes just finding the settings page takes the longest time out of all those steps. Is it in User Management? Content Management? Logs? Who knows!

I'm going to use the example of the Bio module; not picking on the Lullabot team or Bio module maintainers, this one just happened to be the first example I thought of. :)

Bio's settings page is difficult to find, as it's not in "Site configuration" but rather in "User management". It also hides itself quite nicely using the title "User biographies" instead of "Bio settings", as one would expect. The readme.txt file doesn't mention how to find the settings page at all.

So what I had to do in this case, after becoming frustrated with searching for the settings in the menu, was pull up the source code and check out hook_menu() to see exactly where I should go.

And here's my suggestion: we're all used to seeing the "installation successful" messages (and looking out for php errors on install of course). For example, the Bio module has these:

enable-module-messages.png

What if this message held the link for the settings page? Then it's just one click away, instead of a potential 2 minute search to find it.

enable-bio-better-message.png

This is just one line of code in the bio_install() function:

drupal_set_message(t('You can edit Bio settings at ') . l('admin/user/bio','admin/user/bio'));

Seems like a small change, but if every module did this, it would collectively save me hours in the module evaluation stages of a project, because I find that plenty of modules seem to hide their settings and not explicitly detail them in readme.txt, requiring me to either hunt them down or open the source.

Since I talked about the Bio module, I've provided a patch in the issue queue. Hate to be a complainer that does nothing about it... :)

http://drupal.org/node/236187

... little thing, but these

... little thing, but these little things make people happy ;)

You're right, that's one of the most annoying things in Drupal administration.

Of course, what if there is more than one module enabled?

If you enable a module - thats fine. If you enable multiple modules, each of which require configuration then you will be provided with a bullet point list of pages to go to. Maybe the links could open in new windows?!

There is also hook_requirements which a developer can use to test that configuration has been complete and if not, flag a drupal_set_message error up on the screen...

Tabs!

@Nicholas_Thompson: that's what tabbed browsing is for. Middle-click every link in the list, and they're all there ready for you.

target=blank

You could always just create the link to automatically create a new tab/page using target="_blank"

It's generally considered

It's generally considered against usability to force a link to open a new page or tab. What if the user wanted it to be opened in the same window?

The general rule is "don't break the back button." Forcing a new window or tab breaks a user's ability to use the back and forward option of the browser.

Great idea!

I'm going to adopt this in my own module development.

Definitely best practice

I try to do this with my modules (and link to block configuration for modules that create blocks).

Everyone also remember to use the /admin/by-module page when having trouble finding settings after enabling a module, and if that doesn't work see if it has added anything to content types or taxonomy or anywhere else that might possibly make sense... and that you are a user with permissions to the module you just enabled! Ah, Drupal usability.

(My suggestion for the last is to at least have an administrator role to which modules could give sensible permissions to by default.)

benjamin, Agaric Design Collective

There's an issue filed

There's an issue filed against core to help all contrib module maintainers in their quest to make modules more admin friendly. Check it out at http://drupal.org/node/230059

hook_menu() to the rescue

When I can't find the settings for a module, I just open the .module file (or sometimes the .admin.inc file) and look at hook_menu(). That way, you'll find it within 5 seconds max.

Although this of course is *really* bad usability!

This is just a thought: what about installation wizards for modules? Some really complex ones (at least for novice users) could definitely use that.

Smart idea

As is always the case with smart ideas someone thought of this before: http://drupal.org/node/198919

One message

In order to keep it all in one message, you could shorten the phrase to "The Bio configuration options have been saved", using "Bio configuration options" as a link to admin/user/bio.

So this idea has been picked

So this idea has been picked up in a slightly different form on the developer list and there's an issue open for Drupal 7: http://drupal.org/node/245417

Part way there in D7

To my surprise, Dries committed this patch to D7 (it could do with some honing really) http://drupal.org/node/192962#comment-690961. This means for any active module you get a link (on the main modules admin page) to the module's help page (if there is one), which also automatically provides links to the modules various admin pages. Except that in certain situations you may not get links to all the admin pages IIRC.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.

More information about formatting options