Understanding Connections in the Social System Mapping Context

The Connections Page of the Member View represents the key functionality of sumApp, enabling network members to show their relationships on the map in Kumu, and to keep the map as up-to-date as possible with as little effort as possible – while at the same time, structuring the resultant data-set in a way that works seamlessly with Kumu or other network graph tools.

But since everything in a network is connected to everything else and network graphs can be applied to just about everything, the relationship between how sumApp gathers connection information and how it ends up visualized in Kumu can be confusing.

I find it useful to distinguish between two different ways of understanding ‘connection’:

• One way of understanding connections is as known, self-reported relationships from one person (or organization) to another. One of our master mappers refers to these as ‘validated’ connections, where people say directly who they know and how well. The member is the authority about that connection.
• The other is what I call ‘discoverable’ or potential connections. If you and I live on the same block, or work for the same company, or are committed to the same issue – that’s often treated as a ‘connection’. But we may or may not actually know one another, so in terms of actually interacting it’s a potential connection, not a known and verifiable connection.

Both of these connection types are important for our mapping purposes, but it helps to realize that they are derived from the data differently.

The first type – ‘validated’ connections, are defined by the members, using the pop-up member tiles on the connections page. The options they’re able to choose from are defined by you, the map-maker, your ‘visionary’ partner if you have one and the pilot group if one exists. Those options are set up in define connection options.

The second type comes from commonalities identified in the survey. For instance, you can use the cluster function of Kumu to cluster on a list-type survey field. Clustering will turn the option list items into separate nodes and then show everyone who chose a certain response linked to that option. See the clusters in the Human Systems Dynamics map in the image below. The blue rectangles on in this view were generated from a question in the sumApp survey, asking about the member’s most-used HSD Methods and Models. The green circles are network members, and the blue lines show who selected the method ‘Decision Map’ from the options listed.

If you intend to draw out commonalities using the survey, you need to use standardized or list-like options. It can be tempting to just add an open text field to ask for the state members live in, for example. But that usually turns into a mess, when some people spell the state out (e.g. Minnesota) and others abbreviate it (MN), and still others mis-spell it. You’ll end up with a node per spelling variant, with different people attached to each.