Month: January 2004

Political clicks and mortar

Clay Shirky alleges that the boost Dean got from the internet was illusory; internet campaigning is a substitute for the real thing. That’s only true if the legions of new internet activists give up, and don’t learn the next steps of political activism.
I’ve seen the gap between familiar and new in Texas. I participated a little in the project to get internet tools for the Texas Dean campaign. Glen Maxey, a sensei of local politics, runs the campaign, and talks about precincts and delegates. The enthusiastic crew building web tools talk about blogs and RSS, PHP and MySQL.
My main political experience has been digital rights issue activism, not political campaigns. Last year, fighting the SDMCA battle, we used email, blogs and wikis to co-ordinate; shoe-leather to lobby legislators, and old-fashioned connections to invite tech industry lobbyists to help fight off the movie moguls.
In the comments to the Shirky post, Rusty Foster explains how the Dean Campaign dropped the ball in the field campaign in Iowa.

The field ops were not, as far as I know, too busy blogging pictures of their cats to handle the strategy. Their strategy and execution just didn

Technical support by RSS

Last week I was scanning my RSS reader and stumbled across a Socialtext bug report. The Shifted Librarian wanted to scan the RSS Winterfest weblogs, and ran into a bug in our new RSS feed. I reported the bug. Pete diagnosed the problem in the blog comments.
RSS for information discovery, and weblog for collaboration. It works.

RSS Attention Management

RSS readers are very handy for people to manage attention to incoming information.
Debates about the relative superiority of RSS readers and web browsers are missing the point. Nobody wants the whole web coming to their desktop reader.
You use RSS for sources that change periodically, that you visit again and again. Bug-tracking is a great application — several people in the RSS-Winterfest IRC mentioned bug-tracking as handy use of RSS.
A few people in the IRC mentioned RSS for alerting. The RSS polling design isn’t intended for real-time notification. For that you need IM or Jabber or Tibco. Real-time notification and periodic updates can be used nicely side-by-side — for example, a system administrator might want routine human and system notifications via RSS, and system-down or danger-zone alerts by IM or pager.
Information updates have different levels of urgency — “the building is on fire” is more urgent than “the room temperature has increased from 68 to 72 degrees” (unless you’re managing a temperature-sensitive lab culture).
A given piece of information is more urgent for some than others. A customer support query is urgent for the service reps on duty, and of background interest to product managers and developers.
We need a range of attention-getting media.
* IM/pager for lapel-grabbing alerts
* email for important, short-notice items
* RSS for alerts for discretionary attention
* Weblogs and wiki providing a “browse mode” fix for recent changes junkies, and a searchable archive for occasional readers
(We also need a Ross Mayfield trademark colorful chart to gain fame for the concept.)
These modes complement each other. They help individuals manage attention, and they help organizations focus attention on urgent matters, while building knowledge in important areas.

RSS-Winterfest — the liveliest teleconference ever

Over 1000 participants participated in the RSS Winterfest voice-blog-wiki-IRC multi-model conference last week. Socialtext hosted the “Eventspace” wiki-blog — we hosted the application, and we also helped to host the online party. It was lots of fun, included insightful conversation, and created useful resources.
Participants in IRC improvised conversation on the themes of the sessions. Bloggers posted session notes and questions and resources. Wiki participants built collaborative pages on RSS Tools, RSS Authentication, and other topics.
Here are some of the practices we used that helped make the conference lively:
* create weblogs with relevant topics
* set up sign-in space for people to describe themselves and learn about each other
* pre-populate the wiki with the conference program and other resources
* real-time gardening — link interesting pages to the home page, consolidate related resource pages, help harvest quotes and references.
Maybe most important, we helped weave questions, comments, and insights from the IRC and wikiblog into the voice conference. It’s a salon facilitation skill, translated to electronic media.
This RoperASW/Tandberg polllast year revealed the crushing tedium of traditional teleconference. Less than half of attendees actually pay attention to conference calls. With audience participation tools, you get an event that is more lively and intelligent.

Is RSS Ready for Prime-Time

