flowy
flowy copied to clipboard
alyssaxuu
Insert a block between 2 existing blocks
Current behavior: Drag a new block between 2 existing blocks (parent and child) and the new block becomes another child of the parent.
Desired behavior: Drag a new block between 2 existing blocks (parent and child) and the new block inserts between the parent and child.
Ideally a block can identify the behavior it wants when dropped, e.g. "split" or "insert". We're going to add this behavior ourselves ... and will likely submit a pull request.
The reason we need this is when you are designing a complex drip sequence, you may want to insert a block between 2 existing items.
We're going to do the same thing with removing a block. The removed block's child we auto re-attach to the removed block's parent.
Note, we would identify the desired behavior as an attribute of the block itself (not something exposed in the UX). So, when given to our BlockManager the dragged block can indicate it's desired action...
I can see how that would be useful. I'm just wondering how it would behave though, from a user perspective? Would it have a modal that asks if you want to split or insert, would it be some keystroke, or would it use different "snapping areas" (e.g. instead of splitting when dragging a block under another one, it would only happen when dragging a block next to another one (so on the right or the left).
I can definitely think of a way to implement this at least where the developer can make the choice, for now (so like you said, setting the behaviour beforehand). But will likely be added in the next big release (if it is included at all).
I can't remember the exact method names but basically when the block gets dropped it would indicate if it should split (current behavior) or insert (new behavior).
I don't think it should be in the UX just because I tend to think of a block as a wholly independent object. For example a "conditionTextMessageReply" block.
The way I designed this is that a block manager calls renderDrag() when a block gets dropped in snapping(), e.g. conditionTextMessageReply.renderDrag(). The block manager can also query the block to see if it has properties, e.g. conditionTextMessageReply.hasProperties, to determine if the property window needs to be shown. This also can run checks to make sure that blocks are allowed to snap to each other. And, when saving the output(), loop through all the blocks and call validate() ... I could go on :)
Following that pattern, my plan was for a block to have a dragBehavior that could be "split" or "insert". So, when flowy is going to add the block it knows what behavior to apply. I haven't really looked into how to do that just yet.
I'd like to try and get the block manage functionality that I built packaged up, but I'd like to do it in a way that keeps flowy super simple and clean. So it would be something that could be used in addition to flowy, but not required to use flowy
I can't remember the exact method names but basically when the block gets dropped it would indicate if it should split (current behavior) or insert (new behavior).
I don't think it should be in the UX just because I tend to think of a block as a wholly independent object. For example a "conditionTextMessageReply" block.
The way I designed this is that a block manager calls renderDrag() when a block gets dropped in snapping(), e.g. conditionTextMessageReply.renderDrag(). The block manager can also query the block to see if it has properties, e.g. conditionTextMessageReply.hasProperties, to determine if the property window needs to be shown. This also can run checks to make sure that blocks are allowed to snap to each other. And, when saving the output(), loop through all the blocks and call validate() ... I could go on :)
Following that pattern, my plan was for a block to have a dragBehavior that could be "split" or "insert". So, when flowy is going to add the block it knows what behavior to apply. I haven't really looked into how to do that just yet.
I'd like to try and get the block manage functionality that I built packaged up, but I'd like to do it in a way that keeps flowy super simple and clean. So it would be something that could be used in addition to flowy, but not required to use flowy
I see, right, so you would set some properties to each block, and when the block is about to connect, it checks the properties assigned to those blocks - so supposedly within the block array itself.
I'm wondering though why you don't think it should become a new behaviour? Would it not be intuitive enough to allow for something like the following (maybe using a different sort of indicator, put that together really quickly):
Unless the problem is that dragging a block under another block is expected to turn the first block into a sibling of the last block's children, which would indeed make it counter intuitive and confusing.
Just throwing the idea out there, I think doing it programmatically is a good idea by itself but I'm always happy to expand on the interaction side of the library if it is seen fit.
I'd love to see it in the UX. 100%. But with a big emphasis on keeping it as super-simple as you've currently designed flowy.
Hello @alyssaxuu, @robhoward,
Such a method would also be very useful in our case. For instance, we have blocks that only accept one child. Thus, dragging a new block between this "one child block" and its child would automatically trigger the insert, instead of the "split".
Regarding the UI, here is a small idea. Assuming that a parent can have multiple children, but a child only one parent (as per #8 ):
If we drag a block to the parent's "blue dot", it would trigger a split:
If we drag the block to the child's "blue dot", it would trigger an insert:
Hello @alyssaxuu, @robhoward,
Such a method would also be very useful in our case. For instance, we have blocks that only accept one child. Thus, dragging a new block between this "one child block" and its child would automatically trigger the insert, instead of the "split".
Regarding the UI, here is a small idea. Assuming that a parent can have multiple children, but a child only one parent (as per #8 ):
If we drag a block to the parent's "blue dot", it would trigger a split:
If we drag the block to the child's "blue dot", it would trigger an insert:
That would definitely be way easier to implement. But I'm not sure if the behaviour here would be intuitive enough - it feels like there is little space between the two "snapping areas" so the user could mistakenly drop it into the wrong place. It also doesn't feel obvious (at least to me) which one would attach between the blocks, and which one would split.
that's elegant and intuitive. i like it.
Ok, just read @alyssaxuu comments too. She has a point.
I like it because the only time we have a forked parent/children relationship is when dealing with a condition (Yes/No). So this works for us similar to how it works for @johndkn
But I'm not sure if the behaviour here would be intuitive enough
I somewhat agree on that... May be adding a text label next to the blue dot would help ? Something like "Insert between" or "Add to block"
Here's another idea that could be used from a developer perspective. Using some sort of keystroke to distinguish between the two kinds of attachments. Just brainstorming.
