Jon Udell

My guest for this week’s Innovators show is Andrew Rasiej. The show is a perfect example of what I envisioned a few years ago when I began looking for ways to mash up ITConversations with Social Innovation Conversations. Andrew is a social entrepreneur whose projects all, in one way or another, adapt technology to social need.

In this conversation we focus mainly on two of those projects. MOUSE advances the computerization and networking of schools by inviting students to become system and network administrators. The Personal Democracy Forum is an initiative to reboot politics.

From this interview, and from an earlier conversation with Andrew at Transparency Camp 2009, I took away two key principles:

1. Design for abundance. Activating student sysadmins and crowdsourcing political action are two of many examples where the gamechanging assumption is that resources and talent are abundant rather than scarce.

2. Be a lifelong learner. And to the extent you can, prefer to work with other lifelong learners.

There’s a bit of a conundrum here, because lifelong learners arguably are a resource that really is scarce. I’m still not sure how to think about that.

As my mom wrestles with the difficult combination of hearing loss and vision loss, I’ve grown more aware of the strengths and weaknesses of various assistive technologies. Many are disappointing, but the Humanware magnifier is working well for her.

It’s basically a digital camera that projects onto a flatscreen monitor. You position your book or magazine on the flatbed, and zoom the onscreen text to the needed magnification.

As I watched her use the device I could see room for improvement. Although the bed slides laterally and longitudinally, the action is a bit stiff. So she tends to slide the reading matter around on the bed, rather than sliding the bed itself. As a result, she winds up realigning the book, newspaper, or magazine more than would otherwise be necessary.

With books, in particular, there’s also the issue of getting them to lie flat. I don’t think there’s any easy solution for that, but my mom’s OK with holding her books open on the bed.

There’s really only one test that matters: Can she read? And the answer is yes. My mom has been a lifelong voracious reader. Her macular degeneration had gotten to the point where she simply could not read, and that was devastating. Audiobooks help, but not much. That’s partly true because of hearing loss, and partly because the audio gadgets she’s tried — CD players, MP3 players — lack the affordances she needs.

The Humanware magnifier just works. There’s a big on/off switch, and a big zoom dial, and she can put a book, magazine, or newspaper onto the flatbed and read. Not nearly as fast as she’s capable of, but she can read. And so she does.

This week’s Innovators show has the lowdown on Phil Windley‘s new company, Kynetx. The first application of the Kynetx technology is Azigo’s RemindMe service. It alters search-results pages to highlight cases where the user has — but would likely have forgotten about — a discount-qualifying membership.

There are a number of moving parts in this scenario. On the back end, Kynetx provides a rules engine that decides how to rewrite a page based on the context of the user’s “web episode” and the user’s membership in an organization like AAA. Membership is asserted by an Information Card that the user installs, then presents on request to a browser extension. It asks the Kynetx service for a chunk of page-modifying JavaScript, then runs that code locally to effect the change specified by the rule.

If you’ve followed the Internet identity saga — a story that Phil has helped to write, as author of a book on digital identity and as an organizer of the Internet Identity Workshop — you’ll be thrilled to see that the Kynetx system is responsible for the minting and real-word use of Information Cards. As Phil explains in this interview, the cards as currently used convey no extra information, they merely signify membership. Still, it’s great to see this key technology finally percolate out into the mainstream.

Kynetx will mainly serve companies that want to solidify and enhance high-value relationships with customers by means of “permission-based context management.” Refreshingly, the Kynetx wiki qualifies that definition in a way that will make Doc Searls smile:

The following anti-lexicon contains words and concepts that Kynetx doesn’t use:

• exploit – while opportunities might be exploited, people never should be.

• eyeballs – we’re not doing optometry

• target – you target enemies, not customers.

Near the end of the interview, Phil refers explicitly to Doc’s VRM (Vendor Relationship Management) campaign:

We see ourselves as plumbing for VRM. For example, we’re putting together a green choice card. If you install it, as you search around the web it will show you which companies have been ranked well or poorly in terms of social responsibility. Right now it’s just a demo, and we don’t have great data, but suppose we did, and there were enough of those cards out there, and Constellation Brands was determined by Fortune Magazine to be the least socially responsible company in 2008. If every time a cardholder found a Constellation product on Google there was a little icon indicating that, and there were a lot of people with the card, you could change the company’s behavior. They’d want to get the icon off that page.

It’s a fascinating notion, and it leads to an issue that I should’ve raised with Phil in the interview but will raise here instead. A couple of years ago, during my period of infatuation with Greasemonkey, I made a 4-minute screencast entitled Content, services, and the yin-yang of intermediation. At the time, I’d just invented a Greasemonkey-enabled version of LibraryLookup that was more aggressive than the standard bookmarklet version.

With the standard version, you click a bookmarklet while on an Amazon page, and a query against your local library pops up in a window. With the Greasemonkey-enhanced version, the Amazon page itself is rewritten to say:

“Hey! This book’s available at the Keene Public Library!”

Or:

“Due back at the Keene Public Library on March 28.”

But does the user of a web-based service have the right to modify pages in these ways? The screencast ponders that question. Three years ago there wasn’t enough client-side page rewriting going on to raise that question in a big way, and I guess there still isn’t, but now that jQuery is making the capability broadly available it’s bound to come up.

There’s a continuum of ways in which I can modify a web page in a browser, ranging from font enlargement to translation to contexual overlays. I wouldn’t draw a line anywhere along that continuum. It seems to me that I’m entitled to view the world through any lens I choose.

This doesn’t only apply to my view of the virtual world, by the way. It will apply to my view of the physical world too. We don’t yet have magic glasses that overlay web prices on shelf items, or web reputations on store signage, but someday we will.

I can’t see how I could be prevented from creating a heads-up display — for realspace or cyberspace — that’s advantageous to me. But I’ve got a hunch that those magic glasses are going to be controversial.

Last week I started inviting calendar curators to join the elmcity+azure project. The age-old question immediately arose: How to communicate and collaborate? An email distribution list? A web forum? A blog? A wiki?

Been there, done that. Times are changing, and it felt like there ought to be a new answer to that old question.

Here’s the answer I came up with: a FriendFeed room. From my perspective, it’s an ideal solution. And fittingly, that’s true because it embodies the same principles woven into my elmcity project: syndication, publish/subscribe messaging, loose coupling.

I needed a lightweight system that would enable everyone involved in the project to be aware of, and optionally discuss:

• Service updates
• New locations
• New feeds
• Issues

So I created a FriendFeed room, and subscribed it to the following feeds:

• All the curatorial feeds on Delicious: elmcity, a2cal, whyhuntington, localist
• The subset of my blog’s feed that is specific to the project
• The Pipes feed that gathers news about a related effort to improve iCalendar validation. (That Pipes feed is, in turn, gathering a handful of other feeds, combining the icalvalid tagspaces on Technorati, Delicious, WordPress, and Twitter.)
• The updates from a project status page that I’ve started writing on my blog.

It took about five minutes to set that up yesterday. I checked the room just now, and here’s what I saw:

In other words, Bill Rawlinson, who is curator for Huntington, WV, found — or, rather, created, using the increasingly awesome FuseCal — three new iCalendar feeds today. Those are three events of interest to the project. It should require near-zero effort for such event to come to the attention of project members. And when the workflow is syndication-enabled — as is automatically true for us, because we are using Delicious as the curation tool — it really does cost nothing to usefully propagate those events. The web hooks are already there, you just have to use them.

I have invited the curators into the room, and some have joined, but a crucial benefit of this arrangement is that nobody has to join unless there’s a need to actively discuss issues. To monitor the project’s event stream you can just go to the project’s FriendFeed room. Or don’t go. Because that stream is also, of course, available as a feed you can subscribe to.

It’s wildly cool, and incredibly useful. Thanks FriendFeed!

I really chatting last week with Andrew Turner on my Innovators show. Andrew is the driving force behind GeoCommons, a new service that brings social curation and visualization to the realm of geographic information and cartography.

