Nick Bradbury

No More Free Tech Support

Developers sometimes dread meeting new people. We suspect that when people find out what we do, they're probably going to ask us to fix a problem they're having with their computer.

The same dread occurs at major holidays when we get together with extended family. While everyone else is enjoying their time together, we're off by ourselves fixing their computers, or getting rid of a virus, or uninstalling the dozens of toolbars that suddenly appeared in their browsers, or figuring out why iTunes won't sync anymore.

It's not that we don't want to help. It's just that we spend all day (and sometimes all night) in front of our computers, so it'd be nice to forget all about tech at social events.

But this situation is unlikely to change soon. Despite our attempts to make software easier to use, it's still too unfriendly, too breakable, and just too damn geeky. People rely on their computers so heavily that we're going to be asked for free tech support for many years.

So here's what I propose: offer to trade your time doing tech support for their time talking about how they use their computers.

Yeah, I know that sounds silly, but hear me out.

A big reason software is still so unfriendly is that most developers spend very little time understanding how non-geeks experience the tech we build. We surround ourselves with fellow techies and start thinking everyone uses software the same way we do, so we keep building stuff for ourselves.

The only way we're going to stop spending so much time giving free tech support is by making stuff that's easier to use and less breakable. It's when we step into the world of non-geeks, where people type URLs into Google's search box instead of the address bar, that we start to understand what we're doing wrong.

So the trade seems like a fair one to me.

The Friction in Frictionless Sharing

Facebook claims that frictionless sharing makes sharing easier. They've improved the usability of sharing by taking away the friction.

So let's look at it from a usability perspective.

This is an oversimplification, but we can think of frictionless sharing as an attempt to replace something like this:

With something like this:

Instead of requiring the user to confirm every single article they choose to share, just give them a one-time dialog that enables them to share everything down the road.

That's a lot less work for the user, right?

Well, no, not really. Because in the past the user only had to decide whether to share something they just read, but now they have to think about every single article before they even read it. If I read this article, then everyone will know I read it, and do I really want people to know I read it?

That creates more friction, not less.

And let's not forget the friction the user experiences as they browse around the Web. Now they have to remember which sites are automatically sharing what they read. Did I allow a Facebook app to share what I read on this site? I don't remember, so I'd better not click that link.

So frictionless sharing isn't frictionless after all. All it does is trade the small friction of having to choose what to share with the large friction of having to think about whether what you're about to do will be shared.

The Long-Term Failure of Web APIs

Years ago, when developers such as myself started the transition away from OS-specific APIs to web APIs, we believed that doing so would empower our software and save it from the confines of the desktop.

And we were right.

But we've also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on.

I wrote the first version of HomeSite back in 1994, and seventeen years later I can still run it on the latest version of Windows.

I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I've relied on.

You might think you're immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we've seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have broken, or will break, existing apps.

The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they've integrated with, and less time adding the features and refinements that would really benefit their customers.

That's a long-term failure, any way you look at it.

Bing Search in FeedDemon

Now that Microsoft’s Bing search engine is live, I figured I’d create a "search definition" for FeedDemon to simplify subscribing to Bing search feeds.  Here's how to use it:

1. View this page in FeedDemon, then click here to install the Bing search definition
2. Click the Subscribe button, then type the keyword you wish to search for and click Next
3. Select "Bing" from the list of search engines and click Next
4. Select the folder you want to place this feed in, then click Next
5. Click Finish

After installing this search definition, you’ll also be able to search Bing directly from FeedDemon’s address bar.  Before you can do this, though, you’ll first need to select Bing as your search provider from the search button at the right of FeedDemon’s address bar, like this:

Note that FeedDemon’s address bar supports all of Bing’s advanced search keywords, including the feed: keyword which enables finding RSS feeds about a specific topic (ex: type feed:fitness to find fitness-related feeds).

Update: FeedDemon's automatic error reporting shows that there's a bug in older versions of FeedDemon which may cause a file access error downloading the above file when not logged into Windows as an admin.  This bug was fixed in FeedDemon 3.0 RC2.

The Great Un-Friending of 2009

If we ever friended each other on Facebook, then there’s a good chance you’re annoyed with me right now for un-friending you.  But I swear it’s nothing personal.  Lemme ‘splain.

