Cognitive dimensions ‘beyond the notation’
Introduction
From the time I joined Thomas Green in his formulation of cognitive dimensions (CDs) in 1989, our discussions were bedded in examples and empirical results. What we both wanted to know was how notations (or, more broadly, information artefacts) work when they do, and why they don’t when they fail. CDs were an attempt to capture and articulate these issues. Thomas had been drawing on his extensive knowledge of notation types and examples, and I brought along my questions and examples from empirical studies of professional software developers’ use of programming languages and other representations to solve problems. In order to make sense to each other—and especially when we didn’t—we referred continually to examples.
The ideal for CDs was to make cognition-related attributes of notations evident, in a way that related those attributes concretely and clearly to how notation users employ and experience notations. We strove for a theory that could reveal hidden attributes of the concrete. We needed user-relevant dimensions, and we needed to express them or interpret them into forms that were user-friendly. That drove the ‘straw tests’ in the 1996 paper, and it carried through later in the work Thomas did with Alan Blackwell on the CDs questionnaire [1].
This paper reflects on how empirical studies of professional software developers have informed the development of CDs—and have raised persistent questions for CDs. The remainder of this paper is in three sections: the first recalls how empirical studies contributed to the CDs portrayed in the 1996 paper; the second considers unresolved issues, especially issues ‘beyond the notation’ which might yet be addressed by CDs; and the third explores a possible approach to those issues.
Section snippets
Using lessons from empirical studies of professional software developers
At the time Thomas Green drew me into his development of CDs, I was spending time observing professional software developers in an attempt to understand something about the relationships between their reasoning and the ways they represented their solutions, whether as programs or in some other form. As a result, there was ample opportunity to ‘float’ some of the CDs ideas with them. What was striking was their response to the CDs, which appeared to offer names for things these expert,
Beyond the notation: unresolved challenges in CDs
CDs are a useful concept and metalanguage, providing an account which is derived from an interaction between theory and experience. They reflect, however, just one aspect of the design process. It is their relationship to other aspects of the design process—particularly those contiguous with representation, such as convention and process—that has fuelled so much discussion. Our biggest struggle centred on scope: where does the notation end, and how much does a CDs analysis include? Many of the
Possible solution: one way to represent this is facets
It is clear that there is no single satisfactory structure which represents clearly the relationships between the various CDs. A possible solution involves using a multiple structure, via facet theory. “The essence of facet analysis is the sorting of terms in a given field of knowledge into homogeneous, mutually exclusive facets, each derived from the parent universe by a single characteristic of division” [6].
Facet theory has been around in library science and information systems for
Example application: drawing on specific expertise
So how might this work for CDs? Still thinking within the context of software design representations, let's consider how we might identify facets, and whether doing so provides any leverage on the issues raised.
“The essence of facet analysis is the sorting of terms in a given field of knowledge into homogeneous, mutually exclusive facets, each derived from the parent universe by a single characteristic division” [6, p. 1] The first step is to identify facets. Fig. 1 offers a first attempt,
Conclusion
CDs have been effective, providing a framework on which to hang guidelines, and by which to structure economical analyses of representations of various kinds. Further, they provide a metalanguage allowing really useful discussions with designers and expert users of representations. They hold promise as a vehicle for eliciting and potentially capturing users’ perceptions and understandings of representations [11].
Like many frameworks, CDs ‘raise the stakes’, making evident and accessible issues
Acknowledgements
I will always be grateful to Thomas Green, for letting me play in his sandbox. Cognitive dimensions are his baby. Thanks to the software developers who have informed me over years. Thanks to Alan Blackwell and his anonymous readers for constructive criticism. Thanks to Gordon Rugg for patient discussion and input. Some of the work discussed here was funded under an EPSRC Advanced Research Fellowship (GR/A00126/), and some under an EPSRC grant (FaCADE: Facilitating Communication Across Domains
References (11)
- A.F. Blackwell, T.R.G. Green, A cognitive dimensions questionnaire optimised for users, in: A.F. Blackwell, E. Bilotta...
- et al.
Where to draw the line with text: some claims by logic designers about graphics in notation
- T.R.G. Green, M. Petre, R.K.E. Bellamy, Comprehensibility of visual and textual programs: a test of Superlativism...
- M. Petre, Software development expertise. Expert Systems, in...
- M. Petre, Mental imagery, visualisation tools and team work, Keynote paper, in: Proceedings of Second Program...
Cited by (21)
Visual Design Thinking: A Collaborative Dimensions framework to profile visualisations
2019, Design StudiesCitation Excerpt :NET Platform (Clarke, 2005; Green, Blandford, Church, Roast, & Clarke, 2006): they created a visual aid in the form of a radar diagram to present the results of usability analysis, comparing the fit of the system to the users’ needs. Petre (2006) reported that information artifact designers, when exposed to the framework, “immediately recognised the meaning of the CD, and applied it to their own, already existing, but preverbal, concepts.” ( p. 293).
A study on the effects of routing symbol design on process model comprehension
2013, Decision Support SystemsCitation Excerpt :Modeling design choices especially relate to notational aspects — the choice of different visual symbols for describing a process in the model. Precisely, the modifications may relate to the formal rules of a modeling grammar (its primary notation) or the way a specific model is visualized (its secondary notation) [50]. While the primary notation is normally prescribed by the specification of a modeling grammar, it has been shown that secondary notation influences process model comprehension, for instance, in terms of modularity [60], the grammatical style of text labels [36], or color highlighting [58].
Syntax highlighting in business process models
2011, Decision Support SystemsCitation Excerpt :By enriching the process model with information beyond the formal notation (e.g. color, line strength, etc.), the reader may access the information captured in the model with a differing degree of ease [51]. Visual cues, which are not part of a notation, are known as secondary notation [52]. These visual cues have a twofold advantage.
Designing and Evaluating the Usability of a Machine Learning API for Rapid Prototyping Music Technology
2020, Frontiers in Artificial IntelligenceHow quickly do we learn conceptual models?
2019, European Journal of Information Systems