Options to hide unavailable variants from variant selects/drop-downs

[sciascia]

Note: Sorry this issue is long, it was initially short but this lead to endless confusion/discussion so it was expanded.

PROBLEM... The way variants are loaded allows customers to select products that don't exist - not sold out but products don't actually exist!

This not only sounds silly, most of us (including developers) interpret the result, 'Unavailable', to mean 'Sold out'. And if developers are confused, imagine how confused visitors are. This is expensive at this stage in the funnel.

Displaying products that don't exist or allowing visitors to select products that don't exist, also seems like a silly Shopify 2.0 outcome in general - right?

ISSUE OUTCOMES...

• Properly support Shopify's default 3x variant sets (merchants are currently given just enough rope to hang themselves)
• Stop Dawn creating shopper confusion at a critical, expensive stage in the sales funnel
• Leave it to partner apps to provide advanced conditional logic for complex products

BASIC, ONE-WAY VARIANT SEQUENCING COULD...

• Remove products that don't exist so visitors can't see or select them
• Break the task into steps which human brains really like (less funnel drop-off)

CONSIDER THE LEFT EXAMPLE FROM DAWN...

• Yes, many shoppers will easily understand how to choose what they want but...
• Some shoppers focus exclusively on their target (Galaxy S21). This leads to a decision that 'Unavailable' must mean 'Sold out', even though Apple doesn't make the Galaxy. Notice how the first select states Apple? An Apple Galaxy S21 doesn't exist but on page load, the selects display a product that doesn't exist - silly no?
• This often happens quickly, with a return to Google after only a few seconds: LAND –> UNAVAILABLE –> LEAVE
• And finally, the decision area is more cluttered, taking up valuable screen real estate

CONSIDER THE RIGHT EXAMPLE WHICH USES VARIANT SEQUENCING...

• It removes the ability to choose Galaxy S21 before choosing Samsung
• It uses zero brain power by directing shoppers to 'Choose...' without adding extra elements to the page. Our brains like this.
• It removes elements, takes up less room and dramatically reduces visual clutter to aid decision making

BASIC VARIANT SEQUENCING IS WELL-UNDERSTOOD... For each shopper that changes the combinations, or asks when the Galaxy will be in-stock, others exit thinking it's sold-out. Instead, variant sequencing is simple and is understood by all ages like my 70 year-old Dad. It also suits many products...

HOW IT WORKS IF SWITCHED ON...

• Only the first select is active on page load
• Secondary selects are disabled until variants are chosen from proceeding selects
• Variants update based on proceeding selects thereby removing 'not possible' combinations
• Feedback that selects are updating could be included (short animation or a flash of sub-selects)
• Display a 'From price' until final selection is made
• Move option set names into selects as the first item
• Use clear, directional language like 'Choose (option set name)...'
• Display sold-out variants with strike-through

OPT-IN... Setup could be simple, optional and self-explanatory. And if you like how Dawn works currently, don't turn it on.

Or setup could be fully configurable...

VARIANT LINKING... Currently, it seems Dawn is guarding against visitors not finding their preferred variant from a variant link or variant search result - an argument made in comments below.

e.g. A variant link auto-configures the first select to 'Samsung' and the second to 'Galaxy S21'. But say the visitor wants an iPhone case and if variant sequencing is on, they won't see iPhone unless the first select is changed to Apple.

• However, because the visitor can't see what they want (iPhone) anchoring or confirmation bias doesn't come into play like it does currently. i.e. iPhone won't distract visitors from noticing that Samsung needs changing to Apple
• Also, shoppers are less likely to have been shown links for variants they didn't search for, and are less likely to click variants they don't want. Especially when also shown results for variants they do want (as is common in search results)
• And finally, the proposed change is optional, letting merchants choose which solution works best for them

BIAS AND HUMAN DECISION MAKING... Some dismiss fixation, anchoring or confirmation bias. However, plane crashes have been caused by pilots with tens of thousands of flight hours, fixating on one piece of data at the expense of obvious data to the contrary.

In this context, look again at the first screenshot above. Some shoppers fixate on the thing they want (Galaxy S21) at the expense of obvious data to the contrary, the fact that Apple doesn't make the Galaxy S21.

But because our brains don't like to think, people see 'Unavailable' and think 'sold-out', then leave. The path of least resistance wins out more often than not.

DESCRIBE ALTERNATIVES YOU'VE CONSIDERED...

• Splitting variants into multiple products greatly confuses shoppers with certain product-types in our experience
• Splitting variants also breaks stock counts when sub-variants are common across newly split products. e.g. If full sheet sets and half sets are split into separate products, pillowcases (which are typically offered in addition to sets) can only live with one of the newly created products. Otherwise, stock counts will require constant juggling between the two (painful)
• Splitting variants also splits reviews, and more reviews often means more sales
• Apps are bloated in this area, with many complex features that aren't required for basic, one-way variant sequencing
• Apps also introduce different standards, costs, and in our experience, lower page speeds (plus other theme-pain)
• Apps introduce interoperability issues like you pre-order app doesn't work with your product options app etc

HAVE ALSO TRIED...

• https://www.youtube.com/watch?v=vspWDu_POYA
• https://community.shopify.com/c/Shopify-Design/Variants-Link-product-options/td-p/615156
• https://gist.github.com/carolineschnapp/1083007

FINAL THOUGHTS... 'Unavailable' seems like a past hangover or a workaround - or maybe it's a solution to a different problem like development resources or protecting the app ecosystem.

Whatever the reason, letting shoppers choose variants that don't exist seems like a silly development outcome for Shopify 2.0 - right?

[johnsfuller]

From a UX perspective, I'd prefer some middle-ground.

For example, say my shop sold tshirts in S, M, L, and XL. I'd want to convey to the customer that XL is possible even when the shop is "sold out".

Therefore, I'd rather have XL show as disabled instead of hiding the variant option altogether.

[sciascia]

@johnsfuller The request isn't to handle sold-out, it's to stop people from thinking that 'Unavailable' means sold-out.

However, I agree, have amended screenshots above. An official example of how this should be handled is needed (yep, my JS is lame). Especially in the flagship Shopify 2.0 theme - right?

[gregjotau]

https://github.com/Shopify/dawn/pull/105

Sold out UI is implemented in this PR. I tested on famme.no and it works.

[sciascia]

105

Sold out UI is implemented in this PR. I tested on famme.no and it works.

Thank you, will see if I understand how to adapt this for unavailable variants (not sold-out) - my JS is pretty lame so will see how I go! Cheers

[cfxd]

@sciascia check my PR @ https://github.com/Shopify/dawn/pull/105/files

[sciascia]

@cfxd Thanks for your help but to be frank, I don't understand how to adapt your changes to remove unavailable variants based on interaction with the first select/variant (but I understand very little about JS sorry).

[cfxd]

@cfxd Thanks for your help but to be frank, I don't understand how to adapt your changes to remove unavailable variants based on interaction with the first select/variant (but I understand very little about JS sorry).

The link I pasted shows you file by file exactly what to add/remove and where to do it in your files if you want to do that manually. Alternatively, you can pull down that branch and just use that, or download the entire theme with that branch checked out @ https://github.com/cfxd/dawn/archive/refs/heads/variant-picker-sold-out-ui.zip.

[sciascia]

@cfxd Thanks for your help but to be frank, I don't understand how to adapt your changes to remove unavailable variants based on interaction with the first select/variant (but I understand very little about JS sorry).

The link I pasted shows you file by file exactly what to add/remove and where to do it in your files if you want to do that manually. Alternatively, you can pull down that branch and just use that, or download the entire theme with that branch checked out @ https://github.com/cfxd/dawn/archive/refs/heads/variant-picker-sold-out-ui.zip.

@cfxd Oh OK, sorry. I couldn’t see any if/else logic which removes unavailable variants when a user interacts with the selects - the JS changes look so simple! Will integrate and test. Thank you.

[sciascia]

@cfxd Your zip has ‘sold out’ in the name, does your code also remove unavailable or just sold out?

Unavailable is different from sold out because unavailable occurs when a user selects variants that aren’t possible. Why Shopify doesn’t recognise this as a major UX bug after all these years is beyond me because customers (and developers) think unavailable means sold out when it doesn't.

In our experience, it's a critical time in the sales funnel to have silly confusion like this - right?

[cfxd]

@sciascia Please read the pull request, all of your questions are answered and there are links to examples where you can see exactly how it looks on the frontend.

[sciascia]

@sciascia Please read the pull request, all of your questions are answered and there are links to examples where you can see exactly how it looks on the frontend.

@cfxd I've re-read it several times and tested the code but it doesn't handle 'Unavailable' variant combinations - you understand that 'Unavailable' is totally different from 'Sold out' - right?

See attached which uses your code (switched from selects to buttons to better illustrate). Notice how certain in-stock variant combinations are 'Unavailable'. This is because the combinations aren't possible but Shopify displays them anyway.

Instead, the variants should update whenever the customer interacts. I've re-read the pull request and tested the code several times so I'm really sorry if I'm missing something basic request.

[cfxd]

@sciascia I understand what you're asking, but I don't think it's proper UX to hide variant options just because a combination is not sold on your shop. Visitors arriving to view a specific variant might then not even realize that other variant options are available if those options are hidden on page load or after making a selection.

You may want to consider simply changing the "Unavailable" label text to read something more descriptive such as "Invalid selection" or "Not sold in this configuration" or possibly even include an asterisk with small text below the Unavailable button.

[sciascia]

@sciascia I understand what you're asking, but I don't think it's proper UX to hide variant options just because a combination is not sold on your shop.

It's also not proper UX to show people things that don't exist. e.g. A Google iPhone case - right?

Visitors arriving to view a specific variant might then not even realize that other variant options are available if those options are hidden on page load or after making a selection.

