It takes the data from an online message submission form. Processes it, checking that the required fields are filled, and constructs an email to send me. If the fields are filled then, it sends that email off, and pop’s up a message saying that the message has been sent. If the fields are not, it won’t send the email and will let the user know the error.
It’s built from nodes, the circles, and arrows between them. Nodes are where code lives, producing and modifying data. For example, the form node creates a packet of data containing all the information that was entered in the form when the user clicks a submit button. The arrows are how the data moves around the program. The arrow between form and messageConstructor lets the former hand that packet to the later, where the email is constructed. Arrows are drawn between ports. The function of a node determines what ports it has. The code nodes (the filled ones) contain just that, code. In the dialogue below you can see the code of a splitter node, as well as its ports.
The other kind of node, the unfilled ones, are called structure nodes. They are not written in code, but instead contain a structure of other nodes. Below we can see that messageConstructor in fact contains two branches, one gives us the output we want on if one of the required fields isn’t filled (this is failureValue) whilst the other, successMessageConstructor, gives us the output we want on a success.
In fact, successMessageConstructor is also a structure node, and we could go deeper into that if we wanted to understand or change how it acted.
Overall we have a few levels that we can understand this CRANQ program from. From the highest overview, we can see how it accomplishes what it does. Then, depending on the steps in this process, we either have more structure, so we can understand how that step is achieved, or we have code, which is understandable because it accomplishes something precise and small. In this way then, the program matches closely with how we image it in our heads. This helps us to reconcile the difficulties that come from the dual role of the developer. When I wrote it, I made the full view first, because I had a sense of how I wanted to make it work. Then, some of the nodes were already built, like splitter or form and others, like ifElse, I built up, either by writing code directly or by giving them structure.