In his recently-posted review of Dreaming in Code, by Scott Rosenberg, Joel Spolsky writes:
The way you make users understand your program model is with metaphors. When you make things look, feel, and most importantly, behave like things in the real world, users are more likely to figure out how to use the program, and the app will be easier to use.
Rationale is riddled with metaphors. Many we’ve just adopted because they are the standard currency for applications of this type. The metaphors are not even all consistent with each other, but because they are generally accepted and occur in distinct contexts, this doesn’t matter too much.
The dominant metaphor, one that’s highly visible even though it is not “in your face”, is the notion of a block. Rationale (like Reason!Able before it) helps people deal with abstract notions like argumentation through the metaphor of building blocks in the kindergarten. It is saying, in effect: think of a complex argument as like a pile of blocks. Each claim in the argument is a block. Blocks lower down in the pile support blocks higher in the pile. There’s one block sitting at the very top. There are green blocks and red blocks, and in fact these are themselves made up of blocks (analysis mode). Blocks can be moved around, and they basically stay where they’re put, except when they are pushed aside by other blocks (auto-layout).
Building blocks are very basic as metaphors – more basic than, say, files and folders (within folders within…). We think that our use of the blocks metaphor is part of why Rationale is so easy to use. (Another part is that our team includes people who obsess about making things easy to use.) But in adopting the blocks metaphor, we weren’t trying to make Rationale easy to use. Rather, our intent was to make arguments easy to use, so to speak. We were trying to make complex reasoning and argumentation easier to understand, and the corresponding skills easier to master.
So metaphors can play at least two different kinds of roles in software, and sometimes they will play both roles simultaneously. They can help users figure out how to use the software, and they can help users figure out the domain. It may be especially true that the dominant metaphors are simultaneously playing both roles in software, like Rationale, which has as a primary purpose helping people understand the domain, as opposed to software which assumes people understand the domain and just want to help people do work in that domain.
Tim van Gelder 
Hi Tim,
Too bad I missed the New York Conference :(
Your comments overlap nicely with the world of object oriented design and programming at the purely conceptual stage of technical product development. Smalltalk, the first truly object oriented language, was invented precisely so that abstract code would be a better reflection of things in the real world. The Unified Modelling Language (ULM) was invented so that programmers and domain experts could carry on a graphical digalogue that would act as a clear interface between stakeholders with pure domain expertise, and those charged with implementing the software.
After 10 years of using the UML in my own work, for me it’s been a failure. There are simply too many metaphors, with 7 types of diagrams. In other words, too many metaphors. having just taking the new Rationale for a test drive, your team obviously recognizes the need for simplicity, yet offering many tools to support an otherwise very simple visual dialect. Yet there are some interesting ideas in the UML that could be used to map a human dialogue or domain knowledge set, IMO.
In the software world, I’m not alone in abondoning the UML for the “Agile Modelling” type approach proposed by Scott W. Ambler. A piece of paper, a pencil, and a scanner is really all you need to model and share even the most complex software. And what we draw when we design object oriented systems looks a lot an argument map, with a few other methaphors thrown in that are software specific….well, not really, but more about that later ;)
When I came back to your site recently I recalled having read this post and having the distinct sense of having forgotten something seminal … as though a primary source that was salient.
Quite coincidentally today, while doing house-cleaning on my own blog, I came across material in Dan Bricklin’s blog that steered me on the right course; I had been recalling Dan’s 2001 “Metaphors, Not Conversations”.