1) Simple
a. Names with a well-defined purpose. Avoid /usr, /opt, /var, /etc.
b. Names short but memorable. Avoid “Documents and Settings”.
c. Not too many directories at each level.
d. Minimum ambiguity as to where a file belongs.
e. Parallel structures where possible.
2) Complete
a. A place for everything. Names not so specific as to leave gaps.
b. Extensible. A larger number of “semi-standard” optional dirs.
3) Useful
a. Easy to separate files in different categories – all files to restore a system, all system files added after the base install, all user data for a backup, etc.
b. Convenient mount points for external disks, etc.
/sys/
bin/ docs/ libs/ local/ dev/ mnt/
/prog/
bin/ docs/ libs/
/cnfg/
sys/ prog/
/data/
/temp/
/home/
<user>/
prog/
docs/ ...
cnfg/
sys/ prog/
data/
sys/ prog/
temp/
/install/ - package downloads, installation notes, etc.
/sources/
...
The directories above are just the most common ones for a typical installation. All may be extended in a parallel fashion. e.g. a user who wants to replace a program that other users still need, should add bin/ and libs/ under his own /home/<user>/prog/. He could even add a /home/<user>/sys/, but this should probably be discouraged.
There will always be ambiguity as to whether some files belong in one place or another (e.g. is it a system program or an application program?). A good structure will minimize the number of places users have to look.
/sys/local/ - system files not part of the original install, or not installed on all machines. Subdirs might include bin/, docs/, libs/.
/cnfg/ - configuration files. Keeping these files separate allows a system to be easily restored from its original distribution files. These may be over-ridden by files at the /home/<user>/cnfg/ level.
/data/ - variable data files. Less permanent than /cnfg/, more permanent than /temp/. e.g. system logfiles.
/temp/ - files that really are temporary, and can be deleted any time with no backup.
/home/<user>/data/prog/<progname> - user data that is more conveniently kept under a program name than a project name. e.g. mailboxes and other files associated with a particular email program.
/install/ - large packages and other files you might need for a re-install of /sys/ or /prog/.
The proposed directory structure is really a compromise between Unix and Windows styles. Windows is certainly a more “user friendly” system, but it goes too far in assuming users know absolutely nothing. Verbose names like “Documents and Settings” are an annoyance to type, and have to be edited out, for example, when inserting automatic pathnames in a footer. “DnS” would be a much better choice. Separate directories (“data” and “cnfg”) would be even better.
The problem with the old Unix directory structures is that many of the directories have no clear purpose. This has led to inconsistencies between one version of Unix and another, and problems for both program developers and users.