Ten Reasons Why

see, if you describe RSS as something that you need a tool to write, then it's obscure, mysterious and murky... and maybe a little dangerous, because you depend on the tool. But if you describe RSS as nothing anyone couldn't learn how to do in the time it takes to drink a beer, then it enters the domain of the commonplace and safe. Sure, it's probably easier to use the tool. But it's important that people know what the tool does, and that they need not depend on the tool.

Aunt Mabel is constantly amazed at the way I can sit down in front of a program I've never used, that she uses all the time, and figure out how to solve her problem in less time than she took to find the help index. I can do that because I took that class (in the 80s, but on a Trash-80), and a few more, and so even though my last PC program was written in Turbo Pascal (and it had these separate windows, not just the full screen, just like that Windows thing we can't afford a good enough computer to run), I still know enough about how things have to be done, and how they can't be done, to know how they probably were done.

If you rely completely on Blogger or MT, then when something isn't right in Blogger's encoding, or you want to include your MTEntryMore, you'll be completely at sea, and at the mercy of the kindness of strangers who've sat around with a beer and Notepad (exactly how I produced my first RSS feed, though I was coding PHP in Notepad). If you rely completely on (imperfect) tools to do your HTML for you, then when you hit the inevitable weirdness in your tool, you'll have no idea where to even start looking for the problem.

Sure, most of the Pie/RSS heat and light is really only of concern to developers (on both ends of the feed), but for them it's vitally important ("is this < the start of an escaped tag meant to be interpreted, or is it supposed to be plain text talking about the tag?"). That's no reason why people shouldn't at least learn a little bit about what's going on under their hood, so they can at least stick a battery cable back on without having to sit on the side of a deserted highway waiting hours for AAA to show up.

Spoken like true geeks. :-)

Stephen, my point is you shouldn't have to describe RSS to a non-technical consumer at all. RSS is format; understanding that should be the realm of developers, not users. What should be described to users is functionality: "syndicate your content" and "aggregate other people's syndicated content." Aunt Mabel should never have to look at an RSS file.

I think it's empirically false that "it's important that people know what the tool does." How many people can explain how their phone works? How the electricity in their house works? How their car engine works? How their CD player works? Etcetera etcetera ad infinitum. Our world is built upon specialization of knowledge.

You need to know how to plug in your phone line, reset a circuit breaker, fill up the gas tank, eject a CD, subscribe to a syndication feed, but how many people really need to know the guts of those technologies? Knowing a little might about one or the other might save you some money someday, but we can't all be proficient in everything, and it's a waste of resources to try. Phones, electricity, cars, CD players -- these are mature technologies that have abstracted their guts behind common, usable interfaces. Why should we expect less from syndication/aggregation software? Or software in general?

Phil, Aunt Mabel is impressed (and rightly so) by your ability to know "how things have to be done, and how they can't be done, [and] to know how they probably were done."

Personally, I would be more impressed by developers who create applications that are clear and intuitive enough that Aunt Mabel doesn't need your help to solve her problem. Now, Aunt Mabel may not be impressed by those talented developers, but that's because she's not thinking about them -- which means they did their job well.

Please note, I'm not suggesting that people don't need to learn anything at all about technology. However, I think we'd agree that Aunt Mabel probably doesn't need to learn to understand raw HTTP headers to have fun browsing the web. RSS has more in common with that level of technology than "sticking a battery cable back on." Of course, I expect my car manufacturer to make battery cables that don't pop off, too!

Bottom line: I believe this burden should be on developers, not users. We shouldn't expect typical consumers that want to make effective use of technology to rely on their nephew or to rely on learning more about the guts of the technology. Rather, the burden should be placed on developers and interface designers to create software and technology that obliviates the need for the consumer (or her nephew) to "open the hood" to decipher an XML format.

I, too, am tired of reading messages that start with: "Hey, I tried this RSS thing, and all I see is a bunch of code in my browser. What am I doing wrong?" Nothing.

Clearly nobody's wrong here.

It's great to hear more folks talk about improving and un-geeking the Web experience, but what's under discussion are consumer products that don't yet exist. Greg's issue hinges on the fact that the product Aunt Mabel needs is unavailable.

