Bryan Bell has notes from MacRumors about the RSS capabilities of Safari. Apparently you can search the contents of the feeds. This is something Steve Gillmor has been asking for, for ages. Feedster on the Desktop. Of course it can only search the feeds you’re subscribed to.

Geez, what contemporary aggregator doesn’t do this?!?
Oh, yeah. Radio. Duh.

One such candidate is peer-to-peer, as resurrected in the form of Bram Cohen’s BitTorrent. It’s an elegant protocol for distributing files, one that takes advantage of “the unused upload capacity of your customers.” BitTorrent breaks up files into shards that are uploaded around the network as the file is downloaded by multiple clients. The more popular a file, the more endpoints exist. You download a file with BitTorrent by simultaneously collecting shards, assembling them together locally as they arrive.
Map this to RSS feeds: the more popular the feed, the more nodes on the network serving pieces of the feed. That would allow rapid downloads by many users by distributing the data across multiple sites. It’s a digital Robin Hood, redistributing the wealth from the server to a network of peers. BitTorrent does cryptographic hashing of all data, so feed owners can be confident the file reaches its target unchanged.

Link via Scripting News.

For the record, the less-than-perfect status quo is an interface for syndication and aggregation (the orange-on-white XML icon) that:

• doesn’t communicate anything about its function to the average, non-technical Internet user
• links to a file (the XML-formatted RSS feed) that is meaningless for most users
• to use requires a procedure (right-click, copy link, paste link into an aggregator) that is neither automated nor intuitive

Why is improving this interface important? Good interfaces help good technologies grow. While I recognize that a good interface won’t save a bad technology, and that many good technologies have overcome horrendous interfaces, that really doesn’t excuse saddling a good technology like syndication/aggregation with a bad interface.
Crazily, in defense of the leaving the orange XML icon alone, Dave Winer said

How many people click on things they aren’t interested in? I don’t. Too busy. I might, if I knew nothing about XML, click once, after seeing them pop up in lots of familiar places, seeing something I don’t get, click on the Back button and remember not to go there again.

The unfortunate fact is Dave is right about that — those that are curious will click, and if they’re confused they will go away and not come back again. In my book, going away and not coming back is a problem.
Contrary to Alan’s graphic (”Oh dear! Just what does these things mean? Do I dare click them? I am scared!”), the concern isn’t that people will be “frightened” to click on the XML icon. As a producer of content, I want an interface for syndication that encourages and educates my readers to get involved with syndication and aggregation and to use it effectively — not an interface that encourages the uninitiated to never go there again!
The current interface is exclusive, it’s for the people “in the know.” It assumes that you already know what the icon and the acronym mean and what to do with marked-up text behind it. It communicates nothing to people unfamiliar with syndication and aggregation (never mind being familiary with XML). If your typical consumer learned to use it, they learned in spite of the interface, not because of it. They learned because someone else had to teach them to overcome the counter-intuitiveness of the interface.
Now you’re asking “So why are you against VersionTracker using the icon to link to explanatory text?” Simple: because it breaks the interface for those in the know. Someone who right-clicks on VersionTracker’s orange XML icon and pastes that URL into their aggregator won’t get subscribed to the feed. My goal is to encourage a new syndication feed subscription interface that is more communicative and more effective for readers who haven’t been educated on the purpose of the orange-on-white XML icon . . . while not breaking the legacy functionality for those already in the know.

My advocacy here is on behalf of syndication. I don’t want to get into technical arguments, unless they’re about language, which is where my own technical expertise lies.
Yesterday I said I thought Nova Spivak’s “meta” talk was too vague, and that “syndication” was a better word to describe what RSS (which he likes) does.
While “syndication” may be more specific, however, today I’m not sure it’s not misleading, unless we redefine it, which I think we can.

And the day before:

The act of syndication is a statement about the willingness of something to be known. I think that’s the key. This “meta” business sounds to vague to me. When I explain RSS to people and use “metadata,” their eyes glaze. When I use “syndication,” their eyes shine, because they know exactly what I’m talking about. It’s a real word.

