-
Notifications
You must be signed in to change notification settings - Fork 58
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
Group Block - appender behavior #1344
Comments
I've put together some thoughts regarding a better overall UX for the Group block and the appender, but this really applies to a variety of nested blocks contexts so I'm not sure if this is the best issue to drop my notes in. If it deserves to be in another issue or if I should create a master issue of sorts, I'm happy to do so. // cc @pinarol Appender Display LogicI'm not sure if this is already the case or in progress, but I think it would make sense to only show the inline appender on a new Group block (as is the case on Core GB). I think if we include it on anything beyond that, we will run into confusion. We can probably rely on the toolbar inserter primarily, because we get the nice added benefit of an "add block here" indicator, which makes it clearer where the block is being added. Selected Block StylingThe quickest win at this point would be to make sure the left/right borders on every block are there – this would provide a stronger visual cue. This isn't necessarily specific to this issue, but would be helpful. Here's the current, for reference: Child Blocks' StylingAnother thing we should consider doing is giving a block's children an outline, such as a dotted or dashed line. We might also want to give the appender this outline style so it aligns with the style of a child. This would require us to re-think the additional margins we're currently applying (more on that in the next section). I'm not exactly sure how we'd achieve this in code, but it'd look something like this: Insets MarginsA key problem I'm seeing is that we're relying heavily on visual margins, which in theory provides a little visual cue that something is nested. However, once you get a few levels deep, it's almost unusable, as was noted by @mkevins: Considering the upcoming work to implement a hierarchy navigation toolbar, I think we should go one of two routes. Either:
If there are other suggestions, I'm all ears. Navigating HierarchyRight now, because we are using the margins described above, we give the user 16px tappable area to move to the parent block. This is fine in theory, but it's very challenging because of the small tap area. If we remove most of or all the additional margin, we should rely on the upward navigation tool in the floating toolbar to go to the parent block. Selected Parent HighlightingWe've had some discussion around showing an additional outline on the parent of the currently-selected block. It sounded like the plan was to hold off on this and focus only on the selected block (and as mentioned above, a potential dotted/dashed outline of its immediate children). UngroupingWe also don't currently provide the user with a way to ungroup a Group block. While we can rely somewhat on FlowHere's kind of a birds-eye view of the flow that I am using for reference as I'm working through these reviews: |
Thanks @iamthomasbishop I have linked your comment to other related issues. Let's only change the |
According to border and margin styling in this PR I think approach took there will solve the issue with Appender behaviour. |
I am quoting this item from this comment to be solved part of this issue |
I have applied dark-mode to appender here #1379 |
It's necessary to revisit the appender behavior once issues such as: #1315, #1314 will be finished.
Generally, that issue is about appender UX needing adjustments, because current one is not perfect - it's hard to use with finger tapping.
For more details, please check the conversation within the first group block PR
The text was updated successfully, but these errors were encountered: