[bunkat]

Looks like an interesting way to enforce the pattern of testable, reusable components for developers that tend to end up with spaghetti code. However, I think it's a little dubious to say that designers without coding experience will suddenly become empowered to contribute to the code base (or write their own applications) in any meaningful way.

Looking at one of the sample pictures on the Kick Starter page I see AnchorY out connected to SpringY anchor and Touch start connected to DragX open. I literally have no idea what this is doing. I probably would have connected Touch start to DragX in, though apparently that would be wrong. So as a non-coder I need to understand what every component does (which probably is not explained in layman's terms), what inputs are, what outputs are, what the specific component inputs and outputs are, and what those actually do (again in layman's terms please!).

More importantly, I need to be able to think like a coder and know how to break large problems down into small components and be able to figure out how to then wire those together to get the desired outcome. And as soon as I hit a bug or it doesn't do what I want, I'm guessing I'm just out of luck because everything is a black box to me.

I remember some usability studies that we did at Microsoft that was testing a simplified flow control UI to do basic programming. We brought in people that claimed to have at least scripting experience if not coding experience. We should them a constrained UI that had some operations (ping a server, start a server, stop a server) and basic flow control (if, for, etc). We asked them to reboot a server as a warm up question - since no 'reboot' operation was provided they just need to combine a stop server with a start server. We lost 75% of the participants at that step. It was pretty eye opening to see first hand that not everyone can think like a developer, it has nothing to do with providing a nicer UI or pretty visuals. Problem decomposition and recomposition are learned skills.

I really like the approach and think it can be very effective at improving the overall experience for developers. But to say this is somehow suddenly going to allow somebody with no coding or developer experience to "skip the tens of thousands of hours becoming fluent in syntax and start visually hacking on your application now" just reeks of marketing bs.

[ericHosick]

What would have happened if the question had been rephrased to "Ok, you have stop car, start car and check car. What do you do to restart a car"? Perhaps they would have done a lot better because they have a better understanding of the car domain.

The purpose of a visual language is not to replace domain experience. If you put me in front of a drawing program with a pallet of red, blue and green and ask me to create the color cyan... Then we're gonna have a bad time.

Visual programming does not claim that critical thinking is not required: aka programming in this context.

We've chatted with people who've said "I can not get the coding thing. That has always been hard for me. Designing and taking bigger concepts and parts and putting them together: assembly. I get that." These people can solve problems, they understand critical thinking. They have expertise in their domain.

What they don't get is a mapping process of automating a real world system (what programming is) in a computing device by coding out the solution.

Don't even get me started on education where students are expected to learn how to think critically (do that mapping thing) and fight with, to them, totally nonsensical compiler errors as they try to learn coding and syntax.

In my opinion, a lot of brilliant future programmers are lost because they don't enjoy fighting the compiler/interpreter.

[bunkat]

The participants in the study were IT professionals that managed servers for a living. Servers and actions regarding servers were definitely within their domain experience. So we did exactly what you were suggesting we did.

I still think that connecting up a hundred little boxes is just as complicated as actually looking at code syntax, but even more so since everything is a black box. How do you suggest people fix errors in the output when the only action they can take is to connect boxes with lines?

[meemoo]

I'm imagining a debug view that slows down the flow and shows data traveling through the graph, so you can see it at every step.

Or with the circuit board metaphor, a debug "probe" that would show the data (or a graph of data) traveling through that point.

Different debugging tools will make sense in different domains, but we're considering the challenge.

[chipsy]

Where these projects tend to fail is in being designed with the assumption of needing to be as decomposed and abstracted as textual code. Suddenly the components become "syntax" again and you're just doing regular old coding with more clicking. On the other hand, the most popular implementations in the historical record - projects like Pure Data - have relatively weak coding abstractions and instead gain strength from staying tightly focused on their domain and never deviating - they are big libraries with a very tiny language, not the other way around.

NoFlo is building on the existing legacy of what has been shown to work, and is most progressive in the sense that it aims to have libraries for many different domains, rather than just one.

[meemoo]

NoFlo's black boxes can always be opened and modified, whether there is another graph or JavaScript inside.

The tools for interactive prototyping for designers will be built on the foundation that we're building now. So the draggable/spring example could be inside of a black box that exposes the important variables. Designers can use that box as-is, but there is very little friction to seeing and experimenting with how it works inside.