Nick Bradbury

The Increasing Importance of Discoverability

Published on November 25, 2008 by Nick Bradbury7 Comments

It’s incredibly easy to try out new applications these days – especially web-based ones since they don’t even need to be installed. And the more applications that people try, the more important that discoverability becomes.

People who try out an application don’t want to spend any time learning it. They want to get started with it now, see what it does now, and cast it aside now if it doesn’t fulfill their needs. If they can’t discover the features they need right away, they’ll look elsewhere. It’s not like it’s a huge investment of their time to Google for your competition.

Read the help file? Are you kidding? Nobody reads the help file these days. If someone can’t figure out your application by simply using it, you’re screwed if you think you can rely on your help file to explain it to them. Customers would rather try out your competition than read your documentation.

If you want to grab potential customers, you’ve got to make your most important features easily discoverable so that new users won’t miss them. Your next trick is to do that without creating a level of toolbutton overload that would intimidate those same new users. And you’ve also got to avoid annoying experienced users by constantly getting in their face with all your wonderful discoverability.

It’s a tightrope walk, for sure, but I’m happy to walk it. When compared to software written a decade ago, today’s software is generally more usable, and I believe that’s due in part to the fact that discoverability has become more important. Out of necessity, many developers are making it easier to start using their software, and more often than not, I’ve found that this also makes their software easier for experienced users as well.

Yes, most programs – including my own – are still too complicated, too fragile, and too unfriendly, but in general software is slowly getting better, don’t you think?

Windows Vista Gets a Bad Rap

Published on November 24, 2008 by Nick Bradbury15 Comments

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

Published on November 23, 2008 by Nick Bradbury12 Comments

A couple years ago, FeedDemon started displaying favicons – you know, those little 16×16 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 48×48 and 64×64 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

The Value of Automated Error Reporting

Published on November 12, 2008 by Nick Bradbury14 Comments

The past few releases of FeedDemon have an included an error reporting feature which captures unexpected problems and sends us detailed reports on what went wrong. If you’ve never seen this feature in action (and I hope you haven’t), it looks like this:

I’ve been going over the past few months of error reports, and much to my surprise, I discovered that the top three most common problems were never reported in our support forums. If I didn’t add error-reporting to FeedDemon, it’s possible that I’d never have known about these bugs – so if you’re a software developer and you don’t have a similar feature, perhaps that will convince you to add one!

The downside to having an error reporting feature is the dismay you’ll feel if you discover – as I did – that a huge number of problems aren’t your fault, but are instead caused by third-party software (especially anti-virus programs, buggy graphics drivers, and flaky web browsers). These are the most frustrating bugs because your code isn’t wrong, and you can only hack together a workaround rather than truly fix them.

Anyway…thanks to the error reporting feature, I’ve identified and fixed the top 10 most reported errors. All of these fixes are included in FeedDemon 2.8 Beta 2, which was released today.

Helpless Icon Carnage

Published on November 3, 2008 by Nick Bradbury38 Comments

Last week I went on a toolbutton slaughter, and now the carnage has expanded to the icons in FeedDemon’s newspaper.

Each article in a FeedDemon newspaper has a series of icons beneath it, and over time the number of icons has grown to the point that they’ve become a serious distraction. For example, with the addition of the sharing and tagging icons in the upcoming FeedDemon 2.8, each article would have 10 icons beneath it:

Most customers use only a few of these icons, so I’ve removed most them by default in FeedDemon 2.8:

Power users, of course, will want to customize the icons, so I’ve added an “Icons…” button to Options|Reading which displays this dialog:

While I’m still in the mood to clean up FeedDemon, where else should I target for simplification?

The Great ToolButton Slaughter

Published on November 1, 2008 by Nick Bradbury13 Comments

Looking back at early versions of FeedDemon, it’s obvious that I was raised in the Microsoft Office school of user-interface design. Namely, fill your application with toolbuttons, the majority of which most people will never use. Here, for example, is what the toolbars in the first version of FeedDemon looked like:

What on Earth was I thinking? There were so many toolbuttons showing that I had to stack toolbars on top of each other to fit them all. At the time I thought I was giving customers the features they wanted, but what I was really doing was scaring people away by overwhelming them with far too many choices.

Each version since then has been an exercise in killing toolbuttons. By the time FeedDemon 2.0 rolled around, the toolbars were starting to look more sensible:

Much better, but really, the only toolbuttons that need to be showing all the time are the ones that most people will use all the time. The other ones can be moved to menus and keyboard shortcuts, where they’re out of the way yet still accessible.

