I’m unclear why this has happened. The URLs for the feeds should still be in the same place. All of the articles that were in the old feed are still in the new feed. I did mess around in the database and fix a number of GUIDs (Globally Unique Identifiers, for those non-geeks in the audience) that were pointing to a temporary address. But that should only have affected your feed reader’s ability to mark the entry as read or not read.

At least you can delete and re-add the RSS feed to your feed reader. The syndication for my Amazon blog broke altogether several months ago, and my message to the Amazon technical support staff seems to have fallen into a crack in the Earth somewhere. Now I’m stuck adding new entries to my Amazon blog by hand.

Why is so much technology so goddamn fragile?

I joke about this all the time with my web programming customers. Chances are that if you see something drastically wrong with the website I’m managing — layout all fucked up, images floating all over the place, everything completely unreadable — it’s the fault of a single misplaced comma somewhere. Other industries don’t have this problem. I mean, if you’ve got a single board nailed crooked in your house, the whole thing doesn’t fall to pieces.

This fragility is one of the whole reasons why it makes sense to move websites to CMS’s like WordPress or Drupal, or application frameworks like Ruby on Rails. Setting up a framework takes the gruntwork and repetition out of web programming, and it insulates you from fucking up the whole website by sticking a comma in the wrong place. Mostly.

The reality of the matter is that web technology is still on a very low rung of the evolutionary ladder. We’ve got application skeletons and frameworks galore, but you don’t see a lot of application musculatures or nervous systems. Most software can’t repair itself — and even when it can do rudimentary repair work, like replacing accidentally deleted files or Windows Registry entries, it’s not smart enough to know when it needs repairing. My Firefox browser is now smart enough to automatically restore all of my tabs when it crashes, most of the time — but about 20% of the time, the browser still isn’t even smart enough to know that it’s crashed, and I have to open the Windows Task Manager and manually kill the process that’s not responding.

And so I find working on web technology really fucking frustrating because it’s fucking broken so much of the fucking time. The web is full of dead links because the mechanisms for propagating electronic changes of address are sucky. Pages break on different browsers and operating systems because nobody — not even Mozilla — implements all the W3C standards correctly, and it’s quite difficult to make a website degrade gracefully.

I get a little melancholy when I start to think about these things, because I realize that I’m not going to live long enough to see the really cool stuff. None of us are. Technology can be maddening and frustrating today, and it’s going to remain maddening and frustrating for a long time to come.

So my question today is this: what do you find useful on an author’s website? I think we can all agree that excerpts help, and at the very least, having a blog doesn’t hurt. But what about the rest? Do you read additional material like chapter annotations, deleted scenes, and first drafts? Do you actually refer to online glossaries and the like? Does this stuff make you more likely to buy the author’s work? (And when you do buy her work, do you appreciate having lots of links to bookstores that carry it?)

Go ahead and join the discussion if you get a chance. Your input will be invaluable when it comes time to post the new websites for Infoquake and MultiReal. Really, people, I’m doing this all for you.

I’ve made no secret about the fact that I’m a big fan of LibraryThing. I’ve spent hours and hours tweaking my LibraryThing profile, adding books to my catalog, and just browsing around other people’s shelves. I’ve spoken with Tim Spalding, LibraryThing’s founder, and he’s taken the time to respond to e-mails of mine and feature me on the LibraryThing blog once or twice.

So I felt a little like a cheating spouse when I responded to someone’s invitation to sign up for a Shelfari account last week. But it was actually much easier than cheating on a spouse, because I didn’t have to go through that whole tedious seduction and getting-to-know-you routine. I exported my whole LibraryThing catalog in about three clicks, and imported it right into Shelfari. In a way, it was like moving in with your mistress and skipping straight to the seven-year-itch all in one shot.

Here are screen captures of my catalog on LibraryThing and Shelfari, side by side. (Visit my shelf on Shelfari.)

After noodling around with Shelfari a little bit, here’s a synopsis of my thought process:

1. The name “Shelfari” is incredibly lame.
2. Shelfari looks slicker than LibraryThing.
3. Shelfari is more user-friendly than LibraryThing.
4. LibraryThing is fairly slick and user-friendly in the first place.
5. So why would I switch to Shelfari?

The big difference between LibraryThing and Shelfari is that LibraryThing caps its free accounts at 200 books; Shelfari doesn’t appear to have any limits. But keep in mind that the LibraryThing rates are eminently reasonable. $10 a year for all you can catalog, or $25 for a lifetime membership.

Oh yeah, and Shelfari has a Facebook application. (I see that LibraryThing is testing out MySpace and LiveJournal widgets, which is cool, but IMHO they need to get cranking on a Facebook app.)

But there’s a huge amount of functionality that LT has which Shelfari doesn’t seem to have. I went browsing through “my shelf” on Shelfari and discovered that my copy of Shel Silverstein’s Where the Sidewalk Ends doesn’t have Silverstein listed as the author, only as the illustrator; and despite the fact that there’s an “Edit” link next to Edition Details, there doesn’t seem to be any way to edit that information. I was able to change editions to one which does have the author listed… but this one doesn’t have an illustrator listed. LT, by contrast, lets you edit book details to your heart’s content and upload custom covers that the whole community can use. Does the system think that “J.D. Salinger” and “JD Salinger” are two different people? Easy enough to fix that in LibraryThing.

This community focus is one of the things that makes LibraryThing so appealing. It’s kind of like — well, a library. It’s really, really easy to import and export your entire catalog so you can use it in other applications. Put it on your blog? Tie it in to your Firefox? Access it from your cell phone? No problem! If there are inaccuracies in the catalog, everybody pitches in to help fix it. If you read through the help menus and fine print, you’ll see quirky little bits of humor that give the site some attitude. “If the buzz page doesn’t convince you,” says a little blurb on the LibraryThing home page, “you cannot be convinced. Go away.” There’s a lack of commercial focus that’s very reminiscent of that library feeling. Come on in! Put your feet up, hang around as long as you like, buy some of the books on the Community Used Book table in the back if you’d like, but no pressure.

Of course, there are downsides to the public library. LibraryThing seems to go down more often than most other Web 2.0 sites I’ve seen (except for the chronically hapless MySpace). It’s not uncommon to find bugs and layout quirks. Every once in a while, you’ll find something not working with a cheerful little “we’re working to fix things” message. Oops, the plumbing’s leaking over in the corner again! Don’t worry, we’ve called the guy to fix it, he should be here in the next hour or two. Just try to steer clear of it in the meantime, ‘mkay?

Shelfari, by contrast, feels more like a corporate-owned bookstore. Like something a bunch of guys from Microsoft and RealNetworks would put together and then get funding from Amazon for. And if you poke around in the About Us sections of Shelfari for a few minutes, you’ll see that that’s exactly the case. If you’re wondering why Cory Doctorow breaks into hives whenever you say the word “Shelfari”, it’s because the president and co-founder of the company was in charge of DRM for RealNetworks. (Read Shelfari’s Management page.)

Poking around in the About Us sections of Shelfari reveals that these folks expect to sustain this site through Amazon referral fees, which seems pretty unrealistic to me. If you dig around the LibraryThing site, you’ll see several ironic references to the wads and wads of cash they pull in from Amazon referral fees. Meaning “we don’t expect to set the NASDAQ ablaze with this kind of revenue stream.” True, LibraryThing doesn’t exactly push people to buy books off of Amazon — they cheerfully funnel people to any number of sites, including book swapping sites like BookMooch and ReadItSwapIt — but they’ve got a much larger user base than Shelfari at the moment. Shelfari claims that they’re not going to accept advertising either.

So let’s do the math here: no membership fees + no advertising revenue + minuscule referral fee income – hosting fees, bandwidth fees, programming costs, overhead and salaries = remind me again how you intend to stay afloat after the Amazon money dries up?

For the moment it’s pretty clear which service gets my vote as the more functional, useful, and friendly place to be. Luckily, there’s no reason why I can’t maintain accounts on both for the moment. It’ll be interesting to see how Shelfari grows and develops over time.

