Saturday, April 05, 2008

Visualizing the Emergence of a Strategic Knowledge Cluster

In the summer of 2004, when I had just arrived at the University of Western Ontario, my new colleague Alan MacEachern invited me to join a small group that was putting together a grant application. The federal agency SSHRC had just announced funding for the design of something called 'research clusters'. At the time none of us was particularly clear what these clusters were supposed to be, and like many of the best kinds of opportunity, I don't think that SSHRC was really clear either. We eventually settled on the idea that the main task of clusters was 'knowledge mobilization', which left the matter nicely open.

Our initial grant application was successful, and five of us set to work to develop NiCHE, the Network in Canadian History & Environment / Nouvelle initiative canadienne en histoire de l'environnement. As we tried various things we kept track of activities and participants, allowing us to visualize the emergence of our research network. I should say up front that NiCHE doesn't cause research and is prohibited from directly funding research per se. Instead we find ways to facilitate research and training in environmental history broadly construed, and to mobilize the knowledge that researchers create.

One of the tools that we use for visualization is an open source package called Graphviz. We create a file that specifies entities (people, publications, field trips, etc.) and the relationships between them, then we hand off that file to Graphviz, which uses sophisticated algorithms to figure out a neat way to plot the network. We've found such visualization to be very useful, even though it can only ever show the tip of a much larger social iceberg. In our graphs, two people may be linked because they attended the same meeting or each published a chapter in a book. Our data doesn't show whether they knew each other in grad school, have a longstanding rivalry, or both secretly like Buffy the Vampire Slayer.

The original NiCHE executive group worked quite closely together. One of the interesting facts about networks is that the number of possible pairwise relations between entities grows much faster than the number of entities as the network gets larger. Two people have at most one relationship, three people can have three (AB, BC, AC), four people can have six (AB, AC, AD, BC, BD, CD). The ten possible pairwise relationships between the five of us looked like this:



One of the first things that we tried to do was provide licenses for Groove collaborative software to all of the people who were interested in joining NiCHE. For people with Windows machines the software worked very well. Unfortunately, it never really worked for people with Macs. We had to supplement Groove with other software, find suboptimal workarounds, and eventually abandon it. For a while, however, it gave us a way to interact relatively closely with NiCHE members who also happened to be tech-savvy Windows users. Our network took on a hub-and-spoke form.



To reach out to more potential participants, we formed an advisory group and held a meeting in Toronto. Instead of one hub, we now had two, with some bridging members who participated in both online and face-to-face activities.



The executive group split up to host regional meetings in other cities across Canada.



We put together an online directory so members could add information about themselves. The directory allowed us to contact people and tell them about upcoming activities. Since it was publicly accessible, the directory also allowed NiCHE members to learn more about one another.



Although adding one's name to a directory is a relatively weak form of participation, we found that many people became more active in NiCHE over time. The network seemed to extend to new participants, many of whom would then get involved in a number of subsequent projects. There is a saying in free / open source software, "contribute nothing, expect nothing." Conversely we could say that the people who contributed something to NiCHE could expect something from us. Some of them contributed articles to a special issue of the journal Environmental History. Some contributed chapters to a new textbook, Method and Meaning in Canadian Environmental History.



Subsequent activities like a summer school and a graduate student workshop brought in some new participants, and brought back many more:





When SSHRC announced a much larger grant for strategic knowledge clusters, we were able to include a version of the last figure as part of our application. (The Graphviz script that generated it is here.)

A year and half later, we're in the process of scaling up NiCHE activities by a couple of orders of magnitude. Network visualization gives us some insight into the work of a few hundred people who are loosely affiliated with NiCHE and collaborating in many different ways. We can identify people who have energy and initiative to share, and try to help them. Some provide 'bonding capital', tying tightly-linked groups closer together. Some provide 'bridging capital', mobilizing knowledge from one region or disciplinary specialization to another. We can also be more strategic about developing the connections that still need to be made, to make our network stronger and more effective. (For more about social networks, see Clay Shirky's new Here Comes Everybody.)