There are pros and cons to both ways, that's why designers/merchants need a way to choose what's best for their store/product/industry - no?

You may want to consider simply changing the "Unavailable" label text to read something more descriptive such as "Invalid selection" or "Not sold in this configuration" or possibly even include an asterisk with small text below the Unavailable button.

Customers gravitate to what they want, so when they see iPhone, they ignore say, Google. "...what do you mean not sold in this configuration? I chose iPhone..." etc. Also, 'invalid selection' and asterisks are workarounds, so if the choice is either:

1. Confuse people coming from inbound links or...
2. Show people products that don't exist

Shopify should recognise that both are silly at this stage in the sales funnel and solve it. At the very least, let people choose which suck is best for them - right?

[PaulNewton]

This is a sticky wicket problem that crosses many areas in such as way that can be hard to explain why it's such a problem to get right. Part of it stems from , and other inputs , being built on the variant data of either the full title or it's options and the frontend dropdowns not being built to be bi-directional|multi-directional for each option selection that is generated to interact with every other dropdown. The "unavailable" isn't validated until AFTER selections are made.

A thing to keep in mind is the wider merchant base doesn't always have this problem so the incentive to solve it globally for those that do is low, along with an expectation they will solve that specific business requirement. @sciascia You said it yourself:

There are pros and cons to both ways, that's why designers/merchants need a way to choose what's best for their store/product/industry - no?

@sciascia It's also not proper UX to show people things that don't exist. e.g. A Google iPhone case - right?

And that's the problem - the first field "Brand" when a selection is made needs to dynamically update what is in the field "Model". What you do not want is to remove Iphone X in it's entirety from the dropdown data, right? If you do then when users select "Apple" there is no longer an "Iphone X" option at all!. So we've arrived that the catch: all you've done is a round trip back to the Unavailable problem but now instead preventing invalid combos now we're preventing combos that ARE valid through simple omission. A silent death trading a true negative for a false negative.

Now reverse the problem keep "Iphone X" and remove "Google" from the brands dropdown, starting to see the issue?

And note if you do do this with dynamic JavaScript it can be a perf hit even with only 100 variants if your not careful.

Confuse people coming from inbound links or...

Most themes should default to pre selecting the first available variant, or the selected variant the url is a variant deep link(?variant= parameter)

This isn't unsurmountable but there are reasons it's like this and not an easy fix unless someone spends a good deal of time on it. Then there's that even with Online Store 2.0 shopify still has to support legacy systems around this behavior.

*edit fix quotes next paragraph collapse missing linebreak

[sciascia]

Part of it stems from , and other inputs , being built on the variant data of either the full title or it's options and the frontend dropdowns not being built to be bi-directional|multi-directional for each option selection that is generated to interact with every other dropdown. The "unavailable" isn't validated until AFTER selections are made.

For the vast majority of merchants with this issue, it's not bi/multi-directional, it's top-down. And if consumers aren't already familiar with top-down, they tend to gravitate to the first variant first, then instantly understand it.

e.g. If Apple is chosen from the master variant, the sub-variants update...

Or if Sony is chosen from the master, the sub-variants update...

Here's a quick example in practice: https://youtu.be/vspWDu_POYA?t=457

To aid consumer understanding, sites might opt to include a sub-variant loading animation, or flash sub-variants on update, or disable sub-variants until a master variant is chosen.

A thing to keep in mind is the wider merchant base doesn't always have this problem so the incentive to solve it globally for those that do is low, along with an expectation they will solve that specific business requirement.

More merchants than you realise either live with it or split variants into separate products. But this causes endless consumer confusion and also splits reviews for the same product. We do this currently and it's incredibly frustrating.

But if you offer 3 layers of variants like Shopify does, you need to solve the problems it creates. Otherwise, you're burying your head in the sand and creating 'not my problem sir' development.

The great thing about the new sections system is that it could be simple, powerful and aid consumer selection at a critical point in the sales funnel. e.g. If I choose selects, show me basic options that make it understandable for customers...

Remember, this is just to support the default variants Shopify provides, nothing advanced, nothing custom, no apps etc.

This isn't unsurmountable but there are reasons it's like this and not an easy fix unless someone spends a good deal of time on it. Then there's that even with Online Store 2.0 Shopify still has to support legacy systems around this behaviour.

I'm not saying it's easy, I'm saying it's 2021 and this was all solved a decade ago. Variant hierarchy or sequencing is common-place and is understood by everyone, including my 70-year old Dad.

It might've been OK for Shopify to leave this out 10 years ago but not today. It's as basic as shoppers choosing what they want. That's not edge or advanced, it's fundamental - right?

[PaulNewton]

Reference urls of the official shopify advanced customization tutorial often used to solve this issue and it's javascript github gist

• https://community.shopify.com/c/Shopify-Design/Variants-Link-product-options/td-p/615156
• Linked options helper methods for Shopify · Gist · GitHub

[sciascia]

Reference urls of the official shopify advanced customization tutorial often used to solve this issue and it's javascript github gist

Thanks Paul, I'ma designer so my JS is lame sorry. However, I tried that stuff from the video but it doesn't work in Dawn. I assume Dawn's JS is completely different from Debut or it was my JS skills.

[PaulNewton]

But if you offer 3 layers of variants like Shopify does, you need to solve the problems it creates.

X amount of options provide flexibility for product architecture, the outcomes of how some businesses use such a system are not to be born by everyone regardless of framing it in a rhetorical landmine as a problem or "fundamental".

Remember, this is just to support the default variants Shopify provides, nothing advanced, nothing custom, no apps etc.

Yes that's part of the problem this type of change affects those aspects of shopify so it's they that must be remembered. Dawn is at the mount not the mouth. Basic features in a reference theme creates flexibility for all types of changes downstream. Overly specific advanced changes in a reference theme creates inflexibility for even basic changes downstream.

A top-down variant hierarchy is common-place and is understood by everyone..

So if "everyone" understands a top-down variant hierarchy... how is "Unavailable" also not understandable by everyone knowing to just flip the parent options till they get valid combinations? "Unavailable" is understood by everyone... see how that works? Avoid hyperbole when seeking specific technical and UX change that can impact millions of businesses.

I am not being facetious, just because you have a need for the specific a general use case for this type of UX problem still has to be addressed headon from references in UX research and/or merchant behavior data; probably before even dealing with the technical implementations. Shopify would have the best merchant behavior data on the truth of this by testing stores for link-options.liquid but so far they are not engaging all tickets for this project.

It might've been OK for Shopify to leave this out 10 years ago

QED you've solved it? Shopify has had an advanced tutorial to address this behavior pattern that has existed for a decade in shopify's own themes for the technical , the UX, and now legacy reasons. Unless Shopify actually has plans to address this in an intrinsic way(liquid or a rest api)[1] this feature request seems a pointless uphill battle best left as a blogged about customization, a separate repo branch needing this specific behavior, or left in pull requests with the contributor documenting how merchants can integrate the pull request themselves.

Probably anyone wanting this would probably need to go beyond a feature request and Champion this change and collate the ecosystem knowledge around this problem in a way that no one has done before publicly so that they completely grok it deep enough that it doesn't get dismissed as yet another overly specific "want". Messing with options gets a very long preflight checklist in dealing with the technical implementation: repo maintenance[2], backwards support , app integrations, customizations like swatches ,etc.

[1] I'd expect this more likely to be addressed in tandem with some future feature that lets us deep link to options and not just "variants"(?variant=12345) on /products pages. [2] cfxd's PR #105 more than doubles the code handling the options output, mostly due to the nature of what conveniences are available in liquid for dealing with options and arrays.

[PaulNewton]

@sciascia sites might opt to include a sub-variant loading animation, or flash sub-variants on update, or disable sub-variants until a master variant is chosen

Loading/Transition behavior probably should be part of the notes for this type of request as a locked UI form elements during such state transitions can be a user frustration.

[sciascia]

Allowing shoppers to choose products that don't exist is a really silly development outcome.

'Unavailable' is the solution to a different problem (cost, resources, app ecosystem, whatever).

[aarsammon]

Has anybody figured this out? I can't understand why you would want to show variants that don't exist. It's terrible user experience.

We need to remove all unavailable outcomes on variant reload.

[olegbek]

This is what I've done. I simply need a dropdown of all sizes(variants). There is a 'noscript' tag in the code which has a normal 'select' with proper variants, not options. I've replaced 'noscript' with div and used {% if variant.available %} to remove unavailable variants from the list. Also commented out the logic under {%- when 'variant_picker' -%} that spits out dropdown or buttons. Looks and works exactly the same as the Dawn' version but without unavailable variants there. I know this won't fit everyone's case but it's just what I need for my simple case.

[sciascia]

@olegbek Thanks for this but sold-out and unavailable are actually two differing things.

'Unavailable' gets displayed when variant combinations that don't exist are chosen. Hence this request to have Dawn not display them to begin with.

If you're reading this and are from Shopify, this is another example of how everyone is easily confused (then leave your site).

[olegbek]

Not a problem. @sciascia I definitely understand the issue and your case and my approach doesn't help you but just decided to share my approach in our case. We're not showing sold-out products at all on the website.

[sciascia]

@olegbek Sweet as, cheers

[sathwal]

If anyone needs help with this, please check out my job on Fiverr where I can help fix it for you - https://www.fiverr.com/share/ZLkjvQ

[vahidrk]

It's still unsolved. I've wasted a good amount of time on this and still nothing!

[cfxd]

It's still unsolved. I've wasted a good amount of time on this and still nothing!

Not a particularly friendly or helpful comment you've left here, but have you seen this?

You can always submit a PR of your own if nothing else is working for you and you don't want to share any additional details.

[sciascia]

