Building on Therriault's ideas, I have sketched out some ideas I would like in a J visual interface.
1) A Derived entity should take a colour which is a mixture of the colours of its parts. This allows us to quickly identify how it was formed. Restricting verbs, conjunctions and nouns to primary colours makes this easier.
2) Hooks and forks should have distinct colours as they are special constructs in the language.
3) Gerunds should be shaded a common colour(close to a verb's colour preferably) to emphasize that it acts as one element.
4) The arguments to a function (x and y) should be optionally displayed(toggled or and off).
5) The user should be allowed to edit the structure by dragging and dropping elements as they wish and have the code updated automatically.
Some more ideas are detailed in the diagrams below:
An alternate version where all arrows point up, indicating data being fed into a pipeline. Expansions of derived entities are represented by dashed lines. This way the figure can be flipped upside down and still be readable.
Sami,
ReplyDeleteYou've done a great deal of thinking on this interface. Having spent some time myself on it, I find it fascinating to see where we converge and diverge in our thought. Now my comments.
1) Having the derived entity be a mixture of colours is something I had not considered. It is a very innovative approach, but has a few challenges. The first one is that many users are challenged in distinguishing particular hues, so choosing colours that can be seen as different across the general population could be problematic. The second I see is how to represent derived entities that become a basic part of speech. An example is 'each' &.>. This takes the conjunction &. (under) with the monadic verb > (open) to create a derived entity which is an adverb (each) which will unbox, apply a selected verb, and box an argument. In your example the colour would be purple, but the fact that it is also an adverb would suggest yellow should also be included in the visual presentation.
2) Separate colours for hooks and forks is certainly one way to distinguish them (colour challenged users aside), but my preference remains that they be considered conjunctions. This allows more flexibility in more complicated expressions of nested forks are represented. Perhaps if you showed how you would approach an expression like
(-~+/%#) y
I would have a better idea of how this would either simplify or complicate the concept.
3) I haven't spent too much time thinking about gerunds yet, past the fact that they are actually nouns. This is an area where shading by making the luminance either brighter or darker might be a way to distinguish without needing hue differentiation. It also would have the tendency of reducing the saturation which would bring it closer to the monotone. I like this as I was thinking of nouns as blacks, whites or shades of grey.
4) Toggling the x and y display is a great way to give the viewer control over the complexity, as long as it doesn't change the nature of the operator display. What I mean by this is that I like the fact that the arguments allow you to differentiate monadic from dyadic verbs and I wouldn't want to see those properties disappear along with the x and y arguments. Also, in your diagrams I didn't see any indication the viewer would have access to intermediate results. I think this is pretty important and was wondering how you let the viewer see that +/ takes 3 4 5 6 and sends 18 as a result to % in the fork.
4) I think the drag and drop idea is okay as long as the structure of the diagram can be maintained. For example, a user could drag and drop the components into a pattern that completely obfuscates the meaning, either intentionally or through ignorance of the language. I might like an ability to 'swap out' operators on the diagram by clicking on the diagram and then a new operator to see the effect the change has, but I want the diagram to consistently represent the language and not be manipulated by me repositioning things. As an aside, the language that I think does the best job of this is Scratch, scratch.mit.edu/ which is an MIT project written in Squeak (a version of Smalltalk).
Thank you for all of your work on this. It is really great to see another take on the visual presentation of J and I look forward to see how you develop your ideas.
Cheers, bob