A lot of our discussion wasn’t specific to geographic data. Issues of provenance, data tethering, syndication, and interpretive context apply to any kind of data that lives online and is both produced and consumed by a lot of different people. As more kinds and quantities of data move into the public realm, we’ll discover and codify best practices for coordinating our efforts.

But we also, of course, talked about the special challenges of geographic data. Marrying temporal and spatial data is a huge one. As I mentioned here, the team at Stamen Design is doing great work on that front.

Of course we’ll want to encapsulate, in software tools, some of the chops that produce animated displays like their Oakland crimespotting map, or the Rocky Mountain Institute’s oil import map.

My own related effort was far less effective than that RMI oil import map. The best stories told with data will arc through time, and it needs to get way easier for anyone who cares to tell those stories.

As the tools and services emerge, we’ll run into another issue that Andrew and I discussed. Cartography is an incredibly subtle art, and we will soon see a proliferation of awful maps made by folks with data, tools, and no design sensibility. But that’s OK, in fact it’ll be a good problem to have. People went nuts with fonts and colors when the web was new, and everyone suddenly became a publisher. Over time things have settled down. It’ll be interesting to watch the cycle repeat as everyone becomes a mapmaker.

As calendar curators begin bringing the elmcity project to life in their communities, they’re broadening my horizons. Last year, for example, in the comments on this entry, I learned about FuseCal, a calendar-publishing service that can extract structured calendar information from semi-structured web pages. I’ve been using FuseCal ever since, but in my community I’ve only found one otherwise-inaccessible calendar that it can successfully parse. Curators in other communities, however, are finding more. The Baltimore list includes a handful of them, and so does the Huntington, WV list.

In that comment thread, I tweaked FuseCal’s product manager Matt Gillooly when I said that a service based on HTML screenscraping shouldn’t need to exist. His reply was spot on:

I agree that, ideally, FuseCal wouldn’t have to exist — in the same way that, ideally, hospitals and prisons wouldn’t have to exist. :-)

Seriously, though, I think you need to provide a lot of incentive in order to get people to change the way they behave. It’s much easier to sell a Tylenol than a vitamin.

Matt’s right, of course. My goal for this project is to bootstrap networks of calendar feeds in communities. What matters is lighting up feeds, much more than how they get lit. So it’s great to see FuseCal lighting up feeds in Baltimore and Huntington.

Another service that has seen limited use in my own community, but will be more important elsewhere, is Upcoming. It’s ironic because back in 2005, when I first started thinking about this stuff, Upcoming was the model for what I hoped would emerge in Keene. I walked around town that spring, took photos of event posters, noticed how little of that information was available online, and wondered what it would take to fix that. I’d been using Upcoming myself, but hadn’t had much success getting anyone else involved.

In a blog entry I mused about ways to improve the service. One of my suggestions was to provide an API, and Upcoming’s founder Andy Baio heard and responded.

Four years later there still aren’t many Upcoming events for Keene. But as other communities come online, I’m finding that Upcoming is more popular there. So I’ve added it to the mix, and am finally using the API I asked for long ago.

The elmcity service now supports three major sources of events:

1. A curated list of iCalendar feeds
2. Eventful
3. Upcoming

The Eventful and Upcoming sources are governed by three bits of Delicious-tagged metadata. For Keene, they are:

radius=15
lat=42.9336
lon=-72.2786

Both services support queries that, if written in English, would say: “Give me all the events within 15 miles of Keene.”

Won’t there be duplication? Sure, and here’s an example from the Keene calendar.

I regard this as a good problem to have. Seeing an event from multiple sources is infinitely better than never seeing it at all. Over time I’ll look for ways to coalesce these duplicates. But for now, given that the vast majority of events aren’t being posted online in any structured way, I like showcasing the many ways to do that.

From an article in today’s NY Times by my friend Peter Wayner:

