Symphonious

I spoke a little while back about Feedburner vs Blogbeat. I wish I'd taken more time to give constructive advice to the Feedburner team about what they could improve because as is so often the case these days, they picked up on my entry and Matt Shobe responded in the comments. One of the things he commented about was being able to redirect your feed so users don't have to update their subscriptions:

With the comment about "making your users change," I assume you're referring to the need to publicize a FeedBurner feed URL in order to have your subscriber base use your FeedBurner feed. We have a good number of publishers redirect requests for their "original" feed URL to FeedBurner — so doing requires your users to make no changes to their existing feed readers but gets you 100% of your feed traffic stats tracking through our service.

That's actually the approach I took and it worked well to switch to Feedburner but seems to screw over Planet aggregators who update their feed URLs to the redirected URL and now I can't stop using Feedburner without pestering the planet maintainers to change the URLs back. This is probably a bug in Planet because I don't think (but couldn't be sure) that my server was responding with a permanent redirect, but rather just the standard what you want is over there but don't assume it always will be redirect. Either way, if there's one thing you can depend on it's user agents implementing redirects badly so if you're considering redirecting your feed, I'd suggest you think it through pretty carefully because switching back might be a bit of work.

For now I'm just leaving my feedburner account active and hopefully the feed will keep working so the planets don't have any trouble.

Update: Rick Klau's comment below is awesome.  Apparently FeedBurner will redirect people back to your feed if you want to leave the service (see http://www.burningdoor.com/feedburner/archives/001251.html). How cool is it when a company not only doesn't lock you in, but goes out of their way to help you leave, and goes running around the internet posting to blogs about it for people who are too lazy to read the documentation? Twice in my case! That's awesome customer service!

Robert Scoble takes James Robertson to task for criticizing OPML in response to Scoble's feature request. Mostly I agree with Scoble, when a user asks for a feature you shouldn't give them a rant about why the specific technology they're talking about is crap, you should give them your considered, professional opinion and recommendation. Hopefully that means identifying their problems and providing a solution but it might mean just telling them that their proposed solution won't work and you don't have an alternative.

Scoble is wrong to criticize James when James is in fact doing Scoble a favor by not giving him the specific implementation he asked for. The excerpt that Scoble quoted from James' entry is very misleading. He really should have quoted the entire paragraph:

Ye gods, it's time someone came out and said something. OPML is a really, really crappy format. Really crappy. I had massive headaches implementing OPML support for import/export in BottomFeeder. Why? Because there's no real specification. Like everything Dave Winer has ever been involved with, the specs are all in his head, and it's up to the rest of us to figure out wtf he actually meant. Here's the "spec" - and look at all the meaningless crap in it (windowRight? Why is there something specifying the number of pixels for the margin?).

See, the criticism wasn't actually that the format was difficult to work with or not technically perfect, it was that OPML just isn't defined well enough to achieve the interoperability goals that Scoble had in mind. It doesn't solve his problem. That's a key response Scoble missed in his list of answers you can give to clients (as if you could ever enumerate every possible response you should give to your clients): "the solution you've proposed doesn't actually solve your problem". You may or may not provide a better solution, just having the knowledge that the current solution is wrong is very valuable.

Speaking of which, why are people so insistent on having the attitude that you can't criticize something unless you can do better? Knowing that something won't work is more valuable than coming up with the idea that doesn't work - they've already done more than the person that came up with the original idea just by showing why it won't work. Besides which, there's a different set of skills required to do something than there is to evaluate it. How many wine drinkers know how to make a better wine than the one their drinking? How many have actually done it? Would you suggest they just drink whatever wine is put in front of them because they can't do better themselves?

So to answer Scoble's final question:

I see the feature I want. I see that someone has done it by hand to get what they want. I want even more. Are you gonna give it to me? Fine. If not, then can you stay out of the argument please?

I certainly hope not and Scoble, you're very much out of line to expect him to butt out. Not only is he right to point out a serious flaw in OPML (a loose specification is one of the biggest flaws a file format can have, particularly when it's intended to be used for interoperability) but he's perfectly entitled to post to his blog about it in response to more and more users calling for OPML as the be all and end all solution. Maybe if he'd started his entry with "Dear Scoble," or had given some indication that he was actually talking to Scoble instead of just reacting to something Scoble said you might criticise him for being rude to a potential user but as it is he's just putting himself out there in the blogosphere with his opinion and being open. Isn't that what blogging is all about? Isn't that what you keep promoting?

Maybe Scoble's just having a bad day. I'm probably being way too harsh - I've check the "Rant" box to serve as a warning… To end on a more positive note: Scoble, that is a pretty good list of requirements you've listed this time round. Hopefully someone will take that, decide what the best technology is and make it work for you. I'd also hope that Dave Winer picks up on the criticism and clarifies the spec so that implementations have something concrete and air-tight to implement and test against.

