Pondering mobile first

Beta
#1

Imagine the following scenario if you will

a website is all built using the new reponsive controls, with elements having multiple changes at various screen sizes.

Then imagine, coming back to the website at a later date to change a font size of a heading, only instead of picking a specific screen size, you just change the font size while viewing on an xl screen.

now at that point I foresee at least 2 problems

  1. you have effectively changed the XS screen size not the XL
  2. if you have any font size settings after the XS, you will not see the font size change you just made

I would welcome your thoughts on how to prevent this ‘mistake’ from happening

while I welcome mobile first as an idea, there is not one person here (I’m guessing) that actually develops on a mobile sized screen, and defaulting to ‘all sizes’ actually changing the XS settings (& upwards) is likely to cause a lot of grief to website builders, clients, and dare I say it Themeco Support

2 Likes
Responsive Styling Beta Progress
#2

I was pondering rather or not to mention this but now that you have @scotbaston, it’s not just me thinking the same thing which is good.

I think that the mobile-first approach is a bold and admirable move, especially considering how much mobile traffic has grown. My main concern here is that, even though the mobile-first approach should be the correct way to design, I don’t think it’s everyone’s custom to start mobile-first when it comes to the actual build of a site. The main reason I don’t think it’s everyone’s way of doing because, up until this new release, I don’t believe I’ve seen any other builder have their base breakpoint as the mobile.

With that in mind, people have grown accustomed to having the desktop-first approach because it’s just what is out there at the moment. Going full-on mobile-first seems to be a big change for many that are stuck in their ways and have been building desktop first for years. This could cause a bit of frustration or confusion with users that maybe have less experience than those with years of experience but might cause discomfort for those with years of experience that just likes to do thing how they always do them.

This is the scenario that I see might cause frustration:

  1. Build a XL breakpoint to get it looking all nice and how I want it.
  2. Once I move to the L breakpoint (which will automatically activate responsive styling), I make the changes in this breakpoint to make it as I want it.
  3. But now because anything I changed to the L breakpoint is being inherited on the XL breakpoint, my XL breakpoint doesn’t look how I left it.
  4. Now I have to go through each value that was inherited from the L Breakpoint and get it to how I want it
1 Like
#3

Good point @Maratopia_Digital & @scotbaston! I’ve thought about this too. My usual workflow is to start at XL and work my way down to mobile viewports.

Maybe a simple “Mobile-First” – “Dekstop-First” switch would do the trick?

#4

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?

1 Like
#5

@kory as I imagine this I think this will be a very good addition to the responsive styling options

#6

Hey @kory,

I know I’m sounding like a broken record here from the other thread that I mentioned. But it would be really nice if this was an option setting, similar to preserve inspector group or auto close elements settings on the preference panel, where we get to decide the cascaded flow. Apologies I know I’ve been going on and on about this haha, I just think this would be a really nice feature to have and would give us users the choice for our preferred way of building sites.

Really digging this proposed way as well, I think it’s a nice feature and I think it won’t be that big of a change for most users. And definitely agree there with most users just using the inline responsive as I’m pretty sure that’s how I’ll mostly use it.

I think what I’m wondering here is if I had all my element values set based on the XL preview (responsive toggle OFF) then when I go to the MD Breakpoint (responsive toggle OFF) on the label responsive modal and change a value on the MD Breakpoint would that still inherit to the L and XL breakpoints? Or would it act as a just-for-that-breakpoint basis?

But I got to say, you guys are giving us a killer product here. The amount of things we are able to do with the last release is amazing now with the responsive styling it’s just getting better and better. You’ll be taking over the world with this Theme Options Reboot :joy: 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.

1 Like
#7

I know I’m sounding like a broken record here from the other thread that I mentioned. But it would be really nice if this was an option setting, similar to preserve inspector group or auto close elements settings on the preference panel, where we get to decide the cascaded flow. Apologies I know I’ve been going on and on about this haha, I just think this would be a really nice feature to have and would give us users the choice for our preferred way of building sites.

Definitely appreciate all the thoughts you’ve been sharing here. Under the hood, we actually built the system to allow any base breakpoint to be selected. Our intention was to allow the base breakpoint to be changed as part of the Theme Options update. We discussed all this with the team at length today and think it’s best to just move this up to this cycle as well. We’re working on a new control that will be in the current Theme Options to let you select it (preferences only affect the logged in user). Then for the Theme Options reboot update we can add the ability to add/remove/change the actual breakpoints. This should hopefully make sure we accommodate the many different site building workflows! Kory might have more to add here, but I’ve just been following the conversation and thought I’d share an update based on some talks we had earlier today.

think what I’m wondering here is if I had all my element values set based on the XL preview (responsive toggle OFF) then when I go to the MD Breakpoint (responsive toggle OFF) on the label responsive modal and change a value on the MD Breakpoint would that still inherit to the L and XL breakpoints? Or would it act as a just-for-that-breakpoint basis?

Stay tuned on this one - we’re working through some ideas for a mechanic that will allow you to do either/or of those options.

2 Likes