UMN Usability - Make add new field form into two step process

I'm not articulating this properly in the room. ;) Let me try with a mockup. ;)

A few notes on webchick's mockup :
- Currently, the field type is choses using radios because it allows us to display some desciption text about the field type. Do we want to lose that by using a select ?

- It's really easier on us if the 2nd step form is *just* the field settings page (i.e the same form you get when you edit the field later on)

- The widget is currently picked on the 1st page so that the 2nd form can present the right widget specific options.
By moving the choice to the second step, the workflow becomes :
> pick a field type, give names, hit 'Next'
> pick a widget, with options form relevant to the *default* widget, hit 'Save'
> reedit the widget to pe presented with the right options for the widget you actually selected
It's a known usability issue of the fields settings page, but at least it currently does't confuse the user when he *creates* a field.
The right fix for this would be to AHAH update the form when a different widget is selected, but it's not done yet :-)

Yes, this would need to come with AHAH stuff in order for the mockup to work as expected for most users.

But a three-step form would be preferable to having the widget and field type selections on the initial page as it is now. I would actually call this a critical bug, and have updated it as such.

One of the participants was trying to add a "Description" field to the workshop they were creating. As a move of desparation, they enabled *all* CCK modules, so when they arrived at this form, were confronted with a huge wall of types and widget choices. They never even saw the field *types* in the list at all. Node reference happened to be listed first, and had an "Autocomplete text" widget choice, so they simply chose that one immediately because they fixated on the word "Text" and it was the first one listed. The page as it stands makes absolutely no sense to people.

Oh, @ - Currently, the field type is choses using radios because it allows us to display some desciption text about the field type. Do we want to lose that by using a select ?

We could do radio buttons instead, I don't really have a preference. I actually totally missed these descriptions on initial read, and don't really find "Store text in the database." a useful description of "Text." For one thing, it uses its name in its definition. ;) However, I can see the need for descriptions on things like node reference, for sure.

Just the main thing is make data type and widget selection two different steps.

It accomplishes the goals at the expense of other goals. We are asking for machine name twice. Asking for widget type twice (once with select list - next time with radios). I think some jquery on the original initial form is whats needed.

I just had the opportunity to try CCK beta today. YOU ARE MY HERO!!! This looks *awesome* now. :D