Just wanna show my editor concept

[ern0]

I just want to show my editor concept for you, which I've made a year
or two ago.

Probably, you've heard my story, but probably not: with my friend,
we've made a dataflow system years ago, for automation, home
automation purpose. We call it "Prototype", because after we've
brought it to life, we've recognized we've missed some important
things: proper multithreading, data packets (it handle only integers
and triggers), arrays etc. Editor! We have no editor for the
Prototype, only a GraphViz based script-to-image converter. So, as we
recognized that we have to learn lot in the topic, we decided that
we'll start a new engine/system when we're ready for it. We're almost.

Meanwhile, I've made an editor concept based on SVG, using Rafaelj.js,
here it is:
http://linkbroker.hu/ihome/editor/

It has minor glitches, but you can see the look-and-feel.
--
ern0
dataflow evangelist

[Paul Morrison]

Hi Ernő!  Nice to see you are still actively FBPing!

I like the way the blocks tilt as you are moving them - cute! 

Keep us posted on what you are working on,

Best regards,

Paul

--
ern0
dataflow evangelist

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ern0]

> I like the way the blocks tilt as you are moving them - cute!

I'm programming for 25-30 years, but it was the first case I was using
atan() function. I've written pre-calculated sinus tables for scrollers
and Lijassous-curves for my intros, but I never used sin()/cos(), and
especially atan() before in a running program. Arcus tangent is needed
to calculate the pins' (connectors') positions: when you grab the
component box, you can tell to Raphael/SVG to rotate the whole box by a
specific degree, but the connections, which sticks to the rotated
component must be calculated yourself. Math level 2 badge unlocked!

Anyway, I'm not 100% satisfied with this editor concept.

Not because it has a hidden bug. (You can delete connection by starting
a new connection from a pin, and if you go the same direction (+/- a
small angle) with an existing one, it will be faded, which means "marked
for deletion", then if you release the mouse button, it will be deleted.
If there are more connections in the similar direction, the closest one
will be selected - it sounds a good idea, but if you're over a target
pin, it's better to be select the connection which ends at the target
pin you're right over, not the closest one). These UI things can be
polished.

But beyond a certain complexity, the graph is still a mess.

Creating composite components (packing several components into a new,
compound component) does not always help, connections are complex and
diverging, can't split graph into two or more boxes with only a few
connections between them.

One cause of the mess is poor space utilization. I like left-to-right
flow better than top-to-bottom, but even a simple construction requires
lot of "real estate", while there are large white, unused spots, while
connections often hid under the components, and running criss-cross the
table. That's why I shrinked one-in-one-out components to 1 line
(instead of 3 lines: header, in, out): to keep them as small as
possible; that's why the components are transparent: to see connections
running under.

Is it UI problem? I think yes, it is, I hate when content gets aligned
to technique (e.g. in case of document writing, deleting some words from
a paragraph at the bottom of the page, avoid orphan lines on an almost
empty page, but what about the text?!). Should we write a graph
optimizer"? Probably not, I personally hate when my graph gets
re-arranged every minute, and components pops up at surprising positions.

Use 3D? Weirdo. Use grid and use cell refs instead of graphic
connections, like a spreadsheet? Oh, no.

So, these are the issues I've unveiled with this little editor concept.
--
ern0
dataflow evangelist

[Chad Dombrova]

Hi ern0,
Looks cool. Is there a repo for this editor?

-Chad

[Alfredo Sistema]

There are solutions to your problems, one is to use something DrawFBP does, which is allowing for additional bends on connections, so that you can manually route them to make nicer graphs and avoid unnecessary overlaps.

Another change is to disregard ports as a list of things under the node name, and put the names on the connections, like DrawFBP does.

The dataflow granularity is also important, dealing with just integers is going to make graphs very complex and achieve very little, operating on a packet level lets you achieve simpler graphs.

[ern0]

Here you are https://github.com/ern0/dataflow-editor-concept

--
ern0
dataflow evangelist

[ern0]

> allowing for additional bends on connections,

Yep, it's a good feature, but (IMHO, as it's a GUI issue, always: IMHO)
takes too far from the purpose of the editor - specifying components and
connections -: it's a drawing function. I think, a DF editor should not
contain drawing features.