Some people are so devoted to their keyboard that they search for backups and worry about finding another copy of a discontinued version. Jon Udell, a senior technical evangelist for Microsoft who suffers from repetitive stress problems, uses a Floating Arms keyboard last manufactured in the 1990s. The device incorporates the left part of the keyboard into the left armrest and the right half into the right armrest. The weight of the arms is carried by the rests, which put the hands in the optimal position to stroke the keys. It is the ultimate synthesis of easy chair and keyboard.

“[If you are a touch typist] your hands never cross the center line anyway,” explained Mr. Udell. “This way you take all the weight off your shoulders, all the tension off your neck, you straighten your back, and you breathe better.”

What will he do if it breaks? He hopes someone else builds another version because nothing else comes close for him.

“It’s been a godsend and I don’t know what I’ll do without it,” he said, fingers crossed.

Here’s the picture of my beloved “Captain Kirk chair” that we ran in BYTE in 1996:

The Floating Arms Keyboard, from Workplace Designs ((612) 439-4474), addresses postural problems associated with the traditional desk, keyboard, and chair. A BYTE editor found that switching to this keyboard greatly reduced work-related pain.

From that article:

Understanding keyboards is a complex research task. “That is because the problem is multifactoral,” says Cathy Mishek O’Brien, president and CEO of Workplace Designs (Stillwater, MN), which sells the Floating Arms Keyboard.

Thanks again Cathy. If you should happen to find this, I’d love to hear more from you about the story of this product: how it was developed, why it was discontinued. It’s hard for me to understand why a product that was so revolutionary, and is so effective, didn’t succeed.

WHAT AND WHY

With the community calendar service now live, I’ve got to do a bit more work to make it fully data-driven. Since I’m already managing the per-community feed lists and metadata on Delicious, I figure I might as well go all the way. So I’m keeping a list of the Delicious accounts that control each community’s calendar aggregator on Delicious too. Today there are three. The idea is that when I add the fourth, I won’t touch any code — or even configuration data — that will require an update to the running service. I’ll just bookmark a fourth Delicious account and tag it with calendarcuration.

But that’s merely an administrative convenience. Much more critical, at this point, is to help curators find machine-readable calendars in their communities and — since most of the calendars that might exist don’t — also show people how they can easily create them.

I got a running start when I bootstrapped the Ann Arbor instance, thanks to Google Calendar. I searched for Ann Arbor there and found a nice list of iCalendar feeds. But that search feature is, at least for now, gone.

Several curators have tried searching the web for .ICS files (e.g. filetype:ics), but that’s not very productive for a couple of reasons. Where iCalendar resources do exist, they often aren’t exposed as files with .ICS extensions. But more importantly, relative to the number of iCalendar resources that could exist, very few actually do.

So I thought back on how I bootstrapped the original Keene instance. A number of the events there are recurring events that were advertised on the web, but not in any structured format. I found them one day by doing web queries like:

"first monday" keene
"every thursday" keene

There’s no fully automatic way to convert this stuff into structured calendar data. But it’s pretty straightforward to fire up a calendar program, enter some recurring events, and publish a feed. The advantage of recurring events, of course, is that they keep showing up, which is very helpful if you’re trying to build critical mass.

So I’m now envisioning a pair of tools to help curators do this more easily. First, I’d like to have each community’s aggregator running a scheduled search that helps the curator be aware of calendar-like information that could be upgraded to actual calendar data. Second, I’d like to provide a tool that partly automates the cumbersome data entry.

I’ve done an initial version of the search tool, and an example of its output is here. I’ll attach the code to the end of this item, for those who care, although I expect that if it winds up being useful to curators, most will appropriately not care, and will only want to scan the links now and then.

It may be interesting, over time, to try to evolve this into a robot that makes sense of the calendar information that people actually write, as opposed to the information that calendar programs constrain them to produce. But meanwhile this hybrid approach seems like a way to make progress.

HOW

I did this tool in two parts. The kernel, so to speak, is in C#, because for now that’s the most practical way to write Azure services and applications. But the application is in IronPython, because the search function doesn’t yet need to be hosted on Azure, and IronPython is a really flexible and convenient way to experiment with the kernel.

