The lore on how to prepare for these talks also has roots that connect Mark Fowler’s 2004 Giving Lightning talks to Jason Grigsby’s 2008 How to Give a Successful Ignite Presentation to many others more recently. Everyone agrees: practice. But how?

For mine I wrote a script in 20 stanzas and then set about tuning them to the required intervals. My first thought was to refer to a clock while reading the script aloud and editing it, but it was hard for me to look back and forth between the clock and the script. So I made a couple of audio tracks for timing. countdown-slide.mp3 says “3, 2, 1, slide” and then every fifteen seconds, “slide” again, finishing with “end.” countdown-5-10-slide.mp3 adds “five” and “10″ at the appropriate intervals. Both turned out to be helpful in different ways.

For tuning the written script to the intervals, I used the countdown-5-10-slide track which gave me plenty of cues to help gauge the edits. For practicing the script I used the countdown-slide track which emits exactly the stream of cues you get in the talk: start, a cue every 15 seconds, then stop.

As is often appropriate for an Ignite talk my slides were mainly pictures not words. I tried to search for and use only images licensed for sharing, but the discoverable pool of such images isn’t nearly broad or deep enough. So I fell back to grabbing images from Google and Bing searches, feeling guilty about that, and wondering what it will take to make the pool a lot broader and deeper.

I wasn’t sure at first I’d need the countdown-slide track — the one that just says “slide” every 15 seconds. If you practice and memorize the script while watching the slides then you’ve got your cues, no need for audio timing. But after a few run-throughs I got antsy and wanted to go for a hike. That’s where the countdown-slide track really worked, in a couple of ways. It not only provided the cues, it prompted me to visualize the slides. From then on I could practice anywhere I wouldn’t mind being seen talking to myself: running, hiking, driving to the airport. I hardly used the slides again.

When I did use the slides, in a few practice runs and then in the talk, I saw how helpful it had been to have visualized them, but not seen them, while practicing. I’d learned to do the talk from memory without the slides. Doing it with them was, by comparision, easier.

This makes perfect sense, of course. I think it’s related to how musicians memorize music: hear the tune, see the notes on the page, feel your fingers on the instrument. Then selectively omit the audio track, the sheet music, and even the instrument, and do the hearing, seeing, and feeling in your mind.

A couple of weeks later I was on a panel where I had up to 10 minutes to speak. I wound up using only 4 minutes, and while there weren’t any slides, I still wrote it out as a story told in memorizable stanzas. I think it turned out better than if I’d used the whole time for something less tightly constructed.

The 4-minute panel talk turned out to be harder to learn than the 5-minute Ignite talk, and now I see why. Even though slides weren’t required, I could have used them as practice cues! I guess that’s what Joshua Foer and other memory experts keep telling us: divide things into chunks, tag the chunks with pictures.

[1] The subject was barefoot running. I think it’ll be posted soon.

It got there by way of a new technique I just added to elmcity’s repertoire. Until now, the only way to syndicate events from Facebook through an elmcity hub was the one described here. In that scenario a curator asks an elmcity hub to search Facebook for public events in the hub’s location. This hasn’t worked well. If you use Facebook’s API to search for public events using the term Keene, NH you’ll find events, but only ones that include Keene, NH in the event’s title. Events that mention Keene, NH in the location field are oddly missing.

So until now, if you wanted to use Facebook to promote a public event in Keene, you had to use Keene, NH in the title to get it to work. Being married to me, Luann knows to do that, and her event was already appearing in the hub. But for most people this sort of hack will (and should) be a non-starter.

Even if Facebook’s API worked the way I’d expect, and could find public events by location rather than just by name, it’s not really the right thing. The elmcity model puts event owners in charge of data feeds that hubs (and other consumers) access at specified URLs. It’s nice to know that your public events in Facebook can be found via search. But if you want to syndicate those events through a hub you’d rather publish an explicit feed URL.

It turns out that you can, but in an odd way that requires some explaining and raises important questions about the evolving landscape of online identity. The new elmcity technique relies on the Export link at the bottom of Facebook’s Events page. The label, Export, connotes private use of the iCalendar feed behind that link. The feed is primarily for Facebook users who want to sync their Facebook Events pages to their personal calendars. When you click the link, you’re shown an URL like this:

webcal://www.facebook.com/ical/u.php?uid=652….115&key=AQD…qcT

If you change webcal to http you’ve got one of those special sharing URLs that are public, in the sense that they live on the open web, but also private, in the sense that they’re not discoverable. You wouldn’t use this kind of URL for anything really sensitive. But it can be appropriate for calendars, or friends-and-family photo galleries, or other cases where security-by-obscurity is a reasonable tradeoff.

Syndicating Facebook events

When I fetched the URL for Luann’s Facebook events, by way of her Export link, I had an iCalendar feed that was a mixed bag. It included events to which Luann had been invited by friends; those events were marked private. It also included the event that Luann was promoting; that one was marked public. Ideally Facebook would provide a separate URL for just Luann’s (or any Facebook user’s) public events. There would be nothing secret about that URL, it could be shared freely on the open web.

Lacking such an URL from Facebook, elmcity has to synthesize it. To do so, it filters the private feed to include only events that meet two criteria:

1. They belong to the Facebook user, not to a Facebook friend of that user.

2. They are marked public.

Here are the iCalendar properties that enable such filtering:

ORGANIZER;CN=Luann Udell:MAILTO:luann@luannudell.com
CLASS:PUBLIC

In this example, when I excluded everything in Facebook’s iCalendar feed that wasn’t organized by Luann, and wasn’t public, I was left with a feed containing just one event: Luann’s art opening. That’s the feed I wanted to tell the Keene hub to subscribe to.

My first thought was to use the normal elmcity mechanism for subscribing a hub to calendar feeds. The hub’s curator bookmarks the feed in a designated Delicious account. In this case, there would need to be an extra bit of metadata to enable the hub to filter the feed properly. It could easily find events marked PUBLIC. But how would it know to find Luann’s public events? For that it would need the name of a Facebook user, in this case Luann’s name.

At first blush that seemed easy to solve. The elmcity service uses Delicious tags to convey metadata to hubs. I could define a new convention like so:

The combination of the trusted and ics and feed tags is the normal way a curator tells a hub that the bookmarked URL is an iCalendar feed that the hub should try to process. The who=Luann+Udell tag would be extra metadata telling the hub to restrict a Facebook calendar feed to only the events organized by the named Facebook user.

Problem solved? Unfortunately no. Do you see why not? This mechanism leaks private information. Although the elmcity hub isn’t going to publish anything other than Luann’s public event, her Facebook feed also contains a private event from Judy. Anyone who scans the feeds for the Keene hub would see the unfiltered URL and could find Judy’s private event.

If the architecture of elmcity were more typical, this wouldn’t be a problem. Curators would create accounts at elmcity, they’d log into those accounts to add feeds, the lists of feeds subscribed to by hubs would be hidden from the world. But elmcity does things differently. Hubs are transparent conduits through which public information flows. They reveal their sources. Nothing needs to be hidden, and so nothing is hidden. Curators do their work out in the open. Communities served by elmcity hubs can see how those hubs are constituted.

If Facebook provided a Publish link for public events, along with an Export link for all events, then it could participate directly in elmcity-style calendar syndication. Since Facebook doesn’t offer a Publish link, elmcity needs to receive the Export link from curators by way of some private channel of communication.

Syndicating Facebook events privately

If the architecture of elmcity were more typical, curators would have accounts at elmcity and would use those accounts to send private messages to the service. But again, elmcity does things differently. You shouldn’t have to create an account for everything under the sun. You already have plenty of perfectly good accounts. Why not reuse them?

The relationship between elmcity and Delicious is one example of such reuse. A curator creates a new elmcity hub by designating a Delicious account to control it. If the administrator of the elmcity service deems the proposed new hub legitimate, he or she (so far, just me) tells the service to use that Delicious account to specify the hub’s settings and list its feed URLs.

There’s an analogous relationship between elmcity and Twitter. If a hub’s Delicious settings name a curator’s Twitter account, then Twitter becomes a channel for private messages between the curator and the hub. For example, a curator can send a Twitter direct message to the hub that simply says: start. When the hub receives the start message, it immediately refreshes all the hub’s feeds instead of waiting for the next scheduled refresh.

Until recently that was the only control message that a curator could send to a hub. But now there’s another: add_fb_feed. From my Twitter account I just sent a direct message to the elmcity service’s Twitter account. The message said:

add_fb_feed id=652...115 key=AQD...qcT who=Luann+Udell category=art

Which means the following:

1. Make this Facebook iCalendar URL: http://www.facebook.com/ical/u.php?uid=652….115&key=AQD…qcT

2. Restrict it to public events organized by Luann Udell

3. Use art as the tag for events in this feed

The hub read that message and responded:

elmcity received your add_fb_feed command

And then:

facebook feed successfully added

This isn’t ideal. Curators still need to trust the elmcity service not to disclose URLs sent through the private Twitter channel. Such disclosure could happen in any of the following ways:

• The operator of the elmcity service gives up the data on purpose. I wouldn’t, of course, but it’s theoretically possible.

• The elmcity service gives up the data accidentally. It’s just software; mistakes happen.

• A curator gives up the data either accidentally or on purpose. This risk exists because the elmcity service only has trust relationships with curators. They, in turn, have trust relationships with the contributors who provide calendar feed URLs. Contributors who want to use Facebook as a source for public events that flow through an elmcity hub will give their Export URLs to curators. And curators, accidentally or on purpose, could leak those URLs.

This post is already too long, so I’ll say elsewhere why I think you probably shouldn’t use Facebook as the authoritative source for public events that you want to promote. But if you understand the mechanism I’ve explained here, and if you think the risk/reward tradeoff is acceptable, then you’re welcome to use it. If you’re an elmcity curator who has designated a Twitter account for private communication with the service, here’s the new command you can send to add a Facebook feed from one of your contributors:

add_fb_feed id=UID key=KEY who=USER [category=CATEGORY]

Usage is as follows:

add_fb_feed is a required verb

id=UID is a required parameter. Replace UID with the xxx from uid=xxx in your Facebook Export URL

key=KEY is a required parameter. Replace KEY with the yyy from key=yyy in your Facebook Export URL

who=USER is a required parameter. Replace USER with your Facebook name, using + instead of the space character.

