DragonStyle

Survey: Northeast has dumbest drivers

Did anyone who has ever driven in the Northeast, particularly Boston, actually need a study to tell them this? [disclaimer: I am one of those horrible drivers, you can see me in the mornings on Broadway in Cambridge if you'd like.]

From: CNN.com

When faced with a written test, similar to ones given to beginning drivers applying for licenses, one in ten drivers couldn't get a passing score, according to a study commissioned by GMAC Insurance.

Link to article...

Pickup Lines: The First Drafts

OK these are actually pretty hilarious.

From: McSweeneys Lists

Link to article...

One more comment on 'Add Feed'

Ok, one more quick comment about the thread on 'The Usability of Subscribing to Feeds' over on Jeffrey Veen's blog. The more I think about the discussion going on there, the more I think there are really two usability problems that are being debated (I think Jeffrey is on to this when he asks - "Should I help people subscribe?"):

1) How should a website explain what RSS is to a user who isn't familiar with it?

2) How should a website make it easy to subscribe to the site feed?

Here's a quick shot at answers to these questions:

1) How should a website explain what RSS is to a user who isn't familiar with it?
It shouldn't. Users who don't know who don't use aggregators shouldn't be bothered with evangelism in the website. They should just read the web page and enjoy it! At some point, someone will likely show them a reader, and they'll make up their mind that they're interested, and no evangelism or explanation will be needed. Think of how you were first exposed to IM or Email- someone shows it to you and you quickly understand it and are sold. At no point did anyone explain POP or SMTP to me when I was first exposed to email. No one listed the benefits either, I just tried it and got it. No salesperson called me and told me the benefits of email, so don't mess up my web pagee viewing experience by trying to evangelize syndication.

2) How should a website make it easy to subscribe to the site feed?
They shouldn't. They should make it easy for feed readers to allow users to subscribe to web sites. That way, browser toolbars, bookmarklets, GreaseMonkey extensions, embedded feed readers, or any other application has a consistent and reliable way to expose adding a feed to their users.  The user can choose the application that makes the most sense to them, and use the 'Add Feed' capability built right into their favorite application. If they don't have an application because the user doesn't like using syndication/a feed reader, no worries- they aren't having to deal with it.

What is it with this weather? Enough, already!

In case anyone was wondering, the weather in Boston is pretty terrible right now. A little sun, please?

From: H2Otown - a site by and for people who live in and love Watertown, Massachusetts

Watertown blogger Dowbrigade launches an essay about our terrible recent weather and how to get through it -- A Rainy Night in Watertown:

Link to article...

The RSS-Only Blog?

Except that something like 90% of users currently _only_ use the 'superfluous' web front end.

From: The RSS Weblog

Russell Beattie speculates on the RSS-only blog—no Web page, no HTML code, just a feed link. He projects that comments would be obliterated in such a blog, but that might not be such a bad thing. Also—there’s a problem with permalinks.

Link to article...

Add Feed in the Web Page: Not Good.

[Disclaimer: I work at Onfolio] Jeffrey Veen is continuing the discussion about how to represent 'Add Feed' to users, struggling to find a better alternative than the orange XML icon (and the subsequent click through and viewing of heinous and confusing xml). Here's the problem- you shouldn't need a visible link in the web page for users. The most lucid comment is made by Sam Ruby in the comments- let the readers do the work rather than trying to do it yourself! (Cause let's face it, you've got a lot of explaining to do if you're trying to help users who don't understand RSS, showing them the guts of the system doesn't really help. Maybe instead, you should try explaining the web by discussing HTTP Gets and Posts!).

Let's take an example- Onfolio. This is an app that is embedded in IE or Firefox, and it includes a toolbar that appears in the top right hand corner of the browser. Here's a nice little picture of how Onfolio looks in Firefox.

When you navigate around the web, Onfolio's toolbar is keeping an eye on the pages that you are viewing and looking for link tags that provide a feed url. When the toolbar detects one for the current page, it lights up:

Press the button, and you add the feed to Onfolio.  It's really that simple.  At no point are you required to view XML.  If you're visiting a page that doesn't include a feed, the button is still there, but it isn't lit up, indicating that there isn't a feed here:

Pretty straightforward for users- they just press add when they want to add a feed. A couple of the advantages of this approach:

1) Users always know how to add a feed- press the add feed button. This means that there is no need to search the page for a link somewhere, sometimes as a text link, sometimes as a button.  There is no need to copy a feed url, or drag a link, etc...  Press a button. Nice.