The C# piece uses James Newton-King’s Json.NET library because JavaScript interfaces are now the preferred way to search programmatically. It’s been a while since I’ve done this kind of thing. Used to be, the REST APIs were easy to find. But now, since those interfaces are mainly intended for use by JavaScript objects embedded in web pages, I had to do a bit of spelunking.

One of the interesting things about Json.NET is that it includes an implementation of LINQ for JSON. That’s why you see the “from … select” syntax, which extracts an enumerable list of URLs from the JavaScript results returned by the search services.

using System;
using System.Collections.Generic;
using System.Linq;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

namespace CalendarAggregator
{
  public class Search
    {
    public List<string> search_result_urls;
    public Dictionary<string, int> dict;

    public List<string> livesearch(string query)
      {
      var url_template =  "http://api.search.live.net/json.aspx?AppId=XXX& \
          Sources=web&Query={0}&Web.Count=50";
      var offset_template = "&Web.Offset={1}";
      var search_url = "";
      int[] offsets = { 0, 50, 100, 150 };
      foreach (var offset in offsets)
        {
        if (offset == 0)
          search_url = string.Format(url_template, query);
        else
          search_url = string.Format(url_template +
            offset_template, query, offset);

        var page = Utils.FetchUrl(search_url).data_as_string;
        JObject o = ( JObject) JsonConvert.DeserializeObject(page);

        var urls =
          from url in o["SearchResponse"]["Web"]["Results"].Children()
            select url.Value<string>("Url").ToString();

        dictify(urls);
        }
      return new List<string>();
    }

    public List<string> googlesearch(string query)
      {
      var url_template = "http://ajax.googleapis.com/ajax/services/search \
          /web?v=1.0&rsz=large&q={0}&start={1}";
      var search_url = "";
      int[] offsets = { 0, 8, 16, 24, 32, 40, 48 };
      foreach (var offset in offsets)
        {
        search_url = string.Format(url_template, query, offset);
        var page = Utils.FetchUrl(search_url).data_as_string;
        JObject o = (JObject)JsonConvert.DeserializeObject(page);

        var urls =
          from url in o["responseData"]["results"].Children()
             select url.Value<string>("url").ToString();

        dictify(urls);
        }
      return new List<string>();
    }

  private void dictify(IEnumerable<string> urls)
    {
    foreach (var url in urls)
      {
      if (dict.ContainsKey(url))
        dict[url] += 1;
      else
        dict[url] = 1;
      }
    }
  }
}

Here’s the IronPython piece which uses the search methods from the C# code:

import clr
clr.AddReference("CalendarAggregator")

locations = [
'ann arbor',
'huntington wv',
'keene'
'virginia beach',
]

qualifiers = [
'first',
'second',
'third',
'fourth',
'every'
]

days = [
'monday',
'tuesday',
'wednesday',
'thursday',
'friday',
'saturday',
'sunday'
]

for location in locations:
  search = Search()
  for qualifier in qualifiers:
    for day in days:
      q = '"%s" "%s %s"' % ( location, qualifier, day )
      search.googlesearch(q)
      search.livesearch(q)

for key in search.dict.Keys:
  print key, search.dict[key]

The elmcity+azure project is live today at elmcity.cloudapp.net. The service is currently gathering and organizing online calendars for two towns: Keene, NH and Ann Arbor, MI. I’m keeping the list of iCalendar feeds for Keene, and Ed Vielmetti is keeping the list for Ann Arbor.

If you’d like to play along in your town, just pick a Delicious account, bookmark all the useful iCalendar feeds you can find, plug in some metadata, and point me to the account. I’ll register it with the service, which will:

• Regularly parse the iCalendar feeds in your list.
• Report numbers of events found in the feeds, or details of errors encountered.
• Scan Eventful.com for events in your specified location.
• Merge all the events.
• Publish an HTML view of the merged calendar, based on the HTML template and CSS file that you specify.
• Produce JSON and XML views of the merged data.
• Serve up an embeddable JavaScript widget for just the current day.

