UI-oriented summary of D7 Field API

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

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 ?

Introduction

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.
OTOH,
- 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.

Current UI screenshots: Access field UI pages,
- for nodes (+ links on node type overview)
- for taxonomy terms (not integrated to the 'vocabularies overview' page yet)

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

Widgets, formatters

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.

Settings

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.

Note:
"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

TODO
- 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 ?

Module-defined fields

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.

Form_builder

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.

Comments

There are some interesting

KarenS's picture

There are some interesting ideas at http://realize.be/pimping-cck-display-fields-ui that incorporate some of what we need, like assigning fields to regions per context.

Very interesting

ha5bro's picture

I like it, it's great to extend the Drupal region's into the node.

I hope we'll still have the ability to manually create templates though :)

Jim

Cross reference to

KarenS's picture

Cross reference to http://drupal.org/node/367498, which explains a concept of re-usable displays.

Cross reference to

KarenS's picture

Cross reference to http://drupal.org/node/472126, the new re-worked node form for D7 which will have a right sidebar and 'meta' area, so we will have at least three regions 'main', 'sidebar', and 'meta', with weights within each of these regions.

Cross reference to

KarenS's picture

Cross reference to http://drupal.org/node/404818 which is where the port of Formbuilder to D7 is going on.

I spent some time today with the D6 version of formbuilder and CCK to see if I could see good ways to incorporate it. As yched notes above, my question is whether it can handle the quirky needs of our UI given that the processing is backwards to the process we will need for fields (i.e. Formbuilder: pick any widget and drag it onto a form, then choose what type of field it is from whatever fields support that kind of widget; CCK: pick any type of field and drag it into the node, then choose from the widgets that field supports what type of widget it will use. Once you've made the first decision, you can change only to another type of widget supported by that field.)

We will also clearly need to separate the 'form' context (where Formbuilder may work fine) from 'node', 'teaser', 'rss', and other displays that need weights but don't use forms. And some fields have no form element at all, but still need to be displayed. Not sure yet how well this will work.

Lets meet!

Bojhan's picture

Hey,

I am really glad that yched picked this up, and I would like to respond to all questions - as KarenS it might work but not for all. So instead of going into a LONG talk about all the display and more complicated issues regarding this. Let me try to keep it short.

@yched Oke, let me try to prove you wrong - trying to reflect on all your questions. So my role is only giving an Usability Expert view on this, I am not sure on the technical implications.

  • Fields are much more then widgets, yes this is a large issue - I am almost about to say it could be solved by the tabs, just how we pull in advanced settings now (not sure though). Basically saying, yes - we know their is a large amount of stuff that doesn't map to the current idea - how high is the use case for that? So lets hide it in the well designed! tab.
  • I don't think scanning this, is bad usability. It might become a large list, yes - but you can see what you see on your form. Therefore it maps closer to the representation. (I see your efficiency point, yes this is more enjoyable but not necessarily more effective - http://www.welie.com/thoughts/?p=9 which talks about it a bit)
  • Manipulate different object - Yes. It's the other way.
  • Also: Yes, not sure how we can ever build an interface to map something that is done programmatically in that way - probably we can only mention what the programmatically action just did.

The box

So when you click edit in form builder, I believe this box should be context driven. So a download field would be designed differently then a text field, might sound complex - but means we don't have to worry about changing field values not being task driven - but system driven.

Mental Model

So last year I was working on an application which had a similar problem like this. From the usability testing we did back then, was it hard for people to understand abstract concept such as data objects (fields in this case) - but rather preferred the closer actual representation of the content (and edit it there) - which I was told is not possible. So we chose the middleground.

Form builder is facing this same problem. The CCK UI is the abstract data objects, while we thinkg that a user would want to edit is at the 'node' itself.

My take on this is. Yes Form builder doesn't map to the representation, but it goes on the layer in between - which is still fairly close to the mental model.

Obviously I shouldn't just make assumptions so I just asked three users who don't know the abstract field concept the following things:

So there knowledge was that you can stuff (Developed by : Konami - was one guys example) to your content type(node). So I asked where they would go design the contents of this page, so to add like Developed by : EA. One of them answerd "I would like to just add this on my editing page - because I am making something more". The other answered (I think he is more knowledgeable about fields) "I would like to edit or add options like "class teacher" on where I can change the title and stuff".

The last one, answered "I would like to change this on my page, just like clicking and removing stuff from the page"

So even though this is very in-the-wild questioning. I think I can understand that people do actually think about adding it to the form - because its something more (so you can't do that on the content page).

After that I showed them the Form builder, beyond the "cool" - they understood you could build your content type by dragging things in and, allows easy editing of the ones there are. So I mentioned to one, what about adding something you don't want to display but do want to give with the content type for system like stuff (he just said, to want to put it somewhere in a not display thing).

Conclusions

I don't think my in-the-wild questioning sets any direction, but it does explain the concept of users thinking about adding something more - is on the adding page. So wanting to add more "options" , they need to go where you can usually add the other things like title and body (technical the node/add/something).

I don't feel that "Formbuilder is totally mapping to a users mental model on how to build up these pages, but it does give them a lot of scent as to what they are working."

So on the premise it maps closer to the mental model, than the current proposals I would say lets explore the edge cases and use cases.

I think KarenS is definitly on a right track that the way form builder is designed, is to handle forms not to handle the node/teaser/rss (is display the right word here?) type things. I feel that this should live somewhere else, say for example Manage Fields on /admin? Since is it a 80% thing?

Would really love to get together sometime (on skype?) and just discuss this, as groups or issues doesn't live to these type of in depth discussions. I am open to all alternatives and complications and changing anything of this concept, but consider the drag and drop and editing of fields in your form, a step in the right direction.

Thanks for stepping in

yched's picture

Thanks for stepping in Bojhan. Sorry, little time to reply for now.
I'll try to hang out on #drupal-usability tomorrow see if I can catch you.

Usability

Group organizers

Group categories

UX topics

Group notifications

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