2) There is a consistent way for authors to notify feed consuming applications that feeds are available- in the page itself. No need to get users involved in the implementation details such as syndication using a particular xml format. (I'm especially bummed out about pages that let you choose atom or RSS, I mean do I really need to make that choice?).

What do you _really_ read in your aggregator

I read the latest post from Charlie Wood with great interest. He talked to all kinds of enterprise customers who are thinking about RSS and adoption of readers. What were the problems that they were thinking about? He points to 2 major problems- internal email spam, and brand monitoring. I can't relate to internal email spam (Onfolio is still a small company!), but I definitely use my feeds to keep an eye on the Onfolio brand.

Taking a closer look at the feeds that I subscribe to, I have 4 categories of feeds that I am currently subscribed to:

1) Search feeds that monitor Onfolio.
I have feeds from Blogdigger, IceRocket, MSN, Technorati, PubSub, Feedster, Yahoo News, as well as feeds from our customer forums. I read every single one of the posts that come into these feeds. If you forced me to stop using Onfolio (or any other feed reader), this is what I would miss more than anything. Interestingly, these are also the feeds that generate the most junk for me (ads in some, 30% junk rate, etc...). I can live with that to be notified when someone writes something about Onfolio, though!

2) Feeds from people that I know
My colleagues, friends (near and far) do sometimes have blogs.  When they do, I like being subscribed because its an easy way to keep up with whats going on with them. This is probably the second most important use for me.

3) 'Magazine' feeds
I have feeds that I enjoy reading, but that I basically wouldn't miss that much if they were gone. Espn feeds, Autoblog, etc. . . These are fun to read, but I don't really care if I miss a post, and honestly it is pretty nice to just navigate to their page when I feel like reading something (similar to how I open Sports Illustrated if I'm bored at home and looking for something to read over breakfast).

4) Feed I wish I wasn't subscribed to
Here's the biggest surprise to me- I am subscribed to at least 5 feeds that I actually never read at all. I have no idea why I've continued to be subscribed to these feeds (Techbargains, you know who I'm talking about!), but I am. I pretty just mark these all as read whenever there are new items in them.

So back to Enterprise RSS- monitoring the brand makes a ton of sense to me as a great use of RSS. I'm not so sure about reducing internal spam.  A couple of examples:

1) Group blogs are just like email lists. If you set up a group blog that many people can post to, isn't this just like an email list that many people can send to? What if anyone could post to the 'main company bulletin board blog.' Isn't that just another inbox to spam? Maybe the difference is that at least you can unsubscribe to the group blogs, but you can't get off the 'all' list? But if you unsubscribe, do you miss the news that the office is closing early next Wednesday?

2) Companies have email lists now- and its pretty straightforward to do things like not let anyone send an email to all@company.com. Maybe they should look into that first before abandonding the e-mail platform, adding a new inbox to all users desktops, and trying to make everyone be a blogger?

3) Since email isn't going anywhere, should we make every employee read internal blogs too? Since sending email isn't going anywhere, should we really make every employee write blogs too?

I am hot and cold on the whole thing, because RSS and aggregators are easy to be hot and cold on. They are great and addictive, but a little hollow at the same time. I guess that's the fun part about working in this segment, though- there is more to think about, to learn about, or to be hot and cold about every day.

Web-based todo list review

I took a quick peak and Backpack as well when I was in one of my task organizing modes. I have to agree with Walt here- I don't need another place to store todos, and I'm not getting rid of my email client anytime soon, so I'll stick with Outlook.

From: Lifehacker

The Wall Street Journal's Walter Mossberg reviews web-based personal organizers Backpack and Usetasks. While he says Backpack is better, his final not-very-revelatory verdict is, "They're ok, but not for everyone":

Link to article...

VC’s Work the Social Networking Angle

Social networking that makes sense- targeting of a meaningful community that already exists, students of the same college. I'm a little skeptical that I'd want to be in this for 12.2 large, though.

From: Syndicator blog

With the ability to attract and reach elusive but desirable demographics with pinpoint accuracy, online social networking environments such as Yahoo! 360, MSN Spaces and others have been getting a lot of attention lately.Now, Media Post …

Link to article...

The 'Dirty Little Secret' About Longhorn

Not that surprising, honestly. While the .Net framework provides a lot of productivity, I can understand taking a conservative approach to OS development.

From: Microsoft Watch from Mary Jo Foley

Contrary to what many believe, Longhorn won't be built on top of the .Net Framework, we hear. But that might not be a bad thing.

Link to article...