« Simplicity Ain't So Simple, Part I: Decide What to Hide | Main | Simplicity Ain't So Simple, Part III: Don't Add Features You Can't Support »

Monday, December 11, 2006


Feed You can follow this conversation by subscribing to the comment feed for this post.

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!

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.


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.


The comments to this entry are closed.