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.