[2.6/2.7] UX when hiding "Choose an option" in variation attribute drop-downs

[manospsyx]

Issue Description

When "Choose an option" is hidden from variation attribute drop-downs using show_option_none (https://github.com/woocommerce/woocommerce/blob/master/includes/wc-template-functions.php#L2171), the resulting UX is defective in a number of ways:

1. Selections can't be "Cleared". Currently, the script attempts to clear to the empty ('') option, which doesn't exist.
2. Clearing in this context does not make much sense. The 1st available options may not correspond to a valid variation at all, so a different approach is needed.
3. UI initialization is problematic when the attribute defaults are undefined and the 1st available options do not correspond to a valid variation.

Since this is not a feature but custom functionality enabled using a filter, I don't see a pressing need to provide a solution in WC 2.6.

Possible Solutions

A. Hide placeholder options when a valid combination is selected, show them when clearing

The simplest solution would be to always populate the drop-downs with a placeholder option ("Choose an option") and:

• Hide the placeholder options when the selected attributes correspond to a valid variation.
• Keep them hidden until the user clicks on "Clear".

B. Implement an alternative selection UX when placeholder options are hidden, and optionally use it (via filter) when multiple attributes are available

Currently, attribute values always "lock each other up" no matter what the selection sequence is.

Example:

Attribute A -- Option 1, Option 2
Attribute B -- Option 10, Option 20

Valid variations: [A:1, B:10], [A:2, B:20].

If the user selects Option 1 for A, then:

• Only Option 10 is available in the Attribute B drop-down.
• When Option 10 is selected, it is no longer possible to change the selection in Attribute A.

In some cases, it might be better to use a "non-locking" UX:

If the user selects Option 1 for A, then:

• Only Option 10 is available in the Attribute B drop-down.
• When Option 10 is selected, the user can still change the selection in Attribute A.

Assuming that the [A:1, B:10] combination is chosen:

• If the user changes the Attribute A selection to Option 2, then the Attribute B dropdown is reset to the placeholder option: "Choose an option".

So in general:

A selection in an attribute drop-down only limits the available options in the drop-downs under it, not above it. When an "incompatible" selection is made in a drop-down, the selections underneath it are reset to the placeholder option. Obviously, the ones above it are always going to be valid.

A similar UX is used in Composite Products 3.7 when dealing with drop-downs and dependent options.

[manospsyx]

Ref #12485 and #12486 -- I have seen issues opened in the past requesting that Solution B becomes the default behavior, but I didn't consider this a good idea then, and I still don't think it's a good time to change the default variations UX. However, it might make sense to implement it and have it activated using filters.

I'm happy to give Solution A or B a shot and send a PR, perhaps when the WC 2.7 compatibility dust settles.

[mikejolley]

@jameskoster input?

[jameskoster]

I like the second solution as well. Been thinking about that for a while in fact xD

I'm a little uncomfortable in making something we feel is an enhancement only available via a filter, though.

How about we did it the other way around? Make this the default, but let folks revert via filter?

[manospsyx]

How about we did it the other way around? Make this the default, but let folks revert via filter?

It depends on the use case. In cases where attributes need to (or might) be configured in any sequence, some people might prefer the current approach with the "Clear" button + placeholders.

Example: Choose a Color and Size for a T-Shirt. If Color is listed before Size, then a customer that chooses a Size first will probably want to see only valid selections in Color. If they see all Colors listed and pick one that is not available in the chosen Size, they will see the Size field reset itself. Upon clicking on Size, they will see that their initial selection is not listed.

In this application, I'd consider this kind of "non-locking" UX a bit troublesome. (Composite Products uses a slight variation of this, where instead of resetting Size, it would display a notice that the chosen Size is not compatible with the previous selections.)

The "non-locking" UX is definitely better in cases where selecting options in sequence is expected or implied, and has the advantage that:

• it doesn't need a "Clear" button
• it doesn't need placeholder options

It is difficult to support one or the other since I don't see any of the two being an edge-case requirement. One might work better for a product but not for another (even in the same shop).

With that said, CP switched to the "non-locking" approach because the extension is more commonly used in applications where sequence is enforced -- there, "attributes" (components) that are "stacked" in a single page are commonly separated by long descriptions and other elements, so users are less likely to scroll down and start choosing options in reverse. Note that when "attributes" are arranged in steps, the 'non-locking' approach is the only meaningful one.

For a tiny UI such as the Variable products' one, where attribute drop-downs are practically next to each other, it's a toss.

Note that both of them are able to handle "optional" attribute definitions, when/if they are introduced in core.

[mikejolley]

@jameskoster If you want to run this by team-x with fresh eyes, by all means. I don't mind which is the 'default' so long as a) the default works across the majority of use cases and b) it's easy to switch back. Would be nice to have some kind of basic CSS powered swatch too for things like colors and size codes but maybe asking for too much :)

[jameskoster]

We'll chat about it today.

[jameskoster]

Asked @tiagonoronha and @kellychoffman to take a look. If there was a working PR to help compare that'd be super-useful cc @franticpsyx xD

[manospsyx]

If there was a working PR to help compare that'd be super-useful

OK there is one now. It should work fine if you re-construct the specific use case described in #12565 but I haven't tested extensively otherwise.

Vids included.

#12566 describes 4 UX setups:

1. 'locking' with placeholder options visible
2. 'locking' with placeholder options hidden
3. 'non-locking' with placeholder options visible
4. 'non-locking' with placeholder options hidden

Flip between (1) and (3) with this filter -- https://github.com/woocommerce/woocommerce/pull/12566/files#diff-65760bf45f136dba5d546afa2c8b7ee9R1009

Then you can play with the behavior of placeholders by setting this to false -- https://github.com/woocommerce/woocommerce/pull/12566/files#diff-65760bf45f136dba5d546afa2c8b7ee9R2168

For me it's a toss between (1) and (3). I'd keep the current (locking) behavior as the default.

[jameskoster]

This is awesome, thanks @franticpsyx. I think I agree with your conclusion.

I believe @kellychoffman is looking at some design options for this as well. We'll catch up about that this week and see if that impacts the decisions at all.

[mikejolley]

Let's close in favour of #12566 and work on the solution there - there are 3 threads going on about the same thing.