Upcoming talk at Kynetx Impact

As Phil Windley mentioned the other day, I’ll be speaking at the Kynetx Impact conference, April 27-28 in Salt Lake City. Last year I interviewed Phil about what Kynetx does. It’s hard to boil it down to an elevator pitch without examples, so here’s one that came up today: Scott Hanselman’s Put Missing Kids on your 404 Page application.

Inspired by a PHP solution to the problem, Scott set out to replicate it for ASP.NET.

But then I realized that a server-side solution wasn’t really necessary.

Could I do it all on the client side? This way anyone could add this feature to their site, regardless of their server-side choice.

One next step, as Scott points out, is to add geolocation so the list of kids you see will be more relevant to you. But there are lots of ways to contextualize that list based on aspects of your identity. And this is what Kynetx applications do: Contextualize your experience of the web based on aspects of your identity.

My own interest in this idea dates back to the LibraryLookup project, which was an early demonstration of the power of client-driven contextualization. It evolved from a bookmarklet to a browser plug-in, but then stalled there for lack of a ubiquitous client-side technology.

Now there is: jQuery. What Scott’s example shows, as do all Kynetx applications, is that we’re ready to make clients more equal partners in the dance of the web. Among other things, this possibility raises horny issues about the control of content — issues that I explored in a 2005 screencast.

But there’s also a deep connection between Phil’s work and the ongoing saga of digital identity. Phil wrote a book on that subject, and has been a key organizer of the Internet Identity Workshop. When he started Kynetx he wasn’t really thinking about a tie-in to Information Cards and the identity metasystem. But the connection emerged organically.

In a Kynetx-enhanced version of the Missing Kids 404 Page application, your browser would present selected aspects of your identity to the services that provide the data, and a Kynetx application would personalize that data in ways meaningful to you.

The Internet began as a network of peers. That arrangement didn’t last long, and there have been several efforts to restore the original symmetry. In the early 2000s, during Napster’s heyday, there was a flurry of interest in peer-to-peer architectures. Thanks to today’s more capable and more standardized browsers, we’re seeing a new wave of interest. I’m looking foward to hanging out at the Kynetx conference and meeting folks who are riding that wave.

Talking with Eric Frank and Jon Williams about Flat World Knowledge, a commercial publisher of open textbooks

My guests for this week’s Innovators show are the co-founder (Eric Frank) and CTO (Jon Williams) of Flat World Knowledge, a new textbook publishing company with a refreshingly disruptive business model. Like any other textbook publishing company, Flat World is building up a stable of authors with whom it has exclusive (or, in this case, semi-exclusive) relationships. Authors assign the Creative Commons Attribution-Noncommercial-Share Alike (by-nc-sa) license to their work. Flat World makes the books freely available online, in HTML and PDF formats. It sells print-on-demand copies of the books direct to students, along with a variety of study aids.

Ebooks are another potential source. But so far, Flat World has found that students overwhelmingly prefer to read printed books. Eric Frank has a wonderfully pragmatic view:

Publishers need to be device-agnostic in the broadest sense. The printed book is one of the devices we target.

As and when students indicate a preference for ebook formats, Flat World will provide them. It does seem that ebook readers are on the cusp of mainstream adoption. But it has seemed that way before. “It would be tragic,” Eric says, “to bet your business on that.”

The bet that Flat World is making is on a neutral format, Docbook XML, from which any other format can be automatically derived. I’ve done a lot of my own publishing to multiple formats from a single source. Back in 2003, when XML support was added to Microsoft Word — which was and is the tool of choice for book-length writing — I thought it would end the painful process of converting Word manuscripts into published formats. That mostly hasn’t happened yet. Jon Williams thinks that’s because, until recently, publishers didn’t need to automate the production of various electronic formats. As that need arises, we should finally begin to see end-to-end automation from original manuscript to published formats.

