The cognitive dimensions framework is a broad-brush evaluation technique for interactive devices and for non-interactive notations. It sets out a small vocabulary of terms designed to capture the cognitively-relevant aspects of structure, and shows how they can be traded off against each other. The purpose of this paper is to propose the framework as an evaluation technique for visual programming environments. We apply it to two commercially-available dataflow languages (with further examples from other systems) and conclude that it is effective and insightful; other HCI-based evaluation techniques focus on different aspects and would make good complements. Insofar as the examples we used are representative, current VPLs are successful in achieving a good `closeness of match', but designers need to consider the `viscosity' (resistance to local change) and the `secondary notation' (possibility of conveying extra meaning by choice of layout, colour, etc.).

We present a new visual programming language and environment that serves as a form of feedback and representation in a Programming by Demonstration system. The language differs from existing visual languages because it explicitly represents data objects and implicitly represents operations by changes in data objects. The system was designed to provide non-programmers with programming support for common, repetitive tasks and incorporates some principles of cognition to assist these users in learning to use it. With this in mind, we analyzed the language and its editor along cognitive dimensions. The assessment provided insight into both strengths and weaknesses of the system, prompting a number of design changes. This demonstrates how useful such an analysis can be.

Software development remains mentally challenging despite the continual advancement of training, techniques, and tools. Because completely automating software development is currently impossible, it makes sense to seriously consider how tools can improve the mental activities of developers apart from automating them away. Such mental assistance can be called “cognitive support”. Understanding and developing cognitive support in software engineering tools is an important research issue but, unfortunately, at the moment our theoretical foundations for it are inadequately developed. Furthermore, much of the relevant research has occurred outside of the software engineering community, and is therefore not easily available to the researchers who typically develop software engineering tools. Tool evaluation, comparison, and development are consequently impaired. The present work introduces a theoretical framework intended to seed further systematic study of cognitive support in the field of software engineering tools. This theoretical framework, called RODS, imports ideas and methods from a field of cognitive science called “distributed cognition”. The crucial concept in RODS is that cognitive support can be understood and explained in terms of the computational advantages that are conferred when cognition is redistributed between software developer and their tools and environment. The name RODS, in fact, comes from the

Process management is a crucial issue in developing information or computer systems. Theories of software development process management suggest that the process should be supported and managed based on what the process really is. However, our learning from an action research study reveals that the requirements engineering (RE) process differs significantly from what the current literature tends to describe. The process is not a systematic, smooth and incremental evolution of the requirements model, but involves occasional simplification and restructuring of the requirements model. This revised understanding of the RE process suggests a new challenge to both the academic and industrial communities, demanding new process management approaches. In this paper, we present our understanding of the RE process and its implications for process management.

This article presents a cognitively oriented viewpoint on design. It focuses on cognitive, dynamic aspects of real design, i.e., the actual cognitive activity implemented by designers during their work on professional design projects. Rather than conceiving designing as problem solving—Simon’s symbolic information processing (SIP) ap-proach—or as a reflective practice or some other form of situated activity—the situativity (SIT) approach—we consider that, from a cognitive viewpoint, designing is most appropriately characterised as a construction of representations. After a critical discussion of the SIP and SIT approaches to design, we present our viewpoint. This presentation concerns the evolving nature of representations regarding levels of abstraction and degrees of precision, the function of external representations, and specific qualities of representation in collective design. Designing is described at three levels: the organisation of the activity, its strategies, and its design-representation construction activities (different ways to generate, transform, and evaluate representations). Even if we adopt a “generic design ” stance, we claim that design can take different forms depending on the nature of the artefact, and we propose some candidates for dimensions that allow a distinction to be made between these forms of design. We discuss the potential specificity of HCI design, and the lack

The literature on expertise is wide-ranging, both across many domains and within software development, however when findings from these are contrasted with literature on experience in pair programming, some startling differences become apparent. For example, knowledge seems to be a key feature in obtaining expertise, however there is little mention of core programming knowledge as a measure of expertise in the pair programming literature. This paper discusses these discrepancies, along with findings on the reliability of various types of rating, to provide context for the presentation of data from a survey of commercial pair programmers which aims to help clarify what factors are considered good indicators of pair programming expertise by different groups.

We present a new visual programming language and environment that serves as a form of feedback and representation in a Programming by Demonstration system. The language differs from existing visual languages because it explicitly represents data objects and implicitly represents operations by changes in data objects. The system was designed to provide non-programmers with programming support for common, repetitive tasks and incorporates some principles of cognition to assist these users in learning to use it. With this in mind, we analyze the language and its editor along cognitive dimensions. The assessment provides insight into both strengths and weaknesses of the system, suggesting a number of design changes. This work supported by the National Science Foundation under grant number IRI-9020089. Additional support provided by the Hertz Foundation and the AAUW. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing t...

This document can be downloaded via links at

The paper presents a cognitive analysis of design as a problem-solving activity. Design is characterized through results from empirical studies of various design tasks. Based on this characterization, it will be argued why and how knowledge modeling can be considered as a design task. Knowledge modeling has been qualified as the "construction of a set of successive representations". Processing different types of representations at different levels and from different viewpoints plays an important role in design problem solving. It will be argued that other characteristics of design may also apply to knowledge modeling. As there are not yet data available on the cognitive activities involved in knowledge modeling, hypotheses for studying these activities may be inspired by what is known about design: design problems have no pre-existing, complete problem definition, and no unique, correct solution; the design activity does not follow a pre-existing plan, it is opportunistically organized.