Use Webform's UI for field addition

I finally gave this a shot, and I must say I'm pretty happy with the results.
Attached patch still needs minimal polishing (thus still CNW), but works pretty well.

This lets admins :
- add a new field
- add (share) an existing field
- add a new group
- directly drag-n-drop them to the right place
straight from the 'Manage fields' screen.
List of widgets is JS-updated when selecting a field type for 'add new field'.
Label and list of widgets are JS-updated when selecting a field for 'add existing field'
(simple update, no AHAH - probably not needed).

See attached screenshots if you want to see what it looks like without applying the patch.

PS : obvious downside of this new approach wrt the existing 'add field' form is that we don't have much room to put help text ('#description'). This could probably be made better.
Obvious upside is that no-one should have to witness a new user desperately searching the UI for a way to add a new field ever again ;-)

I've polished this a little more and will post a new patch very soon. Glad to see there's interest :-)

Karen and I were rather thinking we released ASAP (it can be a matter of days now) and kept this and the 'combo field' work for 2.1.
This patch involves some string changes (not *that* much), and in #278827: String freeze / translation updates before final release we committed to not release less than 2 weeks after the last string change, so committing this means pushing the release by at least another 2 weeks.

OTOH, I was willing to try and release during Szeged :-), but we found out we had to roll a new D5 release first and this got delayed.
So now that Szeged is over, maybe another 2 or 3 week delay is not that dramatic after all...

I'll detail the TODOs on this patch when I update it, we can discuss then...

Updated patch. Everything works OK AFAICT, but testers are welcome to push it to its limits.
Comments in a followup post.

So, there are some points open for discussion :

- Do we want this to deprecate the old 'Add field' / 'Add group' primary tabs ?
I'd say yes ultimately, but probably depends on the points below...

- Help text :
This new way to add fields and groups is much faster when you know what you're doing, but leaves little space for the help text we had in the previous 'Add Field' multistep forms (See screenshot for a comparison).
Current patch puts minimal help text, putting more quickly clutters the UI IMO.
Best thing IMO would be to remove '#description' texts completely, and start integrating with advanced_help.module.to defer beginner's help to a separate popup, ideally with screenshots and all. This help page is still to be written, though; takers welcome :-)

- Field creation workflow :
The main difference with this new approach is that you create your fields and groups without ever seeing the 'configure' form and all the options for the fields.
Once the field is created, it's up to you to find it's 'configure' link in the updated list of fields and click it.
Redirecting to the configure page after form submission is tricky because with this patch you can add two fields (one new, one existing) and one group in one single form submission...

My suggestions, from easiest to most complex :
1) display the link to the settings page in the creation status message : 'Field foo was created. You can now [configure it]'.
2) redirect to settings page if only one item was created (most common case)
3) find a way to cycle through all settings pages for the newly created items, sort of like Views2 does when adding several filters in one go.

[edit : forgot the screenshot]

And :

- given the points above, do we want this in 6.x-2.0 release, or do we wait until 2.1 ?

Karen :
Actually not going through the settings form is only problematic for new fields :
A new group works out of the box using default styling (which is just what 98% people want) even if you don't go through its settings form (I just fixed something in current CCK D6 about that, minor fix to be reported in this patch as well).
A new shared field instance is created by duplicating a previous instance, so its settings are valid straight ahead.

So maybe an easy solution simply is :
4) only redirect to the field settings page if a new field has been created

@ff1 : A Views2-like UI would sure be beneficial for many parts in CCK. This might not happen before a while, though, and definitely not before the first D6 release.

@Moshe & Karen :
I'd say polishing this (redirects, removing the deprecated 'add new' form, testing testing testing, writing advanced_help page(s ?), including some time for translators) will push the release for something like another 3-4 weeks. Shipping with this would definitely make the d.o announcement sexier, but right now I'd tend to think releasing sooner is what the community expects...

I gave this a push. Here's an updated patch :
- handles redirection to field settings form :
When inside a 'create new' sequence, the 'change basic settings' fieldset and menu elements like primary and secondary tabs are removed, to limit the temptations for the user to break away.
When a new group is created, I chose not to redirect to its settings form. Can be changed if we want, but for 95% use cases people leave the default settings so I think this is a win.
- removes the previous 'Add [field|group]' primary tabs
- themes the 'Manage field' and 'Display field' tabs using templates (theme function was beginning to get unreadable)
- includes fairly extensive simpletests for the new UI
- includes a 1st batch of 'advanced help' pages

The advanced help pages could use a proof-read to fix possible typos.

Now, about when to commit this / when to release :
Because of the recent API changes in Views, we can't make our final release before Views-rc2 ships.
That should happen soon, but it's not there for now.

I gave this new UI quite extensive testing, and IMO this is ready. Committing this now would require a 10 days padding time to fine-tune / debug.
IMO this is worthwhile for such a UI win.

The amount of string changes in this patch is actually fairly minimal - aside of course the new 'advanced help' pages.
But releasing with untranslated 'advanced help' is not that bad IMO.
AFAICT, hass is the only translator that's still in the game, so we probably shouldn't bother about other languages too much.

So my proposal, if Karen is OK, would be to roll an RC7 asap, commit this patch, and roll a final release in 10 days if Views RC2 is ready by then.

CVS doesn't handle binary files in patches, so here's a zip of the images in cck/help/

And here's a drop-in replacement, fully patched cck folder for easier testing.

Yay then. RC7 rolled - I'll let a few hours go by before committing this to -dev, just in case the RC7 has blatant failures (I've been caught screwing releases recently...)

Short update : I just added another thing in my (uncommitted) code : do not automatically generate names for fieldgroups. We had a TODO in the code about that, and now seems a good opportunity. Simply adds a new 'group name' form input on the 'add new group' row of the 'Manage fields' tab.

Now that we are more confident about the stability of RC7 and Views compatibility issues have eased a little, I committed this.

The help files could still use a quick reread to fix typos and such - any taker ?

Advanced help files are translatable. Translations are searched in /translations/help, so people can commit them freely just like .po files.

Only downside is that, yes, it's out of .pot, so keeping track of changes in the original help files is more complicated - it requires a file diff of the current state of help files against the state that was last translated. I think a 'translation workflow' discussion in advanced_help issue queue might be a good idea.

This doesn't make the advanced_help feature less precious IMO, and as I said, if the help pages are not translated when we ship, it's still better than no help pages at all.

Due to what merlinofchaos explains, Views currently does "(?) Label", so we'll stay consistent with that.

And I would also add some space between "add" and the above field list table or move it over in a new table below the above table on "admin/content/node-type/cck-test1/fields" + make the "add" bold like above titles to separate.
The styling is there. You should clear your browsers cache.

BUG: "New foo" fields shouldn't be draggable... or you will have other bugs... do it.. move "create fields" to the right, below the "new group" and press "save". You get the errors:
Not a bug : if you try to nest fields below the 'new group' but don't provide the info to actually create the group, it's a mistake.

OK for the 'display fields' tab bug when there's no field - I thought I checked that, but this needs fixing.
Since this has been committed, subsequent bugs if any should get their own threads.

Fixed the issue about 'Display fields' tab when there are no fields.

hass : seeing your screenshots, you *need* to refresh your CSS cache, you do not get the new styles for this page.

Fixed the issue about 'Display fields' tab when there are no fields.
This involved a string change, BTW.