Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block Editor: Add block zooming. #16578

Closed
wants to merge 4 commits into from
Closed

Block Editor: Add block zooming. #16578

wants to merge 4 commits into from

Conversation

epiqueras
Copy link
Contributor

Description

This PR implements a new block zooming feature that lets you focus the editor on the selected blocks through a button in the block toolbar. Furthermore, if one of the blocks selected has descendant blocks, the editor will unwrap them while it is zoomed.

A button on the top right of the block list lets you zoom back out and also serves as an indicator that the editor is zoomed.

This functionality will be crucial for maintaining the current user experience of editing a post after we move to a setup where post content itself is a block, like in #16485, or we introduce other top level blocks with complex descendant hierarchies. The idea is that users can zoom into a block like post content and edit the unwrapped descendants with the same ease of editing top level blocks. It lets them get around the clunkiness of editing inner blocks.

How has this been tested?

Both single and multi selections were zoomed into, with and without blocks with descendants, and the zooming worked as expected. The button to zoom back out also works as expected.

Screenshots

ezgif com-video-to-gif (1)

ezgif com-video-to-gif (2)

Types of Changes

New Feature: Add block zooming.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@epiqueras epiqueras added the [Package] Block editor /packages/block-editor label Jul 13, 2019
@epiqueras epiqueras added this to the Future milestone Jul 13, 2019
@epiqueras epiqueras self-assigned this Jul 13, 2019
Copy link
Member

@jorgefilipecosta jorgefilipecosta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally agree with the usefulness of this functionality, but I wonder if we should call it zoom. Zoom may be associated with magnifying/scaling, while this feature does not necessarily make the selected blocks bigger, it just focus/crops the editor to show them. Maybe focus these blocks would be a way to describe the action?

