4 ms·

Cool stuff. Wish I found this a few years ago when I dug into this topic for a thesis. Back then I analyzed this incredible resource (warning: clicking this lin

by djedr 6y ago

Cool stuff. Wish I found this a few years ago when I dug into this topic for a thesis. Back then I analyzed this incredible resource (warning: clicking this link will load looots of images): http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/ http://blog.interfacevision.com/design/design-visual-progarm... and came up with my own provisional taxonomy where major categories were "Line-connected block-based", "Snap-together block-based", "List-based", "Enhanced text", and a few others. Looking back I still think that the most promising direction when it comes to real-world applications of visual programming is the hybrid approach: make a language which has "real-time" interchangeable text and visual representations -- you get the best of both worlds this way (that was basically the topic of my thesis[1]). I thought it was an original idea when I started out with my research, but sure enough there were attempts in the past. And towards the end (4+ years ago) I discovered a fresh one which seems to be still going strong, albeit rebranded: https://github.com/enso-org https://github.com/enso-org Last time I checked they were making what I consider a bad design choice by leaving the structuring of the visual representation entirely up to the user, but maybe that's fixed now. Anyway I think it's a cool topic and worth keeping an eye on. [1] If anyone is interested it's available here: https://djedr.github.io/masters_thesis.pdf https://djedr.github.io/masters_thesis.pdf

wdanilo 6y ago
@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will have credit risk analysis". This way authors of workflows are able to navigate trough hierarchical graphs really, really fast, knowing where are things they have designed. With auto-generated layouts, the layout can change drastically when you apply even small semantic changes (like when you pass a new parameter between two nodes), and thus, it will break this mental space-mapping between nodes positions and their responsivities. Anyway, we are building Enso in a completely open way, allowing third-party auto-layouting algorithms to manage the graph visual layout, and we are very open to investigate it further - that's why I asked this question :)
- djedr 6y ago
  Hey, thanks for the response. :) I see it as analogous to structuring source code text. The sweet spot IMO lies in the place where the editor offers guidance for common use-cases (think auto-indent, on-demand auto-format), but allows you to arrange code in a non-standard way when appropriate. That I think would be ideal. Not all good programmers care about maintaining perfect visual order and I think that's fine. They would appreciate the automation and would be discouraged by the lack of it. Same as in text languages/IDEs. Of course it's totally fine if your audience does not care about such features or they are not a priority. But for a good general-purpose system I think that would be a must. Now the sweet spot is not trivial to achieve and I haven't completely solved it, but I feel it can be done and I'd invest in researching it. PS I hope your project succeeds!
  - wdanilo 6y ago
    I fully agree that the visual environment should arrange the newly created graph nodes in a nice way automatically. In the Enso 2.0 version we have a very early support implemented exactly for that. However, there is a lot to be done yet to have it working fluently in the case of bigger and complex graphs. It is a fascinating research topic for me, TBH. Thank you for nice words! <3
- jpaulmorrison 6y ago
  Soon after starting work on what later became Flow-Based Programming (FBP), I decided that I should leave the block layout entirely up to the application developer... A few years later, James Martin (1981) was working on what he called 4th-generation languages, and the blocks were prone to moving around unpredictably as the text was changed... Very confusing, as people do like things to stay where they are put! This actually fits in with the idea of "loci" alluded to elsewhere in this page. In FBP, "stepwise refinement" is a key part of the design process, so you get a hierarchy of simple structures... I agree that you could add a function to "prettify" your diagram(s), but this should still be under the developer's control. And if you make it simple to move blocks around (as in DrawFBP), it's probably not worth the trouble!
  - 6y ago

by djedr 6y ago

wdanilo 6y ago

@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will have credit risk analysis". This way authors of workflows are able to navigate trough hierarchical graphs really, really fast, knowing where are things they have designed. With auto-generated layouts, the layout can change drastically when you apply even small semantic changes (like when you pass a new parameter between two nodes), and thus, it will break this mental space-mapping between nodes positions and their responsivities. Anyway, we are building Enso in a completely open way, allowing third-party auto-layouting algorithms to manage the graph visual layout, and we are very open to investigate it further - that's why I asked this question :)

djedr 6y ago
Hey, thanks for the response. :) I see it as analogous to structuring source code text. The sweet spot IMO lies in the place where the editor offers guidance for common use-cases (think auto-indent, on-demand auto-format), but allows you to arrange code in a non-standard way when appropriate. That I think would be ideal. Not all good programmers care about maintaining perfect visual order and I think that's fine. They would appreciate the automation and would be discouraged by the lack of it. Same as in text languages/IDEs. Of course it's totally fine if your audience does not care about such features or they are not a priority. But for a good general-purpose system I think that would be a must. Now the sweet spot is not trivial to achieve and I haven't completely solved it, but I feel it can be done and I'd invest in researching it. PS I hope your project succeeds!
- wdanilo 6y ago
  I fully agree that the visual environment should arrange the newly created graph nodes in a nice way automatically. In the Enso 2.0 version we have a very early support implemented exactly for that. However, there is a lot to be done yet to have it working fluently in the case of bigger and complex graphs. It is a fascinating research topic for me, TBH. Thank you for nice words! <3
jpaulmorrison 6y ago
Soon after starting work on what later became Flow-Based Programming (FBP), I decided that I should leave the block layout entirely up to the application developer... A few years later, James Martin (1981) was working on what he called 4th-generation languages, and the blocks were prone to moving around unpredictably as the text was changed... Very confusing, as people do like things to stay where they are put! This actually fits in with the idea of "loci" alluded to elsewhere in this page. In FBP, "stepwise refinement" is a key part of the design process, so you get a hierarchy of simple structures... I agree that you could add a function to "prettify" your diagram(s), but this should still be under the developer's control. And if you make it simple to move blocks around (as in DrawFBP), it's probably not worth the trouble!
- 6y ago