A book called “Diagramming Techniques for Analysts and Programmers” (1985). Found it through a paper by David Harel. He descibed it as:

The state of the art on diagrammatic languages at the time can be gleaned from the book by Martin and McClure titled > Diagramming Techniques for Analysts and Programmers> . This book discussed many visual techniques, but little attention was given to the need for solid semantics and/or executability. Curiously, this book could have helped convince people that visual languages should not be taken seriously as means to actually program a system the way a standard programming language can.

https://archive.org/details/diagrammingtechn00mart/page/310/mode/2up

Also started reading through “Usability Analysis of Visual Programming Environments: a ‘cognitive dimensions’ framework” by Green and Petre (1996).

The dimensions in outline: The list of dimensions that we shall use in this paper follows. For each dimension we supply a thumb-nail description. A lengthier account of the dimension and its relation to the underlying evidence will be found in the appropriate section below.

• Abstraction Gradient: What are the minimum and maximum levels of abstraction? Can fragments be encapsulated?
• Closeness of mapping: What ‘programming games’ need to be learned?
• Consistency: When some of the language has been learnt, how much of the rest can be inferred?
• Diffuseness: How many symbols or graphic entities are required to express a meaning?
• Error-proneness: Does the design of the notation induce ‘careless mistakes’?
• Hard mental operations: Are there places where the user needs to resort to fingers or pen- cilled annotation to keep track of what’s happening?
• Hidden dependencies: Is every dependency overtly indicated in both directions? Is the indi- cation perceptual or only symbolic?
• Premature commitment: Do programmers have to make decisions before they have the information they need?
• Progressive evaluation: Can a partially-complete program be executed to obtain feedback on “How am I doing”?
• Role-expressiveness: Can the reader see how each component of a program relates to the whole?
• Secondary notation: Can programmers use layout, colour, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language?
• Viscosity: How much effort is required to perform a single change?
• Visibility: Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to juxtapose any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

https://web.engr.oregonstate.edu/~burnett/CS589and584/CS589-papers/CogDimsPaper.pdf