I have an application that allows users to create and edit graphs. The interface is a simple drag & drop UI that allows creation/deletion of nodes and edges. Nodes contain some internal configuration, therefore clicking on a node will open up an editor in a sidebar to edit the node-specific settings. Edges are added by clicking on a node's handle (the black dots in the image below) and dragging to another node's handle.

enter image description here

Some sub-graphs represent a specific logical unit in the context of the domain of the application. In order to simplify application flow, I want those sub-graph to be shown as a single node, which can then be somehow expanded (or zoomed in).

Consider this example:

enter image description here

Let's say that Node 2 and Node 3 are part of a single logical unit, let's call that Logical unit node. Then I'd like the graph to be displayed like this, by default:

enter image description here

Edges would be rendered by this logic:

  • for each node n not in the logical unit, if there's a node in the logical unit that has an incoming edge from n, draw an edge from n to the logical unit node
  • for each node m not in the logical unit, if there's a node in the logical, unit that has an outgoing edge to m, draw an edge to m from the logical unit node.

My question is: what would be the best way to allow the user to zoom in and out of the logical units, while minimizing excise and cognitive load?

The first approach I thought of was the following: when a logical unit is expanded, its inner graph replaces the view of the current graph entirely, so you only see its nodes, and there's a back button to go back to the main graph. This is optimal if the goal is to reduce useless information on the screen, but doesn't work well if the user wants to focus on the sub-graph while also working on the rest of the main graph.

Also, adding edges from nodes outside the logical units to ones inside of it becomes pretty difficult. One thing I thought of is that, when a node is drawn from a node to the logical unit, a dialog pops up showing the unit's inner nodes, and you select the one(s) that the edge is connecting to, but I believe this could be too cumbersome.

Another alternative I thought of is to expand the sub-graph in the main view, like this:

enter image description here

This wouldn't work well if the sub-graph is too large, though.

How can you make this workflow lighter and user-friendlier?

  • Not related to the core of the question but: Does "clicking on a node's handle (the black dots in the image below) and dragging to another node's handle" mean that I have to hit a relatively small dot on the drag target rather than the much bigger rectangle of it? Mar 1, 2023 at 3:07

1 Answer 1


You don't need to reinvent the wheel here. There are some excellent node editors out there which you can just copy existing behavior from. For example, blender:

blender node group example

As you can see, it takes both of your concepts and uses them, where you can have groups which can be tabbed into to reveal the internal structure, as well as frames which denote areas in the graph which do specific things. You'll also note that the second output of a node isn't dashed, but that the edges all have the same properties - except that they're colored by the data type they carry (here, a single value gets implicitly converted to a color and thus changes color midway through). Also, the values of a node are directly accessible.

Anyway, point is: What you are trying to do has been done before, and if you're doing it again, it's generally a good idea to follow their workflows right up to the point where they become illogical, janky, or otherwise undesirable. Doing something different to the competition just so you can do it different won't earn you any brownie points with your users in much the same way that changing the shortcut for "save" to Ctrl+V won't.

And lastly: Do user tests! You cannot draft up the ideal behavior on paper (and neither can I), because it's not up to us to decide what proper usability looks like. It's our users who determine if the way we communicate with them through the UI is sufficiently understandable, pleasant to use and such.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.