In a perfect world, how would you deliver content to people? (And don’t tell me neural implants — let’s stick with existing computer hardware.) You would divide your article/opinion/rant/manifesto into a layer for data and a layer for presentation. The data would consist of the actual words, images and multimedia that you’re trying to communicate. The presentation would consist of specific instructions for how to display the data in various different mediums.

Why separate data from presentation? Because we’re constantly thinking of new ways to repurpose existing content, and it’s impossible to foresee every way that someone might want to use your content. People are reading content on cell phones, syndicating content on other peoples’ websites, feeding content into their iPods and through screen readers. And that’s just today. Who’s to say that in five years, movie theaters won’t be broadcasting web content alongside the previews? You don’t want to spend three months updating all of your old content for a new medium every four years.

But even discounting these more esoteric methods of content delivery, you can’t even count on a standardized web browsing experience on a PC. People are browsing with Windows, OS X, Linux, Unix, PalmOS and BeOS. They’re using Internet Explorer, Mozilla Firefox, Opera, Konqueror, Netscape and Safari. They’re using large resolutions and small resolutions, TrueType fonts and Postscript fonts and OpenType fonts of all sizes and shapes, 16 million color monitors and monochrome Blackberrys. They’re using services like Babel Fish to translate your website into French, Spanish, Croatian and Farsi.

You want your words to be immortal. If your great-grandkids aren’t reading your words a hundred years from now, it shouldn’t be because their robot butlers can’t figure out how to read your primitive web pages.

Let’s also not forget that the most important “readers” of your content aren’t people at all. They’re Google and Technorati and del.icio.us and other websites and technologies. And while it might be easy for a human to look at web page code and be able to tell what the meat of the page is, it’s not quite so easy for a machine. In an ideal world, you want Google to be able to open your file right up and instantly “know” where to find the meat of the page without having to guess whether your website’s copyright notice is pertinent data or not.

So you need to separate data from presentation. The problem is, HTML doesn’t do that.

Most Net-savvy folks already know that HTML is something of a kludge. Tim Berners-Lee cribbed most of it from the existing SGML. It jumbles data and presentation tags all together in one big random heap. Real programmers look at HTML and shudder. The rules are dreadfully inconsistent and none of the web browsers out there interpret them the same way. Add to this the fact that Microsoft and Netscape started adding their own proprietary tags to the mix during the browser wars of the ’90s, and you have a real headache. (Don’t even get me started on JavaScript and ActiveX.)

Cascading Style Sheets (CSS) promised to relieve some of the HTML headache. CSS allows you to assign style rules to almost any element in your HTML — turn all my hyperlinks purple and give them a ridged, dotted, blue border on three sides — thus taking a good bit of the presentation out of the HTML.

CSS2 went one step further by letting you position elements on a page with your style sheets. This was supposed to eliminate the standard way of positioning things on web pages, which basically involves creating lots and lots of nested tables full of transparent GIFs to nudge things into the right place.

The problem? CSS is kind of a mess too. Certain things that were very difficult with the table model are easy in CSS, but the reverse is also true. Run a Google search on “CSS vertical-align” or “CSS footer”, for instance, and you’ll find hundreds of articles from diligent programmers trying to figure out how to create a simple right-hand column. I now program my websites exclusively using the CSS model, but I still need to use clunky workarounds. In order to put a simple footer on every page of your website, for instance, you need to use an updated version of the transparent GIF trick to “prop” the rest of the page up. CSS has no real way to do it natively. Really.

So we’re getting there, albeit very slowly. Now instead of HTML, web programmers are using what’s called XHTML, which is essentially HTML made nice and tidy, HTML as it should have been. We’re using XHTML to present our data and CSS to deliver our presentation.

One can only hope that someday we’ll reach the holy grail. Pure XML files with nothing but data. Pure style sheets in CSS or XSLT or whatever else comes along. Portability. Compartmentalization. Sense.

I predict we’ll get there about ten minutes before the neural implants hit the street.