Flat World is a commercial publisher of open textbooks, and Eric is careful to spell out what he means by open. It doesn’t simply mean free, or collaborative, although there are both free and collaborative ways to use Flat World books. It means precisely what the by-nc-sa license says: You are free to use, share, and remix, with attribution, but not for commercial gain. Whenever a work yields commercial value, in any of the ways it might, that money must flow back to Flat World and its stable of authors.

The dominant revenue stream is print-on-demand. If Flat World is able to scale out its catalog — and that’s the biggest if the company faces — its printed textbooks will be an affordable alternative to conventional offerings. Meanwhile, teachers who adopt Flat World books can adapt them to their needs. In theory, a Flat World book can become a nexus of collaboration, grow more valuable as a result, convert some of that value into revenue, and share that revenue with a community of collaborators as well as with the publisher and author. It’s early days, and that hasn’t happened yet. But I like the way that Flat World has opened a door to that possibility, without betting its business on lots of people walking through it anytime soon.

Why the Maya used a 260-day calendar

Last night I attended a lecture by Vincent Malmström who, in 1973, published a paper in Science proposing an answer to the mysterious (and still controversial) question: Why did the Maya use a 260-day calendar?

Malmström’s 1997 book Cycles of the Sun, Mysteries of the Moon, which he has also made freely available here, tells the whole story from his point of view. It’s a remarkable tale of geography, religion, culture, computation, science, and human foibles.

The Maya actually used three different calendars. The Tzolk’in ran on a 260-day cycle, and the Haab’ used a 365-day cycle. Then there was the Long Count, which counted days since a mythical beginning of time and also included the other two.

The Long Count’s start date was written, in its full form, like this:

0.0.0.0.0, 4 Ahau 8, Cumku

The first five digits measure days in units of 144,000, 7,200, 360, 20, and 1. 4 Ahau is a Tzolk’in day, based on a cycle of 13 numbers with a cycle of 20 days names. 8 Cumku is a Haab’ day, based on 18 20-day months.

Today’s date is 12.19.17.2.3, which Wikipedia’s Long Count page helpfully computes for you using this markup:

Today, {{CURRENTDATE}}, in the Long Count is {{Maya date}} (GMT correlation)

(Here GMT doesn’t stand for Greenwhich Mean Time, but rather for Goodman-Martinez-Thompson.)

But today might be 12.19.17.2.2, according to this calculator. There has, evidently, been epic confusion and controversy about whether the mythical start date was 584,283 or 584,284 or 584,285 days ago. Thompson originally thought 584,285, then changed his mind and decided on 584,283.

Prof. Malmström likes 584,285, which fixes the start date as August 13, 3114 B.C. Why? Thompson didn’t think there was any astronomical basis for the 260-day calendar, but Malmström figured there had to have been. And he wondered where, in that part of the world, you might observe a 260-day astronomical cycle.

It turns out that at latitude 14.8 º N, the sun is directly overhead on August 13 passing southward, and again on April 30 passing northward, an interval of 260 days. August 13 is also the day after the peak of the Perseid meteor shower. Malmström writes:

The signs were therefore unmistakable. First the heavens would give their notice. All night long the skygazer would watch as stars burst from behind the towering mountains to the northeast and flashed across the sky. And the following morning, as the sun arched higher and higher across the heavens, he would watch as the shadow it cast grew steadily shorter, until, as the sun reached its zenith, its shadow completely disappeared. This then, he decided, was the day for his count to begin.

Why count days? If you’re planting maize, you need to calibrate carefully to the arrival of the monsoon rains. The two solar passages correspond roughly to the beginning of the rainy season at the end of April, and the harvest in mid-August.

Note that these passages, and the associated latitude 14.8 º N, don’t apply to the Maya in the Yucatán Peninsula, but instead to an earlier Olmec civilization to the southwest, on the Pacific coast near what is now the border between Mexico and Guatemala. The Mayan new year was July 26, not August 13. But the 260-day calendar predated the Mayans by a millenium.

