Gutenberg-mobile: Inner Blocks - Navigating Down in the hierarchy

[pinarol]

User should be able to navigate downward in the hierarchy.

Please take a look at the prototype to get a sense of how it should behave.

Block Focus/Visual Cues

Transparency

You’ll notice below that the selected parent and all of its children are fully visible – everything outside of that is semi-transparent (in this example, 20% opacity). This helps to draw the eye to the current selection, without losing focus of the wider picture.

Selection Indication

A selected block that has children gets a strong focus border (blue) and each child on the next level gets a dotted outline that hints at what’s inside.

[pinarol]

Let's also address padding changes from this comment

[jbinda]

Hi 👋

To navigate down should we render separate icon next to 'navigate up' button ?

Small Offtopic:
Navigation is just to make selecting block more user-friendly when we have many block. How about moving block in hierarchy - there are plans to implement this feature ? I've noticed that when you add block to some group there is no option to 'level-up' this block and IMO it will be quite comfortable because you do not need to recreate the block.

I wrote this because some of the logic may relay on the logic that I need to implement to deal with navigation and wonder

[pinarol]

To navigate down should we render separate icon next to 'navigate up' button ?

No need for that because navigating down should be available by just tapping. If you have chance to investigate the web version of any blocks that has InnerBlocks in it(like Group, Column, Media&Text) you can see that it has a parent first approach, when you first tap it focuses to the container block and if you tap again only then you’d be able to focus the child block inside it. We want the same thing on mobile.

[pinarol]

Navigation is just to make selecting block more user-friendly when we have many block. How about moving block in hierarchy - there are plans to implement this feature ? I've noticed that when you add block to some group there is no option to 'level-up' this block and IMO it will be quite comfortable because you do not need to recreate the block.

I wrote this because some of the logic may relay on the logic that I need to implement to deal with navigation and wonder

We don’t currently have sth in designs to move a single block upwards in the hierarchy but we have an ungroup functionality that needs to be added in the near future. Ungrouping can help but surely it is not the same thing so this can be a good enhancement. @iamthomasbishop

But technically, ungrouping means changing the hierarchy of blocks so you can use this info when building any logic. But if this is still unclear please reach out with some more info about that logic you are planning to build so that we might be able to help better.

[jbinda]

I have obtain the logic on web and try to implement it as much similar as possible on mobile.

I have also played with the opacity and dashed border when selecting Block which has some nested InnerBlocks. My question is what if we select e.g. image block which is on the same level with group block (and it is not the child of that group) We should also put opacity on the other blocks ? Or it is applied only when we select block with inner blocks inside ?

[pinarol]

My question is what if we select e.g. image block which is on the same level with group block (and it is not the child of that group) We should also put opacity on the other blocks ? Or it is applied only when we select block with inner blocks inside ?

@iamthomasbishop could you help with this one? 👆🏻

[iamthomasbishop]

@pinarol @jbinda If I'm understanding the scenario correctly, I believe the selected image block would be the only block at full opacity – the other blocks (sibling blocks in this scenario) would be dimmed. Only the selected block (and its children) would be 100% opacity.

[pinarol]

Let me ask one more question just to be sure. So even if there’s no nested block usage in the editor should we still use dimming ? Let’s say the editor has just pagargraph blocks in it, should we dim the unselected paragraph blocks? @iamthomasbishop

[iamthomasbishop]

So even if there’s no nested block usage in the editor should we still use dimming ?

No, if no blocks on the canvas contain children (no nesting) we shouldn't use dimming – at least for now. Although we should keep an eye on how this tests/feels when implemented, because it's something that could prove intuitive to add globally if appropriate.

[pinarol]

Ok thanks that was what i was thinking but just wanted to be sure. So for now we should use dimming only when someone selects an inner block. And we can decide if we want to make this global after trying it.

[jbinda]

@pinarol @iamthomasbishop can you take a look on this PR (https://github.com/WordPress/gutenberg/pull/17547) with navigation down and check if the GIT presents the logic to dim blocks that we discussed above ?

[jbinda]

I have also question about design:

1. I'm not pretty sure if I should apply some paddings inside blocks that are "border-dashed"
2. Probably I should also replace top and bottom border on selected block to be fully-bordered

I have also issue with RichText editor (Heading and Paragraph block) because it goes to editing mode after press on it. Do you know there's a way to lock the editor and do not show the text-carret ? Then I would be able to select parent block first. Please see on GIF how it works for rest blocks

[iamthomasbishop]

I'm not pretty sure if I should apply some paddings inside blocks that are "border-dashed"

There's a lot going on here, but in terms of padding, I believe the thought was that we should minimize or remove the padding on children to avoid so much whitespace (as discussed in this issue). I'm open to suggestions for how we'd achieve this (my thought was to add padding on the parent then slim down the children paddings so that the blocks don't move around on canvas – just the paddings/margins would adjust).

