The technology understanding gap

2008 #51: Still Not Connected
Eugene Eric Kim has an excellent post on The Technology Understanding Gap which uses a story to articulate one of the key challenges of technology stewardship – the frequent gap of understanding, and practice with technology that happens between a steward and her/his community. (The same goes for advisers, consultants and that geek friend who really, really wants to help you.)

First a quote from Eugene (I realize as I write this and having just written about Brian Hsi, that these guys both are smart and have a very thoughtful way of expressing both their ideas, and how they formulated them. I love that about both of them!)

Technology is insidious. It has a way of dominating a problem the way nothing else can. If you understand technology, it’s hard not to see everything in that light. If you don’t understand technology, it’s hard not to be overwhelmed by what you don’t know.

Eugene tells the story of a group he was facilitating and how they were trying to figure out how to connect a network of practitioners across the country. Eugene, recently inspired by Clay Shirky and his three column model, decided to use the “Tasks/Tools/Promises” framework for thinking about the group’s challenge.

Eugene Kim's flipchart picture
Eugene continues:

What do you notice about this picture?

Obviously, the Tools column is completely empty. That’s a dead giveaway that I’m facilitating this discussion. (That and the horrific handwriting.) Figure out the basics first. Don’t let the question about technology drive the discussion.

During the discussion, one of the participants asked, “What tools can we use?”

I responded, “Let’s not worry about that now.” So we kept talking and talking, and I noticed the two non-technical participants in the group squirming like crazy.

So I stopped, noticed how gaping the Tools column looked, and said, “You’re uncomfortable about not having discussed the tools, aren’t you.”

She nodded.

“Don’t worry about it,” I responded. “The tools part will be easy, once we figure everything else out.”

“Easy for you, maybe,” she said. “You already know what goes there.”

That was not quite true, but I got her point, and the force of it struck me so hard, I had to stop for a moment. I looked at the gap, and I saw possibilities. She looked at the gap, and she saw a void. That was upsetting for her. It made it hard for her to think about the other aspects of the problem.

It made me realize how much I take my technology literacy for granted. But it also created an opportunity to discuss how easily we are sidetracked by technology. “Tool” does not have to mean software, and making that assumption prevents us from exploring other viable, possibly better solutions.

In his post, Eugene goes on to reflect that next time he does the exercise he is going to start WITHOUT the tools column. I can see that as a really useful option. But I think there is an additional perspective.

Tools are sometimes not just practical affordances to get a job done, but they offer a way to visualize an outcome. we conceptualize them quickly with “technology” and all its bells and whistles, but tools are something bigger than just the latest software. Yes, they can limit us, but sometimes they also open up possibilities. As much as I’m a deep believer in the Task and Promise columns, I am surprised and reminded that some people, even non technical people, have a conceptual framework that builds ON the IDEA of a tool. So taking away that column may actually INCREASE anxiety for some, rather than reduce it.

My final question to myself and you, is how do we USE the tool column in a way that does not lead us down the technocentric path, but still helps us keep the concept and usefulness of “tool” in our conversations? How do we most usefully have and facilitate, as needed, these conversations?

Photo credits:
Creative Commons License photo credit: Jeroen Latour and Eugene Kim

What about the freaking book?

Some of you know that Etienne Wenger, John Smith and I have been working on a book about technology for communities of practice for what seems like an eternity. Well, there IS progress. We are working on the final round of writing and editing. We desperately need a graphic designer who can help us turn our images into something useful. The focus is information graphics.  (Yes, with a very small budget!) If you are interested, ping me. In the meantime, John posted a wee update on the book blog… Technology for Communities » Time marches on. One of the things he did was share a couple of graphics we are using. (These are examples of the work we need someone to improve upon!)

What is an API?

I have been doing little editing/clean-up bits for the upcoming “Stewarding Technology for Communities” book and one of the things we want to get right are the technical terms – and we want them to be understandable to people who may not be techies. One that I was chasing down yesterday was API, or Application Programming Interface. I wasn’t clear if APIs opened up access to functionality, the actual code, or both. I decided to ask my Twitter friends. Here is what I learned – I thought I would share it with you.

reply to NancyWhite

  • davecormier @nancywhite it’s like exposing the underside of a lego block. if you make your block to fit the holes, you can connect to it 04:27 PM January 02, 2008
  • D’Arcy Norman dnorman @nancywhite: APIs expose functionality so you can write your own code to incorporate it. 01:17 PM January 02, 2008
  • Chris Lott fncll @NancyWhite also depends on what is meant by “access” to code– a proprietary system w/API can provide access to code 11:13 AM January 02, 2008
  • Chris Lott fncll @nancywhite APIs provide access to existing functions, code and data, any or all of which can be used to further functionality. 11:12 AM January 02, 2008
  • Scott Leslie sleslie @nancyWhite forget what I just said. I thought you were asking a different question. Just waking up. 11:42 AM January 02, 2008
  • Scott Leslie sleslie @NancyWhite both, it depends. Some API’s focused around giving you functionality, other’s around data (though w/ data, there are other ways) 11:41 AM January 02, 2008
  • Jan Karlsbjerg JanKarlsbjerg @NancyWhite API’s make FUNCTIONALITY accessible to other programs/programmers. 11:38 AM January 02, 2008
  • Lion Kimbro LionKimbro @NancyWhite: APIs make functionality accessible. Even if code is available, I wouldn’t necessarily call it “accessible.” 12:21 PM January 02, 2008