I am currently designing a solution about IVR's (Interactive Voice Solution) system that should enable user design their own flows according to their needs. In this solution, user should need to arrange questions, answers, messages and their relationship with keypad or with voice commands according to their business flow.

After taking some time about researching about options, we conclude that visual programming interfaces can be a good option. According to my research, I found some libraries related to show flows:

NoFlo- http://noflojs.org/

Meemoo- http://meemoo.org/

jsPlumb- http://jsplumbtoolkit.com/home/jquery.html



mxGraph- http://www.jgraph.com/mxgraph.html

Node-RED- http://nodered.org/

GoJS- http://gojs.net/latest/index.html (paid)

My own experience with MAX MSP,Grasshoper (generative modelling plug-in works for Rhino), Visual programming interfaces can be really complicated while building complex structures. On the other hand, it is easier since it creates a better feedback loop compared to text based programming.

There are also some visual programming tools like, a popular example at these days, Scratch, http://scratch.mit.edu/ developed for learning how to code.

A favourite subject for Ph.D. dissertations in software engineering is graphical, or visual programming. […] Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will. (Frederick Brooks The Mythical Man Mont)

There are games that are also using visual programming elements like (Drag-drop, rubber connections, clustering several elements into one, input and output parts - ex: jigsaw)

After collecting these all information, instead of being more clear about the way, I feel that I am lost in many different views and could not find solid information about whether they are working good for non-tech users. Can you please your knowledge or experience if you already worked on such a project?

Thank you,

  • The Domoticz open source project has an integrated visual Lua script editor which works well for simple scripts. Not sure what libraries it's using.
    – Andy Boura
    Aug 30, 2014 at 8:43

7 Answers 7


I've worked on visual programming systems/languages and I agree with Frederick Brooks. Graphical or diagrammatic or any kind of non-text based languages do not make good general purpose programming languages. Text is very efficient at describing complex things, especially behaviors and actions, usually much better than non-text. A picture is worth 1000 words only in special cases.

But special purpose graphical languages can be good applied to limited, domain specific problems. For instance LabVIEW has been successfully applied to many problems within it's target niche.

These domain specific graphical languages sometimes are quite usable by non-technical people, but they're no silver bullet. They (usually) still require a significant investment in learning the language and system, and even then the problem must be clearly understood to attempt to express it within the graphical language/system.

  • Interested in how you formed your opinion and what visual programming systems/languages you worked on as I am running around with an idea for a visual interface for a couple of programming related tasks. W/Could you share links to some systems (instead of libraries) for me to analyse? Jan 5, 2014 at 11:36
  • I agree based on my experience with visual languages in a few domains. They work OK but there are other representations of process logic that work equally well. @Abektes, one point of confusion in a visual/diagrammatic language is the meaning of nodes and connections between nodes. You need to decide (1) whether nodes are objects, processes, or the result of a process (a system state) and (2) what the connection between two nodes means. Not surprisingly, people interpret diagrams differently and the meaning of nodes and connections is, often, at the root of the differences. Jan 6, 2014 at 19:26
  • @MarjanVenema - I haven't worked on this stuff in years (but I do keep an eye on it out of interest). In 90s I helped make something called PARTS Workbench. The main problem was as complexity increased you get a mass of wiring which is harder to understand than comparable code. As long as the problem is fairly simple I think visual programming is feasible.
    – obelia
    Jan 6, 2014 at 19:35
  • Thanks obelia. Googling for that brought up some interesting links. Jan 7, 2014 at 7:37
  • Hey @user1757436 thanks for giving some insights.Sorry for late reply, i was mobilized. I was thinking using connection for showing the flow. We are trying to create dialog concept for IVR's.I ll keep all u guys updated if i find something valuable... Thanks again
    – Abektes
    Jan 10, 2014 at 8:50

I have worked for a long time writing software for the financial industry, and I have to say that Excel is by far the most successful visual programming interface for non-technical users.

  • Novice users start off working with simple rows and columns.
  • They start "programming" with simple drag to select and sum a column (or some other simple operation), and gradually move onto more complex tasks (e.g. more complex formulas, referencing values in other sheets, creating pivot tables).
  • Expert users can add various controls (e.g. buttons, listboxes), write their own macros, and add other data sources (RTD Servers etc.)

I am constantly amazed at the stuff people are doing with it*.