category=CATEGORY is an optional parameter. You can use a single term or a comma-separated list of terms. These will appear as tags on each event flowing from the feed through the hub.

If you send a bogus or missing command verb, or id, or key, you’ll get a Twitter message describing what went wrong.

Consider the physics of things in the real world. As hominids we have a million years of experience with the properties and behavior of physical things. And as individuals we have lifetimes of such experience. Based on those experiences, here are some things we know:

• If I give you a thing then it’s yours until you give it back. We can’t both use it.

• If I want to make a collection of things, I get a bucket and put things into it. A thing is either in the bucket or it isn’t. The same thing can’t be in two buckets at the same time.

• If I invite you to work on a project using my collection of things, you have to visit my house.

In the virtual dimension none of these laws apply.

• I can give you a link to a thing, and we can both use it. If either of us improves it, we both share the improvement.

• If I want to make a collection of things, I can invent a tag that identifies things in a collection. We can invent many tags for many collections. A thing can be in more than one collection.

• If I invite you to work on a project using my collection of things, you can join me in a virtual place.

As we begin to colonize the virtual dimension, we begin to learn about the physics of virtual things. But we still haven’t fully internalized the laws and properties that govern them. All of us, digital natives included, still tend to treat virtual things as if they were physical things.

Making and sharing collections of things is a common scenario that illustrates the tension between these two different sets of laws. When the things are physical objects — say, coins — there’s no choice about how to collect them.

Scenario 1: Somebody passes around a bucket, people toss coins into the bucket, whoever holds the bucket has the coins.

But when the things are virtual objects — say, chunks of information, existing as web resources, identified by URLs — there is a choice. Somebody can still pass around a virtual bucket, people can still toss virtual coins into it, and whoever holds the virtual bucket will have access to the collection of coins. That’s exactly what happens when we use an email conversation as the virtual bucket. Or:

Scenario 2: We can invent a name for a virtual bucket, and toss web resources into it by tagging them with that name. Now anyone who searches for the tag will have access to the collection of resources.

This new scenario raises important questions. How do we choose a name for the collection? How do we choose a service that binds the name to things in the collection? How do we restrict access to the collection? On what terms are these name-binding and access-control services provided to us?

I can’t answer all these questions at once, so let’s start with the most fundamental one: How can we name things?

In A tale of two dams I made up a tag, WestStDamKeene, that could be used by anyone to co-ordinate web resources related to an ongoing conversation in my city about the fate of the Ashuelot River dam on West Street. The tag is 14 characters long. With 14 characters you can make quite a lot of names. If each character can be a letter or a digit, then there are 36 choices for each character — 26 letters plus 10 digits. There are 36¹⁴ strings of 14 such characters. When faced with big numbers like that I turn to my favorite scientific calculator, WolframAlpha. It evaluates the number like so:

In a recent talk I failed (spectacularly) to convey the point I’m about to make, so I’ll try it again and more carefully here. We can make about as many 14-character tags as there are grains of sand on Earth. True, a lot of those won’t be nice mnemonic names like WestStDamKeene, instead they’ll look like good strong unguessable passwords. But there are still unimaginably many mnemonic names to be found in this vast namespace. Each of those can serve as a virtual bucket that we can use to make and share collections of arbitrarily many web resources.

The implications take a while to sink in. Grains of sand are inert physical objects. They just lie around; we can’t do much with them. But names can be activated. I can create a 14-character name today — actually I just did: WestStDamKeene — that won’t be found if you search for it today on Google or Bing. But soon you will be able to find at least one hit for the term. At first the essay I’m now typing will be the only hit from among the 30 billion indexed by Google and 11 billion indexed by Bing. But if others use the same term in documents they post to the web, then those documents will join this one to form a WestStDamKeene cluster.

This isn’t even tagging in the conventional sense. Set aside, for now, the clusters that can form around that tag on Delicious, or on WordPress, or on Flickr, or on Twitter, or even at the intersection of all those tag-oriented services. Consider only what can happen when you make up a never-before-seen term, utter it in a document placed on the web, and invite others to utter it in documents that they place on the web. When we enact this scenario we are, in effect, creating an ad hoc web service that we can use to make and share collections of things related to (in this case) a particular dam project in a particular town. Of course tag-oriented services enhance our ability to make and share such collections. But even without them we can still do it. In the realm of virtual things, names are as plentiful as grains of sand. But they aren’t inert. We can wake them up and use them to co-ordinate our activities.

Yeah, but how impressive? And, even more interesting to me, how can we find data to help answer the question? Perhaps with a sequence of searches like so:

“1-foot sunflower”

“2-foot sunflower”

…etc…

“26-foot sunflower”

“27-foot sunflower”

These are parallel searches of Google and Bing for “[1..27]-foot sunflower”. Here are the resulting counts, with Bing scaled up by a factor of 100 to make the trends comparable:

So, maybe my near-11-footer isn’t so special after all. This method of finding out is interesting, though. It seems incredibly naive. If you try those queries you’ll find all sorts of stuff that isn’t relevant to what I mean by an n-foot sunflower. But if the amount of irrelevance is constant across the range, it factors out, right? And the two independent search engines make this a controlled experiment.

I wonder how well this proxy for sunflower height distribution correlates with the actual distribution. Of course there are a million other questions you could try to answer this way. It’d be easy to make a web app to automate this method. I lazily hope somebody already has, or will, so I don’t have to.

PS: My sunflowers are actually a second crop. The first one had a crazy head start, because we had freaky warm weather in February. But then in early April, when they were already 3 feet high, the chickens broke into the enclosure and demolished them. What lofty heights could my sunflowers have reached this summer? We’ll never know.

PPS: Here’s the data:

1,2,0
2,994,10
3,8,4
4,10,4
5,9,4
6,3270,37
7,74,11
8,135,12
9,176,11
10,1690,39
11,75,9
12,472,37
13,82,12
14,220,8
15,54,9
16,9,4
17,2,1
18,55,4
19,6,2
20,119,8
21,0,0
22,2,0
23,0,0
24,8,3
25,891,2
26,3,2
27,0,0

I figured this would enable two ways to find pages, like my blog post, that refer to agenda items, like Tom’s request. First, you could search for pages that mention the hashtag. For example, this combined search of Google and Bing for granicus732_7716 finds my blog post because it mentions that tag. These searches also find my tweet containing the tag, and some echoes of the tweet. Finally, of course, you could search Twitter directly for the tag.

A second approach would be to search for pages that link to the video segment. I expected to be able to find my blog post by searching for this permalink which it cites:

http://keene.granicus.com/MediaPlayer.php?view_id=2&clip_id=77&meta_id=7716

I planned to use the link: operator, which finds pages pointing to an URL. And I figured this would work for both Google and Bing. But I was wrong on several counts. Bing doesn’t seem to support the link: operator. And even though Google does, this query doesn’t find my blog post.

Using the permalink as a plain search term doesn’t work either. And after reviewing the advanced search operators for both Google and Bing, I’m left wondering: How do you find pages that cite a permalink?

Until April 30, your choices when publishing an event were:

Some people opted for Closed when they really ought to have picked Secret. With the advent of API-based search that meant automated tools like the elmcity aggregator could surface events — like surprise birthday parties — not meant to be seen.

But on May 1 the choices had narrowed to just public or private. It’s implemented as a checkbox:

[x] Anyone can view and RSVP (public event)

It defaults to checked, i.e. public. That’s consistent with the general tilt, in Facebook, toward public rather than private defaults. Many people think that’s the wrong default, and I’m inclined to agree. But at least a confusing three-valued choice has been reduced to an easier-to-understand two-valued choice.

Given that, I’ve decided to add Facebook as an elmcity event source. I’m mindful of the power of defaults, so haven’t made this a default behavior. When a curator spins up a new elmcity hub, the event sources included by default — that is, before you add any iCalendar feeds to your registry — were, and still are, Eventful, Upcoming, and EventBrite. If you want to add Facebook events, you can now do so by adding a new name/value pair to your hub’s metadata record in delicious:

facebook=yes

Curators can, by the way, now include or exclude any of the services. These are the defaults:

eventful=yes
upcoming=yes
eventbrite=yes
facebook=no

All of these settings can be tweaked.

The elmcity service finds Facebook events by searching for them using the location you specify in your metadata record. Here are some sample searches:

If you change the location parameter in that URL you can see which Facebook events will be included for your town. So far, I’m not seeing many public events, even for very populous locations. Facebook’s event system was always more appropriate for friends-and-family events that you wouldn’t expect to see on a community calendar. If you wanted to advertise an event open to the general public, services like Eventful or Upcoming or EventBrite were better ways to do it. Or you can create a public iCalendar feed.

It will be interesting to see if Facebook’s new event system, which defaults to public, produces more public events than before. To the extent that it does, it could become a useful source for elmcity curators. But if people who create public events in Facebook want that to happen, they’ll need to learn more about those events appear in other contexts.

Consider this event, one of a handful that turns up in a search for Keene, NH. Here’s what anyone can see in Facebook:

What film is being screened? Neither the title nor the description tells us. My guess is that if you know Susan Hay, and are affiliated with mothersuniting.org, that information is part of a shared context that Susan just took for granted when she posted this “public” Facebook event. When she marked the event Public it hadn’t occurred to her that the actual scope of Public means she ought to have named the film in the title or description.

Note that there is an events page at mothersuniting.org, albeit five years behind the times. My own view is that mothersuniting.org should be the authoritative source for its own event information. It could use Google Calendar, for example, to publish an HTML view of a calendar into the events page on its website, while at the same time producing an iCalendar feed that could be listed in a community registry. Facebook really ought to be a downstream consumer of that kind of event source, not an upstream producer.

But no matter what I think, there will be people, maybe a lot of people, who end up making Facebook the authoritative source for their event information, instead of their own websites. So I’m enabling curators to capture those streams. We’ll see how it unfolds. As always, it’ll be fascinating to watch people walk the slippery path that divides private from public.

PS: If you’re a developer working with the new events API, here’s an odd quirk I’ve uncovered. Dates and times reported through the Facebook API don’t correlate sensibly with dates and times reported in the Facebook application.

At first I thought this was a timezone issue, and tried various Ptolemaic adjustments to make things work out. It got weirder and weirder, until finally I went empirical and made this table of observations:

    Where: Keene: GMT-5
 FB start: 2010-05-09 19:00
API start: 2010-05-10 02:00
     Diff: +7 hours

http://www.facebook.com/event.php?eid=113825365318937

    Where: Chicago: GMT-6
 FB start: 2010-05-01 11:00
API start: 2010-05-02 06:00
     Diff: +7 hours

http://www.facebook.com/event.php?eid=114150548619789

    Where: Salt Lake City: GMT-7
 FB start: 2010-04-28 06:00
API start: 2010-04-28 13:00
     Diff: +7 hours  

http://www.facebook.com/event.php?eid=115044215191908

    Where: Fresno: GMT-8
 FB start: 2010-05-03 11:00
API start: 2010-05-03 18:00
     Diff: +7 hours

For no reason I can see, the API reports a local time that’s 7 hours ahead of the time you see when you view the event in Facebook. After making that adjustment, things seem to work. Why 7 hours? Beats me.

At first glance, it seems doable. Here are some sample queries:

http://elmcity.info/fb_events?location=keene,nh

http://elmcity.info/fb_events?location=ann arbor, mi

http://elmcity.info/fb_events?location=portsmouth,nh

You can see what turns up for your town by swapping in your city and state. A lot of the events are public and could reasonably be included in a citywide aggregation. But then there are ones like this:

SURPRISE Lantheaume Baby Shower
1000 Market Street, Portsmouth, NH 03801
2010-06-26T20:00:00+0000

Clearly this baby shower should not appear on a citywide public calendar. Why does search find it? Let’s look at the data about this event that’s visible to the world:

{ “id”: “314667046847″,
“owner”: {
“name”: “Jesse Barnes”,
“id”: “11000551″},
“name”: “SURPRISE Lantheaume Baby Shower”,
“description”: “Baby \”Ox\” is on his or her way! Come and celebrate with the mom-to-be and her closest friends and family! Please remember to bring your decorated onesie so that we can display them for Kris. \n\nLook on this site for additional details that are still being determined. “,
“start_time”: “2010-06-26T20:00:00+0000″,
“end_time”: “2010-06-26T23:00:00+0000″,
“location”: “1000 Market Street, Portsmouth, NH 03801″,
“privacy”: “CLOSED”,
“updated_time”: “2010-04-02T15:01:10+0000″}

When you create a private event, there are three options:

Open: Anyone can see this Event and its content.

Closed: Anyone can see this Event, but its content is only shown to guests.

Secret: Only people who are invited can see this Event and its content.

Clearly Jesse should have marked this event Secret, not Closed. Until very recently, an error like that would be unlikely to result in an embarrassing information leak. But now things have changed, and people are going to start learning harsh lessons about the visibility of their Facebook stuff.

I don’t see any way to teach my service to exclude events that people marked as Closed because they thought it meant Secret. So I guess elmcity’s Facebook feature is going to have to wait until those lessons are learned.

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!

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.

In this case, the half-dozen largest awards aren’t described:

award	amount	funding agency	recipient	description
EE00161	2,601,788		Sothwestern Community Services Inc
S394A090030	1,471,540		Keene School District
AIP #3-33-SBGP-06-2009	1,298,500		City of Keene
2W-33000209-0	1,129,608		City of Keene
2F-96102301-0	666,379		City of Keene
2F-96102301-0	655,395		City of Keene
0901NHCOS2	600,930		Sothwestern Community Services Inc
2009RKWX0608	459,850	Department of Justice	KEENE, CITY OF	The COPS Hiring Recovery Program (CHRP) provides funding directly to law enforcement agencies to hire and/or rehire career law enforcement officers in an effort to create and preserve jobs, and to increase their community policing capacity and crime prevention efforts.
NH36S01050109	413,394	Department of Housing and Urban Development	KEENE HOUSING AUTHORITY	ARRA Capital Fund Grant. Replacement of roofing, siding, and repair of exterior storage sheds on 29 public housing units at a family complex

That got me wondering: Where does the money go? So I built a little app that explores ARRA awards for any city or town: http://elmcity.cloudapp.net/arra. For most places, it seems, the ratio of awards with descriptions to awards without isn’t quite so bad. In the case of Philadelphia, for example, “only” 27% of the dollars awarded ($280 million!) are not described.

But even when the description field is filled in, how much does that tell us about what’s actually being done with the money? We can’t expect to find that information in a spreadsheet at recovery.gov. The knowledge is held collectively by the many people who are involved in the projects funded by these awards.

If we want to materialize a view of that collective knowledge, the ARRA data provides a useful starting point. Every award is identified by an award number. These are, effectively, webscale identifiers — that is, more-or-less unique tags we could use to collate newspaper articles, blog entries, tweets, or any other online chatter about awards.

To promote this idea, the app reports award numbers as search strings. In Keene, for example, the school district got an award for $1.47 million. The award number is S394A090030. If you search for that you’ll find nothing but a link back to a recovery.gov page entitled Where is the Money Going?

Recovery.gov can’t bootstrap itself out of this circular trap. But if we use the tags that it has helpfully provided, we might be able to find out a lot more about where the money is going.

First, Southwest Airlines. I had booked a round-trip flight and then needed to change to one-way. You can’t do that online. So I clenched my jaw, called customer service, and prepared for the long wait.

Instead, this:

IVR: “Would you like us to call you back in about 20 minutes?”

Me: “Why…yes! Beep, beep, beep, beep, beep, beep, beep, #.”

My jaw relaxed.

Twenty or so minutes later, an agent called back and we made the change. Now the unclenched jaw morphed into a smile.

Second, FindTape.com. I’m making interior storm windows and I need double-stick tape for the project. Which, sure, you can buy online. But the smorgasbord of choices is paralyzing. I wasted a half-hour trying to figure out which product would best suit my unusual application and made no progress whatsoever.

Then, at FindTape.com, I read this:

If you have a specific question related to which tape would work best in your application please fill out and submit the following fields so that we can have an appropriate representative get back in contact with you.

A fellow named Kevin wrote back, we’ve have been discussing my options, and now I’m ready to buy.

Both examples remind me of Michael Nielsen’s luminous phrase: the restructuring of expert attention. He coined it to define a new era of scientific collaboration, but it applies more broadly.

We’ve been told that companies can’t afford to focus expert attention on customers. The truth, of course, is that they can’t afford not to.

For a generation and more we’ve driven a wedge between people who have expertise with products and services and people who need that expertise. How’s that working for you? Me neither.

It’s true that expert attention is a scarce resource. But we’re living through a Cambrian explosion of awareness networks and communication modes. Used adroitly, they can optimize the allocation of that scarce resource. Which is a fancy way of saying: Maybe personal customer service isn’t a lost art after all.

Admittedly that sounded a lot more exciting prior to 2006, when the BBC ended its trial of the Creative Archive service that was expected to “open the floodgates” to a “treasure trove” of cultural riches. Ian Forrester says those expectations were ratcheted back for two reasons. First, much of that treasure trove remains undigitized. Second, rights clearance proved to be an intractable problem.

So the “our stuff” that’s available to build “your stuff” turns out to be mostly metadata: news headlines, program titles and schedules. What’s more, that metadata comes from a plethora of BBC content management systems. What can you make out of these ingredients?

Here’s an evocative example: http://www.bbc.co.uk/nature/species/African_Bush_Elephant. The BBC’s Tom Scott explains:

Over the last few months we’ve been plundering the NHU’s [Natural History Unit's] archive to find the best bits — segmenting the TV programmes, tagging them (with DBpedia terms) and then aggregating them around URIs for the key concepts within the natural history domain; so that you can discover those programme segments via both the originating programme and via concepts within the natural history domain — species, habitats, adaptations and the like.

This is just the sort of remixing that Backstage ought to enable anyone, inside or outside the BBC, to achieve. Since I’m a US resident, and don’t pay the UK’s television license fee, I can’t watch the videos on that page. There’s nothing that the Backstage team can do about that. But they can take a radically open and inclusive approach to the management of the metadata that supports this remixing, and that’s just what they’re doing.

In our conversation, Ian Forrester describes how the taxonomy that governs the Backstage feeds and APIs is shared with that of Wikipedia and its structured derivative, DBpedia. Tom Scott elaborates:

You might have noticed that the slugs for our URIs (the last bit of the URL) are the same as those used by Wikipedia and DBpedia that’s because I believe in the simple joy of webscale identifiers, you will also see that much like the BBC’s music site we are transcluding the introductory text from Wikipedia to provide background information for most things. This also means that we are creating and editing Wikipedia articles where they need improving (of course you are also more than welcome to improve upon the articles).

As someone who both practices and preaches collaborative curation, I’m delighted to see the BBC taking this approach. And I love the phrase webscale identifier. Here’s how Michael Smethurst defines it, in the post pointed to by Tom Scott:

I agree with the four Linked Data rules but I’d like to try to add a fifth: if possible don’t reinvent other people’s web identifiers. By web identifiers I mean those fragments of URLs that uniquely identify a resource within a domain. So in the case of the MusicBrainz entry for The Fall (http://musicbrainz.org/artist/d5da1841-9bc8-4813-9f89-11098090148e.html) that’ll be d5da1841-9bc8-4813-9f89-11098090148e.

The last time we updated the /music site we made this mistake (kind of unavoidable at the time). Even though we linked our data to MusicBrainz we minted new identifiers for artists. So The Fall became http://www.bbc.co.uk/music/artist/jb9x/ where jb9x was the identifier. But jb9x doesn’t exist anywhere outside of /music. We’ll (hopefully) never make that mistake again.

Beautifully said. Enormous synergies have gone unrealized because web publishers have chosen to mint new namespaces rather than add value to existing ones.

What I realized when talking with Ian, though, is that there is one namespace for which the BBC is the appropriate mint, namely its own. Here, for example, are some of the family of URLs for a radio drama called The Archers:

homepage: http://www.bbc.co.uk/programmes/b006qpgr/

upcoming shows: http://www.bbc.co.uk/programmes/b006qpgr/episodes/upcoming.xml

In this example b006qpgr is, at least potentially, a webscale identifier. It’s a unique tag for the show that, if used on blogs, on Twitter, and elsewhere, would make it easy to assemble all kinds of online activity related to the show. But in fact only web developers using Backstage feeds and APIs will ever discover, or use, b006qpgr. In colloquial discourse people use The Archers.

If the BBC wants people to collaborate with its namespace in the same way that it collaborates with Wikipedia’s, this would be more inviting:

http://www.bbc.co.uk/programmes/The_Archers/

http://www.bbc.co.uk/programmes/The_Archers/episodes/upcoming.xml

It should go without saying, but right after the first rule for linked data, “Use URIs as names for things,” I would add “Where possible, choose names that make sense to people.”

Dear Mr. Udell,

I am looking for a flexible calendar aggregator that I can use to report upcoming events for our college’s “Learning Commons” WordPress MU website, a site that will hopefully help keep our students abreast of events and opportunities taking place on campus.

1) Our site will be maintained using WordPress MU, so ideally the
display of the calendars, and/or event-lists will be handled by a
WordPress plugin. The one I am favouring is
http://wordpress.org/extend/plugins/wordpress-ics-importer/ . I have
tried this plugin and it almost does what we want.

Specifically, the plugin includes:

– a single widget that can display the “event-list” for one calendar;

– flexible options for displaying and aggregating calendars.

This plugin almost does what I want, but not quite.

a) The plugin is now limited to a single “events-list” widget. But with WordPress 2.8, it is possible to have many instances of a widget, so theoretically, I could display the “Diagnostic Tests” calendar in one instance , and the “Peer-tutoring” calendar in another widget instance.

b) It would be nice to have an option to display only the current week for specific calendars. While in other cases, it makes sense to display the entire month. And although I haven’t thought about it, likely displaying just the current day would be useful.

c) I would like flexibility over which calendars to aggregate, creating as many “topic” hubs as the current maintainer of the website might think useful for the students.

2) It would be nice to remove the calendar aggregation from the WordPress plugin, and handle that separately. Hopefully the calendars will change much less frequently than the website will be viewed. If I understand http://blog.jonudell.net/elmcity-project-faq/ properly, this might be possible using the elmcity-project.

For example, I think we could use “topical hub aggregation” to create a “diagnostic test calendar” that aggregates the holiday calendar and the different departments “diagnostic test” calendars. What I don’t understand is what is the output of “elmcity”. Does it output a single merged calendar (ics) that could be displayed by the above plugin? Is that a possibility?

Similarly, I believe I could create a different meta bookmark to aggregate our holiday calendar and our different peer-tutoring calendars (created by each department). Is this correct?

We have lots of groups, faculty, departments and staff on campus, and each wants to publicize their upcoming events. Letting them input and maintain their own calendars really seems to make sense. (Thanks for the idea. It seems clear this is the way to go, but I don’t seem to have the pieces to construct the output properly, as yet.)

I agree with your analysis that it would be better to have a separation of concerns between aggregation and display. So let’s do that, and start with aggregation.

I would like flexibility over which calendars to aggregate, creating as many “topic” hubs as the current maintainer of the website might think useful for the students.

I think the elmcity system can be helpful here. I’ve recently discovered that there are really two levels — what I’ve started to call curation and meta-curation.

I believe I could create bookmarks to aggregate our holiday calendar and our different peer-tutoring calendars (created by each department). Is this correct?

Right. It sounds like you’d want to curate a topic hub. It could be YourCollege, but if there may need to be other topic hubs you could choose a more specific name, like YourCollegeLearningCommons. That’d be your Delicious account name, and you’d be the “meta-curator” in this scenario.

As meta-curator you’d bookmark, in that Delicious account:

- Your holiday calendar

- Multiple departments’ calendars

Each of those would be managed by the responsible/authoritative person, using any software (Outlook, Google, Apple, Drupal, Notes, Live, etc.) that can publish an ICS feed.

There’s another level of flexibility using tags. In the above scenario, as meta-curator you could tag your holiday feed as holiday, and your LearningCommons feeds as LearningCommons, and then filter them accordingly.

What I don’t understand is what is the output of elmcity. Does it output a single merged calendar (ics) that could be displayed by the above plugin?

Yes. The outputs currently are:

• A merged ICS file

• A default HTML view that can be included in an iframe (e.g.: http://elmcity.info/events includes http://elmcity.cloudapp.net/services/elmcity/html). If that solution works for you, the template and CSS for the view can be altered, and you can point to your versions from your Delicious metadata

• A Today view (e.g. http://elmcity.cloudapp.net/services/elmcity/today_as_html) that can be included (in an iframe, or programmatically)

• The same Today view using JavaScript: <script src=”http://elmcity.cloudapp.net/services/{a2cal|elmcity|etc}/jswidget”></script>

• XML and JSON data for programmatic use

Now, for the display options. So far, we’ve got:

• Use the WordPress plugin to display merged ICS

• Display the entire calendar as included (maybe customized) HTML

• Display today’s events as included or script-sourced HTML

• I have also just recently added a new method that enables things like this: http://jonudell.net/test/upcoming-widget.html

You can view the source to see how it’s done. The “API call” here is:

http://elmcity.cloudapp.net/services/elmcity/json?jsonp=eventlist&recent=7&view=music

Yours might be:

http://elmcity.cloudapp.net/services/YourCollegeLearningCommons/json?jsonp=eventlist&recent=10

or

&recent=20&view=holiday

etc.

This is brand new, as of yesterday. Actually I just realized I should use “upcoming” instead of “recent” so I’ll go and change that now :-) But you get the idea.

The flexibility here is ultimately governed by:

1. The curator’s expressive and disciplined use of tags to create useful views

2. The kinds of queries I make available through the API. So far I’ve only been asked to do ‘next N events’ so that’s what I did yesterday. But my intention is to support every kind of query that’s feasible, and that people ask for. Things like a week’s worth, or a week’s worth in a category, are obvious next steps.


]]> http://blog.jonudell.net/2009/08/15/elmcity-and-wordpress-mu-questions-and-answers/feed/ 1 jonudell http://blog.jonudell.net/2009/06/18/its-the-headings-stupid/ http://blog.jonudell.net/2009/06/18/its-the-headings-stupid/#comments Thu, 18 Jun 2009 13:37:07 +0000 Jon Udell http://blog.jonudell.net/?p=1741 ]]> My recent adventure in naming the times of day was so much fun that I lost track of the original purpose of the exercise, which was to improve accessibility for sight-impaired users.

