The capture problem is the specter haunting all DR efforts (indeed, all knowledge management efforts attempting to meaningfully capture elements of human reasoning and discourse). How does one acquire quality input to a rationale management system, without disrupting the very process it is designed to support, or without having to employ dedicated scribes who do nothing but maintain rationale libraries?
The cost–benefit tradeoff is a slippery tightrope to walk, and has focused our energies on a “value now, value later” imperative. As Grudin [13] has pointed out, there cannot be a disparity between who invests effort in a groupware system, and who benefits. No designer can be expected to altruistically enter quality DR solely for the possible benefit of a possibly unknown person at an unknown point in the future for an unknown task. There must be immediate value. The difficulty, of course, is that it is not merely a “capture” problem, but “useful capture”. One could minimize the capture effort and simply video record every design meeting, but this would not render a useful archive. Computationally tractable structure must be added by some means. Extracting useful content automatically from multimedia meeting records is an active research area, but very challenging. Later, we will report on the synergy of combining the richness of video-based DR with argumentation-oriented approaches, but let us first focus on the specific capture problem associated with the latter.
Very soon after “idea processing” visual hypertext systems such as NoteCards [14] and ibis [10] began to be used for structuring ideas, re-ports began to emerge of “cognitive overhead”. A 1994 survey [3] found comparatively weak evidence regarding usability and utility compared to what might have been expected given the scale of system development efforts. A later survey echoed this, highlighting the pattern of failure in many kinds of interactive systems that assume the willingness of users to structure information [30]. The ray of hope that somehow we might find just the right balance of intuitive user interface, natural representation scheme, and fast computers began to dim, and many researchers moved on to other challenges.
Nonetheless, encouraged by the limited success of the ibis prototype in an industrial case study [11] that the problems stated earlier were surmountable, the early 1990s saw the launch by Conklin and colleagues of a commercial software tool that combined graphical hypertext, IBIS and groupware capabilities. The QuestMap Windows single user and group-ware product made a mark in the hypertext and groupware communities, and even resulted in a few isolated cases of extended industrial-strength use [8]. However, this product ultimately succumbed to market pressures, and is no longer available. Much was learnt from this episode, in particular an appreciation of the value that can be added in design meetings once people have learnt the meta-cognitive skills of using IBIS, some of whom may then appreciate quality software support to overcome the limits of mapping on paper, whiteboards, or a generic drawing tool. Let us consider the nature of this skill in more detail.