In my experience, emphasis on the XML aspects of syndication induce the same kind of eye-glazing.
I’m not sure where Doc stands on the little orange icon, but shifting the focus onto the process of syndication and aggregation is the right direction. Focusing on the value of and removing technical impediments to that process (as opposed to making the process all about the data format that makes up its guts) is what will take the tech mainstream.
[Note: I orginally drafted this post on Monday morning, but didn't post it until this morning (Wednesday). When doing so, I forgot to change the Authored On date, so, chronologically, it got posted two days in the past. I've updated the timestamp to indicate the actual posting time, not the time of drafting.]

We don’t really need a content to rename RSS. Another acryonym — who cares? Technology is already acronym soup.
We *do* need a contest (or something) to get rid of the orange XML button that links to a bunch of gobbledy-gook. Yes, gobbledy-gook. *I* know it’s XML, I know how to parse XML with my eyeballs . . . as does only about another 2% of the consumer population. (And I think that’s a generous estimate.)
Dave Winer says:

“[I]f you let your mouse hover over the white-on-orange XML button, a tool tip will appear that says: ‘Click here to see an XML representation of the content of this weblog.’
Now I assume something that you may not assume, that my reader is intelligent, and if they don’t care about XML, or don’t care to see the XML version of the weblog, they will either ignore the icon, or check it out, be puzzled, and get on with their life.”

That’s really condescending, IMHO.
There are bazillions of intelligent people who “don’t care about XML” and “don’t care to see the XML version of a weblog” and wouldn’t understand — and shouldn’t have to understand — the meaning of “Click here to see an XML representation of the content of this weblog.” Lack of familiarity with XML or RSS isn’t a sign of a lack of intelligence.
In fact, the entire success of weblogs is a result of software that abstracted the coding and tech-know-how necessary to frequently update a websites content and replaced that with an easy-to-use form-based interface . . . absolving intelligent non-technical people from having to waste precious time becoming an expert in something as mundane as HTML or FTP, removing the technical obstacles to using the Internet as a medium to communicate their passions.
The orange XML icon is simply bad user interface design. It doesn’t communicate its purpose (except to the few already in the know). By assuming prior knowledge of acronyms and technology, it’s an interface that excludes, instead of one that includes.
What would be better?

1. A “Syndicate” or “Sydication” icon instead of an “XML” icon. “Subscribe” would be even better than “syndicate,” although there would likely be confusion with email subscription. I’ve written about this before, of course.
2. A pop up that says “Click here to subscribe to this site’s content in your news aggregator” — much more explanatory than “See an XML representation.”
3. Functionality that, when clicking on the “syndicate” icon, automatically launches the local machine’s default aggregator and gives the user the option to subscribe.
4. Absent a defined default aggregator, drives the user to a feed styled with XSL and CSS a la Mezzoblue’s experiment: http://www.mezzoblue.com/rss/2.0/ (Yes, this page is a valid RSS 2.0 feed — view the source if you don’t believe it)

Number 1 and 2 are mind-numbingly easy. Number 4 is do-able with most of today’s technology, and weblog vendors could make it easier.
Number 3 is probably problematic without further definition of the technology.

• Plugging the RSS Usability Hole [Link via Lockergnome's RSS Resource] re-affirms the lunacy of the little orange XML box as the primary interface to content syndication feeds. I wrote about this extensively back in the summer [chronologically: 1, 2, 3, 4, 5] Kudos to the author, David Shea of Mezzoblue, who actually does something to solve the problem: a true human-readable RSS feed. Yes, it looks like a regular web page; that’s the point. View the source, though, and you’ll see it’s just the RSS 1.0 XML file rendered via XSL and CSS.
• The End of RSS [Link via Stephen Downes' Online Learning Daily] talks about the irony of RSS success: ” Herein the black hole of RSS: If your feed works, if you are successful in attracting subscriptions on a global scale, if you do it right, you are doomed.” The problem isn’t RSS itself, but rather that much of the RSS aggregator software doesn’t properly follow protocols, downloading the feed even if it hasn’t changed, thus consuming unnecessary bandwidth. Is it any surprise that Radio Userland appears to be one of the most eggregious abusers of the protocol? Doubly ironic, since Dave Winer lodged complaints about the bandwidth burden of his feed being accessed too frequently.

]]> http://www.tenreasonswhy.com/weblog/2003/11/rss-and-its-discontents/feed/ 4 http://www.tenreasonswhy.com/weblog/2003/09/naming-rss/ http://www.tenreasonswhy.com/weblog/2003/09/naming-rss/#comments Sun, 21 Sep 2003 16:39:13 +0000 Greg http://www.tenreasonswhy.com/weblog/?p=555 Daniel Neely writes

