Nick Bradbury

What's the Story Here?

It was interesting to watch the evolution of the Microsoft RSS patent story last week.

After reading about the patent applications on Dave Winer's blog, I read through them and posted my thoughts (in a nutshell, I disagreed with the inventions claimed in the applications, but given all the patent lawsuits Microsoft has experienced, I understood why they filed them). By the time I uploaded my post, several bloggers were claiming that Microsoft was attempting to patent RSS, so I quickly updated my post to make it clear that the applications were much narrower in scope.

Over the next few days my FeedDemon search feeds brought in a ton of other blog posts and mainstream articles about the subject, many of which continued to claim that Microsoft was trying to patent RSS. By the time Microsoft's Sean Lyndersay had posted his response, much of the geekosphere was already up in arms.

CNET's article was the first mainstream piece I read about about the patents, and to her credit the author tried to decipher what the applications were about. Perhaps that's one reason the article was so widely copied? It quoted both Dave Winer and myself, and the same (or very similar) quotes were used in many other pieces about the patents. I'm not one to complain about free publicity, and I'm flattered to be considered a trusted source, but it's hard to believe that so many independently thinking writers decided to quote the same two people.

But there's more to this story than how bloggers and journalists reacted to a couple of minor patent applications. There were 69 Microsoft patent applications published the same day as the two RSS-related ones, and a quick perusal of LatestPatents.com shows how frequently patents are sought by major tech companies. It seems to me that there are several stories here:

1. Why do large companies feel the need to file applications for dubious inventions (cursor interaction and window repositioning, for example)? Do they expect to make a fortune from patent licensing? Are they seeking ways to sue their competitors out of business? Or are they merely protecting themselves from patent trolls?
2. We're all building upon prior art here, so why do so many software developers permit themselves to be listed in patent applications as inventors?
3. How do companies who on principle refuse to file software-related patent applications defend themselves against patent lawsuits?
4. How many of our beloved Web 2.0 companies will turn into (or sell their inventions to) patent trolls if they run out of cash before being acquired? It happened after the first dot-com bubble burst, and it will happen again.

I'd certainly read any article that seriously investigated those questions. How about you?

My 2006 Favorites

Yep, I'm joining the ranks of bloggers who write about their favorite pop culture releases of the past year. Sad, isn't it?

Music

This one's easy: Stadium Arcadium is hands-down my favorite album of the year. I agree with Fred Wilson that this double album would've been better if it was pared down to a single CD, but figuring out which songs to remove would've been tricky because even the weakest tracks are enjoyable. I've witnessed many of my favorite bands disintegrate or turn into caricatures of themselves in the 15 years since I graduated from college. Not so with the Chili Peppers - this album shows them getting better with age.

Honorable mention: The Beatles Love. The mashups are hit-and-miss, but the CD is worth its weight in gold for the digitally remastered versions of "A Day in the Life," "Revolution" and "I Am the Walrus" (three of my all-time favorite songs).

Movies

United 93 was the film that had the biggest impact on me this year. I initially avoided this movie because I mistakenly thought it was a cheap attempt to cash in on 9/11, but now I wish I would've seen it while it was still in theaters. United 93 is more respectful to history than any film I can remember, and it moved me much more than I expected it to.

Honorable mention: An Inconvenient Truth. I watched Al Gore's presentation on global warming two weeks ago, and it was an eye-opener - especially since I stepped outside after viewing it and discovered it was 70°F (definitely not the norm here for the middle of December). That's like hearing a banjo right after watching Deliverance.

And I'll give a second honorable mention to Monster Road, a documentary released on DVD this year about the bizarre world of animator Bruce Bickford. If you like weird movies, this will be right up your alley.

Video Games

It's rare that I have time for video games these days, and when I do play it's usually something like Unreal Tournament. But this year my favorite game was a little different: Lego Star Wars II. My son saved up for this game over the summer, and the day he bought it we played it together for six hours straight. I doubt I'd enjoy playing Lego Star Wars II by myself, but playing it with a seven-year-old was an absolute blast.

Honorable mention: GameTap. Alright, so it's not actually a video game - it's a video game service. After signing up for GameTap, I downloaded a ton of classic games like Zaxxon and Joust. It was fun to wax nostalgic over the quarter-munchers I played in the arcade when I was a kid.

Blogs

I read a lot of blogs, but Creating Passionate Users is one of the few that causes me to drop everything when it has a new post. I can't say I'm always happy to read what Kathy Sierra has to say, though - all too often she points out mistakes in software design and usability that I've been guilty of :)

Honorable mention: The Dilbert Blog. I'm not a huge fan of Scott Adams' comic strip (I've worked at a few Dilbertesque companies, so I find the strip too realistic for my tastes), but his blog has caused more coffee to be spilled (or spurted) onto my keyboard than anything else I've read this year.

Clarifying Microsoft's RSS-related Patents

Before I prattle on about this, I'd like to make it clear that this is my personal blog.  I speak for myself here, not the company I work for, so please don't mistake my personal ramblings for company policy.  If I had that kind of clout, every day would be "free pizza and beer day" at work.

Anyway, the uncovering of Microsoft's RSS-related patent applications generated a lot of buzz yesterday, some of it worthwhile but much of it over-the-top.  I'll say it again: they're not trying to patent RSS.  Instead, they're trying to patent two applications of RSS:

1. Content syndication platform: describes the Windows RSS Platform, which is built into IE7/Vista and was announced at Gnomedex 2005 three days after the patent was filed.  This platform exposes an API which enables applications to access the user's shared feed subscriptions, providing object-oriented methods for reading, adding, deleting and updating feeds regardless of their format.
2. Finding and consuming web subscriptions in a web browser: describes an API and user interface for discovering and exposing RSS feeds to other applications (specifically web browsers).

So while they're not trying to patent RSS, they are trying to patent obvious inventions for which there's plenty of prior art.   Assuming that the inventors of that prior art file the necessary citations, I'd be surprised to see these patents granted (and if they are granted, expect to see plenty of civil disobedience amongst developers of RSS-enabled applications).

To me, the bottom line isn't that these patents prove that Microsoft is evil: instead, they illustrate how screwed up our patent system is.  I still believe these are defensive patents (Googling for microsoft patent infringement shows why this is necessary) - but like Dave Winer, I'd like to see Microsoft pass the acid test before I'm willing to say that with any certainty.

Update: Niall Kennedy has an in-depth analysis of Microsoft's syndication platform patent application.

Update #2: Microsoft's Sean Lyndersay chimes in.

Microsoft's "Content syndication platform" Patent

Dave Winer links to a US Patent Application filed by Microsoft in 2005 regarding the Windows RSS Platform.  Here's the abstract:

"A content syndication platform, such as a web content syndication platform, manages, organizes and makes available for consumption content that is acquired from the Internet. In at least some embodiments, the platform can acquire and organize web content, and make such content available for consumption by many different types of applications. These applications may or may not necessarily understand the particular syndication format. An application program interface (API) exposes an object model which allows applications and users to easily accomplish many different tasks such as creating, reading, updating, deleting feeds and the like."

Wow.  I had no idea Microsoft invented all that - I could swear some other folks have implemented similar ideas!

But before the geekosphere goes into "patent attack mode," let's take a breather and think about why this patent was filed.  For example, quite often companies file patents just to protect themselves from lawsuits.  There are plenty of sleazebags who file patent applications on obvious ideas, and then wait for someone like Microsoft to infringe those patents.  In other words, companies like Microsoft often file patents to prevent having to shell out millions of dollars to predatory lawyers who haven't invented anything other than a legal pain in the ass.  And beyond the potential monetary loss, a patent lawsuit can mean delaying a technology that's critical to a company's success.  Yes, it sucks that the patent process has devolved to such a state, but this is the reality of the environment that today's businesses have to operate in.

So I'm not going to jump on the "Microsoft is evil" bandwagon about this (yet).  However, Microsoft clearly did not invent all the ideas claimed in this patent, so some clarification would be appreciated from Microsoft's RSS team (several of whom are listed in the patent as inventors).  Specifically, what was Microsoft's purpose in filing this patent?  And what exactly did Microsoft really invent here?

Update: Some bloggers apparently think that Microsoft is attempting to patent RSS itself, but that's not the case.  I don't agree with Microsoft's claims, but they're much narrower than that.  Read the application before posting, folks!

Desktop Software is Paralyzed by Fear

Despite the power and rich UI that desktop applications offer, it's obvious that the move to Web applications is accelerating. For many people, the ability to access their data through any browser clearly outweighs the benefits of desktop software.

However, if you get away from techie circles and speak with mainstream users, you'll find that many of them don't care about the ease of accessing their data. They only need to access their data from one location, so it makes no difference to them whether they can get their email at Starbucks. In fact, some of them don't even like the idea of their data being "out there somewhere."

Yet they're still moving to the Web.

Why is this? There are many reasons, but fear is a big one. Downloading and installing software is scary.

When you try to download something, you're presented with a security warning about how the software could potentially harm your computer. If you install the program despite this warning, your firewall often displays an intimidating dialog asking whether you really want to trust this application enough to let it talk to the outside world. It's a one-two punch that's driving away many would-be users of desktop software.

Sadly, I don't see any signs that this will dramatically change for the better, at least not in the Windows world. Despite the enormous graphical improvements and other advances in Windows Vista, downloading and installing software is still too scary for non-technical users.

It's great that Microsoft is concerned about security - given the past few years of spyware-ridden desktops, they have to make security their priority - but I sure wish they could make Windows secure without scaring away customers.

Five Things People Don't Know About Me

I'm not a big "meme" fan, but this one's fun enough.  So here goes:

5. I like talking with people, but I hate the phone.  It's an evil invention that interrupts your life.  I avoided buying a cell phone for years - in fact, it wasn't until my wife became pregnant that I found a good reason to own one (a cell phone, that is, not a wife).

4. I'm so bad at dancing that I can't even do the two step without tripping.  No joke - I tried.

3. When I was a little kid, I performed locally as a ventriloquist (my dummy's name was "Jerry Wiggins").   I even won a few talent shows, but gave it up after a couple of years.

2. I flunked out of college the first time around (yes, I was studying computer science at the time).

1. Screw pessimism - I'm still waiting for The Beatles to get back together.

I'm supposed to spread this meme to five other people, so I'm tagging some fellow RSS geeks: Brent Simmons, Dare Obasanjo, Kevin Burton, Greg Reinacker and Niall Kennedy.  (And if you didn't want to be tagged, blame Mark, not me.)

Extending Your Application

Gordon Weakliem responds to my post about power users by suggesting that developers make their applications extensible.  That way power users can build their own features, sidestepping the need to complicate your software by adding those features yourself.

It's an excellent point, and there are certainly a number of applications that have greatly benefited from their extensibility (Microsoft Office and Mozilla, for example).  Plus, making your program extensible is one of the best things you can do to help build a community around your software.

But if you plan to make your software extensible, be aware of the costs of turning power users into developers:

• Feature requests from power users won't slow down after you make your software extensible (if anything, they'll increase).
• Unless your support team has programming skills, it will be up to you (or other developers on your team) to support power users who are extending your software.
• Making your software extensible may complicate future versions by requiring them to be backwards-compatible.

Not long after I created the first version of HomeSite, I started receiving requests to make it extensible so that third-party developers could hook into it.  I eventually exposed HomeSite's object model through ActiveScripting, enabling customers with programming experience to roll their own features.  This was enormously popular with power users, and the benefits trickled down to new users since they could download third-party add-ons that provided additional functionality.  It also resulted in a very active community of "HomeSite extenders" who shared and discussed their work with each other.

It was worth the effort, but I would never claim that it made HomeSite simpler to support.  Instead of requesting new features every now and then, power users would frequently ask that we make HomeSite even more extensible.  At the same time, we also had to help developers who were having problems getting their add-ons working, which often meant educating them about JScript or VBScript.  So while I don't regret making HomeSite extensible, supporting it was a lot more work than I anticipated.

In addition, we had to make sure that new versions of HomeSite continued to support adds-on created for prior versions (for the record, we weren't always successful).  In most cases this was no big deal, but there were situations where changes to our object model required some "creative" coding to ensure that old add-ons would work.  This was further complicated by the fact that third-party developers found all sorts of ways to hack around limitations in our object model to get their adds-ons to do things we hadn't anticipated (truth be told, though, much of this could've been avoided had I spent more time designing HomeSite's extensibility features in the first place, but when you work for an Internet start-up, time isn't usually something you have in great quantities).

Don't get me wrong - I'm not suggesting that you avoid extending your software.  But I am suggesting that you really think about the implications before you do it.  Unlike some of the features you'll add to your application, extensibility is something that really requires thinking beyond the current version, and failing to get it right could easily complicate your software rather than simplify it.

Simplicity Ain't So Simple, Part VII: Know When to Stop

'Nuff said :)

Simplicity Ain't So Simple, Part VI: Simple = Secure

If you want to create software that's used by a lot of people, you already know you've got to make it simple. But if you're designing a desktop application which connects to the Internet, you've also got to make it secure.

To some that may seem obvious, but plenty of developers - including myself - have been blindsided by security holes that we should've seen a mile away. All too often we look only at the positive side of the technology we're involved with, failing to see that if we get lucky and our software gains mainstream acceptance, it then becomes a possible point of attack.

Somehow you've got to keep your customers safe without making them feel limited by your security restrictions, and unless your target audience is security experts, you've got to do it in a way that doesn't require a special "security" page in your options dialog that's stuffed with cryptic settings.

Bottom line, if you want to appeal to a mainstream audience, you've got to make your software simple and secure, which is extremely hard to do. How you go about doing that depends on the type of software you're working on, but there are some basic things you can do:

• Don't think of security as a "feature" that you can add later: think about it as part of the foundation of your software. Adding security later may complicate your software, as well as require changing its behavior in ways existing users won't like.
• Don't require customers to do anything extra to make your product secure. If you need to add any security-related settings, make them default to the most secure values possible - and then think about whether you can drop those settings entirely (after all, do you really want to enable customers to make your software less secure?).
• If you have to warn customers when a specific action has a security risk, make sure your warning dialog uses clear, ungeeky language. You can't expect customers to make an educated decision if they have to decipher your jargon.
• Take off your white hat and wear a black one for a while. If you were tasked with exploiting your application, how would you do it? And I don't mean this in an "old school" hack-the-EXE way: I mean how could you exploit existing features to make customers susceptible to phishing, XSS attacks, etc.
• Always, always, always think about how spam could affect the technology that your software relies upon. Anything that requires showing end users information from the Internet is susceptible to spam-like behavior, even if nobody is doing it yet.
• If your software connects to the Internet, don't read this list and think it doesn't apply to you. It does.

Making your software secure is your job, not your customers'. So don't let securing your software complicate their lives - make it simple for them (and yourself) by baking security into your application from day one, and do it in way that doesn't require them to keep a technical manual by their side.

Simplicity Ain't So Simple, Part V: Combine Features

In this series of blog posts for developers, I've talked about simplifying your software by hiding non-essential features (or not adding them in the first place).  But sometimes you can simplify your software by combining features.

That may sound weird, but take a close look at your application and chances are you'll find some features that overlap.  Look even closer and you may discover that you can combine those features in a way that makes your application simpler.  Here's an example:

Over the past few releases of FeedDemon, I've struggled with the number of items to show on the toolbars.  I wanted to make sure that the most important features were easily accessible, but I didn't want to overwhelm new users by showing too much at once.

By far the biggest struggle has been with the toolbar above FeedDemon's integrated web browser, which looks like this:

Notice that the address and search boxes are separate?  To geeks like me it makes perfect sense to do this, but as Ivan Ičin points out, less experienced users don't always see these as separate actions.  So this week I decided to combine them, like this:

And you know what?  Not only is this more intuitive for inexperienced users, but I'm finding that I like it better as well (a lot better, in fact).  Combining these features is simpler than having them separate.

Combining features can also mean making an educated decision about an action the user makes.  For example, although you can explicitly tell FeedDemon to mark an article as read, it's automatically marked as read when you click its title to navigate to it on the web.  You've chosen to read the article online, so why force you to mark it as read?  By combining the two actions, FeedDemon is simpler to use.

Similarly, TopStyle has one toolbutton for refreshing the internal browser so that it shows the latest changes, and another toolbutton for saving those changes to disk.  But when you save changes to disk, TopStyle assumes you'll want to see those changes, so the browser is automatically refreshed.  Not forcing the user to explictly refresh the browser after saving changes makes TopStyle simpler to use.

These are minor things, sure, but it's the little things that keep people using your software for the long haul.  It's easy to impress new users with a shiny new UI, but if you want to keep them as customers, save them a few steps.