Online Store Editor - Sidebar & Conditional Settings

[adrocknaphobia]

Thanks again for all the feedback on our latest developer preview. We’re circling back here to share some of the ideas that have been refined through discussion here as well as through live conversations with several of you. We’re breaking up the various topics into individual threads so that we can post updates more quickly and create a more focused discussion. We’re looking for your feedback to help mold the final product. In this thread, we want to dive into the online store editor sidebar and settings panels.

Making the Sidebar more condensed = less scrolling

We’ve been exploring a new UX design to streamline settings panels so they don’t take up as much screen real estate. On the left you can see what panels look like today and on the right is a concept of what those same panels could look like in the future. We are also exploring the possibility to specify which headers (and their corresponding settings) you want to be collapsed by default, so that you have a place to put more advanced settings without cluttering the screen on first load.

Conditional Settings

We are also very aware that merchants can be overwhelmed by the sheer number of settings. Our first step towards improving that experience is to introduce conditional settings so you can hide settings based on a variable or a conditional expression.

Similar to conditional app blocks, the available_if property expects a boolean value and will display the setting if true. In the below example, the opacity setting would not be displayed until an image has been selected.

{
  "type": "image_picker",
  "id": "image",
  "label": "Image"
}, 
{
  "type": "range",
  "id": "image_overlay_opacity",
  "label": "Image overlay opacity",
  "min": 0,
  "max": 100,
  "step": 10,
  "unit": "%",
  "default": 0,
  "available_if": "{{ section.settings.image != blank }}" // displays setting only if image selected
}

Thanks again for all your feedback, it means a lot. Keep in mind that everything we’re sharing is still early but it’s directionally where we’re thinking of going. So things might change in terms of exact syntax etc. but regardless we wanted to get the conversation going.

[PaulNewton]

If you don't have the real estate the vertically-condense can be horizontal-punishment, unless this all responsive.

IF IF you have the screen real estate the prototype is exactly what I'd expect in the here and now, nice.
Except for media/previewable/thumbnail etc settings as relying on the page load for higher fidelity makes the edit loop harsher as the pickers are postage stamps and so are the block-previews.

Really the epic want is gonna be for stylist control over settings density/arrangement.
Currently there are situations you have to uncompress what you've built using stuff like separators/headings to make sure something like a bunch of related checkboxes don't get misclick's by the fat fingered, those in a hurry, or those with mobility issues. Though conditionals are something that can make those situations even less frequent.

[PaulNewton]

While this is being worked on when someone does have the screen real-estate the right sidebar should be more noticeable when the chosen target changes. I've noticed a few times how it's confusing about why something doesn't have settings because they are all faaaar on the right side of their screen lol.

[adrocknaphobia]

Solid ideas. I've gotten tripped up a few times with the "faaaar on the right side" problem myself.

[WolfGreyDev]