With that in mind, I’ve pared back the toolbars yet again in the upcoming FeedDemon 2.8:

As was the case with the sharing feature I discussed in my previous post, I should’ve taken a simpler approach with FeedDemon’s toolbars from the start. I’ve learned the hard way that simplifying what you’ve already released is a lot harder than designing something simple to start with (especially since changing what existing customers have become used to is a sure way to annoy them).

PS: Power users who relied on previously available toolbuttons can always add them back – just click the “Customize” arrow at the far right of the toolbar.

Really Simple Sharing

Published on October 27, 2008 by Nick Bradbury16 Comments

It’s a common complaint of software developers: their customers keep asking for features that already exist. That’s happened to me more times than I can count, and it used to frustrate me – until I realized I was the problem. I had designed those features so poorly, or buried them so thoroughly, that they weren’t being noticed.

I bring this up because I keep seeing comments from people saying they’d like to use FeedDemon, but they really need a “sharing” feature like the one Google Reader has. Or I’ll read a review of FeedDemon that says the lack of a sharing feature is a strike against it. Which bothers me to no end since FeedDemon has had sharing for quite some time (and NewsGator Online has had it even longer).

The reason so many people miss FeedDemon’s sharing feature isn’t due to “user error,” of course, but because I made it too geeky and too hard to find. In order to share an article in the current version of FeedDemon, you have to copy it to a “clippings folder” that has an RSS feed – and as you can see, it’s far from obvious how to do this:

Create a clippings folder
Choose to share it as an RSS feed
Click an obscure icon under the article’s headline to display a menu of clippings folders
Choose the clippings folder you want to copy the article to

Not exactly the simplest approach, huh?

So I decided to rectify this in the upcoming FeedDemon 2.8 by adding a single, obvious “Share” link – which is how I should’ve done it in the first place.

Simply click “Share,” and FeedDemon will copy the article to your shared clippings. New users who don’t have any shared clippings (and probably don’t know what they are) can still use this feature, because it takes care of configuring everything without all the “geek speak” of the current version.

PS: I hope to release a public beta of FeedDemon 2.8 within the next 10 days.

Your Customers Have Enough Work to Do

Published on October 17, 2008 by Nick Bradbury1 Comment

If you haven’t had enough of a preview of FeedDemon’s upcoming tagging features, then check out this guest post I wrote for the NewsGator Widgets Blog.

“One of the more challenging tasks developers face — regardless of whether they develop desktop applications, web applications or even widgets — is designing a feature in a way that not only hides the technical details, but also respects the end user by not asking them to do too much work.”

I talk about how adding a feature requires thinking about the extra work you’d require of your customers if you don’t design it correctly, with FeedDemon’s tagging features used as examples.

FeedDemon Tagging Update

Published on October 7, 2008 by Nick Bradbury25 Comments

Thanks to the great feedback on my previous post, I’ve made a couple of updates to FeedDemon’s upcoming tagging support.

First off, I’ve added tags to FeedDemon’s subscription tree, as shown in this screenshot (click to enlarge):

Selecting a tag in the tree displays a newspaper containing all posts with that tag.

I’ve also added “suggested tags” to the tag editor, which attempts to recommend tags for the selected post:

I’ll be fine-tuning the tagging features even more before this version is released, of course, but I plan to keep it simple. I know there’s a lot of tagging-related stuff I could add, but complexity is something I hope to avoid :)

Tagging in FeedDemon: What Would You Like to See?

Published on October 6, 2008 by Nick Bradbury25 Comments

I’ve been adding support for tagging to FeedDemon, and I wanted to pass the new features by FeedDemon customers to see if I’m missing anything.

The way it works so far is that FeedDemon’s “Subscriptions Home” report now includes a list of tags you’ve used, as shown in the screenshot below (click to enlarge):

Clicking one of these tags displays a newspaper showing all posts you’ve added that tag to (click to enlarge):

As you can see from the above screenshot, the newspaper now shows each post’s tags, and clicking one of these tags shows all posts which have that tag. Tagging a post is as simple as clicking the new “Edit Tags” icon and then entering a list of tags, or selecting from tags you’ve already used:

You can also manage your tags in bulk, renaming or deleting them across all posts:

Tags added to posts in synchronized feeds are passed to NewsGator in the background, so any tags you add in FeedDemon will be available in NewsGator Online or any other application which syncs with NewsGator and supports tagging.

So, that covers the basics of where FeedDemon’s tagging support currently stands. Beyond these features, is there anything important I’m missing? What tagging features would you like to see?