🚀 go-pugleaf

On the subject of "virtual folders":
1. It has been suggested that having two different kinds of folders on a
   single volume might be confusing.  To this I respond
   a. We already have most of this confusion by having different kinds of
      folders on different volumes (i.e., MFS vs. HFS).  Making this
      distinction explicit by giving the two different kinds of folders 
      different icons should help reduce the confusion.  Incidentally, I
      would suggest giving MFS folders a "virtual folder" icon whether or
      not "virtual folders" are implemented on HFS volumes.
   b. If there is great concern about having two different kinds of folders,
      then let "virtual folders" have an entirely different characterization
      in the desktop paradigm.  For example, you might characterize a
      "virtual folder" as a sheaf of documents held together by a paperclip.
      (I would say "stack of documents" if it weren't for the confusion with
      Hypercard.)  This could help emphasize that the documents in such a
      sheaf retain their individual identity as documents and thus must be
      uniquely named, appear together in the SFGetFile dialog box, etc.
2. It has been suggested that using "virtual folders" in place of real folders
   would result in less efficient use of the file system.  On this I agree,
   but "virtual folders" were proposed not for situations where real folders
   can be used, but for situations where real folders cannot be used and
   further organization is still desirable.  To emphasize this intended
   distinction, I would make "virtual folders" slightly harder to create.
   For example, I might let the New Folder command work as it does now
   (create a real folder on an HFS volume or a "virtual folder" on an MFS
   volume) and require the user to hold down the option key while selecting
   New Folder in order to create a "virtual folder" on an HFS volume.  I would
   hope that this slight knowledge and work barrier would mean that people
   use "virtual folders" only when they really needed them.
3. Concern was expressed that the "virtual folder" structure would be lost
   when the desktop file is rebuilt.
   a. Rebuilding the desktop loses other information (e.g. file comments and
      the icons of documents whose application are not on the same volume).
      Being forced to rebuild the desktop is a catastrophic situation, in my
      opinion. 
   b. In newer releases of the finder, rebuilding the desktop lost the names
      of MFS folders, but not the organization of files into those folders.
4. It was suggested that 90% of the problem would be solved by making INIT 31
   and the Control Panel search specially named subdirectories of the system
   directory (allowing real folders to be used for organization).  I can't
   speak for the person who made the orginal suggestion, but for me this would
   help with only about 25% of the problem (and that percentage is probably
   diminishing).
   a. As applications become more complex, many require the presences of
      supports files (e.g. help files for almost any complex application;
      dictionaries, a thesaurus, and glossaries for a word-processing
      application; instrument descriptions and phrase libraries for music
      programs; etc.).  Although some of these programs have more sophisticated
      automatic searches for these files, many search automatically for them
      only in the folder containing the application and the system folder.
      This problem is especially obnoxious if the application is so heavily
      used that you would like to place it on the desktop.
   b. As more and more applications become compatible with being run from
      file servers, it becomes increasingly common to store user customizations
      in some kind of "settings" file in the system folder.  This also seems to
      be a popular choice for where to put other "permanent" information
      (e.g. DiskFit's list of the SmartSets it knows about and what is on them).
   I would be happy to see system changes such as the ones suggested for
   INIT 31 and the Control Panel, as well as ones for print drivers and "prep"
   files, scrapbook and clipboard files, other code resources (such as
   Macintalk, AppleTalk, and EtherTalk), etc., but the problem won't really
   be solved until you find a clean way to organize application support and
   "settings" files, and its not clear if there is a system change that would
   do that automatically.

To me, taking two features that already exist and are likely to continue to
exist (i.e. the handling of folders on HFS and MFS volumes) and allowing them
to be used together is a simple and fairly elegant solution to a continuing
organizational problem in the visual access to the file system.  If Apple
would prefer to ignore the behavior of MFS folders and seek other solutions,
thats fine with me, but make certain you address the applications software
side of the problem as well as the systems software side.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications