[drupal-devel] [feature] Enhance hook_settings - add an optional 'advanced' tab

Sun Sep 11 16:33:39 UTC 2005

Issue status update for 
http://drupal.org/node/30515
Post a follow up: 
http://drupal.org/project/comments/add/30515

 Project:      Drupal
 Version:      cvs
 Component:    system.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  moshe weitzman
 Reported by:  moshe weitzman
 Updated by:   Bèr Kessels
 Status:       patch (code needs review)

-1 for the concept.
"Advanced" settings are bad UI. It is not up to us to decide what is
"advanced" and what not. You also simpley split them up on an imaginary
and non-existing border. Tehre is no difference between advanced and
simple, so making usch a border is bad. 

On top of that, "advaced" allows lazy UI design. "I would like to have
a better look over how to render these options, and I still need to
write better descriptions" vs "hmm, dunno what to do with them yet,
lets stick em in advanced". That off course is over siplified, but I
hope it exlpains the problem. 

Please, please, do not introduce "advanced" tabs or areas. No modern
environments (desktops, apps etc) have this, for the reason that
"advanced" is a non-existing group. (well except FF, but it is a much
debated issue, and is considered one of teh top UI mistakes in FF).

If this does not convince you people, I will try to find some good
online resources, for II only know this from what I read in usability
books. 

Also, when discussing usability issues please just post a screenshot
with the patch, or even jsut a mockup before a patch. Usability is
*not* about code, thus a patch is not a good method of communication. A
mockup also saves a lot of time when developing issues.

And last, this, in fact is a duplicate of: http://drupal.org/node/30843
one of these two should be marked as dup.

Bèr Kessels

Previous comments:
------------------------------------------------------------------------

Tue, 06 Sep 2005 16:05:53 +0000 : moshe weitzman

Attachment: http://drupal.org/files/issues/hook_settings.patch (25.19 KB)

This patch opens the door for advanced preferences in Drupal. If you
have sufficient permissions, you will see an *advanced* tab on settings
pages when a module chooses to put stuff there. The permission is global
across all Drupal - 'access advanced functionality'.

This patch enhances hook_settings so that it accepts a $type parameter.
By default, $type='simple' and everything works as today. If modules
return HTML when $type=advanced, a new tab appears on the settings
page. To see this in action, visit admin/settings/aggregator applying
the patch and after giving yourself the permission above. The patch
appears long only because of whitespace changes. It is a minor change
to all hook_settings() implementations.

This 'advanced tab' paradigm can be used outside hook_settings as well.
Just protect your tab/feature with the permission above. 

Contrib modules will continue to work without patching but will show an
duplicate tab called 'advanced'. To fix, just add an if($type ==
'simple') block in hook_settings(). I will add upgrading instructions
to drupal.org and update hook_settings() docs if this is committed. 

I feel that this is a good balance between those who repeatedly yell
for 'fewer settings' and those who want their site to work a specific
way but are uneager to hack the source code. This 'advanced settings'
paradigm has worked well for Mozilla project (about:config) and many
others. If these advanced features clutter and bother you, don't enable
this permission or don't click on the advanced tab. There is no way that
Drupal becomes a cluttering steaming pile of configuration options - our
culture precludes this. Lighten up, and give the people what they want.
We can't expect everyone to hack the source to get commonly requested
behavior.

I also simplified upload config by renaming upload_admin() to
upload_settings() and removing an unneeded menu entry.

------------------------------------------------------------------------

Sun, 11 Sep 2005 05:28:51 +0000 : moshe weitzman

i'd like to hear some comments from CVS review team on this. If not
desired, alternatives are appreciated.

------------------------------------------------------------------------

Sun, 11 Sep 2005 06:10:03 +0000 : Crell

This was discussed recently on the -devel mailing list, and for reasons
discussed there I have to -1 this in concept.  An "Advanced" tab means
the UI designer failed to properly design the UI to discourage the user
from doing stupid things.  That's not something we should encourage.

If there are too many configuration options in some module for them to
be just shown linearly (I don't actually know many modules with that
problem), that's what <fieldset> is for.  

If some module has enough options that even <fieldset> isn't enough,
then rather than hard-coding an "advanced" tab we should allow
arbitrary module-developer-defined tabs that all get the extra magic of
the settings page.  The $delta methodology of hook_block() would be a
good model to follow here.

If you just want to split some options off as "Danger, Will Robinson!",
frankly I can't think of any good examples.  Perhaps you could offer
some?

------------------------------------------------------------------------

Sun, 11 Sep 2005 14:16:23 +0000 : Jose A Reyero

+ 1 for the concept

I think we are always trying to find what is an imposible balance
between ease of use  (less settings) and options/flexibility (more
settings), so having simple and advanced settings would be a good
thing.

However, about the implementation, I wouldn't like having an 'advanced'
tab, so from an advanced administrator's point of view you would have to
guess which settings are in 'simple' and which ones are 'advanced' to
find them.

I'd rather have a single page having all settings -that would be more
if you have that advanced permission. So you can just return all simple
settings as deffault, and then a few more if the parameter is
'advanced', and then we'd need to rewrite that settings hook only when
additional advanced settings are provided.