3 ms·

Visual programming has interested me for a long time because it is amazing how many times it has been tried and the result been unusable. If I had the time and

Visual programming has interested me for a long time because it is amazing how many times it has been tried and the result been unusable. If I had the time and resources, I'd very much like to try developing a visual programming system that uses a user interface change that I think would greatly change things. Basically, using the middle mouse wheel to zoom in/out. If you've played the Supreme Commander game series, you will have the best idea of what I mean. As it is, you end up with absolutely everything trying to be jammed in to one gigantic flat space. That's terrible. Better would be zooming in on a 'box' (function, data structure, etc) and having its guts become the new 'context' you're working in. So far as I have been able to find, this has never been attempted.

meemoo 12y ago
We are working with an SVG-based ZUI framework for noflo-ui/flowhub and have plans take the metaphor further: http://i.imgur.com/wQqvhlD.gifv http://i.imgur.com/wQqvhlD.gifv ZUI dataflow has been done in the past with Nuke. VFX people make some massively complex graphs with that tool.
falcolas 12y ago
A ZUI would be great for working with the FP paradigm, but good UIs are hard to make; I think it's one of the way that NoFlow is gaining the traction it is, the UI is pretty good.
- robhawkes 12y ago
  The GUI with NoFlo is one of the major reasons why this is different to the previous attempts at FBP (that and it's JavaScript). What I also love is that it's all released under MIT: https://github.com/noflo https://github.com/noflo
- meemoo 12y ago
  > the UI is pretty good. Thank you, that is encouraging. We're working to make it really good.
dragonwriter 12y ago
> Better would be zooming in on a 'box' (function, data structure, etc) and having its guts become the new 'context' you're working in. Its a fairly obvious dataflow UI paradigm, since its exactly the paradigm typically used for nested dataflow diagrams. If it hasn't been done already in FBP UIs, I'm surprised. But, certainly I'd agree its exactly what an FBP UI should do. Of course, that requires the user actually to design in terms of nested components rather than in a single flat diagram space -- and probably means you need "visual refactoring tools" that let you combine components into a single component with nested content and exploded components with nested content up to the parent level. And, ideally, probably stronger refactoring tools that can identify groups of components that make sense to combine using some heuristic measuring degree of connections within the group vs. connections outside the group to the rest of the diagram.
- otakucode 12y ago
  > requires the user actually to design in terms of nested components rather than in a single flat diagram space The way I picture it, the user would almost be forced to nest components. The flat diagram space would become unmanageable (a very common problem I see in various visual programming systems), and nesting would be extremely simple. If you want to turn something into a component, just draw a box around the various pieces and hit a single button. Boom, it automatically disappears all of the pieces into a single component with the input and output pins aggregated. Given that we've got nice big screens now, I would experiment with not even making the workspace scrollable. The ideal systems would have all 'chunks' (conceptually speaking) visible as single-screen pieces. In my really crazy fantasies, such a system would allow you to 'zoom in' right down to assembly output. I've also been doing a lot of thinking about provably correct programs. People talk a lot about it especially in FP circles, but proving programs correct is very rarely actually done. Integrating a lot of design-by-contract elements would be almost necessary, and that doesn't work terribly well in most languages. You end up with enormous amounts of code checking and asserting everything and even if you omit that stuff from release builds, it seriously detracts from readability. I've considered the idea of coding in "layers" which makes it easy to hide/show different 'layers' where the layers would be things like 'contract code' or 'error handling' and the like, so you could leave your 'primary' view of the code strictly code that actually gets stuff done... but I don't have the UI design chops to do something like that without introducing as many problems as it solves, I don't think. With a visual programming system, however, the contracts could be simply a little 'bubble' over the in/out pins. If you want to investigate the constraints on an input variable, you'd just zoom in on the bubble. With enough constraints, automated reasoning could help prevent you from writing bad code to begin with, along with proving invariants about the code to indicate correctness.
sethjgore 12y ago
That's exactly what I think a visual programming system needs. Zoomable objects Has been tried on either smalltalk/squeak (forgot which, but alan kay pushed for it).. A visual programming system needs: 1) quick and natural way to access tools without interruption of flow. 2) has a visual language in its structure. Needs something beyond "wiring" model that is noflo. Your zoom in and out concepts touch the right concepts. (have ideas on this) Re: 1) I've been working on something similar to this. Reply if you'd like a working link. Got to get that up. It's mainly a reactive system where randomness of human input is valued over precision of clicks, typed text....he keyboard is a key piano in a sense. The computer decides what the input means. Rather than the other way around. Visual realm values this huge stream of information vs sound/text. This reactiveness could let us find components/parts intuitively, like how u tuen the dial on a running water hose. I think being able to find tools/components you need quickly is an important part of using a visual programming system. Visual = intuitive. Re: 2) We need a visual language as much as we need a text language for text programming. I'm working with a couple of teachers on expanding a visual language learning system called Grmmr, can be found on green-bridge.org, still need to add visuals and a working shopping cart, ha. Point is we have established a very simple but crazily effective visual language (around for 15 years) you can use to teach grammar and relationships in text. I know this can be applied to visual programming with very little effort. We definitely are exploring in expanding the usage of this system beyond grammar.
programmarchy 12y ago
Quartz Composer has these features. You can zoom and also group components into a "patch" with its own set of inputs and outputs. I've had some success using QC for prototyping animations and custom UI controls for iOS, then later hand coding them in CoreGraphics. I got the idea from the Facebook devs who developed... I forget the name of the app. Anyway, would have been great if Quartz compositions were directly importable to iOS.
zeLaur 12y ago
I think visual programming in a way that it would really be helpful is close to impossible. To achieve a good, working, prototype for visual programming means to be on a sort of "Happy Path" and use some conventions ( more or less strict). At that point, you are no longer and engineer / developer / hacker / coder ( or what ever you prefer being called ) you slowly transform into "Just the guy who knows you to configure that specific program / platform". Look at ERP solution that are offered nowadays, you get a gigantic package that needs to be configured by a person ( who will either check some boxes, add some params , enable some features visually / write a goulish xml / yml document that configures that system). So yes, although visual programming seems very appealing it still has a lot to go... * Disclaimer I`m preping for a PHD, my thesis subject is "user self generated application", so yes, I did some research, poked a lot in this field, and can say I know a bit about visually creating stuff from checkboxes, textboxes and buttons... it's a lot more complex than it seems and if you want to go all in and allow fine grained control from visual to final generated stuff, in the end you will overly complicate things ( remember the microwave with over it 30 buttons, with 28 buttons that nobody actually used ). Have a nice day :)

meemoo 12y ago

We are working with an SVG-based ZUI framework for noflo-ui/flowhub and have plans take the metaphor further: http://i.imgur.com/wQqvhlD.gifv http://i.imgur.com/wQqvhlD.gifv ZUI dataflow has been done in the past with Nuke. VFX people make some massively complex graphs with that tool.

falcolas 12y ago

A ZUI would be great for working with the FP paradigm, but good UIs are hard to make; I think it's one of the way that NoFlow is gaining the traction it is, the UI is pretty good.

robhawkes 12y ago
The GUI with NoFlo is one of the major reasons why this is different to the previous attempts at FBP (that and it's JavaScript). What I also love is that it's all released under MIT: https://github.com/noflo https://github.com/noflo
meemoo 12y ago
> the UI is pretty good. Thank you, that is encouraging. We're working to make it really good.

dragonwriter 12y ago

> Better would be zooming in on a 'box' (function, data structure, etc) and having its guts become the new 'context' you're working in. Its a fairly obvious dataflow UI paradigm, since its exactly the paradigm typically used for nested dataflow diagrams. If it hasn't been done already in FBP UIs, I'm surprised. But, certainly I'd agree its exactly what an FBP UI should do. Of course, that requires the user actually to design in terms of nested components rather than in a single flat diagram space -- and probably means you need "visual refactoring tools" that let you combine components into a single component with nested content and exploded components with nested content up to the parent level. And, ideally, probably stronger refactoring tools that can identify groups of components that make sense to combine using some heuristic measuring degree of connections within the group vs. connections outside the group to the rest of the diagram.

otakucode 12y ago
> requires the user actually to design in terms of nested components rather than in a single flat diagram space The way I picture it, the user would almost be forced to nest components. The flat diagram space would become unmanageable (a very common problem I see in various visual programming systems), and nesting would be extremely simple. If you want to turn something into a component, just draw a box around the various pieces and hit a single button. Boom, it automatically disappears all of the pieces into a single component with the input and output pins aggregated. Given that we've got nice big screens now, I would experiment with not even making the workspace scrollable. The ideal systems would have all 'chunks' (conceptually speaking) visible as single-screen pieces. In my really crazy fantasies, such a system would allow you to 'zoom in' right down to assembly output. I've also been doing a lot of thinking about provably correct programs. People talk a lot about it especially in FP circles, but proving programs correct is very rarely actually done. Integrating a lot of design-by-contract elements would be almost necessary, and that doesn't work terribly well in most languages. You end up with enormous amounts of code checking and asserting everything and even if you omit that stuff from release builds, it seriously detracts from readability. I've considered the idea of coding in "layers" which makes it easy to hide/show different 'layers' where the layers would be things like 'contract code' or 'error handling' and the like, so you could leave your 'primary' view of the code strictly code that actually gets stuff done... but I don't have the UI design chops to do something like that without introducing as many problems as it solves, I don't think. With a visual programming system, however, the contracts could be simply a little 'bubble' over the in/out pins. If you want to investigate the constraints on an input variable, you'd just zoom in on the bubble. With enough constraints, automated reasoning could help prevent you from writing bad code to begin with, along with proving invariants about the code to indicate correctness.

sethjgore 12y ago

That's exactly what I think a visual programming system needs. Zoomable objects Has been tried on either smalltalk/squeak (forgot which, but alan kay pushed for it).. A visual programming system needs: 1) quick and natural way to access tools without interruption of flow. 2) has a visual language in its structure. Needs something beyond "wiring" model that is noflo. Your zoom in and out concepts touch the right concepts. (have ideas on this) Re: 1) I've been working on something similar to this. Reply if you'd like a working link. Got to get that up. It's mainly a reactive system where randomness of human input is valued over precision of clicks, typed text....he keyboard is a key piano in a sense. The computer decides what the input means. Rather than the other way around. Visual realm values this huge stream of information vs sound/text. This reactiveness could let us find components/parts intuitively, like how u tuen the dial on a running water hose. I think being able to find tools/components you need quickly is an important part of using a visual programming system. Visual = intuitive. Re: 2) We need a visual language as much as we need a text language for text programming. I'm working with a couple of teachers on expanding a visual language learning system called Grmmr, can be found on green-bridge.org, still need to add visuals and a working shopping cart, ha. Point is we have established a very simple but crazily effective visual language (around for 15 years) you can use to teach grammar and relationships in text. I know this can be applied to visual programming with very little effort. We definitely are exploring in expanding the usage of this system beyond grammar.

programmarchy 12y ago

Quartz Composer has these features. You can zoom and also group components into a "patch" with its own set of inputs and outputs. I've had some success using QC for prototyping animations and custom UI controls for iOS, then later hand coding them in CoreGraphics. I got the idea from the Facebook devs who developed... I forget the name of the app. Anyway, would have been great if Quartz compositions were directly importable to iOS.

zeLaur 12y ago

I think visual programming in a way that it would really be helpful is close to impossible. To achieve a good, working, prototype for visual programming means to be on a sort of "Happy Path" and use some conventions ( more or less strict). At that point, you are no longer and engineer / developer / hacker / coder ( or what ever you prefer being called ) you slowly transform into "Just the guy who knows you to configure that specific program / platform". Look at ERP solution that are offered nowadays, you get a gigantic package that needs to be configured by a person ( who will either check some boxes, add some params , enable some features visually / write a goulish xml / yml document that configures that system). So yes, although visual programming seems very appealing it still has a lot to go... * Disclaimer I`m preping for a PHD, my thesis subject is "user self generated application", so yes, I did some research, poked a lot in this field, and can say I know a bit about visually creating stuff from checkboxes, textboxes and buttons... it's a lot more complex than it seems and if you want to go all in and allow fine grained control from visual to final generated stuff, in the end you will overly complicate things ( remember the microwave with over it 30 buttons, with 28 buttons that nobody actually used ). Have a nice day :)