Andrew J. Ko ajko @ uw . edu

I'm an assistant professor at the Information School at the University of Washington. I am also a core member of the dub group, our cross-campus human-computer interaction research and education coalition.

As a researcher and teacher, I'm fascinated by software. I'm intrigued with how it's built, the people who build it, and its far reaching effects on society. I study beginners, end-user programmers, and professionals with lab studies, classroom, corporate field work, and artifact analysis. I use the results to invent tools that better support the design, creation and repair of usable and useful software.

I'm interested in ...

Usability 2.0. How can 1,000,000 users communicate problems to 100 designers in a mutually beneficial way? Tech support isn't the answer and user testing doesn't scale. We're inventing help tools that incentivize user feedback at a massive scale, and creating tools that aggregate and visualize this feedback to support design and bug triage decisions.

User feedback in open source. Most OSS projects are driven by a small core of active contributors and a much larger group of less frequent contributors. We're studying the value that this latter group brings and investigating ways to increase it.

Playing with code. Too many programming languages, even those designed for beginners, make code sterile, cryptic, and fragile. We're making code something that people can play with, exploring tools and languages that help people explore and ideate in the medium of code.

My older work, which focuses on a range of human issues in software development, appears below.

recent projects

The Whyline for Java lets you point to program output and ask a 'why' question, then get an explanation than pinpoints the answer.

Information Needs in Co-located Software Development Teams. What kinds of information do software developers look for on a minute-by-minute basis? Rob DeLine (MSR) and I spent a summer hanging out in software developers' offices and took extensive notes on the information they were looking for. They spend a lot of time staying aware of their teammates' activities as well as seeking design rationale (but never finding).

Tools

These are technologies that I'm no longer actively working on. If something here seems interesting, however, drop me a line. I'm always open to new perspectives on past work.

Crystal. Ever wonder why your software is doing something strange? Crystal is an automatic, contextual help tool that lets you click on confusing output and ask 'why' questions.

Barista is a toolkit for creating flexible structured code editors. The key different between Barista editors and prior structured editors is that they use standard text editing interaction techniques, but a structured visual representation.

Jasper is a workspace for gathering task-relevant code during software maintenance tasks. Its motivated by findings from one of my studies that showed that most of what developers do during such tasks is navigate between relevant code.

Slate is a spreadsheet language with a novel labeling system. Users give labels to data and the data is propagated through formulas, causing unexpected combinations of labels in the presence of errors.

Citrus is a novel programming language that supports one way constraints, events, value restrictions, and object ownership. I used Citrus to implement the Barista toolkit above and lots of other prototype user interfaces.

The Whyline for Alice is a debugging tool that allows developers to ask why and why not questions about their program's output. The prototype that I wrote for Alice helped developers solve problems 8 times faster than normal tools.

Studies

The Linguistics of Problem Reports. Are there linguistic trends in people's descriptions of software problems? To find out, we analyzed nearly 200,000 open source bug reports, specifically studying their one-line summaries.

Bottlenecks in Software Maintenance Tasks. We studied several expert Java programmers using Eclipse to fix bugs and add features to a painting application. The study identified several trends in these activities, including that developer's spent an average of 35% of their time scrolling within files and switching between files, to code they had already seen but needed to reference again. If you're curious, you can view the source code for the Paint application used in the study.

Text Editing Strategies in Code Editors. How do programmers edit textual code (as opposed to visual or otherwise)? We did a fine grained analysis of several programmers character-by-character edits, finding that programmers generally preserve the syntactic integrity of their code. Almost all edits, however, require them to pass through some syntactically invalid state momentarily.

Learning Barriers in Visual Basic.NET We studied a classroom full of non-programmers attempting to learn Visual Basic.NET and found that, while many barriers were difficulty with syntax errors, many others had to do with searching for, using, coordinating, and debugging uses of abstractions in APIs. We identified many ways that programming environments might lower or remove these barriers.

What causes people to insert errors in code? Traditional perspectives blame the programmers or the languages. We observed and documented groups developing interactive 3D simulations, the errors introduced into their code, and their efforts to find and repair these errors. About half of the errors introduced occurred as a result of efforts to repair other errors that were based on these false assumptions.