Concept maps and visualizing things

I've been advocating for the use of concept maps for years. I've even written papers about it. But I've also spent most of my time writing plain, linear text. Scholarly papers, courseware, grant applications - these are all the basics of academic communication, and they're all just strings of words. So it's been hard to practise what I preach.

Recently, though, something happened that really opened my eyes to the very significant benefits of diagrams in general and concept maps in particular. So significant was this experience, that I want to share it in the hope that I can help others who are also struggling with the confines of linear text.

I should preface this by saying that I am a visual thinker - I literally think in pictures and remember things by associating them with images. For instance, my son has a favourite dish at a local Chinese restaurant. I could never remember the name of the dish, until I wrote it down in a small notebook I always carry. Now I remember it easily by visualizing the page on which I wrote it. Indeed, I can actually see quite plainly where on that page I wrote the name of the dish, the colour of the ink I used, and that I wrote it in ALL CAPS.

Caveat lector: if you're not a visual thinker, what follows may not make much sense.

Diagrams Matter

I think diagrams are important tools for four reasons.

First, they are very dense representations of information. A picture can be worth much more than a thousand words, especially if it's the right picture. A one page diagram can contain the equivalent of many pages of text in very crisp, self-evident forms.

Second, diagrams are thinking tools. They create a feedback loop with your brain. You draw a diagram to get thoughts out of your head; by reviewing and studying the diagram, you can examine, improve, and validate your own thinking. It can be much easier to see your thoughts in a diagram than when they're buried in paragraphs of text.

Third, they are group collaboration tools. A collaboratively constructed map helps ensure that the entire team has an integrated and agreed to mental model of whatever the map represents. This helps the team really work together.

Fourth, they are communication tools. A well-constructed concept map can communicate very effectively to appropriate audiences, without drowning the reader in reams of linear text.

What's a Concept Map?

In case you're wondering, a concept map is a directed hypergraph that connects nodes (boxes) denoting concepts with directed labelled links (labelled arrows) denoting relationships between those nodes. In regular graphs, a link connects only two nodes. In directed graphs, links are arrows; that is, the relationships they denote distinguish between its two participants. A hypergraph is a graph in which a link can start (or end) at one node and end (or start) at many other nodes.

Since there are no real restrictions on the labels of node contents in concept maps, they can represent nearly anything. However, there are conventions - best practises, as it were - that can help one think rationally about maps. The basic distinction is between concepts and relationships. Concepts go in nodes; relationships go on arrows connecting them. Concepts are the things in which you're interested, and relationships are whatever connections between those things you think matter. One map can include many different kinds of relationships: causal relationships, temporal relationships, containment and aggregation relationships, classification or parent/child relationships, etc.

Also, one should be able to read two nodes and the link between them as a sentence, where the first node (where the link starts) is the subject of the sentence, the second node (to which the link points) is the object, and the label on the link is the verb. That one should be able to read sentences off a concept map suggests that they can be used as a form of knowledge representation, because each sentence represents a fact. This opens up all sorts of possibilities that go far beyond what I want to write about here. Those interested in finding out more about this can start by looking up ontologies and concept maps.

Concept maps are related to another, arguably more popular tool for organizing information visually: mind maps. The difference between them is that mind maps organize things strictly in a hierarchy, whereas concept maps create network graphs where any node can connect to any other node. I prefer concept maps because, in my experience, knowledge is best represented by a richly interconnected network; I find hierarchies to be a relatively poor oversimplification. However, mind maps can be very useful when designing text (an article, book, report, etc.) because their hierarchical structure mirrors the hierarchical structure of written documents (chapters made up of sections, which are made up of subsections, which are made up of paragraphs...).

Concept Mapping Saved My Courseware

In fall 2009, I taught a new design course to second year mechanical and industrial engineering students. As a first pass, I started with the general structure of my fourth year design course, then tweaked it to suit the second year students.

It became obvious by the end the semester, having taught the course all the way through once, that the material was not as appropriate as it could have been. So I set about rewriting the material to account for the problems I noticed. One of the key web pages in the revamped courseware is supposed to give an overview of engineering design and how it fits into the overall product development enterprise.

I'd been working on that page on and off for a few weeks but just couldn't get it right. It was only a few screens long, but it seemed jumbled and disorganized, a collection of random thoughts. You can see what it looked like here.

Then I thought: let's build a concept map of what I wanted to say, and let's let the map guide my writing of the actual page. So using that first web page as rough notes, I started building a concept map with my favourite tool for such things, CmapTools.

There are many applications for drawing concept maps. I prefer CmapTools because it is easy to use, true to the ideals of concept maps as set out by their inventor, Joseph Novak, and has a web server that lets me work on maps wherever I might be, supports collaborative map making, and automatically creates web versions of the actual maps for inclusion in web pages.

By the time I got through the first half-screen of notes from the web page, I had quite a sizable concept map. You can see that map here. I was very surprised to find that:

1. I'd formed the concept map in less than one hour, and
2. the concept map had much more in it than did that first half-screen of the web page.

That is, I was able to generate a useful, usable concept map in only a fraction of the time it had taken me to write a horrible text description of essentially the same thing. And the content of the map was much more extensive than the text on which it was based. Indeed, that one map easily represents a two-hour lecture.

I did spend a lot of time arranging things topologically and geometrically on the concept map, but that actually helped me organize the material, because the layout of the map informed how I thought about the material. The act of building the visualization actually helped me develop the content.

The Importance of Layout

Layout is very important when you're creating a diagrammatic visualization. I think this is not sufficiently emphasized in the literature on concept maps. I get my students to create lots of diagrams, and I find that layout is at least as important as content when it comes to making a clear and easily understandable diagram.

Here's an example. I once took part in a study of a design team in industry; in particular, we were interested in how the team members exchanged information. We asked each team member with which other team members they shared information, and whether that information drove the individuals' tasks or was provided as feedback. Our first pass, shown in Figure 1, was just to note the basic information flows without regard to layout. The nodes represent the members of the teams, and the arrows represent the direction of information flow. Since only one relationship is shown by the links, we didn't bother labelling them. Not surprisingly, we got very little from this diagram.

Figure 1: Initial version of a concept map of information flow between team members.

By the time we had carefully rearranged the layout (Figure 2), we got something very different and very meaningful. We noted that the team members in the small hierarchy to the lower left of Figure 2 got along quite well, whereas the members in the relatively mangled substructure in the middle of Figure 2 didn't get along well at all, especially since member E, being the only member not driven by any other team member, should have been but wasn't the team leader.

Figure 2: Same information as Figure 1; different layout.

Building Concept Maps

Anyways, back to the concept map about engineering design. I was so impressed with the speed and quality of the result, that I'm now convinced I need to base all my lecture notes on concept maps.

Now, it may well be that one reason that this map fell into place so quickly was that I'd spent so much time struggling with the text version. I do tend to work best in long periods of cognitive gestation (i.e. navel-gazing) punctuated by fits of frenetic and usually sleepless activity. Perhaps the time I spent working on the text version helped the problem settle snugly into the deeper parts of my brain where my unconscious mind could spend quality time sorting it out, and by the time I got to the concept map, I'd already worked it all out unconsciously. I honestly don't know.

But I am willing to entertain the notion that it was the concept map itself that did the trick, because that's just what concept maps are supposed to do.

What's also interesting is that I've developed my own method for building concept maps, that isn't quite the standard way of doing it. According to the literature, one should first enumerate as many concepts as possible, and then link them together, and finally go over the whole map to make sure everything is there that should be there.

Instead, I have found that working on specific regions of a map helps me think not only about the details of that region but also about the other regions of the map. That is, I tend to create a map by creating a concept, then creating other concepts that connect to the one, adding links as I go. Put another way, I focus on one conceptual area of a map at a time, rather than dealing with all concepts first and all relationships later. I also tend to alternate periods of adding concepts and links with periods during which I just rearrange the layout of the map. I find that playing with layout helps me discover relationships between concepts that I hadn't noticed before. It also helps me identify inconsistencies in my thinking. This in turn stimulates further episodes of concept and link generation.

I take this as a benefit of concept mapping and of CmapTools: the representation accommodates more than one method of construction, which means it's more likely to accommodate many different thinking styles.

My method is also consistent with a well-known design concept: that designers work in alternating periods of synthesis (in this case, building the map) and analysis (changing the layout and correcting mistakes). So one might characterize my approach to building concept maps as a designerly way to do it. Since designerly thinking is not common in the majority of the population, this method probably won't work for everyone, but it is an alternative to the "standard" way of building concept maps.

In any event, even though I'd always been impressed with concept maps, I'd never really had the kind of "A-ha!" moment that I had with them when I was struggling with my courseware.  If you're looking for a new way to organize your thoughts, you really should look at concept maps.