Howdy @scotbaston, @Maratopia_Digital, and @sparko! Thanks for writing in and sharing your thoughts. We’ve been having some discussions about some of this internally, of which I will share more below and we’d love some feedback on.
@scotbaston, regarding the situation you laid out, as things currently stand, things wouldn’t play out this way.
If you see no label highlight on a control’s label, that means that nothing has been done responsively to that control, which also means that any time you update that control, you are always updating the base style (because it’s the only style present on that value.
If you do see a label highlight for a control, that means that responsive styling is present for that control. When responsive styling is present on a control, it’s like a gate has been opened up, and now responsive styling is “on” for that control always. That means if you see a highlighted label on a control, any change you make to that control—regardless of if one of the responsive toggles in the Toolbar is selected—will be affecting that breakpoint directly (and any breakpoints above it if they are inheriting).
This reality should address both of your concerns, because you’d always be seeing the “current” value of a breakpoint, whether it is an overwrite, or an inherited value from an overwrite (the orange state). Since that logic gate is open and that singular control only is always “on” responsively, this particular situation shouldn’t be an issue.
Hopefully that clears things up. Do let me know if I happened to miss something or perhaps didn’t understand the example scenario fully.
@Maratopia_Digital, the scenario you’ve laid out in this situation I think holds a little more water as something that could potentially happen with users. The thing with both “desktop-down” or “mobile-first” is that either way, you’re having to work with a cascaded flow of styling, it’s just which direction do you want to move? Check out the idea laid out towards the end of this post and let me know what you think if it might aid in this situation.
Proposal
The ideas I laid out on this thread with regards to always making the label next to each control clickable seem to be fairly well accepted so far as a good move in terms of bringing back that micro-flow of quickly setting a value across multiple breakpoints if you know what you want to do for an Element off the top of your head. We still want to work on bringing that in as I think it is a good compliment to the more macro focus of the new responsive toggles in the Toolbar.
One discussion the team had earlier today was the fact that changing the responsive toggles to effectively operate as on/off switches for responsive styling might be a big change to most users who are used to using them up until this point simply as a way to quickly preview different screen sizes.
A proposed idea we’re exploring is essentially putting the toggles by default back to the way they have always behaved. They will simply be ways to preview different screen sizes out of the box, without any new utility added to them. Next to these responsive toggles we would add one new button—a “power” button if you will—that will be the logic gate for enabling / disabling responsive styling. When this button gets pressed, the responsive toggles would then function as they currently do in the beta. Now, as you click from breakpoint to breakpoint, you’d be able to adjust any control for any Element on that breakpoint without any further action. Then if you wanted to go back to simply using the responsive toggles as breakpoint previews, you turn off the new “responsive styling” toggle and things are back as they were.
The thought here is that this paired with the “micro-flow” feature of the labels from the thread mentioned earlier would help make the transition to responsive styling more gradual. With this responsive toggle turned off, you’re always adjusting the “base” style no matter what, until you either opt-in with the toggle, or click into a label and simply perform your overwrites inline. I can even envision a scenario for many users in this situation where they might not even enable the global responsive toggle in the toolbar, and instead choose to make their edits as they go inline on the label.
How does all of this strike you all, and does it help to ease any of the concerns about a mobile-first approach moving forward?
Also Beta testing for you guys is pretty cool too, you put time and effort into reading and responding to our thoughts, ideas and concerns. It’s enjoyable and satisfying that we can have input on this awesome product.