I'm not claiming Excel is the best design ever. I'm not saying that everyone should use it, or claiming that non-technical people are coming up with elegant software designs using it...

...but Excel must be doing something right to be so ubiquitous and loved**.

I suspect that having a big grid of numbers is the key. Most programming is about manipulating data, yet most graphical programming languages seem to be about manipulating workflows / stringing components together.

*i.e. Sometimes we get a "house of cards" set of workbooks to make into an application

**however hated it is among real developers.

  • 2
    A key reason that Excel is so approachable and successful is that it is a declarative (or imperative) system rather than procedural language. User declares outcome needed e.g. state thisCell = 34 / thisCell = formula(other_cells) / thisCell = result_of_function() and the Excel works out the requisite order. This reduces learning curve as well as decreasing the complexity of interactions. I've built a domain specific declarative language and it was vastly simpler than procedural code which preceded it. Also the new language was editable by domain experts without programmer assistance.
    – Jason A.
    Sep 1, 2014 at 21:26
  • 1
    Good point there. It's like game design. Make it easy for users to discover the simplest actions. Then build more complex behaviour base on those actions.
    – nightning
    Sep 3, 2014 at 20:31

I found the more successfull project in the field is a plugin for unity 3D : playmaker. Playmaker is a visual states machine that emphasize on helping games devellopper on main tasks and allow to iterate quickly with visual feedbak in real time.

In fact maybe nodes are not the best visual system to help non programming people to understand code logic. Each field should invent system that are more relate to the experience the user intent to create.

A good example is mozilla appamaker. The visual canvas is a smartphone. the prefabs are screenparts. they also work on making listener visual with good feedback and feedforward. I think the visual system they created is easier to understand.

generic design lead to failure.

  • 2
    This answer would be a whole lot better if you provided links to the mentioned projects.
    – msp
    Aug 12, 2014 at 15:00
  • Playmaker for Unity 3D is here hutonggames.com
    – Adriano
    Sep 4, 2014 at 11:27

im still fascinated about the software http://en.wikipedia.org/wiki/MeVisLab . It helps to see the flow of the app in kinda tree hierachy, but enables also developing extreme complex modules, that then a non-tech user can use for its own ideas.


I think the approach taken when they designed the DRAKON visual language is something to consider while choosing or designing a visual programming language.

For DRAKON they designed a set of rules or constraints applied in a visual manner that try to emulate or improve the rules used for text based programing languages.

In text based programming languages we generally follow the following process when reading a program:

When we open the text file with the source code, we immediately search for the function or method that initializes the program, then we follow the path that the programer determined to be the best case scenario, with corner cases put in special places like at the end of the function. If we find a subroutine call, we start looking for its definition and jump to the chunk of text where it’s found. When we reach the end of that subroutine we jump back to caller routine. The process is repeat until we reach the end of the program.

So, what they did with DRAKON was to put lines between those calls to subroutines and replace the subroutines with nodes while adding rules specifying how the lines and the nodes are placed in a diagram.


When I worked in forex, we did user testing and training for a visual trading strategy creation application. It proved easier to get into, and faster to create non-complex strategies (which most are).

Another good example is Jira's workflow builder. Most of the project managers I've worked with - including in legal, marketing, accounting departments - had no issue figuring it out and using it for themselves.

In my experience, yes, visual interfaces are effective for non-tech users, because they:

  • don't cause a "I'm not a programmer" mental block
  • encourage experimentation
  • give sense of ownership of your creation and satisfaction

To strengthen these, we found it essential to

  • make the UI discoverable and forgiving
  • have Undo, Copy / Paste capabilities
  • provide a tutorial, examples and templates
  • export / import functionality to share examples, and provide support easier

Lastly, many people have done a form of visual programming without realizing it. For example, by creating mind maps, flow-charts, and process diagrams.


The Unreal Engine 4 Blueprint system is the most complete and successful visual programming language that I know of.

Essentially it is a layer on top of c++, which is a layer on top of machine code.

Some of those interfaces you've shown don't seem to be as complete, but any additional visual scripting on top of code is beneficial makes them more effective for everyone, including non-tech users.

The benefits are not only for non-tech users, for a complete visual scripting language like UE4 Blueprints, sophisticated users also benefit from the visual prototyping, developing, and debugging advantages that this extra layer provides.

As long as the interface is truly a layer on top, and not just a clumsy replacement, it is beneficial to all users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.