Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert From: hirchert@uxe.cso.uiuc.edu Newsgroups: comp.sys.mac Subject: Re: 'Virtual' Folders - good idea!! Message-ID: <46100167@uxe.cso.uiuc.edu> Date: 21 Jun 88 17:14:00 GMT Lines: 76 Nf-ID: #R:<8806161351.AA09732@decwrl.dec.c:-35:uxe.cso.uiuc.edu:46100167:000:5120 Nf-From: uxe.cso.uiuc.edu!hirchert Jun 21 12:14:00 1988 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