The Monster Map: Part Two – Evolving Tools
This post is a continuation from Part One.
The May 2016 event was the third annual bushCONNECT and over the course of those years, the tools available for Network Mapping have improved tremendously – making a big difference in how relevant the maps are to people.
Year 1 – Got data? (LinkedIn Does)
If you want to map a network, you need some data. Data about the whatever the dots on the map represent & data about the connections between the dots. In other words – in the bushCON instance – we needed info about the people & info about who knew who.
We were able to take the info about the people from the registration form, because, in order to evaluate the event, the Bush people asked a lot of questions about attendees.
But – how to figure out who knew who? We didn’t have a good survey tool for asking that (among a group of over 1,000). We wouldn’t have been able to pre-populate it with attendee names even if we had, because we didn’t know who was coming until they registered, which happened over time. So we’d have needed to do the survey the week before the event, which wouldn’t give us time to do all the subsequent steps.
Plus no-one believed we’d get people to go through 1,000 names anyway.
We chose to hire a programmer to create a simple API to pull existing connections from a social network – LinkedIn seemed most relevant (as opposed to say, Face Book or Twitter).
Year 1 – The Viz Tool – Gephi
The first year, we used Gephi – a pretty good, fairly technical open-source desktop network analysis software program. Gephi was great for statisticians – it’s a very science-y tool with a lot of fascinating layout algorithms. The Gephi interface is a little daunting to the normal user, so for the purposes of sharing the map, we exported it into a minimally-interactive file that could be viewed through a browser. I wanted more, but most people had little experience with network maps and had no expectations for anything more than Gephi provided.
Year 1 – Tools Reflection
Those who had any interest in the map at all were satisfied with the mapping tool – in fact they thought it was pretty cool. I was the only one who found it inadequate.
That first year, most attendees were either disinterest or said things like – ‘it’s a cool tool, but this data isn’t very relevant’. The seeming randomness of the attendees didn’t help. bushCON wasn’t an intentional change network, so it was hard to get excited about it. One had to extrapolate the relevance to a smaller, more intentional network. It was more of an example of what could be possible than a useful map in its own right, though some people did use it to close some triangles and a few saw the potential it offered for supporting social change.
In addition to the challenge of abstracting an abstraction to another somewhat-abstract context, a lot of people also questioned the meaningfulness of using LinkedIn connections. There was no way to know if the connections shown by LinkedIn represented forgotten ships passing in the night or close partnerships. Plus, we have communities that don’t use LinkedIn at all, so the maps made them look far less connected than they really are. It all felt excessively techno-white-middle-class centric, which most people found problematic, if not offensive.
It was clear we needed a better way of gathering those connections, but apart from some very expensive ONA tools, we knew of nothing. And even those ONA tools wouldn’t have worked well with a group of over 1,000 people. Our project instigator Michael Bischoff suggested that Tim & I develop a better tool to gather more meaningful, self-reported connections. But at the time, I wasn’t convinced the idea was feasible. I couldn’t imagine how you could get 1,000+ people to go through a list of 1,000+ people, and rank their connection from 4 options, and I thought that any solution we might come up with would be too expensive for us to develop. LinkedIn seemed like the best we could do with a group of that size.
I concluded that a network map was a new visual language, and like any language, it would take repeated exposure before most people became interested. It still struck me as a valuable addition to the collective imagination, even if it didn’t have much immediate practical application.
Year 2 – New Viz Tool – Kumu | Same LinkedIn Data
The second year, we switched mapping tools to Kumu.io a brand-new online systems & network mapping platform. Kumu provided much of the functionality I was yearning for but couldn’t get in Gephi. Kumu enabled robust online interactivity & filtering of attendees by relevant demographics such as issues people were interested in working on, or states of residence. This online access could be shared with all attendees before & after the event, allowing them greater ability to understand their place in the network, find others to collaborate with & see triangles they should close. Kumu also showed the profile pictures downloaded from LinkedIn, which increased the sense of human connection, because you could now see & recognize people’s faces.
Between bushCON14 & bushCON15, Tim came up with same good design ideas for a tool like Michael suggested, but I thought it would cost too much to build. I still wasn’t convinced people would use it & I didn’t see a market for something as simple as we could afford to make. So in year 2, we re-used the LinkedIn API & registration sheets for gathering data.
Year 2 – Tools Reflection
Kumu was an all-around big ‘wow!!’ – even though we were pushing its capacity with our volume of data, so it moved excruciatingly slowly – and the functionality was nothing near what it is now. Still, it’s a lovely, interactive living-feeling platform that was unanimously admired by our visitors.
But people were still critical about the relevance of LinkedIn data. We got more API users in yr. 2 than in yr. 1, so I knew the idea was catching on at least a little. But the LinkedIn shortcomings were growing less acceptable. Then, a couple months before that second bushCON, LinkedIn announced that they were closing down their API to all but the biggest ‘partners’. Luckily they didn’t close it till right after the event, so we got that year’s data. But we knew that if we were going to continue this work, we’d have to create that App that Michael had suggested, and Tim was beginning to envision, and that I was still hoping I could resist.
Year 3 – Kumu again| New App for Data Gathering
Kumu was built by innovative systems thinkers & network weavers, for innovative systems thinkers & network weavers – following innovative system’s thinking & network weaving principles. One thing I mean by that is there is an avid community of highly innovative kumu-users engaging in a constant dialog with the Kumu founders/developers & each other about what’s working, what could be improved, new ways we are using the tools, ways we want to use the tools – and that ongoing dialog shapes the platform. Which is to say – it just keeps improving. Even tho the Mohr brothers (e.g. Kumu Founders) keep working on speeding things up, we still push the envelope on rendering speed with the bushCON dataset. But even so – the ‘Wow!’ factor was so great that no-one seemed to mind the slight sluggishness we encountered.
After bushCON #2, neither Tim nor I were initially ready to commit, but Michael kept nudging us about the App idea. He even dragged me to a couple funder meetings hoping to get someone else to pitch in, but no-one bit. We even got laughed at a time or two. But people’s interest in mapping seemed to be growing, our imaginations kept chewing on the challenges, Michael didn’t stop nudging – and I gotta admit, being laughed at for an idea kinda spurs on the rebel in me. I’ll do all kinds of questionably-smart shit just to prove to myself & anyone watching that I can. Or maybe to prove scoffers wrong.
So several weeks after bushCON #2, Tim & I started to visualize & diagram our ideas, find a programmer, & get estimates. Michael pitched in some seed money & we felt like we had to proceed – despite our seriously-limited funds & fiscal fears. We started beta-testing the App (we call it ‘sumApp’ – Greater than the Sum-App, or sounds like some-map- get it?) late last summer, started using it with clients in the fall and by the time registration opened for bushCON #3, we were ready for the big time. Actually, we were slightly afraid of so many people potentially using it at once – but in fact, it all went super-smoothly.
sumApp allowed attendees to load a picture of themselves (it automatically pulls in gravitars as well), answer some questions about themselves, and then scroll through a panel of names & faces to find people they know. Upon finding someone known, the user taps the photo to get a pop-up where they can say how well they know the person. It’s an iterative process – at first we loaded about 50 of the programming & recruiting partners, and that first group was able to go in & share their connections. Once registration opened, we loaded another 100-300 people per week. People who had already shown connections could go back in at any time and check out the new people to see who else they knew.
Year 3 – Tools Reflection
By Stephen Covey’s jargon, you could say the saw has been sharpened. We finally have great tools. Kumu visualizes beautifully, sumApp worked really well, and the updating process has gotten less cumbersome each year.
In fact, it’s a real commitment to go through a scroll of 1,250 people – I expected to hear some complaints about that ask. I was surprised that not a single person complained, and several even commented on how they found the exercise useful in preparing for bushCON. They planned out who to email ahead of time to connect with, they contemplated how long it had been since they’d seen people and started looking forward to seeing them, they pre-planned coffee-dates for afterwards & generally arrived having given real thought to the people in their own networks who were going to be present. It stimulated their network-imaginations, even before seeing the map. People said it was cool.
To a person mired in technical nitty gritty & awash in suggestion for improvement – it was so rewarding to hear that the PURPOSE of all that data-crap was being served, even better than anticipated.
To be continued in Part III – Sensing What is Emerging. . .