Jon Udell

Every Christmas we watch It’s a Wonderful Life. This year I’ll be imagining Jimmy Stewart saying, to a panicked crowd of delicious.com users rushing for the exits, “Now, hold on, it’ll work out, we’ve just got to stick together.”

If you’ve never used the social bookmarking service that began life with the whimsical domain name del.icio.us, here’s the Wikipedia summary. The service began in 2003, and by 2004 had transformed my work practices more profoundly than almost anything else before or since. I’ve written scores of essays explaining how and why. Here are some of my favorites:

2004: Collaborative knowledge gardening

2005: Language evolution with del.icio.us (screencast)

2005: Collaborative filtering with del.icio.us

2006: Del.icio.us is a database

2007: Discovering and teaching principles of information management

2007: Social information management

2008: Twine, del.icio.us, and event-driven service integration

2008: Databasing trusted feeds with del.icio.us

2008: Why and how to blurb your social bookmarks

2009: Collaborative curation as a service

Since the now-infamous leak of an internal Yahoo! slide naming delicious as one of a set of doomed services, there’s been some great gallows humor. Ed Kohler:

The easiest way to shut down Wikileaks would be to have Yahoo! acquire it.

And Anil Dash:

It seems like @pinboardIN is the most successful product Yahoo!’s had a hand in launching in five years. Congrats, @baconmeteor.

Anil is referring to pinboard.in, one of several delicious-like services to which delicious users began fleeing. Pinboard is notable for a clever model in which the price of a lifetime subscription rises with the number of users. When I first checked yesterday morning, that price was $6.90. I signed up at $7.24. Neil Saunders started tracking it at #pinboardwatch; it got to $7.74 last night; it’s $8.17 now. Maybe I should’ve bought 100 accounts at $6.90!

But seriously, this is a moment to reflect on how we can preserve the value we collectively create online. As some of you know, I have made heavy use of delicious in my own service, elmcity. When the news broke, Jeremy Dunck asked: “Bad news for elmcity, huh?”

Actually that’s the least of my worries. The folks who curate elmcity calendar hubs use delicious to configure their hubs, and to list the feeds aggregated by their hubs. It’ll be a bit inconvenient to transition to another bookmarking service, but it’s no big deal. And of course all the existing data is cached in an Azure database; the elmcity service doesn’t depend on live access to delicious.

The real concern is far broader. Millions of us have used delicious to create named sets of online resources. We can recreate our individual collections in other services, but not our collaborative efforts. In Delicious’s Data Policy is Like Setting a Museum on Fire, Marshall Kirkpatrick writes:

One community of non-profit technologists has been bookmarking links with the tag “NPTech” for years – they have 24,028 links categorized as relevant for organizations seeking to change the world and peoples’ lives using technology. Wouldn’t it be good to have that body of data, metadata and curated resources available elsewhere once Delicious is gone?

The problem with “elsewhere,” of course, is that there’s no elsewhere immune to the same business challenges faced by Yahoo!. Maybe now is the time for a new model to emerge. Except it wouldn’t be new at all. The Building and Loan service that George Bailey ran in It’s a Wonderful Life wasn’t a bank, it was a coop, and its customers were shareholders. Could delicious become the first user-owned Internet service? Could we users collectively make Yahoo! an offer, buy in as shareholders, and run the service ourselves?

It’s bound to happen sooner or later. My top Christmas wish: delicious goes first.

A non-profit organization chartered to promote arts and culture within its community will be curating a new elmcity hub. The curator plans to invite dozens of member organizations to contribute to the hub — that is, to manage their public schedules using calendar applications, and to convey the URLs of their calendar feeds to the hub. It’s critical that these member organizations will be able to easily accomplish this task. I’ve been pointing to a series of how-to articles but it was time to make the instructions clearer and simpler. It was also time to revisit how to use screencasting to explain step-by-step procedures.

I started with the two web applications that make publishing calendar feeds as simple as it can be: Google Calendar and Hotmail Calendar. Here’s the new and improved explanation of How to publish a calendar feed from Google Calendar or Hotmail Calendar. I’ll soon learn how well this new explanation works for the intended audience. Meanwhile, here are some notes on the techniques I discovered.

Using sparkcasts

My earlier explanations didn’t use screencasts, they were just textual narrations with embedded static screenshots. That’s an appropriate way to explain step-by-step procedures. Screencasts can be overkill.

