Electronic business card for Nielsen can be retrieved by sending any

This paper suggests a framework for understanding the roles that children can play in the technology design process, particularly in regards to designing technologies that support learning. Each role, user, tester, informant, and design partner has been defined based upon a review of the literature and my lab’s own research experiences. This discussion does not suggest that any one role is appropriate for all research or development needs. Instead, by understanding this framework the reader may be able to make more informed decisions about the design processes they choose to use with children in creating new technologies. This paper will present for each role a historical overview, research and development methods, as well as the strengths, challenges, and unique contributions associated with children in the design process.

We present a technique for evaluating the usability and e#ectiveness of ambient displays. Ambient displays are abstract and aesthetic peripheral displays portraying non-critical information on the periphery of a user's attention. Although many innovative displays have been published, little existing work has focused on their evaluation, in part because evaluation of ambient displays is di#cult and costly. We adapted a low-cost evaluation technique, heuristic evaluation, for use with ambient displays. With the help of ambient display designers, we defined a modified set of heuristics. We compared the performance of Nielsen's heuristics and our heuristics on two ambient displays. Evaluators using our heuristics found more, severe problems than evaluators using Nielsen's heuristics. Additionally, when using our heuristics, 3-5 evaluators were able to identify 40-60% of known usability issues. This implies that heuristic evaluation is an e#ective technique for identifying usability issues with ambient displays.

Computer professionals have a need for robust, easy-to-use usability evaluation methods (UEMs) to help them systematically improve the usability of computer artifacts. However, cognitive walkthrough (CW), heuristic evaluation (HE), and thinking- aloud study (TA)—3 of the most widely used UEMs—suffer from a substantial evaluator effect in that multiple evaluators evaluating the same interface with the same UEM detect markedly different sets of problems. Areview of 11 studies of these 3 UEMs reveals that the evaluator effect exists for both novice and experienced evaluators, for both cosmetic and severe problems, for both problem detection and severity assessment, and for evaluations of both simple and complex systems. The average agreement between any 2 evaluators who have evaluated the same system using the same UEM ranges from 5 % to 65%, and no 1 of the 3 UEMs is consistently better than the others. Although evaluator effects of this magnitude may not be surprising for a UEM as informal as HE, it is certainly notable that a substantial evaluator effect persists for evaluators who apply the strict procedure of CW or observe users thinking out loud. Hence, it is highly questionable to use a TA with 1 evaluator as an authoritative statement about what problems an interface contains. Generally, the application of the UEMs is characterized by (a) vague goal analyses leading to variability in the task scenarios, (b) vague evaluation procedures leading to anchoring, or (c) vague problem criteria leading to anything being accepted as a usability problem, or all of these. The simplest way of coping with the evaluator effect, which cannot be completely eliminated, is to involve multiple evaluators in usability evaluations. Morten Hertzum was supported by a grant from the Danish National Research Foundation. We thank Iain Connell for providing us with additional data from Connell and Hammond (1999), Hilary Johnson for access to the data set from Dutt, Johnson, and Johnson (1994), and Rolf Molich for making the data set from Molich et al. (1999) available on the Web

Field research methods are useful in the many aspects of Human-Computer Interaction research, including gathering user requirements, understanding and developing user models, and new product evaluation and iterative design. Due to increasingly short product realization cycles, there has been growing interest in more time efficient methods, including rapid prototyping and various usability inspection techniques. This paper will introduce "rapid ethnography, " which is a collection of field methods intended to provide a reasonable understanding of users and their activities given significant time pressures and limited time in the field. The core elements include limiting or constraining the research focus and scope, using key informants, capturing rich field data by using multiple observers and interactive observation techniques, and collaborative qualitative data analysis. A short case study illustrating the important characteristics of rapid ethnography will also be presented.

Researchers in Computer Supported Cooperative Work have recently developed discount evaluation methods for shared-workspace groupware. Most discount methods rely on some understanding of the context in which the groupware systems will be used, which means that evaluators need to model the tasks that groups will perform. However, existing task analysis schemes are not well suited to the needs of groupware evaluation: they either do not deal with collaboration issues, do not use an appropriate level of analysis for concrete assessment of usability in interfaces, or do not adequately represent the variability inherent in group work. To fill this gap, we have developed a new modeling technique called Collaboration Usability Analysis. CUA focuses on the teamwork that goes on in a group task rather than the taskwork. To enable closer links between the task representation and the groupware interface, CUA grounds each collaborative action in a set of group work primitives called the mechanics of collaboration. To represent the range of ways that a group task can be carried out, CUA allows variable paths through the execution of a task, and allows alternate paths and optional tasks to be modeled. CUA’s main contribution is to provide evaluators with a framework in which they can simulate the realistic use of a groupware system