@@ -1228,6 +1247,7 @@ export default combineReducers( {
isTyping,
isCaretWithinFormattedText,
blockSelection,
blockZoom,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I create a group block, add some blocks inside it, select all the blocks inside, zoom them, and then press the undo button the editor crashes.
I guess blockZoom probably needs to be inside blocks reducer branch, so it is covered by undo functionality. As a side note, we should decide if zooming in creates a undo level or not, there are pros and cons of either option. But it is possible to have the functionality working correctly with undos without creating undo levels, like the block selection done in #16428.

Related #12327.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I need to move it, but I don't think it should create an undo level. It's not an edit operation, it's more like selections which we also don't expect to create undo levels.

I plan to give this reducer it's own history so that you can zoom out in steps after zooming in multiple times.

I wonder if it'll be easy to nest 2 reducers with history like that.

@@ -40,8 +40,8 @@ function useMovingAnimation( ref, isSelected, enableAnimation, triggerAnimationO
ref.current.style.transform = 'none';
const destination = ref.current.getBoundingClientRect();
const newTransform = {
x: previous ? previous.left - destination.left : 0,
y: previous ? previous.top - destination.top : 0,
x: previous ? previous.left - destination.left : -50,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this negative margin may be causing a strange movement on the previous block when a new block is inserted:
Jul-14-2019 14-34-42

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's strange. I would think previous is defined there. I'll look into it.

*
* @return {Object} Updated state.
*/
export function blockZoom( state, action ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the blockZoom reduce handle the case where a sibling of the zoomed blocks is inserted?
E.g: If add a paragraph, zoom it and then press enter the editor crashes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, definitely.

switch ( action.type ) {
case 'ZOOM_BLOCKS':
return action.clientIds;
case 'CLEAR_ZOOMED_BLOCKS':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add cases for remove and replace block actions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@epiqueras
Copy link
Contributor Author

epiqueras commented Jul 14, 2019

@jorgefilipecosta I like "focus" more too, but I thought there was some prior art to this. Here are the next steps:

  • Change the term "zoom" to "focus".
  • Integrate with undo.
  • Fix animation jump on last block when a new block is inserted.
  • Handle block insertion, replacement, and removal.

@jorgefilipecosta
Copy link
Member

Regarding this step Change the term "zoom" to "focus"., feel free to ignore it for now as it was just a thought and other people may think differently.

@epiqueras
Copy link
Contributor Author

epiqueras commented Jul 14, 2019 via email

@ZebulanStanphill
Copy link
Member

I would prefer "focus" to "zoom", since the latter makes me think of visually zooming into something, and I think that calling it "zoom" would cause many people to mistake it for something relating to accessibility. I'm not sure if "focus" is the best term, but I think it is better than "zoom".

@epiqueras
Copy link
Contributor Author

9928699 Block Editor: Lock all templates while zoomed.

I started by trying to support insertions, replacements, and removals, but I quickly realized that it would take a pretty widespread refactor due to a lot of assumptions we make in the logic for getting insertion indexes and other data. I don't think the need for this feature warrants those changes. This makes me think that we might have to try a different approach for #16485 where the editor just switches between editing the template and editing post content with a static post title component like it does now.

68dcb44 Block Editor: Fix animation jump on last block when a new block is inserted.

That seems to do the trick.

0061fc8 Editor: Clear block editor zoom before undos.

I looked at the approach taken in #16428, but I didn't want to reimplement what was done there and just add another property to the new object that gets sent between the editor and the block editor. I also think that this need will start to pop up more and like #12327 describes, we'll need to sync any reference to blocks in history. This encompasses quite a bit of data and it would be better if we come up with some sort of generalized solution.

I would prefer "focus" to "zoom", since the latter makes me think of visually zooming into something, and I think that calling it "zoom" would cause many people to mistake it for something relating to accessibility. I'm not sure if "focus" is the best term, but I think it is better than "zoom".

I'd say that focus is a term much more related to accessibility and that is actually my only concern with it. Focus is something applied to the currently edited field or selected button that gives accessibility tools' commands a target to operate on. I am not sure if it makes sense to reuse that term for what we are doing here.

@chrisvanpatten
Copy link
Contributor

I agree with the others that "Zoom" doesn't really accurately describe this feature. "Focus" is closer, but there might be other ideas too.

The main concern I have here is that I guess I'm not clear how things like — as in the example — background colors are handled. If you have a text block where you've applied a white color, but then zoom to the block, does there need to be some kind of accommodation to both (a) change the color to a visible color, and (b) prevent changing the color?

By removing the context of the containing block, attributes which are dependent on that context could become a bit thorny.

@talldan
Copy link
Contributor

talldan commented Jul 16, 2019

Looking at some other apps that have similar features

Workflowy and Dynalist are hierarchical note taking apps. They have a feature they also both call 'zoom'. In Dynalist click the little magnifying glass next to a note (https://dynalist.io/demo) and in workflowy click the bulletpoint itself (https://workflowy.com/demo/embed/).

Both use a little breadcrumb trail at the top to make it easy to zoom back out to the right place. Might be a consideration for this feature too.

@epiqueras
Copy link
Contributor Author

I started by trying to support insertions, replacements, and removals, but I quickly realized that it would take a pretty widespread refactor due to a lot of assumptions we make in the logic for getting insertion indexes and other data. I don't think the need for this feature warrants those changes. This makes me think that we might have to try a different approach for #16485 where the editor just switches between editing the template and editing post content with a static post title component like it does now.

We did end up taking a different approach. I'll close this for now.

@epiqueras epiqueras closed this Jul 24, 2019
@youknowriad youknowriad deleted the add/block-zooming branch July 25, 2019 09:43
@swissspidy
Copy link
Member

@epiqueras Curious, was there any follow-up PR to this, or is this off the table for now?

@epiqueras
Copy link
Contributor Author

The new modes introduced in #16565 are sort of an evolution of this.

https://github.com/WordPress/gutenberg/blob/d4f48403611fb6812af61eff789fcaf71592bf8a/packages/editor/src/editor-modes.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Block editor /packages/block-editor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants