-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Help text to Custom Liquid Section + Block #299
Comments
Support copy drafts v1 longer explanation; upgrade path more insider/jargony v2 shorter, upgrade path explained more simply v3 a combination Additional copy changes
|
Thanks @gretchen-willenberg. I think introducing the concept of the upgrade path might be a bit TMI in this context so I would stick to a spin off version of your V1:
What do you think? |
True. Cool with the first sentence. Can I stubbornly hang onto
|
Aligned on |
@gretchen-willenberg Neither are currently good Learn more or Learn about liquid pointing to just the top level liquid reference is not suitable to inform merchants about how to use this liquid setting type and it's limitations. Merchants looking to add a little flexibility just need an understandable resource to give them context of what this thing can do , like adding themselves as vendor* or showing another feature image to pages before they get punted to the much broader and complex areas of the liquid ref , the customization tutorials, or try to use code from places like partners code snippets and not understand why some code errors out (it has The findable resources on the topic of liquid settings leave much to be desired as well
And the main doc about this new setting type is for implementers not end users : https://shopify.dev/themes/architecture/settings/input-settings#liquid * |
@nicklepine Future - Down the line IF shopify support resources grow for this , such as a premade list of snippets, will probably want to swap "advanced" to be "basic or advanced" aligning with support policy 🤷 |
Doesn't this create a UX exception, which other keyboard entry settings have a behavior of not having a placeholder? (pickers don't count) Looking at things like RTE text settings we get:
In the above the placeholder text explains some general usages and importantly makes it a pain point if the user DOESN'T edit it , getting users to either delete all the text or start editing the text more immediately seeing results on the page. Also placeholders make it clearer visually where an output will be. I think the issue is finding a general case placeholder that is short, explanatory and contains text&liquid&html code that instantly encourages change and exploration because it's undesirable to leave it alone. 😫 It should be some short overally generally usable liquid code so it's more explanatory insitu regardless of page|resource context.
And probably should try to avoid objects that may not exist during a store setup like description 🤷 , though it could be argued request.design_mode could be used to link the merchant to the admin to edit that field probably best not to encourage that route logic in sections. In this context I think the two below examples are actually bad because they immediately fulfill a too specific need.
and updating the policies snippet from the liquid docs to have links
💣 Both are broken when a store doesn't have those things available yet, in others not having payment methods or no polices entered in the admin results in bad placeholder output. So placeholders like that would need guards {% if shop.policies.size > 0 %} overcomplicating things for a liquid placeholder by having conditions AND loops. Liquid setting is a lowkey gamechanger for the theme customizations part of the ecosystem and probably will be my favorite feature of OS2 even though it basically loses me work! And I'd wager it will be a merchant favorite too once it's capability is more well known.. soooo getting the first touch experience tuned of the liquid-setting-type in the reference theme seems important for longterm merchant pedagogy making themes even more flexible. Aside: policies example code also points out a problem that snippets in the liquid ref will get used for this feature but not all of them are functionally complete i.e. the shop.policies snippet does not generate urls_ |
There is an existing link that, from what I can see, is there by default based on the type of the setting ( As for the text to add, we could link to different resource or ommit the |
Good flag @ludoboludo Then let's keep the existing Liquid link coming from the liquid setting in editor, and ditch the learn more in the additional help text ( was intended to link to the same place). So the paragraph to add is simply: cc: @gretchen-willenberg I think Paul's suggestion is a good one, to put emphasis on the Liquid code rather than apps - given we also have the separate concept of app blocks in the theme. |
Relates to: #42
Describe the enhancement you'd like
We have an opportunity to better inform merchants on the usecases in which they add an custom liquid section:
@gretchen-willenberg Could you help come up with copy for this?
The text was updated successfully, but these errors were encountered: