Gutenberg: Responsive previewing and device-specific editing

[jasmussen]

Work ongoing in #19082 (see also mockups) has enabled previewing responsive changes to existing blocks. Specifically, it enables previewing content at three breakpoints, mobile, tablet and desktop. This opens up a number of questions and possibilities, one of which is: can we leverage this responsive preview feature, to enable responsive editing?

Examples of responsive editing:

• Showing a drop-cap in a paragraph, only on the desktop breakpoint.
• Showing 1 column on mobile, 2 on tablet, 4 on desktop.
• Showing a block only on mobile, hiding it on tablet or desktop.

This ticket shows some initial mockups exploring what that might look like. These mockups assume the following design constraints:

• Responsive editing is an advanced feature that will be used occasionally, and most users likely won't use it at all.
• Responsive editing should work with every existing block, and not require any additional code or opt-in.
• Any responsive change should be instantly previewed, be direct manipulation.

The above constraints make this ticket an alternative approach to #13363.

Mockups

• Preview button is replaced with a dropdown indicating the view you're currently seeing. This happens only when an editor registers an editor-style, indicating that the editor itself is a preview.

• Dropdown contains three breakpoints, defaulting to Desktop.
• "Preview in new window" has the same effect as the classic button.
• "Device specific editing" is toggled off by default.

• When "Device specific editing" is enabled, any change you make is saved only for the current view.
• A centered label at the bottom indicates that any change you are making is for that breakpoint only. Clicking "Done" untoggles the button again.

• In the Phone breakpoint, content is previewed in a phone sized canvas, including any breakpoint changes

• In this shot, the Image block was deleted.
• The blue dot indicates a change was made.

• The blue dot has a tooltip on hover, and on click you can port changes to other breakpoints, or undo changes.

• The blue dot also appears for any post or page that has had responsive edits made. Click it to open a dialog to view or change those edits.

Next steps

For the time being, the above flow shows how to:

• Enable responsive editing.
• Preview mobile, and delete an image just for that breakpoint.
• Surface which elements were changed, and how to port those to other breakpoints.

This flow on its own should be portable to making any other changes, such as column changes, or even alignment or sidebar changes. So now is a good point to stop and revisit the ideas presented:

• Enabling responsive editing happening in the same dropdown that you use to preview the changes.
• The blue dot to indicate _something was changed_ (often used for "unsaved changes" or "notification").
• The blue dot can afford a tooltip and interface for enabling at other breakpoints.
• A hidden block becomes a placeholder.

Pending your feedback, subsequent discussion points include:

• What does the interface that lists all responsive changes look like?
• What does a sidebar option with a responsive change look like?
• How well does the blue dot scale to other responsive edits?
  
  
  
  • What would it look like for a drop-cap change?
  
  
  • An alignment change?
  
  
  • A column change?
  
  

Let's discuss.

[epiqueras]

A simpler alternative for achieving the same sorts of layouts that this feature would power could be to have two grid blocks with different children that show/hide at different breakpoints.

I worry that scaling these "responsive edits" to all possible types of edits like alignment/color/sidebar settings could get complicated and confusing fast.

[karmatosed]

I really like the idea of this and my mind is skipping into how this would work for global styles. I keep thinking of the final step being confirming what you've changed - but that's to explore another time.

I really like the idea of the 'notification' indicator and this is a good spot (dot joke) to explore what that could be regarding color and shape.

[MichaelArestad]

I worry that scaling these "responsive edits" to all possible types of edits like alignment/color/sidebar settings could get complicated and confusing fast.

@epiqueras That is a concern I share, but as I think about the individual pages and posts I've created for clients over the years, I see flexibility in what settings change per device being valuable. I also predict that on any given page, there won't be as many device-specific edits as we might fear. I wouldn't expect more than a few images changing/showing/hiding, headlines changing in style or content (by showing/hiding), and maybe a modification or two to make something fit better on small devices.

Because of the potential mental overhead of learning how to make these changes and recognize them, I think this feels like a v2 feature. Something we can design and get ready to implement, but perhaps save it for a few months after folks get familiar with basic full site editing.

@jasmussen Right now, I'm digging the overall flow. Some thoughts in no particular order:

• I wonder how you could make the "deleted block" placeholder disappear so a user could get a more literal preview. In addition, is there a way to make it appear when needed?
• I wonder where the best place for the "device-specific editing" toggle is. It seems rather unexpected to me in that dropdown. Would it be a document-specific setting? An editor specific setting? Could it be something you prompt the user with as they edit something in a device preview view?
• I like the idea of dots, but wonder if we could show a letter or something to the same effect. For example, maybe a blue "D" (for device) or "R" (for responsive) might be good in its place and not be too reminiscent of the blue/red notification dot?

[epiqueras]

Can't grids achieve all of that as well? Without introducing something new to learn.

[ZebulanStanphill]

In the case of variable columns-per-row, you can accomplish that at the theme (or global styles) level using CSS Grid.

I'm also concerned about the blue dot. I think it should look more like an interactive element and use an icon of some sort.

Also, the "List device-specific changes" toggle should be split out into its own control on a separate line.

[jasmussen]

Can't grids achieve all of that as well? Without introducing something new to learn.

Can you elaborate on how grids can solve this? While CSS grid can change broad stroke layouts at different widths, these changes are layout-only. Unless I'm mistaken, you could not hide a block just on the mobile breakpoint, nor could you set a 50vh min-height on the Cover block just for the mobile breakpoint, and a 100vh min-height on the desktop.

Think of these mockups as looking at what the editor could be in 2 years. This is an exceptionally difficult interface, the way to build it is to start with the vision, then work our way towards that.

In 2 years full site editing will likely be in a better place, themes might be block editor aware, media queries work in the editor, blocks can leverage element queries, and the theme stylesheet is loaded into the canvas directly. (Probably.)

What does responsive editing look like in that interface? That's the question the mockups shown have tried to answer:

• By grouping responsive editing to the viewport width, everything remains direct manipulation. Instead of adjusting _just the columns block_ for the mobile breakpoint, you'd adjust _every block_ for the mobile breakpoint.
• By continuing to use smart defaults for blocks built (columns is born with 1 col mobile, 3 cols desktop) and keeping the responsive editing a power user feature that is off by default, you might never need to do this.
• But when you do enter responsive editing, the simple blue "something changed" dot will scale to any change made that is out of the ordinary, and provide an immediately visible interface for learning about, resetting, or adjusting those properties.

It's only when a specific breakpoint needs to be adjusted from what it comes with by default, that you'd need to enter responsive editing.

---

Inversely, if we were to keep going down the per-feature, per-block approach to responsive edits:

• You would lose the direct manipulation. You might be making edits to the tablet layout for a grid, while previewing at a desktop breakpoint. You might think you were also making tablet-only changes to content inside the grid, when in fact those changes are global.
• You would have no simple way to see a list of all responsive edits made to a page, or post, or template. You'd have to hunt through every block at every breakpoint to debug a change, which would be further confusing in case of blocks that come with smart defaults.
• You would essentially be white-listing every property and change that needed to have responsive edits, increasing the block API surface and putting the onus on block developers to decide which properties are surfaced as responsive.
• Specific to the dimension control, this is a sidebar-only interface, limiting the type of properties you can enable responsive edits for, and further distancing it from the direct manipulation interface of the block itself. This also means any feature not in the sidebar, would need another interface, actually another thing to learn.

Perhaps the biggest cost, in my mind, is the opportunity cost. We can't yet imagine what wonderful and crazy things users can build when everything becomes responsive-enabled.

---

The mockups shown here are early, in need of refinement. But they do adresss those challenges outlined directly. I would very much encourage additional ideas, but because this is a future thing, those ideas should address the same challenges:

1. Is there a way to make properties available to responsive edits, without requiring developers to add a dimension control on a per-block, per-feature basis?
2. How can we make responsive changes direct manipulation?

As an example of how why those two principles are worth tackling, I worked on this Layout Grid block, where we added responsive controls using a dimension control, like so:

This was created for lack of a better interface, and it's a bad user experience in many ways:

• It's not direct manipulation. If you choose a tablet breakpoint, only the layout grid block will show show the tablet layout, even though the rest of the page and even content inside, is shown at desktop dimensions.
• It does not work with either media queries or even element queries. If you resize the browser window, the tablet and mobile queries do not kick in.
• It's per-block, per-property, and not WYSIWYG. You might end up looking at a preview cobbled together by a tablet breakpoint grid, and a mobile breakpoint font size, because none of those properties are aware of the other.

[jasmussen]

I'm also concerned about the blue dot. I think it should look more like an interactive element and use an icon of some sort.

I tried using the classic multi-screen icon, but it added visual complexity and drew attention to itself in a way that was not conducive to the idea that _you don't have to make responsive edits_. The dot, on the other hand, felt like it immediately opened up the interface, and you've probably seen it many other contexts without even thinking about it:

In a way, the dot deserves better than to be called non-descript. It is an icon, and it means _there's something here for you to look at if you want to_.

[epiqueras]

Can you elaborate on how grids can solve this? While CSS grid can change broad stroke layouts at different widths, these changes are layout-only. Unless I'm mistaken, you could not hide a block just on the mobile breakpoint, nor could you set a 50vh min-height on the Cover block just for the mobile breakpoint, and a 100vh min-height on the desktop.

See this comment for how the grid should work: https://github.com/WordPress/gutenberg/issues/19254#issuecomment-578190112.

You can hide a block on mobile by putting it in a grid that does so. And you can show different subgrids with different cover blocks to achieve that min-height difference.

What does responsive editing look like in that interface? That's the question the mockups shown have tried to answer:

The grid approach is also direct manipulation, can have sensible defaults and an immediately visible interface.

Inversely, if we were to keep going down the per-feature, per-block approach to responsive edits:

I wouldn't call it per-feature, per-block, it would just be limited to the grid.

You would lose the direct manipulation. You might be making edits to the tablet layout for a grid, while previewing at a desktop breakpoint. You might think you were also making tablet-only changes to content inside the grid, when in fact those changes are global.

