[drupal-devel] two minor usability issues, introduced recently

[Richard Archer]

At 11:02 PM +0200 26/9/05, Dries Buytaert wrote:

>> This is perhaps a terminology issue and one that has confused the
>> heck out of me. On several occasions while I've been learning Drupal
>> I have enabled the aggregator module in order to activate an RSS feed
>> of MY news. When what I really needed to do was turn on the RSS block.
>
>This issue is new to me; I don't know about other people being
>confused about this.  Interesting nonetheless. Maybe the module
>description (shown on the 'administer > modules' page) needs to be
>improved upon.  Feel free to make concrete suggestions (or better
>yet, a patch against Drupal CVS).  You know better than anyone else
>what could have avoided the confusion.

If there had been an item which mentioned RSS or syndication in the
administer menu I would have clicked on that instead of looking
around for a module to enable RSS feeds.

Concrete suggestion:
Create a administer > syndicate menu item which contains
the RSS Settings content from the current global settings page.
Add some help text to this page informing the user that they need
to enable the Syndicate block to publish a link to their feed.

Attached is a first cut of a patch that does this.


>> Out of interest, why is it that module settings show up under the
>> Settings admin menu option and not in a pane within the module's
>> own menu option?
>
>It's a hard problem, but one we have to solve.  I think we all agree
>that the current situation is a bit of a mess.  An important part of
>the problem boils down to the question: "What exactly makes a
>setting?".  For example, adding profile fields is an uncommon yet
>reasonably complex task.  Is it a setting or not?  Does it belong under:
>
>   1. administer > settings
>   2. adminster > profiles
>   3. administer > users > profiles
>   4. <something else>
>
>I believe Kieran's usability study will help us reorganize the
>administration section, however, maybe not at this level of detail.
>We'd have to ask Kieran.
>
>What would be really useful for us, is for you to compile a list of
>situations where you expectation did not match the actual location of
>a setting/task/function.  If we had a dozen such lists from different
>people, we might see a pattern or two.

My goal at present with Drupal is to set up a very simple Drupal
installation which I can hand over to non-technical people to manage.
So I have disabled as many modules as I can but I'll offer some
feedback on the modules I have used.

contact.module
I expect to go to administer > contact form and have all the
configuration options for the contact module available with an
extra "settings" tab for the options currently found on the page:
administer > settings > contact form.

users.module
Once again, I expect to go to administer > users and have all the
configuration options for users available with a settings tab
containing the options from current administer > settings > users.

aggregator.module
Same again. I would expect to find the content from
administer > settings > aggregator in a settings tab on the page
administer > aggregator

I have attached patches for these three modules so you can try
this system out and see how it handles. Patches are against HEAD.


I also noticed that comment.module is structured in this way already.
You go to administer > comments and you have list and configure tabs.
This could just as easily be set up with the "new comments" and
"approval queue" as the tabs and the contents of the configure tab
on an administer > settings > comments page.


As for profiles... that's a tricky one. I think I would have it as
administer > profiles for a couple of reasons.

1. It's a module which can be disabled and enabled. And from a
usability standpoint it would be best to have a new admin menu appear
once the module has been enabled so the user knows where to go to
configure the module.

2. I notice that the profile module does not adhere to the Drupal
user interface "standard"  of having a "list", "add category" and
"add field" tabs. Instead it has the clunky "add new field" section.
And once the user is in there they need to key in the name of the
category... I hope they remembered it! This needs to be refactored.

3. This module is crying out for some reporting to be added and if
that gets done it makes more sense to have an administer > profiles
section which contains the settings and reporting rather than have
it all hiding in a tab on the administer > users page or a settings
page.

 ...Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modules.refactored_settings.patch.gz
Type: application/octet-stream
Size: 2808 bytes
Desc: not available
Url : http://drupal3.drupal.org/pipermail/development/attachments/20050927/b9ed4214/modules.refactored_settings.patch.obj