Removing a topology node is unclear

[grdw]

Hitting the delete key is a bit to obscure.

Options to consider:

1

Remove button on the bottom right of the form menu:

---

2

Another alternative (although more complex) would be for a clicked node to transform into "Add" and "Remove" buttons:

     _|_            ___|___
    (   )    ->    ( - | + )
     ‾|‾            ‾‾‾|‾‾‾

From here.

---

3

Another option would be something as implemented here:

---

4?

Other ideas are welcome

[grdw]

Ping @antw @ChaelKruip if I could get your opinion 👍

[antw]

(2) and (3) are my favourites.

(3) looks a little cluttered, but I think that's just because of the two "add node" buttons in that screenshot. In our case the button would be part of the pop-up, so it wouldn't look as busy. It might be preferable to show it below the node instead of above, to avoid covering up the parent nodes and to emphasise that the + adds a child?

I suppose (2) could be implemented identically to (3) by positioning the pop-up exactly in the center of the node, so that the circle is behind the pop-up and not visible.

I have no strong preference really; (3) is more future-proof if we add more buttons later. Which do you prefer @grdw?

[grdw]

(3) is more future-proof if we add more buttons later. Which do you prefer @grdw?

(3) Because it's been proved to be working in multiple mindmap tools I've seen thusfar and it's futureproof because we might probably be adding more interesting buttons and features in the future.

[ChaelKruip]

I actually think (1) allows us to keep the topology view less cluttered than (2) and (3) but might become confusing because you would use the same dialog to change attributes of the node and apply operations to the node.

I think (3) has my (slight) preference because it makes a clear separation between things about attributes (in the dialog to the right) and things related to topology-building...

But I am willing to go with @grdw personal view.

[grdw]

I'm now at a stage where it looks like this:

The position is a few pixels of (that's due to the dragging of the tree). My guess is that there's some rounding in the left position of the g-tag and. To get to the point, this is functional but it doesn't look all to great.

The popup will probably be styled differently and that's fine. Just as the remove button. The thing is that the + button now sort of just 'hangs' there.

Another idea is to just spell out what it actually does:

If I move the + svg as a button inside of the popup I'm sort of finding it way more logical:

And to make it even more small and minimal:

[antw]

If I move the + svg as a button inside of the popup I'm sort of finding it way more logical:

Definitely agree. :+1:

[antw]

... although I would prefer slightly different wording, since one adds a child node and the other removes the selected node. I think we should shy away from using the word "node" in the frontend, since it's a data-structure term, and "component" is more descriptive to end-users.

What about: "Add child component" and "Remove this component"?

[grdw]

I'm sort of inbetween (2) and (3) at the moment 😆

I like to keep it as the last image in my previous comment (if anyone objects, please say so). I think the trash icon is actually pretty clear in this context.

When there'll be more features in the future we can expand the amount of buttons quiet easily;

Like a 'shuffle this node to a random other position feature':

[grdw]

One problem though: I'm able to drag the popup outside of the container 😢 (as shown in the image). I'm trying some weird combination of z-index'es but can't seem to find the ideal solution. Maybe I need to include the elements in the d3 graph?

@antw do you have an idea about how to solve this problem?

[antw]

@antw do you have an idea about how to solve this problem?

Maybe hide the popup whenever the user starts dragging by hooking into the zoomListener function somehow?

Or detect any mousedown inside the tree which isn't on a node or the popup, and hide the popup? This doesn't help if the user clicks the node and drags though (although it would be nice to not trigger the drag behaviour if the mousedown target is a node/popup (final bullet point here)).

If not, perhaps it's possible to wrap the <svg> element inside a <div> with overflow: hidden set?

<div style="overflow: hidden">
  <svg><!-- ... --></svg>
  <popup-element><!-- ... --></popup-element>
</div>

[grdw]

If not, perhaps it's possible to wrap the

with overflow: hidden set?

Yes that is the fix! 👍

However, I also needed this.

[grdw]

it would be nice to not trigger the drag behaviour if the mousedown target is a node/popup

It doesn't do this when it's a popup 👍 . It does do it when it's a node 👎 . I'm able to capture the event target when I'm zooming like this:

if (d3.event.sourceEvent.originalTarget.nodeName === "svg") {
   ...
}

This means that I only apply the transition of the svg when my initial mousedown was on the svg. However when I hold my mousedown on the circle and even barely move out of the circle my zoomListener does go into effect resulting in a really stuttery zoom (because I'm moving in and out of the circle).

Another approach would be to remove all zoom listeners from a certain d3 element like this:

d3.select("circle").on(".zoom", null);

However, the zoomListener is attached to the svg and therefor to all the elements inside the svg. So I'm a bit fiddling still but thought I might give you a status update 😄

[grdw]

Created a separate issue here https://github.com/quintel/etmoses/issues/1498

Closing this issue.