Enhance hook_settings - add an optional 'advanced' tab

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?

+ 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.

-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.

+1 on the feature.

I have argued countless times for an "advanced" section for infrequently used and powerful options.

I think this has nothing to do with failure of UI design. It is providing power for those who need it, while keeping the interface uncluttered and not confusing for the rest.

moshe, please don't misrepresent us (or at least me :-) ) as claiming that all Drupal Devs don't care about usability. I'm actually pleasantly surprised at how much brain-time is given to usability issues by the Drupal community, particularly for an open source project. Of course, there's still plenty of room for improvement, which I doubt anyone disputes, and we don't want to lose ground on that front, either.

Part of my issue with "Advanced" is that it has no clear meaning. As you point out, many programs have "advanced" control panels or tabs or pages or whatnot. But what qualifies as "advanced"? In some programs it means "something that the great unwashed masses won't understand, but is still very useful". Example: Firefox, where half of anything useful is under Advanced. In others, it means "Don't touch this unless you know what you're doing, because you could break your computer and start a thermonuclear war if you mess up." That's especially the case with programs that use video codec libraries that have a zillion configuration options that I couldn't even begin to comprehend.

So if we offer Drupal module developers an easy way to dump stuff into "advanced", what does "advanced" mean? Does it mean "put stuff here that only uid 1 will care about"? Does it mean "put stuff here that only a Drupal developer should be touching"? Does it mean "put stuff here that may confuse dumb users but is good for normal people"? It's inherently ambiguous, and simply putting a recommended usage guideline on the site somewhere is not going to help.

What will then happen is "advanced" will have at best a translation of "uh, fancy stuff", which from a usability perspective is terrible. That's badness. The term itself is just completely unclear and undescriptive. That's what I mean when I say it becomes a dumping ground for stuff the developer doesn't want to categorize.

Incidentally, I feel the same way about "administer", which is equally unclear as to what actual abilities it gives you. The system should be built in such a way as to make the path of least resistance for developers one that is naturally clear and explicit. An "advanced" tab encourages poor organization.

Options that fall into the "set this wrong and you could break the system" category should be very explicitly marked as such. "Advanced" does not mark them as such. Making those be only config-file-accessible is one option, but that can quickly devolve into a windows registry or Firefox's about:config and related messes if we're not very careful. It's a better design, both usability- and security-wise, to not make it possible to break the system in the first place. :-) config-file-only settings should be confined to core alone, not modules or even core modules.

As I said, if the problem is that we need better or more fine-grained organization of configuration options then allowing an arbitrary number of settings local tasks is better than adding just a single ambiguous extra tab.

- it is familar. anything else we come up with will likely be less familiar

It's familiar but undefined. What "advanced" means varies with the program. It's a bad design in other programs and it's a bad design in Drupal.

- People already react in the right way when they see it. Experts proceed and newbies don't

Which is itself part of the problem. That creates a "cool people" and "second class citizens" split with no clear continuous learning curve between them. That's bad. Most people are in between "expert" and "novice", and we should allow for that. A "cool people only" tab is not a good way to handle that.

Also, I've requested that reviewers propose solutions along with any negative review.

A reviewer can say that an idea is bad without offering a counter-proposal if he believes the problem being solved is not one that needs solving. You're presupposing that the everyone agrees on the problem to be solved, just not the exact method. That's not the case.

And I did make a counter-proposal: Allow finer-grained organization of options with an arbitrary number of settings tabs, modeled on the hook_block() API. If there's enough options that fieldset is no longer sufficient to organize them properly, then use semantically useful tabs to group them. "Advanced" is not a semantically useful term.

I never meant to imply that we have lazy UI designers. Nor lazy developers. Sorry for the misinterpretation, caused by me.

Crells last post explains much better what I tried to say.

And I very much disagree with your point that one should not thumb something down unless it comes with a good alternative. That is silly. Often things are no good solutions. Often the current state is better then a proposed alternative. Often an alternative needs to grow in a discussion. So sorry, but I will continue to thumb down ideas I strongly disagree with, even If at that very moment I see no clear alternative yet.

A last I would like to comment on the quotes like "But FireFox has it too". IMO that is either just poor UI design (in teh case of FF) or leftovers from days where Usabilty was not as advanced or even ignored (outlook).

I will try to explain it again what we should do *instead*: Look for better, existing, or even physical lines, and split up the UI by these lines. again: *Advancedness* is not an existing line. While there are real lines, that we can use to split up the interface. Functionality, category, Role, module, actions, goals are a few.

With an example with Advanced tab:
I want to set up clean urls and .htaccess has a problem:
Admin >> common settings >> advanced > ".htaccess has a problem find out more here". After solving ,htaccess:
Admin >> common settings >> advanced > use clean urls.

with a better devision:
Admin >> url settings > ".htaccess has a problem find out more here". After solving ,htaccess:
Admin >> url settings > use clean urls.

Now, be fair, and think wich of above examples makes most sense? An advanced tab containing a random selection of settings, or a dedicated page containing all our URL settings? This is an example based on a split in "category, but as stated aboe there are much more options for plsitting, such as action based:
Install >> I want to optimise my site for search engines > clean urls

All these options are IMO better then using the old fashioned and non existing "advanced" vs "simple".

Ber,

Please do not get offended with what I am going to say, I say it with all due respect. This is not directed at you, but at the "no more options" way of thinking camp in general.

I have noticed that every time this topic comes up, we have the same argument that leads to nowhere.

Person X wants feature A (e.g. filtering of statistics, turn off printer friendly on book pages, and about a million others, ...etc.). This conflicts with how things are today, or with what person Y wants.

An option is proposed so feature A can be turned on or off at the discretion of the site's owner.

Immediatley, the "more options are bad" party jumps and says that this is a) poor UI design, b) is more clutter, c) is confusing, ...etc.

We propose to have the option in an obscure place, but then that is shot down too ...

The result is that Drupal becomes rigid and does things only in a certain way, in the name of UI finesse.

We have to be more practical and less rigid in this, and evaluate every case on its own merit, not on pre-conceived theoretical philosophies.

I am not against options. I am not offended, And I am not against more features,
I prefer KDE for the very fact it offers me more options/freedom then Gnome. I despise OSX on that level, that it does not really allow me to have things my way, I hate the absolute scattererdness of wondows. The way every app does things completely different.

I love Drupal for the fact it allows me to some level to make it my own (the developer platform thing). I love the way Drupal is on its way to become a well integrated unity.

What I _am_ "ranting" against is that open Source problem of fixing issues Ad-Hoc. Fixing issues on a standalone basis. Fixing issues when they arise and start itching, and then only scratch the itch itself, rather then looking if one might be allergic or have a skin desease that causes the itch.
That way we end up with a (nuke, anyone) huge chunk of bolted-and-welded-together frankenstein. Where every page looks and feels different, where no-one really feels confortable upgrading, and where users are only complaining about the learning curve. Dries does a wonderfull job in trying to keep all this together.

Solutions, in core, IMO need to go much deeper then an itch that needs scratching now, REally, I beleive Drupal is quite a mess in configuration stuff now, (compared to closed source apps/cmses i have seen). I will "fight" against any change that will make this worse, no matter if that makes me look "offended". No matter if that is the less-worst-solution ATM. I would really debate anything that will scatter our current scattered interfaces even more.
And in the end I am only a voice, that can be easily ignored, and has really nothing to say, of any weight. In the end they are how I would like things to be.

Ber

No more hook_settings().