Just a few decades after its inception, the 260-day “sacred” calendar was augmented by a 365-day “secular” calendar. The problem was that the sacred calendar didn’t quite work. There were 13 20-day cycles — or 20 13-day cycles — during the sun’s southward passage, and what seemed like 8 more 13-day cycles during the northward passage. So when the calendar started running, things seemed to work out — albeit in a delightfully curious way.

Each time the zenithal sun passed overhead on its way south, a new 260-day cycle would begin on a day numbered “1” but with a different name. Thus, the skygazer watched as the beginning of each successive cycle shifted from “1 Alligator” to “1 Snake” to “1 Water” to “1 Reed” and then to “1 Earthquake.”

That didn’t last long, though.

Where the priest had erred, of course, was in concluding that the cycle of the sun could be measured in 28 “bundles” of 13 days. This meant that he had equated its annual migration through the heavens with an interval of 364 days, when in actuality it took about a day and a quarter longer than that. Thus, after only four years had elapsed his count was already off by 5 days. This might go unnoticed by the commoners at first, but certainly, as the error increased with each passing year, it wouldn’t be long before “the cat was out of the bag.”

What a colossal screwup! I like to imagine the priests furiously backpedaling.

OK, wait, I know we said 260, but it’s really 365, but we’ll keep both, don’t worry, it’ll work out, trust us, we know what we’re doing.

Of course the fun never stops. We’re less than two years away from Y 13.0.0.0.0. That’s in 2012, on Dec 23. Or on Dec 22, or Dec 21, depending on which correlation constant you choose. On one of those dates the world will end. Or not. Prof. Malmström suggests you choose 584,285. That’ll give you two extra days to put your affairs in order.


For more on the endlessly weird human reckoning of time, see A literay appreciation of the Olson/Zoneinfo/tz database.

Visualizing the names of your Twitter lists

A while ago I asked the Lazy Web for a service that would produce a tag cloud of the names of the lists on which a Twitter user appears. Mine, for example, would look like this:

The Lazy Web seems not to have taken up the challenge, so I took a crack at it. The solution I came up with is a single-page application, which is just a web page that uses HTML, CSS, and Ajax to do something that’s (hopefully) interesting and useful.

Here’s the page: http://jonudell.net/NamesOfTwitterListsFor.html

It defaults to my Twitter name but you’ll of course want to try yours, and those of others you’re curious about. The first time through, you’ll be prompted to authenticate to api.twitter.com. This looks like the password anti-pattern, but really isn’t. You’re authenticating yourself to the Twitter API in the same way that you normally do to the Twitter website.

Note that since the API call used to build the tag cloud is rate-limited, queries through this page will be charged against your daily allotment of Twitter API usage, just as when you use client applications like TweetDeck or Seesmic.

What will your tag cloud say about you? I don’t think you’ll be surprised. It’s just another of the unique signatures written for us by others. That those signatures do get written, though, and that they can be discovered and read, never ceases to surprise me.

The dynamics of single-page applications also never cease to surprise me. In this case, a tiny 4K web page is all that’s delivered from my modestly-equipped personal webserver. It would probably survive a Slashdotting. If not, the page could be hosted on any other server, or on a other local drive, and would continue to work the same way.

I’m also using jQuery, in this case served from the Microsoft content delivery network, so that’s unlikely to be a bottleneck. The only real limit is Twitter API usage, and that’s spread across all the Twitter users who authenticate through the page.

When you arrange and deploy a tiny amount of HTML, CSS, and JavaScript in this way, you can create a lot of leverage!

Uses of pattern language in the urban century

I’ve long been familiar with the idea of software patterns. But I didn’t connect it to its roots in the architectural writings of Christopher Alexander until I recently listened to Kent Beck’s keynote at the 2008 Rails conference. Kent was deeply influenced by The Timeless Way of Building. That book wasn’t available in my local library. But the companion volume, A Pattern Language: Towns, Buildings, Construction, was. It’s been a revelation to read it for the first time, more than thirty years after it was published, through lenses formed by my experience with software and networks.

