9/16/2010; 5:57:04 PM.   .

This is a follow-up to the 16 Media Partners piece from Tuesday.

Doug Williams, in a comment on the previous piece in this thread, said: "As was communicated at the event, we are taking open requests for partnerships at contentpartnerships@twitter.com. Even if you aren't content or application owner, I'd enjoy hearing what you would like to see enabled in the detail pane. For a number of business, legal, and technical challenges, providing open access to the detail pane does not make sense at this time."

How Twitter has lost its way. They used to have a wide-open content platform, you could flow through anything you wanted on a completely level playing field. Now, they're talking "content partnerships."

If there were legal or technical challenges, how could search engines provide access to graphic content? There's even an open format for embedding these objects. The really good-for-everyone approach would have been to just support that, and test with your partners, and then we can all scramble to make sure it works with what we do.

I don't even see the business reason for not processing anyone's content, unless they're charging their 16 media partners, which seems backwards. After all, twitpic, yfrog, et al are storing the images, and effectively having their ads scraped.

As for what was said and wasn't said at the event, I wasn't there -- and the video feed was only what Scoble could scrape together. Someday we'll be adults here, and really explain what's going on, not blow smoke in each others faces.

 9/16/2010; 12:48:04 PM.   .

A few days ago I wrote a piece about how to reboot RSS. A lot of people read the piece, and asked me to expand on the ideas from a technological point of view, which I'm glad to do.

To begin, let's review the architecture of RSS.

Here are the basic concepts.

1. Feeds. They come from lots of places. Blogs have feeds. News organizations have them. Sources for news organizations have them. Even Twitter provides its content in the form of feeds. I have a feed from my stock broker, and from Netflix, recommending new releases I might want to watch. Amazon offers me deals. I subscribe to a feed from the NOAA that tells me about the hurricanes, as the news becomes available. This is the same feed that the Times and Reuters and AP watch. I get news from a huge number of tech blogs. From English-language news sources in Europe and Asia. I get radio programs, links to new software downloads. I even follow a few Twitter users whose updates I don't want to miss. I subscribe to feeds about the place I live now, and places I used to live. And of course feeds from friends I want to keep up with. All of this and much more comes to me through feeds.

2. Feed items. Each item in a feed has several bits of data: A title, link, description, publication date, identifier. Not all are always present. And there is other data that is less common but also appears: An enclosure, categories, a pointer to the source of the item (if it was republished).

3. Feed engine. It reads a collection of feeds periodically, and from that collection produces a stream of new content. There are lots of them. There's one embedded in every feed reader. I've written several.

4. Subscriptions. Each user has a collection of subscriptions, which can be edited. You can subscribe to a feed, which is most commonly done when you're viewing a website and decide to add it to your collection. You can decide you no longer wish to see items from a feed, or unsubscribe. This usually happens when you're reading feeds.

5. User interface. There are lots of ways to read feeds. There's the hierarchic approach favored by Google Reader and NetNewsWire (examples). There's the River of News approach that I like. You can have feed content emailed to you, or SMS'd, or read it in Twitter or Facebook or Friendfeed. There are many other user interfaces for feed reading.

Feeds and engines, and the tools that generate feeds, are independent of each other, and this is a good thing. You have your choice in every category. But there is one place where having choice makes RSS weaker and harder to use, and that's in the act of subscribing to a feed.

Here's the scenario. I'm reading a news article and realize this is the seventh time in the last two days that I've been at this site, and I really like the way they cover the news. A thought forms in my head: "I want to subscribe." This is where the user experience can get confusing. It's different for everyone. If the site provided a link to subscribe in your favorite reader, it's easy. But if they didn't, and if you haven't installed a bookmarklet, you're in for some copying and pasting, navigating and waiting. And you'll lose your place. Most of the time you decide not to bother. And the use of reader-specific links reduces the number of choices, and this is where the stagnation in the RSS market came from. This, the act of subscribing, is the act that we have to make more fluid, easier, more satisfying, faster.

It's important to say that I am not proposing any changes in the architecture of RSS. I am however, proposing that some new software be built, with the aim of making RSS easier to use, more reliable, and to create a more diverse marketplace with lots of opportunity.

And that's where I'm going to stop for today. There are more pieces coming, if there's an interest.

 9/16/2010; 9:23:51 AM.   .