When I interpersed time-of-day labels into each day’s event listing, I used HTML DIV tags. Wrong, wrong, wrong! Those labels are structural elements, and as my accessibility consultant Susan Gerhart gently reminded me, screen readers depend on HTML headings to find and announce them. The labels should have been second-level headings — i.e., HTML H2 tags.

It gets worse. When Susan prompted me to take another look at what I’d done, I found that the date labels were inexplicably tagged as paragraphs (P) instead of the top-level headers (H1) that they logically are.

Oh. Right. Of course. Duh. Fixed. Sorry.

What was I thinking? How could somebody like me, who has preached about the attention-focusing power of heads, decks, and leads, screw up something so basic as this?

Easily, as it turns out, in the absence of feedback. If you yourself don’t depend on a design feature, there is a natural tendency to forget why it matters to others.

Coincidentally (or not) Susan recently wrote an essay, and published a companion audio recording, that will help me — and I hope others — not to forget again. Entitled Hear Me Stumble Around White House, Recovery, and Data GOV web sites, it’s a blow-by-blow account of her efforts to navigate those sites with a screen reader.

In this recording you can hear Susan and her screen reader trying to make sense of whitehouse.gov. If you’ve never heard a screen reader in action, it’s worth listening for that alone. You’ll get a very clear sense of how these tools depend on the hierarchy of the page.

Simultaneously you’ll hear Susan narrate her intention — to read an article about cybersecurity — and her frustration. For example:

I was thrown off by the slide show at the top of the page. Once I hit the cybersecurity story, the next time I traverse this section the story was about the Supreme Court nominee.

Despite this randomness, the page does at least identify the top stories with H1 tags. And Signed Legislation is an H2. But none of the headlines under Signed Legislation are H3s, they’re Ps.

Over at recovery.gov and data.gov Susan finds none at all, and reacts to their omissions less gently she did to mine:

It’s the headings, stupid!!!

Thanks. I will try not to forget that again.

---

PS: In a follow-up to her blog essay, Susan links to detailed reports by accessibility pioneer Jim Thatcher on the issues he found with data.gov and recovery.gov.


]]> http://blog.jonudell.net/2009/06/18/its-the-headings-stupid/feed/ 1 jonudell http://blog.jonudell.net/2009/06/15/when-does-afternoon-begin/ http://blog.jonudell.net/2009/06/15/when-does-afternoon-begin/#comments Mon, 15 Jun 2009 20:44:10 +0000 Jon Udell http://blog.jonudell.net/?p=1728 ]]> When I invited folks to become calendar curators for the elmcity project, the person who stepped forward in Prescott AZ was Susan Gerhart, whom I interviewed here. One of her great insights about web design is that the right thing for a vision-impaired user is almost always also the right thing for everyone. She calls this the curb cuts principle:

Curb cuts for wheelchairs also guide blind persons into street crossings and prevent accidents for baby strollers, bicyclists, skateboarders, and inattentive walkers.

So I shouldn’t have been surprised when Susan noticed that the HTML rendering of the calendar need some curb cuts. Within each day, the events show up as a long undifferentiated list. She suggested that subdividing the list by time of day — morning, afternoon, evening — will be helpful to folks using screen readers. But in fact, it’s just plain helpful. So I’m testing a version of that idea now.

Ionically I was just thinking about this same principle in another context. The new version of Oakland Crimespotting, which I raved about, segments incidents using this vocabulary:

light, dark, commute, nightlife, day, night, swing shift

In that spirit, I’m trying this:

morning, lunch, afternoon, evening, night

This of course leads to the question: When do these times begin and end?

I was fascinated to see that both Google and Bing return the same Yahoo answers page for the query morning afternoon evening.

For now, though, I’m going with this ruleset:

  Morning:  5:00 AM to 11:30 AM
    Lunch: 11:30 AM to  1:00 PM
Afternoon:  1:30 PM to  5:30 PM
  Evening:  5:30 PM to  9:00 PM
   Night:   9:00 PM to  5:00 AM

But I’ll make these rules — and maybe even the time-of-day names — configurable on a per-location basis.


]]> http://blog.jonudell.net/2009/06/15/when-does-afternoon-begin/feed/ 8 jonudell