Settings for content types: per type or big list?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
joachim's picture

Admin UI question to ponder:

Suppose a module adds a property or setting to content types: it allows you to say "content types X, Y, Z have property foo, or can do a particular thing, or do a thing in this particular way".

When should this be a UI element added to the content type admin page, and when should this be a single list of all content types?

A run-down of examples:
Added to the content type admin page: upload, comment, nodeblock, community_tags, meta tags, nodewords, content_profile
List of types: taxonomy, flag, simplenews

Comments

I think module configuration

delf's picture

I think module configuration page should have default settings with checkboxes to apply global settings to. Each node type on other hand should have it's own settings.

similar question

greggles's picture

I've wondered about this myself because Pathauto puts them into one big list. On the development mailing list in early 2008 there was a discussion that said we should do it in both places (ugh).

Let's see if we can get a best practice on this.

--
http://growingventuresolutions.com | http://drupaldashboard.com | http://drupal.org/books

both places: generic solution

donquixote's picture

we should do it in both places (ugh)

I would like to see a generic solution for that.

Example:

1) I want to do some modifications to the webform content type. One of these modifications is to disable comments.
Solution: admin/build/content > Content types > Webform
as we know it.

3) I want to disable comments for all my "static page" content types: page, webform (contrib), frontpage (custom), panel page (contrib).
Solution: admin/build/content > Content types settings > Comments.
I get an editable list of all content types and their associated comment settings.

If some of the elements don't fit in a table row, we could show a sub-form for the active row: either in a popup, or on the right or below the list.
Nothing happens on server side until you click "Save" at the bottom of the list.
Rows with modifications get an icon or a special color. Especially if the change is hidden in a sub-form.

pathauto

donquixote's picture

Those modules that don't want to add clutter to the content type configuration form, it would still be a good idea to put a link in that form.

Edit content type "webform".
[...]
more settings (expand/collapse)
link: pathauto settings

going both ways is not generic

luco's picture

it's actually a usability principle. if you can offer more than one way to accomplish a given task, and it won't hurt your production, then why not?

on the other hand, it might not stick with module contributors who usually develop on tight budgets and schedules for their own projects and release for the community in exchange for as much as a paypal link and a happy issue queue.

don't get me wrong - I'm not badmouthing or anything, it's just a real-world view. there's only so many rules and regulations they're willing to follow without sticking to what would seem as a guideline.

For drupal I think if

gagarine's picture

For drupal I think if something it's for a content type it would be in the content type admin directly on node type settings or create a new tab.

Keep interface simple and give one way by interface. It's hard to understand and document if the same action can be done by two forms.

I don't like documentation like "You can go by this way or this way or this way....".

Example: copy. You can only make copy past with the shortcut CMD and C with the keyboard. They are an other way... by menu or drag and drop with mouse but because is NOT the same interface. Who thinks it's nice idea to add a new shortcut or two different menu in a usability mind?

Sure vim have different shortcut and for good reason and it's really more productive but it's not easy to learn because you need learn a knew things.

For productivity, we can create a module than get all settings form of each node type and make one page by settings instead by node type.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: