Hi,
��
Towards the end of��last year we worked on GT Connector, a new kind of interface that allows us to��exercise and test the limits (or the lack thereof) of��Bloc.
��
It looks like this:

��
You can see it in��action here:
https://twitter.com/feenkcom/status/936109463462965248
��
In the current��implementation, the Connector allows us to navigate and connect example methods. The focus is��not on examples, but on the connections. We used��examples because the engine��was already around and offered us a nice use case. We want to extend it in the��near future to other kinds of objects.

There are a couple��of things that are worth noting:

��� The editor works live, and��the connection points appear and disappear as you type.

��� The layout of the editor��elements is based on a tree-based graph layout that only works with��constrains (no actual visible edges between��the editor elements).

��� The editor works live, so��adding new elements to the scene properly rearranges the scene.

��� But, perhaps, the most��exciting part is the fact that the lines connect an element from inside��the text editor element with another that��lives outside of the editor��element.

��
All these validate��the architecture of Bloc of having exactly one rendering tree. It was not an��obvious goal a couple of years ago, but we are really��happy that it works.
��
To put it in��perspective, let's compare this with the html world. Text is text is rendered��through the DOM tree. If you want graphics you might use��something like SVG��which comes with its own tree. However, these are two distinct worlds, and you��cannot go from one to another, or at least not��easily. This is the case in most��engines we looked at.
��
Why is this��important? One thing we learn in the Smalltalk world is that covering the same��space with less concepts opens up a whole dimension of��creativity that is��simply not possible outside of it.
��
The goal with Bloc��is to enable new kinds of user interfaces. As we are late to the game of modern��interfaces, even though the field was invented in��Smalltalk, our only chance to��take the lead again is to rethink the model.
��
Let's look at the��Connector again. In most user interfaces we have panes on the outside, and��visuals confined within the boundaries of those panes.��Interestingly, we can��trace this pattern to the very first Smalltalk interfaces. In the Connector��interface we have no boundaries with text and��visualization being intertwined��to form a new kind of workflow.
��
Talking about��workflows, we now have two distinct and novel ways to explore examples: one is��Connector, and the other one is the expandable code��editor. For example, the scene from above looks like this in the example expanding editor:

��


Both of these interfaces are��not found in other infrastructures, and yet they were both inexpensive to��implement in Bloc.

We believe this will��have a deep impact for all sorts of interfaces, and especially for the IDE. If��you are interested in more details related to the IDE,��take a look at the��following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf
��
Please let us know��what you think.
��
Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"