Sometimes I am making stuff with Fritzing (electronic designer
application), and I can spend lotsa time with aligning wires, rotating
elements, then aligning wires again. Maybe it's an important part of
electric designing, I don't know, I'm not electric engieer, but I hate it.

> put the names on the connections,

Yes, it's a possible solution. But, in my eye, port names are such
important, they should be always visible, I don't wanna push them out to
the field of wire jungle.

It sounds that I'm a negative figure from some silly tale, who always
says the opposite others say. Perhaps, but I want to make a perfect
editor, which requires no manual, no training.

Probably, this is impossible, and it looks even harder, if I tell you,
that in my head, the real dataflow graph should be different than what
the user draws: I am planning implement inserting of automatically
placed invisible components, for various purposes.
--
ern0
dataflow evangelist

[Humberto Madeira]

Hi ern0,

Creating svg-based flow graph editors seems to be becoming a more popular activity :-) 

On Thursday, 16 June 2016 07:04:50 UTC-4, ern0 wrote:

> allowing for additional bends on connections,

Yep, it's a good feature, but (IMHO, as it's a GUI issue, always: IMHO)
takes too far from the purpose of the editor - specifying components and
connections -: it's a drawing function. I think, a DF editor should not
contain drawing features.

The alternative is to rotate where the connectors attach to the components.  

My own connectors are outside the roundrect (black squares for input, white-filled for output) spaced out along the edges and labeled with a floating text element.

Although I will also try to add in line bends when I have the time....

 

Sometimes I am making stuff with Fritzing (electronic designer
application), and I can spend lotsa time with aligning wires, rotating
elements, then aligning wires again. Maybe it's an important part of
electric designing, I don't know, I'm not electric engieer, but I hate it.

> put the names on the connections,   

Yes, it's a possible solution. But, in my eye, port names are such
important, they should be always visible, I don't wanna push them out to
the field of wire jungle.

I spent some time with naval engineering (think plumbing with fuel,hydraulic,salt water,fresh water, etc.)

Because of my naval heritage, I feel better putting names on both the connectors and the connections.

I want to know what the ports are for, as well as having some idea of what is supposed to be flowing between them

The flow engine may or may not need to use the information, but it is useful to the user anyways.

 

It sounds that I'm a negative figure from some silly tale, who always
says the opposite others say. Perhaps, but I want to make a perfect
editor, which requires no manual, no training.

+1 :-) 

 

Probably, this is impossible, and it looks even harder, if I tell you,
that in my head, the real dataflow graph should be different than what
the user draws: I am planning implement inserting of automatically
placed invisible components, for various purposes.
--

