How We Designed Routing Interactions

In this post, I’d like to give you a sneak peek into what is the most complex part of Diagrams, namely the routing interactions and the algorithms beneath them.

But first, let’s recap the meta-model and visualization principles outlined in the post about the app’s fundamentals. Every diagram you create in Diagrams consists of elements and relationships. These diagram objects are placed in the canvas and aligned to the ever-present grid. Consequently, the routes of all relationships have a shape of rectilinear paths going through the grid points. Each route is further divided into parts like segments, end points, and mid points as shown in the following overview.


If you hear the term routing algorithm you might think of automatic layout algorithms for graph visualization (like Graphviz). In general, those algorithms produce layouts for whole diagrams in a static manner without taking the user’s preferences into consideration. Although they can be integrated into interactive diagram editors where they can be triggered by a button click we strongly believe that they aren’t suited for such environments. Instead, we’re focusing on enabling smart interactions with diagram objects for performing individual layout operations. This is possible by leveraging the grid as mentioned before.

When a relationship between two elements gets created, its route is computed automatically. An existing route can then be adjusted indirectly or directly by the user. The indirect adjustment happens when one of the attached elements gets moved or when one end of the relationship gets re-attached to another element. The direct adjustment, on the other hand, happens when an inner part of the route (segment or mid point) is dragged to another position in the grid. The latter interaction is what we’re going to discuss here. In the following image, three sample cases of this interaction are shown. In each case, a mid point of the base route (thin) is dragged to a new position producing an adjusted route (bold).


The concept for this interaction has been evolving for the past few months and we went through many iterations along the way. What might seem very simple in the beginning becomes quite difficult once striving for an intuitive interaction which produces aesthetically pleasing results under all circumstances. While working on the initial research we analyzed our competitors. None of them offered a satisfying solution which confirmed our suspicions about how complex this topic is. The challenge was accepted!

After we made the initial drawings on paper, we looked for a way of putting the ideas into interactive prototypes. Unfortunately, this feature is so specific to our domain that the easiest way for us was to integrate it right into the application. When our ideas were confronted with the interactive environment and we had the chance to test them live for the first time, some assumptions were destroyed and we had to start working on the next iteration by incorporating what we had just learned. This process included reworking the concept, updating the implementation, and finally testing it live again.

We went through many iterations like this and I have to say it was pretty tedious work. We had to prepare concepts for individual route arrangements, ensure consistent behavior, and handle special cases (e.g. for routes covering attached elements or routes containing loops). The implementation was very math-heavy and it was often hard to wrap our heads around it, especially because it was changing that frequently. Visualization of the concepts was a helpful technique for us. In fact, we drew sketches on over 200 sheets of paper for this very feature, the route drag adjustment interaction.

After all this work and numerous alpha tests, we arrived at a promising result which includes some innovative concepts we haven’t seen anywhere else.

For example, we feature handles for route parts which have a unified look across points and segments. To increase the interactivity, those handles appear when hovering over the route parts and they change their appearance depending on the drag state.

We also took steps to improve the aesthetics of the resulting routes by reducing crossings with the attached elements and collapsing segments and eventual loops by visualizing the parts which will get cut off after completing the interaction.

Both concepts are demonstrated in the following recording of the development version of the app:

The final implementation is still in progress. In the next few weeks, we’ll handle even more edge cases, polish it and test it in an internal alpha version. After that, we’ll proceed with the interactions targeting the end points.

Are you curious about when you will be able to put your hands on it? We still don’t have a date but we’re slowly approaching the private alpha phase.

Yet Another Diagramming Application

People often tell us they know other solutions on the market that do something similar to Diagrams. They are right, those tools indeed do something similar. So why are we building yet another diagramming application?

Because Diagrams differs in a few fundamental aspects which have the potential to change the way people create structured diagrams. In this post, we are going to briefly introduce them to you.


We believe that diagram types with different layouts require different interactions. Supporting all possible diagram types in one application would mean dropping to the least common denominator of the interaction model and this would be a suboptimal solution.

This is why Diagrams supports only “structured diagrams” which are based on graphs. To put it simply, these are diagrams which consist of boxes (elements) connected with lines (relationships). This meta-model is universally applicable to a variety of diagram types like class diagrams, network diagrams, flowcharts, organizational charts, and many more.


Building upon this meta-model allows for interactions which are leveraging the specifics of elements and relationships. Among other things, this means that relationships stay connected to elements when moved.

Zero Distractions

Here is what we have figured out: Most tools out there are packed with tons of features. They attempt to support as many individual options and special use cases as possible. In our eyes, these are nothing but distractions. They keep you from focusing on the content of your diagram.

Even worse, those features create room for fiddling around with fine configurations of pixel sizes, layouts, colors, fonts, and so on. Although these settings are useful for graphic designers, they are certainly useless when creating structured diagrams.

This is the reason why Diagrams has no inspector pane on the right side of the application window, leaving more space for the canvas and therefore for your focused work. It’s almost like drawing on a paper.

Rethought Workflow

A lot of effort was put into designing the diagramming workflow right from the beginning of the development. For us, workflow optimization is all about speed, intuitive interactions, and standardization.


We truly believe in the visual nature of diagramming as we think that automatic generation of diagrams can never reach the same quality level as a human can produce. This is why an interactive canvas plays an essential role in the diagram creation process. The canvas is the entry point into the application and we’ve equipped it with streamlined interactions to make diagram editing a joy.

Furthermore, the canvas leverages a grid which simplifies the layout as it is used to align the elements and relationships in the diagram. It prevents you from losing focus by fiddling with alignments and size adjustments. This feature is so essential that it sits at the core of the application and it is reflected in most canvas interactions.

There is also no need to set the size of your diagrams manually. Just grow them as big as your structures demand. Diagrams has an infinite canvas which will adapt to the size of your diagram.


Diagrams follows a, what we call, “creational approach”. This means that instead of applying random visual attributes to generic shapes you pick the types for your elements and relationships from a palette at the time of their creation. Each type defines the visual attributes which leads to ensured consistency among all its instances.


This might sound like a minor change but it’s actually a deal breaker as this approach allows working in a semantic manner. When working on a diagram of a particular type the palette would show only the relevant element and relationship types from which you can choose. So if you are creating a class diagram, for example, you’re actually adding a class element and an inheritance relationship instead of a rectangle with a text field and a line with a non-filled arrowhead.

Native Application

Last but not least we believe that only native applications can deliver the user experience you deserve. We don’t compromise in this regard and therefore we’re building a native application which feels at home on macOS.

Stay Tuned!

Hopefully, we could illustrate that we’re doing everything we can to help your brain stay focused while removing clutter at the same time. That’s how we understand the user experience.

There is more to show. We can’t wait to share some more in-depth insights with you during the next months. The further we are in development, the more details we will be able to talk about.

But for now, let’s get back to Xcode.

Hello World!

Hi there, this is Lukáš.

I’m the founder and developer of Diagrams, an upcoming Mac application for creating structured diagrams. In this post, I’d like to introduce you to this project which I have dedicated my life to for the last few years.

I came into software development in one of the weirdest ways possible: Before I started programming, I taught myself UML, the visual modeling language for describing software systems. Despite the controversy about the usefulness of UML and the processes it is usually connected to, I saw greater value in its way of visual representation.

Since I’m a visually oriented person, I still do a lot of drawing when developing software nowadays. This helps me to structure my ideas and possibly to come up with better architectures in the end.


As I was looking for a digital solution which would support my workflows on the Mac, I wasn’t able to find any suitable applications.

The UML editors supported the logic, but looked really crappy, and were overloaded with tons of unnecessary features.

The vector graphics editors, on the other hand, were not designed with the logic in mind. I had to fight the features specific to graphics editing as well as the flexible formatting and layout possibilities.

These tools were too complex for my needs. I wanted something as simple as a plain paper with all the benefits of the digital world. This is why I decided to build it myself. In the form of a truly native macOS application.

MacBook Pro.jpg

Currently, the app is under development. The core architecture of the app is finished and a few internal alpha versions were already released. But there is still plenty of work to be done. You can expect the public release to come later this year.

Over the next weeks, we will reveal more details about Diagrams on this blog. We will explain where it tries to innovate and improve on the existing tools. We will share further concepts, show off some bits from the design process, and discuss individual features.

If you’re interested in these topics you should read this blog, subscribe to our mailing list, or follow us on Twitter.

Stay tuned!