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.