If we do have to keep adding additional padding inside every level of the hierarchy, let's at least slim down the padding to be more managable.

Probably I should also replace top and bottom border on selected block to be fully-bordered

I'm not exactly sure what you mean, it looks to me like top/bottom borders are fully-bordered in blue. Although I still noticed that the left/right borders aren't there (not unique to this issue), so we should definitely apply left/right borders to ensure consistency.

I have also issue with RichText editor (Heading and Paragraph block) because it goes to editing mode after press on it.

Do you mean the text input becomes active even though it's not yet the desired selected block? I'm not exactly sure what this looks like.

[jbinda]

I'm not exactly sure what you mean, it looks to me like top/bottom borders are fully-bordered in blue. Although I still noticed that the left/right borders aren't there (not unique to this issue), so we should definitely apply left/right borders to ensure consistency.

That's what I've asked :) If I should apply left and right border

Do you mean the text input becomes active even though it's not yet the desired selected block? I'm not exactly sure what this looks like.

Yes, I presents it in my answer to the PR here

I will also adjust the style according to what you wrote

[iamthomasbishop]

Awesome, thank you!

[jbinda]

Do you mean the text input becomes active even though it's not yet the desired selected block? I'm not exactly sure what this looks like.

Yes, I presents it in my answer to the PR here

I have fix this behaviour (big thanks to @lukewalczak for advise about give a try with pointerEvents="none" prop). Aztec Rich editor is wrapped in a View which gets mentioned prop after you pass it. The result is it disable all interaction with the Editor and that I was looking for.

I have also change the colour of the dashed border and apply left/right solid border when block is selected. Currently working on the margins and paddings.

[jbinda]

@iamthomasbishop

What value those margins should have ? The left/right border should be applied only for Group block or for other block as well ?

[pinarol]

Normally these changes should apply to all blocks which use InnerBlocks but since we don't have a good solution for https://github.com/wordpress-mobile/gutenberg-mobile/pull/1362 yet let's limit it to Group block temporarily. Otherwise it can block merging Media & Text.

[iamthomasbishop]

@jbinda that definitely looks a _lot_ better. It's already feeling much more clear. The border colors seem pretty solid, just strong enough but not overpowering. If this feels different in a live build I will make note of it during final design review, but looking nice.

What value those margins should have ?

The block contents optically should always be 16px, but the padding/margins should essentially adjust so that children appear inset. Here is a visual example:

⬆️ Top example is a normal "parent" block, and the bottom is child block of the parent. And note that the block content area (red highlight area) is the same size on both. So the contents of both of these blocks are inset 12/16px, but children are padded slightly differently so that they appear inset. Does that make sense?

With that said, I wouldn't be opposed to applying a slight inset to the parent (blue border above) to make it even more obvious – something like 4px on the left/right sides would be fine.

[jbinda]

@iamthomasbishop I updated the borders and it looks as presented on below GIF.

I still need to sort out the issue with margins on nested levels
Also when margin changes the block is resizing which do not looks very well but I'm not sure if we can avoid this because we apply 2 borders and additional margins when select the block. I think maybe adding some animations onFocus() will make this effect looks smoothier ?

What do you think ?

Normally these changes should apply to all blocks which use InnerBlocks but since we don't have a good solution for #1362 yet let's limit it to Group block temporarily. Otherwise it can block merging Media & Text.

I assumed that for other block the borders should like before which is without left/right part

[jbinda]

I also tried to align content of Group Block to out-of-the-group block. And it is quite difficult because there is only 16px each side. On this 16px we need to put 2 borders (dashed gray and solid blue) and keep enough space to make it look nice. Im not sure if I described my point clearly ?

However this is the best result I can set up at this moment. On previous GIF you can notice that the blue solid border is aligned with content of top block. Here the dashed border is aligned.

[iamthomasbishop]

@jbinda Thanks for the updates! Overall, this is looking _super_ close. The border styling is looking nice, although I have a couple of requests:

• In general, I'd like all selected blocks to span the full-width of the viewport, however...

• For any borders that are inset (and we're applying border-radius) we might want make give the parent (solid blue) a border-radius: 4px and the child (dotted) a border-radius: 2px

I also have a question regarding border positioning – are we applying border on the outside of each "box" or inside? The last example looks _inside_, which is fine, but I just want to make sure I'm on the same page, and if so we can apply an extra 1px inside (so that the border is _optically_ on the outside)

I still need to sort out the issue with margins on nested levels

This is the biggest thing remaining, I think. Ideally, all selected blocks should span of the container 100% width. This would essentially make all of the jumpiness go away, but the above demo certainly feels a lot better than previous iterations so we're on the right track.

[iamthomasbishop]

Sorry, I hit enter too soon 😄 Continuing feedback:

Also when margin changes the block is resizing which do not looks very well but I'm not sure if we can avoid this because we apply 2 borders and additional margins when select the block. I think maybe adding some animations onFocus() will make this effect looks smoothier ?

I'm not 100% sure what you mean here, but if I'm understanding you correctly, maybe removing the additional margins is the key? Also I'm open to seeing onFocus() animations/transitions, so if you try that, please share a visual 👍

I assumed that for other block the borders should like before which is without left/right part

I think _all blocks_ in general should have left/right border but we already have a separate issue for that.

On previous GIF you can notice that the blue solid border is aligned with content of top block. Here the dashed border is aligned.

This is also slightly better, can you send a GIF of this in action, so I can see how much jumping is happening?

[jbinda]

@iamthomasbishop this is the GIF with latest. I have also adjust dashed-border rounding to 2px and include 1px extra margin to achieve visual effect which you described on the border.

I have noticed that this "jumpy" effect appears when you select block group itself and keep working on it.

[iamthomasbishop]

@jbinda This is looking better with each iteration – I still think we should attempt to zero out the extra margins that are causing the jumpiness, but I think it's nearing the point where it's acceptable (even if imperfect). Can you tell me what the border-radius of the blue outline is so I can double check vs. my Figma file? It still feels a tiny bit off but I'm not sure why.

[jbinda]

In given example:
Blue solid borders have 4px margins
Dashed borders have 2px

[iamthomasbishop]

Ok, I'll apply this to my Figma styles, it looks rather nice. I'm fine with rolling with those border stylings.

Side note (don't let this block your progress on this ticket): I like the 4/2 border-radii so much that I'm starting to think we might want to apply this style universally (4px border-radius to all selected blocks). It especially looks nice if we bring the left/right padding down to 12px and apply 4px left/right margins as I think was previously mentioned but paused. This can probably be tackled separately. For reference that would look like so:

[jbinda]

@iamthomasbishop @pinarol

I have manage to change bahaviour of nested blocks. According to @iamthomasbishop said about margins in nested groups and this comment I have prepared below solution.

Combination of dimmed content and dashed/solid border will give us the feeling and clearly show the structure without loosing width in rendering the content. Please check below GIF:

Further more I said that will try to implement some animation and below I post 2 GIFs with animations:

1. Animate only on exit the block

2. Animate on enter/exit the block

Please note that the type of animation as weel as the duration can by adjusted :)

WDYT ?

[iamthomasbishop]

@jbinda Margins are much better. The animations feel a little odd in the two animated examples above. Some thoughts:

• The duration is a bit long, so it's exaggerated – I think a shorter duration (100-300ms?) would be a bit more fluid

• I'm not loving the "zooming in" effect this produces. It feels like when selected, blocks shrink then zoom in, it's a bit disorienting. Is there anything we can do to make it more fluid, going from "A to B" more fluidly without jumping?

• Would it make sense to try somehow transitioning only border opacity?

If none of the above feels better, we can ship with the first example you attached to your last comment (the non-animated one here.

[jbinda]

@iamthomasbishop

I also like the margins from 1st example :)

The duration is a bit long, so it's exaggerated – I think a shorter duration (100-300ms?) would be a bit more fluid

Yes it can be adjusted. I intentionally increase the timing in that case that you can observe what really happens

I'm not loving the "zooming in" effect this produces. It feels like when selected, blocks shrink then zoom in, it's a bit disorienting. Is there anything we can do to make it more fluid, going from "A to B" more fluidly without jumping?

We can also switch the animation e.g. to fade In/Out instead of zoom In/Out

Would it make sense to try somehow transitioning only border opacity?
It make sense and we can give it a try. I will need to verify if its possible

I also had been thinking about this animation yesterday and I agree that i needs to be polished (it was just initial concept to give you some feeling about that). Like you said I think we should ship this feature without animation and then is separate issue open a discussion and try to implement if we find something smooth and nice looking.