Conditional settings is going to be huge. Anything that can reduce the amount of clutter in the settings is welcomed and a good stepping stone for accordion style groupings (if that's even a consideration at this time).

Side note: While we're talking about the sidebar, I can't be the only one who doesn't like that it's forced on the right. On my 13" MacBook Pro, I have to resize my browser window thinner so I can push it back on the left. Otherwise the preview viewport is around a tablet/md breakpoint size and never a true desktop/lg breakpoint size.

[dhruveonmars]

Huge news!!

Will we be able to add multiple conditions, eg {{ section.settings.image != blank }} && {{ section.settings.overlay_text != blank }}, or base of other values, eg products.metafields.some.item == 'value', or shop.address.country.iso_code == 'US'?

And can conditions come from other areas? ie a block setting, being able to look at section settings {{ section.settings.custom_layout }} or theme settings {{ settings.some_id == 'some_value' }}

Would entire blocks be able to available conditionally as well? Let's say for eg, we had a section, featured collections, and in one scenario, instead of displaying a list of collections, we wanted to display products from each collection under tabs. So in this case, when enabled, a new block becomes available to add/control the collection tabs style/layout/etc.

Would this only control the settings shown in the UI, and themes would still be responsible for controlling behaviour, ie in liquid would we be able to do if section.settings.image_overlay_opacity != 0 or would we still need to do if section.settings.image != blank and section.settings.image_overlay_opacity != 0 and previously added values would still be saved in the JSON?

[PaulNewton]

There is no && either in JSON or liquid, so if anything boolean conditions would be like this? 🤔

{{ section.settings.image != blank  and section.settings.overlay_text != blank }}

[PaulNewton]

would we still need to do if section.settings.image != blank and section.settings.image_overlay_opacity != 0

OS3.0 is gonna be a force multiplier on most current friction points in liquid like that.
available_if(enabled_if plz) making settings, or blocks, have clean existence/non-existence seems like a must. sans backwards compatibility issues of not saving settings 🤔.
Or were gonna end up with some crazy logic like class generation as an everyday thing.

---

More better if sections, or blocks, have access to all block-children's existence/properties without having to use conditional checks or hacks as that could soften the burden of changing the layout of containers with classes, or generating grid styles, due to shifting block nesting combinations.

💩 dirty syntax for examples sake: <section>....<slide class="grid-item {{ blocks[column-1].settings.class_name }}>

[bakura10]

Thanks a lot for the info. Here are a few feedbacks:

• Conditional settings are awesome. I'm also super happy that it supports actual Liquid condition and not just on boolean attribute (like app blocks). It is not 100% clear from the example, but can you please confirm it will work also for conditions like this:

"available_if": "{{ section.settings.layout == 'grid' }}"

We have a lot of such patterns in our themes.

• For the new layout, this is a welcome change, especially for images and color schemes that always took too much space. However, I am not convinced on the two columns layout. There are two issues I see:

• There are a lot of settings label wording that we've adapted to fit just one line. Most of them will end up into two columns.
• Similarily, there are a lot of select settings labels that we have adjusted to ensure that they can be shown using this easier-to-use picker rather than the select (which requires more clicks). By making them two columns, for sure most of our select options will look again as plain select.

[clauderic]

We're aiming for conditions like "available_if": "{{ section.settings.layout == 'grid' }}" to be possible yes. We may initially limit the context you have access to, current thinking is we would limit access to only the block, section and theme setting values, but this is something that could be expanded on in the future.

[PaulNewton]

available_if should be allow_if, display_if, enabled_if, render_if, show_if , etc
"available" should be kept reserved in the liquid inventory syntax because that whole system creates enough confusion as is without verbiage overlapping internal theme settings terminology in forums or googling.

enabled_if would probably have resistance because of the long ago short term decision to use "disabled" etc for visibility toggling in the settings panel.

[PaulNewton]

If blocks also have an existence setting would they also be able to use the existence of block-children {{ block.blocks['image'].count }}
Or block-peers in setting conditions or other: {{ block.parent.peers.count }} , {{ block.parent.blocks['image'].count }}

For example an image block able to check if other image blocks already exist in the same level to reveal additional settings/presets.
Because that would be wild, helping streamline future settings and things like continuing to use css column grid systems; i.e. .col-4 vs col-12.
In the current state I think exposing such additional peer-based/advanced settings "conditionally" means either making the condition check done with a higher up section setting: "available_if": "{{ section.settings.show_advanced_options }}"
which is still miles awaaay better than we have now but a user still HAS to KNOW to enable such a thing which is the thinking burden we want to get rid of
Alternatively , possibly a dedicated block that is a variant of the image block with more settings but someone again has to "just know" when to use such a thing.
Or a sub-block that contains only advanced-settings activated with "available_if": "{{ block.parent_block.settings.show_advanced_options }}" , "available_if": "{{ block.parent.available }}", section settings, etc which also has no idea of it's parents peers unless peers object access was a thing {{ blocks.parent.peers.count }} .

[jdunham2]

{{ block.parent.peers.count }} , {{ block.parent.blocks['image'].count }}

Seconding this... Being able to use parent and target nested blocks by name or id would be amazing.

[mattvague]

@adrocknaphobia love love love the conditional settings, will hopefully solve a lot of problems and make the merchant experience a lot better.

I have to say I'm a bit confused by the syntax though. It sort of looks like standard liquid with the {{ }} delimiters, but AFAIK {{ section.settings.image != blank }} isn't actually valid liquid (i.e. if I output that on the page right now it won't output "true" or "false"). I obviously have no idea how you're implementing this, but it feels confusing to have a whole new syntax here that looks sort of like liquid but doesn't actually work the same way.

My feeling is that having the value of available_if parsed with standard liquid would be more natural, and also a lot more powerful.

e.g.

"available_if": "{% if section.settings.image != blank %}true{% endif %}"

or multiple conditions:

"available_if": "{% if section.settings.image != blank  and section.settings.overlay_text != blank  %}true{% endif %}"

or else branches:

"available_if": "{% if section.settings.image != blank %}true{% elsif section.settings.product !== blank and section.settings.product.image !== blank %}true{%else%}false{% endif %}"

You might object that "available_if": "{{ section.settings.image != blank }}" is more readable and less verbose. I would agree with you on that, but I would vastly prefer the power and lack of learning curve of just being able to write standard liquid here instead. Not sure if that's possible, but just my 2 cents.

Love that you guys are thinking in public like this and are gathering early feedback, excited to see how this turns out.

Have a great day!

[willbroderick]

This is cool to see! Just a few comments that come to mind:

I can't see the short labels working. It wouldn't pass the German test - for example Dawn uses "Hintergrundfarbverlauf" for a background gradient, which wouldn't fit.

The image, video, and color scheme selectors could be a lot smaller than they currently are. I love the idea of replacing those with smaller options. Being able to see the aspect-ratio of the image is really useful - if it could still 'contain' that'd be great.

There is no way I would be able to use those padding sliders with a mouse! I really think those need to span the full width of the bar.

[ceri-waterscreative]

So excited for conditional settings, I need it like yesterday 😅

[jonneryd]

This might be a bit late, but I’m excited about the conditional settings feature.

Accordion for Organizing Schema Settings

One idea is to implement accordions / dropdowns similar to the current custom CSS feature at the section level. Essentially, this would introduce a new "accordion" type (just like the current "header") that easily distinguishes, for example, between desktop and mobile settings.

Example:

{
  "type": "accordion",
  "content": "Mobile Settings",
  "info": "These adjustments only affect mobile.",
  "settings": {
    // The settings contained in the accordion defined here as usual
  }
}

Current Custom CSS Example

This accordion would work much like the current custom CSS accordion.

Or even better: Conditional visibility based on editor breakpoint

It would be awesome if conditional settings could reference the current editor breakpoint. For instance:

{
  "type": "style.size_panel",
  "id": "size_mobile",
  "label": "Size (Mobile)",
  "default": {
    "width": "25%",
    "height": "auto"
  },
  "available_if": {% if editor.breakpoint == "mobile" %} // or the appropriate syntax to access the current breakpoint
}

This setting would only appear when the theme editor is in mobile breakpoint.

While this might be beyond the scope of the current preview, I believe it would make the sidebar much easier for merchants to navigate and making themes less intimidating and more straightforward.

[PaulNewton]

upvoted but editor.breakpoint would need to be more agnostic ala request.design_mode ~= request.design_mode_small or request.visual_preview_mode ~= request.visual_preview_mode_mobile etc.
A strict breakpoint is problematic as dictating a fixed breakpoint creates a chilling effect a fixed requirement on theme designers having to design around.

Mobile configurator confusion

Breakpoint conditions, design conditionals layout conditionals, seem more an idea by developers for developers, not for merchants.
When a merchant clicks into a section/block ALL settings should show that may apply to that section/block, free of design context.
If they are in a mobile context when the click into a content, suddenly a lot of settings are missing or veeery different.

Having two or more collections of settings that are defacto separate due to conditional breakpoint(s) may feel like a good idea but in practice we only need the experience of merchants NOW that get confused with settings, design based conditions will create more confusion for merchants by burying configurations within other configurations within other configurations.
Add in market-contexts and alternate templates, etc and this quickly sprawls out of control.

Possibly a version of the layout switcher needs be at the top of settings that have layout based conditions /shrug
Similar to the header (or an option of it), to quickly flip filter to mobile specific settings. And that this filter is tied to toggling between desktop and mobile views in the preview frame.
IDK, the main thing is to increase merchants awareness they are or can be in that context so the merchant is made of aware of the condition at some level to avoid confusion about settings that suddenly go missing.
Before even having to touch or have eyes on the main layout switcher in the upper right; on the entire other side of the screen for some viewport sizes /shrug.

[jonneryd]

Thanks for the detailed feedback. I now see the issues with my earlier approach.

I really like the idea of adding a layout/context switcher at the top of the sidebar, directly tied to the header’s layout switcher. This not only clears up the hidden settings problem in mobile contexts but might also nudge theme developers to optimise for mobile without adding extra complexity for merchants. Great call!

I guess this would mean tagging all current setting types, or would we need a new settings array (like a settings_mobile) in the section/block schema?

[PaulNewton]

Maybe such switch/filter is only needed when settings are in the left side bar opposite the main switcher.

I did mean all this in the context your suggestion of available_if using some property of the editor as a condition of the layout type/context to narrow down the settings being shown ; just not explicit pixel size set in stone by shopify*
So I don't think having to tag everything is how they should do it , yet without that leads to a logic problem if trying to show all settings at the start:
open a section/block the first time means all setting show which means a hypothetical request.design_mode_small is true?
But then switching to mobile layout also means request.design_mode_small would still be true.
There's a logic issue there, could just be based on how I'm naming things in this hypothetical, small or mobile alone are probably the wrong words.
request.design_mode_small_settings_available?
desktop layout == request.design_mode_small_settings_available == true == all setting shows
mobile layout == request.design_mode_small_settings_available == true == only mobile settings show ala overrides
or request.design_mode_all_settings? but then how to you flip it.
/shrug.

*if settable by the developer that's fine and a completely different thing but meta issues is we currently can't explicitly set the width of the preview area; for mobile ,desktop, tablet or ranges.

[PaulNewton]

Meta

This type of thing trickles back up to how we currently have to do things when a section needs to be drastically different between desktop and mobile. Where we have to make two sections using responsive media queries, or js, to show and hide one specific sections for desktop vs mobile; or outright customize all section settings in a theme to have a responsive CSS toggle.

Which can get crazy confusing for merchants, staff or vendors.
Further compounded by the fact of yet another meta issue being we can't explicitly rename/relabel sections arbitrarily in the editor for custom organization.

[PaulNewton]

We can now rename blocks and sections in the visual theme editor
https://changelog.shopify.com/posts/rename-blocks-and-sections-in-the-online-store-editor

[selastingeorge]

@lujostack , Is this currently available in beta? I was building a theme from scratch but unable to make visible_if work, It keeps giving me error.

Invalid schema: setting with id="marquee_speed" visible_if is invalid

{% schema %}
{
  "name": "Announcement bar",
  "limit": 1,
  "settings": [
    {
      "type": "select",
      "id": "type",
      "label": "Type",
      "options": [
        {
          "value": "static",
          "label": "Static"
        },
        {
          "value": "marquee",
          "label": "Marquee"
        },
        {
          "value": "carousel",
          "label": "Carousel"
        }
      ],
      "default": "static"
    },
    {
      "type": "header",
      "content": "Marquee Settings",
      "info": "Customize speed, text and transition timing for marquee effect"
    },
    {
      "type": "range",
      "id": "marquee_speed",
      "label": "Speed",
      "default": 5,
      "min": 1,
      "max": 10,
      "visible_if": "{% if section.settings.type == 'marquee' %}"
    },
    {
      "type": "color_scheme",
      "id": "color_scheme",
      "label": "Color Scheme",
      "default": "scheme-1"
    }
  ],
  "presets": [
    {
      "name": "Announcement Bar"
    }
  ],
  "enabled_on": {
    "groups": ["header"]
  }
}
{% endschema %}

[jonneryd]

Conditional visibility settings are currently not available. This is only a discussion about the dev preview, not actual implemented features.

[selastingeorge]

Thank you @lujostack , In the vs code extension it actually recognizes the visible_if key in the schema.

[jonneryd]

They've added the theme validation for it, but it's not implemented other than that. Here is the commit.

[selastingeorge]

Hope it would release soon :)

[adviewmx]

Don't work for me

with visible_if (this attribute is in the autocomplete in vscode)

• Invalid block 'slide_image': setting with id="img_link" visible_if no es válido.

with available_if

• Invalid schema: setting with id="loop" 'available_if' is not a valid attribute

[efekurnaz]

Conditional visibility settings are currently not available. This is only a discussion about the dev preview, not actual implemented features.

[adviewmx]

I got excited ahead of time, hopefully it will be available soon, it would help a lot to have a cleaner editor

Conditional visibility settings are currently not available. This is only a discussion about the dev preview, not actual implemented features.

[stephanie-shopify]

Hi all, Conditional settings are live. https://shopify.dev/docs/storefronts/themes/architecture/settings#conditional-settings Have a great weekend!

@adviewmx @efekurnaz @selastingeorge

[bakura10]

Nope, as always with most new features, they are not supported in app blocks (nested snippets, inline_asset_content, conditional settings...). This create an extremely bad dev user experience, it's the same tech, same language, so we should expect to all the features be available everywhere.

[willbroderick]

Can we get support in the theme submission zip validator, so we can submit themes to the theme store that use this? Would love to make the new-theme-install onboarding experience simpler using this.

[PaulNewton]

Example error when trying to use visible_if in an app-embed block
Error while updating drafts: [blocks/dev_party_button.liquid] Invalid tag 'schema': settings: with id="power_mode" visible_if is invalid

{
  "name": "Party",
  "target": "body",
  "javascript": "dev-party-button.js",
  "settings": [
    { "id":"dev_mode", "type": "checkbox", "label": "Enable dev options" },
    { "id":"power_mode", "type": "checkbox", "label": "Enable power options", "visible_if": "{{ block.settings.dev_mode == true }}" }
  ]

Same for {{ block.settings.dev_mode }} , to replicate i'm adding the json to the app-embed code from the theme-extensions repo ; with some file-renamespacing.

Error message is confusing as something like available_if gets a clear "not a valid attribute" error in the shopify-cli.
Error while updating drafts: [blocks/dev_party_button.liquid] Invalid tag 'schema': settings: with id="power_mode" 'available_if' is not a valid attribute
So it makes it seem like there simply is a value typo when using visible_if even if you use the example expression out of the conditional setting docs ; including adding the separate layout_style setting to try and account for missing value sources
i.e. "visible_if": "{{ block.settings.layout_style == 'flex' }}"

Every other feature is half-baked , the annoying thing about the platform who cried shipped is responsible people still have to take it seriously each time and do the testing just to prove it's not even there.

[binarymonkey84]

A bit sad that I only found out about this via somebody else posting on LinkedIn, though!

It wasn't posted in either of the official changelogs below:

• https://shopify.dev/changelog
• https://changelog.shopify.com/

Is there something else I need to monitor to get notifications of all changes at the time they happen?

[mdamjanic7]

@binarymonkey84 You are monitoring the right links. The changelog post went live yesterday.

It's just that some folks discovered visible_if before we were ready to announce it.

[mohamedhaddi]

Any plans to add conditional sections and conditional blocks in the future? (similar to "available_if" for conditional app blocks)

[WolfGreyDev]

visible_if on "type": "header" settings in blocks and sections work as expected, but this behavior doesn't work with settings from the config_schema.json. Is there any reason behind this?

[mxstbr]

Conditional Settings should work in theme settings. If you have a case where they don't that's a bug! If so, you post your whole config/settings_schema.json? Thank you.

[mxstbr]

Going to close this discussion as we've introduced this feature. Please open new discussions for follow-up requests!

[bakura10]

For reference, it has recently been added to theme extension (app block), but the feature has been forgotten on app embed, creating a quite inconsistent experience. It would be nice if this feature could work consistently on all surfaces.

[anastis]

It appears that visible_if doesn't work for "type": "link_list" settings.
POC:

{
  "type": "link_list",
  "id": "test_link_list",
  "label": "Just a test",
  "visible_if": "{{ false }}"
}

Other types seem to work just fine.