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

Enhance the tools for selecting child/parent blocks #9628

Closed
jasmussen opened this Issue Sep 5, 2018 · 17 comments

Comments

@jasmussen
Contributor

jasmussen commented Sep 5, 2018

Selecting the parent of a block is not quite as easy as it should be. For some blocks, such as Columns, it can be fiddly to select the right block to apply changes to. Selecting the inner block might be easy, but due to overlapping outlines, selecting the parent might not be.

Let's explore ways to make this easy and obvious so that Gutenberg can scale to more complex blocks with additional inner blocks.

Breadcrumbs

The first improvement we could make, could be breadcrumbs. In the top toolbar we'd always show the selected block, or the selected block and its parent:

model a blockquote with passthrough prop

☝️ Note: This mockup assumes the blockquote becomes a container for inner blocks, which it isn't yet. But in this case, it illustrates that we have selected a Paragraph inside a Quote block. You can click the Quote icon to select the quote.

If the block doesn't have any inner blocks, it's just a block type indicator, which has been requested many times.

In order to be an unobtrusive interface, yet still be there when you need it, we'd only ever show two levels of nesting here. For example if you had selected a paragraph inside a quote inside a columns block, we'd only show the quote and the paragraph. Clicking the quote would then change the breadcrumb to show the columns block and the quote block.

Click-through

For more complicated blocks, such as the Columns block, we should look to existing desktop apps and mobile solutions for patterns to emulate. One consistent pattern is to group things together and require you to drill down into the group in order to manipulate contents. This is a pattern you might see in Illustrator or Sketch, where you double-click to enter a group. Or in MacOS where when you enter Overview mode, you see previews of all open apps, but you have to select an app before you can manipulate its contents.

It is also already, in a way, a pattern we employ in Gutenberg, where the selected block can show additional controls.

Here is a Cover Image hovered. Note how even though the Heading block inside is hovered, it's the Cover Image block that's highlighted.

model b 01 cover image hovered

Here, the Cover Image is selected. Now inner blocks are made manipulable:

model b 02 cover image selected

When you select an inner block, it is now selected. The parent block is still shown because both are part of a group.

model b 04 cover image child selected

Complementary Features

This would be two ways to make it easy to select parent and/or child blocks with simplicity and confidence.

The features would be designed to work together. For example we might want to enable the "click-through" by default on all blocks that have inner blocks, but provide an optional "passthrough" property which blocks could declare if they felt they could do without the click-through tools.

For example when the blockquote receives innerblocks, we'd probably want to disable the clickthrough for that block as it's rare that you need to select the quote itself, and when you need to do that, the breadcrumb might be sufficient.

We might also find that the Cover Image used in these mockups works well as is, without the need for a clickthrough. But it is very likely that the clickthrough will make managing the Columns block that much easier — one click to select the columns block and apply an alignment, another click to select an inner block.

Next Steps

Your thoughts are welcome.

We will also want to explore additional features for complex blocks, such as slideshows where an inner block might be out of view depending on the implementation of said block.

But as a start, these two features might make a positive impact. Already today, the "clickthrough" is implemented on mobile, so it would be a matter of refining that, and expanding it beyond that breakpoint.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Sep 5, 2018

Contributor

I like the breadcrumbs idea. (Actually, I suggested something pretty similar in #6459 back in April.) What would happen with the breadcrumbs when Unified Toolbar is enabled?

I also think the click-through idea is good too, and it is already used on mobile, so it adds consistency. I am not so sure about the passthrough idea, though; I imagine that could cause confusion due to different behaviors across blocks.

Contributor

ZebulanStanphill commented Sep 5, 2018

I like the breadcrumbs idea. (Actually, I suggested something pretty similar in #6459 back in April.) What would happen with the breadcrumbs when Unified Toolbar is enabled?

I also think the click-through idea is good too, and it is already used on mobile, so it adds consistency. I am not so sure about the passthrough idea, though; I imagine that could cause confusion due to different behaviors across blocks.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 5, 2018

Contributor

I like the breadcrumbs but I also like the unified toolbar. Can we find another position for the breadcrumb :)

Also, I personally don't like the borders around the parent block. But if we keep them, how do we treat multiselection :). Should we show borders around multiselected blocks' parent?

Contributor

youknowriad commented Sep 5, 2018

I like the breadcrumbs but I also like the unified toolbar. Can we find another position for the breadcrumb :)

Also, I personally don't like the borders around the parent block. But if we keep them, how do we treat multiselection :). Should we show borders around multiselected blocks' parent?

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Sep 5, 2018