Dylan Greene writes an insightful yet ultimately unsatisfying piece arguing that RSS is not yet ready for Prime Time.
He’s right that RSS has weaknesses. The way most people use it, it wastes bandwidth. Many feeds don’t include full-text (need to fix this…). Comments aren’t well integrated. And, the coup de grace, an RSS reader isn’t yet built into Microsoft Windows.
True, but not that useful, unless you’re a Gartner analyst trying to determine whether a technology has reached a state of ultimate, top-right-quadrant maturity.
The interesting questions are:
* is RSS mature enough to do what you want?
* can you benefit from RSS as an individual, a publisher, or an organization.
If you’re a mildly tech-savvy individual wanting to keep track of lots of weblogs and news, then RSS is a lifesaver.
If you’re a complete novice, or if you advise complete novices, you probably want to avoid RSS — though bloglines is pretty darn accessible — I’d recommend it to anyone who is comfortable with a browser.
If you’re a blogger or web publisher, and want to reach the increasing number of users who depend on RSS to read web content, then surely publish in RSS.
If you’re in an organization where most people are drowning in email (i.e. most of us) and you have influence over technology choices, you might want to consider using RSS to complement business applications, helping individual employees manage their time and attention.
Dylan’s points are correct, but they don’t tell you whether the rewards of RSS are worth the trouble for you. It takes a bit more effort to use technologies that are somewhat in their life cycle. You need to decide whether it’s worth it.
If you’re an open source geek or work for a technology company that’s not Microsoft, you have opportunities to shape next-generation syndication standards and applications. Those opportunities are here now, and will be gone in a few years.

Confidence in the voting system

A recent Zogby poll found that even in red states, which voted for George W. Bush, 32 percent of the public believes that the election was stolen. In blue states, the fraction is 44 percent.

via a succinct op-ed by Paul Krugman.
I’ve been working on evoting issues here in Texas. Voting administration officials are very concerned that “alarmism” about evoting will reduce public confidence in elections.
It is too late. We have a problem. Without a voter-verified paper trail, there’s no way to have a reliable audit. If something goes wrong, we’ll never know.
The way to handle citizens’ justified concern is action, not Xanax and lullabies.
Officials are concerned about cost. Krugman says it well.

What about the expense? Let’s put it this way: we’re spending at least $150 billion to promote democracy in Iraq. That’s about $1,500 for each vote cast in the 2000 election. How can we balk at spending a small fraction of that sum to secure the credibility of democracy at home?

Open source informalism

UC Irvine Researcher Walt Scacci is studying open source development, and has come across distinct practices.
It’s not clear to me how the open source practices differ from agile processes in general — a lighter, more conversational, less document-heavy design process.
What are some of the differences you’ve found, apart from the obvious ones?

For example, in software engineering, there’s a widespread view that it’s necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it’s possible to pose questions as to what was implemented, compared with what was specified.

We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven’t written down the problem? While it’s true that there’s no requirements specification, what there is instead is what we’ve identified as a variety of software informalisms.

What do you mean by “informalism”?

That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.

Bruce Eckel on blogging and simplicity

Bruce Eckel is trying to cultivate bloggingas a genre for expressing ideas that aren’t yet complete thoughts. “I now believe there are three modes of written communication: books, articles, and ideas. The first two I have long experience with, but I lack a medium for ideas. ”
Eckel draws an interesting connection between initial simplicity — getting something out quickly — and elegant simplicity, which takes a lot of work to prune a complex expression to a simple form. They aren’t the same thing at all, but getting material out into the world helps give you the feedback that lets you refine and polish.

What is the balance between simplicity and expedience? “Do the simplest thing that could possibly work” is certainly not saying “do the most elegant thing” because the goal is to get something working, without too much effort, so that you can try it out and see if it solves any portion of the problem. “Trying it out” is what will produce the valuable information that can be fed back into the next iteration, and will also begin to tell you what’s most important about the problem.

Simplicity is hard

In the article about the 80/20 rule, Tim Bray explains that simplicity isn’t easy.
In Tim’s words, “the mental machinery involved in the design process naturally tends towards more rather than less.”
The unofficial version of my business card reads “grinch.” I spend a lot of time saying no to all kinds of attractive, bright, shiny jingly ideas. “Too complicated.” “Not the most important thing right now, maybe later.” “What’s the simplest way of doing things that works”? Two parts diplomacy, one part curmudgeon. Not a good way to win popularity contests.
Before Christmas, from a biotech company, “This is much easier to use and manage than $competitive product. I can use this with much more of my team”
Yesterday, from a consultant who helps organizations improve collaboration and manage knowledge… “It’s like $competitiveproduct, but easier to use and cheaper.”

The 80/20 rule wins

Tim Bray has been working on a series of articles analyzing which factors lead to technology success. The strongest predictor isn’t investor support, technical elegance, a compelling idea, standardization. It’s the “80/20” rule, systems that yield 80 percent of the benefit for doing twenty percent of the work.

The 80/20 Tribe