Nested Tree Mockup

def symbol

label = "Home Location"

latlong

def structure

label = "latlong"

surface

lat

long

process

distance

complicated sphere wrapping formula

EXPECTATION

On HTTP_Request

Expect .*/HOST{value="geekgene.com"}

expr

then

expr

then

some proc tree

else

some other proc tree

else

expr

then

some proc tree

else

some other proc tree

With SessionInitParams

Instance = 48

This is just a quick experiment with the CSS (1 selector with 4 properties). I could probably make it sexier, but it's pretty darn readable from both text and tree perspectives, I think.

Try playing around with the width of the window and watch how the structure adapts. I don't think it's fully cross-browser compatible, but seems fine in Chrome, Firefox and IE 11 (9 and up, I think)

Noteworthy issues to consider when translating typed text to trees:

I don't think we want to require parens when we can use syntactical context.
For many processes, we probably want to have keywords indicate advancing to next branch (almost like parens, but not paired... we could manually pop up by typing a close_paren (or other special key) and not display the paren just change the tree formatting/placement of cursor).

e.g. If {first-child} Then {second-child} Else {third-child}
e.g. On {first-child} Expect {second-child} Do {third-child} With {fourth-child}

In fact, I think we'd want to prepopulate the next child keywords and be able to tab into their slot to type (tab then press {delete} to delete optional ones like ELSE or WITH).
Where/How do we store such keyword sequence associations? Label Table?
It doesn't make a lot of sense to display Symbols as def trees like above. A label table view would be much more useful.
It also seems like we could make a simple def-symbol button or something to generate those kinds of entries.
Similarly, it seems fairly easy to build a Structure Def tool for everything up until the process defs... which is where we switch back to the coding style originally describe above. So "coding" is always for writing processes. We can make a pretty simple UI for def-building so that constructing the semantic trees for content which work slightly differently than code, don't get confused with process trees.

Possible Color Coding Approach for Semantic Tree Background Colors:

First Column (named) colors are for borders, controls, etc.
Second Column nested colors are for recursing tree levels. They need to be darker than expected because 10 steps of 10% opacity <> 100%

Note: We probably want to use the inverted colors (right-most) so that color clarity is higher in the initial levels setting type context clearly. It also makes layering veary easy because you're always adding a new layer of transparent white. Every time you switch symbol contexts (Process, Symbol, Receptor, etc.), you start a new color context layering anew (That's why the inverted colors may make more sense.)

Process: seagreen

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(0,100,0,.1)
Receptor: gold

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(190,175,0,.1)
Protocol: tomato

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(190,110,0,.1)
Semtrex: crimson

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(150,0,0,.1)
Symbol/Label: blueviolet

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(80,0,130,.1)
Value/Literal: royalblue

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(10,40,120,.1)
Def/Structure: sienna

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(90,60,30,.1)