Expressing the structure

In this chapter I have covered in some depth how to typeset a lish so that elements of differing widths are aligned in a tabular way: that is, the ge- ometry of how a lish is to be presented to the user in two dimensions. The final appearance of the lish as displayed will also depend on other aspects such as the use of gridlines, relative spatial separation, and colour. Some of these could be placed under the direct control of the user by consulting appropriate cell attributes as the lish is rendered, in the same way as was done for fonts earlier. It would be useful, however, if even the default ren- dition could make effective use of such properties to enhance the way the lish is displayed. Some desirable characteristics of the final output are:

• It should be clear to the user what the underlying list structure is. This addresses the role expressiveness cognitive dimension.

• Areas that are intended to be tables should be recognisable to the user as such. This addresses the closeness of mapping cognitive dimension. • The result should be visually engaging (for example, laid out so as to

invite easy scanning; free from extraneous clutter).

A detailed exploration of these characteristics, and the tensions and trade-offs between them, is beyond my scope here; it would be a large and useful area for future work. But the lish editor has to display something! I have therefore made some pragmatic choices that go some way towards meeting the criteria above, and implemented them in the lish editor. In the remainder of this subsection I simply describe these choices without detailed justification (though I do sketch a brief rationale).

Shading and colour

When I first introduced the lish, I used the style of Figure 3.4 on page 48. This style is useful for making clear what the structure is, but does not scale well to more complicated lishes, where an excessive depth of nesting of the boxes would make for difficult reading. The lish editor uses a more subtle indication of the depth of the structure by shading the margins of each lish on a graded scale (I have chosen to use pale brown / creamy shades). To preserve visual differentiation, the scale is recycled once the structure becomes more than four lishes deep. An alternative would have been to use a wider range of shades so as to increase the depth before recycling becomes necessary, but this would give the display a rather dark, “muddy” appearance.

Cells are usually displayed with black text on a white background. As we have seen, however, the first element of each lish has a special status with regard to generating templates. In the next chapter, such elements will acquire a further distinction with regard to how they are used in calculations. So in the editor, I distinguish these template-forming cells by giving them a blue-grey shading. Once again, a fourfold scale is used depending on their depth, and recycled as necessary. Cells that are either themselves the first element of a lish, or lie within an ancestor that is a first element, are treated in this way.

It will be seen that there is a tendency for multi-dimensional lish struc- tures to have rather large numbers of these template-forming cells, many of them empty (represented by null). To avoid profligate use of display space,

              

•, Var1, Var2, Var3 ,  •, •, •, • ,  •, •, •, • ,  •, •, •, •         ,        

•, Var1, Var2, Var3 ,  •, 1, 2, 3 ,  •, 4, 5, 6 ,  •, 7, 8, 9               

Figure 5.5: A rendition of a lish showing the use of lines and shading (above) and the underlying list representation (below). The red box around the 6 is the cell cursor.

empty template-forming cells are assigned smaller internal dimensions than are given to ordinary cells lying in the body of the lish. In practice I have observed that this scheme is only partially successful – they still occupy more space than is desirable. An improved version of the editor would offer the user the option to hide these cells altogether.

An example of this scheme can be seen in Figure 5.5. All the cells in the left hand half of the table are template-forming (since they all lie in the first sublist of the root), so they have all been assigned the blue-grey shading. In the right hand half of the table, the cells in the top row and left hand column are also template-forming, so they too have this shading; the cells containing the numbers 1 to 9 are not template-forming, so have a white background. The columns that contain only nulls have been rendered narrower than the rest, since their cells all have the smaller internal dimensions.

Lish margins

In Figure 5.5, a pale brown margin can be seen around both of the two top- level sublists, and around the root. But no margin is visible around any of the eight innermost sublists. This is because the lish editor has been set to collapse the margin width to zero on certain sublists. The aim is to retain a

       Title cell,      •, Var1, 

•, Var2a, Var2b , Var3 ,  •, 1,  •, 2, 3 , 4 ,  •, 5,  •, 6, 7 , 8            

Figure 5.6: The suppression of top and bottom margins around the column group containing Var2a and Var2b.

Figure 5.7: The use of a “box” view on the lish of Figure 5.5, to clarify the underlying structure.

margin where the visual separation would be helpful, but suppress it where the result would be an unnecessarily sparse layout (rather like double-spaced text). To be precise, the rules the editor applies are:

• When both a lish and its parent are oriented horizontally, the inner lish is given only left and right margins. A corresponding rule applies when both are vertical. This prevents a spurious increase in the row height within a table when a column group is introduced.

• When a sequence of lishes having the same archetype lie alongside, the margins along their adjacent edges are suppressed. This causes the elements of such lishes to be displayed slightly closer together than would be the case if they had no common archetype relationship. The first rule can be seen in action in Figure 5.6. The column group containing Var2a and Var2b has a brown shaded margin on either side, delimiting it within the table of which it forms a part. But there is no brown shading between the sublists [•, 2, 3] and [•, 6, 7]; the row height is not inflated by the presence of the column group.

Gridlines and box view

The editor uses gridlines sparingly, to mitigate the visual overload of multi- ply nested boxes. Where a sequence of lishes form the rows of a table, a light horizontal rule is drawn under each, but not between the cells. Similarly, if a sequence of lishes represents columns, a vertical rule is drawn. This gives the user a hint to the underlying structure of the table. A lish that contains a higher than two-dimensional structure is subdivided by slightly heavier rules, examples being the three vertical lines dividing the top level structure in Figure 5.5. Areas containing dynamically generated cells (to be introduced in subsection 6.3.2) are shown with a dotted border.

Early experience with the editor suggested that the rendition of the lish described above, while quite effective as a way of showing lists as tables, tends rather to obscure what the underlying list structure is. To mitigate this problem, I added the option of turning on a “box” view which shows that structure more explicitly. In this view, a full grid is drawn over the parent list of the element selected by the cursor – that is, every element is outlined, giving a “ladder” appearance. In addition, green boxes are drawn around the ancestors of the parent, to a maximum of four levels. These additional annotations give the user a clearer view of the local structure surrounding

the cursor. The green boxes are drawn slightly expanded relative to the sublists that they enclose. This is so that where the margins of nested sublists were suppressed as described above, the boxes will not be coincident, ensuring that an outer box always strictly encloses an inner box. An example is shown in Figure 5.7.