Not a particularly friendly or helpful comment you've left here, but have you seen this?

You can always submit a PR of your own if nothing else is working for you and you don't want to share any additional details.

It's fantastic you've found a solution to 'Sold-out' but this issue is about 'Unavailable' which is a different variant exception. If your code solves 'Unavailable' than please ignore this comment and let us know!

But if it doesn't solve 'Unavailable', please be a ware that anyone posting 'Sold-out' commits (#861 #105 #1407) to this issue, create more confusion and illustrate how easily the two are confused - no wonder consumers are also confused!

Also, some of the people posting here (in a developer forum) are merchants because Shopify doesn't provide visibility on feature requests or design issues with its themes - they simply go into a block hole.

Hence this Github issue. Shopify 2.0 displays variant combinations that don't actually exist by default, and that's a silly outcome in anyone's book - including developers right?

[JonoHall]

I share your frustrations with this seemingly terrible design decision, but I guess Shopify have their reasons for keeping dynamic selectors out of their base code.

I've had linked options with old themes for 5+ years now using Caroline Schnapps snippet, and we simply can't switch to Dawn until this was resolved.

I'm a backend developer (PHP etc) with no experience with JavaScript. But out of shear frustration I got to town figuring out a solution for my situation. Caroline's code requires jQuery to run, Shopify has dropped this, so I set about trying to convert her code to work, difficult when it's not my own code. In the end, I completely rewrote how it works in native JavaScript.

The solution posted below has been working on my shop for the last couple of weeks without incident so far. https://github.com/JonoHall/linked-options (please refer to my updated solution here)

Please note that this code is as-is, it's for Drop Down boxes only (not pills). I don't pretend that I'm fully qualified in JavaScript, I basically learned/wrote this over a couple of weeks. Treat it like it has bugs, a beta if you will, it's very basic.

If anyone has JavaScript development experience, please feel free to contribute with pull-requests.

Hopefully this might help a couple of people out. And hopefully a more official solution comes along eventually.

https://user-images.githubusercontent.com/4916365/158136115-f134c19b-33dc-491b-aada-869c90b9e949.mp4

[PaulNewton]

@aarsammon ..I can't understand why you would want to show variants that don't exist. It's terrible user experience.

@sciascia Hence this Github issue. Shopify 2.0 displays variant combinations that don't actually exist by default, and that's a silly outcome in anyone's book - including developers right?

An option is the smallest unit of possibility of a product

I.e. sum of the parts, not a single variant in totality ; so yes very unintuitive in a this-then-that linear mindset if viewing a product only as a container for variants.

Users do not always use inputs linearly. Consider a product with 3 options and then work backwards in the UI dropdowns from the last option. Now do if the middle option.

For example even though you may have no shirt that is large+womens+red, however as a merchant and product seller you still want red(colors) to be selectable in dropdowns or swatches or images. The size or gender options can be changed because "red" is a possibility of the product not a dead end because of 1 variant. Now go through a linked-option scenario while using swatches, that red swatch has to be removed from the UI; as do any other tangential elements on the page everytime a parent option changes (lots of dom manipulation and layoutshift).

Imagine @JonoHall 's paint brush example with a 3rd option of tip-shape(square,angled). The amount of clicks and back and forth for customers goes way up for any customer shopping based on that last characteristic that's now hidden 2 layers deep.

You want the possible >>options<< to be navigable regardless of the combinatorics outcome of the variant itself. Yes , there are legitimate reasons to do progressive disclosure via something like linked-options instead of providing all possibilities at once and those cases should test and validate assumptions as often a custom implementation is needed anyway because you are introducing different UX behaviors and code complexity for a products specific context.

Meanwhile dynamic linked options ramp up complexity really fast and tend to work in 1 linear direction unless you add even more complexity to be multi-directional between all options. With things like: what happens when one option set is selected nullifying another set? whether aria-live regions get used? How do you do product-interest analytics at the option level if a 3rd of the time that option isn't interactable or the combo never exists? what happens when variant is deleted while a customer is shopping? What happens if shopify ever allows more than 3 options etc etc.

If you ever work in an archetype theme see their dynamic options doc and code as a general example of how complexity ramps-up https://archetypethemes.co/blogs/support/dynamic-variant-availability

Now do all of the above through the lens of accessibility with a screen reader as a customer that's non-sighted or low mobility or keyboard-only etc.

For the current approach of multiple-option products the ecosystem gets some side affects: Simpler code in exchange for some combinations having an non-existent state "unavailable" (again handled by simple code disabling add-to-cart buttons). And headaches for merchant 🤕 because it's not an easy thing to distill down and educate merchants about all the non-apparent reasons option selectors are like this in a satisfactory way that counters expectations of the uninitiated. It's kinda like fixing the expectations, complexity, and usage surrounding slideshows; the problem is very unwieldy and sometimes self-defeating so best left to the individual business to handle with a boilerplate response because there's either not enough collective action or valid data to back it up that can force change 🤷‍♂️.