To me, that issue extrapolates into "Couldn't I be closer to turning Aunt Mabel loose with this stuff if developers spent more time abstracting the guts, and less time jiggering the underlying standards?" Yes and no.

Consider that Aunt Mabel knows how to type (at least peck) an email message to my Aunt June. She can capitalize, punctuate, and mash a few carriage returns for vertical whitespace. Cool. We can easily build tools for that.

But we anticipate that our Aunts will one day want to embed hyperlinks in their text as we do, so we add that feature in the most intuitive way we know, explain it succinctly … and the old dears start to melt down. Emphasis, bolding, colors, and images present the same trouble. Is the problem that we aren't abstracting things sufficiently or that they don't want to know?

I'll agree that syndication/aggregation is a special case. Just this week I registered and now host a domain for my Aunt June (I really have one; she's 70 and lives in New Jersey), because she just bought her first PC and was in danger of getting mired in AOL email. It's better she starts out with regular MX and, say, Outlook Express, than be tangled in that morass. Last night I told my slightly savvier parents about the plan, since I similarly dug them out of the AOL-hole six months ago. They said, "Yeah, but we don't know where to start any more. It's a blank window now." There's something to this, something that Steve Case understood.

So taking RSS alone, I'd agree that private aggregators and sturdy auto-discovery are an urgently needed bulwark against commercial channel penetration. Yet I can't help also knowing that the alternatives I'd propose aren't ready — not on the terms Aunt Mabel needs or wants — and over-geeking is only a part of the reason.

One last thing. I'm only 24-hours into this realization, and it's painful: our Aunts want WYSIWYG, so do most folks. That's where the hot poker touches singeing flesh in this holy-war torture chamber. A WYSIWYG abstraction layer is probably where it ends.

Enter XUL.

>Users should never have to think about how RSS or Atom feeds are formed

This is true.

>one of the most nonsensical tidbits I've seen is the argument that RSS is better because it's "human readable."

This is not nonsensical - Programmers are human. Shallow xml will always be more readable to programers (who after all - need to write tools that will read and write xml) than deeply-nested XML. This issue isn't about the end-users, its about how easy it will be for developers to write tools (in Perl, Python, Java - whatever) that will process the format.

I can tell you that when I show other teachers how I made my class paperless in large part by aggregating my students RSS feeds, I never show them the code. I tell them they don't really need to know how it works, that the software takes care of it, and that all they need to deal with is getting the right address into their readers. 1. Click the XML button. 2. Copy the address that comes up. 3. Paste it into the aggregator. 4. Start reading. 5. Have a beer.

Like Greg, I've stayed away from that whole Echo/RSS thing because frankly I don't have the time to really care as long as whatever comes out of it does what RSS does for me now.

Walter, that's what IDEs, validators, etc. are for. Programmers are users, too! Just far more specialized users. ;-)

Anyway, I think "for the sake of the programmers" is a bogus argument. When people talk about RSS being "human readable" they're not claiming it's "human readable" in the way C++ code or a Perl script is. Programmers are certainly capable of "reading" things that are far more complex than RSS, so I don't think we need to keep syndication formats dumbed down for the programmers.

Rather, the "human readable" argument is invoked with the comparison of the early days of HTML and being able to learn to hand-code your own HTML by using the View Source option in browsers. Fine. That was great. It's how I learned HTML.

But it's not 1995 anymore. The people I want to reach with the technology are the kind of people who wouldn't have touched a computer in 1995, not the ones who were viewing HTML source and figuring it out on their own. Suggestions along the lines of Phil's ("hey, they should learn more about how the computer works") have about as much resonance for Aunt Mabel as suggesting she learn to rebuild a transmission or lay bricks.

Weblogs authoring tools are becoming popular precisely because they make knowing HTML irrelevant to publishing a frequently-updated, interactive, sticky website. So why do some people feel that knowing how to read/write an RSS file is relevant?

Will, actually developers should collapse steps 1 to 3 into a single auto-discovery step.

Sorry but I have to disagree with you. People do want to see and understand RSS feeds. First you have the so-called "view source" phenomenon. More people have learned more HTML and JavaScript by viewing other people's source than any other way. If HTML and JavaScript weren't human-readable, this would have been a great obstacle. Second you have the "try this" phenomenon. More people have figured out more stuff on the 'net by simply trying stuff than any other way. I've coded a bunch of CGIs just by trying stuff. If it wasn't all text, it wouldn't be nearly as easy. Third there are a lot of bloggers who don't use Radio or Movable Type. I happen to have a home-grown-CGI blog. Which means to provide an RSS feed I have to know what they look like. And the easiest way is by looking at existing ones...