Mixing one acronym with another, is just asking for puzzled looks by your readers. It’s bad enough that a person still looking for the “Any” key needs to associate just one acronym with content. I think it’s quite absurd to tell people to “click the XML button to get the RSS feed!” It leaves too many people scratching their heads and saying, “Huh?” Not a good thing if you’re trying to reach a not-so-tech-savvy demographic. [link via Lockergnome's RSS Resource]

Absolutely! I think Neeley is identifying the problem appropriately, particularly the idiocy of misleading orange acronym button. Although, I don’t think his solution (replace the acronym soup with the term “feed”) is the best solution.
It’s amazing that we have a perfectly good term — subscribe — that the mainstream understands to mean “receive regular updates to this publication,” but we don’t use it for content syndication via XML formats. Perhaps it has too many connotations related to subscribing to email ists?
“Subscribe” is a term that is much more accessible than “RSS” or “XML.”

Jon Udell expresses doubt that RSS will replace email. His mail argument is that his current combination of spam filters work fine (though his email account is groaning under the volume). “It would be nuts,” he writes, “to throw out the SMTP baby with the spam bathwater,” though some tweaking (to verify that the sender is allow to send from that address) amy be needed. I don’t agree, and here’s why. In general, it seems to me, technologies that allow other people to put content into your space are unstable. On the other hand, technologies that allow you to get what you want from remote locations have been much more successful. SMTP is a put-type technology, while RSS is a get-type technology. It doesn’t mean that RSS will replace email. But something will.

While Stephen is more or less correct about the put/get difference, I can’t agree with his estimation of their comparitive value.
As opposed to the put/get dichotomy, I prefer to think of it as the difference between sender-initiated communication and recipient-initiated communication.
What Stephen calls “put-type technologies” are successful and useful because they allow the sender/caller to initiate communication. For example, IM and phones are put-type communication mediums, although synchronous forms, as opposed to the asynchronous put-type communications of email and the traditional letter. Sender-initiated communication is valuable because it generates a much higher likelihood of response than a medium where the individual who wants to get information out has to wait for his or her recipient has to request the communication because it eliminates the discovery component of recipient-initiated communication. E.g. if I want to subscribe to your RSS feed, I have to know where to find that feed first. If I want to check out a book from the library, I have to be able to find the book in the stacks (and find the library!)
Of course, the risk associated with sender-initiated communication is that sometimes senders we don’t want to communicate with will initiate communication with us — phone solicitations, email spam, etc. However, people accept this risk because the inconvenience of filtering out the unsolicited communication is less than the inconvenience of the discovery component of recipient-initiated communication. When I need to share a bit of important business information with a colleague, I want the additional security of putting it in their inbox instead of waiting for them to come to me. When my loved one is in the hospital, I want my phone to ring — I don’t want to wait five hours or five days to check to see if I’m needed.
Jon Udell’s more recent follow up column on the subject, E-mail’s special power points out another value of email that I hadn’t considered, it’s instantaneous group-forming capabilities:

Every interpersonal e-mail message creates, or sustains, or alters the membership of a group. It happens so naturally that we don’t even think about it. When you’re writing a message to Sally, you cc: Joe and Beth. Joe adds Mark to the cc: list on his reply. You and Sally work for one department of your company, Joe for another, Beth is a customer, and Mark is an outside contractor. These subtle and spontaneous acts of group formation and adjustments of group membership are the source of e-mail’s special power. Without any help from an administrator, we transcend the boundaries not only of time and space but also of organizational trust.

Will RSS replace email? I’m with Udell; not a chance. I don’t think Stephen believes RSS (or whatever content syndication mechanism we wind up with)will replace email, but I suspect we agree that it will become an effective alternative for a narrow band of email functions, like newsletters.
However, I do believe our best geeks will escalate the cold war with spammers to provide better software code for filtering . . . and eventually the government will alos step in to attempt better legal code. I’m not saying it’s easy, but I am saying that sender-initiated communication mechanisms, including email, will not be replaced by recipient-initiated get-type technology.
You heard it here first. ;)