reverse selection of node types is clumsy
Two modules I've used recently require you to make "reverse selections" of node types. They ask "select node types *not* to use" or similar. I find three issues here: 1) I have to reverse my thinking in order to make the correct selection. It takes longer. 2) I have lots of node types in my system and I normally only want to select one or a few of them in any given case. The selection is *much* bigger inversed. 3) When adding a new CCK type, it is not included in this reversed list - enabling the new type by default! It's easy to forget to disable this until someone discovers the bug of a content type where it does not belong. Cheers, --fletch
I think the reasoning is based on implicitly allowing new node types. -----Original Message----- From: "Dave Fletcher" <fletch@splendora.com> Date: Fri, 7 Mar 2008 11:41:00 To:development@drupal.org Subject: [development] reverse selection of node types is clumsy Two modules I've used recently require you to make "reverse selections" of node types. They ask "select node types *not* to use" or similar. I find three issues here: 1) I have to reverse my thinking in order to make the correct selection. It takes longer. 2) I have lots of node types in my system and I normally only want to select one or a few of them in any given case. The selection is *much* bigger inversed. 3) When adding a new CCK type, it is not included in this reversed list - enabling the new type by default! It's easy to forget to disable this until someone discovers the bug of a content type where it does not belong. Cheers, --fletch
On 3/7/08, David Strauss <david@fourkitchens.com> wrote:
I think the reasoning is based on implicitly allowing new node types.
This is completely wrong to me. It assumes the module author knows what I want to do with the node type. I have to strongly disagree, #3 on my list is my primary complaint. I realize not everyone is a developer and may not use the node abstraction for as many subsystems as I do, but for me, this is a royal pain. Cheers, --fletch
Quoting Dave Fletcher <fletch@splendora.com>:
On 3/7/08, David Strauss <david@fourkitchens.com> wrote:
I think the reasoning is based on implicitly allowing new node types.
This is completely wrong to me. It assumes the module author knows what I want to do with the node type.
I have to strongly disagree, #3 on my list is my primary complaint. I realize not everyone is a developer and may not use the node abstraction for as many subsystems as I do, but for me, this is a royal pain.
May I suggest a module (a name of node_type_defaults would be good) that creates a hook_node_type implementation for the 'insert' operation that sets the desired defaults? The weight of the module needs set high so that it is last in the list. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Got eamples of specific modules that do this? Dave Fletcher wrote:
Two modules I've used recently require you to make "reverse selections" of node types. They ask "select node types *not* to use" or similar. I find three issues here:
1) I have to reverse my thinking in order to make the correct selection. It takes longer.
2) I have lots of node types in my system and I normally only want to select one or a few of them in any given case. The selection is *much* bigger inversed.
3) When adding a new CCK type, it is not included in this reversed list - enabling the new type by default! It's easy to forget to disable this until someone discovers the bug of a content type where it does not belong.
Cheers,
--fletch
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On 3/7/08, Sean Robertson <seanr@ngpsoftware.com> wrote:
Got eamples of specific modules that do this?
Well, I didn't want to name names ;-) But since you asked, the two that are the focus of my complaint are OG and notifications. Cheers, --fletch
Ha, I just spent 30 minutes trying to debug a problem caused by this very problem in OG. Kyle On Fri, Mar 7, 2008 at 2:08 PM, Dave Fletcher <fletch@splendora.com> wrote:
On 3/7/08, Sean Robertson <seanr@ngpsoftware.com> wrote:
Got eamples of specific modules that do this?
Well, I didn't want to name names ;-) But since you asked, the two that are the focus of my complaint are OG and notifications.
Cheers,
--fletch
-- Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog
Why not an admin setting? (and why not take this to a feature request on the respective issue queues) http://drupal.org/node/add/project-issue/og http://drupal.org/node/add/project-issue/notifications
Well, I didn't want to name names ;-) But since you asked, the two that are the focus of my complaint are OG and notifications.
On 3/7/08, catch <catch56@googlemail.com> wrote:
Why not an admin setting? (and why not take this to a feature request on the respective issue queues)
Yes an admin setting sounds great. The reason I brought it here and not the issue queues is to make module devs aware that this setup is not ideal for some users. Cheers, --fletch
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Fletcher schrieb:
On 3/7/08, catch <catch56@googlemail.com> wrote:
Why not an admin setting? (and why not take this to a feature request on the respective issue queues)
Yes an admin setting sounds great.
IMO it doesn't. The usability people (do they exist now?) should come up with a set of do's and don'ts WRT such things and we should ask module developers to abide by it. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH0dtEfg6TFvELooQRAobNAJ451BrFpUPsK/VZgikCZ57Ab7ogNQCgsx2w ajgyfL+3DcM8kIrF4PrW7j8= =cXHZ -----END PGP SIGNATURE-----
Ideally, we should have a node type selection API that allows you to select some setting for each node type and a default for new types. -----Original Message----- From: Gerhard Killesreiter <gerhard@killesreiter.de> Date: Sat, 08 Mar 2008 01:18:13 To:development@drupal.org Subject: Re: [development] reverse selection of node types is clumsy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Fletcher schrieb:
On 3/7/08, catch <catch56@googlemail.com> wrote:
Why not an admin setting? (and why not take this to a feature request on the respective issue queues)
Yes an admin setting sounds great.
IMO it doesn't. The usability people (do they exist now?) should come up with a set of do's and don'ts WRT such things and we should ask module developers to abide by it. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH0dtEfg6TFvELooQRAobNAJ451BrFpUPsK/VZgikCZ57Ab7ogNQCgsx2w ajgyfL+3DcM8kIrF4PrW7j8= =cXHZ -----END PGP SIGNATURE-----
IMO it's an interesting solution to have a widget for the purpose, though I'm not aware of other similar pre-fab widgets in Drupal. Thinking about this, yeah an admin setting seems wrong. If you want your module to automatically enable something for new node types, I'd suggest altering the node type form and put a default-on checkbox. That way, at least the feature can be disabled immediately after creating the type, and users don't have to hunt down the setting. Cheers, --fletch
On Friday 07 March 2008, Dave Fletcher wrote:
IMO it's an interesting solution to have a widget for the purpose, though I'm not aware of other similar pre-fab widgets in Drupal.
Thinking about this, yeah an admin setting seems wrong.
If you want your module to automatically enable something for new node types, I'd suggest altering the node type form and put a default-on checkbox. That way, at least the feature can be disabled immediately after creating the type, and users don't have to hunt down the setting.
Cheers,
--fletch
Great. Then your module has the same problem as comment module, where I have to go disable comments on every frickin' node type except for "forum" just because my client decided they wanted forums at the last minute. Inverted options are a PITA, even when spread out to separate node type forms. -- 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 3/8/08, Larry Garfield <larry@garfieldtech.com> wrote:
Great. Then your module has the same problem as comment module, where I have to go disable comments on every frickin' node type except for "forum" just because my client decided they wanted forums at the last minute.
Inverted options are a PITA, even when spread out to separate node type forms.
Yes I completely agree that enabling certain things by default is bad mojo. My points were that a) this is what some core modules do for a solution already, and b) at least they're all in the same place. Abolishing inverse selections altogether is preferable, but not very enforcible in third party modules. A style guide that strongly recommends against the practice would be idea. I'm not volunteering though, got way to much on my plate already :-) Cheers, --fletch
On Mar 8, 2008, at 10:32 AM, Dave Fletcher wrote:
Abolishing inverse selections altogether is preferable, but not very enforcible in third party modules.
<advocate class="devil"> Consider the case of OG, where you're using it to restrict access to data on your site. It's a pain (and potential security problem) in the other direction, if you have to remember to privacy-enable all new content types as you add them, instead of having everything private by default until you exclude it from the privacy system. </advocate> Granted, this is a somewhat obscure case, and it's probably best to optimize the UI for the common case. But, this is probably what Moshe was thinking when he set it up like this in the first place. Food for thought... -Derek (dww)
OK to clarify what I meant for an admin option - every node type is "opt in" when you install a module. But there's a check box that says "enable x automatically for new node types when created". Then we have the same UI pattern, but if there are security/privacy issues with a node_access module. That means no reversal of logic, just one additional checkbox per form. I'd really like to see this standardised across both core and contrib - at the moment you can't even tell in advance if a setting will be in a content type fieldset or on the module's own admin page (for example taxonomy vocabulary vs. comments).
On Saturday 08 March 2008, Derek Wright wrote:
On Mar 8, 2008, at 10:32 AM, Dave Fletcher wrote:
Abolishing inverse selections altogether is preferable, but not very enforcible in third party modules.
<advocate class="devil">
Consider the case of OG, where you're using it to restrict access to data on your site. It's a pain (and potential security problem) in the other direction, if you have to remember to privacy-enable all new content types as you add them, instead of having everything private by default until you exclude it from the privacy system.
</advocate>
Granted, this is a somewhat obscure case, and it's probably best to optimize the UI for the common case. But, this is probably what Moshe was thinking when he set it up like this in the first place. Food for thought...
-Derek (dww)
That's true if you want to build an entirely-OG site. If you want to OG-enable just part of your site, for selected node types, then it becomes a liability, not a feature. I can't speak for Moshe or what was going through his head when, but I'd love to see OG's permission interface be opt-in. I've watched new colleagues of mine get confused by it on their first OG project, as it is essentially a double-negative. (Not to pick on OG here; it's just OG and Comment are the two most obvious examples I know of.) -- 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 Mar 8, 2008, at 12:15 PM, Larry Garfield wrote:
That's true if you want to build an entirely-OG site. If you want to OG-enable just part of your site, for selected node types, then it becomes a liability, not a feature.
Agreed. That's exactly what I meant here: On Mar 8, 2008, at 10:41 AM, Derek Wright wrote:
Granted, this is a somewhat obscure case, and it's probably best to optimize the UI for the common case.
I'm just wanted to point out a use-case that's related but hadn't been mentioned in the thread yet, so that as people are brainstorming about possible changes, we have all the different cases in mind and at least have an answer (if not a solution) for each of them. The answer to this use-case might have to be "sorry, that's an edge case, and we're going to optimize for the common case", which is a totally legitimate answer. I only wanted to make sure it was on the table for consideration, that's all. Cheers, -Derek (dww)
A huge +1 on that idea! David Strauss wrote:
Ideally, we should have a node type selection API that allows you to select some setting for each node type and a default for new types.
-----Original Message----- From: Gerhard Killesreiter <gerhard@killesreiter.de>
Date: Sat, 08 Mar 2008 01:18:13 To:development@drupal.org Subject: Re: [development] reverse selection of node types is clumsy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dave Fletcher schrieb:
On 3/7/08, catch <catch56@googlemail.com> wrote:
Why not an admin setting? (and why not take this to a feature request on the respective issue queues)
http://drupal.org/node/add/project-issue/og
http://drupal.org/node/add/project-issue/notifications Yes an admin setting sounds great.
IMO it doesn't. The usability people (do they exist now?) should come up with a set of do's and don'ts WRT such things and we should ask module developers to abide by it.
Cheers, Gerhard
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH0dtEfg6TFvELooQRAobNAJ451BrFpUPsK/VZgikCZ57Ab7ogNQCgsx2w ajgyfL+3DcM8kIrF4PrW7j8= =cXHZ -----END PGP SIGNATURE-----
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
participants (9)
-
catch -
Dave Fletcher -
David Strauss -
Derek Wright -
Earnie Boyd -
Gerhard Killesreiter -
Kyle Mathews -
Larry Garfield -
Sean Robertson