Visual Scripting Language

[ocratato]

I have been reviewing a good proportion of the 86 different visual programming languages listed by Wikipedia. Some like Piet and Befunge are truly bizarre.

One of the main issues is that they are seen as being too basic for professional programmers to use, and hence they tend to not get much attention unless there is a strong commercial incentive, such as the LabVIEW product.

Most of the examples were either for creating 3D worlds for games or for creating simple business applications by extending the usual drag-n-drop GUI construction process into the underlying actions.

The Apple Automator program comes very close to what we are proposing.

Two basic styles of graphical editing seem to be applicable for our purpose. We can either create a flowchart diagram or use some sort of blocks or tiles that “clip” together. If we use the tile approach then a Nassi-Shneiderman technique might be applicable. However, the flowchart is the more commonly used technique and is, perhaps, less likely to intimidate the novice user.

The use of the dot program (or similar) to automate the layout of a flowchart might be a useful option.

Rather than pop-up dialog boxes for setting command parameters it might be better to have a semi-fixed window pane that shows the details of which ever command is selected. Alternatively, allow it to be floating or pinned according to the user's desires. Systems which have a separate pop-up window for every little action get tedious very quickly.

A common theme among many of the examples is the ability of the user to visualise the execution of their program – to be able to watch what is happening step by step. Our solution should include a debug mode as part of the editor that will allow this sort of visual testing.

[ocratato]

An update for anyone watching...

I have reviewed several online tutorials and books on Linux and have selected about 150 commands for the initial set. They can be classified as relating to scripting, the state of the computer, or processing text files.

For the parameters EBNF looks promising. It can be used to guide the user into selecting valid combinations of options. It can be displayed as a syntax diagram to also help guide the user.

While the design should "hand hold" the user as the default, it should also allow commands to be simply typed into a text dialog so that any command can be incorporated into the script - not just those that we have prepared.

Now, onto designing a visual language....

[ocratato]

Another update...

The visual language design is done, and I think it should handle most scripting tasks.

I have been thinking about the runtime script interpreter and have realised that there is a bit of a problem with security. Normally when we download scripts off the internet they are confined to the browser sandbox and are not allowed (we hope) to access or modify the user's files (without explicit approval). However the scripts for a visual scripting language will be just ordinary XML files which could easily be downloaded from random places on the net and easily installed and run by an ordinary user. This could quickly become a bit of a problem

My idea is to cryptographically sign the scripts. The editor would sign a script with the user's private key. The editor and runtime would only open or run scripts using the user's public key, or perhaps one of another set of public keys controlled by the system administrator. The latter set would allow scripts to be used across a site, or to be installed from the distribution's repository.

Any thoughts or suggestions?

[ocratato]

Since it appears that no one else is much interested in this thread, I'll wrap it up for now with the preliminary analysis document, attached.

[jpollard]

You forgot about programmers that have color blindness...

The usual symbol for a test point is a rectangle/square rotated 45 degrees. For loops it was a rectangle with triangles on either side.

And left out a very important concept called "pipe".

Nothing was mentioned about the editor functions - such as simplifying drawing (minimizing line intersections) reoganization (moving chunks of the diagram around). For a basic editor you might look at TGIF.

Nice document for a starting point.

[RupertPupkin]

Originally Posted by ocratato

Any thoughts or suggestions?

I suggest you read this article: Visual Programming and Why It Sucks

[ocratato]

Originally Posted by jpollard

You forgot about programmers that have color blindness...

The usual symbol for a test point is a rectangle/square rotated 45 degrees. For loops it was a rectangle with triangles on either side.

And left out a very important concept called "pipe".

Nothing was mentioned about the editor functions - such as simplifying drawing (minimizing line intersections) reoganization (moving chunks of the diagram around). For a basic editor you might look at TGIF.

Nice document for a starting point.

Thanks for your comments.

Colour blindness was actually mentioned in para 4.9 on user configuration. Pipes are shown as thick lines on several diagrams, as are references to stdin, stdout and stderr. A named pipe, however, was not mentioned, and might be a useful addition.

I gave some thought to using a diamond shape for tests, but since any command can have an error exit status it would be just a visual artifact - though it might be useful for documenting the intent and structure of the script.

As for editor functions - that is a good point. I have used GraphViz in the past for automating the layout of diagrams, but I am not sure how easy it would be to use for a complex flow chart. The little program shown in 4.10 already has the capability of moving multiple objects, so manual reorganisation will be possible.

It must be remembered that the intent for this program is simple scripts, not vast complex programs like us programmers tend to end up writing. It must look like it is simple to use.

---------- Post added at 12:40 PM ---------- Previous post was at 12:31 PM ----------

Originally Posted by RupertPupkin

I suggest you read this article: Visual Programming and Why It Sucks

Thanks for the link. I think it makes the case FOR this little project quite well.

Remember, my aim is to build something that a secretary might use to sort some stuff, not to be used by the likes of us to create the next great program.

[jpollard]

If that is the only case you have, then it would be simpler to teach the sort command itself.

After all, 4 to 5 lines is a "simple" script. Takes only 5/10 lines including documentation...

Scripts that short are usually throwaways.

[ocratato]

Originally Posted by jpollard

If that is the only case you have, then it would be simpler to teach the sort command itself.

After all, 4 to 5 lines is a "simple" script. Takes only 5/10 lines including documentation...

Scripts that short are usually throwaways.

I think we have closed the loop on this thread

My initial aim (see my origial post) was to provide an ability for the desktop user to make what you and I would call throwaway scripts to do those simple tasks, and to enable them to access the hidden gold mine of command line programs.

[jpollard]

Originally Posted by ocratato

I think we have closed the loop on this thread

My initial aim (see my origial post) was to provide an ability for the desktop user to make what you and I would call throwaway scripts to do those simple tasks, and to enable them to access the hidden gold mine of command line programs.

Yet you have taken away the command line...

[ocratato]

Another update for anyone that comes across this thread...

The high level design has been done - though I expect a few tweeks will be needed as work progresses.

The detailed design is underway. So far 140 classes have been identified, and I expect this number to increase as the design work proceeds.