You shouldn't be able to edit a grid at a breakpoint you're not previewing.

You would have no simple way to see a list of all responsive edits made to a page, or post, or template. You'd have to hunt through every block at every breakpoint to debug a change, which would be further confusing in case of blocks that come with smart defaults.

It would be simpler to see and display because the scope is limited to grid blocks. With the idea in this PR, any minor edit can be subject to the behavior.

You would essentially be white-listing every property and change that needed to have responsive edits, increasing the block API surface and putting the onus on block developers to decide which properties are surfaced as responsive.

Where did you see that proposed? I don't know how that relates to the grid approach.

Specific to the dimension control, this is a sidebar-only interface, limiting the type of properties you can enable responsive edits for, and further distancing it from the direct manipulation interface of the block itself. This also means any feature not in the sidebar, would need another interface, actually another thing to learn.

Yeah, I wouldn't suggest this either. I think we are talking about different things.

As an example of how why those two principles are worth tackling, I worked on this Layout Grid block, where we added responsive controls using a dimension control, like so:

Yeah, that is not ideal and probably why you rejected the grid idea.

You should not be able to edit a grid for a breakpoint you are not previewing. Furthermore, grid inner blocks should be the same between breakpoints. What you can set are two breakpoints for the grid: one at which it starts to render blocks in a list, one at which it starts to render blocks in a grid layout. Setting one of those breakpoints can change your preview to that size to see the change in action. Combining multiple grids that either hide, stack, or display typically at different breakpoints with different children can let you achieve any layout you can think of while maintaining all of the properties we want for the editor.

The problem with making all edits responsive is that we don't even have a definition for how an edit can be made or what they represent. They can be done programmatically by block developers; they can be done in an infinite number of different possible UIs. I can't even begin to think about how to surface all of them without ending up with some cluttered edited properties list that is hard to parse. Have you ever seen another editor that takes this approach? It might be helpful to see how others deal with it.

[shaunandrews]

• Love this. This viewport-specific editing mode will help us avoid having viewport-specific controls on a per-block level. I’ve already seen this done by a few plugins, and it leads to an overwhelming and repetitive UI.
• I think adding the switch to enable viewport-specific editing to the view menu makes a lot of sense. It exposes the functionality in context, and helps explain something I probably wouldn’t understand if it was presented elsewhere.
• I like the idea of showing a constant indicator when viewport-specific editing is enabled. You’ve done this by adding a line of text to the breadcrumb bar. But I’m wary of putting more into that bottom bar; People rarely notice it, and the breadcrumb list could get very long and break the alignment. Maybe this indicator should live in the top bar as a new element next to the view menu, or a variation of the view button itself. (I know, adding more to the top bar might be a bad idea.)
• Using the dot next to the device name in the menu seems a little strange. Its kind of mysterious. I wonder if using a label would be more clear. Something like “3 edits”.
• Visually, I find the hidden block to be _too_ strong. But that’s minor. Conceptually, I don’t love that the block still displays _something_ and takes up space in the canvas when hidden. I wonder if there could be a way to completely remove it, and add a button somewhere saying “show 2 hidden blocks”. This way I could toggle them on or off depending on what I’m doing. Otherwise, I worry that hidden blocks will break the layout in the editor and break the WYSIWYG promise of the canvas.

[jasmussen]

You’ve done this by adding a line of text to the breadcrumb bar. But I’m wary of putting more into that bottom bar; People rarely notice it, and the breadcrumb list could get very long and break the alignment. Maybe this indicator should live in the top bar as a new element next to the view menu, or a variation of the view button itself. (I know, adding more to the top bar might be a bad idea.)

✨

Great observation. There might even be an opportunity here to unify what pattern we come up with, with the Code Editor which currently has an "Exit" bar at the top.

Using the dot next to the device name in the menu seems a little strange. Its kind of mysterious. I wonder if using a label would be more clear. Something like “3 edits”.

Good idea to explore. It's a little space constrained, but it seems like it should be doable?

Visually, I find the hidden block to be too strong. But that’s minor. Conceptually, I don’t love that the block still displays something and takes up space in the canvas when hidden.

Good thought. This comment surfaces a challenge I had not considered, the case where the hidden block should not affect the _layout_, which a placeholder like this would do. Imagine hiding the 3rd menu item in the navigation block just on mobile.

I wonder if there could be a way to completely remove it, and add a button somewhere saying “show 2 hidden blocks”

This seems very much worth sketching out, because with your point very well made, the challenge becomes creating an obvious interface for unhiding those blocks when you need to.

Thanks all for the feedback, and keep it coming. The feature outlined here is a ways out, so let's keep the ticket open to additional input.

[johnstonphilip]

Related: https://github.com/WordPress/gutenberg/issues/20244

[paaljoachim]

This is a big issue.
Should we break this issue into more actionable issues (or a test PR)? As it will create an easier focus on smaller features.
As we need to figure out an easier way to get movement here.

[jasmussen]

A block I'm working on, Layout Grid, will change the viewport when you select a responsive option in the sidebar — incoming feature. Testing the experience on that plugin sheds quite a bit of light on the various bit and bobs we can consider here.