Look, simple things work. RSS right now is really simple. That's a good thing.

Ole

Ole, I have to disagree.

As a consumer of RSS, yeah, it's quasi-human-readable, but ... I'm going to let an aggregator parse all the code for me.

Yeah, I can read HTML too ... and when "reading" it, I filter out the tags and try to read the content.

But 999 times out of 1000, I'm going to sit there and be happy to let my Web browser parse it all so I spend less time reading the content.

The only time I'm going to want to see the tags in context is when I'm trying to figure out what was done--whether a nifty XHTML/CSS trick or trying to figure out what's borked with the RSS feed [which is the only time I look at RSS feeds *anyway*].

And that one-in-a-thousand happenstance is not me being a user ... I've then slipped over to the geek world.

I geek enough at work. When I'm being my normal happy consumer self, I don't really care what's under the hood. And while I know how to change my oil, I'm happy to hand the guys at the local lube shop $30 to change the oil and keep my hands clean, thankyouverymuch.

It's true that nobody needs to know how to hand-code or read RSS. It's definitely a power-user thing, but I see it as giving web authors a chance to be not totally dependent on a publishing tool.

What would be really nice for hand-coders is if RSS had a
'quirks mode' like HTML. I know this is blasphemy, for I see the reasons why XML must validate, but anyone can write a web page without playing the My Standards Are Bigger Than Your Standards game. RSS is useful, and anything that gets it into the hands of more people is, in the immortal words of Martha Stewart, A Good Thing.

How high should Pie/Echo/Atom/Whatever set the bar for readability?

RSS 1 is pretty hard to read. RSS 2 is quite a bit easier. I've tweaked an existing RSS 2 template, but decided I didn't want to mess with RSS 1. I am modestly technical.

Yes, non-technical users should not have to worry, and yes, it would be nice if the tool could handle every imaginable manipulation you'd like to impose on your feed. There's probably a power-of-ten law for users: for every 1 serious geek there are 10 power users; for every 1 power user, there are 10 "black box" users. Or something. The question a lot of people are asking here is "What you do for the power-user constituency?"

The problem with this thinking is that it creates an artificial divide between "users" and "developers". The point of the web it its easy for anyone who is interested enough to interact, even write a script or two. No Microsoft or Cisco certification required, no masters in computer science required. Period - if HTML was complex and not human-readable, we'd be using the Microsoft Network right now.

Ole, the "view source phenomenon" and "try this phenomenon" ceased being relevant years ago. The only people that "view source" are those that already have an interest in learning about the underlying code. Just the interest in trying to decipher the source or write a CGI script (!) puts them in a tiny minority of all consumers. People who position "human readable" as a threshold that must not be bypassed are either (a) thoroughly ignorant of how non-technical users relate to technology or (b) potentially acting out of self-interest (e.g. keeping the technology dumbed down to their level keeps them from having to rely on other, more skilled technologists).

Out of all the hundreds of millions of consumer computers on the planet, how many of those users do you suppose write CGI scripts?!? For every person that codes their own home-grown blog, there are hundreds of thousands (if not millions) who don't. The demand for content management systems (both enterprise and lightweight, blog-style CMS's) comes from the need to provide ways for users to create and author web content without touching the underlying formats. You're suffering from the inability to extrapolate past your own nose. Your computer experience is not that of Aunt Mabel. The few exceptions to this situation don't invalidate the generalization: most consumers don't give a rat's ass about HTML, CSS, RSS, or name-your-acronym.

Chad, sure a lot of web-scripting is easier than getting Cisco certification. See the above response to Ole: the fact that a minority of users on the web want to create scripts, doesn't invalidate the truth that understanding scripting -- like understanding HTML or RSS -- is irrelevant to the majority of people who use the web.

Chad & Ole, is it possible for you to comprehend that arguing against something does not equate to arguing for its converse? I have no problem at all with RSS or it's simplicity. I do have a problem with people who try to hold back more complex solutions through adherence to a ridiculous doctrine of "human readable" code and the "view source" smokescreen.

