Once the keyboard enables creation of diamonds--and some way to specify yes/no and traverse those boxes--we'll be well on our way to flowcharts.
If one were navigating sub-levels of logic in a flowchart with keyboard, I wonder if it's better to have a modal experience or a top-level consistent experience.
The modal one gives feedback to the UI that we're in a nested part of the flowchart. The top-level always navigates boxes regardless of the type (rectangle or diamond). Or maybe some combination in between.
Just as a reminder about flowcharts:
> For many people it has long been article of faith
that flowcharting should precede coding. There is
a kernel of important truth here: coding cannot be
the first stage in building a program; it must be
preceded by design. But flowcharting is not designing.
Design is about structure, and flowcharts, as their
name suggests, are about the flow of control. At the
time when the designer should be thinking about the
shape of his problem, the flowchart encourages him to
think about execution of the program inside the
computer. Of course, some programmers who draw
flowcharts do produce well structured programs; but
their success is in spite of the technique, not because
of it. Flowcharts tend to conceal structure...
Principles of Program Design. M.A. Jackson (1975)Searches which yield graphs more like what you're doing are "concept maps", "block diagrams", "org charts", or "tree diagram". However, your tool allows zero or more parents and zero or more children, whereas many of these don't allow all those choices or allow more than that.
Flowcharts need at least diamonds and circles in addition to rectangles. They also allow arbitrary connections, not just parent, and children. I'm not a topology person, but from some digging around, it seems like the connections that you're allowing are typical of a "directed acyclic graph".
It also needs loops, else it's just a simple tree, precluding a lot of use-cases for flow charts.