I direct the USE research group, which studies people's interactions with code. We build better developer tools, we study software teams, we design better ways to learn to code, and we invent new ways to help people understand how software works. My interests span human-computer interaction, software engineering, and computing education. I'm always recruiting students at all levels to support this work.
Below you'll find current and past projects, sorted chronologically and tagged.
filter: show all
there's nothing left to show
What makes someone a great software engineer? [ICSE15
]. What combination of technical, tactical, and social skills make software engineers effective?
, VL/HCC 2014
]. Can a game teach programming and debugging skills and also be fun? We say yes. Our recent work has shown that personifying an interpreter in in a puzzle game context significantly increases engagement and learning. The game is live at helpgidget.org
] enables developers to easily record and replay browser interactions to arbitrary points of execution at exact level of granularity. Time-travel debugging has come to the web.
] helps you find software help in a single click. Querying by user interface selection is better than querying with text because people with similar problems choose similar things. We've deployed this to four web sites, including the UW Libraries.
] automatically extracts problem topics from support forums around the web, visualizing them over time to help identify new issues. See the demo
How do software teams use user feedback?
We've investigated beta testing [ICSE11
], post-deployment usability [CHI11
], open source bug reporting [CHI10
], and support requests [CHASE11
Why is programming difficult to learn?
These studies have investigated the role of programming environments[VL/HCC06
], mentorship [VL/HCC09
], and documentation [VL/HCC11
The state of the art in end-user software engineering
]. Reports on the past two decades of research on making end users' programs more reliable through software engineering techniques.
] lets you point to program output and ask 'why' and 'why not' questions, then get an explanation that pinpoints the answer. Dramatically reduces fault localization time. Prototyped for Java
] 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.
]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.
] 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.
] 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.