[PaulNewton]

@JonoHall To avoid having quantity as an option and confusion with the cart quantity here are alternatives: count ; then box, case, casing ,container, lot, packaging, portion, units(if never using unit pricing) ,

[sciascia]

@PaulNewton Users do not always use inputs linearly

They do when guided through the process. Yes, there are use-cases where some will get confused (covered below) but this is less likely if they were stepped through the selects one-by-one.

Consider the right example. It instantly explains that a brand, product, and colour need to be chosen in order - and it directs you to the first select with zero thought.

Our brains really like this because the work of deciphering next steps has been done for us. And a huge advantage of configuring the selects yourself, is that you're more likely to understand how to get what you want.

ON PAGE-LOAD, VARIANTS AREN'T CONFIGURED TO A REAL PRODUCT

Consider the left example. When I tested Dawn, page-load configured the selects alphabetically, or by option order, not by a product that actually existed. This is an illogical outcome for most shoppers - I'm sorry but it just is!

And because it's illogical, our brains often can't be bothered understanding it, so decide that 'Unavailable' (or some other term) means sold-out. It's the path of least resistance which is a primary goal of brains = don't waste energy.

BUT WHAT IF CUSTOMERS ARRIVED VIA A VARIANT LINK?

1. Variant links configure selects to products that actually exist. This is logical, so the way the selects work is more readily understood, making problems arising from select order more edge.
2. With regard to search results, shoppers are less likely to have been shown links for variants they didn't search for, and are less likely to click variants they don't want - especially when also shown results for variants they do want, as is common in search results. This makes problems arising from search results more edge for many product types.
3. Yes, there's the potential for confusion but that's true of any solution using multiple selects, including the current one so why not handle common exceptions?

@PaulNewton Now do all of the above through the lens of accessibility with a screen reader as a customer that's non-sighted or low mobility or keyboard-only etc.

Yes, everything you outlined is complex and each way has pros and cons but it's totally doable as your link below proves! However, Shopify offers 3 levels of variants by default, which is more than enough for merchants to hang themselves without a proper way of handling variant exceptions.

Also, this isn't an either/or request, it's optional so you can choose what's best for you and leave more complex logic to apps - right?

@PaulNewton If you ever work in an archetype theme see their dynamic options doc and code as a general example of how complexity ramps-up https://archetypethemes.co/blogs/support/dynamic-variant-availability

OK but the example in your link provides the solution! As do millions of other sites. It's just that many of us don't agree this is an advanced theme customisation in 2022. It's basic ecommerce, especially for the next-gen 'Shopify 2.0' - and we get that you don't agree!

But if displaying products that don't exist is an acceptable Shopify 2.0 outcome, Shopify are quite capable of explaining that for themselves.

@JonoHall I share your frustrations with this seemingly terrible design decision, but I guess Shopify have their reasons for keeping dynamic selectors out of their base code.

Couldn't agree more, they definitely have their reasons however, I don't agree this is an advanced theme customisation in 2022, especially when you offer 3 variants per product out-of-the-box.

At least supply an official, Shopify 2.0 way of handling variant exceptions, even if it's in a developer blog - right?

@JonoHall Hopefully this might help a couple of people out. And hopefully a more official solution comes along eventually.

Thank you so much. We've just started migrating our store to Shopify 2.0 so will definitely take a look at your code - very much appreciated!

[webmgrscandia]

I share your frustrations with this seemingly terrible design decision, but I guess Shopify have their reasons for keeping dynamic selectors out of their base code.

I've had linked options with old themes for 5+ years now using Caroline Schnapps snippet, and we simply can't switch to Dawn until this was resolved.

I'm a backend developer (PHP etc) with no experience with JavaScript. But out of shear frustration I got to town figuring out a solution for my situation. Caroline's code requires jQuery to run, Shopify has dropped this, so I set about trying to convert her code to work, difficult when it's not my own code. In the end, I completely rewrote how it works in native JavaScript.

The solution posted below has been working on my shop for the last couple of weeks without incident so far. https://github.com/JonoHall/linked-options

Please note that this code is as-is, it's for Drop Down boxes only (not pills). I don't pretend that I'm fully qualified in JavaScript, I basically learned/wrote this over a couple of weeks. Treat it like it has bugs, a beta if you will, it's very basic.

If anyone has JavaScript development experience, please feel free to contribute with pull-requests.

Hopefully this might help a couple of people out. And hopefully a more official solution comes along eventually.

msedge_iFq47KfTGe.mp4

HI! What theme are you using? Can you help me with the set up?

[davidkensell]

Another example, if it's helpful to whomever is considering solutions to this problem.

I can understand why you might not want to hide "XL" if it exists in Red but not Green. But in shoes, or this case orthotics, you have completely different size sets — even tho they often use same numerals. So displaying them both together is pretty confusing.

I guess I will probably break them out as two different products, common approach for shoes.

