Looking at the design and benefits of X10.

In 2002 DARPA (Defense Advanced Research Projects Agency) launched a major initiative in HPCS (high-productivity computing systems). The program was motivated by the belief that the utilization of the coming generation of parallel machines was gated by the difficulty of writing, debugging, tuning, and maintaining software at peta scale.

Low-end mobile phones are becoming generally available throughout the world and the main window onto the Web. A large constituency for Web access is being created whose experience Web designers are not familiar with, particularly because of the central role of auditory, rather than visual access. This is analogous to problems faced by visually impaired users, where again Web designers have an audience whose experience they rarely share. One might think that proven design practices of working directly with users or intermediaries would be effective, but we argue that in these situations they are difficult to apply, not least because of the distance geographically and culturally from the users. We therefore present alternative ways for developers to gain insight into the experience of auditory access. We also discuss the potential of tools and resources such as simulations of an auditory interaction with the Web and illustrate how these can help --- particularly with early stage design. Successful simulations can reduce the cost and effort needed to design a usable auditory Web experience, and as a bonus, the insights gained often improve a site for many other users as well.

Using evidence from a survey of 49 IBM Web developers we explore two concerns: barriers to the developers' designing accessible Web-based products, and what value they felt specific features in an "accessibility" tool might have. They found designing for accessibility difficult, but more surprisingly, they found using the test tools and finding technology work-arounds equally hard. Testing and finding work-arounds were also the most time consuming aspects of accessibility, while design was not. When asked about tool features, all agreed that a checklist of automatically detected problems and an explanation of each problem were the most important. There were fifteen features in all, and the more experienced the developer, the more they valued the other features, particularly being able to experience a site as someone with a particular disability would, and being able to pinpoint a problem on the rendered view of a page. The survey results suggest existing tools are often unclear, cumbersome, and incomplete with respect to the standards that must be met.

Human performance models based on information foraging theory have proved capable of predicting navigation behavior on the Web. They can therefore provide a useful tool for Web site design. They may also be effective for modeling auditory navigation within a single Web page. Designers often struggle to accommodate this sort of access, different as it is from their own experience. As a step toward realistic simulations based on models of auditory Web access, we describe information seeking strategies observed in people with visual impairment using screen reading software for Web navigation tasks. We outline one example strategy for approaching a new Web page that, guided by information foraging theory, may expose access barriers that current design tools miss.

Designers often have no access to individuals who use screen reading software, and may have little understanding of how their design choices impact these users. We explore here whether cog-nitive models of auditory interaction could provide insight into screen reader usability. By comparing human data with a tool-generated model of a practiced task performed using a screen reader, we identify several requirements for such models and tools. Most important is the need to represent parallel execution of hearing with thinking and acting. Rules for placement of cogni-tive operators that were developed for visual user interfaces may not be applicable in the auditory domain. Other mismatches be-tween the data and the model were attributed to the extremely fast listening rate and differences between the typing patterns of screen reader usage and the model's assumptions. This work in-forms the development of more accurate models of auditory inter-action. Tools incorporating such models could help designers create user interfaces that are well tuned for screen reader users, without the need for modeling expertise.

UI designers use a variety of prototyping tools, from paper and pencil sketching, to drag-and-drop mock-up tools (e.g., Balsamiq Mockups), to sophisticated suites of modeling tools and toolkits (e.g., iRise or dijit, the dojo GUI toolkit ). Many projects would benefit from quickly analyzing prototypes at an early stage without the effort of bringing in users for empirical tests. Most analysis tools, however (e.g., AutoCWW [1], Bloodhound [2], and CogTool [4]), require prototypes to be in their own format, which forces the designer to re-do the prototypes in order to analyze them. Our work is a step toward allowing the CogTool analysis tools to import from many different prototyping tools, so designers will have a path to quick usability analysis without changing the way they currently express their preliminary designs.

This paper presents the motivation, design rationale and implementation detail of a study of programmer behavior in scientific computing circa 2002. We discuss the constraints of creating a retrospective baseline—the methods used, the necessary conditions—and what we have learned. We examine the problems of doing such a study and the difficulties of ecological validity in a partly controlled setting.

In this paper, we motivate and position a method for measuring the complexity of programming-related tasks. We describe this method, Complexity Metrics (CM), and give a brief worked example from the domain of High Performance Computing (HPC). We are using the method to help determine the productivity impact of new tools being developed for HPC by IBM. Although we argue that the CM method has certain virtues, we acknowledge that it is a work in progress. We discuss our strategy of complementing the CM method with knowledge we derive from applying other methods to better explore the complex issue of productivity. We end the paper with a discussion of some of the open issues associated with the CM method and plans for future work.

This paper reviews several techniques we have discovered while trying to extend the Firefox browser to support people with visual, motor, reading, and cognitive disabilities. Our goal throughout has been to find ways to make on-the-fly transformations of Web content including adjustments of text and image size, text style, line and letter spacing, text foreground color, text background color, page background removal, content linearization, and reading text aloud. In this paper, we focus primarily on the changes we make to the browser's Document Object Model (DOM) to transform Web content. We review the kinds of approaches we have used to make DOM modifications sufficiently fast and error free. We highlight the problems posed by Web pages with a mix of static and dynamic content generated by client-side scripts and by Web pages that use both fixed and relative placement of page elements, pages of the sort we expect to see in increasingly in the future.

A design story about the design of a visualization for controllers who monitor IBM's controls process, provides the backdrop for reflections on the success of a participatory design process. The story illustrates that while the design process appears to lead to a successful general technical solution, the solution fairs less well when viewed from the perspectives of: support for evolving work practices, or support for the particular and contextual tasks of individuals. This leads us to reframe our participatory design process as the design and socialization of end-user programming tools.