advanced settings (was Re: [drupal-devel] advanced theme in core vs all in core.)

[Bèr Kessels]

An advanced tab is considered very bad design. 
It allows lazy UI design (hmm where to put that, aah well, Ill stick it in 
advanced untill I have a better idea) but above all: there is no reason to 
have an advanced tab.

If you design your UI in a good way, people need not bother at all about 
"advancedness" of settnigs. For them they are all equal. 

Clean urls: advanced? Probably, yet still everyone wants them. So then you 
must automate some of the checkings (like we do now), to disable it for 
certain situateion. Then add some clear help text and leave it in a nice 
place?. ut certainly not hide it.

Ber


Op woensdag 07 september 2005 04:14, schreef Larry Garfield:
> On Tuesday 06 September 2005 08:45 pm, Khalid B wrote:
> > > Can you provide a few examples of where this would actually make sense?
> > > I'm not coming up with any where the correct answer is "well if you
> > > named it and explained it better on the normal settings page then it
> > > wouldn't be so 'confusing', now would it?" :-)
> >
> > For anyone who have been following development, there are so many
> > times where the discussion goes like this:
> >
> > A: I need a new feature X to be added. Here is the patch.
> > B: The option is fine, but we have to preserve existing behavior.
> > A. Here is a revised patch with an option to turn it on.
> > C. No. More options means confusion and clutter. -1.
> > D. Let us have the option in $conf in settings.php where it is hidden.
> > ....
> > ad nauseum.
> >
> > So, this is my proposal: provide  the option for those who want it and
> > keep it out of site  from the rest.
>
> Well, then the answer is to not have so many people knee-jerk C. :-)  More
> options need not automatically mean more clutter, if organized properly.
>
> A better solution, IMHO, would be to allow mult-tab settings pages.  You
> can already hack this using MENU_LOCAL_TASK, and I have, but having some
> way to get the settings page magic would be nice.  You can already group
> settings to an extent using fieldset, but if you want an extra layer of
> grouping then settings tabs are the way to go.  We'd need a $delta
> parameter added to hook_settings(), and some way to let the the settings
> system know that there are multiple tabs.  hook_block() would be a good
> model to follow, methinks.
>
> That way, the module developer can group lots of options more logically
> than just with fieldsets if they want, including putting "lesser used"
> options onto a further-right tab.  If they want to be lazy and call one of
> them "advanced" we can't stop them, but at least then module devs have the
> opportunity to provide better organization if there are lots of options to
> be had.
>
> (Or we could support Javascript-based tabs, so that they're all technically
> the same form but get hidden/unhidden.  Perhaps that could even be mapped
> to the existing fieldsets.  I've been meaning to figure out how best to do
> that...)
>
> Of course, I'd rather see many of the configuration pages under admin moved
> to be tabs under settings as well, but not all of those are easily
> organized into just setting variables. :-)
Regards,
 Bèr
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]