Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Random links

by

## Some people think that it’s a bad idea for government to get involved in helping organize local wireless networks. This great little post by Glenn Fleishman asks, what if we’d applied those arguments to the introduction of electricity 100 years ago?

 

Electricity is too important a resource for America’s future to be left in the hands of cities and towns, the council argues, which are inefficient enterprises that take profits from industry in their pursuit of ever-greater control of the flow of capital within their borders. “How big may these so-called public utilities grow in their efforts to stifle free enterprise and increase the size of government?” the report asks.

The report notes that 97 percent of all neighborhoods in the U.S. have at least one functional electric street lamp running built through private enterprises’ effort, and that some urban areas have two electrical lamps on each corner, as well as lighting available at different times of the day and night both within and outside of homes and businesses.

## Cliff Figallo, who I once had the pleasure of working with at Salon, is blogging thoughtfully at “What Retirement?” about all the issues — Social Security and otherwise — facing today’s workers as they ponder the (long, we all hope) tail end of their careers and lives.

## Annalee Newitz of the EFF deconstructs EULAs (“end user license agreements”), those boilerplate legal agreements we all click through without reading so that we can actually use commercial software.

## Leftie SF author China Mieville put together this list of “Fifty Fantasy & Science Fiction Works That Socialists Should Read”

## The hotel that inspired the greatest farce of the television age, “Fawlty Towers,” has been sold. But how can the Patels, the new owners of Torquay’s Hotel Gleneagles, possibly maintain its proud tradition of rudeness and incompetence?

Fox blood on the tracks?

by

A CNet columnist, Molly Wood, totally misunderstands what Firefox, and open source software, are all about. She’s arguing that now that Microsoft has said it will issue an update of its browser, we can write Firefox off:

“For a moment there, it looked like the tyrant IE could actually be overthrown. Those were heady days, weren’t they? Well, they’re over now… If IE 7 is even 50 percent more secure than current versions, the Firefox rebellion is finished. If IE 7 has tabs, Firefox will be destroyed as surely as the Hungarian uprising of 1956 was crushed by the Soviets… now that the sleeping giant has awakened, I think the buzzing gnat of the browser wars is about to be squashed flat.”

This is a prime example of one of journalism’s worst habits — a knee-jerk application of “who wins, who loses?” logic to situations where it doesn’t really apply. “Finished.” “Destroyed.” “Crushed.” “Squashed flat.” This is the language of pro wrestling, sometimes adopted by business writers who are desperate to paint the typically colorless corporate world in the bright colors and action-packed imagery of sports.

Yet the whole point of the open-source challenge to Microsoft is that it can’t be “crushed” like a small commercial competitor. IE 7 may or may not cut into the extreme growth curve of Firefox adoption; but the people who are building the open-source browser will happily continue to fix their bugs and add their plugins and improve their product whether their adoption rate stalls out or not. And Firefox has already achieved critical mass in the market such that responsible Web site designers can no longer take the lazy “everyone uses IE” route.

Naturally, everybody wants their work to be appreciated and their products to be used, and I’m sure the Firefox team are going to pay close attention to Microsoft’s competition — but I can’t imagine them sweating the way the employees of a commercial startup in their shoes would. Microsoft can improve its browser from now till doomsday — and if it does, we should applaud — but there is no way it can “cut off the air supply” of an open source project the way it could “squash” a company like Netscape. Firefox’s air is free.

Tree-cutting and tag-spinning

by

I have been mulling over a big old post about tagging and folksonomies, but book work has taken priority this week, and by now most of what I wanted to say has been said by others (here are some good links).

So this is all I think I’ll throw in to the discussion — and append to my previously posted skepticism that people beyond early adopters will pursue tagging with any avidity: “Tagging” is a great word. “Categories” are onerous; they sound like work. “Tags” sound like play — like a game we played when we were tots. (Hey, it’s ludic!)”Categories” also implies, to many users, a mental model in which each item must live in one category to the exclusion of others. “Tags” encourages overlap, duplication, experimentation.

I like the way David Weinberger puts it here, as he compares older-fashioned information hierarchies with folksonomic tagging: “The old way creates a tree. The new rakes leaves together…. The old way — trees — make sense in controlled environments where ambiguity is dangerous and where thoroughness counts. Trees make less sense in the uncontrolled, connected world that cherishes ambiguity.” And the world of software is so allergic to ambiguity that we should cherish any new development that opens a space within the digital realm for multiple meanings.

If the software that begins to harness the tagging phenomenon can stay true to the spirit the word evokes, I think it has a chance of overcoming human inertia and resistance to doing more than the bare minimum of metadata labor. Which places a premium (as Ross Mayfield points out) on ease of use. If people are going to tag things at all, you need to make it really easy for them to do it fast. Del.icio.us — once you set up its toolbar shortcut — is pretty good, though I think it would be great if it showed you how other people tagged a link before you did your own tagging. Technorati’s experiment with tagging for blog postings obviously has a very long way to go, but it’s moving in the right direction.

