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

the standards debate

Jon has a summary of the state of the discussion, and I mostly agree with his conclusions. I think there's no doubt that Echo's happening, which is good. Also, there's no doubt that, ideally, it would be better if the process involved less infighting and was more evolutionary. But as Jon says (and as I've said before) that the cost of switching RSS formats won't be as high as in other cases.

Categories: technology
Posted by diego on June 30, 2003 at 8:28 PM

the three-pane question

Software that deals with information in general, and with email (or RSS) in particular, has, over the past few years used a relatively standard three-pane interface, as shown in the following sketch:

The new interface that has been appearing more often contains essentially the same components, but in a horizontal layout:
Used where? I've noticed it in several new programs (or new revs of old programs), but here are a couple of concrete examples: the RSS aggregator for IDEA, FeedDemon and, more importantly for wide adoption, the next version of MS Outlook.

The "all horizontal" mode is better IMO, since it gives you more space to view information (which is typically "long" rather than "wide"). It also makes it easier to follow the progression of "contained" information: as you move along the x axis to the left, you increase specificity--this consistency can then help in other areas of the UI. Apple for example has used the all-horizontal paradigm for one of the settings of the file browser in the Finder, and it's much, much better than the alternative. Simple and easy to use.

The all-horizontal mode has one drawback: You need a bare minimum of 800x600 to be able to use it well. (or maybe 1024x768?). This limits it mass appeal a bit, but it's probably safe to say that people that use 640x480 are probably late adopters, and not likely to be trying out new software anyway.

So I'm considering making the horizontal view the default for the next beta of cactus, and it might even be useful to allow in-place editing of some elements (say, contact or task information). Comments?

Categories: clevercactus
Posted by diego on June 30, 2003 at 1:47 PM

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.