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.
Good point and example. Coding so that parameters that may change are variables is generally a good programming practice. However, exposing those variables is rarely good UI. As you pointed out, it’s typcially only in special cases that the defaults are inappropriate. In such cases, users needing special settings will let you know. Even then the change is typically only made once then left as the new “default”. It just makes sense to keep such options away from the day to day use of a feature.
Great post! A good indicator of quality of design is the lack of documentation or explanation required for users to just “get” the system.
Conceptual elegance can be very difficult to achieve (especially for complex problems), but it is worth the effort. Of course, then the only problem is that users don’t get why you charge so much to develop the software (if it is custom for them) as it just looks like you’ve done something very simple :->
I love that “making complex things simple” line, thanks. :)
Does the interface tell me the user costs of the feature in any way? Many times when I see such offers in interfaces I wonder why they’re not the default… I figure there must be a tradeoff somewhere. Are the costs exposed in any way…?
tx, jd
Great post, you’ve articulated a concept that more developers should understand beautifully.
And as a lowly user, I just have to say that I’m *DROOLING* over that screenshot!
Jubilee Thoughts: When the Simple is Hard
JD, in this case I do plan to let users know that enabling pre-fetching on a per-feed (or per-folder) basis has some additional costs (ie: it will take longer to update your feeds), but in general I only do this when the cost is one the user would reasonably care about.
Hi:
It’s apparent that you and I think alike. It is often that I complete a “feature” and then see that I have added too much importance to it in the presentation. At such times, I have to back-off and re-evaluate the feature on the basis of how can I simply the UI.
I claim that simplicity of the presentation is often inverse to the complexity of the programming. It takes effort to make things simple.
tedd