Will the whole thing get debased by commercialism and swamped by spam? Sure. Then we’ll return to the drawing board.

Tracking the newsroom bug-tracking idea

by

I want to return to the idea I floated a few days ago about bug-tracking software for newsrooms. The comments response ranged from “neat idea!” to “it’ll never work,” so let’s look it over again.

What I imagined was something similar to the way open-source software development projects manage bug reports. When people file bugs against such a project, they go to a publicly available online resource and enter a form that says “Here’s a problem I encountered,” and provide details. Different projects follow different organizational structures, but generally speaking, other developers will review the bug and try to classify it: Sometimes they’ll say it’s a duplicate and point to previous entries in the database that dealt with it; sometimes they’ll say it’s a simple problem and go fix it right away and close it out; sometimes they’ll say it’s a big one and leave it open to be dealt with in the future; sometimes they’ll say it’s a “known bug” that for one reason or another is never going to be fixed; sometimes they’ll say it’s not a bug at all.

For a newsroom, the idea is to provide a structure and a channel for reader dissatisfaction. You wouldn’t have to follow the software model detail for detail, but the general outline could be valuable: Provide a form for readers to enter complaints, one that requires them to present details. Post the complaint publicly as soon as it’s entered, and record the publication’s response in a reasonably prompt fashion — anything from “Thanks, we fixed the spelling on that name” to “we chose the phrase ‘private accounts’ because it is an accurate description of the president’s proposal, and the label was in wide use by supporters of the idea until very recently, so we do not plan to stop using the term.” The explanation is on record, and if other readers keep filing the same complaint they can simply be pointed back to the original answer. Spam? Just delete it. Letters to the editor that don’t have a specific complaint? Re-route them to the letters box.

The most common objection seems to be, forget it — this will become another free-for-all for political partisans to work out their agendas, another wide-open Internet forum that will degenerate into circular debate. Such forums already exist, to be sure; the point of a bug tracker is to avoid that outcome by choosing a narrower environment for the feedback that allows you to quickly aggregate and dispose of duplicate complaints, and that provides a public record of responsiveness and accountability. If 500 people all holler that you shouldn’t say “private accounts,” you can answer them once and be done with it — but you can point each individual complaint back to your explanation, so those people understand that you actually heard them and offered some sort of response. There’s a big difference between the silence of no response and “no, we’re not doing that, here’s why.” The latter won’t satisfy everyone, but it at least acknowledges that there’s been an exchange on the subject.

Ross Karchner proposed a somewhat different model based on wiki practices: “1) A publically viewable changelog, where you can see, in detail, the changes made to an article. 2) A place where the author(s) and editor(s) can discuss the changes needed and made. This is also in public view…” I’m not sure whether Ross means the changelog and the writer/editor dialogue to commence from the first time the writer composed a draft, or only upon publication. The former is, I think, too wide open — even a blogger has the right to compose a posting and revise it in private before choosing to push the “publish” button. The latter is fine — but since most reputable publications rarely change articles once they’re published, and note the changes as corrections if they do, then it’s just codifying an existing practice in slightly different ways.

As for the idea of trying all this out at Salon: Who knows, I might well advocate it, though my current on-leave status doesn’t put me in a good spot to work on it. But Salon has been dealing with the back-and-forth of online criticism of our work for 9 years plus. Whatever problems we may suffer from, a failure of responsiveness to online feedback is not, I think, one of them, and we have a pretty sturdy process for reviewing complaints fast and correcting them where needed.

I think this approach would pay off best for a newsroom that is having difficulty convincing readers that the publication is actually listening to them. If you showed the public that you were recording and responding to the issues they raised — whether you end up publishing a correction or simply saying, “We don’t think that needs correcting, and here’s why” — I think you’d start to bank some confidence and trust pretty quickly.

I’m not suggesting that this idea is the single, one-fix-solves-all-problems answer to the ills of journalism today. It’s a pragmatic, you-could-do-it-real-soon suggestion for beginning to deal with professional journalism’s biggest problem: the public’s loss of trust, which begins with the sense that media companies are big institutions that pay no attention to their own mistakes.

Bugzilla meets the press

by

This morning’s Romenesko brought this link to a Sacramento Bee column about how some newspapers have begun to use databases to track errors and corrections. Reasonable enough, but maybe not far enough, and it got me thinking.

Software development teams have used bug tracking software for ages now — why not journalists? But keeping it in-house, as the papers the Bee cites seem to do, limits the value of the approach.

I’m spending a lot of time these days around open-source software developers, and they take the logic of this approach one step further: Major open source projects maintain public bug databases. Anyone can come along and post a bug report. It’s like opening a trouble ticket: developers will have a look, see if your complaint is new or duplicates an existing problem; over time the database provide a permanent record of the resolution (or non-resolution) of the issue.

