Redesign content type editing (after CCK UI is in)

This looks great, the content type edit form with or without CCK UI is offensive, this would help a lot.

So my first concerns, I agree with the problems btw. Is that we are pulling fields into content types interface, although this makes sense - it will be very hard to pursue - in terms of scale, keeping it usable. The other seem hard to just grasp.

Thanks for getting the ball rolling, kika.

First of all, discussion on Field UI already started at http://groups.drupal.org/node/23545, and I'd like very much if we kept the strictly-"Field UI" bits it in one place, or this won't be manageable.

Then, a bit like Bojhan, I agree on the 'problems' - this is spot on about the kind of challenges Field UI raises -, but not so much with the 'solutions' ;-)

- Big +1 on making 'non-fields' (e.g node title) configurable in the 'Manage fields' table. I am convinced that the 'Field UI' can be the central hub for a large part of the 'node features' (and more generally 'fieldable objects' features), even those that are not actual 'fields' (not yet, for some of them).
The 'explanation or submission guidelines' could be one of those 'pseudo fields' too. Same goes for 'display post information' on the display-side (except it could be per build mode and *configurable* !)
Note that you *can* (even in CCK D6) reorder 'non-fields'. In fact, core drag-n-drop wouldn't work well if "some" rows were reorderable and others not.

- The single "dropdown select + 'add' button" for both 'add new field' and 'add existing field' needs its own discussion. It's really not that simple, and there are good reasons why CCK D6 presents this the way it does (screenshot). Short version: settings dependency: you cannot pick field settings until you picked a field type, you cannot pick widgets settings until you pick a widget, so it's mainly a way to limit the number of forms you need to go through when creating a field.

- Big big -1 on 'field overview in a collapsible fieldset in the edit node type'. Like Bohjan, I don't think this will work at all, for many reasons:
Too many important things here; the list can grow pretty big; I don't want to have to scroll one whole page to access this and scroll all the way down to submit. Usability nightmare IMO.

- Really not sure about "When editing / When viewing" tabs. First it breaks the general pattern that primary tabs should be 'actions' (verbs) - ok, so does 'Manage fields' (verb + noun), but to a lesser extent.
More importantly, there are bound to be 'exceptions', things that fit in neither 'view' or 'edit' easily. You already point 'name', 'machine name', 'description', there's also 'comment settings'; I'm sure there would be others for vocabs, comments...

- Which leads me to:
I *think* we might be able to merge 'Manage Fields' and 'Display Fields' in one screen, with a clever use of vertical tabs.
But I'm pretty much convinced this screen needs to be it's own page / primary tab.
This can then be more easily reproduced on all fieldable objects. Bear in mind that contrib objects can be fieldable too. Thus, Field UI is pull, not push: it doesn't "know" about 'content type UI', 'vocabs UI', 'comments UI' or 'contrib_foobar UI', and cannot make special cases. It's fieldable objects that say "here's the page to attach the Field UI for this object type".

Clarification on "teaser" / "summary" / "trimmed text" : actually those are 3 different things in D7.

- "Teaser" is just a 'build mode', i.e. a way to display a node: which fields are visible, with which display settings...
'teaser' is the build mode used for nodes displayed on the front page and on taxonomy listings.
- "summary" is an optional, user-entered, 'alternate version' (usually shorter) of a text field.
- "trimmed text" is an automatically shortened version of a text field, typically used when no explicit summary is available.

The three notions relate this way: The 'body' field is configured by default to display 'summary if available else trimmed version' in 'teaser' build mode.

#504564: Make summary length behave with fields (could use some help with functional reviews) should alleviate the confusion you point out, by moving 'length of trimmed post' out of the 'edit content type' form into a display setting for the body field (and more generally for any text field). This is the logical followup to 'body as field'; 'length of trimmed post' makes no sense as a content type property anymore.
Same argument goes for "Minimum number of words", BTW, but there's no patch for that yet.

