Here's an idea I had for a new UI paradigm...
Take an application like ThumbNailer:
The first screen is simple, just a few fields to fill in and a few buttons to click. It's (hopefully) not too intimidating. But, if you hit that Advanced button, you get this:
Yow! I wrote the thing, and it startles me how dense it is, every time I see it.
Each of those items in the tree on the left side represents a page-full of options on the right side. There are literally hundreds of options, many of which interact with other options. And, there is an entire text-formatting language including primitive database lookup and file I/O, an HTML template format, plugins, a scripting interface, timer-based operations, etc.. There's a huge sprawling monster of an application hiding behind that Advanced button (and it's going to get even bigger in a few weeks when we release version 9).
It's very powerful and very configurable, and I'm sure it's very intimidating to most computer users - even to sophisticated users. And, that's a problem, obviously, because people are less likely to buy stuff that they are intimidated by.
So, how do you avoid that?
One way is to dumb-down the software: take out all those options and make a program that only does one or two very narrowly-defined things. The problem with that is that as users start using it, they start wanting it to do more - they ask for features that help them better solve the problems they encounter, and everybody encounters different problems. So, programs grow organically as people find new things they want them to do. That's what happened with ThumbNailer - back in version 1, there was only one Preferences screen, with a half-dozen options. It just read images from one folder, resized them, and wrote them to a new folder - now it has its own built-in scripting langauge. But, over the past 9 years, it's grown immensely - as has Windows and Word and Outlook and Excel and every other program anyone uses (except Notepad and Minesweeper). What starts out simple becomes complex as people demand more features.
Another way to help deal with the complexity is with "wizards", which step users through common tasks, offering only a few options at a time. ThumbNailer has a few wizards, but as with all wizards, they do nothing to help users understand the deeper features; they only apply limited subsets of options, through a completely different interface than normal, in order to solve some tightly-constrained problems. And, while that's not necessarily bad for the user - if the wizard solves the task at hand, that's great - it doesn't give users access to the full power of the program. Also, wizards are also a pain in the ass for programmers. And we have to be considerate of the poor programmers.
But, another option is this: applications could start off showing users only the high-level options for the high-level features. In ThumbNailer, for example, the new user would press the Advanced button and only see a handful of simple high-level options. The myriad other options wouldn't just be grayed-out, they wouldn't even be visible. But, as the user started using this or that feature, sets of options related to that feature would start appearing. They'd be introduced gradually, based on how the user was using the program. If the you never used the high-level HTML features, you'd never see the low-level features. If all you ever did was convert PCX files to JPG files, you'd only see the set of options for PCX, JPG and 'conversion'. This would allow the user to become familiar with the program a bit at a time, without inundating him with options the first time he uses it. This requires that the program's options can be cleanly segregated into different levels of sophistication, obviously.
One problem with the approach as described above is that not seeing the options for the low-level features could lead you to assume the program doesn't have those features. Grayed-out controls solve that problem, in most programs, by showing the user what's possible to control, even if you can't control it right now. But again, a screen-full of controls intimidates users. Moving them to different screens doesn't help much since that just increases the number of screens a user has to know about (see the left side of the Advanced window, above). So, in my scenario, a program would have to have a way of advertising hidden features without throwing a hundred grayed-out checkboxes in the users face. That could be done in the help file, or right in the program somehow - maybe with a 'preview' window associated with each feature. The user could bring up a preview window to get a brief description of the options he's not seeing (and what they do) because he's never explored this or that feature.
And of course the user could manually choose to view option sets even if he's never used that feature - overriding the option-hiding 'intelligence', in effect.
I've never seen this kind of thing in any program. Most programs hide features down levels of nested dialogs, or on tabbed dialogs or tree'd-dialogs (like ThumbNailer) or tree-like controls (which are all really the same thing, with just a different way of choosing which sub-dialog you're seeing). There are most-frequently-used paradigms in some of the menus in Microsoft's applications, which is similar but not the same - those menus hide menu items you don't use, they don't configure themselves based on the features you use.
So, maybe I'll experiment with this. Aside from the fact that it would help overcome the intimidation factor, it might also be kindof fun, to watch new options appear as you become familiar with different facets of the program.
On a side note, I suspect this idea is patentable (if it isn't already) - though I'm not about to try patenting it.