Contributor

I like the click-through option. This will require some additional work on the 'passthrough' block (so each individual "column" isn't considered a layer to click through, for instance) but I think it makes a lot of sense.

Contributor

chrisvanpatten commented Sep 5, 2018

I like the click-through option. This will require some additional work on the 'passthrough' block (so each individual "column" isn't considered a layer to click through, for instance) but I think it makes a lot of sense.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 6, 2018

Contributor

What would happen with the breadcrumbs when Unified Toolbar is enabled?
I like the breadcrumbs but I also like the unified toolbar. Can we find another position for the breadcrumb :)

Good question. Quick and dirty mockup:

challenge

Yep, I see the challenge of the duplicate icon for the switcher. I think it's good to keep thinking about this. Also note how this design omits the document outline, which is blocked on #4287.

Also, I personally don't like the borders around the parent block. But if we keep them, how do we treat multiselection :). Should we show borders around multiselected blocks' parent?

I think it's important to show them as indicating the inner blocks are part of the parent group. They anchor the inner blocks.

Right now this is how multi selection works:

screen shot 2018-09-06 at 11 17 28

And this is what happens when you just select two child blocks:

screen shot 2018-09-06 at 11 18 19

In other words, in master we sort of have the parent border already, and we hide it when multiselecting child blocks. I actually think showing the parent border always, even in multi selection, makes sense when you're only selecting child blocks. But perhaps we should make multiselection different when the parent block is multiselected. So instead of highlighting every child block with additive layer effects, we only highlight the parent block. Would that work?

Contributor

jasmussen commented Sep 6, 2018

What would happen with the breadcrumbs when Unified Toolbar is enabled?
I like the breadcrumbs but I also like the unified toolbar. Can we find another position for the breadcrumb :)

Good question. Quick and dirty mockup:

challenge

Yep, I see the challenge of the duplicate icon for the switcher. I think it's good to keep thinking about this. Also note how this design omits the document outline, which is blocked on #4287.

Also, I personally don't like the borders around the parent block. But if we keep them, how do we treat multiselection :). Should we show borders around multiselected blocks' parent?

I think it's important to show them as indicating the inner blocks are part of the parent group. They anchor the inner blocks.

Right now this is how multi selection works:

screen shot 2018-09-06 at 11 17 28

And this is what happens when you just select two child blocks:

screen shot 2018-09-06 at 11 18 19

In other words, in master we sort of have the parent border already, and we hide it when multiselecting child blocks. I actually think showing the parent border always, even in multi selection, makes sense when you're only selecting child blocks. But perhaps we should make multiselection different when the parent block is multiselected. So instead of highlighting every child block with additive layer effects, we only highlight the parent block. Would that work?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 6, 2018

Contributor