What is more exciting is that we are getting closer to the point where we can make these kind of tools available to everyone in NiCHE. People will be able to enter their own information about research collaborations and interests, and explore social connections within the network. It will become much easier to find joint acquaintances to make introductions or to find people with particular skills or expertise.

Tags: | | |

Tuesday, March 25, 2008

Monitoring the Backchannel

Rob MacDougall and I are putting together something new and fun for Western freshmen this coming fall, a course called "Science, Technology and Global History." Our goals are modest. We hope to cover the history of the whole enchilada from the Big Bang to the near future, while inculcating the idea that historians and scientists both need to have the same kind of critical, evidence-based habits of thought. Forget the two cultures. While Rob is figuring out how our students can work in teams online with students in South Asia, I'm left to kick back and brainstorm classroom mischief.

One of the interesting things about first year courses at our university is that the enrollment can't be capped. So we could have six students or six hundred. I've done large lectures before, and I'm not very enthusiastic about the format. I try to wave my hands a lot, because I once attended a seminar by a psychologist who studies the teaching evaluation process and he said that students rank mobile professors more highly than sessile ones. I also stopped talking every ten minutes or so to give students a chance to ask questions, but most of them seemed pretty shy. Each term, I got to know the half-dozen who did like to speak up in class.

Since I teach with a laptop and LCD projector, I've been thinking it would be fun to have a chat window running so students could provide backchannel commentary that could be seen by all. This might be something like IM or Twitter. As I was talking, I could keep an eye on the chat window and field questions that would take the class somewhere interesting. If there was a sudden storm of confusion, I could go back and unpack or repeat something. Students who read my blog could even try to amuse me by setting loose chatterbots that simulate famous historical figures. Now I suspect that some of you might be worrying that a few students would abuse the system and type obscenities or whatever. But I'm not worried, because I can always walk over to the computer and close the chat window. It's that easy. I figure that if you treat people like adults they respond in kind.

I'd be happy to hear from anyone who has tried something like this.

Tags: | |

Sunday, March 23, 2008

A Lunchtime Chat

There is a question that I'm told is popular to ask incoming freshmen: "Which historical figure (Jesus, Gandhi, Ozzy, etc.) would you most like to have lunch with and why?" Now I have no idea what quality in the student this question is supposed to elicit, except perhaps forbearance. I'm glad that no one ever tried it out on me, because most of the answers that occur to me--"Is that likely to happen if I decide to attend this school, sir?"--probably wouldn't help my case. When the list of candidates is specified in advance, they're typically chosen either because they are (in)famous icons of recent pop culture or because they are timeless sages who have already provided written answers to the most common set of meaning-of-life-style questions. As much as I might rather meet Lao Tzu than Elvis, my hunch is that it would be more in keeping with Taoist principles to dine with someone who speaks your language and shares your preference for Southern fried cooking. I could be wrong about that.

The whole dining with the stars thing puts me in mind of the Turing test. Alan Turing famously argued that we'd know that a computer was intelligent when its conversational interaction was indistinguishable from a person. Because people and computers look differently (android fantasies notwithstanding) he suggested a situation that would cloak the embodiment of the interlocutor. The person who is conducting the test takes turns asking questions of two different respondents via a low-bandwidth connection (think IM). If he or she can tell which one is the computer, it fails the Turing test.

