FriendFeed and level playing fields 

I've always been a bit puzzled about how FriendFeed does RSS, but I've never (until now) taken the time to find the source of the puzzlement. I've always just fumbled my way around, sort of approximating what I wanted, and when I couldn't get it, falling back to the API. But now I've hit a wall, and taken the time to understand the nature of the wall. Let me explain.

Consider this screen (click on it to see the detail):

Suppose you used a photo site that wasn't one of the ones listed, but you had an RSS feed for your photos and favorites on that site. What are you supposed to do? I always assumed you should just add the feed under "Blog" but then your readers will start asking why your pictures don't do all the neat things that happen automatically with Flickr, Picasa, SmugMug or Zooomr sites. I have such a site, and I don't want them to do anything special for it, I just want to tell FF that it's a photo site and have all the cool special goodies they have for Flickr kick in automatically.

If you pop up a higher level, you'll see that this is actually contrary to the whole idea of feeds, which were supposed to create a level playing field for the big guys and ordinary people. That's why a guy like Mike Arrington was able to start TechCrunch and eventually be a competitor of CNET. The fact that RSS didn't favor the big guys made that possible. In fact the whole web is like that. You don't need a special client to read the NY Times and another to watch videos on YouTube. Any browser will do, for any site, no matter who's writing and who's reading. It's why many of us fell in love with the web, at first sight. In the software world before that, it mattered who you are or who you worked for. Kind of like FriendFeed. :-(

It's also against the level playing field idea to favor people, like me, who can program to the APIs. The point of feeds was to make the technology transparently understandable to people who just had brains, that you wouldn't need to understand anything deeply arcane to make RSS work. Since FF is about feeds, it seems to me that it ought to be consistent with the philosophic simplicity of feeds. Again, this is just another application of a principle of the web -- you could always View Source to see how a website worked, and if you were willing to do a little trial and error, and head-scratching, you could make your site work the same way as any site you could view in your browser. This was a good thing.

Now, don't get me wrong, I like APIs, I even love APIs, but only when a feed won't do. There are cases where the API shows more power than the feeds, where feeds can and should have the same power. For example if I want a description to come along with a picture, I have no choice but to write a program to push the content to FriendFeed. That seems wrong to me. RSS and Atom both have description elements, why ignore them? Also, I can if I want make sure the content arrives in a timely manner, but only through the API. The functionality of a web app shouldn't unnecessarily favor programmers. That's unweblike imho.

Now I wouldn't make these criticisms if I didn't think FF was an excellent web app. But like all technology it can be better. That's why I make the suggestions.

Tech developers and users 

It's impossible to tell how tech companies will take feedback or advice, I just give it as it occurs to me. I don't try to sugar-coat it, but then I don't think that there's anything wrong with providing an imperfect or incomplete product or service.

I was the guy who said "We make shitty software" to his developers as he passed them in the hall. To which the standard response, which always got a laugh, was: "With bugs!"

It's a joke, but not really. We know our software sucks. But watch, we'll make it suck less.

Anyway, offering advice to most developers is a waste of time, and only makes them hate you. But what are you supposed to do if you want to build on their product and keep hitting the same brick wall, month after month. Is there a polite way to express frustration? If so, I'd like to know what it is.

In Thursday's piece I said developers are every bit as insistent about ignoring users as news people are. I see it happen every damn day. It's just as bad no matter where it happens.

Medvedev and his Macbook 

Update: Obama uses a Mac too.

Fractional horsepower ImageMagick HTTP server? 

I love ImageMagick, it's creating thumbs for me, night and day, day in and day out. The feed that's using the thumbnails is up and working.

But I'm still bugged that: 1. It seems slower than it should be. 2. A window flashes every time it creates a thumbnail.

People have suggested that I use PHP to interface to ImageMagick, but no slight to PHP, I already know too many languages, I'm trying to forget some!

Then I got a message from Phil Pearson, a guy who helped a lot in the early days of XML-RPC, and that triggered a thought -- you know what I really want -- an HTTP interface right into the ImageMagick engine. I'd accept a REST interface, but I'd be ecstatic about an XML-RPC interface. Truly.

Then you could put the engine where ever you wanted and call it from anywhere. If it started consuming the whole CPU, then fork off another one. I know you can probably do this with PHP, but I'm picky. I want my XML-over-HTTP. That's my comfort zone.

Update: I hear that Graphicsmagick is faster than Imagemagick.