Greg,
When talking about XML being human-readable, I don't think anyone seriously considers it to mean "user readable" - do you ?
For "Human readable", read "Developer readable". From a developer pov, XML is good. XML which isn't deeply nested is even better.

Walter

Personally, I'm willing to suffer with a slightly more unreadable format as long as it provides a syntax which will be digestible by a lot of software. The incredible laxness of HTML is great in that it allows for a lot of pages to get built quickly, but it also makes the content a lot less likely to escape it's web page bonds. Anyone ever fool around with creating a custom HTML renderer?

Hopefully, RSS/Atom/Whatever will make it's way into whole new types of software, and will be exposed by all new types of information sources. We're going to need software to do rich things with that content, and a lot of it will probably be written by a guy w/ notepad and a beer. Possible a latte.

Walter, I give you this:

"And since users are explaining [RSS], it matters less what developers think. This is the magic part of RSS. It was designed so that users could understand it." -- Dave Winer

Or just look at Stephen's comments at the top of this thread:

"[I]f you describe RSS as nothing [sic] anyone couldn't learn how to do in the time it takes to drink a beer, then it enters the domain of the commonplace and safe."

Stephen can correct me, but I don't think his (or Phil's) use of "anyone" was limited to developers.

Again, for the record, I'm not an opponent of the simplicity of RSS. I think Stephen's tutorial is great as an exercise for developers. But it really has little real world use, because in the real world, users don't code RSS.

RSS's simplicity has certainly helped its spread, but it has also been the source of a lot of the struggle around it, as many of it's proponents are opposed to making RSS itself more complex, or even having competing formats that are more complex. I am opposed to using that that simplicity of RSS as an argument against complexity of other approaches. Such approaches are not mutually exclusive.

Greg,
I think we agree on more than we disagree. As an independant producer and consumer of RSS (using perl code rather than tools) , I'm comfortable with the format - I haven't touched the perl code since I wrote it. I just don't want to touch code for the same end result if/when the new format supercedes RSS.

OK, first, minus two points for sticking a [sic] into a perfectly good sentence.

Next, I am in general agreement with the argument about people not needing to, or wanting to, look under the hood. In my paper
Nine Rules for Good Technology I expand on this at length.

But...

The context in which I wrote the article was as follows: Technology Source ran some RSS articles and naturally thought about creating its own RSS feed. So I started getting questions about how much it would cost, how much programming time was required, what software would be needed, etc.

That's when a nagging doubt became clear to me: though RSS started out as nearly perfect technology, it was being mystified beyond recognition. I needed to make it seem simple, because, at heart, it *is* simple.

Heck, it would have taken me less time to write an RSS generator than to write the article. It would have taken much less time to point to an RSS generator. But then the people at Technology Source would be natural prey for vendors who would insist that they must have this and that feature, and would pay much too much for software which is in essence so simple it ought to be free.

So I wrote the article. I realize that most people don't want to look at the source. I realize that most people want to use an easy authoring tool. What I wanted to say was merely that they *could* if they wanted to.

There's a lot of freedom in that. Try creating an MS-Word file with a plain text editor (any plain text editor, not just MS ones). Try creating a PDF file by hand. When you lose the possibility of creating the file yourself, you are now bound to the format, locked in to the vendor.

There is a serious danger of this happening in RSS. Technorati won't harvest OLDaily because my blogging software doesn't ping them. My software - like everything else on my site - was written by hand. Yes, sure, I could start pinging and trackbacking and blogrolling and so on like everyone else. But I don't think I should, and I don't think these things should become inherent to RSS.

I don't think so because they take away our independence. They tie us to supporting particular vendors, particular sites. Why can't Technorati harvest my blog like all the other people out there? Why can Fred's blogging tool harvest my feed and *look* for a reference? Pinging is undemocratic: it concentrates power into the hands of the few, and takes RSS - and blogging in general - out of the hands of the people.

Think about it. Why did RSS succeed where so many other XML formats have languished, shriveling on the vine? Because RSS became a *people's* format. A few simple tags, into which you could stuff, well, almost anything. No special tooks, no panels of experts saying you must create your feed according to highly refined directives. Even Dublin Core, which ought to have filled this role, is falling victim to official implementations and ISO sanction.