But it is nice to be able to show motion and sequential flow. I wondered: if sparklines are “intense word-sized graphics” that appear inline with text, is there a similarly lightweight way to use screencasts? Well, that’s how this explanation works. The steps are all written as text. Each step comes with a Watch! link that opens a quick little inline screencast.

Using Firebug to prepare screencasts

As I mentioned the other day, Firebug is an amazing tool for making mockups based on live web pages. And sometimes you can do more than just take screenshots of those mockups. Sometimes you can interact with them.

I used that method to temporarily alter both Google Calendar and Hotmail Calendar for these sparkcasts. In my case, both include several private calendars that were irrelevant to my explanation. Using Firebug I was able to remove them. I also made the address shown in Gmail look like the generic YourAccountName@gmail.com instead of judell@gmail.com. If subsequent interaction with the page doesn’t trigger a refresh of these altered elements, the changes will persist. Handy!

Using Camtasia to make animated GIFs

A movie-style screencast is a fairly heavy object, and it would be cumbersome to embed lots of these on a page. Animated GIFs are lighter. And it turns out that Camtasia can produce that format. Nice!

Using jQuery to reload animated GIFs

On the first try, I made each sparkcast loop forever, and used jQuery to show only the current one. But that wasn’t ideal. What I really wanted was for each sparkcast to play once when shown, then stop and offer a Replay link. If you view the source of this page, you’ll see the solution I came up with. It turns out that when you dynamically reload an animated GIF, you need to decorate its URL in a unique way; otherwise the browser won’t replay it.

Using Image Magick to control the looping of animated GIFs

Once I figured out how to replay a play-once GIF, I had to make all the GIFs stop looping. I’m sure that PhotoShop and others of its ilk can do that, but I like Image Magick’s ability to automate repetitive tasks. The Image Magick incantation to make an animated GIF play once goes like this:

mogrify -loop 1 howto-01.gif

Now that I’ve written this down, I can forget it until I need it again!

Eric von Hippel’s book Democratizing Innovation rang all sorts of bells for me back in 2005. I cited it in a couple of InfoWorld columns and continue to cite it in blog posts. Here’s how I originally summarized the book:

MIT’s Eric von Hippel notes that users of products and services — and by users he means both individuals and companies — often innovate on their own rather than relying on manufacturers to do it for them. And not just in the realm of IT; a survey of employees in 74 pipe-hanger installation companies found that 36 percent developed or modified pipe-hanger hardware for their own use.

There’s no mystery why this should be. In general, we all share the same needs, but specific requirements vary in ways that motivate a shift from mass production to mass customization. The question is how to do mass customization economically.

Von Hippel advances the notion of user innovation toolkits. The Apache Web server, with its modular architecture, is an example of such a toolkit. In the hands of skilled programmers, Apache can be, and often is, tailored to specific needs. When such customizations are shared, other users benefit. But so do Apache’s developers, who, by observing what’s done with the toolkit, can more intelligently evolve the core product.

I’m always on the lookout for user innovation toolkits, and what brings me back to the topic today is this analysis of the design of Google’s and Bing’s maps (/via @gnat). It includes a stunning animated gif that flips between the Google and Bing renderings of the northeast U.S.

Justin O’Bierne’s question was: “Why Do Google Maps City Labels Seem Much More “Readable” Than Those of Its Competitors?” It’s a fascinating and, in my non-expert judgement, a very plausible analysis. When I watch the two sample images in rapid alternation, though, I’m struck by the way in which each seems more readable than the other in certain ways. I can imagine a mixing board with knobs for a bunch of textual, graphic, and layout parameters. By twiddling the knobs I could combine what I like best about each of these two samples. Of course I’m not a designer. If you are a designer, you’ll say that I’m being naive, that design isn’t knob-twiddling, it’s a holistic exercise. And you’ll be right. When everyone can twiddle all the knobs, disasters can ensue. I’ve created a few of my own.

Still, if we can democratize the knob-twiddling, we should. User innovation toolkits can’t guarantee good outcomes, but they can open up the design process to experiments that might sometimes work.

In that vein, I want to draw attention to an interesting use of Firebug. If you’re a web developer you know about this excellent tool. If you’re not you probably don’t, but you might want to remember what I’m about to say. It turns out that Firebug can enable an armchair web designer, perhaps with minimal knowledge of HTML and CSS, to prototype in-situ alternate versions of live web pages.

I discovered this because I wanted to be able to show how the elmcity event viewing widget might look as a replacement for the existing widget on the events page of various web sites. I formerly did this kind of thing in two ways. One was to drop an image of the new element onto an image of the existing page. The other was to save the page, edit its HTML and CSS, and snapshot the result. For all sorts of reasons, both of these methods were flawed and, more importantly, inacessible to anybody without a ton of web development experience.

