Jon Udell

Recently I did my first Ignite-style talk[1]. It’s an interesting format: a 5-minute 20-frame slideshow set to auto-advance every 15 seconds. The format has its roots in the 5-minute lightning talks that I remember from early Perl conferences. In lightning talks the slides were optional, you just had to finish on time or get gonged. (I can still see Larry Wall cheerfully ringing the gong on others and just as cheerfully having it rung on him.) Ignite makes slides mandatory. The 15-second cadence invites you to think in stanzas; it’s a nice constraint to embrace.

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.

Yesterday I joined a panel at the New England Conference of Public Utilities Commissioners. I was the odd man out in the group but that was the point. The organizers wanted somebody other than the Usual Suspects to bring an outside perspective to the panel. Here’s roughly what I said.

My phone bill is itemized down to the last minute and second — every call, every number. For the longest time I’ve wanted my electric bill to be itemized in the same way, right down to the watts actually used by every appliance.

How can you decide whether to replace your old fridge if you don’t know what it really costs to run it? Or how guilty should you feel, or not feel, about turning on the air conditioner in June, if you don’t have the data?

Well I’ve finally got the data, at least sort of, thanks to the smartmeter I installed recently. It’s a first-generation device; it’s a little flaky; it doesn’t track individual appliances. But it does give me realtime feedback about how many watts my house is burning.

That’s a really interesting number. When you turn off some lights, you see the difference right away, in watts and in pennies per hour. It’s a powerful behavior changer.

Around the time I was installing this thing I heard a commentary on NPR about smartmeters, The title of the piece was “Smart Meter, Big Brother,” and you can guess what it was about. Smartmeters are an unpredictable new technology, they bring unforeseen privacy risks that none of our statutes and regulations have ever thought about.

What was the guy worried about? Well, suppose you come home every night around the time the bars close. The electric company can tell because it sees your lights and appliances come on. Then somehow it leaks that data to your insurance company, which raises your premiums.

Really? I don’t know, to me there’s nothing new here. Most people I talk to have given up on privacy. They just expect that’s what would happen with your data.

Here’s what would be a new twist. Why do we just assume that a smartmeter will automatically phone its data home to the electric company? Mine doesn’t. It only feeds data to my own home computer, and from there to wherever I route it. PSNH doesn’t know anything about this. [ed: Well, I guess they do now :-)]

This reminds me of what we’ve been seeing in IT for quite a while. Consumer technologies at the edge of the network have disrupted enterprise technologies at the core, Telecom feels this disruption intensely right now. I’m wondering if other utilities, like power, will start to feel it too.

I know a guy who runs a company that does demand management for big box retailers like Michaels and Petco. He drops a package of instrumentation and controls into your store, he connects it to the web, and then when there’s a rolling brownout in California he can dial down the lights and ventilation and AC in all the buildings across his network.

He picked the retail sector because every one of those stores has the energy footprint of 20 or 30 homes. And he avoided the residential sector because it’d be a lot harder to have the same kind of impact there.

But now I’m wondering if we’re going to start to see the crowdsourcing of demand management. I’ve already got a do-it-yourself Internet-connected smartmeter. How much longer until I can add DIY controls to dim the lights or schedule the dishwasher to run off peak? And then how much longer before I can connect up with a bunch of other people who want to do the same things?

I’m not saying this will happen. But it could. And if it did, we wouldn’t need to wait for legislators and regulators to figure out how to deal with some new privacy threat, because there wouldn’t be a threat. It would just be people choosing to share their data with other people in order to conserve energy. And, by the way, they’d be having a lot of fun doing it too! Think massively multiplayer online game for the smart grid.

Now maybe I’ve told the wrong crowd about my DIY smartmeter. Maybe I’ve already broken some rule I don’t know about. But if not, or in any case, I’d like to put this crazy idea onto the table for discussion.

For me it was a chance to hang out with a bunch of public utility regulators and watch them wrestle with thorny issues. Does regulation often stifle innovation? Yes. Is regulation a means to socially just ends, like rural broadband? Yes. I found it fascinating.

Also, I got to spend an evening and a morning at the fabulous Mount Washington hotel during a perfect New Hampshire solstice.

I guess because I lost my own dad a few years ago, I was really moved by Sunday’s outpouring of Father’s Day sentiment. On Twitter, on Facebook, on blogs, everywhere you looked online you found people sharing an “I miss my dad” moment. Then today, while searching YouTube for renditions of a beautiful Hawaiian slack key guitar tune I’m learning, called Moe ‘Uhane, I found this wonderful version. And even better, this comment:

I was there when he taped this on my little tape recorder back in the 80′s. I was sleeping and woke up to find him playing still in his pj’s. Miss my dad. Thanks for representing. Sounds awesome!

- Mahina Chillingworth

Sweet! The tune came to Sonny Chillingworth in a dream, and then his dreaming daughter woke up to hear him recording it.

My latest Radar essay makes the modest proposal that Facebook might, in some cases, syndicate my data from elsewhere rather than requiring me to type it in. Most people think that’ll never happen. Paulo Eduardo Neves sums up why not:

I don’t think they have any intention to open gates in their walled garden.

Of course garden gates can work two ways. They can keep things in or out. We can all appreciate why Facebook wants to keep things in. But is it really in Facebook’s interest to keep things out? That would require Facebook to become the home for all of our photos, our calendars, and every other stream of data we create. What a burden! Why not let a decentralized internet carry some of that burden?