The model doesn’t map perfectly onto journalism, but it’s not too far off: Let people file “bug reports” if they believe your publication has published something in need of correcting. The publication can respond however it seems appropriate: If the complaint is frivolous, you point that out; if it’s a minor error of spelling or detail, you fix it; if it’s a major error, you deal with it however you traditionally deal with major errors — but you’ve left a trail that shows what happened. However you respond, you’ve opened a channel of communication, so that people who feel you’ve goofed don’t just go off to their corners (or their blogs!) feeling that you’re unresponsive and irresponsible.

I know this idea will horrify a lot of editors and reporters, but I think an adventurous newsroom could benefit from the transparency and the accountability. Maybe someone’s already doing this out there — if so, it would be great to see what we can learn.

Udell’s umlaut epic

by

The Wikipedia’s heavy metal umlaut page is a pretty amazing thing in itself. But this is even more amazing.

Jon Udell has been pioneering what he calls “screencasting,” an unusual sort of online journalism that involves taking over your browser screen with screengrabs and animations while he narrates via the audio track. It always seemed mildly interesting to me as a way to do technology demos and product walkthroughs and the like; but with this piece, Udell has taken the form to a higher level, and shown us that it’s something weird and wonderful — and unique to our new Web world.

Plus we get a full technical education in the difficulty of producing an umlauted “n” on screen, an investigation into an act of drive-by wiki vandalism, and an anthropological chronicle of the behavior of Wikipedia contributors. Bravo!

1968: the year of the blog

by

Having heard Alan Kay’s inspiring talk at the 2003 Emerging Technology conference, I already knew how much of modern computing Douglas Engelbart‘s famous 1968 demo of the NLS (“oNLine System”) contained within it — and how far we still have to go to match the stuff Engelbart showed off then, not only in its individual elements (graphical interface, hypertext, advanced input devices, distance collaboration, and so on) but in their total integration.

What I didn’t know was that the NLS appears even to have had a kind of blog capability as one of its many tricks.

I’ve been watching the amazing videos (shot by Stewart Brand) of Engelbart’s demo — all available online, here. If you take a look at this one, you’ll see Jeff Rulifson explaining that the NLS programmers — who, in true bootstrapping fashion, seem to have maintained all their code within the NLS itself — kept a kind of bug log. Since NLS tracked who was using it and what everyone did when, each entry in the bug log has a little subscript line, flush right, with the name of the person who posted it and the time it was posted.

Sure looks like a weblog! And if you were logged into NLS you could even add comments. (I’d clip a still from the Real stream but haven’t been able to do a screen capture — perhaps part of the Real format’s DRM, or I’m too much of a klutz. Anyway, the video clip is under a minute.)

Rhymes with Mombasa

by

Picasa, my favorite Windows photo-organizing software, has a great new upgrade from Google, which acquired the company a while back.

The funny thing here is that, though you will find Picasa referred to here and there as a “service,” it’s not really that; it’s an old-fashioned, standalone desktop application with a bit of sharing coated on top. I’m not stating that as a criticism — I love Picasa, and it’s helped me keep track of the absurd quantities of photos of my kids I’ve taken over the past five years. Much as I love Flickr, there’s no way I’m going to upload that volume of photos across the Net.

It’s just odd to think of Google, the locus classicus of the new world of distributed web-based computing, doing this sort of product, and just giving it away. John Battelle has more here, noting that there is no business model of any kind behind Picasa. That worries me, only because I’d really like to keep using this software for a long, long time.

Blows against the spampire

by

Another turn of the technodialectic: Google implements a new HTML tag to defeat comment spam. Congrats to the Google/Blogger developers for implementing this. On first glance, looks like a smart solution: The rel=”nofollow” tag as an attribute in an HTML link tells Google not to pay attention to the link for pagerank purposes. If your blogging tool is set to automatically insert this code into any links created by commenters on your blog — and we should expect that now from SixApart, Blogger, Userland and anyone else in the biz — then you pretty much have shot the horse out from under the comment-spammers, and they ought to go away. (Though Chuq Von Rospach says they won’t as long as there’s even a tiny fraction of vulnerable, un-upgraded blogging software.) More comment from Dave Winer, who loves the news, and John Battelle, who’s not so sure.

Will this tool also somehow lock-in existing blog power relations, as a commenter on Battelle’s blog complains? I dunno. It seems to me that there’s still plenty of room in the blogosphere for links created by blog authors to point to newcomers. And commenters can still link away — their links will only be followed by live readers, though, and not the Googlebot. On balance, sounds good to me. Of course, the techno-dialectic being what it is, the comment-spammmers will figure out some new, more devious scheme to subvert Google before long.