A short and easy to read paper this morning picking up on the Debugging Reinvented theme of challenging the tools we use everyday.
Error notifications and their resolutions, as presented by modern IDEs, are still cryptic and confusing to developers.
Can we do any better? And if so, how would you go about improving error messages in a principled manner?
Barik et al. address this by first thinking about an interaction framework describing the interaction between a developer and a compiler/IDE, and then looking at two key stages in that interaction: the presentation of the error itself, and the way that the developer articulates what they intend to do to fix the error. For each of these two stages, they introduce a taxonomy that helps give structure to the problem.
We have conducted preliminary research on the first (presentation of error messages) taxonomy by randomly sampling and categorising roughly 40% of the 500 possible OpenJDK compiler error notifications. The notifications are categorized based on information needed for developer comprehension.
The notification taxonomy on its own doesn’t seem particularly exciting: you’ll find entries such as ‘clash’, ‘bad practice’, ‘improper name’ and so on. Where the potential starts to become more apparent is when notification types are connected with the articulation (resolution) taxonomy.
Five example resolution actions are given in this second taxonomy. For example, ‘ChooseOneOf(X,Y,…)’ for selecting between incompatible alternatives. Connect the notification error type with a resolution action and populate the alternatives and you start to see how an IDE could make use of this to better assist the developer. See the paper for some screenshots of this idea in action.
The taxonomies give consistent and unified semantics to error objects, which in turn allows IDE developers to easily add presentation and articulation features to their tools. More importantly , the taxonomies allow IDE developers to also design presentation and articulation of notifications in a consistent and unified way.
Stepping back a little, lots of our tools, frameworks, systems and applications produce notifications intending to alert some user of a situation that may need addressing. Often we craft these messages on a case-by-case basis with little thought to an overall scheme, and not enough attention paid to articulating the possible resolution actions and assisting the notification recipient in selecting one of them. The bigger message of this paper for me is that we can improve ease of use by carefully considering these taxonomies as part of the overall design.