Re: [drupal-devel] advanced theme in core vs all in core.
Actually.. having many many many settings configurable via the interface leads to clutter, which is a usability no-no.
This all depends on the presentation of your options. If this is organized properly, this usability no-no can be virtually anulled. Clutter is a usability non-no, sure, but if you organize it properly, even a lot of options can be presented without clutter. If you ask me, Drupal needs an "advanced" mode, where all these "extra" features can be put for users who want then, and hidden for those who don't... Regards, Kobus
If you ask me, Drupal needs an "advanced" mode, where all these "extra" features can be put for users who want then, and hidden for those who don't...
I came up with this idea some time ago to get over the impasse of "more options is confusing" vs. "we need an option for X". I am + 1 for an advanced settings tab for these less used options.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06 Sep 2005, at 4:05 PM, Khalid B wrote:
I am + 1 for an advanced settings tab for these less used options.
The form API could theoretically be used to add an interface_level property to each element, and just not show elements the user might be confused by. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDHbSagegMqdGlkasRAqo+AJ9w9yfgnuBTm+3JuhdiBPSmHm1ikACgulW8 vueJLPT9kpAhI39x9KSx1iQ= =f2NY -----END PGP SIGNATURE-----
What about a /admin/advanced which is a single page, listing ALL variables, similar to about:config in moz/ff. Op dinsdag 06 september 2005 17:24, schreef Adrian Rossouw:
On 06 Sep 2005, at 4:05 PM, Khalid B wrote:
I am + 1 for an advanced settings tab for these less used options.
The form API could theoretically be used to add an interface_level property to each element, and just not show elements the user might be confused by. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 06/09/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
What about a /admin/advanced which is a single page, listing ALL variables, similar to about:config in moz/ff.
You may want to look at the WordPress "All Options" screen. Here's a screenshot from 1.5.2: http://static.flickr.com/24/40885069_6892f7e99f_o.png To make this, their options table has the following fields: option_id, blog_id, option_name, option_can_override, option_type, option_value, option_width, option_height, option_description, option_admin_level, autoload. -- David Carrington
The problem with a "list all variables" page is that it's VERY easy to get lazy about settings after that, and you end up with all of the useful or cool stuff there and only there, with no decent inline documentation. It becomes the Windows Registry very very quickly. :-) An admin/advanced page, if we include one, should still be a well-built and well-documented page, just listing less-used stuff. Developers shouldn't have an "easy way out" of just throwing something into the advanced screen and forgetting about it. On Tuesday 06 September 2005 11:24 am, Bèr Kessels wrote:
What about a /admin/advanced which is a single page, listing ALL variables, similar to about:config in moz/ff.
Op dinsdag 06 september 2005 17:24, schreef Adrian Rossouw:
On 06 Sep 2005, at 4:05 PM, Khalid B wrote:
I am + 1 for an advanced settings tab for these less used options.
The form API could theoretically be used to add an interface_level property to each element, and just not show elements the user might be confused by.
Regards, Bèr
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op dinsdag 06 september 2005 20:37, schreef Larry Garfield:
An admin/advanced page, if we include one, should still be a well-built and well-documented page, just listing less-used stuff. Developers shouldn't have an "easy way out" of just throwing something into the advanced screen and forgetting about it.
True IMO that page should only be a summary of already defined variables. So, in contrary to windows registry or (shivver) gnome-conf, this should (IMO) only list the variables that are settable in other places too. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Tuesday 06 September 2005 03:14 pm, Bèr Kessels wrote:
Op dinsdag 06 september 2005 20:37, schreef Larry Garfield:
An admin/advanced page, if we include one, should still be a well-built and well-documented page, just listing less-used stuff. Developers shouldn't have an "easy way out" of just throwing something into the advanced screen and forgetting about it.
True
IMO that page should only be a summary of already defined variables. So, in contrary to windows registry or (shivver) gnome-conf, this should (IMO) only list the variables that are settable in other places too.
Regards, Bèr
But if they're already listed elsewhere in logical places, why have a "big heat o' variables" too? If they're hard to find in their current location then we need to clean up the current location, not add a bandaid on top of it. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I was thinking in the line of having an admin/settings/modulename/advanced (or admin/settings/advanced/modulename), that displays a tab titled "advanced". Then each module can put whatever exotic options it has, those that are for power users, or less often used, or can be confusing. The same goes for admin/settings/advanced, where Drupal core's own advanced settings can be placed. At the top of these screens we can have a warning that the admin must really know what they are doing before changing any of this. This way, we do not hard code much, provide power for those who need it, and keep it away from sight of the majority who do not need it. P.S. Regarding the "list all variables" page, that would be nice too. But it can grow to be very long, as well as some of these variables may have a lot of info it (e.g. primary links for older themes, mission, ...etc.) On 9/6/05, Larry Garfield <larry@garfieldtech.com> wrote:
On Tuesday 06 September 2005 03:14 pm, Bèr Kessels wrote:
Op dinsdag 06 september 2005 20:37, schreef Larry Garfield:
An admin/advanced page, if we include one, should still be a well-built and well-documented page, just listing less-used stuff. Developers shouldn't have an "easy way out" of just throwing something into the advanced screen and forgetting about it.
True
IMO that page should only be a summary of already defined variables. So, in contrary to windows registry or (shivver) gnome-conf, this should (IMO) only list the variables that are settable in other places too.
Regards, Bèr
But if they're already listed elsewhere in logical places, why have a "big heat o' variables" too? If they're hard to find in their current location then we need to clean up the current location, not add a bandaid on top of it.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Tuesday 06 September 2005 08:17 pm, Khalid B wrote:
I was thinking in the line of having an admin/settings/modulename/advanced (or admin/settings/advanced/modulename), that displays a tab titled "advanced".
Then each module can put whatever exotic options it has, those that are for power users, or less often used, or can be confusing.
The same goes for admin/settings/advanced, where Drupal core's own advanced settings can be placed.
At the top of these screens we can have a warning that the admin must really know what they are doing before changing any of this.
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?" :-) Personally I see "advanced" tabs and forms as a sign of failure on the part of the UI designer to properly organize and design the interface in the first place. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
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.
Personally I see "advanced" tabs and forms as a sign of failure on the part of the UI designer to properly organize and design the interface in the first place.
This is an example of how new features/options get shot down: clutter. It is sort of a Godwin law like thing on this list (just kidding, but there are similarities).
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. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
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 ]
On Wednesday 07 September 2005 02:07 am, Bèr Kessels wrote:
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.
Precisely what I've been saying. :-) The solution to the "don't add more configuration options because it's confusing" problem isn't to create a "mere users don't use this" section, it's to allow module designers more power in organizing options in proper ways. (And to not be so paranoid about additional configuration options.) For most modules, I suspect that proper use of fieldsets is perfectly adequate. For very large or very customizable modules, having the ability to add additional settings tabs with meaningful names is a much better solution than an arbitrary "advanced" tab. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Tue, Sep 06, 2005 at 10:05:55AM -0400, Khalid B wrote:
If you ask me, Drupal needs an "advanced" mode, where all these "extra" features can be put for users who want then, and hidden for those who don't...
I came up with this idea some time ago to get over the impasse of "more options is confusing" vs. "we need an option for X".
I am + 1 for an advanced settings tab for these less used options.
+1 for more settings -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
participants (7)
-
Adrian Rossouw -
Bèr Kessels -
David Carrington -
Khalid B -
Kobus Myburgh -
Larry Garfield -
piotrwww＠krukowiecki.net