I’ve been on Facebook for a while but I never really used it – the UI felt clumsy and cluttered, and I just didn’t get the appeal.  But lately I keep running into people in the “real world” who swear by Facebook, so I decided I should take a second look at it.

BTW, when I say “real world,” I mean the world away from my computer and the small circle of geeks I cocoon myself in.  If you’re not familiar with that world, it’s worth a visit.  Nobody cares what OS you’re running, what browser you’re using, or whether your HTML validates.

Anyway…because I never used Facebook, I just blindly friended anyone and everyone.  Which now, of course, makes it such a noisy place that I can’t possibly spend any time there.  So I pared down my list of friends to a much smaller group of semi-related folks in the hopes that I’d better understand why so many people like Facebook.  And the first people to get cut were my geeky friends.

So, don’t take it personally if I un-friended you – it probably just means you’re a geek, in which case you should be following me on Twitter instead :)

Windows Vista Gets a Bad Rap

From what I can tell, the general opinion of Windows Vista is that it sucks.  And to be honest, when I first tried Vista on my Dell laptop, I also thought it sucked.  It was slow, it crashed all the time, and I couldn’t see any compelling reason to upgrade my desktop system from XP.

But a couple months ago I bought a new desktop system that came pre-loaded with Vista, and much to my surprise, I like it.  I’ll be the first to admit it’s not the slightest bit revolutionary, but I still like it better than XP.

Of course, getting it pre-installed on a new system with Vista-compatible hardware is a big reason it’s more reliable for me than it was.  One of the things that hurt Vista out of the gate was poor driver support.  In particular, buggy graphics drivers destabilized the OS, leading many people (myself included) to revert back to XP.

Now that I’m running Vista on a decent system, I find it even more reliable than XP.  And now that I’ve had enough time to explore the “new” OS, I’m finding a lot of things I like.

So what’s my favorite Vista feature?  It makes my software look better (yeah, I’m vain).  The latest versions of FeedDemon look so much nicer on Vista than they do on the cartoony XP - especially the FeedDemon 2.8 Beta, which adds a number of Vista-specific UI improvements.  I cringe every time I have to test FeedDemon on XP because it looks crappy by comparison.

As an aside, I noticed a huge lack of developer interest in Vista, which certainly hurt it as much as buggy drivers did.  When Windows 95 was released all those years ago, developers couldn’t wait to come out with versions of their software that took advantage of all the features in the new OS.  But how many developers came out with Vista-specific versions of their products as soon as Vista was released?  Very few – and those that did often did so only to make their software play nice with Vista’s annoying UAC.  New Microsoft operating systems just aren’t as exciting to developers as they used to be.

OK, back to the point: while Vista deserves some of the criticism it receives, overall I think it gets a bad rap.  It should have been much better than it is, but it’s still an improvement over previous Windows releases.

Favicon Hell: Small Feature, Big Code

A couple years ago, FeedDemon started displaying favicons – you know, those little 16x16 icons that web sites use to brand themselves.  It was a popular addition, because it’s much easier to tell your feeds apart when they don’t all use the same generic feed icon.

It seemed like such a simple feature at the time.  Just check the root folder of the feed’s homepage for the favicon, download it if it exists, then display it in FeedDemon.  No big deal, right?

Bah.

The first problem was web sites that lied when I requested the favicon.  They’d use the wrong MIME type, so I couldn’t rely on that to determine if I was actually getting an image.  And all too often they’d indicate that the favicon existed by responding with an HTTP 200, but instead of returning a favicon they’d give me an HTML document that contained a 404 error message.  So that meant writing code to handle that situation.

The next problem was the sheer number of favicons that used the ICO file extension but turned out to be bitmaps.  Or GIFs.  Or PNGs.  Or JPEGs.  Or some undiscoverable format.  Which meant writing code to detect the true image format, and more code to convert them to Windows icons (something I didn’t get right until last week’s FeedDemon 2.8 Beta 3).

Then came the fact that not all versions of the Windows API play nice with truecolor icons, and the version of the development tool I’m using doesn’t handle them well, either.  More code to handle that situation and fail gracefully. 