Then I realized that Firebug enables a better way. Clearly I’m late to the party. I’m sure most web developers have known about this technique for a long. But I’ll bet a lot of people who aren’t web developers would want to use it from time to time too, if they knew how. So, here’s the drill.

Let’s say that I want to show the Keene Sentinel how the elmcity widget would appear on the Sentinel’s calendar page. Here’s the existing page:

I position the cursor on the calendar element, and inspect it:

Now I can see that the element I want to replace is <div id="calendar">. So I click its parent, <div id="inside-page">, inspect it, click Firebug’s Edit button, and remove everything inside that tag:

Edit button??!! Who knew? Many of you, I guess, but not me until recently. Anyway, to complete the task I follow the instructions for how to stick an elmcity viewer widget into a page:

Done! Here’s what the Keene Sentinel’s calendar page would look like if it used the elmcity widget:

Firebug isn’t just a great tool for developers. It’s also a user innovation toolkit that can enable anyone to try out an alternate version of a live web page.

I’d like to thank the folks at the Berkman Center for listening to my talk yesterday, and for feedback that was skeptical about the very points I know that I need to sharpen. The talk is available here in multiple audio and video formats. The slides are separately available on SlideShare. There are many ways to use these materials. If I wanted to listen and watch, here are the methods I’d choose. For a tethered experience I’d download the original PowerPoint deck from SlideShare and watch it along with the MP3 audio. For an untethered experience I’d look at the slides first, and then dump the MP3 onto a portable player and head out for a run. Finally, if I lacked the time or inclination for either of those modes, but was still curious about the talk, I’d read Ethan Zuckerman’s excellent write-up.

After the talk we had a stimulating discussion that raised questions some of us have been kicking around forever in the blogosphere:

1. Do “real people” — that is, people who do not self-identify as geeks — actually use feed syndication?

2. If not directly and intentionally, do they use it indirectly and unconsciously by way of systems that syndicate feeds without drawing attention to the concept?

3. Does the concept matter?

The third question is the big one for me. From the moment that the blogosphere booted up, I thought that pub/sub syndication — formerly a topic of interest only to engineers of networked information systems — was now becoming a tool that everyone would want to master in order to actively engage with networked information systems. Mastering the principles of pub/sub syndication wasn’t like mastering the principles of automotive technology in order to drive a car. It was, instead, like knowing how to steer the car — a form of knowledge that we don’t fully intuit. I have been driving for over 35 years. But there are things I never learned until we sent our kids to Skid School and participated in the training.

I’ll admit I have waffled on this. After convincing Gardner Campbell that we should expect people to know how to steer their cars on the information superhighway, I began to doubt that was possible. Maybe people don’t just need automatic transmission. Maybe they need automatic steering too. Maybe I was expecting too much.

But Gardner was unfazed by my doubt. He continued to believe that people need to learn how to steer, and he created a Skid School in order to teach them. It’s called the New Media Studies Faculty Seminar, it’s taking place at Baylor University where Gardner teaches, at partner schools, and from wherever else like minds are drawn by the tags that stitch together this distributed and syndicated conversation. Here’s Gardner reflecting on the experience:

Friday, I was scanning the blog feeds to read the HCC blogs about the discussion. Then I clicked over to some of the other sites’ blogs to see what was happening there. Oops! I was brought up short. I thought I’d clicked on a St. Lawrence University blog post. It sure looked like their site. But as I read the post, it was clear to me something had gone wrong. I was reading a description of the discussion at HCC, which had included very thoughtful inquiries into the relationship of information, knowledge, and wisdom. Then I realized that in fact I was reading a description of the HCC discussion — because that’s what they’d talked about at St. Lawrence University as well.

And now my links bear witness to that connection, tell my story of those connections, and enact them anew.

This property of the link — that it is both map and territory — is one I’ve blogged about before (a lucky blog for me, as it elicited three of my Favorite Comments Ever). But now I see something much larger coming into view. Each person enacts the network. At the same time, the network begins to represent and enact the infinities within the persons who make it up. The inside is bigger than the outside. Each part contains the whole, and also contributes to the whole.

The New Media Studies Faculty Seminar has given some educators a lesson in how to steer their own online destinies, and a Skid School course on which to practice their new skills. That pretty much sums up my ambition for the elmcity project too. Automatic transmissions are great. But we really do need to teach folks how to steer.