Note that the text that appeared in printed journal contains very minor typographic and grammatical corrections that do not appear in this version. SpeechSkimmer:

Abstract Research into the cognitive aspects of programming originated in the study of professional programmers (whether experts or students). Even "end-user" programmers What is Programming? Goodell's excellent website devoted to end user programming Programming is in fact seldom defined in modern research publications. An earlier programming textbook from 1959 gives a typical formulation for that time: "This sequence [of basic operations] is called the program and the process of preparing it is called programming" [32, p. 4]. Programming is the "spadework" of finding a precise mathematical formulation and method of solution, possibly notated in a "convenient problem-oriented language" whose symbols are "more closely related to the mathematical problem to be solved". The major changes since this was written are a) that many computer users do not now consider themselves programmers (when Weinberg wrote his early monograph "The Psychology of Computer Programming" As programming applications have moved away from the mathematical domain typical of early computing, the nature of the basic operations, the symbols in programming languages, and the formulations or methods of solution have all evolved. An introductory chapter to the book "Psychology of Programming" Three definitional questions Who is a programmer? The lines of professional demarcation within the software development community have always been fluid as a result of changing programming tools. For example, the distinction between "analysts" and "programmers" blurred when 4GLs enabled programming at a level of abstraction that was comparable to the vocabulary of the analyst. Analysts thus became analyst/programmers in the 1980s, and were simply called programmers again by the 90s. The same trends occurred in other specialist jobs. Unit test engineers were initially programmers (who wrote test harnesses), then In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments, pp. 2-10. simple operators of regression test tools, then programmers again as the testing tools became programmable. Recent trends have been to increase the number of people who might do programming in the course of their work. Almost all major software applications include scripting or macro languages of some sort, usable to configure and customize the behaviour of the application. Most operating systems include scripting languages. One of the most widely used classes of software application, the spreadsheet, is itself a declarative programming language. Many people who are not professional programmers use spreadsheets to create large and complex applications, thus inheriting all the software engineering problems of specification, design, testing and maintenance. End-user development, end-user customization and enduser software engineering have all been proposed as terms expressing the challenges faced by users encountering these new tools. Some of those terms apparently deemphasise the sophistication of the programming required ("customization"), while others emphasise the fact that large and complex design projects are difficult whatever the tools used ("engineering"). Some of these differing emphases in terminology can seem more suited to software product marketing, rather than seriously contending that "customization" means no programming is involved. If a conventional programming language were used to carry out the same tasks, there would certainly be no doubt that these applications were conventional pieces of programming work. But the one aspect in which end-user programming tasks always differ from conventional programming tasks is precisely that the software tools used for development or customization have the potential to be so unlike conventional programming languages. Which of the following can unambiguously be categorised with respect to the boundary between programming languages and other forms of software: Scripting languages? Spreadsheets? Macro languages? Keyboard macros? Configuration files? Java programs? Javascript programs? Server Side Include macros? Cascading Style Sheets? HTML pages? Microsoft Word documents? From the perspective of a non-programmer or end-user, the distinctions between these technologies are not at all clear-cut. All of them are able to produce dynamically modified text documents, and several can potentially be used to create apparently identical results. Yet some of them are classified in professional contexts as being programming languages, and some are not, with the result that when carried out by an end user, some of them may be classified as end-user programming and some not, even though the user may feel that he or she is doing a single task in different ways. This ambiguity becomes acute when the programming is taking place in a context that is completely separate from the workplace. An end-user programmer at work is quite likely to realise that the things he or she are doing could have been achieved by a professional programmer working within the organization. Previous academic studies have emphasized the roles these end users play on the boundaries of professional programming activity within an organization In contrast, a domestic programmer is not usually described as a "power-user". There may still be good reasons why somebody would create a Word macro to save time on a lengthy task at home. We have proposed elsewhere a system suitable for enhancing domestic remote controls with programming abilities In order to avoid these inconsistencies, the first proposal of this paper is that all computer users ought to be regarded as potential programmers, whose tools differ only in their usability for that purpose. The social approval accorded to such skills may increase with time, but this is not a fundamental indicator of inherent cognitive challenge in the task. If it is possible to find interesting programming-like attributes in other kinds of computer use, programming research could be universal and inclusive in its scope, rather than restricted to the experience of "professional" programmers. The next section therefore considers a classification of programming languages that takes account of these user perspectives, rather than conventional definitions. What is a programming language? What aspect of programming languages makes them different to other kinds of computer usage? Consider some of the examples presented above. A web page generated by a Javascript script or Server Side Include macro, when seen in a browser, may appear indistinguishable from a web page written directly in HTML. The difference resulting from the script or macro is that a different viewer, or the same viewer at another place or time, will see a different web page. The author writing the page specifies these differences by adding control information (in the scripting or macro language) to be interpreted by the computer rather than by the viewer. These simple variations might be seen as conflicting with some ideals of modern design for usability. What the user sees when authoring the page is not necessarily what he or she gets when viewing it -a conflict with the ideal of WYSIWYG. What he or she is manipulating is not a concrete instance of the desired result, but an abstract notation defining required behavior in different circumstances -a conflict with the ideal of direct manipulation. Of course these departures from the "ideal" are not a bad thing -they are necessary in order to achieve the task. But the additional challenges to the user are typical of the challenges that distinguish programming activities from those activities that do allow direct manipulation and WYSIWYG. When we consider other examples given above, similar properties are apparent. The distinction between writing an HTML document and a Word document is that the HTML document may look different to different viewers (depending In Proceedings of the IEEE Symposia on Human-Centric Computing Languages and Environments, pp. 2-10. on the size and shape of the browser window, the browser version, platform, available fonts etc). A single decision by the author can thus have multiple consequences -different results each time the document is viewed in a different situation. Once again, this range of effects is produced in HTML by the use of an abstract notation to define required behavior in different circumstances (here, the markup language). As with the use of JavaScript, even the abstractions of HTML provide the opportunity for syntax errors, runtime errors, or bugs in the form of unintended or exceptional behaviors. The same is true even of a keyboard macro. Pressing a key when composing a regular document is a fairly direct manipulation -the character that was written on the key appears on the screen, and can be viewed and retained or deleted in a direct feedback process. But pressing a key when composing a keyboard macro has other effects beyond those that are directly visible. When the macro is executed again in a new context, the results will be different. The user must anticipate this, and use abstract commands rather than direct manipulation commands (e.g. using the "end of line" key rather than pressing the right arrow key until the cursor reaches the end of the line, which would fail with a bug the first time it was executed in a line with a different number of characters). All of these examples, although rather trivial by comparison to the challenges of large software projects, do share important characteristics of conventional programming. The user must: • Decide the intended result of executing the program (requirements); • Identify when it will be executed, and allow for variation in different circumstances (specification); • Choose from a set of technical features that may support this behaviour (design); • Enter abstract control commands as well as data (coding) and anticipate; and • Account for departures from the intended behavior (debugging). All of these things are intellectually challenging, and they increasingly arise in all aspects of computer use. Consider, for example, the definition of a document template, or even a paragraph style in a word processor. Even quite mundane user tasks can involve requirements gathering, specification, design, coding and debugging. In order to account for these experiences, the second proposal of this paper is that almost all major software applications could now be recognized as including programming languages. If this were the case, research into programming could focus on programming experiences independent of language, especially those which result when abstract notation replaces direct manipulation. What is programming activity? The word programming is often used in common speech to describe activities that might seem trivial by comparison to large-scale software application development. People do not in general say they are "programming" their Word document when defining a paragraph style. But many people do say (even on their resumes, I have found), that they have been "programming" in HTML. Furthermore, people say they are "programming" their VCR, their microwave oven, their car radio or their boiler controls. Is there any value in extending our attention to these common uses of the term when we do research into the cognitive demands of programming? If we consider the user experience of marginal programming technologies, as addressed in the previous section, we see that even these mundane activities share many of the same properties. They all have the basic character that the user is not directly manipulating observable things, but specifying behaviour to occur at some future time. In order to address these experiences, the third proposal of this paper is that when people say they are programming, we should not question whether this activity is genuine programming, but instead analyse their experience in order to understand the general nature of programming activity. Cognitive features of programming What are the cognitive implications of this broader domain of programming tasks? The common features of the various programming tools described so far are a) loss of the benefits of direct manipulation and b) introduction of notational elements to represent abstraction. It is possible to relate both of these to relevant topics in cognitive science. Loss of direct manipulation The cognitive benefits of direct manipulation arise partly from the fact that image-based representations mitigate the "frame problem" in cognitive science Such planning is only possible if the scope of effects of a given action can be constrained. In other words there must be a defined boundary beyond which the action will not have further effects. If there is no basis for setting such a boundary, any action may potentially have infinite consequences, and it will not be possible to place bounds on the planning algorithm. This is known as the frame problem. In direct manipulation systems, many constraints on causality are made directly available via the user's perception of the apparently physical situation. This is less true of linguistic representations, where there is no limit on the abstract expressive power of the representation system These considerations lead to the well-known cognitive benefits of direct manipulation In Proceedings of the IEEE Symposia on restoring the state of the representation to that before the action should restore the situation. In programming systems, none of these things is necessarily true. The situation in which the program is to be executed may not be available for inspection, because it may be in the future, or because the program may be applied to a greater range of data situations than are currently visible to the programmer. Where acting on a single situation is concrete (actions have visible effects in the current situation), programming is abstract (effects may occur in many different situations, not currently visible). Multiple effects of an action will be distributed either in space, in time or in both (if two events occur in the same place at the same time, they are the same event). In previous publications, we have described these fundamental non-direct manipulations of programming as "abstraction over time" and "abstraction over a class of situations" Use of notation The second universal characteristic of programming situations is that the program is represented using some notation. This is also a universal characteristic of abstract thought. According to one perspective in the philosophy of mind, concrete action is that in which there is a causal relation between the action and a perceivable state of the world Is there any kind of programming that does not use notation? It would be possible to do programming using representations not usually regarded as notational (e.g. by speaking to a computer, or drawing a picture of the required situation in the world), but these alternatives can be regarded for our purpose as impoverished notational systems. The cognitive benefits of various notational options have been analysed at length by Green with various collaborators in the Cognitive Dimensions of Notations framework Abstraction as a tool for complexity Tools for processing abstractions provide a further benefit beyond those of defining actions in the future, or in multiple situations where the actor need not be present. Conceptual abstractions can also be defined and combined in order to manage complexity. This results from a further confluence of the two primary characteristics of abstract action, indirect effects and notation use. In a simple programming activity such as programming a VCR, the user is defining some abstract behaviour which is not directly observable because it will take place in the future. This is done with the assistance of a simple notationperhaps a display of start time and channel identification. But the user manipulates this notation directly -there is no higher order mechanism by which the user can specify changes to the programme other than those defined directly with the VCR controls. In contrast to this very simple programming situation, more complex situations can be approached by defining changes to the notation itself, so that the user can extend the vocabulary with which he or she will then express required behaviour. An example of this in a domestic context is a sophisticated boiler control (such as those common in Central Europe) in which the user can define one or more modes of operation, then specify that a particular mode should operate at a particular time of day. This makes programming itself more efficient by allowing the user to refer to a new abstraction (the mode) rather than repeating all the notational elements defining time and temperature for every occasion on which that mode of operation is required. Abstraction use in which the user conceptualizes common features of complex behaviour, then formulates notational abstractions in which to express them, completes the range of generic programming behaviours for which we propose a common description of cognitive challenges. In the domain of professional programming, this type of abstraction use is still a very active topic of research. One way of answering the question "what is programming" from a computer science context (proposed by Tony Hoare A cognitive model for abstraction use

Arcball is an input technique for 3-D computer graphics, using a mouse to adjust the spatial orientation of an object. In Arcball, human factors and mathematical fundamentals come together exceptionally well. Arcball provides con-sistency between free and constrained rotations using any direction as an axis; consistent visual input and feedback; kinesthetic agreement between mouse motion and object rotation; and consistent interpretation of mouse position. Attention to mathematical detail facilitates the tasks of users and implementors. Users say that as a general-purpose rotation controller Arcball is easier to use than its nearest rival, the Virtual Sphere. It is also more powerful, and simpler to implement. Résumé Arcball est une interface utilisateur pour un système de visualisation 3D utilisant la souris pour orienter les objets dans l’espace. Dans Arcball, facteurs humains et concepts mathématiques se marient exceptionnellement bien. Arcball assure la consistence entre rotations libres et contraintes quelle que soit la direction de leur axe. Consistence entre l'entrée et la réponse; accord kinésique entre mouvements de la souris et rotations de l’objet; interprétation consistente des positions de la souris. Les utilisateurs affirment que le contrôleur universel de rotation Arcball est plus simple à utiliser que son concurent direct: «the Virtual Sphere». Il est aussi plus puissant et plus simple à implémenter. Key Words: object movement, view movement, mouse, user interface, interactive graphics, 3D graphics, rotation,

The current variety of alternative approaches to usability evaluation methods (UEMs) designed to assess and improve usability in software systems is offset by a general lack of understanding of the capabilities and limitations of each. Practitioners need to know which methods are more effective and in what ways and for what purposes. However, UEMs cannot be evaluated and compared reliably because of the lack of standard criteria for comparison. In this article, we present a practical discussion of factors, comparison criteria, and UEM performance measures useful in studies comparing UEMs. In demonstrating the importance of developing appropriate UEM evaluation criteria, we offer operational definitions and possible measures of UEM performance. We highlight specific challenges that researchers and practitioners face in comparing UEMs and provide a point of departure for further discussion and refinement of the principles and techniques used to approach UEM evaluation and comparison. 1.