If you decide to try curating one of these lists, you’ll quickly find, as I have, that there are no major technical hurdles. True, there are some issues with invalid iCalendar feeds. But that’s not what prevents us from having a comprehensive view of all the public events happening where we live. The real challenge is explaining how to publish useful calendars using free, ubiquitous tools, why posting a PDf to the website isn’t good enough, and what network effects can happen when more of us publish and syndicate calendar feeds.

It’s a big challenge. But progress in this domain can generalize to others. When I discussed this project at Transparency Camp, Greg Elin said: “OK, so you’re not trying to get people to adopt a technology, you’re trying to get them to adopt a pattern.”

That’s it exactly. This pattern of collaborative curation isn’t yet well understood or widely practiced. But it’s a key strategy that Internet citizens can use to enhance collective awareness and enable collective action. So if you try this experiment, I’m most interested to know what words, images, behaviors, or demonstrations help you get that idea across.

Doug Purdy is thinking out loud about the principles, scenarios, architecture, and software necessary for what he calls infobus and what I have called hosted lifebits. I started to respond in comments on Doug’s blog, but of course that subverts what I declare to be a core principle, namely syndication.

There’s a crucial difference between a) committing my words to Doug’s blog, and b) committing my words to my own lifebits stream and then syndicating them to Doug’s blog. We don’t see it very clearly yet because we lack the mechanism for b).

I can kinda get the effect of syndication by referring to Doug’s blog entry from mine, and hoping that his blog engine will notice and acknowledge. But a truly syndication-oriented mechanism would imply that I publish in my own space, and then — in Doug’s space — actively subscribe back to myself. To explicitly comment on Doug’s entry, in other words, I don’t type words into his comment form. I create a subscription associated with my identity (as a conventional comment always is) that points back to my feed.

Let’s consider Doug’s point #4: “You determine if/when/how this data is accessed, the terms of use and the revocation of the license.” If I comment on Doug’s blog, I can hope for ex post facto control of my words, but whatever agreement may be (tacitly or explicitly) in place, the architecture doesn’t support that control. I may or may not be able to revise or extend my remarks. And Doug can certainly revise, extend, or delete — it’s his blog.

If I syndicate to Doug’s blog, there is still only a hope of ex post fact control, not a guarantee. But the architecture is at least aligned in my favor. The effort I invest in writing on Doug’s blog, or a bunch of other blogs, is preserved. I can archive, organize, and search all my stuff. I don’t need to depend on services Doug’s blog may or may not offer to find out who is reading and reacting to my stuff. And if I want to withdraw my comment, I just revoke the permission I gave Doug’s blog service to syndicate from mine.

Realistically, that revocation won’t erase my contribution to Doug’s blog. My words may have been quoted there, in other comments, and the mixing process dilutes control — which I argue is a feature, not a bug. But if the default is to syndicate by reference, rather than by value, the architecture favors the kind of control we want.

To clarify what I mean by favoring the right kind of control, let’s switch to a medical information scenario. Recently I had a dental xray. The image lives on the dentist’s hard drive. I want it to work differently. When I show up at the dentist’s office, I want to give the xray technician a token that grants her machine access to my lifebits store. The machine publishes the image to my store. I, in turn, agree to syndicate the image back to the dentist — maybe to copy, but maybe only to view.

One interesting benefit of this arrangement is that I’m decoupling dental service from image storage service. Maybe I’ll just turn around and reconnect them, because maybe I’d rather just let the dentist bundle those services. But when I interpolate my lifebits store into the pipeline, I guarantee portability to another dentist.

Another benefit is clarity of ownership and syndication rights. My lifebits store will have a management service where I declare, review, and adjust all of the syndication relationships between my lifebits streams and the services they participate in. And this management service can not only implement my ownership and syndication policies, it can announce them to the world. It can be the place where I say who gets to do what with my stuff. Some of those policy assertions will be private, but many will be public. Ultimately, again, there is no guarantee of ex post facto control. But if you violate my terms, it will be easier for me, or anyone, to determine that you have done so.

