[2.6/2.7] UX when hiding "Choose an option" in variation attribute drop-downs #12487
When "Choose an option" is hidden from variation attribute drop-downs using
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.
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:
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.
Attribute A -- Option 1, Option 2
Valid variations: [A:1, B:10], [A:2, B:20].
If the user selects Option 1 for A, then:
In some cases, it might be better to use a "non-locking" UX:
If the user selects Option 1 for A, then:
Assuming that the [A:1, B:10] combination is chosen:
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.
The text was updated successfully, but these errors were encountered:
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.
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?
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 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.
@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 :)
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.
#12566 describes 4 UX setups:
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
For me it's a toss between (1) and (3). I'd keep the current (locking) behavior as the default.