Now blogging at diego's weblog. See you over there!

invisible features

[via Erik, Charles]: Joel gets it right in his short comment about invisible software features:
Unnecessary UIs [...] that pop up to brag about a cool feature the developer implemented are a little bit obnoxious. Too many software developers just can't bring themselves to implement completely invisible features. They need to show off about what a great feature they just implemented, even at the cost of confusing people. Really great UI design disappears. It's a matter of taking away, not adding.
I agree 100%.

This is really hard to do, and it definitely takes discipline. For example, a lot of work in clevercactus has gone into creating deep integration without forcing abstractions, a bit like playing around with puzzle-pieces until they fit. The result is that, if you look at a screenshot, cactus looks very much like an email reader. This is both good and bad.

It's good because there is less cognitive overload (in UI-speak), and because features "appear" when you need them, and can be ignored when you don't. It's bad because users might tend to focus on one feature alone, and not see the other features at all. And, this not by any fault on the user's part, but because the program doesn't expose them properly.

For example, a couple of weeks ago Francois posted a comment about cactus on his weblog that is a good example of what I mean. He discovered things incrementally, things that were "invisible". Francois knows software, and he can poke around the program and understand what he's seeing. Most users, though, won't. They probably won't get to the point where they have to ask themselves "What is this weblog posting thing he's talking about?". They won't see it at all. And, arguably, no one should have to spend time discovering features.

So cactus needs more work in creating "soft exposure" of features that are available. A short tutorial would be useful, but the UI needs soft clues to show the user what the program can do. Clues that are soft enough so they can be safely ignored, but also visible enough so that if the user is curious, and has some time to spare, the feature can be checked, help on it obtained, etc.

Which brings me back to Joel's example.

Apparently, this is not necessarily the case Joel was mentioning. His example is a feature where there should only be one behavior, and so asking the user is overkill (and/or showing off). The feature should be invisible, yes. But somehow the user should be made aware of it. Why? Well, for starters, it's good to know what your software is doing to your data (if the data was created by for program for internal use it's a different matter), and then we have the more prosaic case in which a user wonders "I know this site changed its URL, I wonder how did the program deal with it". Giving information in this case seems eminently useful. So how to do it? In this particular case, in my opinion the URL should update itself in the bookmarks with no message, but the next time the user opens the menu the bookmark will appear with a different color and maybe with a temporary submenu or other UI widget to "learn more" about what the color means. The temporary UI widget would explain what changed and why. User satisfied, feature exposed. But only if necessary. Categories: clevercactus,
Posted by diego on June 30 2003 at 12:40 PM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37