D8 is a good time to re-evaluate which widgets we want, and with what UX.

Background

Currently we have two widgets:

1) "Single"
Shows the inline form in a fieldset. Assumes a single value required field. No possibility to delete the entity, clone or reference existing entities, only add/edit.

2) "Multiple"
Shows a table with Edit / Delete / Clone buttons.
Below the table has Add and Reference buttons.
(Clone and Reference are disabled by default).

If the field is required and no entities have been added, the add form is automatically opened.

The first attempt to change this is #2134035: Allow to add existing entities using the single value field widget:

In my project requirement, the user should be able to choose if he want to use an existing entity or create a new one.
I -could- use the multi value field and limit it to only 1 value, but this is ugly in user experience perspective:

"You have added 0 out of 1 allowed" is a useless information
The draggable list of values is also useless, we only have one possibility
The user has to click "edit" when he wants to view and edit the fieldvalues of the entity

Now, to be fair, the tabledrag should be removed in case cardinality is 1, there's a patch for that already: #2401171: Turn off table drag when only one value is available. It would also probably be better UX to hide the "You have added 0 out of 1 allowed" message in that case.

Anyway, pfrenssen created a patch that reverts to triggering the "single" behavior implicitly for required single value field.
For non-required single value fields the behavior is the "multiple" one without the annoying tabledrag and message.

The other attempt to change the widget behavior is #1960686: Option to allow editing multiple entities directly (ala Field Collection) which introduces core/field_collection like behavior, basically extending the "single" widget behavior to multivalue fields.

Proposal

I still see two separate use cases, and will need "single but multivalue" behavior for tax rates in Commerce 2.x.

So, I suggest we keep the two widgets. Make "single" support multivalue fields (like #1960686: Option to allow editing multiple entities directly (ala Field Collection) wanted). Improve "multiple" UX like pfrenssen wanted.
Find new names for the widgets, because they are no longer accurate. My only proposal so far is "Simple" and "Complex". Could use a bikeshedding.

Comments

bojanz’s picture

bojanz CreditAttribution: bojanz commented
Issue summary: View changes
slashrsm’s picture

slashrsm CreditAttribution: slashrsm at Examiner.com commented
Issue tags: +Media Initiative, +D8Media

Thank you for starting this conversation Bojan!

At Examiner we already have a use-case which will require #1960686: Option to allow editing multiple entities directly (ala Field Collection) like behaviour. I will check D7 patch and see if it can be ported to D8 easily.

"Simple" and "Complex" seems better naming than what we have at the moment. I don't have any better ideas for now. I'll try to figure some out to be prepared for bikeshedding ;).

One thing that we should think about are assumptions Simple widget has (required, single value, one bundle). People are really confused when they configure their widhet that then simply doesn't appear. We should improve UX there. WidgetInterface::isApplicable() might help but probably won't fix this problem entirely.

I pointed @neardark to this issue.

bojanz’s picture

bojanz CreditAttribution: bojanz commented

One thing that we should think about are assumptions Simple widget has (required, single value, one bundle). People are really confused when they configure their widhet that then simply doesn't appear. We should improve UX there. WidgetInterface::isApplicable() might help but probably won't fix this problem entirely.

The new plan removes the "single value" assumption, but "required" and "one bundle" will stay, can't see a way around that. isApplicable() should be fine, since it will prevent people from activating the widget if it doesn't match their configuration.

slashrsm’s picture

slashrsm CreditAttribution: slashrsm at Examiner.com commented

Ah... so you think we should do #1960686: Option to allow editing multiple entities directly (ala Field Collection) as part of simple widget? Isn't the only difference between simple and complex the fact that one opens all inline forms by default and one doesn't?

bojanz’s picture

bojanz CreditAttribution: bojanz commented

Well, the "simple" one has no concept of open/close, it just embeds the form for each delta. That gives you simplicity, but loses the ability to present alternative forms (clone/reference). There's also no separation between the table and the add form, new deltas are a part of the "table".

pfrenssen’s picture

pfrenssen
Location Sofia
CreditAttribution: pfrenssen for Drupal Association commented

Thanks a lot for opening this discussion. I think renaming the widgets would indeed go a long way to clear up the confusion. My initial idea was to call them "Embedded" and "Flexible" but "Simple" and "Complex" would be fine as well.

I would like to mention that I presented a case in #2491527-12: [Drupal8] IEF FieldWidget merge & refactor to unify the widgets into one single widget, because they function largely in the same way. The "Complex" widget just has some additional steps to guide the user to the right entity reference. These steps are not needed when you only have a single, required, single-bundle reference so we can simplify the UI in that case.

Some objections were raised that changing the way the widget works depending on the way it is configured could be confusing for site builders. I personally think it is intuitive that the UI adapts itself to the configuration in a kind of set-it-and-forget-it way. After all, if the reference is single and required, why should the user first have to click a buttons to add a reference? Why not just embed it?

I guess the best solution would be to use both. If a site builder already knows that the "Simple/Embedded" widget would be suitable, then allow to pick this and set it up quickly. However in the case a site builder would pick the "Complex" one and happens to configure it to be a single, required, single-bundle widget then we can also render it as an embedded widget. In practice we could use the same code to render both widgets.

woprrr’s picture

woprrr CreditAttribution: woprrr as a volunteer commented

I guess the best solution would be to use both. If a site builder already knows that the "Simple/Embedded" widget would be suitable, then allow to pick this and set it up quickly. However in the case a site builder would pick the "Complex" one and happens to configure it to be a single, required, single-bundle widget then we can also render it as an embedded widget. In practice we could use the same code to render both widgets.

I fully agree with the conclusion for me this seems the most simple and clear.

I have a question, actuelement can we hide the widget if single cardinality exceed 1. I have the impression that multiple_values = false is useless ... It would be logical UI side not to propose the widget in this case.

bojanz’s picture

bojanz CreditAttribution: bojanz commented

The Simple widget no longer needs to be limited to cardinality 1.
"multiple_values = false" means that Drupal can repeat the widget for each delta, precisely what we need.

We need to keep the two separate widgets, we can't switch automatically, because we'd need to switch based on whether clone or reference existing is enabled, which is very unintuitive. We've done all of the unification we could with the introduction of the base class.

olak’s picture

olak CreditAttribution: olak commented

hey,
i'm not really sure if this ise the proper thread for this, or if its a duplicate.
my experience using this great module which simplifies a lot the workflow for refrencing entities, was quite good.
one point. using the form with "Inline entity form - Multiple values" widget you can either create a new entity, or use an existing one. the problem is if you try to use an existing one and realize it that it doesnt exist and you have to create a new one.
my proposition: it should ask the user. always use the add existing, and if it doesnt exist, either create it automaticaly notifing the user, or have an extra button create (next to add term and cancel) so it triggers the add entity form

  • bojanz committed 382e7f9 on 8.x-1.x 
    Rename the multiple widget to the complex widget (as decided in #2532810...
bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented
Status: Active » Fixed

Decision made, rename implemented: http://cgit.drupalcode.org/inline_entity_form/commit/?id=382e7f9

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.