(...) the trickiest one: introduce generic UI pattern for field management on all fieldable enitities. (btw, where that latter discussion should happen? http://groups.drupal.org/node/23545 ? A new issue? Here?)

Well, I'd say the g.d.o post could host this, at least until #516138: Move CCK HEAD in core lands ? g.d.o discussions get less focus that the d.o issue queue, but OTOH that might not be a bad thing for starters :-p

> I am convinced that the 'Field UI' can be the central hub for a large part of the 'node features'
> (and more generally 'fieldable objects' features), even those that are not actual 'fields' (not yet, for some of them).

> Thus, Field UI is pull, not push: it doesn't "know" about 'content type UI', 'vocabs UI', 'comments UI' or 'contrib_foobar UI',
> and cannot make special cases.

How these pseudo fields like 'Title' can be added to Field UI when UI does not know nothing about 'content type UI' etc?

This is currently done in a cck / field_ui hook : hook_field_ui_extra_fields(). node_field_ui_extra_fields() declares 'title', 'author' etc as 'extra fields'.
This is in place already, even though it needs a rehaul:
- Make it a field.module hook instead of a field_ui.module hook (we want the informations and user-defined order to be kept when field_ui is disabled)
- Better separate 'form' additions and 'view' additions
- Allow different additions per bundle (content type). Currently it's only by object type (all nodes types have the same extra fields - not true in practice)
- Define a framework for 'settings' forms, used by both fields and 'extra fields'. I think we might see clearer if/when #492834: Hover operations for flooded state screens lands, because I think this UI pattern applies just nicely to Field UI's settings subforms.

> It's fieldable objects that say "here's the page to attach the Field UI for this object type".

But can it can be also "here's the fAPI container in $page structure to attach to the FieldUI" or am I dreaming?

Hm, I guess it could, but making such a complex form into a mere subpart of a larger, unknown form sounds like a promise for FAPI hell, besides being a wrong move usability wise IMO :-)
Also, Field_ui needs to be able to generate links to the 'manage fields' page of a given bundle for a given object type (the page itself or its child subforms for a given field), so it needs to know the actual path anyway. See http://api.drupal.org/api/function/hook_fieldable_info/7 for how it's currently done.

The two patches listed blockers for this issue have been resolved (#372743: Body and teaser as fields has documentation that is still being written).

Since the start of this issue it appears that a lot of user interface quirks listed here have been resolved. Here is a summary of those quirks listed in the first screenshot:

1. Using "0" for the default Minimum number of words is a confusing non-descriptive value
2. In node/add form belongs to a special section "Revision information", not part of the publishing
3. Why are preview post settings different between Comment and Node content types?
4. It is possible to disable the teaser in two places
5. Can we please stop mixing "teaser", "summary", and "trimmed post" and pick one?
6. Body field label editing in two places

It looks like #1, #3, #4, and maybe #5 are resolved. #2 and #5 deserve another look.

I know that the term Content-Type is used in an effort to make things easier for Site Administrators, but giving something more then one name is actually harmful. Pick a term and stick with it; nodes and node-types or content and content-types. under no circumstance should we go on using Posts and Content-Types. I recommend keeping Node. Developers already use this term and if a Site Admin isn't a developer, learning the meaning of the term Node-Type will be as easy as learning the term Content-Type.

#5 - I vote for "teaser", but will happily change my vote to which ever is the majority favorite

I'm not sure whether something is actually left to be done here. The originally posted mockups + annotations are looking awesome, but I think we've made a lot of visual improvements to this interface already, so the notes seem to be mostly obsolete.

why not start by making the entire Field UI that controls 'display' of fields an optional step (set to - by default - inherit the fields manage settings, including order of fields and associated field groups if the module exists)...

then present a simple user option to state clearly, "this is the way a user will see fields when adding content, would you like to change the order of all of this stuff when people are actually looking at it?" (something to that effect, you get my point)

personally, a simple UI for managign conditional fields in core would also address a lot of what feels overwhelming (e.g. if tons of fields about location don't matter unless you know the location, then present a conditional setting to "present checkbox to user: have location info?" and then do or do not show those ten fields, and so on..

there's a ton of work being done around module extensions to clean up clunky content type creation and display workflows, and many seem like features that could work much better in core (conditional fields, field groups, etc)

in one use case that i literally just showed in a demo to a corporate team, i took ALL of the fields on a possible node and put into a giant collapsed field group so that you could only see subject and body and tags - then i said out loud to the people, "and if you have more that you want to add, here's where you go to add detail"

take a cue from the general inter webs: forms are getting shorter, and shorter, and shorter....people have increasingly gotten worse at paying attention to anything. we are a nation of gnats.

I think we did most of this, further improvements require more major overhaul.