Nick Bradbury

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.

Simplicity Ain't So Simple, Part IV: The Blessed Curse of Power Users

The types of applications I've created would never have survived without power users, so I do everything I can to keep them happy.  If you're a developer, I recommend that you keep your power users happy, too.

Power users who love your software will talk about it in online forums, say complimentary things about it in their blogs and convince their coworkers to buy it.  They'll make great feature requests, give detailed bug reports, help less experienced users get up to speed and provide an incredible amount of help during betas. 

But there is a downside.  You need power users, but power users can be the enemies of simplicity.

Power users will request features that nobody else wants, and they'll ask that existing features provide a ton of options that maybe 1% of customers care about. More than anything else, power users want to be in control of the software they use, so they'll choose something complicated over something simple if doing so leaves them in charge.

You might think you can ignore them and cater to mainstream users, but you risk having power users constantly deride your work if you create something they hate (Microsoft Frontpage comes to mind here).

So how do you keep them happy without scaring off new users? 

It really boils down to doing what I recommended in part I of this series: figure out which features - and which options - you need to make obvious and which ones you need to hide.  You can hide things that only power users want.

Most power users are the unofficial support technicians for their friends and family, so they understand your desire to keep things simple.  Power users can accept that some features need to be buried beneath a menu or obscure setting, and they usually won't complain if they have to spend a minute or two customizing your software to get it to work the way they want.

By all means keep your power users happy, but make sure you don't increase your software's complexity in the process.  Both sets of customers will be happier for it.

Simplicity Ain't So Simple, Part III: Don't Add Features You Can't Support

Making software simpler for end users is incredibly important, but sometimes simplifying your software means making things simpler for you, the developer.  And the best way you can do that is to avoid adding any feature that would bury you in support costs.

I'll give you an example: a number of FeedDemon customers have asked for an integrated blog publishing tool, which certainly sounds like a good idea.  However, I've avoided adding one because it would be too hard - and I don't mean too hard to develop, but too hard to support.

Most blogging services enable third party applications to post to them through a "standard" API, but I'll wager that every developer of a blog posting tool has experienced hair loss trying to deal with all the creative ways that blogging services support this API.  And they must quake in their boots when they hear that a popular blogging service is coming out with a new version, since that often means changes to how external tools post to them.  These developers probably spend a huge chunk of time dealing with "bug reports" that are caused not by their application but by changes to blogging services.

If blog posting was FeedDemon's primary purpose, I could accept this support burden.  But it's just one feature among many, so it wasn't worth it.  I figured I was better off integrating with third-party tools that provide the same functionality. 

So before you add that cool new feature to your software, take a minute to consider whether the benefit to your application is worth the time you'll spend supporting it.  You don't want to find yourself unable to keep up with the competition because you're spending too much time supporting features you didn't really need to add in the first place.

Simplicity Ain't So Simple, Part II: Stop Showing Off

One mistake I see developers make over and over again is that we make a feature look complicated just because it was hard to create.  We may not be aware of it, but we want our customers to know when we sweated blood during development, so we'll design a feature's user interface in a way that shows off how much work went into it.

We're doing our customers a disservice when we do this.  We should instead show off how good we are at making complex things simple.

For example, the prefetching feature I blogged about last week hasn't been easy to create.  This feature prefetches (downloads) links and images in your feeds so that they're browse-able inside FeedDemon when you're working offline.  It works in the background so you can keep using FeedDemon while it does its business, and it's smart enough to skip web bugs, links to large downloads, and other items that shouldn't be cached (including items that have already been cached in a previous session).

It didn't seem like a complex feature when I started on it, but it ended up being a lot more work than I anticipated.  It could easily be an application all by itself, complete with all sorts of configurable options.

But instead of turning this feature into a mini-application, I demoted it to a lowly menu item:

That's it.  All that work for what looks like a simple, tiny little feature to end users.  I didn't even expose it as a toolbutton on one of the main toolbars, since I figured it was a feature that at most 20% of my customers would need.

But the end result is a feature which is simple to use, especially for those new to FeedDemon.  Users can just click a menu item and not have to deal with knowing how it all works.

And I still get to show off by blogging about how much effort went into it :)

PS: Chances are power users will demand some configuration options and per-feed settings for this feature, but any options I make available won't be exposed within the feature itself.  Doing so would force new users to know about them, making the feature appear more complicated than it needs to be.

Simplicity Ain't So Simple, Part I: Decide What to Hide

Joel Spolksy is right about simplicity and the 80/20 rule:

"A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it's never the same 20%. Everybody uses a different set of features."

Simplicity is a goal all developers should strive towards, but it's a mistake to think that simplicity means having a small feature set.  You're rarely going to sell more copies of your software by providing less features.

If you want to sell more copies, focus on figuring out which are the features that 80% of your customers want and make them obvious, then make the other features less obvious but still easily accessible through a menu item and/or keyboard shortcut.  That way new users aren't overwhelmed by the sheer number of toolbuttons staring them in the face, and power users aren't underwhelmed by the lack of features.

The hard part, of course, is figuring out which features fall in the 80% category.  If you hide a feature that 80% of customers want, they might not try your software long enough to discover that it actually does what they need.

This is one place where beta versions come in handy.  Beta versions don't have to be used just to find bugs: they can also be used to figure out which are the most important features.

Sometimes in beta versions I'll deliberately remove (or obscure) access to a specific feature just to find out if people really use it. If a lot of beta testers complain about the feature being removed, then it's an 80% feature that needs to be an obvious toolbutton. If only a few complain, then it's a feature that only 20% want so it can be demoted to a menu item.

If you're a developer, take a look at your UI and try to figure out whether all those toolbuttons really need to be there by default.  Chances are you can hide a lot of them, which will make your application simpler to learn without making it any less powerful.