What’s matters most to Facebook, I should think, isn’t my photos and my calendars, but the surrounding interaction that it can uniquely enable, capture, and monetize. Couldn’t inbound syndication amplify that interaction? Dunno, just asking.

One of the great pleasures of summer in Keene, NH is our New England Collegiate Baseball League team, the Swamp Bats. I tell people that going to one of the Bats’ home games at the high school’s Alumni Field is like winding the clock back fifty years and bringing a Norman Rockwell painting to life. Fans arrive early and set up lawn chairs along the first base line. Kids run potato sack or frozen T-shirt races between innings. College players from teams around the country, some destined for the big show, remind you how sweet the little show can be.

Of course the Swamp Bats schedule should syndicate through Keene’s calendar hub. And last year it did. The Swamp Bats site was using Google Calendar, which provides an iCalendar feed, so I just added that feed to the hub.

This year there’s a new website based on the Joomla content management system. When I first looked at its rendering of the schedule, my heart sank. The iCalendar feed was gone!

On closer inspection, though, I found that it was still lurking in the background. The sites’ calendar is served up by a Joomla component called GCalendar which wraps an instance of GoogleCalendar. Why? The documentation explains:

No longer are you forced to use an i-frame and settle for a less then ideal look. Now you can integrate a Google Calendar directly into your website – using AJAX. This extension pulls directly from your Google Calendar within Google and displays it directly on your website.

Fair enough. The standard IFrame method for displaying a Google Calendar widget is, indeed, less than ideal. But in the process of wrapping the widget so that webmasters can make pages that look nicer, the iCalendar feed was left on the cutting room floor. That deprives visitors to the Swamp Bats website of the opportunity to add the Swamp Bats calendar to their personal calendar programs. It also prevents the Swamp Bats calendar from syndicating through an elmcity hub or directly to media outlets.

This omission isn’t an exception, it’s more like the rule. Web designers and builders obsess about how sites look, but typically ignore how they connect — or don’t — to the emerging web of data. As a result, I had to ferret out the hidden Google Calendar in order to connect the Swamp Bats schedule to the elmcity hub.

After some poking around I found it by viewing the source of the month view, which looks like this:

It’s not obvious, but if you click the down arrow above June 2011 a list expands:

In the HTML source for the list, two Google Calendar IDs appear:

<tr>
<td>
<input type="checkbox"
  name="5nmm1e33jj6bfo14jq9jv44p18%40group.calendar.google.com"
  value="/index.php?option=com_gcalendar&view=jsonfeed&format=raw&gcid=1&Itemid=110"
  checked="checked" onclick="updateGCalendarFrame(this)"/>
</td>
<td><font color="#6b49b0">Keene Swamp Bats</font></td>
</tr>
<tr>
<td>
<input type="checkbox"
  name="8s9qdhf61u2q3697vocm6abkg0%40group.calendar.google.com"
  value="/index.php?option=com_gcalendar&view=jsonfeed&format=raw&gcid=2&Itemid=110"
  checked="checked" onclick="updateGCalendarFrame(this)"/></td>
<td><font color="#9e8462">Keene Swamp Bats Away</font></td>
</tr>

A Google Calendar ID is an email address at the root of a family of related URLs you can use to embed the calendar’s widget on a page, or subscribe to the calendar’s public (or maybe private) feed. In this case I’m after the public feed. Here’s how you form its URL from a root email address:

http://www.google.com/calendar/ical/ + EmailAddress + /public/basic.ics

Applying the rule to the first item in the list¹ produces this iCalendar feed. I plugged its URL into the Keene hub, and now it knows that the Bats are playing the Holyoke Blue Sox tonight at Alumni Field:

I’ve also subscribed to the feed in Outlook, so I can see the games as an overlay on my personal calendar. Another Swamp Bats fan could do the same in Google Calendar, or Hotmail Calendar, or Apple iCal, or any other standard calendar program.

All’s well that ends well, I suppose, but geez, it really shouldn’t be this hard. Web designers and builders ought to think like the web. If you regard the web is an interactive experience, they do. But the web is also an ecosystem of linked data. That way of thinking has, so far, tragically failed to sink in.

Web pros! Wake up! There’s more to this game than achieving the “ideal look.” When you are working with data, please make it available as data to the people and the systems that need it.

¹ What about the second item? That calendar is empty. It seems the intent was to provide two calendars, one for home games and the other for away games. But in fact, for some reason, the first calendar has both, and the second has none.

Ernest Hebert is an author and Dartmouth professor who was born in Keene and writes fiction about this area. During an interview with the Keene Sentinel he unloaded a gorgeous rant about William Faulkner. It’ll soon vanish behind the Sentinel’s paywall. So as a public service, and to ensure I can refer to it later, I’m placing it here for safekeeping.

Q: How do you feel about being compared to William Faulkner?

A: I hate being compared to Faulkner — this kind of uppity, snooty southerner with his turgid prose based more or less on the Bible. I can’t bear to read Faulkner. It makes me want to puke. I just loathe Faulkner. And you can quote me on all of that.

Done!

My wife Luann showed her new art work at a local venue last Saturday. Here’s how the event looked in Keene’s elmcity hub:

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.