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.).

A programming system is the user interface between the programmer and the computer. Programming is a notoriously difficult activity, and some of this difficulty can be attributed to the user interface as opposed to other factors. Historically, the designs of programming languages and tools have not emphasized usability. This paper describes the process we used to design HANDS, a new programming system for children that focuses on usability, where HCI knowledge, principles, and methods guided all design decisions. The features of HANDS are presented along with their motivations from prior empirical research on programmers and new studies conducted by the authors. HANDS is an event-based language that features a concrete model for computation, provides operators that match the

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

Little is known about how developers think about design during code modification tasks or how experienced developers ’ design knowledge helps them work more effectively. We performed a lab study in which thirteen developers worked for 3 hours understanding the design of a 54 KLOC open source application. Participants had from 0 to 10.5 years of industry experience and were grouped into three “experts ” and ten “novices. ” We observed that participants spent their time seeking, learning, critiquing, explaining, proposing, and implementing facts about the code such as “getFold-Level has effects”. These facts served numerous roles, such as suggesting changes, constraining changes, and predicting the amount of additional investigation necessary to make a change. Differences between experts and novices included that the experts explained the root cause of the design problem and made changes to address it, while novice changes addressed only the symptoms. Experts did not read more methods but also did not visit some methods novices wasted time understanding. Experts talked about code in terms of abstractions such as “caching ” while novices more often described code statement by statement. Experts were able to implement a change faster than novices. Experts perceived problems novices did not and were able to explain facts novices could not. These findings have interesting implications for future tools.

Software visualization is nifty stuff; but is it the powerful cognitive tool it is often assumed to be? This chapter attempts to moderate the understandable enthusiasm for software visualization and to raise some of the questions for which the discipline doesn't yet have answers. The chapter is structured as a list of questions with discussion. The questions are not a comprehensive analysis of cognitive challenges in software visualization. Rather, the chapter attempts to provide a list sufficiently provocative to give designers pause, in order: (a) to establish that good software visualization isn't simply a matter of mimicking paper-based tasks or doing what is technically easy---and certainly isn't `solved' yet; but also (b) even simple tools can improve software comprehension, if they're the right ones.

Introduction 2 | MULHOLLAND AND EISENSTADT programming, as opposed to the "design" and "planning" sides. We realised eventually that the debugging/maintenance needs of experts were fundamentally the same as the pedagogical needs of our novices: both needed to see in a perspicuous fashion what was happening during program execution, though at different levels of granularity. This resulted in a shift in our emphasis from automated debugging assistants to software visualization. To justify this shift, let's consider the evolution of our view in detail. In 1976, we faced the challenge of teaching programming in very adverse circumstances: we wanted to teach AI programming to Psychology students at the UK's Open University. Our students were (a) computer-illiterate or computer-phobic, (b) working at home with no computer hardware, and therefore having to attend a local study centre to use a dial-up teletype link to a DEC system-20, (c) studying Psychology with no intention

Keywords: POP-I.B barriers to programming, POP-II.A. novice programmers, POP-III.C all cognitive dimensions, POP-III.B new language. Research in Psychology of Programming (PoP) and related fields over the past thirty years has identified many important usability issues for programming languages and tools. However, when new programming languages are designed these findings do not seem to have much impact, so popular modern languages continue to exhibit many of the same old problems. This paper reviews the progress of an ongoing project to elevate the influence of PoP on the design of a new programming language. In the context of designing a new programming language for children, we cataloged and interpreted the prior work, performed new studies where questions remained unanswered, and have focused on usability throughout the design. In addition to producing a system that is easier to learn and use than existing systems, we hope to exemplify a process that could be adopted by other language designers to improve the usability of their systems.

Abstract Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers understand software, as well as the tools that are used to assist in comprehension tasks. In this paper, I review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I then explore how tools that are commonly used today have evolved to support program comprehension. Specifically, I discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools are distinguished according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tool development and research methods.

Expert programming involves the manipulation of large amounts of memory, including external memory represented on a display, semantic memory for expert knowledge, and episodic memory about what has transpired during a particular programming session. We present a computational cognitive model that emulates several minutes of expert, naturalistic programming behavior. The model has three high-level components: knowledge, an underlying cognitive architecture, and mechanisms that allow the architecture to manipulate the knowledge. To illustrate these components we trace the model on two related episodes of behavior. In the first episode, the programmer acquires information from the display. Then, in the second episode, she recalls something and scrolls through previous screens until she reaches the display from the first episode. Emulating this behavior requires the interaction of external, expert, and episodic knowledge, the encoding of episodic knowledge as carried out by the architecture, and mechanisms for selecting goals, attending to the display, and probing long-term memory.

Cognitive models of software comprehension are potential sources of theoretical knowledge for tool designers. Although their use in analysis of existing tools is fairly wellestablished, the literature has shown only limited use of such models for directly developing design ideas. This paper suggests a way of utilizing existing cognitive models of software comprehension to generate design goals and suggest design strategies early in the development cycle. A crucial part of our method is a scheme for explaining the value of tool features by describing the mechanisms that are presumed to underly the expected improvements in task performance.