PS: Coincidentally, or maybe not, Doug was my guest on last week’s Innovators show. The topic was “Oslo”. But the context was our shared passion for figuring out how computers, information systems, and networks can more easily and more faithfully express the intentions of the people who own, operate, and inhabit them.

I spent last weekend in DC at Transparency Camp, which turned out to be one of the best cultural mashups I’ve attended in a long time. If we can get federal policy wonks and Silicon Valley tech geeks working together in the right ways, there’s good reason to hope that our government can become not just more transparent, but also more effective, more collaborative, more democratic.

A central theme was access to the operational data of government. What kinds of structured or narrative data exist, or could exist? When government doesn’t publish the stuff, how can activists extract it? When government does publish it, how can that be done most usefully? When the information is made available, one way or another, how can citizens, journalists, and government itself make use of it?

In my own work, I’ve been asking and trying to answer these questions. The event validated my efforts, and connected me to a flood of relevant people, ideas, tools, and techniques. That’s what you hope to get out of a conference, and it’s what this one delivered in spades.

But it also brought something else into sharp focus. To explain, I have to revisit 1994. In that seminal year, Microsoft famously “got” the Web. As BusinessWeek reported two years later:

The Web-izing of Microsoft begins in February, 1994, when Steven Sinofsky, Gates’s technical assistant, returned to his alma mater, Cornell University, on a recruiting trip. Snowed in at the Ithaca (N.Y.) airport, he headed back to the Cornell campus. That’s when he saw it: students dashing between classes, tapping into terminals, and getting their E-mail and course lists off the Net.

The Internet had spread like wildfire. It was no longer the network for the technically savvy — as it had been seven years earlier when Sinofsky was studying there — but a tool used by students and faculty to communicate with colleagues on campus and around the world. He dashed off a breathless E-mail message called “Cornell is WIRED!” to Gates and his technical staff.

Fifteen years on, the Net is as pervasive as air, as fundamental as gravity, as nourishing as sunlight — at least for the billion of us lucky enough to be online.

But while the architecture of the Net is firmly established, the architecture of communication and collaboration enabled by the Net is still very much up for grabs. Key principles, best practices, and effective patterns are still emerging.

For many years I have been a discoverer, early adopter, and explainer of those principles, practices, and patterns. And I’ve wondered: What would it would be like if you didn’t have to discover, adopt, and explain this stuff? What would it be like if you could just take it for granted, and just use it, in an environment where everybody else was using it too?

It would be like Transparency Camp 09.

This wasn’t the first event I’ve been to where Twitter was pervasive. But it was the first I’ve been to where tech geeks weren’t the only ones Twittering. The policy wonks were too. Everyone was tuned into the #tcamp09 channel. And, in fact, everyone still is. The conference “ended” on Sunday, it’s Thursday, but a half-dozen new items appeared on that channel since I started writing this essay. I particularly like this one:

Funny. Someone from #tcamp09 lives in my building. She says, “Didn’t we meet this weekend?” “No.” “You’re…cheeky something?” “OH…yes”

That’s a nice example of manufactured serendipity. I coined the phrase in another era. Back then, the new phenomenon called blogging was the realm in which we were discovering, adopting, and explaining the crucial principles, patterns, and practices. Now the action has moved to Twitter. But they’re the same principles, patterns, and practices:

1. The principle of conserving keystrokes
2. The pattern of publishing and subscribing
3. The practice of narrating your work

In 1994 Steve Sinofsky saw the arrival of the Net, and sent email to tell Microsoft about it. In 2009 I see the emergence of a transformative way of using the Net. I could try sending email to tell Microsoft about it, and that would still be the preferred method. But email is no longer the engine that will drive radical improvement. What’s more, it often subverts the right principles, patterns, and practices.

So how does Microsoft, or any large enterprise — e.g., the government — embrace a new architecture of communication and collaboration? Slowly at first, but inexorably, and with profound effects in the long run. I can’t alter the timetable. But this is an interesting moment, and I simply want to observe, mark, and note it.