In 1966, Joseph Weizenbaum created a conversational program called Eliza. Eliza could read an incoming statement like "I hate dogs" and use simple transformational grammar to turn it into a question "Why do you hate dogs?" It could offer noncommittal responses like "Please go on." If the person answered a question with "Yes," Eliza might say "You seem positive." Many people interacted with Eliza enthusiastically, leading some to say the Turing Test had already been passed and others to say that it was rubbish. (If you'd like to converse with Eliza you can Google for one of her many incarnations.)

If I were chatting with freshmen, say over lunch, I'd be looking for students who had heard of Eliza and the Turing test and had a well-developed sense of anachronism. That hasn't happened to me yet. As a public service, I'm going to offer a new question that has been updated for the digital humanities: "What challenges would you encounter when trying to create an Eliza-style simulation of each of the following historical figures? Which would be most or least likely to pass a Turing test and why?"

Tags:

Monday, March 10, 2008

Pupation

Every so often in the past few decades I've had to go through my accumulated collections of code and text and binaries and try to translate them so that they could be used on a new platform or new version of an operating system. In some cases, such as text files, it's always been quite easy. In others, it has been more difficult, or even impossible. The assembly language that I wrote for one chip, for example, won't run on any other. The KnowledgeMan database programming that I did in the 1980s dates me, but otherwise isn't of much use now. More poignantly, KMan doesn't even have its own page in Wikipedia. Now I'm in the process of moving all of my files to an open source revision-control system (more on that in a later post) and face many familiar problems. Once again, I'm discovering that open formats are a really good idea, and that in thirty years--if I last that long--the only sources that I will have to look back on my work right now may be text, XML and source code.

As I go through my files this time around, however, there are a lot of notes from writing my dissertation and publishing it. I'm reminded that I've created a few new careers by metabolizing a succession of older ones and metamorphosing into something different. And when I look through my archival notes and book notes and lists of ideas and questions, I see that most of my work didn't end up in the published book. Some of it was tangential, some was forgotten, some better forgotten.

I'm thinking a lot about the computational tools that historians might use to write different kinds of history. In methodological guides, the emphasis is always on keeping track of things, on proper notetaking and proper citation, so that you don't forget where something came from. Working with digitized sources makes it much easier to search and cite and archive, and easier to imagine that almost everything can be saved. But what if some projects are crucially dependent on a period of forgetting and reuse? What kind of tool would allow some sources to be lost, remake your tangents into something new, turn your caterpillar into a butterfly or a moth?

Tags: | | |

Thursday, March 06, 2008

A Cure for Continuous Partial Attention

On my way home the other night I noticed that the lead story in one of the university student newspapers was headlined "Frustrated profs consider laptop ban." This is one of those perennial favorites. Students seem distracted? Cut off their wireless, ban laptops and smart phones, and forbid internet use for coursework. After all, everyone knows that students always paid respectful attention to their teachers before computer and wireless internet use became widespread. The part of the article that made me laugh the hardest was a quote from an anonymous professor who complained that one student was typing into a laptop furiously for no reason. How hard must that class suck, if the prof thinks that nothing noteworthy was going on? And wouldn't you feel stupid if your inattentive student was brainstorming a cure for cancer? For their part, the students interviewed for the story mostly seemed to think that laptop use was actually helping them to learn and to prepare for their futures.

Really, shouldn't we be worried about the digital divide, rather than trying to exacerbate it? As Manuel Castells argues in The Internet Galaxy, a lack of access to networked devices is only one part of the problem. One of the fundamental challenges for a network society is

the installation of information-processing and knowledge-generation capacity in every one of us--and particularly in every child. By this I obviously do not mean literacy in using the Internet in its evolving forms (this is presupposed). I mean education. But in its broader, fundamental sense; that is, to acquire the intellectual capacity of learning to learn throughout one's whole life, retrieving the information that is digitally stored, recombining it, and using it to produce knowledge for whatever purpose we want. This simple statement calls into question the entire education system developed during the industrial era. (277-78)

A student's freedom to think their own thoughts, to structure their own mental activity, is a far greater good than trying to compel some semblance of attention. So here's a suggestion for all you frustrated profs: relax. I'm guessing that you may have spent some of your own undergraduate hours daydreaming, doodling or writing snarky notes in the margins of your notebooks. And look how well you turned out!

Sunday, February 17, 2008

OSes/2

In my previous post I described a tangible interface that I made for Google Earth, using Arduino and Python. A couple of days after that, I had the chance to take my prototype in to school to try and get it running on one of the student's laptops.

I had pretty high hopes. She had a beautiful new machine. It had only taken me a few minutes to move the project from one of my Win XP computers to another. I had even burned a disk with installation files of all of the software I'd need. She turned on her computer and we waited. And waited. I remembered how disappointing it was the first time I tried Windows 1.0 on my DOS machine. We waited. I remembered how long it had taken for my Win 95 and Win 98 machines to boot. We waited. We made small talk. I asked her how long she'd had her computer (less than a year). I asked her if she liked it. She said plaintively, "I think I want a Mac." We waited some more.

Things went downhill from there. I spent about an hour and a half trying to install my software. Every few minutes, the screen would darken and I would get a security message. Occasionally, a window would open with a long list of processes that needed to be killed. I would then hunt them down one-by-one, try to figure out what they did, and stop them. Unfortunately, the process IDs weren't very useful because they don't appear uniformly in the different tabs of the default display of the task manager. Once in a while I would get an error message with no way to rectify the situation, other than to accept it. Eventually I got to a point where it seemed like I was going to damage something, so I spent another hour trying to undo my earlier actions. Up until a few days ago, I hadn't seen Vista, but had assumed that it couldn't be as bad as the "Hi, I'm a Mac--And I'm a PC" ads made it sound. I took a quick poll of the students and found that about a fifth of them have Macs, and the rest have new Vista machines. I decided to bring in a few old machines running XP to use for their exhibits this year.

I had a lot of time to think while I was sitting there. I have almost $200K to spend on computers for myself, my colleagues and students over the next few years. I had assumed that I'd be buying a few Linux machines for power users and Windows machines for the rest. I just can't see that happening now. I'm beginning to think that the non-Linux machines in our new computer labs might be more useful for everyone if they have an OS that is built on top of Unix.

Tags:

Monday, February 11, 2008

Prototyping a Tangible Interface for Google Earth

As I mentioned in a previous post, students in my digital history grad class this year are working in teams to create interactive exhibits that involve physical computing. Since none of the students have much prior experience with programming or electronics, I'm providing a bit of the scaffolding to help them realize their designs.

The design. One of the groups imagined an interface consisting of a handheld globe. As you touch a point on the surface of the globe, a computer display responds by orienting a corresponding digital globe to focus on that place, and then opens some panels with information about an event that happened there. They decided that Google Earth would make a good software platform. I left them to the task of creating their exhibit materials in the XML-based Keyhole Markup Format (KML) that Google Earth uses.

Hardware. The exhibit will be mounted on a laptop running Windows. For the tangible interface we're using an Arduino microcontroller board. Normally-open pushbutton switches are connected to the digital inputs on the Arduino with 10K pull-down resistors. We debounced the switches in software, by reading their value twice at 10ms intervals. The Processing program that runs on the Arduino is here. It maintains the state of the last button pressed, and sends it repeatedly over a serial connection to the PC. (If you'd like to try making something like this yourself, Lady Ada's Arduino Tutorial is a great place to start).



Python glue. We needed a program to sit in between the Arduino and Google Earth, collecting information from the former and using it to control the latter. Python is ideal for this. First we installed the Python for Windows extensions and the Python Serial Library. We were then able to control Google Earth via the COM API. Our Python test program is here. It first defines two functions, one to orient Google Earth to the main gates of the University of Western Ontario, and one to orient it to Uluru (Ayers Rock) in Australia. The program then initializes the serial port and Google Earth. Finally it enters an infinite loop, reading the serial port and calling one of the two navigation functions when the corresponding button is pressed. (If you'd like to use Python to control Google Earth, François Schnell has a very useful page.)

Testing. I was quite impressed with how crisply the whole system works together. To get it running, you go through the following steps.

  1. Build and test the button circuit, then connect it to the Arduino.
  2. Start the Arduino software on the PC.
  3. Compile the Arduino program and download it to the board.
  4. Run the Python program. It will start Google Earth automatically in full screen mode.
  5. Once Google Earth has finished initializing, you can press the buttons to navigate within the program.


The final exhibit for our class will be mounted in April. You will be able to read more about it on the students' blogs and at the exhibit website. I'll write about some of the other components in future posts.

Tags: | | | | |