There’s a rough consensus that the heat gain attributable to man-made climate change is equivalent to about one watt per square meter. How can we visualize that? You could say it’s like we’ve added one always-on 100-watt light bulb to every ten-meter-square piece of the planet’s surface. Or you could say that we’re adding the heat equivalent of 400,000 Hiroshima bombs per day.

The Hirosohima meme is fashionable in certain circles. You can even use a blog widget or Facebook app to dramatize the effect. Is that helpful?

Yes, according to Joe Romm:

In my quarter century communicating on climate change, I’ve found that many people in the media and the public have a visceral belief that “Humans are too insignificant to affect global climate.”

The anti-science CNBC anchor Joe Kernen voiced this conviction when he suggested that “as old as the planet is” there is no way “puny, gnawing little humans” could change the climate in “70 years.”

Certainly humans do seem tiny compared to the oceans or even a superstorm like Sandy. So I don’t see anything wrong with trying to find a quantitatively accurate metaphor that puts things in perspective.

Yes, but not without context. Suppose I told you the effect was an order of magnitude smaller: 40,000 bombs per day. Or an order of magnitude larger: 4 million bombs per day. Do you have any intutions about those numbers? I don’t. And unless you’re a scientist working in this domain you don’t either.

The missing context, in this case, is the amount of solar power reaching Earth’s surface. It’s about 175 watts per square meter (1, 2). That’s a lot of Hiroshimas. But let’s focus on our representative square, ten meters on a side. That’s 100 sqare meters, roughly the footprint of an average house in Spain. How many 100-watt bulbs are we talking about?

175 W/m^2 * 100 m^2 = 17,500W

17,500W / 100W/bulb = 175 bulbs

So the baseline for our representative square is 175 bulbs. If we add one more bulb, we increase the wattage by about half of one percent. Some will intuit that the extra 175th is significant. I do. We’re adding a measurable fraction of Earth’s insolation? Whoa.

Others will intuit that it’s neglible. But will this formulation at least enable us to discuss the effect in a way that everyone can meaningfully visualize? Maybe not. Because it depends on an intuition that varying a global parameter by half a percent is a big deal. Which is like having an intution that varying the planet’s temperature by a degree or two is a big deal. Some will have it, others won’t.

I can’t imagine preventing 400,000 Hiroshimas. I would rather think about turning off every 176th light bulb. But I can’t imagine turning off 5 trillion light bulbs either. So maybe Joe Romm is right. If both visualizations are valid, and if the goal is to communicate the underlying intuition, then I suppose unfathomably many bombs says that more compellingly, to most people, than half a percent of the solar flux at Earth’s surface.

And yet: half a percent of the solar flux? Whoa. That’s a pretty useful touchstone fact.

Here’s a story that’s playing out in libraries everywhere:

Library Unveils 3D Printer

Keene residents now have access to a 3D printer allowing everyone the ability to turn the digital into the physical. A brand new MakerBot Replicator 2 is now plugged in at the Keene Public Library.

,..

Libraries are now more than repositories of books for researching but active community centers inviting people to come, make, and create things.

That’s a great mission statement, and it’s one I’ve been suggesting for a long time. But when the Keene Public Library jumps on the 3D printer bandwagon, I’m reminded of its failure to embrace other opportunities to make and create, ones much closer to the library’s core competencies.

The LibraryLookup Project was born in Keene. Our library’s online catalog was the first one I connected to Amazon’s catalog. Over the years libraries around the world adopted the technique. It evolved through several iterations, culminating in a service that alerts you when a book on your Amazon wish list is available in the local library. But one library conspicuously refused to get involved: the Keene Public Library. Why not? One objection was that the method preferentially supported Amazon. So I added support for Barnes and Noble, but the answer was still no.

Then there’s this ITConversations podcast I made with Mike Caulfield. At the time Mike lived in Keene as well, and on the appointed day things weren’t quiet enough to record in either of our homes, so we went to the library and asked to use one of the meeting rooms on the second floor, all of which were empty. The answer: No. Why? According to the rules the rooms are available only for use by “non-profit, civic, cultural, charitable and social organizations.” I pointed out that ITConversations was a non-profit. Still no. In the end we recorded in the upstairs hallway outside the forbidden room.