And, of course, I had to reflect changes to a site’s favicon, as well as detect when a site that didn’t previously have a favicon suddenly got one.  And this had to be done in a way that was bandwidth-friendly, both to the client and the server (not as simple as it sounds given that many sites don’t correctly return an HTTP 304 when a file hasn’t been modified).

Oh, and I also had to scale the 48x48 and 64x64 favicons that some web sites inexplicably use.  Not to mention the fact that ill-mannered anti-virus software would sometimes lock the downloaded favicon file right after I created it, resulting in a “file in use” error which I had to capture and work around.

Etcetera, etcetera, etcetera.

The end result is that it took thousands of lines of code just to display favicons.  And that’s often the case with features that seem simple at first glance.  It’s not until you dive into the code and find all the weird problems and bugs that you realize your little feature is actually a big PITA.

So what’s the point of this seemingly pointless blog post?  Really, it’s just to explain my response to customers who ask when I’ll be adding a specific feature:

“I’m planning to add that to the next version, but I can’t promise anything until I’ve actually started coding it.”

I know that response sounds glib to those who hear it, but it’s really me being honest.  If I haven’t tackled a feature in code yet, then there’s no way I can reliably estimate how long it will take to complete it.

Related post: Start Coding Like a Cowboy

NewsGator Pays Attention

NewsGator CTO Greg Reinacker writes:

"We’ve now implemented a persistent APML endpoint in our online platform. What this means is, if you’re using sync with NewsGator Online, there is a well-known URL that represents your APML attention data."

At first glance, this may strike you as something that only hard-core geeks would be interested in.  After all, it's not as though tons of people are clamoring to get their attention data.  And by itself, your attention data doesn't have much value since there's not a helluva lot you can do with it yet.  But as more services support APML, the more valuable your attention data becomes. 

ReadWriteWeb claims that the keys to a killer web service are search, aggregation and conversation.  I'd add relevance to that list.  Relevance is key to bubbling up the stuff that's important to you out of all the stuff you're getting via search, aggregation and conversation.

Right now most services that provide relevance do so by learning over time.  They might, for example, notice that you often read articles about a specific topic, and then use that information to recommend new articles to you.  Or they might be able to recommend new "friends" to you based on the friends you already have. 

But you have to use a service long enough for it to learn about you.  Sites like Netflix and Amazon can't recommend new stuff to you until they know about the stuff you've already bought.  I don't know about you, but I don't want to keep training all these web sites in the hopes that they'll serve me better once they know more about me.  I'd rather have some sort of external profile I can give to these sites which tells them what I'm interested in.

That's what APML is for.  Attention data via APML describes the things that are important to you, and once a service knows what's important to you, it can do a better job surfacing relevant information without first having to spend so much time learning about you. 

Since we're providing your attention data as a well-known URL, you can easily share it with other services.  Unfortunately, we're still at the infancy stage here, so there aren't many services that support APML yet.  My hope is that by being among the first to offer APML, we can convince more services of its value.

SQL Virgin Again

I've been in the coding dungeon lately, which explains why I haven't posted for a while.  One of the things I'm working on is moving some of FeedDemon's data out of XML and into SQLite, which I didn't think would be a big deal since I spent a few years working with SQL before I entered the world of indie development.  I wouldn't claim that I was ever a SQL guru, but I used to be pretty good at it.

It turns out, though, that I've forgotten SQL since then.  And I don't mean that I'm just rusty at it: I mean it's like a foreign language to me now.  Sure, I can throw together a simple SELECT statement, but I've completely forgotten the syntax for GROUP BY, HAVING, and pretty much everything else.  So rather than tackling the move to SQLite with ease, instead I've been stumbling through it like a drunk bishop trying to remember where he left his hat.

Anyway...

So far I'm liking SQLite a lot.  It's fast, compact, simple and - most importantly - reliable.  For now I'm only converting a few features to use SQLite for storage (specifically, the "Popular Topics" and "Feed History" reports), since that way I can get an idea of the potential pitfalls before trusting it with more valuable data (such as the customer's subscriptions).  The end goal is to enable easily querying downloaded content without the substantial performance hit and overhead of an XML parser.

BTW, if you consider yourself a SQLite wizard, please feel free to share any tips here.  I'm sure I could use them at this point!

This Post Belongs on Techmeme

Back in Skinny Jeans: The real reason I left my career in tech.