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 }} .

[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.