As is, it is certainly confusing to someone shopping for Womens who if hit any of the top half size options sees it as "unavailable."

[cfxd]

@davidkensell what you're describing is a customization

[garypaul]

Amazon has really nailed the UI on this one, folks.

https://www.amazon.ca/StarTech-com-TBLT34MM50CW-Passive-Thunderbolt-Charger/dp/B071P51QXS

By default when you go to a page, the first option is selected. "Unavailable" options (based on selection) are dashed.

IF I hover over "2 m" in the example a "Pop-up" says "See available options" shows up. When you click , a green message says: "Updated other options based on this selection"

If I'm a consumer, I want to choose a Style 20 Gbps cable but a SIZE of 0.5m. On this page I can clearly see that it's not available, but when I CLICK on 0.5m, the STYLE switches to 40 Gbps instead of saying "Unavailable" which really is bad UX.

You're showing available options, so it must be available just not in this configuration. If I click on 0.5m, I want you to change the style to see something in 0.5m sizes.

Think about this logically from a shopper's perspective in a store buying cereal.

I want a large box of honey-nut cheerios. It's sold in small/medium/large, and in regular/multigrain/honey-nut.

There are no LARGE "HONEY-NUT" CHEERIOS available, though.

I tap the large button and all the cheerios disappear except the Multigrain. But I don't want Multi-grain. I press the honey-nut button and everything disappears. WTH! Where did the cheerios go? When I select "honey-nut" its available sizes should show up. Other sizes are grayed out but selectable.

The point is... you really can't tell what's more important to the user... the flavor or the size. The phones example is somewhat clear, but not the best example... because USUALLY people are pretty clear about what phone AND manufacturer they want.

[sciascia]

OP here, excellent points but I wasn't proposing that Shopify provide this level of deep conditional logic, only that Shopify provide an alternative way of handling variant exceptions (as an option) through simple, one-way variant sequencing. It's not perfect but would be a better option for many types of products.

@garypaul "USUALLY people are pretty clear about what phone AND manufacturer they want".

Yes but it's surprising how many people think 'Unavailable' means 'Sold Out' and don't understand it's the variant selects causing this, not stock levels. It's 'in the moment confusion' not necessarily product/brand knowledge. And for each person who can be bothered emailing regarding stock, many more leave thinking it's sold out.

SPLITTING VARIANTS INTO SEPARATE PRODUCTS When using Dawn, we've had to split variants into different products (split product pages, different links, split reviews etc) but they're actually the same product. This leads to emails like 'don't you sell XXX?' And again, for each person who emails, many more leave thinking we don't sell that variant - when we do.

BUT THERE'S AN APP FOR THAT - RIGHT? And while Shopify pushes us towards apps to solve this, apps create issues when they're all modifying the same data. e.g. product options apps, bundling apps and pre-order apps are all modifying or interacting with selects. Suddenly, your pre-order app doesn't work with your product options app or worse, displays incorrect info that customers use to make buying decisions.

PRODUCT CHOICE IS THE WHOLE BALL GAME Product choice is ecommerce 101, it's that fundamental. And like many merchants, I'm trying to avoid relying on apps for fundamentals. As soon as multiple apps are required for the basics (as is the case in 2022) Shopify needs to up its game so merchants can avoid horrible problems associated with app interoperability.

AN ALTERNATIVE OPTION One-way variant sequencing is by no means perfect but would provide merchants with an alternative option for handling variant exceptions and reduce the need for multiple apps to modify the same data, at the same time.

[johnsfuller]

I have indeed split some variants into separate products when it makes sense and then created faux variants with product metafields. Same radio variant styling as normal radio variants...

Customer's choose the faux variant and then it links to the other product. A more elegant way would be to ajax and update the url without a refresh. Hope that technique helps give some of you a workaround.

[DummyDesign]

Hello everyone,

I'm a designer too, and at the moment, the only solution I found (using NO apps) was, to add the color swatches in the admin product description using the HTML editor for each product - this way, all the color swatches will be displayed in all product pages and when someone selects another color, they will be redirected to the respective product page of the selected color. In the collection, it will display all product color variations as separate products.

ps: The Swatch color images were upload to Files, and then linked to the product description using their respectives "URL"

[MrBillium]

I wholeheartedly agree with OP on this one. His phone case example demonstrates the problem and a good solution . The 'whatabout xxx' comments may be valid but they don't dismiss the stated issue that you can specify an Apple Samsung case. 'Unavailable' is a crutch and about as useful as 'Error' The proposed workflow addresses the problem and is intuitive.

If a developer wrote a website using Flask, Django etc and allowed the above crazy selection to happen they would be expected to fix it - no excuses allowed.

So why should Shopify get a pass on this?

Grrrrr

[sciascia]

For those of us who've used other ecom software, it's unacceptable that something as fundamental as product choice is not properly sorted for the number of variants Shopify offers by default - this is supposed to be Shopify 2.0 afterall.