I like the click-through option. This will require some additional work on the 'passthrough' block (so each individual "column" isn't considered a layer to click through, for instance) but I think it makes a lot of sense.

Yes, right now the column child block is presenting a few UI challenges. For example you can't insert a block before it, so why can you select it? It's a tremendously difficult technical challenge though, and I understand the challenges it involves. So I'm not suggesting this is easy.

Contributor

jasmussen commented Sep 6, 2018

I like the click-through option. This will require some additional work on the 'passthrough' block (so each individual "column" isn't considered a layer to click through, for instance) but I think it makes a lot of sense.

Yes, right now the column child block is presenting a few UI challenges. For example you can't insert a block before it, so why can you select it? It's a tremendously difficult technical challenge though, and I understand the challenges it involves. So I'm not suggesting this is easy.

jasmussen added a commit that referenced this issue Sep 6, 2018

Remove additional side padding from blocks.
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.

jasmussen added a commit that referenced this issue Sep 6, 2018

Remove additional side padding from blocks.
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.

jasmussen added a commit that referenced this issue Sep 12, 2018

Remove additional side padding from blocks.
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.

jasmussen added a commit that referenced this issue Sep 20, 2018

Remove additional side padding from blocks.
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.

jasmussen added a commit that referenced this issue Sep 25, 2018

Remove additional side padding from blocks.
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.
@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Sep 25, 2018

Contributor

As I was working on #9653, I realized that the arrowkey navigation we already have present for navigating the hierarchy (use the arrow key up when a column is selected to select the parent, i.e. the columns block) is working really well. So well in fact, that perhaps simply surfacing this feature as an "up" button, similar to "go to parent folder" in the Windows file explorer, could be sufficient instead of full-on breadcrumbs.

Here's how that could look. Top toolbar:

top toolbar

Block toolbar:

block toolbar

CC: @youknowriad

Contributor

jasmussen commented Sep 25, 2018

As I was working on #9653, I realized that the arrowkey navigation we already have present for navigating the hierarchy (use the arrow key up when a column is selected to select the parent, i.e. the columns block) is working really well. So well in fact, that perhaps simply surfacing this feature as an "up" button, similar to "go to parent folder" in the Windows file explorer, could be sufficient instead of full-on breadcrumbs.

Here's how that could look. Top toolbar:

top toolbar

Block toolbar:

block toolbar

CC: @youknowriad

mtias added a commit that referenced this issue Sep 25, 2018

Remove additional side padding from blocks. (#9653)
You may have noticed that the padding left and right on a block is wider than above and below.

This was done in effort to make it simple to select the parent block by simply hovering it with the mouse. Arrow keys already traverse up to parent blocks and there's a clickthrough effect on mobile.

However in practice this additional padding has not felt sufficient, and was at the cost of some visual complexity. Instead, we'll be looking at improving parent child selection in #9628.

This PR thus reverts the style of this to how it used to be, with the same padding all around a block.

Reminder: this padding is purely visual — through negative margins, it doesn't actually affect the width of the block itself, or the margins above and below. See also #8350.

@mtias mtias added this to the 4.1 milestone Sep 26, 2018

@tomjn

This comment has been minimized.

Show comment
Hide comment
@tomjn

tomjn Oct 2, 2018

Contributor

Some thoughts

Breadcrumbs

I like the breadcrumb solution, but it suffers from ambiguity, an icon only interface can be problematic and I can see myself hovering over icons to see what they are, or confusing the breadcrumbs for a toolbar of options rather than breadcrumbs.

So perhaps the top toolbar is not the best place to show it, and perhaps some cues from breadcrumbs elsewhere would help. For example, the hierarchy toolbar in PHPStorm that shows the file -> class -> method/function you're currently in, or the folder toolbar in MacOS Finder and Windows Explorer?

screenshot 2018-10-02 at 18 02 34

Click Through

Click through would be a hidden UI, I can see lots of misunderstandings and confusion as people expect to select an image block only to find the containing column block is selected. Usually click through UI in Adobe software is confusing as it introduces modes, and it's difficult to tell where you are and how to exit it, especially if there's nesting. E.g. if you double click to enter a child block, how do you get back to the parent block and how does the UI indicate that you're inside a block?

There's a lot of research and guidelines out there about modes, and something shouldn't be considered good because it's present in Illustrator or Photoshop, a lot more work needs to go into it than just click through before it becomes a suitable solution.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

This is ignoring all accessibility factors this messes with too.

The Up button

The up button idea is nice. My concern would be that it implies that if you press it, a down button will appear and the block will move upwards, it's ambiguous and suffers the same problems the breadcrumbs block did

The Reusable Blocks Pattern

Right now reusable blocks already have a UI pattern that adds chrome to the block interface that isn't visible on the frontend. Could columns not do the same?

screenshot 2018-10-02 at 18 08 33

Or a super rubbish mockup of what I mean

screenshot 2018-10-02 at 18 09 40

Thus, the chrome of the columns block would be what gets used to select it, and it provides something that's visual to aim the mouse at.

Contributor

tomjn commented Oct 2, 2018

Some thoughts

Breadcrumbs

I like the breadcrumb solution, but it suffers from ambiguity, an icon only interface can be problematic and I can see myself hovering over icons to see what they are, or confusing the breadcrumbs for a toolbar of options rather than breadcrumbs.

So perhaps the top toolbar is not the best place to show it, and perhaps some cues from breadcrumbs elsewhere would help. For example, the hierarchy toolbar in PHPStorm that shows the file -> class -> method/function you're currently in, or the folder toolbar in MacOS Finder and Windows Explorer?

screenshot 2018-10-02 at 18 02 34

Click Through

Click through would be a hidden UI, I can see lots of misunderstandings and confusion as people expect to select an image block only to find the containing column block is selected. Usually click through UI in Adobe software is confusing as it introduces modes, and it's difficult to tell where you are and how to exit it, especially if there's nesting. E.g. if you double click to enter a child block, how do you get back to the parent block and how does the UI indicate that you're inside a block?

There's a lot of research and guidelines out there about modes, and something shouldn't be considered good because it's present in Illustrator or Photoshop, a lot more work needs to go into it than just click through before it becomes a suitable solution.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

This is ignoring all accessibility factors this messes with too.

The Up button

The up button idea is nice. My concern would be that it implies that if you press it, a down button will appear and the block will move upwards, it's ambiguous and suffers the same problems the breadcrumbs block did

The Reusable Blocks Pattern

Right now reusable blocks already have a UI pattern that adds chrome to the block interface that isn't visible on the frontend. Could columns not do the same?

screenshot 2018-10-02 at 18 08 33

Or a super rubbish mockup of what I mean

screenshot 2018-10-02 at 18 09 40

Thus, the chrome of the columns block would be what gets used to select it, and it provides something that's visual to aim the mouse at.

@alexislloyd

This comment has been minimized.

Show comment
Hide comment
@alexislloyd

alexislloyd Oct 11, 2018

One potential UX pattern we could use here that would fit with our toolbar model is the OS X folder traversal button: https://cld.wthms.co/avtQLO

I would note that I think users will expect to be able to select child / parent blocks visually through clicking and selection, but obviously there is a lot of complexity in getting that right. The traversal pattern above could be a good first step and we could dive deeper on developing a more elegant solution in phase 2.

alexislloyd commented Oct 11, 2018

One potential UX pattern we could use here that would fit with our toolbar model is the OS X folder traversal button: https://cld.wthms.co/avtQLO

I would note that I think users will expect to be able to select child / parent blocks visually through clicking and selection, but obviously there is a lot of complexity in getting that right. The traversal pattern above could be a good first step and we could dive deeper on developing a more elegant solution in phase 2.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 11, 2018

Contributor

I adore that concept Alexis, notably for the more complex blocks as you mention. I love it so much I immediately ran with it and remixed a few of the mockups to illustrate your idea.

No selection:

no selection

Block selected:

parent selected

Nested block inside selected:

child selected

The folder traversal button popout open:

crumbs dropdown

☝️ I am kind of in love with that concept, it feels like it melts together all the ideas and feedback shared on this thread, making for a solid baseline to iterate from. Thanks so much for bringing that fresh perspective!

Contributor

jasmussen commented Oct 11, 2018

I adore that concept Alexis, notably for the more complex blocks as you mention. I love it so much I immediately ran with it and remixed a few of the mockups to illustrate your idea.

No selection:

no selection

Block selected:

parent selected

Nested block inside selected:

child selected

The folder traversal button popout open:

crumbs dropdown

☝️ I am kind of in love with that concept, it feels like it melts together all the ideas and feedback shared on this thread, making for a solid baseline to iterate from. Thanks so much for bringing that fresh perspective!

@tomjn

This comment has been minimized.

Show comment
Hide comment
@tomjn

tomjn Oct 11, 2018

Contributor

I love the dropdown with the visual tree, part of me thinks seeing the entire document in this format would also be helpful, and even provide a useful way to reorder things.

However on further thinking, I was reminded that we already have a selection mechanism like this, and a document outline in the info panel:

screenshot 2018-10-11 at 17 06 54

This could be enhanced with the styling in your mockup, and serve as an additional selection signifier. At the moment it only shows titles, but a version with a full block tree, and a selection indicator would be very useful

My only qualm is with the toolbar icon itself. it's yet another mystery icon with an arrow, and it's a button that isn't in Finder on MacOS by default unless you customize the toolbar. For those of us who are icon blind and unable to distinguish between icons easily, it's problematic

screenshot 2018-10-11 at 17 05 24

With the text label it's clearer, but without it most wouldn't know what it did without clicking on it:

screenshot 2018-10-11 at 17 05 15

Contributor

tomjn commented Oct 11, 2018

I love the dropdown with the visual tree, part of me thinks seeing the entire document in this format would also be helpful, and even provide a useful way to reorder things.

However on further thinking, I was reminded that we already have a selection mechanism like this, and a document outline in the info panel:

screenshot 2018-10-11 at 17 06 54

This could be enhanced with the styling in your mockup, and serve as an additional selection signifier. At the moment it only shows titles, but a version with a full block tree, and a selection indicator would be very useful

My only qualm is with the toolbar icon itself. it's yet another mystery icon with an arrow, and it's a button that isn't in Finder on MacOS by default unless you customize the toolbar. For those of us who are icon blind and unable to distinguish between icons easily, it's problematic

screenshot 2018-10-11 at 17 05 24

With the text label it's clearer, but without it most wouldn't know what it did without clicking on it:

screenshot 2018-10-11 at 17 05 15

@alexislloyd

This comment has been minimized.

Show comment
Hide comment
@alexislloyd

alexislloyd Oct 11, 2018

Looking good :) Can we try simplifying the icon a little for better legibility? Maybe 3 lines with a bit more spacing instead of 4?

alexislloyd commented Oct 11, 2018

Looking good :) Can we try simplifying the icon a little for better legibility? Maybe 3 lines with a bit more spacing instead of 4?

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 11, 2018

Contributor

With the text label it's clearer, but without it most wouldn't know what it did without clicking on it.

There will be a tooltip as well.

Contributor

mtias commented Oct 11, 2018

With the text label it's clearer, but without it most wouldn't know what it did without clicking on it.

There will be a tooltip as well.

@alexislloyd

This comment has been minimized.

Show comment
Hide comment
@alexislloyd

alexislloyd Oct 11, 2018

In re: @tomjn's comment, I also think it would be worth exploring if this could be integrated into the overall document tree rather than creating a separate place. The challenge there is maintaining the simplicity and scannability of the tree while accommodating a lot more levels of stuff. But maybe that can become more like the layers panel in Sketch or Photoshop (in functionality, not design!), where it's the single source of truth for the whole page structure. Challenging to do well, but maybe worth exploring?

Again, this is likely to be something we iterate on, so what's the most useful MVP that can grow into something more sophisticated?

alexislloyd commented Oct 11, 2018

In re: @tomjn's comment, I also think it would be worth exploring if this could be integrated into the overall document tree rather than creating a separate place. The challenge there is maintaining the simplicity and scannability of the tree while accommodating a lot more levels of stuff. But maybe that can become more like the layers panel in Sketch or Photoshop (in functionality, not design!), where it's the single source of truth for the whole page structure. Challenging to do well, but maybe worth exploring?

Again, this is likely to be something we iterate on, so what's the most useful MVP that can grow into something more sophisticated?

@tomjn

This comment has been minimized.

Show comment
Hide comment
@tomjn

tomjn Oct 11, 2018

Contributor

There will be a tooltip as well.

I don't think that's enough, but I think this is a separate discussion and a feature request, I'll open a new ticket

Contributor

tomjn commented Oct 11, 2018

There will be a tooltip as well.

I don't think that's enough, but I think this is a separate discussion and a feature request, I'll open a new ticket

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 11, 2018

Contributor

Can we try simplifying the icon a little for better legibility? Maybe 3 lines with a bit more spacing instead of 4?

I like that:

screenshot 2018-10-11 at 18 18 06

However on further thinking, I was reminded that we already have a selection mechanism like this, and a document outline in the info panel:

I also think it would be worth exploring if this could be integrated into the overall document tree rather than creating a separate place.

I think that could work. I've previously suggested that item could be rewritten as a plugin so it shows up on the right (see #4287). But I'm a fan of repurposing this for the document tree.

Regarding a label, I like labels, but the option to dock the block toolbar to the top needs to be considered in that light.

This discussion reminds me of #9053 (CC: @westonruter) — I think you might like Alexis' proposal as shown in #9628 (comment).

Contributor

jasmussen commented Oct 11, 2018

Can we try simplifying the icon a little for better legibility? Maybe 3 lines with a bit more spacing instead of 4?

I like that:

screenshot 2018-10-11 at 18 18 06

However on further thinking, I was reminded that we already have a selection mechanism like this, and a document outline in the info panel:

I also think it would be worth exploring if this could be integrated into the overall document tree rather than creating a separate place.

I think that could work. I've previously suggested that item could be rewritten as a plugin so it shows up on the right (see #4287). But I'm a fan of repurposing this for the document tree.

Regarding a label, I like labels, but the option to dock the block toolbar to the top needs to be considered in that light.

This discussion reminds me of #9053 (CC: @westonruter) — I think you might like Alexis' proposal as shown in #9628 (comment).

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Oct 11, 2018

Member

Great to see this moving on and thanks for the concept @alexislloyd. @jasmussen I really like these mocks and think we do really have a great point we can iterate from.

Member

karmatosed commented Oct 11, 2018

Great to see this moving on and thanks for the concept @alexislloyd. @jasmussen I really like these mocks and think we do really have a great point we can iterate from.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Oct 12, 2018

Contributor

so what's the most useful MVP that can grow into something more sophisticated?

I'd say building this as a simpler traversal control, and looking later to see if it makes sense to combine with the document content box based on selection.

Contributor

mtias commented Oct 12, 2018

so what's the most useful MVP that can grow into something more sophisticated?

I'd say building this as a simpler traversal control, and looking later to see if it makes sense to combine with the document content box based on selection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment