I agree that a graduated hierarchical system is best. A good model for designers would be the techniques used by modern game designers. Most modern games are extremely complex and have a graduated system in which you master one aspect before moving on to the next. If learning a program or OS can be done in a similar manner to learning a video game it might work.
Personally I think the solution to the "hierarchical" problem is search. Apple has done a great job with the Spotlight tool. A similar "search" based function launcher might work well to provide access to features that beginning users don't care about but advanced users want.
I'm using the opportunity of this article - which is centred around iphone issues - to discuss something related I've been thinking about in the hope of thoughtful feedback.
There's a progression through ideal structures as your volume of data changes. 1) Flat. Like the filesystem with early versions of DOS. 2) Tree. As presented by contemporary operating environments. 3) Tagged collections.
There's a recurring pattern where you have a home directory and you get so much data in it that you start losing it. I might deal with five support requests a day, and want to reference them for the next two years. I can usually remember when I dealt with them chronologically, but don't trust the standard filesystem (and backup operations, etc) to preserve this. This guy's comments about spaciality are apt for the iphone setting.
This quest for spaciality gets taken to stupid conclusions, as in the OSX finder (I'm now diverged from this guy's post). Spacial placement is irrelevant for anyone dealing with large amounts of data, and not a priority. And that's pretty much anyone who uses their computer for work.
I've written a unix tool that allows me to manage my data as collections of projects. It's called silo. To create a project I do this:
2) Symbolic link to that directory at $HOME/seq/03.project name
The filename in #2 above assumes it's the fourth third project I've created - the next one will be 04, then after 09 it renumbers them so they all have the same number of digits so ordering works for visual display and tab completion. I can destroy projecs, and then rebuild the sequence structure to compact it with 'si -r'. It gives me unique paths for tab completion.
I can rsync these structures around and have complete confidence that it will retain the date, username and hostname for me to order and sort on, because it's inherent to the filename itself of the base directory. This makes for easy backup arrangements using crontab and sshkeys.
I haven't released it yet because I'm just to finish off tagging. Tagging will allow me to crete a second symbolic link structure so that I can go into this directory to find links into the projects which relate to work:
$HOME/tags/work
Filesystem metadata is the wrong direction because it doesn't work across simple backup solutions properly, and if you're discouraging users from backing up then you're doing something wrong.
You could offer GUI environment consumers an interface that was both discoverable and scalable by moving the emphasis on 'directories and files' to 'projects and documents'.
Back to the issue of structural complexity. We've had flat languages (scripts), then programs with goto (still pretty flat), then structured programming (tree). Then modules and packages which is starting to enter collection territory, and cpan - more so. But that emphasis is on the library systems rather than the code. I sometimes thing about this at a high level and wonder how far you could push the boundaries on building a 'collection-oriented' programming language. For example - could I have a cron script that threw a launch wrapper at all folders which were tagged 'cron.run.me' and which weren't currently tagged 'running'? Within the project the logic could just be pointers to modules. The effect would end up being a bit like the scheduler you get in socket programs where there's a list of things to do, and the effect of an action in that list would be to defer something by registering it in another list for some other action to deal with, and then closing.
Personally I think the solution to the "hierarchical" problem is search. Apple has done a great job with the Spotlight tool. A similar "search" based function launcher might work well to provide access to features that beginning users don't care about but advanced users want.