clock

Watching time, the only true currency // A journal from John B. Roberts

Day: November 26, 2005

  • Be very careful using a URL in your headline, especially if you don’t own it!

    I’m amazed at the mild foolishness exhibited by a NY Times headline writer in this article: “Wishyouwerehere.com: Blogs From the Road.” That’s right, the headline writer put a URL in the headline, which leads to several problems.

    1. The URL in the headline is nowhere in the article (either page). That’s appropriate (see #2), but confusing.
    2. The URL wishyouwerehere.com goes somewhere unrelated to travel blogs, which are the focus of the article. It’s not anything salacious, fortunately, just a UK-based production company, Fremantle Media, who’s (hopefully) thrilled with a small (?) amount of unsolicited traffic to their corporate website.

    We’ll hope that Fremantle Media keeps up their domain registration, so the domain farmers don’t swoop in later.

    Does the copy desk at the NY Times really not have a web browser available to them? Or, worse, they do, but never stopped to consider these outcomes?

  • I don’t want everything to be full-text

    I use my RSS feeds as notification. I want to scan.

    I want to somehow squeeze the juice out of a couple of hundred feeds, leave the pulp behind, and spend the real time on the six to nine posts a day which are worth three to five minutes each. Full-text can interrupt the scan. Even full-text has to earn the “launch to browser” action. Most stuff worth reading ends up in a browser window.

    Different tools and contexts matter. If I ever did anything offline, maybe I’d be crazy for full-text, but I think of those rare moments when I’m away from a computer as deliberate, so why not enjoy the connection and the focused reading experience available in a browser?

    I’m bringing this up because Scoble is again sharing his preference for full-text feeds. In Back to reading feeds…, he notes he’s cleaning out his blogroll. (And, now he’s done.) The first criteria for elimination?

    Any feed that doesn’t run full text. Except for the New York Times.

    I disagree, as noted, but then I don’t spend oodles of time on airplanes or other in a disconnected environment. For more of my opinion on this topic, read my earlier posts on this subject… easier to link than repeat myself.

    Aside…If I were really an attention geek, maybe I’d throw off a feed with every RSS item which caused me to spawn a browser window. You get the juice, without doing the squeezing yourself. Reality is, you’d want to combine my “juice” with that of other folks you read and (presumably) trust, and see whether you end up with truly refined sugar, or simply more juice to drink. More juice takes more time… which is part of the problem attention is trying to solve. So refinement is the answer.

  • Are you sure we should make a fuss?

    At first glance, two posts on successive days from the smart folks at 37 Signals are in opposition.

    First, there is “Do Fuss:”

    Spend the time. Put forth the effort. Make it great.
    (snip)
    Well, if it’s just a little thing, then fixing it is just a small matter!

    In other words, details matter and are worth the effort. I agree, even when I can’t live up to the ideal.

    One day later, a different member of the 37 Signals team explains why simple features are not always such “small matters” in Revealing hidden assumptions in estimation:

    Imaginary work is always easier to do than real work.
    (snip)
    Next time you find yourself thinking something ought to be simple to do–whether in a project of your own, or in someone else’s–pause for a moment. What assumptions are you missing? What real work are you overlooking because the imaginary work is so much more attractive?

    I’m happy to give credit to 37 Signals. I use Tadalist quite happily, and hear good things about the other applications.

    Still, I think I think the posts, in combination, demonstrate a push-and-pull in play. “Do Fuss” is aimed at other developers, ostensibly, but may be applied far beyond software. “Reveal…” speaks to developers’ tradeoffs, but feels like a warning to customers, too.

    I guess I’m asking… do you want us to make a fuss or not? Or only about our own work, not yours?

    That’s not a fair question, of course.

    Remember, though, people make a fuss about things they care about. Customers who make a fuss do so because they have a frisson of recognition when using an application that in some fundamental way matches their expectations or needs. (Even the needs they didn’t know they had until that moment!) That recognition is rare enough, I think, that it inspires incredible excitement. You feel “Finally, someone who understands me and the way I work/play/create/consume.” However, all customers move quickly on to the next stage, which is “if it only did _____, I’d really be happy.”

    In most scenarios, only that second stage gets communicated to the developers. But the second stage is never reached without passing through the first stage. Developers must remember that process, and hear the (too often) unspoken thrill their customer felt in the first stage in the background of their complaints, nudges, and requests in the second stage.

    Developers should fuss about their work, and be glad someone else fusses about their work, too.