Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Ecco Pro — back from the dead, again

by

Longtime readers here know of my interest in the subject of outliners and in particular my dedication to an old program called Ecco Pro. I used it as my main organizer for my first book, and now, as I begin work on a new one, I find myself turning to it once again. (If you want to understand why, Andrew Brown’s recent piece in the Guardian offers a thorough explanation.)

Ecco devotees long hoped the program might be open-sourced, but the hopes never materialized. Nonetheless, in one of those twists and turns that keep the software world interesting, there has been much movement in the Ecco world in recent months — and, even without the code being open-sourced, there’s the first significant new work on the program in years.

Here, as far as I can tell, is what happened: A programmer who goes by the handle “slangmgh” posted a message to the Yahoo Group “ecco_pro” on April 16th: “I write little utility, have upload to the files directory! It’s only work for EccoPro v4.01.”

The file was called “EccoPro extension.” It included a half-dozen significant fixes and upgrades to the program. A day later, he’d uploaded a 1.1 version of his “little utility.” Today, he is on 3.6 or so. His furious pace of development has involved, if I understand correctly, the incorporation of the Lua scripting language into the extension. It’s all made possible by the essential solidity of the original program and the API hooks its creators provided — so that, even though the original Ecco code can’t be changed, it can still be built upon.

The only downside to the whole thing is that “slangmgh” is plainly not a native English speaker and so his explanations of the changes and features are sometimes difficult to follow. In recent weeks, other members of the Ecco support group have stepped forward to provide better documentation.

There you have it: an orphaned program that hasn’t been touched in a decade but that still has a devoted community of users suddenly starts evolving again in the hands of an energetic programmer. I don’t know where the Ecco story will ultimately lead but I’m delighted to see it still unfolding.
[tags]ecco pro, pims, outliners[/tags]

Web 2.0’s five-year development cycle

by

As David Bowie once sang:

We’ve got five years — my brain hurts a lot
We’ve got five years — that’s all we’ve got

One of the arguments I often hear raised against Dreaming in Code’s contention that “software is hard” is what I call the “Web apps solve all our problems” stance. In this view, the Web 2.0 wave is not just about user convenience and nimble companies — it represents the final triumph over the beast of software-project delays and headaches, thanks to the ease of prototyping, the fast upgrade cycle and the tight feedback loop of user input characteristic of this approach.

No sane observer denies the importance of this trend. But I’m always a little skeptical of the pollyanna-ish view that moving our software onto the network and into the browser puts all of our old problems out to pasture.

Tonight as I caught up on my feeds I noticed two items from TechCrunch that resonated. First, Yahoo has taken its revised Web-mail interface out of beta, after years of development. (Farhad Manjoo at Salon’s Machinist has a good review.) Yahoo’s new mail system is based around that of Oddpost — a small startup that pioneered the “Ajax”-style Web interface back in 2002 before being acquired by Yahoo. I remember looking at it then and thinking, wow, this is a big deal. And it was, as the concept of updating data within a browser window without refreshing the entire page quickly spread over the next several years. But it took Oddpost from 2002 to 2007 to mature into Yahoo Mail.

Meanwhile, another key Web application that started up only a little after Oddpost, Bloglines, has introduced the first major upgrade to its interface since — well, since it began. Bloglines got acquired by Ask Jeeves years ago, and has had some problems keeping up with its masses of users and data. Even now, its new design — which looks very nice on first glance — is just entering a beta phase.

Put this together and it sounds like, after the phase of “gee whiz, we got a great idea, let’s buy a domain name and put it out there” — once reality kicks in — major Web applications have an upgrade cycle of once every five years or so. Small startups get acquired and face organizational integration challenges; small applications face the uphill struggle to scale for masses of users; and services sit through long “beta” periods to test interface choices, iron out bugs and see how they can handle running under load.

I’m not knocking Yahoo Mail or Bloglines here. But this is sobering data for those who argue that the advent of Web-based apps and services drives a silver bullet through the heart of software’s problems. Five years is no sprint. Funnily enough, it’s roughly the timespan of Windows Longhorn/Vista — or Chandler, the program I wrote about in Dreaming in Code.
[tags]software development, web 2.0, bloglines, oddpost, yahoo mail[/tags]

Wanted: “test-drive” option for RSS feeds

by

I love the convenience of RSS, but one of the problems of life inside the feed reader is that once you find a few dozen feeds you want to follow, the cost of adding a new feed becomes too high. When you find a site you like, you think, “Gee, I want to subscribe — but do I really want to add another feed? I can’t keep up with the ones I have!” (I know that the casual “River of News” approach, where you just let the stuff stream by you, would mean no guilt over not keeping up, but I haven’t achieved that level of Taoism detachment yet.) So over time we stop adding new feeds to our RSS diet. This perpetuates the “first-mover advantage” and makes it harder for newcomers to gain subscribers. (They still can, and do, of course.)

