This Wiki page summarizes the UI needs for the D7 Field API, to get the ball rolling on design discussions.
Discussion currently takes place in the comments here - or is there any other place more in line with D7UX habits ?
A good UI for D7 Field API remains to be invented - esp. when considering a couple new features compared to CCK D6.
To be extra clear: I personally (yched) will not have the time to lead a Field UI brainstorm and the ensuing implementation work, but I do have a couple ideas / intuitions, and will happily participate and feedback if such a community effort happens.
I also did not closely follow the ongoing D7UX work, and might easily miss some UI concepts raising there which could reformulate Field UI issues.
Bojhan and yoroy have expressed their intention to bump this during the forthcoming UX sprint, which is IMO the best thing that can happen :-)
Core or contrib ?
From back in DC Barcelona (sep 07), the 'Fields in Core' roadmap was "API first, UI can remain in contrib for a release cycle" - main reason was to reduce the amount of code to make 'core worthy'. Another good reason is: UI in core means it's frozen until D8.
- the ultimate goal is still to have the UI in core at some point - earlier is better, of course
- it is now obvious that the Field API will remain under-used (and thus under-tested and fine-tuned) unless it ships with a native UI in core. The UI itself will get more eyes in core.
- the D7UX movement is a great opportunity to try to get this right.
The design and coding work done with core in mind will be profitable anyway.
CCK HEAD (tarball, or from CVS HEAD) currently provides a "working" Field UI.
- 'direct' port of the CCK D6 UI - general agreement is that D7 should aim at much better.
- some features are not addressed (formatter settings, storage indexes, per-context order and grouping)
- the organization of subforms for field settings is sub-optimal
- generally still rough on the edges
Participants are nonetheless highly encouraged to install and play with it, to see where we start from.
A couple screenshots are included in the various sections below.
So, here we go:
Fieldable entities, bundles ("= node types") and pre-existing UI
Fields are not tied to just nodes: taxonomy terms, users, other contrib stuff that core doesn't even know about (fictional, possibly irrelevant examples: webforms, panels...).
Each fieldable entity choses what are its 'bundles', i.e what defines which set of fields a given object has: node type for nodes, vocabulary for terms... If it helps taking the leap from CCK D6, think 'node type' whenever you read 'bundle' below.
Each fieldable entity will have its own UI for managing those bundles: create/edit node types, create/edit vocabularies... Field UI has no control on this.
-> Requirement: the Field UI will need to tie itself easily to any existing UI for core or contrib entity types and their bundles (and/or define a set of reasonable UI patterns that fieldable entities need to follow). But: even though "create a node type or a vocabulary" and "set up its fields" are different UIs handled by different modules, users will most likely see this as part of the same "task", so we might need to think of ways to make this the most fluent we can.
Fields, field instances
Field API internally deals with two separate structures:
field: roughly, the definition of a storage 'bucket' (think: a set of columns in a db table)
field instance: the attachment of a given field to a bundle ('node type').
Example: all node types have an instance of the same 'body' field.
This is what lets Views or custom code query a given field across node types: "Select all 'Person' and 'Business' nodes where 'City' is 'Paris'."
Current UI merges the two notions - can be debated, but is OK IMO.
"add new field to a bundle" = create field + create instance,
"add existing field to a bundle (shared fields)" = create instance.
"remove field from a bundle" = delete instance, delete field no more instances
The UI has no way to create a field with no actual instances.
Current UI screenshots:
- 'Manage fields' tab: add fields to a bundle, reorder them, change their settings, remove them
- Overview of existing fields at admin/build/fields (not tied to any bundle admin page) - with links to the 'Manage fields' page for each bundle
Pluggable handlers that define how fields appear in edit forms (widgets) and in displayed objects (formatters).
Available widgets and formatters depend on the field type. Contrib modules can add new widgets and formatters for existing field types.
Here's a list of what users can set up in a field:
- field properties: things that will be the same in every bundle where the field appears.
- type (text, number, image...), name, cardinality (single value, multiple values), db columns to index
- settings specific to the field type: maximum length of text fields, precision of decimal fields...
Most of those settings directly impact the storage thus and cannot be changed after creation.
- instance properties: can be different in each bundle where the field appears.
- weight (order) label, description, required, default value
- settings specific to the field type: min and max value for number fields, formatted text / plain text...
- widget used in forms, with settings specific to the widget type: number of rows in textarea...
- display settings: for each display context ('build mode', see below)
- label display options : above the value, inline with the value, hidden.
- formatter used to display the values: link to img, imagecache derivative... - or 'hidden'
with settings specific to the formatter (new in D7, not handled in current UI): number of decimals, imagecache preset, autostart for media player...
-> UI workflow dependencies, some of which are challenging:
- pick a field type -> pick a widget, pick formatters
- pick a widget -> define the widget settings; change widget -> the settings form changes
- pick a formatter -> define the formatter settings; change formatter -> the settings form changes
This requires forms to be split into independent subforms (or intelligent AHAH form update, which might be tricky).
IMO, only Views or Panels UI and their AHAH subforms/modals made good UI translations of those patterns so far. Heavy supporting code.
The ongoing work on 'Harmonicas' might be precious here.
Current UI screenshots:
Field settings subforms. Probably not the best we can imagine.
Build modes and display settings:
Build modes are the contexts in which the objects can be displayed (for nodes: full node, teaser, rss, search index, search result...)
Each build mode has its own set of fields visibility and display settings.
Each fieldable type declares what build modes it uses - extensible by contrib modules according to their own features: Print.module adds 'print' mode for nodes; an easy module would provide a UI to let admins define custom build modes, and thus define 'display styles' (fields display settings + matching .tpl's and CSS), to be easily reused in several places (Views, custom code...).
-> Requirement: the UI needs to scale for 10+ build modes for an entity type.
(sounds like a use case for vertical tabs ?)
Maybe a good use of vertical tabs might allow us to merge both 'Manage fields' and 'Display fields' screens to a single page.
"fine tune formatter settings for 'rss' mode" could be argued to be an 'advanced' task
but "define which fields are visible in teasers" is a pretty basic task.
Current UI screenshots:
'Display fields' tab: define fields display settings for the various build modes (note: forget the 'Exclude' column, it's on the way out). Currently does not provide access to formatter settings.
Ideally: field order per context
One order for forms, a different order for node pages, yet another one for teasers...
Would also be cool for fieldgroups: different groupings on forms, full nodes, teasers...
Not done yet in code (easy), but more complex as a UI.
Problem: Combine this with "10+ build modes" and it easily turns in config hell:
"How many things do I need to configure just because I added a new field, or enabled a module that silently adds a new build mode ?"
I proposed a possible approach in http://drupal.org/node/367498#comment-1232096, but it could very well be far-fetched or ill-designed.
Fieldgroups / combofield
- different notions of 'grouping' in D7: (HTML) fieldsets, sets of vertical tabs, D7UX's 'meta' section
- how can different 'grouping' notions be plugged from contrib ?
How does Field UI treat module-defined fields ?
Current scenario: all instance settings (order, label, widget, display) can be changed by admins in the UI.
Field / instance deletion: A module defining fields and instances might break if they get deleted.
-> Field UI should forbid the removal of module-defined fields and instances.
But : an admin can add a new instance of a module-defined field. It should then be able to remove that instance.
Quicksketch's Form_builder is a spectacular piece of work in itself. I'm personally not sure it can be the basis of a Field UI - but would be happily proven wrong.
- Fields are much more than widgets, as the list in the 'settings' section above clearly shows. How can form_builder account for field settings, instance settings, display settings ?
- Usability: do we want to be working on a (massive) 'form edit' form whenever we're adjusting field properties ? For day-to-day work, the CCK D6 'manage fields' tab is IMO much more usable.
- Manipulate different object:
Form_builder: "pick a widget and fine-tune its settings". Field API: "pick a field type first, available widgets (+ other things) ensue".
Seamlessly tying those reversed API logics could be tricky.
More conceptually, what is the user's mental target when he defines or adjusts fields ?
I'd personally tend to think "a list of information bits" more than "an input form".
Input forms are merely a way to fill in actual data on your site. But you target your data and how you want them displayed to your users, more than the input form seen by content authors.
Different use case than webform.module, in which you actually design a form.
Also: content (nodes or other fieldable content) can be created programmatically, imported, aggregated... For those cases (which will only get more frequent IMO), primarily designing an input form is counter-pariuri-intuitive.