Scott Klemmer, a graduate student at the Institute of Design at UC Berkeley emailed me last week to talk about API usability. He sent me a link to a paper he and his team had recently presented at this year's CHI conference (annual conference on all things related to UI design and human computer interaction).

The paper describes how the team designed and built an API for developers building Tangible User Interfaces (TUIs). TUIs are interfaces that accept input from the user via physical artefacts, such as the presence of an object on a desk. Developers building such interfaces spend a large portion of their development time on building the application infrastructure to receive and process input events. Scott's group designed an API that provides such an infrastructure, allowing developers to focus on their application needs rather than the infrastructure.

The paper describes how Scott's team used field visits and interviews to gather requirements for the API. They interviewed different developers who had experience of building appplications with a TUI to discover what problems they had encountered. On top of this, they took copies of the code that the developers had written. The group then spent time analysing the code to look for common design patterns. Having identified these patterns, they then designed the API such that these patterns would be supported.

This approach seemed to work well in this case. I'd be interested in learning if there is anyone else out there that has used similar techniques and would be willing to share their experiences. But, what I'd really like to know is, if Microsoft tried to adopt this technique for any new API that we are designing, how willing would you be to let us see your code?