Here’s how A Pattern Language summarizes a pattern called FOUR-STORY LIMIT:

Therefore, in any urban area, no matter how dense, keep the majority of buildings four stories high or less.

And here’s how the Portland Pattern Repository summarizes the Singleton Pattern:

Therefore, let the class create and manage the single instance of itself, the Singleton. Wherever in the system you need access to this single instance, query the class.

The stylistic allusion shows a direct literary influence flowing from architectural pattern language to software pattern language. Alexander’s book, by the way, is a pre-Web hypertext. The pattern called FOUR-STORY LIMIT (21), for example, refers to NUMBER OF STORIES (96), DENSITY RINGS (29), BUILDING COMPLEX (95), HOUSING HILL (39), and HIGH PLACES (62). Each of these numbered patterns links to a set of related patterns, as does each page in the Portland Pattern Repository — which was also, of course, the Ur-wiki from which all things wiki are descended.

I suspect we’ve yet to fully elaborate the connections between software, architecture, and networks. Consider these pattern names from Alexander’s 1977 book:

THE DISTRIBUTION OF TOWNS
WEB OF PUBLIC TRANSPORTATION
NETWORK OF LEARNING
WEB OF SHOPPING
ACTIVITY NODES
NECKLACE OF COMMUNITY PROJECTS
CONNECTED PLAY
NETWORK OF PATHS AND CARS
CIRCULATION REALMS

These evocative names, and the sketches that accompany them, arise from a deeply network-oriented way of thinking. Many of the higher-level patterns express core values about connectivity and decentralization. And those values resonate more powerfully now, in our Net-aware world of 2010, than they might have in 1977.

Some of the prescriptions in A Pattern Language can seem absurd. For example, Alexander argues that an optimal urban core should serve a “catch basin” of about 300,000 people, that these cores should be widely distributed, and that each should specialize in some way that makes it world-class. Why?

The problem is clear. On the one hand people will only expend so much effort to get goods and services and attend cultural events, even the very best ones. On the other hand, real variety and choice can only occur where there is concentrated, centralized activity; and when the concentration and centralization becomes too great, then people are no longer willing to take the time to go to it.

Which is fine in theory, but we’ve already built megalopolises surrounded by suburbs. It’s not like we can do it over.

Except when we can. In America the most striking examples are in Michigan where I lived for many years. Detroit, once a city of two million, is being recreated as a city that may end up at less than a third that size. What will become of the rest? It just might be plowed into farmland. If so, a pattern called CITY COUNTRY FINGERS may turn out to be a useful guide.

Likewise there are plans afoot to gather the remaining population of Flint into a few viable neighborhoods and let the vacated land become parks and forests. If that happens, many of the ideas in A Pattern Language, about how to organize neighborhoods and their transportation networks, could come into play.

In Asia, meanwhile, entire new cities are being built from scratch. I recently met an engineer who works for the global consulting firm Arup. For one of their projects, he told me they’re using a simulation of wind flow as one of the constraints on the layout of streets and buildings. The layout is also informed by RING ROADS and LOCAL TRANSPORT AREAS, patterns that yield a tiered distribution network which optimizes the use of delivery trucks.

Networked software is highly malleable, and we take for granted that we can try out different design patterns. The built environment rarely affords the same opportunity. But in this century of urbanization, as circumstances force us to rethink our energy, transportation, and settlement networks, it may turn out to be softer than we suppose, and more open to the influence of pattern languages.

Shiny new uses for familiar old things

Last year I applied for a grant from a philanthropic group, the Knight Foundation, that wants to save journalism by funding the development of new technological methods. I was conflicted about applying because the project I put forward is already well supported by my employer, Microsoft. But since my proposal was to redistribute all of the grant, as a way of exploring an idea about improving the flow of information in communities, I thought it was fair to give it a shot.