Here, as I mentioned in my BarCamp post, is my idea for a feature that RSS readers should but don’t (as far as I know) have: a sort of “New Feed Probation” or “Test Drive” zone. New feeds you subscribe to are automatically placed here (unless you deliberately put them somewhere else). They remain here for a preset time period (a week, a month, whatever you choose). At the end of that period, your reader flags the feed for you, tells you how much you’ve read it, and asks whether you want to keep it or not. You can see whether you actually ended up reading much of it during the “trial period,” and make an informed choice.

Sure, you could do all this yourself, manually. (I do, sometimes!) But wouldn’t it be nice if the reader helped you with this clerical task — and, in the process, encouraged you to explore new information sources and blogs?
[tags]rss, feed readers[/tags]

BarcampBlock abuzz

by

BarCamp Block was extraordinary — I spent Saturday morning and afternoon there. (Family commitments kept me from the Saturday evening and Sunday events or I’d have stayed all the way through.) This “unconference” was a free event, with “programming” supplied ad hoc by the attendees themselves, and a schedule devised on the fly at the start of the weekend.

Sounds like chaos? “Cult of the Amateur” mediocrity? No way. Think instead of the energy, ideas and conviviality that can flow from a crowd of smart people when they’re given a chance to make things up as they go along.

The event was huge — hundreds of people gathered primarily around one block in downtown Palo Alto centered on the SocialText offices. No one could possibly have attended more than a fraction of the sessions. Three highlights for me were:

  • A discussion among about a dozen people at the Institute for the Future office about coping with RSS overload. This was started by someone who works at a company that’s producing a sort of personal (or collaborative) filter for your RSS feeds (so you can train your feed reader to only show you posts on a set of topics that you’re interested in). I have no use for such a product; when I subscribe to a feed I’m happy if the blogger surprises me with interesting stuff that I didn’t know I was interested in (and that I’d never see with a feed filtered by preset criteria). But the idea led to a good exchange in the room, and helped crystallize my thinking on a feed-reader feature that would make a big difference (for me, anyway!). I’ll post separately on that.
  • Tantek Celik led an open discussion about the state of microformats, a subject I’m increasingly interested in. This is one of those Web-technology phenomena that at the moment is intelligible almost exclusively to geeks, but I think that — like blogs or RSS — it will become much more widely useful and adopted in the next few years. I’ll also be writing more on the subject later.
  • Finally, Brad Fitzpatrick, David Recordon and Joseph Smarr led a session on “Opening the Social Graph.” They were talking about a pragmatic, we-could-build-it-now solution to the much-discussed problem on the “social web” of proliferating networks. Who wants to join another social networking site when, each time you do that, you have to painstakingly rebuild your list of “friends” or relationships? Isn’t there a way to make this information portable? LiveJournal founder Fitzpatrick’s recent paper on this subject proposed one approach. At BarCamp Fitzpatrick and his collaborators talked about setting up a nonprofit organization that would serve as the hub for the backend data services his solution would require. Another fascinating subject worth more future in-depth posting. (No one seems to have posted notes on the session, so I’ll try to add mine to the conference wiki soon.)

So there you have it: I spent less than a full day and came away with my head buzzing and three major areas of material to pursue more deeply. I don’t think any of the old-fashioned, CEOs-on-stage conferences I’ve been to match that record.
[tags]barcampblock, rss overload, microformats, social networking[/tags]

Falling bridges and failing programs

by

Last week I was reviewing my Dreaming in Code slides and talk, which include a brief discussion of the old question, “Why can’t making software be more like building bridges?” when the news hit of the Minneapolis bridge collapse. In the book I used the long and painful stop-start process of the Bay Bridge replacement (a bridge that stopped for a redesign in mid-construction!) as one example of how bridge building may not be as reliable and predictable an undertaking as we think; the Minneapolis tragedy is another example.

At least it’s getting people thinking. For those interested in further reading, there’s Stephen Wolfram’s fascinating post suggesting that future bridge designs may emerge from the sort of mathematical explorations his software has enabled:

what should the bridges of the future look like? Probably a lot less regular than today. Because I suspect the most robust structures will end up being ones with quite a lot of apparent randomness….we’re going to end up being exposed to something really quite new. Something that exists in the abstract computational universe, but that we’re “mining” for the very first time to create structures we want.

Computerworld reports on new systems that allow the placement of acoustic sensors on bridges to provide better feedback mechanisms than today’s routines of visual inspection.

