Early in this term, in my Masters class in Criminal Justice, a student talked about a generalization of a juror. I quickly created this argument map to explain one perspective of the nature of an argument so that we could first share the same argument terminology and, more importantly, the same metaphor of an argument.

juror8.jpeg
Now all the students in the class can more accurately conceptualize the nature of an argument and dialogue about it with concrete terms:

  • “reaching the conclusion,”
  • “inference steps,”
  • “essential supporting conditions,”
  • “the probative strength of the (stepping stone) premises,”
  • “leading the judge to their conclusion,”
  • “not following their reasoning,”
  • “where does their reasoning end,”
  • “not losing the jury,”
  • “a weak argument,”
  • “a premise being irrelevant because it either does not lead to the conclusion or it does not support a premise that does lead to a conclusion,”
  • “too big an inference leap, etc.”

Even if I never draw another map again this term, this one inference path map keeps the students and I in the same territory (i.e., domain).

The lack of a sufficiently strong isomorphic connection to arguments in Rationale™ pyramid or other more abstract argument visual languages was one of my main frustrations with using them.

THE HUMAN MIND SEEMS TO HAVE LITTLE TOLERANCE for the unknown. As a result, it shows a natural tendency to interpret the mysterious [arguments] within the referential frame of the familiar. The mind attempts to understand the unknown based on the known, and the new based on the old. In order to accomplish this, it resorts to metaphorical and isomorphic analogies. http://www.pep-web.org/document.php?id=APA.030.0509A.

If the teacher does not provide a functional and memorable analogy, the students will attempt to come up with one of their own. And if it is not sufficiently isomorphic, they will get lost.

Rationale™ pyramid visual language certainly uses a metaphor. As Dr. Tim van Gelder states:

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.

Correctly understanding the domain of argument is crucial. The more isomorphic the metaphor, the better that understanding will be.