My proposal advanced to the final round and was then rejected. Given my initial ambivalence I was OK with that. But the stated rationale has been bugging me ever since. The letter said:

Because there are thousands of proposals and only a few of them advance, we are able to choose only the most innovative ideas. These are new kinds of technologies or techniques, usually things we have never heard of before.

The meme woven into that paragraph has a name: Shiny New Thing syndrome. It is a plague. Technology journalism feeds it. Thought leaders, including Dave Slusher, Jeremy Zawodny, and Jeff Atwood, have denounced it.

I’m clearly biased, since all my best work involves creative remixing of ideas and technologies that are as common as dirt. But I do wonder about the harm that’s done when we equate innovation with shiny new things.

Old things are full of latent value that we’ve yet to discover and unlock. Why? It takes a long time for real understanding to sink in. In Net infrastructure, consider how long it’s taken us to grok what HTTP, REST, HTML, and JavaScript really are and can do. In education, look at the high-value uses that Sal Khan and Dan Meyer find for low-tech screencasting and blogging tools. In journalism and civic life, read what Alan Rusbridger says about Will Perrin’s compelling — and yet so last-century — use of Typepad to activate communities.

Well, I try to do my part. On my show, which is called Interviews with Innovators, I feature people who are more likely to be evolutionary repurposers than revolutionary creators. Maybe I should rename the show Shiny Old Things.

Producing and consuming OData feeds: An end-to-end example

Having waxed theoretical about the Open Data Protocol (OData), it’s time to make things more concrete. I’ve been adding instrumentation to monitor the health and performance of my elmcity service. Now I’m using OData to feed the telemetry into Excel. It makes a nice end-to-end example, so let’s unpack it.

Data capture

The web and worker roles in my Azure service take periodic snapshots of a set of Windows performance counters, and store those to an Azure table. Although I could be using the recently-released Azure diagnostics API, I’d already come up with my own approach. I keep a list of the counters I want to measure in another Azure table, shown here in Cerebrata‘s viewer/editor:

When you query an Azure table like this one, the records come back packaged as content elements within Atom entries:

[sourcecode language=”xml”]
<entry m:etag="W/datetime’2010-02-09T00:00:53.7164253Z’">
<id>http://elmcity.table.core.windows.net/monitor(PartitionKey=’ProcessMonitor&#8217;,
RowKey=’634012704503641218′)</id>
<content type="application/xml">
<m:properties>
<d:PartitionKey>ProcessMonitor</d:PartitionKey>
<d:RowKey>634012704503641218</d:RowKey>
<d:HostName>RD00155D317B3F</d:HostName>
<d:ProcName>WaWorkerHost</d:ProcName>
<d:mem_available_mbytes m:type="Edm.Double">1320</d:mem_available_mbytes>
…snip…
<d:tcp_connections_established m:type="Edm.Double">24</d:tcp_connections_established>
</m:properties>
</content>
</entry>
[/sourcecode]

This isn’t immediately obvious if you use the storage client libary that comes with the Azure SDK, which wraps an ADO.NET Data Services abstraction around the Azure table service. But if you peek under the covers using a tool like Eric Lawrence’s astonishingly capable Fiddler, you’ll see nothing but Atom entries. In order to get direct access to them, I don’t actually use the storage client library in the SDK, but instead use an alternate interface that exposes the underlying HTTP/REST machinery.

Exposing data services

If the Azure table service did not require special authentication, it would itself be an OData service that you could point any OData-aware client at. To fetch recent entries from my table of snapshots, for example, you could use this URL in any browser:

GET http://elmcity.table.core.windows.net/monitor?$filter=Timestamp+gt+datetime’2010-02-08&#8242;

(A table named ‘monitor’ is where the telemetry data are stored.)

The table service does require authentication, though, so in order to export data feeds I’m creating wrappers around selected queries. Until recently, I’ve always packaged the query response as a .NET List of Dictionaries. A record in an Azure table maps nicely to a Dictionary. Both are flexible bags of name/value pairs, and a Dictionary is easily consumed from both C# and IronPython.

To enable OData services I just added an alternate method that returns the raw response from an Azure table query. Then I extended the public namespace of my service, adding a /odata mapping that accepts URL parameters for the name of a table, and for the text of a query. I’m doing this in ASP.NET MVC, but there’s nothing special about the technique. If you were working in, say, Rails or Django, it would be just the same. You’d map out a piece of public namespace, and wire it to a parameterized service that returns Atom feeds.

Discovering data services

An OData-aware client can use an Atom service document to find out what feeds are available from a provider. The one I’m using looks kind of like this:

[sourcecode language=”xml”]
<?xml version=’1.0′ encoding=’utf-8′ standalone=’yes’?>
<service xmlns:atom=’http://www.w3.org/2005/Atom&#8217;
xmlns:app=’http://www.w3.org/2007/app&#8217; xmlns=’http://www.w3.org/2007/app’&gt;
<workspace>
<atom:title>elmcity odata feeds</atom:title>
<collection href=’http://elmcity.cloudapp.net/odata?table=monitor&hours_ago=48′&gt;
<atom:title>recent monitor data (web and worker roles)</atom:title>
</collection>
<collection href="http://elmcity.cloudapp.net/odata?table=monitor&hours_ago=48&amp;
query=ProcName eq ‘WaWebHost’">
<atom:title>recent monitor data (web roles)</atom:title>
</collection>
<collection href="http://elmcity.cloudapp.net/odata?table=monitor&hours_ago=48&amp;
query=ProcName eq ‘WaWorkerHost’">
<atom:title>recent monitor data (worker roles)</atom:title>
</collection>
<collection href="http://elmcity.cloudapp.net/odata?table=counters"&gt;
<atom:title>peformance counters</atom:title>
</collection>
</workspace>
</service>
[/sourcecode]

PowerPivot is an Excel add-in that knows about this stuff. Here’s a picture of PowerPivot discovering those feeds:

It’s straightforward for any application or service, written in any language, running in any environment, to enable this kind of discovery.

Using data services

In my case, PowerPivot — which is an add-in that brings some nice business intelligence capability to Excel — makes a good consumer of my data services. Here are some charts that slice my service’s request execution times in a couple of different ways:

Again, it’s straightforward for any application or service, written in any language, running in any environment, to do this kind of thing. It’s all just Atom feeds with data-describing payloads. There’s nothing special about it, which is the whole point. If things pan out as I hope, we’ll have a cornucopia of OData feeds — from our banks, from our Internet service providers, from our governments, and from every other source that currently publishes data on paper, or in less useful electronic formats like PDF and HTML. And we’ll have a variety of OData clients, on mobile devices and on our desktops and in the cloud, that enable us to work with those data feeds.

Listen, talk, breathe

Linda Stone, coiner of the marvelous phrase continuous partial attention, has lately been exploring another modern pathology she calls email apnea, which means failure to breathe while checking email. In retrospect, we shouldn’t be surprised. Look:

  • The new 25-payline special edition of Wheel of Wealth will have you holding your breath in excitement…

  • Play Online Slot Machine Game. Coin in – spin – hold your breath……Watch those symbols…..Will it or won’t it?

  • After the first two hits you’re holding your breath for the third reel…

We don’t talk about slot-machine apnea but it’s the same syndrome, produced by the same cause: an intermittent, or variable-interval, schedule of reinforcement. Any activity that exhibits this pattern will be powerfully addictive. A dog begging for scraps of food at the table, rewarded only once in a thousand times, will always beg. Likewise a human begging for scraps of attention.

The link between variable-interval reinforcement and email addiction is well known. Less studied is how this plays out in other modes of electronic discourse. The architecture of those modes introduces another key variable: attention payoff. In a group-structured system, like email or Facebook, the payoff is bounded by group size. It’s true that email messages can escape and go viral, but when that happens the attention payoff is never the kind you want.

