We are working on a product that has to connect inputs and outputs together of different items. There can be hundreds of I/Os for each item and 1 O can go to many Is, but each I can only accept 1 O. Inputs can also accept an input from the end user and Outputs can also display to the end user. Inputs in each item could be optional or required.

We have already figured out how to make the connections together between the items (opening a modal which shows a list of all of the I/Os for that item with a search and, when clicking on the I or O, seeing what can be connected to it, since the list gets limited based on what type of unit the I/O is expecting/providing), the problem we're stuck with is how to display all of the connections so users can edit them in a way that isn't overcomplicated.

The ideas we've come up with and then thrown out:

We started thinking of something like a flow diagram (like omnigraffle) because it's easy to see the flow of I > O. The problem is it becomes very complicated as connections criss-cross and lots of items can connect to the same other item (so item 1's Output A is connected to item 2's Input A and item 3's Output C is connected to item 2's Input B, etc.) and each item's Os can connect to many other items. Along these lines we thought of a flow diagram that was done with words instead of boxes and broken down all the way down to the I/O (so only showing all of the I/Os and having a step down to each thing it's connected to). This would also allow you to link to a group of outputs if it's already used. words connected diagram

We thought of collapsing common connections between many items into a single line and expanding the line on click to show the many connections that exist in the single line, but this still doesn't really solve the problem of potentially thousands of lines.

We thought of zooming levels and making groups of items that are all linked together and having a high level where it just shows that there is a connection between the groups. Problem with this is that you can have a lot of groups and it would just become just like the lower levels unless you trust a user to know that they would have to make groups inside groups to be useful (which could be explained in a tutorial/best practices area).

The other way of thinking about it is using a long list of all items and having each drop down to show the I/Os and having the text under each for what it's connected to, if connected, or just saying "Not connected". If the I/O is connected you could click on the name of what it's connected to and it would scroll to that item. The problem with this idea is that it's not very user friendly as a user would have to scroll the entire list to find what they're looking for/would have to click through connections to find the item they are looking for.

We tried pulling ideas from things like omnigraffle, but it seems that it has the same exact issues we are trying to solve. We also looked at things like database map tools which, yet again, had the same issues. At this point our designers are stuck and are looking for a fresh set of eyes on the problem and trying to see if there's anything out there that we could pull some type of inspiration from.

  • Have you looked at ifttt.com? They manage to make it easy for a user to connect lots of possible outputs from lots of possible sources to any one of lots of possible inputs on lots of destination services. Sep 9, 2016 at 7:41
  • Simulink's Bus objects are very, very close to your requirements if you want to go the visual route. However, I'd recommend the tabular approach mentioned below.
    – pmf
    Oct 6, 2017 at 9:01

3 Answers 3


I might suggest looking at the way these issues are handled in the world of audio mixing software and node-based video compositing, and also visual programming languages.

First of all, modular synth and audio patchbay software need to do this sort of thing all the time, patching the input from one thing into the output of others:

virtual audio patchbay software

You can look here for a bit more on modular synths:


Node-based video compositing has a similar need to flow from one or several inputs through many processing "nodes" and then eventually out to one or more video outputs - programs like Shake, Smoke, and Fusion all use this model, and there are also hybrids with layer-based compositing tools like After Effects:

Node-based video compositing

enter image description here

enter image description here

Here's some detail on the difference between node-based and layer-based software:


Finally, visual programming languages provide similar complex-flow interfaces:

enter image description here

Here's an article on VPLs through the ages and some of their interfaces:


None of these may be exactly right, but they might provide you with some ideas. Good luck, and please share your final product!


In terms of representation, it sounds like what you're describing is a graph right? There's no hierarchy as such, you can have cycles in the routing?

As you've found out, drawing this as a network gets messy when edge crossings occur - it's revealing that the examples in MattyNabib's post still only have a couple of dozen nodes each and about the same number of links - and they have proven to be the major barrier when getting people to understand visualisations of such structures. (Google Scholar has 4,920 articles indexed with the term "edge crossing" and most are about how to minimise them or alleviate their effect)

The two approaches generally used to get round this are aggregation and/or filtering of some kind. You've tried aggregation on edges and weren't happy, what about aggregation on nodes as well? Then there's filtering, only show the edges emanating from a given set of selected nodes (again, usually the ones the user has currently shown an interest in)?

One alternative to try is a matrix representation which is often very useful for dense graphs as they have no edge crossings at all. Every node becomes a row and a column and the edges are represented as the cell at the intersection of a row and column. This also fits nicely with nodes being both inputs and outputs, rows can be nodes as inputs and columns can be nodes as outputs. The only drawback here is that path following between nodes becomes difficult (see DOI - 10.1109/INFVIS.2004.1 for a paper)

A Matrix View of a network

Probably the optimal representation is a hybrid of the two. Use a matrix representation for global overview and a local neighbourhood network graph for whatever the user is investigating or editing at the current time. Highlight the rows/columns in the matrix the local graph corresponds to to show the relationship between the two.

Also, and having worked on a project where linking two sets of nodes was an issue, see how much of the linking can be automated - is it all down to user expertise and choice, or can some of it be pre-computed?

  • Tabular is the way to go; allows for filtering so that for example when one input is selected, only compatible outputs will be shown.
    – pmf
    Oct 6, 2017 at 8:08

Scroll 2 lists?

As entities come under their respective cursors, you show the connection, if any. To reduce scrolling, for the case where the entity's name is known, you could autoscroll as the person types in the name. If there are entities without connections, or other conditions of interest, you could subset the list(s) on demand.

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.