I do this already, but it doesn`t need to be part of the diagram.

The diagram allows the user to manipulate their mental model, and the run-time flow network constructor refactors and transforms it on-the-fly as needed.

Think of it as an one-way rendering process.

Regards,

--Bert

 

[Paul Morrison]

Just a suggestion - have you taken a look at DrawFBP - this works very well for me!  I recently added the ability to add extra bends on connection arrows or drag existing ones - which gives me the ability to lay out good-looking (IMHO) graphs without too much extra work.

Of course, "classical" FBP doesn't allow one output port feeding multiple input ports, which seems to be a source of complexity in your graphs...

Plus, I think DrawFBP is fairly self-explanatory for the simple stuff...  and the Youtube videos I have recently posted should help a bit too.  You can get the jar file at https://github.com/jpaulm/drawfbp/releases/download/v2.11.1/drawfbp-2.11.1.jar . There is also a built-in Help facility - you have to download the Java Help jar file from http://www.jpaulmorrison.com/graphicsstuff/DrawFBP-Help.jar .

Best regards,

Paul

PS I also think it is important not to be forced to specify the actual components too early....

PPS Not negative at all!

--
ern0
dataflow evangelist

[toivo...@gmail.com]

Hi ern0,

 

Just curious, did you try NoFlo Editor?

It looks nice, well tought and fairly complete.

 

Thanks

Toivo

[Paul Morrison]

On Thu, Jun 16, 2016 at 2:49 AM, Alfredo Sistema <sistemas...@gmail.com> wrote:

The dataflow granularity is also important, dealing with just integers is going to make graphs very complex and achieve very little, operating on a packet level lets you achieve simpler graphs.

Couldn't agree more!  For some reason, integers are almost always the first things people try to build visual editors to handle (is that English?!) - perhaps because it's so "obvious" that an arithmetic expression such as a + b * c can be laid out visually, without having to worry about precedence rules...

However, in my experience, that doesn't give you any bang for your buck in terms of application maintainability - for that you want chunks of data (persons, accounts, transactions, etc., etc.)  travelling through your network...  You need to think of your app in terms of streams of data being transformed, converted, filtered, summarized, etc.  I tried to convey this in my book - but maybe I didn't get the message across!  :-)

[ern0]

> expression such as a + b * c can be laid out visually, without having to
> worry about precedence rules...

When I say integers as data, I mean no arithmetic, but values required
in home automation, e.g. percentage of a light dim (0..100), or
enumerated values for different things, say, modes, scenes.

It's not too elegant, when a simple calculation, which can be expressed
as a single line, is drawn as a pretty big graph.

In our automation prototype system integers are only for setting modes,
levels and enums (on/off: 1/0).
--
ern0
dataflow evangelist

[ern0]

> Just curious, did you try NoFlo Editor?
>
> It looks nice, well tought and fairly complete.

Wow, it looks pretty nice, different drawing modes for different zoom
levels looks awesome. I have a picture of the ideal editor in my mind,
and NoFlo, especially the field editor (moving components, connecting
them, zooming etc.), is very close what I call perfect.
--
ern0
dataflow evangelist

[ern0]

> Just a suggestion - have you taken a look at DrawFBP - this works
> very well for me! I recently added the ability to add extra bends on
> connection arrows or drag existing ones - which gives me the ability
> to lay out good-looking (IMHO) graphs without too much extra work.

Usable. It looks like the best looking HTML pages before the
introduction of CSS: they are okay, but you can say at first sight that
it's a web page. Sometimes some lucky picked colors can help. Anyway,
layout issues can be solved with some cosmetics, adding a border or a
light gradient, whatever, I don't know what Java libs offer. What I
found problematic is the connection hotspot: I was playing long minutes
before I've found it. But it's also can be solved with some graphics
work, there should be something indicating hotspots.

As I've hit "export to JSON", I've found that my little editor concept
produces almost bit-by-bit same output (err, it's broken now).

> Of course, "classical" FBP doesn't allow one output port feeding
> multiple input ports, which seems to be a source of complexity in
> your graphs...

And source of other types of pains as well. Yep, without
multi-feed-consumers the graph is a nice tree. I didn't know why I love
trees, but this is another point, because they're simple.

I've read "trough" hundreds of letters, and I don't remember or missed:
is there any common FBP exchange format yet?
--
ern0
dataflow evangelist

[Sam Watkins]

Looks good, I like it :) Nice work.

[Paul Morrison]

On Thursday, June 16, 2016 at 3:51:53 PM UTC-4, ern0 wrote:

> Just a suggestion - have you taken a look at DrawFBP - this works
> very well for me!  I recently added the ability to add extra bends on
>  connection arrows or drag existing ones - which gives me the ability
> to lay out good-looking (IMHO) graphs without too much extra work.

Usable. It looks like the best looking HTML pages before the
introduction of CSS: they are okay, but you can say at first sight that
it's a web page. Sometimes some lucky picked colors can help. Anyway,
layout issues can be solved with some cosmetics, adding a border or a
light gradient, whatever, I don't know what Java libs offer. What I
found problematic is the connection hotspot: I was playing long minutes
before I've found it. But it's also can be solved with some graphics
work, there should be something indicating hotspots.

If you are saying that DrawFBP screens look like HTML pages, that's because I am using Swing, which has something called a LookAndFeel setting.  I am using the SystemLookAndFeel, which looks a lot like the HTML screens.  You can set the LookAndFeel to a variety of different themes - see https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html#themes .   I believe the most recent is called Nimbus, which you might prefer...   If you want to try out a different theme, you can simply do a GitHub branch and try it out... :-)  Swing also lets you list all the installed LooksAndFeels in your code...

Re hotspots, you can attach a connection anywhere on the border of a block - there are no individual hotspots, or you could say the whole border of a block is a hotspot.  This is documented in the Arrows section of the Help facility, but maybe it doesn't stand out clearly enough.  I will add a couple of lines to Readme for DrawFBP on Github - I guess I didn't realize it was non-obvious!

[ern0]

> If you are saying that DrawFBP screens look like HTML pages, that's
> because I am using Swing, which has something called a LookAndFeel
> setting.

I know what Swing is, it was the first pixel-rendering engine for Java.
Yep, the result is very similar to basic HTML rendering, if you don't
spend lot of time with polishing boxes. Probably, Swing has some tricks
to make UI elements great. But your UI graphics is fairly OK, don't
spend extra time with it. Except...

> Re hotspots, you can attach a connection anywhere on the border of a
> block - there are no individual hotspots, or you could say the whole
> border of a block is a hotspot. This is documented in the Arrows
> section of the Help facility, but maybe it doesn't stand out clearly
> enough. I will add a couple of lines to Readme for DrawFBP on Github -

Are you saying we should read the manual? Ouch, I don't expected this!
Okay, without any irony: nowadays no one reads manual or help.

So, you should put a little sign on the right side of the box which
indicates hotspot. Even a fake one; say, put a small bump on the top 4/5
of the right corner, everyone will try it out, probably many will
recognize that other areas can be used as the start point of an edge.

> I guess I didn't realize it was non-obvious!

This happens often when you spend lotsa' time with something, and you're
using it as much that after a while you find the hardest things trivial.
But fortunatelly, there's someone (me) who can point out these UX
issues, you're such lucky guys!
--
ern0
dataflow evangelist

[Paul Morrison]

On Sat, Jun 18, 2016 at 3:20 PM, ern0 <er...@linkbroker.hu> wrote:

 But your UI graphics is fairly OK, don't spend extra time with it.

That's good news!

 

Except...

Re hotspots, you can attach a connection anywhere on the border of a
block - there are no individual hotspots, or you could say the whole
border of a block is a hotspot.  This is documented in the Arrows
section of the Help facility, but maybe it doesn't stand out clearly
enough.  I will add a couple of lines to Readme for DrawFBP on Github -

Are you saying we should read the manual? Ouch, I don't expected this! Okay, without any irony: nowadays no one reads manual or help.

Well OK - I stand (well, sit) corrected!  I did update the Readme, though.  

So, you should put a little sign on the right side of the box which indicates hotspot. Even a fake one; say, put a small bump on the top 4/5 of the right corner, everyone will try it out, probably many will recognize that other areas can be used as the start point of an edge.

I have an idea that I might try out...

I guess I didn't realize it was non-obvious!

This happens often when you spend lotsa' time with something, and you're using it as much that after a while you find the hardest things trivial. But fortunatelly, there's someone (me) who can point out these UX issues, you're such lucky guys!

Absolutely!  I keep asking for feedback - but you'd be surprised how seldom I get it!  So thanks for yours!  Someone once told me that people try something once and then give up if it's not obvious how to use it...  Trouble is that their obvious may not be the same as my obvious!

Regards

[ern0]

> Absolutely! I keep asking for feedback - but you'd be surprised how
> seldom I get it!

That's why Joel's step 12 is so important
(http://www.joelonsoftware.com/articles/fog0000000043.html).
--
ern0
dataflow evangelist

[Paul Morrison]

I had an idea about hotspots - I'd like to know what you think of the idea!  Just give it a try - I'm not going to give any hints!  https://github.com/jpaulm/drawfbp/releases/download/v2.11.3/drawfbp-2.11.3.jar

Also, I didn't realize that the Help facility was not accessible from the jar file - it seems to be fixed now!  (You do have to download the JavaHelp file - https://github.com/jpaulm/drawfbp/blob/master/lib/DrawFBP-Help.jar - and tell DrawFBP where you have stored it.)

Good feedback - thanks!

Regards,

Paul

On Sat, Jun 18, 2016 at 3:20 PM, ern0 <er...@linkbroker.hu> wrote:

--
ern0
dataflow evangelist

[ern0]

We've bought it.

(Musicians' slang: in a studio, when the singer or instrument player
sings/plays the track properly, the recording leader says this, and it
means that the result is satisfactory, no further attempts needed, the
singer/player can came out of the recording room.)

--
ern0
dataflow evangelist

[Paul Morrison]

Or...  it's a wrap!  :-)  Thanks!

ern0
dataflow evangelist