Usability for programmers: dissertation kickoff
Another two months to go and I will have finished all of the taught modules for my master's degree in HCI. Next up — the dissertation. All I need is a topic.
Putting such claims under scrutiny and conducting a more general study of what makes the difference between a user-friendly error message and one that is frustrating would certainly have been interesting. But looking into it further, the common ground that error messages share with linguistics on the one hand and HCI on the other is too far-fetched to justify.
Luckily, the idea led to a whole new area of potentially impactful research –
usability for programmers. This, I think, has an almost romantic ring to
it. If UX is all about putting the layman front and centre when designing
technology, then what of the neglected developer, deciphering compiler errors,
trying to make sense of
git rebase, and battling the RSI that gets worse
every time they must reach the tiny ESC key with their pinky because Caps Lock
is already remapped to Ctrl to make Emacs keybindings more ergonomic…
As it turns out, the programmer is not as neglected as one might think. An initial search for “debugging strategies user study” led to a range of specialised research from copy & paste practices to facilitating feature location in large codebases, accessible directoy structuring, automated debugging tools, as well as more social issues such as code ownership and managing implicit knowledge.
I have narrowed the choice down to four areas:
- Causes behind copy & paste errors, and tool design to prevent them
- A review of debugging strategies: from fault identification to correction
- Visualising git repositories to facilitate comprehension of version control
- Feature location in large/unfamiliar codebases
One of these will become my breakfast, lunch and dinner for the better half of the following year!
A note on methodology
In the area of programming HCI, it is not only the research itself that can make a contribution to the field: adapting research methods to match developer working habits and evaluating their use has potential value, too. Ethnographic studies may have their roots in the African bush where missionaries and anthropologists dutifully noted down cultural peculiarities, but they have been relatively successfully adapted to fit user research in HCI. But where the user is a programmer, many of the best practices for conducting usability studies may well blow up in your face. For example, how do we interpret eye-tracking data when a developer is scanning code? Is it even significant? What about qualitative data from a think-aloud session with a solo programmer? Will the nature of a think-aloud study not transform the session into what is essentially pair programming? And don't even get me started on diary studies… Whatever the eventual topic, it'll be a fun challenge coming up with the methodology.
About Elise Hein
I’m a design system engineer at Griffin. Previously, I helped build products for healthcare research at Ctrl Group, worked on personal digital branding at MOO, and researched development practices at UCL for my master’s degree in HCI.