But in open pub/sub systems, like blogs or Twitter, the payoff is unlimited. Any item that you post could attract worldwide attention, boost your reputation, land you a job, or make a key personal or professional connection. However there’s no guarantee that you’ll get any reinforcement at all. So some fall by the wayside, others become addicted.

“Technology is here to stay,” Linda says. “Can our relationship to it change?”

It must, it can, and it will. But we’ll need to develop some intuitions about global scale and connectedness for which evolution did not prepare us. And then we’ll need to translate them back down to the human scale. Evolution has taught us how to be social. Technology amplifies our ability to give and receive attention, but it doesn’t change the rules of the game. There’s a time to listen, a time to talk, a time to breathe. We’ll remember, and we’ll figure it out.

Talking with Sal Khan about YouTube tutoring as guerilla public service

My guest for this week’s Innovators show is Sal Khan. He’s the creator of http://khanacademy.org, a catalog of more than 1000 YouTube video lessons in math, physics, biology, chemistry, and economics. All of these videos are made by Sal himself, in an engagingly personal style, using simple screencasting tools.

When I first got interested in screencasting, I envisioned the medium not only as a way to demonstrate software, but also as a way to share knowledge at Internet scale. Sal’s work fulfills that vision, and points the way toward a profound and much-needed disruption of our educational system.

At its core, Sal’s project isn’t about YouTube screencasts. It’s about intuition.

I always got frustrated by what went on in the classroom. You see otherwise intelligent peers memorizing facts and not really caring about the actual intuition. And because they didn’t care about the intution in their junior year, when that same idea pops up in senior year, it’s like they’ve never seen it before. It boggled my mind. You’re just relabeling the same concept over and over.

Sal cares about the intuition, and he wants others to care about the intution too. The first beneficiary of that desire was his cousin Nadia, whom he tutored remotely. Then followed other cousins and family friends. Then it dawned on him that there were no limits. The project could scale out. He could become a superempowered individual, reaching anyone who finds value in his method.

One of the key ingredients of that method is improvisation. These videos aren’t carefully planned, and they aren’t edited. As a viewer, you find yourself looking over the shoulder of a smart and broadly knowledgeable person who is solving problems by thinking on his feet. You watch a practitioner at work: engaged with his medium, wrestling with his tools, correcting false starts.

It was Chris Gemignani who first showed me the value of this approach, in a screencast that teaches how to do unexpectedly powerful and elegant Excel charting. He did it in one take. I’d have been tempted to edit out the false starts. But Chris knew better. Learning how a practitioner really thinks about solving a problem is even more valuable than learning the solution to the problem.

One thing that Sal’s lessons can’t be, of course, is interactive. Nor does he pretend that these videos will make teachers obsolete. But he does suggest, and I violently agree, that teachers can and should become curators of online assets like the ones Sal is creating, and should know when and how to weave those assets into their classes.

Teachers should also become connectors. Sal won’t be the only game in town. Other superempowered tutors will emerge. Each will have a unique style. For a given student, a given subject, and a given problem, one or another of those styles may be right. The best teachers will know their own strengths and limitations, will know which online tutors complement their strengths in a variety of ways, and will connect their students with those tutors.

Sal Khan is on fire. He burns with a passion to share his intuitions with anyone and everyone. It is a beautiful thing to see. He has abandoned a lucrative career in finance to do this fulltime, and I am quite sure he will find a way to keep doing it.


PS: The title of this piece refers to Richard Ankrom’s Los Angeles freeway project. At a busy intersection, millions of motorists have been directed to North 5 by a sign that Caltrans omitted. Ankrom created and installed that missing sign.

PPS: I wrote to my son’s math teacher about Sal Khan. She replied: “Thanks for that link to the Khan Academy. I was overwhelmed by how many video lessons he has! He does seem like an inspiring man. Unfortunately, You Tube is blocked here at the high school.”