The point of my article was never to tell people how to create an RSS feed, or to suggest that they create one by hand, or anything else like that.

It was intended to give people back that which belonged to them in the first place: their content.

Stephen --

As I said in the original entry, I didn't expect your intended audience was the average "Aunt Mabel" user. I just used your tutorial as a jumping off point for what has become a fairly interesting conversation.

You wrote: "When you lose the possibility of creating the file yourself, you are now bound to the format, locked in to the vendor.There is a serious danger of this happening in RSS."

Can't happen soon enough for me!! :-)

I'm only semi-serious, but generally speaking, you don't get usability (for users, not geeks) until "the possibility of creating the file yourself" is eliminated.

As long as software vendors are focused on the possibility of the users creating the file themselves, they are focused on geeks, not mainstream users, because mainstream users have absolutely no desire to create the file themselves.

The best thing that could happen to syndication/aggregation technology is to eradicate any thoughts of "the possibility of creating the file yourself" and move on from there!

You wrote: "Think about it. Why did RSS succeed where so many other XML formats have languished, shriveling on the vine? Because RSS became a *people's* format. A few simple tags, into which you could stuff, well, almost anything."

Caveat: I don't think RSS has succeeded yet. It's on its way to potential success, but it's still a little known format only used by a relative few Internet users -- mainly a subset of webloggers which themselves are a tiny, tiny subset of all Internet users. Compared to major-league communication mechanisms like email or instant messaging or even Usenet/NNTP, RSS is playing bush league single A ball in Dubuque, Iowa.

The point that I've been repeating ad infinitum is that RSS did not get on the road to potential success because it's a "people's format." RSS has gotten traction because

1. Weblog authoring tools have shown some traction by burying the complexity of frequent, regular, granular web publishing behind a simple, forms-based interface, and
2. Those same weblog authoring tools automated the creation of RSS feeds for weblog authors

If weblog authoring tool vendors hadn't adopted and automated RSS, it would still be a format languishing in Netscape limbo. Bottom line: A human-readable format is not necessary to make RSS popular. It is made popular by making the underlying XML format irrelevant to the human user, as evidenced by the increase in RSS usage as soon as tools existed to absolve users of having to create RSS files themselves

P.S. The phrase "nothing anyone couldn't learn" contains a double negative. The grammatically correct phrasing would be "something anyone could learn." Hence the [sic]. :-)

My Aunt Mabel doesn't know how to do auto-mechanics, but she does have a nephew or two that are handy under the bonnet.

One day her car doesn't work. She calls nephew Bob, he takes a look under the bonnet and says "Well, it's all controlled by some microchip embedded inside that lump of black resin. Nothing I can do to fix it. You'll have to take to the Official Rip Off Service Centre".

I've got lots of friends/relatives that know I'm a bit of a geek. They don't know squat about their 'puters. I don't ask them to. I do ask them to not buy some pile 'o crap MS box which when things go wrong I know next to nothing about how to fix. I ask them to buy something which is easy to support.

Same with cars -- I recommend against foreign models where parts and service will be hard to find. I don't expect them to fix them themselves, but knowing they can readily find someone else when it matters does matter.

Eric, your anti-Microsoft screed is a bit off topic in a conversation about RSS, but you do illustrate the narrow-mindedness of the geek position quite accurately. "Easy to support" has little real-world relation to "my (or my nephew's) realm of knowledge." because that's an unscalable model of approaching technology in the mainstream. There are several orders of magnitude more Aunt Mabels than Nephew Erics.

Besides, this isn't an issue of support, but an issue of usability. Effective usability decreases or eliminates the need for support. E.g. Aunt Mabel needs a car that doesn't need to be explained to her or doesn't need servicing. Provide that, and easy availability of parts and support becomes a meaningless criteria. Likewise, Aunt Mabel needs software that she can use without having to call Nephew Phil or Eric to set it up or explain it to her. RSS isn't there.

Here's the crux of the matter: to solve real-world technology usability issues, you have to start from the premise that there won't be a geek nephew available at all.

Finally, I'd recommend taking a look at this recent post on Pito's Weblog: http://radio.weblogs.com/0125664/2003/08/17.html#a46. Pito hits the nail on the head. You're stuck in the evangelist phase. Let go. It's time to grow the technology for non-techies.