Cognitive Dimensions
1989。被引用が886くらいあり、相当有名かつ自分の主張に近そう。
モチベーション
‘Cognitive dimensions’ are features of computer languages considered purely as information structures or notations. They therefore apply to many types of language—interactive or programming, high or low level, procedural or declarative, special purpose or general purpose. They are ‘cognitive’ dimensions because they control how (or whether) the preferred cognitive strategy for design-like tasks can be adopted: it has repeatedly been shown that users prefer opportunistic planning rather than any fixed strategy such as top-down development. The dimension analysis makes it easier to compare dissimilar interfaces or languages, and also helps to identify the relationship between support tools and programming languages: the support tools make it possible to use opportunistic planning with notations that would otherwise inhibit it.
Physicists reduce all physical quantities to combinations of three fundamental dimensions, mass, length, and time, all of which are abstractions from the phenomenal world (for example, we perceive weight but not mass). Such varied phenomena as electric charge, gravitational attraction, elasticity, and temperature are all reduced to different combinations of the same three dimensions: a remarkable and enviable achievement. Rather cheekily, I suggest that in HCI we attempt to tread the same path. Many different ways of working at the computer can potentially be accounted for by the interrelationships between a single preferred cognitive strategy and a small number of facts about the language of communication, or ‘notation’, and the circumstances of its use, or ‘environment’.
めちゃくちゃ野心的じゃん
Cognitive science, it must be remembered, is really rather more like plant biology than like physics, in that a whole host of factors (some of them interdependent) affects the growth of plants. Nevertheless our urgent need is for a small number of clear, powerful ideas, which we can pretend are orthogonal.
orthogonalな軸を打ち立てたいということらしい
We are more used to speaking of programming ‘languages’ than notations. I shall use the term notation to keep the form distinct from the content. Pascal, as a programming language, might be properly criticised for its content (poor provision for string manipulation, bit processing, and file handling); but as a notation these omissions are not relevant—what matters is the form; e.g., the identifier hierarchy is very rigidly controlled, from which both advantages and disadvantages flow.
Unfortunately, because of certain characteristics of the Pascal notation, it is pretty well impossible to dictate impromptu Pascal correctly without any omissions. (See below.) In short, although the system worked reasonably well at the technical level, it failed to meet its objectives, simply because Pascal is not a suitable notation for this environments.
なるほど。つまり、UIにおける「記法」が、あるシチュエーションに照らし合わせて実際に使いやすいものである必要があるということか。面白いモチベーション。
written down notationにより着目し、interactive languagesは副次的と書いてある。written down notationは、プログラミング言語やtex、visual programming languagesなどのこと。interactiveはcalculatorなど。
Notations have manifold uses. Important ones are communication (at a distance or over time) and design. I shall focus on their use in design, for recording partial decisions, working out consequences, undoing or confirming decisions, leaving reminders, etc.
We cannot simple-mindedly claim that procedural languages are either easier or harder to read than declarative ones; it would be more valid to say that the structure of procedural languages makes it easier to extract sequence information than circumstance information (Green, 1977), while the reverse is true for declarative languages (Gilmore & Green, 1984).
おいおい手続き的 vs. 宣言的.iconの話はもうされてるじゃないか!読まねば
これを引用している論文たちもかなりいい感じに見える。
そもそも"Notation"という概念が自分の言葉の範疇になかった。これは掘りがいがありそう。
Viscosity
Are there any inherent barriers to change in the notation? How much effort is required to make a change to a program expressed in the notation?
This dimension can be further classified into the following types:5 'Knock-on viscosity' : a change in the code violates internal constraints in the program, whose resolution may violate further internal constraints.
'Repetition viscosity' : a single action within the user’s conceptual model requires many, repetitive device actions.
'Scope viscosity' : a change in the size of the input data set requires changes to the program structure itself.
被引用を眺めてみる