I was also reminded of a thorough and informative paper from 1986 that I came across in my Dreaming in Code research: “Case Study: A Computer Science Perspective on Bridge Design,” by Alfred Spector and David Gifford. (There’s a PDF available here.) This paper outlines the more mature and rigorous process of designing and specifying a new bridge and systematically compares it to the looser and less clearly defined processes we use in so much software engineering.
[tags]bridges, software engineering, stephen wolfram[/tags]

The way the Gates mind works

by

Bill Gates took a kind of victory lap in the press on Monday, with dueling big pieces in the Times and the Journal marking his steadily advancing separation from the company he started three decades ago. While the Journal concentrated on the role that Craig Mundie will take over from Gates — as Microsoft’s long-term software thinker — John Markoff’s Times piece featured some choice quotes from the soon-to-retire founder himself.

First, there was Gates the Google-baiter, adopting a role he has played a lot in recent years:

“How many products, of all the Google products that have been introduced, how many of them are profit-making products?” he asked. “They’ve introduced about 30 different products; they have one profit-making product. So, you’re now making a prediction without ever seeing the software that they’re going to have the world’s best phone and it’s going to be free?”

Then there was Gates the true believer in software:

The center of gravity in the computer industry has dramatically shifted toward software, he said. “Why do you like your iPod, your iPhone, your Xbox 360, your Google Search?” he said. “The real magic sauce is not the parts that we buy for the Xbox, or the parts that Apple buys for iPhones, it’s the software that goes into it.”

Finally, there was Gates the slightly tongue-tied global debugger:

Mr. Gates insists that his new world of philanthropy will be just as compelling as software has been. “I’ll have also malaria vaccine or tuberculosis vaccine or curriculum in American high schools, which are also things that, at least the way my mind works, I sit there and say, ‘Oh, God! This is so important; this is so solvable,’ ” he said, “You’ve just got to get the guy who understands this, and this new technology will bring these things together.”

If that’s the spirit that has inspired Gates to use his fortune for good causes, then one should probably not complain. But there is something so very naive about this richest-man-in-the-world’s can-do engineering spirit.

Problems? You’ve just got to get the “guy who understands”! Give him the right technology! And all will be well.
[tags]microsoft, google, bill gates, philanthropy, new york times, john markoff[/tags]

Notes from Mashup Camp

by

I spent a few hours on Wednesday at Mashup Camp — I think this was the 4th event, the second I’ve attended. As previously I found most value in the “speed geeking” portion: an hour or two spent moving from table to table in a big room hearing a succession of five-minute demos by developers showing off some cool trick or application mashup. Last year I wrote about what it all means:

…you got a window onto a simpler, faster, and perhaps smarter approach to software product development — one that trades in the virtue of from-the-ground-up consistency and thoroughness for the even more compelling virtue of “getting something working fast.” It’s software development as a Darwinian ocean in which large numbers of small projects are launched into the water. Only a handful will make it to land. But most of them required so little investment that the casualty rate is nothing to lose sleep over.

This time I’ll just mention a few demos that I thought stood out:

  • Chime.tv: This is essentially a kind of Del.icio.us for videos, with a smart built-in video player and some basic tools for building and sharing channels. Nothing revolutionary here, except that (a) it lets you aggregate videos you find all over the Web (not just one provider like YouTube) into your own playlist/channel; and (b) it happens to be remarkably well-designed. I expect to be using it for a while as a video-viewing manager. We’ll see how it holds up.
  • Myk O’Leary’s twitterlicious serves as a simple hookup between Twitter and Del.icio.us (or Ma.gnolia.com). In other words: If you’re reading Twitter messages (“Tweets”) on a mobile device and they contain URLs that are inconvenient to save and that you can’t properly visit at the moment, Twitterlicious sends the “tweet” to your Del.icio.us account as a private bookmark with a special tag. You can review these at your desktop leisure.
  • Lignup showed a cool little application that lets you use your cellphone as a mobile input device to add voice annotation to a Web page or object (like, for instance, a Flickr photo). (This press release tells a little more.)

This Mashup Camp was a little less mobbed than the last one I went to, but there still seemed to be plenty of good ideas. And I even bumped into a few people who’d read Dreaming in Code, which always puts me in a good mood.

This weekend I’m going to try to go to at least some of WordPress Camp. Then next week my family will be doing some actual camping — like, in a tent. I think we’ll call it Camp Camp.
[tags]mashup camp, mashup camp 4, mashups[/tags]

Slaves to the inbox

by

