Replies: 29 comments 86 replies
-
WebflowpifyI completely agree with Michaël from Maestrooo! In addition all of this appears to be pointless because, according to personal research, 98% of merchants use 99% of the original theme designs they purchase, with probably only 1% going beyond that and hiring a Shopify developers to make the necessary alterations for them and another 1% which creates the ugliest and most unusable user unfriendly design known to mankind. The Tailwind-inspired class names will haunt me for the rest of my life btw. |
Beta Was this translation helpful? Give feedback.
-
|
Also, now that you will be demanding an 18% fee on theme sales, it won't be easy for partners to scale their teams to implement all of this and rewrite entire themes from scratch to work with this new Webflowify concept. |
Beta Was this translation helpful? Give feedback.
-
I do customizations, so according to personal research almost 100% of merchants customize themes /s |
Beta Was this translation helpful? Give feedback.
-
|
The new version is notably more complex to navigate and I personally find it unnecessary. I agree with your perspective that customers seldom require extensive modifications to the original theme design, typically preferring to utilize available features and settings. Moreover, upgrading between the old and new versions would undoubtedly be both time-consuming and labor-intensive. |
Beta Was this translation helpful? Give feedback.
-
There's a usage bias in there that anyone dealing with theme support burdens must be cautious in assuming will always be true. Currently "extensive" modifications(code edits) are difficult because of liquid's increased clunkiness, restrictive setting types, lackluster 1P tooling, along with poor merchant education & surfacing of features like custom-liquid settings, etc etc etc. Nestable blocks change the paradigm enough that "extensive modifications" could become as common an expectation as how merchants currently add or remove a section with a few clicks in the visual-editor. * |
Beta Was this translation helpful? Give feedback.
-
|
Just going off the suggestion of using something like |
Beta Was this translation helpful? Give feedback.
-
|
hells no, i don't want tailwind in my life |
Beta Was this translation helpful? Give feedback.
-
|
Any talk of tailwind et al. as a built in feature is a foot gun for devs, support and merchants. But it is REALLY good for the cottage industry of customizing, fixing or repairing themes due to unnecessary complexity. |
Beta Was this translation helpful? Give feedback.
-
|
This is super complexe indeed, I find the current implimentation super complexe for merchant which will create incosistencies especialy after adding an extra layer of the breakpoints. |
Beta Was this translation helpful? Give feedback.
-
Great feedback. I can totally see where this level of flexibility being given to merchants could be concerning, but @tbqmax mentioned, many merchants just use themes as-is and will probably not interact with these settings very much. Something to keep in mind is that, while these are merchant facing features, theme blocks and style settings are also theme development tools. They are designed to allow the theme developer to use less code, reuse blocks, and write less CSS to accomplish things in Themes. We are definitely keeping an eye on how unwieldy it is to build out themes (and for merchants to customize them) with the current feature set and are going to be rolling out improvements to let merchants create more cohesive designs. We don't have any real details to share on that front yet, but think of things along the lines of being able to reuse values for similar settings between blocks and sections as one possible option to sort of "lock in" a grid system of some sort. |
Beta Was this translation helpful? Give feedback.
-
|
You are doing it the opposite way, then. You are giving the maximum flexibility first (and hence locking yourself and locking theme dev in something that you will need to support forever). Introduce first new, more specialized settings like the |
Beta Was this translation helpful? Give feedback.
-
|
i'm on team give me all the flexibility because i've been asking for this very thing for the last 7 years now. |
Beta Was this translation helpful? Give feedback.
-
Resilience > Flexibility |
Beta Was this translation helpful? Give feedback.
-
Then as a speed-bump for support burdens if most merchants don't use settings maybe there should be no problem putting an opt-in safety in the path of those that do go further* Have public stats on current merchant behavior and woes instead of anecdotes would be amazing. *I've always wanted something like this for features like slideshows to have a danger warning persuading merchants to use hero-image sections instead or get educated on usage of that UI but missed when dawn go slideshow to bring it up. |
Beta Was this translation helpful? Give feedback.
-
I'm extremely skeptical of "less-code" actually being less code, or it shifts burdens elsewhere, unless there's substantial changes to the DX experience being in lockstep with new features. Historically shopify's tooling for authoring architecture features has never ever been in the realm of a first class experience*. |
Beta Was this translation helpful? Give feedback.
-
Upgrades are an ongoing struggle for ourselves and our partners and we are constantly trying to improve the experience for merchants and theme developers. Like with any theme upgrade where blocks are changed, the ID or type of a setting changes, etc... , a manual upgrade will be required for merchants to change to a theme that moves from today's settings to Style settings. That said, theme developers do have the choice of switching to using Style Settings for existing themes. We will be sure to update our theme partners when we do make improvements to theme upgrades in the future - it's something we are always looking at and hoping to improve bit by bit. |
Beta Was this translation helpful? Give feedback.
-
|
A heavy source of friction for manual upgrades is no automatic way to get the original version of any theme. 😮💨 , Diff'ing still generally requires diff software, and a dev to use efficiently, but with the github integration and an original theme it's not impossible to see a way to a more approachable workflow since github has a good web based UI for diffs. |
Beta Was this translation helpful? Give feedback.
-
This is a really interesting idea. cc @clauderic can fill in a bit more detail on why we went with the approach we did and whether or not we see a world where we use more generic classes like you showed here. |
Beta Was this translation helpful? Give feedback.
-
|
Slightly related so thought I'd mention here, I also had some thoughts on just being able to access CSS variables directly: |
Beta Was this translation helpful? Give feedback.
-
Since the layout settings apply It's just the nature of Flexbox, though I can see how it might feel unintuitive from a merchant's perspective. Our goal is to give theme developers and merchants as much of the power of Flexbox as we reasonably can, and a side-effect of that is them needing to learn how these blocks behave when certain settings are enabled (wrap v.s. no-wrap, etc...) |
Beta Was this translation helpful? Give feedback.
-
|
What about grid controls? Or custom style settings? |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so you are expecting merchants to understand how flex, shrink, wrapping... works. If I was confused by a width: 65% being smaller than its sibling, merchant will do as well. This is not Webflow, most merchants have zero understanding of this (and don't want to invest time on understanding the technical aspects). They want something that look good with minimal effort. This is the direction we have been going for years at Maestrooo, trying to simplify our sections, take decisions for the merchants on how it will look at each breakpoints, at introducing global theme settings to adjust spacing, style... at the global level (change once, have the whole site adapt without having to re-adjust every possible sections). This works well, and this should be the direction the theme editor is going. |
Beta Was this translation helpful? Give feedback.
-
|
I was going to write exactly as Michaël said. A vast majority of merchants are way beyond these concepts. Even among the front-end community, flex is not understood. Even back-end developers not being able to center a div is not just a joke, it's reality. We're entering tech-savy territory, not really in line with the "build for entrepreneurs" narrative in my opinion. A decent deal of my time is explaining metafield/metaobject capabilities and how to use them, we're at this level of competence on the other side, but at least for this one as well as for Flows, there is a real value for them to understand it ! For flex-box, I'm sorry but they do not. Don't lose the entrepreneur audience with 165% width reduced to 100% due to flex-box specification, please. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly you’re already going to confuse everyone by calling this blocks. we already have blocks. but now sections inside sections are also going to be called blocks. |
Beta Was this translation helpful? Give feedback.
-
Maybe for devs , however I don't think that's a reasonable expectation to ever have for merchants. |
Beta Was this translation helpful? Give feedback.
-
I would argue that whether or not this is used by merchants is somewhat irrelevant to how much of a point this feature has. There are two sides to it. It is both a merchant facing feature and a theme developer tool. It allows us to use the same |
Beta Was this translation helpful? Give feedback.
-
|
Thank you everyone for your feedback! |
Beta Was this translation helpful? Give feedback.
-
|
appreciate you for answering all the questions! thanks. |
Beta Was this translation helpful? Give feedback.
-
There appears to be a significant disconnect here. The core purpose of theme development is, fundamentally, development. While I may be in an echo chamber, my understanding is that developers generally want Shopify to reduce its involvement in rendering cycles and overall storefront handling, particularly concerning CFH (content_for_header), which currently overrides native methods. If anything, these base styles would likely result in more overrides and workarounds, not less code as suggested. Maybe consider Control vs. Convenience - while Shopify aims to simplify development, developers often prefer granular control over their code and themes. Your response assumes that less code is always better, but this ignores the value of custom, optimized solutions.
By limiting developer control, Shopify is creating a paradoxical situation. On one hand, you want to give more power to users, but on the other, Shopify is restricting the very people (developers) who are best equipped to harness that power effectively. This approach forces merchants to grapple with complex layout concepts they shouldn't need to understand, while simultaneously hamstringing developers who could create more efficient, customized solutions. The result is likely to be increased complexity for merchants, reduced flexibility for developers, and an overall decrease in the quality and consistency of store designs. This misalignment has the foundations to compromise the end-user experience and the platform's effectiveness. Relating to the proposed logicSo, let me get this straight.... Shopify generates an external CSS file, injects and renders it in via CFH and then applies a The tactic proposed here also has performance implications while flaunting no fail-safe for custom applied logic. Shopify already has redundant injections that developers are unable to control due to the restrictions that CFH imposes. Also, the Tailwind inspired syntactics are not a good look. Let's just quickly go over some very low-level nuances here. There are far more, but let's just scratch the surface. Specificity and cascade issuesShopify generating both external and inline styles, there's a risk of specificity conflicts. Inline styles typically have higher specificity than external stylesheets, how is Shopify going to isolate this. Reduced optimization opportunitiesRemoving control from the developer, Shopify limits opportunities for advanced CSS optimizations. Inconsistent ExperiencesCustom webshops often require nuanced responsive designs. How can Shopify adequately handle complex responsive layouts or breakpoints, without leading to inconsistent experiences? It's impossible to predict nuances in procedural declarative languages like CSS. Debugging complexityCSS coming from multiple sources (custom code, Shopify-generated external file, and inline styles), debugging becomes significantly more complex. This "enhancement" is just concerning tbh. This is not webflow or wix. Theme development exists in isolation, it has garnered careers and produced specialization. This updates ignores what Shopify developers, theme publishers and this small community has worked to establish. Do better. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly this feels like a lot of extra work just let theme developers create nested settings with global blocks/components |
Beta Was this translation helpful? Give feedback.
-
|
It has been mentioned that it's not a requirement for the theme store... (Let's see how it goes👀) |
Beta Was this translation helpful? Give feedback.
-
|
I don't think you can beat webflow by copying webflow. I don't want to be overly critical because it's clear that something like this is needed within Shopify themes. This would be very useful for one-off landing pages and the type of content that page-builder apps are used to create now. It's great as a limited-set design system for AI prompting. This has many uses. You'll be able to tell the design was crafted with blunted tools, but sometimes that's ok. That said, it's a blunted tool. We still need a version of nested blocks that isn't limited to a small subset of CSS. I hope that is also in the works. |
Beta Was this translation helpful? Give feedback.
-
|
@haroldao Do you really believe that once these features are implemented into Dawn, merchants using your paid theme won't question why it lacks features available in free themes? Even if they don't need or use those features, they'll expect your paid theme to have them just because Dawn does. Additionally, we all know the ultimate goal here is to enable Sidekick (Shopify AI) to make layout changes and customize themes. Just like with NFTs, they've jumped on the AI hype wagon again. So, while it may not be mandatory initially, it will be down the line. However, long before that, merchants and competitors will have already forced you to implement these features. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I know... that why I said we'll see. Regarding your first sentence, I know exactly what to say to a merchant that asks why a setting/feature available in a free theme is not available in my theme...👀 |
Beta Was this translation helpful? Give feedback.
-
|
I could not agree more with all the comments that have been done. @tyleralsbury theme blocks are a great idea, and the addition of static blocks and block restriction is a step in the right direction. It will allow us to create more generic blocks, reuse them across themes, and only bother with styles. On the other hand, all those new style settings introduce so much complexity, and this does not align at all with what merchants are asking us at support. I'm not saying this is bad per so, but just that it should not be part of the theme editor itself. Apps like Instant HQ can do that very well, but in my opinion, they are trying to solve a different problem than what themes are solving. Give such tools the API to do it even better, and keep the theme editor for the mass as optimal as possible. I understand as well that those new settings are completely optional, but you know as much as I do that Dawn is going to adopt them everywhere, on every single block (this is the direction Shopify has been taking by adding a ton of settings to Dawn, which ends up being a highly complex and hard-to-configure theme). All themes will have to follow if they want to survive (even if merchants won't use it, they will constantly ask us why a free theme has theme but not a paid theme). A better direction, in my opinion, would be to introduce some more specific settings to offer a better editing experience (similar to the recent "text_alignment" setting), but ultimately leave the development concern to the theme. Here are a few ideas:
I'm simply not understand the target of this:
At the end you will end up with an extremely complex stuff that you will need to maintain forever, for a use case that seems, in our experience, pretty minimal. Oh, and please remove the idea of the breakpoint stuff. This is useless and will just cause a lot of confusion and extra support debt. We never had such requests from merchants, so I'm not sure where this idea is coming from. Finally, I think this is another perfect example of a lack of communication with partners (and especially Theme Partners). You guys went all in in a direction that is clearly unpopular, did a lot of implementation work, without even asking us what we would think of it, and if it indeed aligns with actual merchant's demand. |
Beta Was this translation helpful? Give feedback.
-
|
Well said. This feature and the majority of OS~3 "features" for that matter appear to stem from a lack of deep understanding and experience within the theme development ecosystem. I'm pressed to find a SWE with above novice knowledge that doesn't consider this a bad idea and the dozen or so I've spoken with are far from impressed with the direction. It seems that those working on these features are not grasping that theme development is its own distinct paradigm with unique challenges and requirements, it's wild that there is so little awareness exhibited, just blatant forms of ignorance at this point. The strategy and the practical realities are lacking and based on the responses in this discussion thus far, I'm not seeing a willingness to divest but instead a steadfast attitude, more concerned about arguing the benefits (if you can even call them that). The bottom line here is that the approach fails to recognize the nuanced needs of developers and the complexities involved. The Tailwind flavoured syntactics suggests superficial adaptation of external influences - novice level ideas. I admire your patience and consideration @bakura10 but imo this shouldn't even be an optional enhancement and if there were more proactive developers in this discussion, I'm willing to bet they'd all align with those of us airing concerns. To add to your point about the lack of communication: This issue is glaringly apparent. Rather than leveraging the expertise of seasoned developers who have spent years in this field — professionals who have deeply considered various implementation strategies and potential improvements. Shopify seems to prefer waiting for bug reports. It's a shortsighted strategy that undervalues the insights of the very community they're meant to serve. |
Beta Was this translation helpful? Give feedback.
-
@bakura10 Maybe that's that then, enabling theme settings should be an opt-in, a hurdle requiring an app install ala search & discovery.
/s When asked about themeborefest kitchen sink themes I say a garbage dump has everything you could ever want but you'd never want to live there. Of course support can't really say such truths to customers they have to wait for the merchant to experience it themselves. /s
Marketing copy, visuals in ads, possibly AI assisted designs; encouraging moving to headless, things that poll well in corporate circles. |
Beta Was this translation helpful? Give feedback.
-
|
The big issue here is that the Dawn/Webflowpify team is stuck in their own little world. And unfortunately from what I can see you are the ones pushing out these new features left and right without really getting what the rest of us, theme developers and merchants alike actually need. Trust me, none of us are itching for Shopify to have more say in how we design and build our themes. Bakura makes a valid point about focusing on "introducing more specific settings to offer a better editing experience (similar to the recent 'text_alignment' setting)." This approach could be more beneficial and align better with developer needs as well as those of the majority of Merchants. Shopify's already bloating our sites with a bunch of unoptimized JS files nobody asked for. If you now start doing the same with CSS, we're done. I think that's one of the reasons some decide to go the Headless road, lol. Honestly, if the team behind this just stepped out of their bubble and did some real-world research, they'd see that merchants usually play it safe. They go for professionally designed stuff because they know it works. Maybe it's time to let the developers do their job without all the micromanaging. The only good thing I see here is that this time you are at least asking for some feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Correct. Echoing the pain points with CFH. Few weeks ago now those running storefront logic shipped an update in trekkie that hijacked the native XHR method and set async to Meanwhile, Cirque du Solei is up in here with remarks like:
As I stated in previous comments, this statement showcases a profound disconnect from the community's perspective and a general lack of basic awareness in this nexus. Their solution demonstrates a lack of concise thinking. The disparity between these actions and the needs of both developers and merchants is stark. It's truly astounding to see such a misaligned approach, not to worry though, they've got it under control. Just bloat CFH more and try wrangle a procedural declarative language like CSS. WILD |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with what @bakura10 and @panoply previously said. This feature doesn't add much except complexity and confusion. I also saw in the documentation "Style input settings (coming soon)" with the following description:
Is the next step to have different content by breakpoint, maybe I'm wrong ? |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to chime in with a dissenting positive opinion here. I maintain around 100 stores for an agency, all centralized on a single custom theme. This theme is spun up, given initial design values and then handed off to account managers for maintenance. Because my "base" theme needs maximum flexibility, I've been home-spinning section style blocks myself by merging common JSON schema into each section (and even more complex strategies). Each section needs color theming, spacing, text, and other settings, and some settings are breakpoint specific. This is taxing to develop, use and maintain, and the section settings are almost unreadable. I understand that theme store developers are seeing a shift towards over-customizability, something their customers don't really ask for, and that doesn't accomplish much. Even though the feature is optional, I get that customers get accustomed to these tweaking settings once Shopify introduces them, and that's frustrating for developing off-the-shelf themes. That said, there are quite a few developers supporting a lot of stores or large stores rather than developing themes for sale. If they are like me, this feature will be a short burst of pain to roll out followed by a whole lot of no-brainer benefit. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely agree @evankford. While its great to have the ability to write custom code, its also challenging to find quality developers. As an agency, we have been moving more and more away from custom building and even towards having our non technical people work on the sites in the customizer since this is the cheapest and fastest way to build out the designs to a reasonable degree for most clients. Granted there are some rockstar programmers on here (panoply for example) that can probably code faster than most of us with his eyes closed and don't want or need this type of control in the customizer. But for companies like us that don't have access to developers like him and are struggling to find solid programmers who work on shopify to produce new sections very quickly, this concept is a great leap forward with much less custom code needed (which means much less potential bugs). |
Beta Was this translation helpful? Give feedback.
-
|
@eballeste, yes the styles features are fully opt-in |
Beta Was this translation helpful? Give feedback.
-
|
@stephanie-shopify any chance we could get similar settings but for our own design tokens? I love the input layout, but giving pixel-specific control to our clients will quickly bring inconsistency in our custom designed themes. |
Beta Was this translation helpful? Give feedback.
-
|
@wiebekaai maybe style-settings-blocks?
Part of this I think is how when adding a new block, just like a section, the settings automatically open so it's intuitive to start changing settings. If a style-settings-blocks work around is possible that means there is at least some method to add an extra hurdle merchants would have to consciously opt-in with to get access to advanced pixel nudging behaviors. % schema %}
{
"name": "Add advanced styles",
"label": "These styles are advanced customizations and are not supported, please see our design policy",
"settings": [
{
"type": "style.spacing_panel",
"id": "spacing",
"label": "Spacing",
"default": {
"padding": "0"
}
},
...*static block rendering: ** are we calling non-static blocks 'dynamic'? |
Beta Was this translation helpful? Give feedback.
-
|
@PaulNewton using a block to share styles is an interesting idea. It does feel like a workaround though. Having a good way to create shared and conditional settings would allow the customization I want. On top of that having the styling panel type of inputs would be a nice to have. I'd prefer to handle the styling myself, with CSS variables and/or TailwindCSS. I guess this could work #41 One of the use cases is a padding-bottom and padding-top setting that we implement for all sections with the same preset values available (S/M/L/XL). |
Beta Was this translation helpful? Give feedback.
-
|
While I can see the goal for Style Settings and acknowledge this is a 'Developer Preview'–it was not presented or showcased as a developer preview. I have merchants asking when this will be available and when we're going to implement it. I generally agree with @blanklob, @panoply, @bakura10, and @tbqmax. This first release is disappointing. First and foremost, this is a great point.
At Proton it is incredibly common for merchants to ask us to support detailed breakpoint specific settings on a section (example pictured below where the merchant can edit image/copy for mobile/desktop along with various other settings like positioning, colors, etc). As an agency we have adopted some of the principles established by Dawn:
The broad styling that can be applied by Style Settings goes directly against this standard. The enablement of in-theme customization on this level will drive us back to seeking perfection across viewports. I applaud the semi-support of flex in the style settings however providing the Webflow like settings is going to create a compatibility sh*t show and an infinite support cycle for Theme Developers, App Developers, and agencies. There was very clearly no consideration for style conflicts or the fact that Safari is a constant pain in the ass, as this expands how do you guarantee cross-browser compatibility? To do so requires prefixing, polyfiling, etc leading to more bloat and my next point. Now I want to speak on the technical performance implications of the direction this establishes. Sections already support “custom css” that comes with it’s own set of issues. For example, in February we completed a week-long performance audit for TrueClassicTees, an OS 2.0 theme that heavily relied on “custom css”. Below is a direct quote from our report to their Eng team.
There were (and are) dozens of
While it does appear the Style Settings generate a single file it is more bloat that we do not need.. [weeks after Dawn is finally improving how styles are loaded](Shopify/dawn#3509).
The support and implementation of this level of customization should be left up to developers. For example, when we support this in themes we do so using Tailwind and CSS variables. That does not mean Shopify should do the same or do something similar though. The merchant experience for configuring this is an absolute mess and the developer experience is even worse repeating all those settings to ensure a responsive design, give us a middle ground, let us define complex setting layouts like those of 'Style Settings' with our own implementations. https://gist.github.com/0x15f/834ad550e8ff95b1d27567de8c65a746#file-shoppable-hero-banner-liquid |
Beta Was this translation helpful? Give feedback.
-
I think dawn is silently dropping progressive enhancement as an idea because of backend forces making js a hard requirement ignoring frontend realities. don't recall the ticket off top of my head, maybe something to do with removing tags? |
Beta Was this translation helpful? Give feedback.
-
|
Really your use case just shows a need for conditional settings , i.e. 'enable mobile settings' checkbox. On the other hand nestable-blocks maybe such scenarious by having standard-blocks and responsive-blocks /shrug. |
Beta Was this translation helpful? Give feedback.
-
Another elephant foot gun in the room 🐘🦶🔫 , what percent of merchants have cross-browser testing to evaluate their choices or even know the concept exists. |
Beta Was this translation helpful? Give feedback.
-
That sounds like a threshold that should be in the shopify admins perf report notifying merchants to optimize styles once total custom-css gets over a certain size or complexity. custom-css should be used sparingly like for quick small fixes , lite ab tests, or specific customizations. |
Beta Was this translation helpful? Give feedback.
-
|
Hey folks, Ok wow, so much feedback. Tried to take it all in but here’s some raw thoughts already. If you want to chat more we’ll find a time to meet, just email [email protected].
As for theme store, this will NOT be a feature that is a requirement. you guys should use it where you think it’s useful and leave it where you don’t. K that’s what I have so far but yea, email me and we’ll find some time to meet. -V |
Beta Was this translation helpful? Give feedback.
-
|
thanks @vlaurenlee this is good news you manage and thanks @tyleralsbury for the answers as well! thats reassuring, i hope you consider other stuff outside the scope of this conversation (discounts, segmentation) <3 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for the answers @vlaurenlee, this is highly appreciated.
There is also a technical complexity I'm curious to hear how you want to tackle. In our themes, we have a common set of breakpoints, that likely won't match the breakpoint you have defined. You referred to the fact that those will become configurable, but how. Will it be a general setting? A per style setting? One concern I have is that CSS does not currently support CSS property in a media query. There is a proposal for that but it never made it into browsers: It is important for responsive that the theme responsive breakpoints match what the editor would define.
And considering Dawn legacy to add every possible settings and customization everywhere, this will be added everywhere on Dawn. As @tbqmax suggested, once it's on Dawn, it's not optional anymore. This has been the reality for us, so you should factor this into your decision.
|
Beta Was this translation helpful? Give feedback.
-
Sentiment wise given shopify's history on dropping things on dev heads anyone facing possible support burdens in the future MUST assume it will at some point be mandated as NOT optional. Otherwise they run the business risk of being blindsided by taking such a thing on faith. |
Beta Was this translation helpful? Give feedback.
-
Merchants ask for tons of things like slideshows or the ability to force a users browser to play audio and video no matter what always or if someone can run their business for them for free. Open ended settings is a type of Merchant UX-safety issue , not just a concern for 3P support , or DX . If a merchant wants to waste time should they be allowed too? IMO yes of course. There's a weird line to weave here somewhere that if gone to far the expectations for it cannot be taken back. |
Beta Was this translation helpful? Give feedback.
-
|
Before going for a more developed answer, let's just start with the elephant in the room : Let the theme developers breathe. Theme blocks is a huge step, it will take months for everyone to digest this paradigm shift ! Add the style settings over these ? This is scope-creep at this point. Outside any problems I might have with the style settings, let us dabble in theme blocks before anything else. |
Beta Was this translation helpful? Give feedback.
-
|
Also kudos to @tyleralsbury who jumped in here quick. Sorry it took so long for us to join you man |
Beta Was this translation helpful? Give feedback.
-
|
Cheers, V! You've all been a bit busy! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@tyleralsbury in this thread before you came. |
Beta Was this translation helpful? Give feedback.
-
|
Yea... wow. Props to you @tyleralsbury and @vlaurenlee for keeping such cool heads! Appreciate your responses and for continuing to consider people's opinions even when those opinions are given in a less than ideal way ;) |
Beta Was this translation helpful? Give feedback.
-
|
I don’t know if my last comment was super clean so I want to expand on this a bit. Basically I agree with everyone…
|
Beta Was this translation helpful? Give feedback.
-
|
@vlaurenlee thats good to know! @panoply i agree about css - Shopify shouldn't be doing any CFH injection. That definitely feels like a step backwards considering theme developers should already be thinking about css and doing their own base styles. |
Beta Was this translation helpful? Give feedback.
-
|
All the features released in recent years have been driven purely by Dawn's needs. Shopify is disregarding the rest of us and focusing only on what a few people working on Dawn deem necessary, based on limited feedback they receive via their Support. As mentioned by the Shopify rep, Dawn needs it, so they're literally forcing it on every theme on the Theme store because of that. Instead of implementing something that’s actually needed like a way to have URL+Label in the same setting we are getting all of these. |
Beta Was this translation helpful? Give feedback.
-
|
@vlaurenlee having the custom css block in Dawn has been super helpful. With the shift to theme blocks, would it be possible to have for every block and not just the top level? Another consideration I see many developers using is adding a "Custom Classes" schema setting to sections and then use it for targeting that specific section (when the section is used more than once on the page) from an external stylesheet since section ids change. |
Beta Was this translation helpful? Give feedback.
-
|
Guys, can we get some credit for being in this thread with you all? This is why we did this dev preview. To get your opinions. The fact that @tyleralsbury and I have been in here all day has to count for something. I love the points but also let's keep things from being too negative in a way that isn't actually going to help us hear your points. |
Beta Was this translation helpful? Give feedback.
-
|
@jdunham2 noted! |
Beta Was this translation helpful? Give feedback.
-
|
Before I begin, thanks for having this discussion, it means a lot to everyone ! I love being as passionate as I am for these discussions, thanks for that ! All arguments shared here are valid and I think listening to them is capital for the theme development landscape future. I will start with a discussion centered on merchant experience, how to correct the style settings. Then, I will share my opinion on the most appropriate roadmap for theme development, I'd love to have your opinion on this ! Please, if anything, just spread the word in upper management, I’m afraid theme agencies (as well as partners) will have a really hard time adjusting given the current agenda ! For my part, I’ll focus on what I specialise in, merchant theme experience. It’s been a few years now since I started to do theme development and I’ve iterated a lot with my schema patterns. Sometimes I’ve gone simple, sometimes more complex. The only constant is that simple always win and with partners being in the game for more than 10 years, we’ve learned how to use the tools provided effectively. I can count more than 5 times where I devised, in my eyes, a brilliant system. That ends up never being used by the merchant because they don’t have the need nor the time for such configurability. Sad but true. Style settings brings absolutely nothing positive to the table. It’s simply, more attractive-looking, data we can already generate, but we don’t. Because we already tried and it didn’t work well. Here is what I’m using these days on all of my sections : It’s as easy as it gets, some headers/paragraphs and easy to grasp settings. I can extend it when needed but that’s all the data the merchant needs regarding layout. Anything else and, from my experience, merchants get lost in the process. Now, here’s what I like with style settings, the idea of more specialized component appearances for “expected” sets of parameters like spacing of alignment. The only drawback at this point with the examples above is that they can take up a lot of vertical space. For the technical aspect, here’s what I would think as a draft proposal : {% schema %}
{
"name": "Test section",
"blocks": [ ... ],
"settings": [
{
"type": "spacing",
"label": "Section spacing",
"options(or configuration)": {
// Here, dedicated settings for component configuration
},
"settings(or slots)": [
{
"type": "range",
"id": "mobile_top_margin",
"slot": // Assign setting to component fixed slot ids
"label": "Top margin (mobile)",
"min": 0,
"max": 200,
"step": 2,
"default": 40
},
{ ... }
]
}
],
"presets": [ ... ]
}
{% endschema %}Of course, it’s a gross simplification as it would require some more parsing capabilities to unlock these component-level settings but that is the way to go with theme developments in my opinion. It could even be just some grouping/accordion features or in general more flexibility on how we expose our settings to the merchant. Just like Trustpilot (and many others) business model is providing more widgets to their clients from an already existing data, I think theme development should also go towards this direction. The data is here, why add an interface layer on top of that ? It’s the job of theme developers to create the most intuitive interfaces, we already know how to prepare our CSS and high-level, theme-wide thinking on how to create the best merchant experience is a favorite part of most people here ! To conclude, here is a purely subjective bullet point list of everything the
I hope all of this helps consolidate and reorder the different needs expressed by a multitude of people with a multitude of needs. Let's try to converge to simple guidelines for Shopify to escalate the feedback ! Again, I want to thank all contributors to this discussion, first @tyleralsbury and @vlaurenlee for participating and hearing our rants, you're awesome ! Then, all the partners that are more than equipped to help Shopify take the right path when we come to crossroads such as this one ! A great day to you all and let's all work towards a great |
Beta Was this translation helpful? Give feedback.
-
|
This was brilliant @TeamDijon
Regarding Shared Schema: Below are several screeners of it in action being used within an text editor environment. This is effectively a POC which showcases IntelliSense capabilities and what real-world usage would look like:
You can refer to a reply in Virgil's previous thread for an overview of how the implementation might look: #15 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
Thanks for thoughtfully sharing your experience here @TeamDijon. |
Beta Was this translation helpful? Give feedback.
-
|
After reading all the comments i think this is the better option instead of css being generated by shopify {
"type": "style.flex",
"id": "flex_direction",
"default": [
{
"screen": "mobile",
"label": "row"
},
{
"screen": "tablet",
"value": "column"
},
{
"screen": "max-desktop",
"value": "--row"
}
]
}in liquid it should be {% assign ss = section.settings %}
<style>
.main-section {
display: flex;
flex-direction: {{ ss.flex_direction.mobile }};
}
@media ({{ breakpoints.tablet }}) {
.main-section {
flex-direction: {{ ss.flex_direction.tablet }};
}
}
@media ({{ breakpoints.max-desktop }}) {
.main-section {
flex-direction: {{ ss.flex_direction.desktop }};
}
}
</style>
<section class="main-section"></section>at last there should be a way to declare these breakpoints object globally where we can name them like min-tablet, max-tablet, min-mobile, max-mobile .... also the value in screen could be custom eith use css var like --row, --horizontal or css value like row and column |
Beta Was this translation helpful? Give feedback.
-
|
for padding margins could be something like this {
"type": "style.padding",
"id": "section_padding",
"default": [
{
"screen": "mobile",
"values": {
"top": "1rem",
"right": "2rem",
"bottom": "--large",
"left": "2rem"
}
},
{
"screen": "tablet",
"values": {
"top": "2rem",
"right": "3rem",
"bottom": "--x-large",
"left": "3rem"
}
},
{
"screen": "desktop",
"values": {
"top": "3rem",
"right": "4rem",
"bottom": "--xx-large",
"left": "4rem"
}
}
]
}{% assign ss = section.settings %}
<style>
.main-section {
display: flex;
padding-top: {{ ss.section_padding.mobile.values.top }};
padding-right: {{ ss.section_padding.mobile.values.right }};
padding-bottom: {{ ss.section_padding.mobile.values.bottom }};
padding-left: {{ ss.section_padding.mobile.values.left }};
}
@media ({{ breakpoints.tablet }}) {
.main-section {
padding-top: {{ ss.section_padding.tablet.values.top }};
padding-right: {{ ss.section_padding.tablet.values.right }};
padding-bottom: {{ ss.section_padding.tablet.values.bottom }};
padding-left: {{ ss.section_padding.tablet.values.left }};
}
}
@media ({{ breakpoints.desktop }}) {
.main-section {
padding-top: {{ ss.section_padding.desktop.values.top }};
padding-right: {{ ss.section_padding.desktop.values.right }};
padding-bottom: {{ ss.section_padding.desktop.values.bottom }};
padding-left: {{ ss.section_padding.desktop.values.left }};
}
}
</style>
<section class="main-section"></section> |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/webstudio-is/webstudio |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that example @thatecommerceguy! It's a good illustration of you would generate the CSS for a |
Beta Was this translation helpful? Give feedback.
-
|
One issue with all layout settings applying For example, in the reference theme there is a section towards the bottom of the homepage titled "Multimedia collage", which has two 25% width blocks (one image, one collection card) stacked vertically, next to a 75% width collection card. To achieve this using While the example in the reference theme isn't egregious, there is nothing to stop the merchant from adding more blocks to the 25% width group block if they want to extend the section further down the page. The issue with this is that the DOM (and keyboard focus) order will be all of the elements in the group block, followed by the other elements in the section, which doesn't match the visual presentation once any of the blocks contained in the group block are below the bottom of the viewport. The W3C focus order requirements in technique C27 are to "Ensure that the order of the content in the source code sections match the visual presentation of the content in the Web page". Failure to so do so is likely to lead to confusion for assistive technology users. It also means that all blocks inside the 25% group block will render first on mobile, which might be confusing for merchants (for the same reason). This could be avoided by using I have picked that example because it illustrates the issue and is more concrete than a theoretical example. While it might be a little contrived, the same concerns apply whenever a layout requires a grid pattern where the items differ significantly in height, and is more likely to be a problem the more complex the layout. Another accessibility concern related to theme blocks is heading hierarchy, since either the merchant will have little control over what heading tag is rendered, or will need to learn about the importance of heading hierarchy to SEO and accessibility themselves (without it necessarily being obvious to them that they need to). The reference theme for example simply renders all heading blocks as h2. I was hopeful that additional options for restrictions on theme blocks would allow building a theme which prevented merchants from accidentally making their own site worse, but with the only restriction (currently) being the permissible child blocks I don't believe that is possible. While personally I'm very onboard with improving the flexibility of theme customisation for merchants, I would have thought that one of the main benefits to merchants of the current system is that they can customise their site with confidence that they're not going to break anything (which appears to be the focus of a sizeable number of the theme store submission requirements). Increasing flexibility is likely to always be in tension with that, but from my perspective there appear to be few tools in these new systems that would let theme designers mitigate the risks introduced by the increased flexibility. |
Beta Was this translation helpful? Give feedback.
-
|
k some good feedback here. Thanks @pbright. yep, we're looking at display:grid already and it will definitely be an option before this actually gets released - more a matter of us trying to get the dev preview out than anything that it wasn't included. What other restrictions would you want for theme blocks? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Vanessa, Thanks for the response, and great to hear that about In terms of theme block restrictions, the W3C WAI success criteria and techniques require three things:
Also relevant to theme block restrictions:
Meeting all of those criteria requires either:
The first is not consistent with how Shopify has implemented theme blocks. For the second to be a viable option, I think the following would be necessary:
This would allow creating a heading hierarchy by having a different theme block for each heading (H1Block, H2Block etc), and then allowing / restricting use of those blocks accordingly. For example, a section might allow H1Block, whereas a ContentBlock nested inside that section might disallow H1Block and allow H2Block, and so on. This would allow theme developers to determine what heading tags should result from a heading block inserted by the merchant at each layer of the hierarchy, and if there is only one valid heading tag (or a subset of valid heading tags distinguished by a setting rather than differing blocks eg. Large / Small) each block could be labeled the same ("Heading") so this system is transparent to the merchant. There are still limitations to such an approach, but I couldn't think of a better approach that didn't depart markedly from the current theme block implementation. Those restrictions would also be useful in other contexts. For example, using min/max restrictions would allow theme developers to require blocks which contain necessary functionality while still giving merchants the flexibility to reorder those blocks, or intersperse other types of blocks. This is particularly relevant to the product page which has a lot of required functionality. |
Beta Was this translation helpful? Give feedback.
-
Nested tree structures and seeing the same type doesn't work so well unless you also have access to each blocks settings because the size may not match the heading structure.
|
Beta Was this translation helpful? Give feedback.
-
|
Another idea @vlaurenlee. This is not directly related to this, but a little bit :D. One issue we often have for themes when they become too complex is an overload of settings. This can cause confusion, and with proposals like style settings that further increase what merchants have to configure, problem with be bigger and bigger. Something theme dev have asked for a long time are conditional settings. Along with specialized settings, they could be really useful (I'm thinking of |
Beta Was this translation helpful? Give feedback.
-
|
yep! me as well. |
Beta Was this translation helpful? Give feedback.
-
|
Same |
Beta Was this translation helpful? Give feedback.
-
|
You folks aren't alone - as Vanessa said, we are also on board with conditional settings. There are parts of Dawn that would have been built differently if we had them, and other parts that we built anyway despite the fact that they would be much better if we could use conditional settings. It's great to see such broad alignment on that! |
Beta Was this translation helpful? Give feedback.
-
|
I still want to point out that despite the full alignment of the community on this topic, it is entirely its own discussion and outside of the scope of this discussion. It would be amazing to create a discussion/workshop for these conditional settings though, what do you think would be the best way to go ? @tyleralsbury @vlaurenlee In my opinion, conditional settings, just like unifying settings/metafields interfaces are key points for theme development. Not as sexy as product listings though, merchants/key enterprise players don't understand the benefit, it's mainly DX in the end. In an environnement where Shopify focuses on bi-yearly Editions, working on these seems complicated and it's entirely understandable. The ratio of effort versus marketing towards Editions seems overwhelmingly against it, there are better quick wins to go after. And I think that in the end, style settings, as is, are mainly that, a marketable quick-win in a ship-it culture. Again, I have absolutely no problem with that, we all have our objectives and I'm not here to judge management decisions at all. Yet, both of these features, as well as theme blocks, are, in my opinion, sane and important ground work that will be capital to the future of theme development. We mainly want Shopify to take a step back and assess the need with the the community and key theme partners to be sure not to ship an half-baked feature that only a little chunk of the community will use (or worse, feel obligated to use). Not enough to keep the same trajectory, but enough to feel obligated to include support for it going forward, adding another layer to the interfaces theme developers needs to navigate everyday. Let us help you and let's create the best for both merchants and partners together 💚 Again, thanks to everybody for the great points covered and wholesome discussion ! |
Beta Was this translation helpful? Give feedback.
-
|
If the condition is user action to add a specific block then very very loosely nestable blocks can be used to conditionally "add" settings 🤷♂️. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks guys, this is kind of why we do this and put ourselves our there early. So we can hear this kind of stuff. We always wanted to give the ability for you to be able to use the same UI (like a spacing panel where there are more advanced settings hidden) but hook everything up yourself in the CSS and the liquid, you should see a release of that sooner than later given this thread. The reason why we wanted to do some generation is because, even for our own themes, we want the ability to minimize the amount of CSS repetition given with each block but it doesn't mean you HAVE to do it that way for sure and it's more explicit and easy to control when you catch the variables in code. We'll come back for sure with more on this one. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding: #38 (reply in thread) Proposal: Expose control at the schema level to prevent style generation and CSS injections from applying both inline Given your commitment to applying cascades upon default reference, both developers and users would expect to control this behavior from the reference point (i.e., within the schema). The ideal solution would allow for custom class naming, for e.g: { "class": "foo" }Including a class property would prevent injections and apply as a disfix (or other), while omitting it would signal to proceed normally (i.e., with injections and auto-generated class name(s)), this approach would:
|
Beta Was this translation helpful? Give feedback.
-
|
It's great to see the theme developer community getting involved in this topic and giving constructive feedback and interesting insights. Sometimes it feels like we're on our own and not really considered by Shopify, it's good to be heard. So thanks to all of you, and especially to @bakura10 @TeamDijon @panoply @vlaurenlee Maxime from Unique Paris |
Beta Was this translation helpful? Give feedback.
-
|
I like the concept of Theme Blocks, as it enables the creation of complex components such as mega-menus, faqs, slideshows, etc which are now difficult to implement and not intuitive for users to configure. But I'm also concerned that Shopify will dictate the technical and design aspects. Developers should maintain control over their projects appearance and structure, including choosing between Flexbox, Grids or whatever is needed. Flexbox isn't always the best option, Grids are becoming more powerful, especially with the growing support for CSS Subgrid there will be designs that will not work with Flexbox. Imagine a global grid system governing the entire layout, with every element inside respecting this grid... this is achievable with subgrid, but flexbox cannot be used in this scenario because the design would not work. This is only a small example, but it is quite significant in our case for instance. If Shopify predetermines these decisions and requires specific tools, it will limit flexibility and push us to find workarounds for navigating the platform's choices. This will restrict us from utilizing the most appropriate tools for every situation. In addition, I am not very into the idea of the current viewport options. Merchants will eventually require specific viewports for tablets, laptops, and other devices, making it hard to ensure that everything functions and looks great across all possible modification options. From a planning and design perspective, creating new themes with so many customization options is challenging. It's nearly impossible to anticipate and ensure that everything will function and appear as intended. I also fear that granting merchants extensive customization freedoms could lead to issues with design, accessibility, and SEO, ultimately complicating the user experience rather than simplifying it as well as increasing the amount of support tickets. Furthermore, this level of customization adds significant complexity to the theme editor, which is already not in its best shape in terms of UX. Theme code will also suffer by being more complex and prone to errors. But I am confident that we can discuss these concerns with you guys, and that this time you are listening to our feedback, and that we can find the best solution that works for everyone. |
Beta Was this translation helpful? Give feedback.
-
|
@vlaurenlee has already mentioned this, but it bears repeating - so far, we have done flexbox, but that's not the end of it. We are definitely looking into including Grid as an option for style settings and "a la carte" settings as well to allow you to use the individual setting types to create your own beautiful setting UIs without relying on us for generation. I believe these things combined would give you the tools you need to create a global grid / subgrid system and limit the customization to the degree you're hoping to. |
Beta Was this translation helpful? Give feedback.
-
|
Ok spent some time with the team this morning. I loved all of the examples, code snippets are really helpful, I can't say this enough, thanks everyone. We’re going to honour that by coming back here next week with examples of code as we figure out next steps. So this is what we’re going to work on and share next week here on the thread:
We’re also likely going to prioritize moving theme blocks to production earlier so that you all can play with it more on an actual live shop if you want. Migration will be tricky but we’re going to figure it out. |
Beta Was this translation helpful? Give feedback.
-
|
Yea, we wont release theme blocks without some work. Also after looking at schedules a bit, there's some appetite from all of us here to actually talk and show some of these so we can get feedback more quickly and actually have some dialog on it and iterate. I'm going to reach out to some of you now but also, if you WANT to chat, email me. This is not a vanity thing, we actually want to talk. We're aiming to chat on the 8th after we've had some time to get a draft of the syntax going and then with the goal of posting here later that week. |
Beta Was this translation helpful? Give feedback.
-
|
awesome, yea will reach out with use cases! thanks. |
Beta Was this translation helpful? Give feedback.
-
it's unrealistic to consider blocks as being production-ready In their current state but that’s just me maybe |
Beta Was this translation helpful? Give feedback.
-
|
Super excited to use in production as is. For us this would be a tremoundous time saver EXACTLY the way it is. Improvements from here will be great. |
Beta Was this translation helpful? Give feedback.
-
|
It's nice to see that this discussion has pushed the team to consider things more thoroughly. I'm left feeling rather optimistic which is rare. I'm easy to find if you want to chat. |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, first and foremost, thank you so much for your perspective. We had the pleasure of meeting so many of you virtually last week to discuss our latest developer preview and received a ton of great feedback. Rather than try to jam it all into a single post, I’ve created a couple of dedicated threads for discussion. Please check out the first two topics here: Another topic which we discussed here and in our developer feedback sessions was the ability to customize breakpoints. We’re going to begin sketching out some concepts and prototypes soon. Once we have something to share, we’ll circle back here and spin up another discussion thread. Thanks again for all your support and feedback. We’re looking forward to hashing out these ideas and many others in the coming months. |
Beta Was this translation helpful? Give feedback.
-
|
Any breakpoints feature may need to also interact with the UI's viewport selectors on the topbar-segmented-selector* somehow, though nothing to the extent of what we'd find in devtools. |
Beta Was this translation helpful? Give feedback.
and others
-
Hi,
Michaël from Maestrooo here.
I tried this morning the reference theme.
Flexibility
I'm not gonna lie, I am not a big fan of all the new features, we are entering the Webflow area here, and I don't really like the flexibility given to merchants here. At least it is optional, but if Dawn goes the road of exposing this to every blocks/sections, this will become the expectations of merchants and I am afraid we will be forced somehow to use this as well.
I am afraid this gives too much responsibility to the merchants. Creating a cohesive spacing system for merchants will take a lot of time.
Upgrade
How will this work in the context of automatic upgrade?
When we rewrote Prestige last year from scratch, we had a lot of issues as Shopify allowed automatic upgrade from an old version, and this messed a lot of things and caused lot of support. If we upgrade our theme to this, we will need to remove and replace a lot of settings, meaning a merchant upgrading will have a store where most of they settings won't be preserved.
I think Shopify should have a way to detect if a theme is using the new architecture or not, and prevent any upgrade.
Class names
I was curious to see how class was implemented, and apparently a unique class is generated for every sections/blocks:
Couldn't this be a bit smarter and using something like
styles:size:width-50%so that if two sections/blocks have the same width, this leads to only one rule ?Size
I'm not sure this is a bug but I've set the right group to be 65%, but it appears smaller than the left image. This is quite unintuitive:
Beta Was this translation helpful? Give feedback.
All reactions