I don’t mean to pillory the Keene Public Library. It’s a great local library, it’s well used, visitors from towns much bigger than Keene are always impressed. And they’ve done some great work online, notably an archive of historical photos that’s now part of the Flickr commons. Why not encourage the community to engage in that kind of making and creating?

It’s not just the Keene library. At a gathering of makers and hackers last year I sat in a session on the future of libraries. The entire discussion revolved around 3D printers and maker spaces. I asked about other creative literacies: media, webmaking, curation, research. Nobody was interested. It was all about 3D printing.

Here’s my conclusion. 3D printing, and the maker movement for which it is emblematic, are memes that are being marketed with great success. So much so that Evgeny Morozov, who makes a living deflating memes, goes after them in this week’s New Yorker.

Criticism has its place, and all popular memes deserve scrutiny. But there’s no question that the maker movement has tapped into a fundamental urge. We are starting to realize that you can’t build a house, or heat it, or feed the family that lives in it, by manipulating bits. You need to lay hands on atoms. As we re-engage with the physical world we will help heal our economies and our cultures. That’s all good. But it’s not the first thing that comes to mind when libraries seek to transform themselves from centers of consumption into centers of production.

Libraries really are about bits. They are uniquely positioned to adopt and promote digital literacies. Why don’t they? Those literacies aren’t yet being marketed as effectively as 3D printing. We who care need to figure out how to fix that.

The other night we looked up and saw an unusually large and slow satellite moving across the sky. Could it have been the space station? I found NASA’s Spot the Station page and looked up our location. Sure enough, there was a space station transit on that night, at that time, in that place in the sky.

Naturally I wondered if I could get that schedule of sightings onto my calendar. But sadly, as is so often the case, there is an RSS feed for upcoming sightings but no iCalendar feed. I wish more online services would realize that when your feed is purely a schedule of upcoming events, it’s really useful to render it in iCalendar format as well as RSS. Conversion from RSS to iCalendar is often possible, but it’s rarely trivial, and nobody is going to bother.

Nobody except me, that is. I created an Elm City service to do the conversion, and a helper that a curator can use to invoke it. Here’s a picture of a synthesized NASA calendar feed merged into the Keene hub:

If anyone reading this has the right connections, please do invite NASA to publish iCalendar feeds natively alongside the RSS feeds they currently provide.

Flight and invisibility are fun to imagine, but what are the real superpowers that make a difference in your life? One of mine is 3-way calling. I deploy it when I’m caught in a bureaucratic tangle in which one or more parties don’t want to communicate with one another. Case in point: the ambulance bill from my son’s car accident almost two years ago. He’s fine, but I’m still wrangling to get the responsible insurer to settle with the ambulance service.

Back in August 2012 I mused about the predicament for wired.com. When insurer A’s responsibility ended it refused to communicate with insurer B. As a result of the long delay created by insurer A, the party now responsible – insurer B – denied the claim.

The other day I talked to ambulance service C, they convinced me that insurer B was still on the hook and that they had the documentation to back that up. So I called B and, of course, got nowhere. They were relying on an insidious denial-of-service attack which works by routing all communication through a low-bandwidth channel: me. When each scrap of information extracted from B has to route through me on its way to C, and when C’s responses have to return to B by the same circuitous path, not much can get done. That’s what B wants, of course.

It can seem like a stalemate. B won’t answer C’s calls. When I ask B to call C that always turns out to be against the rules. Here’s where my superpower shines. With B on the phone I say:

“Hang on, I’m putting you on hold for a minute.”

Right there you’ve got them on the run. The hold maneuver is something they do to you, but don’t expect you to do to them.

Now I call C and join them to the call with B.

“Sheila, meet Frank. Frank, Sheila. Now please work this out.”

The negotiation that ensues always intrigues me. Invariably it entails differences in terminology, records, and interpretations. If systems were built to facilitate direct communication those differences could be worked out. But when systems are built to thwart direct communication it’s a logjam until the clock runs out.