My latest Salon article is “Empty thine inbox” — a piece about e-mail overload hitched to reviews of three current books: “Send,” an e-mail etiquette guide by David Shipley and Will Schwalbe; Mark Hurst’s “Bit Literacy,” which outlines a methodology for personal-information management; and Mark Frauenfelder’s “Rule the Web,” a treasury of tips and tricks for taking control of, and enjoying, one’s online life.

The piece takes a brave stand against the injunction to maintain strict inbox hygiene:

My inbox is not a desk that must be cleared. It is a river from which I can always easily fish whatever needs my attention. Why try to push the river? Computer storage is cheaper than my time; archiving is easier than deleting… Do we really want the job of in-box attendant and e-mail folder file clerk? The mess is Augean scale, the job Sisyphean futile.

One other angle on this subject that I did not work into the article comes from Ducky Sherwood, who wrote books on how to handle e-mail burdens some years ago (and who also has a great resource page on all things email):

I’m a bit bothered by an implicit characterization that “email is the problem.” This isn’t fair to the medium. Your problem is that lots of people give you stuff to do. (“Read my message” falls into the category of “stuff to do”.) People have been overwhelmed by the amount of stuff that other people give them to do since long before email.

[tags]productivity, email, gtd, pims, personal information management[/tags]

Facebook needs work

by

I am by far not the first to point this out, but it bears repetition: Facebook has some big problems with its matrix for defining relationships among friends.

The first generation of social networks were mocked for offering only a simple binary choice of “friend” or “not friend.” Facebook — which started as a network for college students, but opened its doors to the world a few months ago, and is now growing like mad — isn’t much of an improvement. But at least it lets you fill in some blanks and better define your relationship with particular friends.

Each time you confirm a “friend request” from someone on Facebook, you’re confronted with a screen that asks for details. This is the list of options:

How do you know [this friend]?
Lived together
Worked together
From an organization or team
Took a course together
From a summer / study abroad program
Went to school together
Traveled together
In my family
Through a friend
Through Facebook
Met randomly
We hooked up
We dated
I don’t even know this person.

This is a great list if you are 19 years old. It is pretty much useless for the rest of us. And even if you try to use the “worked together” feature, you will get tripped up.

For instance: I know a developer named Jake Savin because he worked at Userland during the period when Userland and Salon ran a blogging program together. Jake just sent me a “Friend request” and asked me to confirm that we “worked together.” I’m happy to do this; but Facebook seems to believe that “worked together” can only mean “worked together at the same company” — so if I confirm Jake’s request, Facebook seems to think I’m saying that I, too, worked for Userland. Which is ridiculous. There’s no tool by which one can express the many shades of relationship as they exist outside of a campus environment.

Facebook has garnered enormous attention from the media and from developers since it opened its platform to allow other companies to build “Facebook applications” that add new capabilities to the Facebook system. But Facebook’s social-networking design needs some basic plumbing work. Before some other company plunks down a few billion for Facebook’s hotness — or before the investment bankers take it public — some basic upgrades are in order.
[tags]social networks, facebook, friending[/tags]

Jaron Lanier’s surface-embracing vision

by

Near the end of Dreaming in Code I took a chapter to look at some of the more visionary efforts today to reform the troubled world of software development. One key portrait was of Jaron Lanier. (It was a delightful coincidence that, well after I’d settled on my book title, I discovered that Lanier had once told an interviewer, “I used to dream in code at night when I was in the middle of some big project.”)

This month in his column in Discover, Lanier uses my book as a jumping off point to discuss some of the same questions I set out with:

Why do some software projects sail to completion while so many others seem cursed? Why must software development be so difficult to plan?

These questions should concern everyone interested in science, not just programmers, because computer code is increasingly the language we use to describe and explore the dynamic aspects of reality that are too complicated to solve with equations. A comprehensive model of a biological cell, for instance, could lead to major new insights in biology and drug design. But how will we ever make such a model if the engineering of a straightforward thing like a personal productivity package confounds us?

In the heart of the piece, Lanier explains, more fully, his big idea — “phenotropics”: a software system, inspired by biology and robotics, in which surfaces “read” each other using fuzzy pattern recognition, allowing for systems that are better able to handle small variations from the norm without crashing.

Suppose software could be made of modules that were responsible for identifying each other with pattern recognition. Then, perhaps, you could build a large software system that wouldn’t be vulnerable to endless unpredictable logic errors.

He mentions Web 2.0-style mashups as one fledgling step in this direction, and also provides an anecdotal account of a project from the 1980s that he collaborated on with Andy Hertzfeld (another central figure in Dreaming in Code) called Embrace.

It’s a mind-expanding read, like so much of Jaron’s stuff. Embrace surfaces! Find patterns!
[tags]jaron lanier, phenotropics, software crisis[/tags]