Further remarks

In this example, there is an excellent closeness of mapping between the lish and the problem domain. The structure of each sample, with fields for sample code and mass followed by a table for the readings (with column grouping within it), is faithfully captured. The template behaviour of the lish is a natural fit for this repeating structure in which each sample has the same form. The lish also allows selections of non-adjacent cells that represent a single object, such as “all the sample masses”, to be treated as such. At the same time, it is sufficiently flexible that properties of an object that are not logically shared with its neighbours are not imposed upon those neighbours. For example, the six cells at the top including the calibration factor have different widths to those immediately under them in the main table. This is as we would wish, since alignment of those cells would not represent any concept that is meaningful to the application – but a normal spreadsheet grid would nevertheless enforce it.

Most of the formatting in Figure 7.5 is the default supplied by the edi- tor. A small amount of secondary notation has been applied manually: the main title and summary report title are in a larger font, and some column widths have been adjusted. The shading and gridlines were all generated

automatically from the lish structure as described in subsection 5.4.1. The generated formatting does a reasonable job of visualising the structure, so there is less need for users to supply these visual elements themselves, as they might do in a spreadsheet.

As with the cashflow example, hidden dependencies are present; the cost of very DRY formulae is that in the density calculations, the formulae are rather distant from the cells that they affect. Once again, it would be a straightforward improvement to the visualisation to make these dependen- cies more explicit. In designing the editor, I adhered to the spreadsheet convention that the data are visible but the formulae invisible until a for- mula cell is selected. The lish has so few formulae, however, that it might be preferable to display both data and formulae by default; the penalty in screen space would be negligible compared to doing the same thing in a spreadsheet.

7.5

Conclusion

In this chapter I examined lish representations of a number of practically useful structures: 3D tables, spanning headings, and a more complex exam- ple having mixed scalar and tabular data with repeating patterns.

The main advantages from using a lish over a spreadsheet for these struc- tures arise from the improved closeness of mapping in the lish. This allows the machine to automate the generation of repeating patterns and to en- sure consistency as data are added or deleted. Formulae are simplified, in particular because the way in which lish calculus is defined over hierarchical structures obviates the need for explicit absolute versus relative references. The editor promotes a workflow where the user can start from a small con- crete example and subsequently add more data, or even more dimensions, without having to change the original formulae. Hence premature commit- ment is avoided.

Some limitations of the lish were also apparent. The presence of hidden dependencies and a tendency towards diffuseness might be problematic, al- though these could be addressed in a straightforward way by an improved editor. Of greater concern was the need for “programming games”, espe- cially in the representation of spanning headings. The picture on viscosity is mixed. The ability for the user to revise a formula in a template, or to add a row for more data, and in both cases have the changes automatically reflected elsewhere in the application, certainly reduces viscosity. On the

other hand, the lack of support (currently) for more fundamental refactoring of lish data rather increases it.

Chapter 8

User study

8.1

Purpose and scope of study

Among my original research questions, I asked:

What would be the consequences for analytical workflow of us- ing a lish, instead of a grid, as the basis of a spreadsheet-like environment?

and

Where would this alternative representation be located in the space of the cognitive dimensions?

Until now, I have approached these questions as a desk-based exercise. This has yielded partial answers. For example, in the previous chapter I demonstrated some example workflows with the lish, and commented on how these differed from building similar models with the spreadsheet. On the cognitive dimensions side, I have also made some progress simply by inspecting worked examples. In this chapter, I seek a fuller answer by in- volving some actual users. To assess workflow, I observed those users at work with the lish; to assess the cognitive dimensions, I interviewed them to find out how they experienced and understood it.

The focus of the study was on expert analysts rather than casual spread- sheet users, as the lish (in its current form, at least) is not really well suited to the latter. The participants were recruited from the UK Government Operational Research Service (GORS) and related analytical professions. GORS covers a diverse range of methodologies including forecasting, opti- misation, system dynamics, queue modelling and statistics. All participants

were power spreadsheet users, and in most cases had coding experience as well.

Confining the study to a single professional group clearly limits the ex- tent to which the results might be generalised to other spreadsheet users (accountants, say). Resource constraints precluded repeating the study else- where, so we should be cautious in generalising beyond the study popula- tion. This limitation is however mitigated a little by the diverse range of applications and model structures encountered within GORS.