Despite knocking their heads together I don’t yet have a final resolution to this matter. My superpower doesn’t always prevail. But it always makes me feel less like a pawn in other people’s games.

When transacting business in a store or a hospital or an auto repair shop I always watch what happens on the computer screen. I’ve never written line-of-business software but deeply respect those who do. It must be a huge challenge to abstract the data, terminology, and rules for some domain into software that can sell to a lot of businesses operating in that domain. Of course there’s a tradeoff. Line-of-business applications typically aren’t user-innovation toolkits. People who use them learn specific procedures, not general skills. Businesses can’t be creative in their use of the software, nor profit from that creativity.

One notable exception is Fix, an auto repair shop in my town owned by my friend Jonah Erikson. Fix doesn’t use any line-of-business software, it runs on LibreOffice, GMail, and Google Calendar. That’s only possible because the team at Fix has an intuitive grasp of the technical fluencies I outlined in Seven ways to think like the web. For example, when you open a case with Fix they create a new spreadsheet. The spreadsheet will have a name like 2013-12-11-Luann’s Passat.ods. No software enforces that convention, it’s just something the front-office folks at Fix invented and do consistently. I’ve long practiced this method myself, and it’s something I wish were widely taught.

Why does something so simple matter so much? Let’s count the reasons.

First, it’s portable. The computer at Fix runs Linux but if there were a need to switch platforms the choice would not be governed by the availability of a line-of-business application on that other platform. That kind of switch hasn’t happened but another did. The spreadsheet files used to reside on a local drive. Now, I noticed on my last visit, they’re on DropBox. Fix didn’t need to wait for a vendor to cloud-enable their estimation and billing, it just happened naturally. No matter where the files live, and no matter what system navigates and searches them, two things will always be true. Date-labelled file names can be sorted in ascending or descending order. And customer names embedded in those file names can be searched for and found.

Second, it’s flexible. There’s freeform annotation within a given job’s spreadsheet. That enables the capture of context that wouldn’t easily fit into a rigid template. But here too there are conventions. An annotation in bold, for example, signifies a task that is proposed but not yet accepted or completed.

Third, it’s free. Fix runs on a tight budget so that matters, but I think freedom to innovate matters more than freedom from a price tag. Using general-purpose rather than line-of-business software, Fix can tailor the software expression of its unique business culture, and both can evolve organically. That freedom is “priceless,” says Fix’s office manager Mary Kate Sheridan.

If you were to watch what happens on Fix’s computer screen you might object that the system requires users to know and do too much. People shouldn’t have to think about filenames and text-formatting conventions, right? Shouldn’t they just focus on doing their jobs? Shouldn’t the software know and enforce all the rules and procedures?

I’m not so sure. In another of my favorite examples, Hugh McGuire, creator of the free audiobooks service LibriVox, imagined a line-of-business application for LibriVox’s readers and quality checkers. He couldn’t afford to commission its development, though, so instead he adapted a web conferencing system, phpBB, to his needs. It remains the foundation of LibriVox to this day. Had Hugh been able to commission the application he wanted, I believe it would have failed. I don’t think lack of special-purpose software hampered the formation of LibriVox’s cuture and methods. On the contrary I think use of general-purpose software enabled that culture and those methods to emerge and evolve.

I realize this approach isn’t for everyone. We need to strike a balance between special-purpose software that’s too rigid and general-purpose software that’s too open-ended. I’m not smart enough to figure out what that middle ground should look like, but I think Bret Victor is and I’ve been inspired by his recent explorations that point the way to great user innovation toolkits. Give people the right tools and they’ll be happier and more effective — not only as employees, but also as citizens of the world.

The first MP3 player I ever used was some version of the Creative MUVO shown at right. I’ve probably owned a half-dozen of them and I just bought two more on eBay. For me it’s the perfect gadget for listening to podcasts, or songs I’m learning to play and sing, while running or biking or hiking or gardening. In those conditions I don’t want a $500 gadget that I might drop, or dunk, or scratch, with a fancy user interface that can access a vast range of features and capabilities. I just want to press play and listen. If it falls on the ground it probably won’t break. If it does break, oh well, it was $20, get another.

The MUVOs I just bought aren’t for me, though, they’re for my mom. She’s 92, and macular degeneration has advanced past the point where the reading machine we tried to modify for her can be of any use for long-form reading. And yet mom, a former college professor and lifelong voracious reader, continues to read more books than just about anybody I know. She does so by way of audiobooks from the library, and digital audio tapes provided courtesy of a Library of Congress program for the blind. Despite hearing loss which is also very significant, she can hear well enough to listen to spoken word audio.

It occurred to me that she’d also enjoy Long Now Seminars, KUOW Speakers Forum, and other series of podcasts. On a recent visit I verified that the MUVO works great for her, precisely because of its minimalist design. We are, after all, talking about a woman who needs the sort of user interface shown in this TV remote brilliantly hacked by my sister.

Mom can’t use a computer now, and even if she could there’s no way she’d be able to find the podcasts she likes and sync them to a device. That’s OK. I’ve listened to tons of stuff that she’d like, so the plan is to keep a pair of MUVOs in rotation. I’ll load a batch of talks for her onto one MUVO and send it. While she’s listening to that one she’ll have her aide send the other back to me for a reload. It’s a method that leading-edge technologists will wince to think about. Can’t cloud synchronization solve this poor woman’s problem?

No, it can’t. My method is the only one that will work for her. And it has another advantage too. Mom will periodically receive a little package of goodies from me via the old-fashioned, yet-to-be-assimilated-by-Amazon US postal service. All in all it’s another triumph for trailing-edge technologies!

For me the most productive programming environments have always exhibited the same pattern. There’s something I think of as kernel space, something else I think of as user space, and most importantly a fluid boundary between them.

For example, my first programming job was writing application software for CD-ROM-based information systems. I wrote that software in a homegrown interpreted language inspired by LISP. The relationship between my software and the engine that powered the interpreter was a two-way street. Sometimes, when I’d find myself repeating a pattern, we’d abstract it and add new primitive constructs to the engine to make the application code cleaner and more efficient. At other times, though, we’d take constructs only available in the engine (kernel space) and export them into the interpreted language (user space). Why? Because user space wasn’t just me acting as a user of the kernel. It was also where the product we were building came into direct contact with its users. We needed to be able to try a lot of different things in user space to find out what would work. Sometimes when we got something working we’d leave it in user space. Other times we’d push it back into the kernel — again, for reasons of clarity and efficiency.

You see the same pattern over and over. In languages like Perl, Python, and Ruby there’s a fluid relationship between the core engines, written in low-level compiled languages, and the libraries written in the dynamic languages supported by the engines.

I realized today that the evolving fluid relationship between web servers and web clients is another example of the pattern. Early on you had to write web software for a server. Now the web client is ascendant and we can do incredible things in JavaScript. But for me, at least, the ascendant client in no way diminishes the server. Now that the two are on a more equal footing I feel more productive than ever.

In my case the server is Windows Azure, and the “kernel” of the system I’m building is written in C# (and a bit of Python). The client is the browser, and “user space” is powered by JavaScript. I’m finding that these two realms are intertwining in delightful ways. For example, one new feature required some additional data structures. Because they’re rebuilt periodically and cached it makes sense to have the server do this work. Initially the server produced a JSON file which the client acquired by means of an AJAX call. When the feature proved out, I decided to streamline things by eliminating that AJAX call. So now the server acquires the JSON and caches it as a C# object in memory. When the page loads the server converts the data back to JSON and makes it directly available to the client.

What about the fact that this arrangement involves two different programming environments? If that bothered me I could be using JavaScript on the server too. But I don’t feel the need. For me, C# is appropriate for kernel space and JavaScript is appropriate for user space. Which language powers which realm isn’t really the point, though. What matters is that the two realms exist and collaborate productively.

Follow

Get every new post delivered to your Inbox.

Join 6,080 other followers