And 'Unavailable' is absolutely the same as displaying 'Error'. We all know that's a classic 🤦‍♂️ in 2022 so there's no need to go back and forth over this.

Even 3rd-party themes handle product choice better than Shopify so everyone knows what needs to be done - right?

[IGordiichuk]

@cfxd ... check my PR @ https://github.com/Shopify/dawn/pull/105/files

Hi. Perhaps there is such a solution for the old Debut theme with radio options buttons? I haven't been able to find it yet. Very necessary. Thank you.

[PaulNewton]

@johnsfuller I have indeed split some variants into separate products when it makes sense and then created faux variants with product metafields. Same radio variant styling as normal radio variants...

FYI: Some metafield definitions types now support lists which can simplify this method when making sets of fake options on products. Note that @DummyDesign 's method works somewhat better in multi-channel situations, but the metafield method does not.

Fat product model, product-family model are also often a requirement due to a merchants ERP, multichannel needs, or faking going over the 100 variant limit. While there are some discussions available online if you need to go through the possibilities here are the alternatives instead of the metafield method:

• Collection-As-Product - For lots of family-variants either put theoften with the same handle as the core product, i.e. shirt, then all others products typically should follow a naming convention for their handles shirt-red, shirt-green to help display options. Use the liquid array filters map and where to work with the collections products data.
  • Handful of loose products - For less than 20 family-variants per page use the liquid global all_products when you dont want to put things in collections but do have a convention or logic to their relation( handle-naming, linklists). Keeping in mind that the 20-uses limit is **per page** so using this with things like inline rendered product-recommendations does not work unless calling over the sections rendering api or other tricks (untested with custom-liquid blocks).
• Lots of products with hierarchy - use a combination of collections and linklists to interrelate and nest by using the link.object to access the product resources through the linklist itself.

[PaulNewton]

@DummyDesign solution I found (using NO apps) was, to add the color swatches in the admin product description using the HTML editor for each product

If multi-channel be sure to check how that description looks displayed in other contexts. If your doing html editing ALOT and the products & swatch-images follow naming conventions it can helpful to instead make some liquid code to generate the html code on each products page, then use the theme editor to put that liquid code into a custom-liquid section in a OS2.0 theme.

[PaulNewton]

If a developer wrote a website using Flask, Django etc and allowed the above crazy selection to happen they would be expected to fix it - no excuses allowed.

So why should Shopify get a pass on this?

Not comparable. One is a just single source dedicated to a single merchants solution. Meanwhile Shopify is a platform that has to provide generalized features to MILLIONS of varying merchants needs. Unavailable is a result of that generalization having a decade of usage.

The good news is this is largely handled as a frontend development issue so that flask,djano developer could be tapped to make a dedicated frontend solution to a single merchants specific need.

[PaulNewton]

@IGordiichuk Perhaps there is such a solution for the old Debut theme with radio options buttons? I haven't been able to find it yet. Very necessary.

See this thread previously linked and it's Debut comments: https://community.shopify.com/c/shopify-design/variants-link-product-options/td-p/615156

[duffpop]

I have indeed split some variants into separate products when it makes sense and then created faux variants with product metafields. Same radio variant styling as normal radio variants...

Would you be able to share an example of this?

I'm working on similar functionality but I'm quite stuck; a product requires four options, the first three are variants and the last is a product metafield.

[sciascia]

@PaulNewton Meanwhile Shopify is a platform that has to provide generalized features to MILLIONS of varying merchants needs.

No merchant ever wants visitors choosing products that don't exist. You can't get more general than this.

@PaulNewton Unavailable is a result of that generalization having a decade of usage.

Even the link you posted from 3 years ago states: 'In short, you don't want your customers to encounter this'. That's because when customers can't easily get what they want, there's no point. Again, you can't get more general than this.

@PaulNewton The good news is this is largely handled as a frontend development issue.

Which is exactly why Shopify should handle this in their flagship 2.0 theme. It's 2022 not 2012.

[JonoHall]

I've taken another stab at this issue. I've got the following result:

Live demo (password: dynamic): https://dynamic-selectors.myshopify.com/products/phone-case

I've tried to keep it a minimal as possible with the options of feature updates in the future. But the modifications are relatively simple for someone that knows how to edit a file and simple to remove if you need to.

To follow along with these enhancements, please visit the following repository. Please star it and be sure to monitor it for changes/bug fixes: https://github.com/JonoHall/Dawn-Enhanced

Notes

• I'm a developer, but this is the first time I've touched Javascript simply to solve this cursed issue. Use at your own risk.
• Works for pills only, I might do drop down boxes in the future idk. It works for both pills and drop-down boxes now.
• I can't install/support this for you, only make modifications to your theme's code if you know what you're doing, or hire a developer to do this for you.
• There's still some user unfriendly things happening here, such as resetting the options when no valid option is available and this may go against usability conventions. But it seems to make a damn lot more sense than the default system.
• I may add some new functionality like asking the user to pick an option first before showing children levels.