As soon as I saw the new Office 12 interface I questioned why you would add modes to a user interface when modes are so frowned on in usability - particularly by Jef Raskin. I was immediately banging my head against the table with the thought that to do anything in the new Office I'd have to figure out which mode the functionality was hidden under instead of just working with the menu categories that I was used to (no better than the ribbon modes but at least I'm used to them). Then I watched Scoble's video about the new office interface and felt a little better - hey, they've got a ton of user data to back them up, people do seem to work in different modes with Word and now the user interface matches the user model. Something just kept bugging me about it though.

This morning I came up with a theory of what I think is wrong. I think the Office team is right, people do use different modes when working with Office, and in fact software in general. The ribbon however isn't likely to work with the user model well. The user model relating to modes is something like:

1. Need to enter content for my document.
2. hmmm, this needs a table.
3. Table is ugly, better make it look pretty.
4. Review content.
5. Add more content.
6. Overall document ugly, better fix that.
7. Final review.
8. Print/save/submit/whatever.

The required model for using the ribbon however is something like:

1. Need to enter content for my document.
2. hmmm, this needs a table.
3. Mental note: I'm switching to my table editing mode now.
4. Note to software: I'm switching to table editing now.
5. Review content.
6. Add more content.
7. Mental note: I'm switching to content entry mode now.
8. Note to software: I'm switching to content entry again.
9. ….

The mismatch is that while humans use modes of thought intuitively and automatically throughout their day, software doesn't know which mode their in and in fact the user doesn't typically realize they're switching modes. This means that instead of intuitively switching modes, the user has to train themselves to realize when they switch modes and tell the software about it. I suspect that this will be a major source of frustration with the new Office interface, though I don't think it's necessarily worse than the current system, just that I don't expect it to be the saving grace of user interface design. Is it enough to justify throwing out the users existing knowledge on how to use the software? Not sure, but probably not.

It will be interesting to see what the feedback about the new interface is once it makes it out to typical end users rather than geeks who have access to MSDN subscriptions and Microsoft Betas. It will also be interesting to track that feedback over time to see if it mellows out and becomes favorable as people get used to it or whether it's another Clippy. Maybe someone like The Basement will do an analysis of buzz trends after Office 12 ships - it would definitely be interesting to see.

I've been playing around with the beta of BlogBeat and recently switched on FeedBurner for my feeds (just the free version). Both systems attempt to show who's reading your blog and provide some statistics about them. FeedBurner does this by looking at the number of people viewing your RSS feed and BlogBeat does it by looking at the number of people looking at your web site.

In the end, you have to realize that the actual numbers are irrelevant because both these methods are really quite inadequate. What they do show however, is trends and comparatives. You can't say with any real degree of certainty that 100 people read your blog, but you can say with certainty that more people read your blog today than yesterday or that Wednesday is the most popular day. It's because of this that I much prefer Blogbeat to FeedBurner, even though I suspect that FeedBurner's number are likely to be more numerically accurate.  With BlogBeat I can see what links people are clicking on around my website, not just what entries they clicked through to. I can see the window size people use when they access my blog - though I wish that were easier to visualize - and the service has a lot of potential to pull out other data about what readers are accessing on the site, more so than just how many people are reading.

I also find BlogBeat's interface a lot nicer to use that FeedBurner's. FeedBurner constantly forgets whether I'm looking at the last 24 hours or all of time (and it only provides those two options) whereas FeedBurner lets me switch charts and datasets while still preserving the timeframe I'm looking at (today, yesterday, this week, last week, this month, last month, this year or last year). Generally I just find that the information that comes out of BlogBeat is easier to understand than out of FeedBurner as well - the graphs are cleaner and clearer, BlogBeat isn't constantly trying to make me upgrade to the paid version either which reduces a lot of the wasted space and makes for an overall simpler, cleaner interface.

It will be interesting to see how BlogBeat goes forward as they come out of beta. How they plan to profit from the service will make a big difference to whether or not it remains usable and worthwhile. For now I'll stick with it and I've turned off FeedBurner again (or at least I'm working on doing so). That's the other nice thing about BlogBeat, it's far less intrusive than FeedBurner and doesn't require making your users change.

I said I couldn't be bothered setting up my feeds to use FeedBurner.  I lied, curiosity got the better of me and my feeds to go through FeedBurner.  The URLs haven't changed, there's just a redirect in place that flicks things over to FeedBurner.  If for some reason you have trouble with my feeds please let me know and if you really object I can give you the non-redirected feed URL that FeedBurner uses to get my feed.

It should be interesting to compare the difference between what BlogBeat reports, what FeedBurner reports and what AWStats pulls out of my web server logs.