When I moved to a house on the edge of a forest I enjoyed many hours exploring the trails, but when maps placed at strategic points consistently sent me in the wrong direction, I thought years away from the world of compass points and orienteering had finally caught up with me. It was not until I stood looking at a map in front of Enos Lake that I discovered the real reason. The map suggested that the lake, which was clearly before me, should in fact be located behind; the map had been mounted backwards with respect to the surrounding terrain. As I saw more maps on the trails, I found that they had all been placed with a similar aspect; even more misleading because they were usually in the middle of the forest, away from prominent features that allowed reorientation.
And the point of this story? Well for the last couple of years I have considered translating the textual form of the J computer language into a visual one, and it has become clear that visual interpretation requires coordination with the structure of the language on a fundamental level. As with my experiences on the trail, it is vital that the map (visual interface) fit the terrain (the structure of the language), or at every step along the way we risk losing our users due to unnecessary mental effort.
So let’s look at the J’s terrain before we position our map. J uses a text based representation to expresse values and structures of its arrays to the programmer. While this style is very good at showing the values of the arrays, it is less effective in conveying their shape and structure (particularly in the case of singletons or arrays with zero valued indices in their shape). For now let’s look at how an array of 2 numbers would be shown.
2 $ 1 2 1 2
To explain, the top line is the instruction to create the array and the second line is the representation. On the top line, the 2 in front of the $ means that the 2 items after the $ will be used to make an array of length 2.
If we represented the numbers as children’s blocks it might look like this:
Similarly a two-dimensional array would be represented with rows and columns. In the example below there are now two numbers before the $. The first number, 3, gives the number of rows and the second number, 2, gives the number of items in each row.
3 2 $ 1 2 3 4 5 6 1 2 3 4 5 6
And in block notation we could stack the blocks as follows:
When we move to three dimensions it gets a bit more complicated. There are now three numbers before the $, and the first number, 3, indicates the number of 3 X 2 planes that we will have. J uses the linefeed to insert an empty line between the planes and separate them in a very effective way.
3 3 2 $ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
If we use the blocks, the situation presents a choice that was not present in our first two examples. Do we stack the planes with the first plane at the back or at the front? Here is an example of the two approaches:
Either choice could work but I prefer having the planes stack like the pages of a book, with the ones closest being the ones that are listed first. This also allows the position in the upper left front corner to be an anchor easily located by the viewer. If instead the planes were added moving forward toward the viewer, then the visible corner value would change as every plane is added. There are enough challenges in understanding array languages without having the positions in the array dance before your eyes.
And it is at this point, gentle reader, that you come in. My perception is but one data point in creating representations for a much wider audience. I welcome feedback about the suitability of the ‘book pages’ approach to three-dimensional arrays, but concerns about the row and plane representations in the case of two-dimensional arrays are important as well in revealing even deeper fundamental differences in visualization. Don’t worry about the fact that J’s text approach and my block visualizations do a poor job of distinguishing between atoms, lists, or matrices of only one value, I will be addressing that in a future post. For now, just let me know if the direction my map is pointed makes sense to you.
Thanks in advance for your help.