hunt@atse.dec.com (Phil Hunt) (06/16/88)
I always thought that the idea of 'Virtual' folders, ie MFS-type folders on an HFS disk was a good idea as an organizer. You could place all your INITs in a Virtual folder that visually unclutters the desktop display, but to the system, these items look on the directory level the virtual folder is stored in. Apple, does this not sound like an excellent idea? My system folder currently contains 106 files (26 inits) and assorted 'Preferences' files created by applications.... Phil Hunt
t-jacobs@utah-cs.UUCP (Tony Jacobs) (06/16/88)
YES, YES. Apple Please do it!!! And why you're at it, how about a virtual directory, a folder that keeps track of all the floppies you ever look at and allows you to search for unmounted files on those disks. This would only be feasable for hard disk users I suspect as the space required to save all those directories could get quite large. If you could delete, rename, and move those files from unmounted disk to disk, you could do a real nice job of organizing archives and keeping track of files. I have some 200 - 300 floppies and it gets to be a real pain to find things sometimes.-- Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu
chow@batcomputer.tn.cornell.edu (Christopher Chow) (06/17/88)
In article <8806161351.AA09732@decwrl.dec.com> hunt@atse.dec.com (Phil Hunt) writes: >I always thought that the idea of 'Virtual' folders, ie MFS-type folders on an >HFS disk was a good idea as an organizer. You could place all your INITs in >a Virtual folder that visually unclutters the desktop display, but to the >system, these items look on the directory level the virtual folder is stored in. > But why even use virtual folders? Why not use true folders? The system could look for cdevs in a cdev folder, inits in an inits folder, etc. Of course, to keep compatibility the system should also look in the system folder itself - this way people who don't know about this feature won't get stung by it. But, for people who know this could save substantial amounts of time when using either the control panel, chooser, etc. There's no reason why the system folder itself has to have tons of files in it. All it would take is a simple modification to INIT31, the Chooser, and the Control Panel. --- BTW, a few system updates ago Apple released a change log documenting what changed between system distribution. Since they no longer seem to do that, does anyone know exactly how system 6.0 and 5.0 differ? Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-201-836-3673 Address: 671 Forest Ave, Teaneck, NJ 07666 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
werner@utastro.UUCP (Werner Uhrig) (06/17/88)
you all know the problem: you go to the library to find a book or magazine (you know exactly where it should be!), but can't find it ... or you take a folder to your desk from the archives, and while you have it there, noone else can look at it or even find it. I'd also like to be able to use the ZOOM-box to cycle through THREE (3) or more window configurations. How about "clicking on ZOOM-box while holding OPTION" ads current window configuration to list of possibles ... (until window is closed, anyway)... I'm sure there are more elegant ways of implementing this. and how about adding TEXT-SWAP to CUT, COPY, and PASTE. better call it CLIPBOARD-SWAP, because I also want a CLIPBOARD-APPEND. not to speak of a RING (not STACK) of Clipboards ... what's the big problem, anyway ?? but mostly I'd like symbolic links to files/folders, oh, and files of type "generation" where new copies do not supercede the old-ones; but rather get created with a new name(version-number is appended) ... complex deletion rules should possible ... I'd also like to have a special folder SCRATCH, where I can put in files that I am willing to see delected should the system find the hard disk is full and wants more free space. That would allow me to trash files without them actually getting deleted before I run out of space - because sometimes, I find having a file around still a day/week later quite useful. I'd also like to be able to flag my files as SPACE-DELETABLE, indicating that the system should remember where (on which floppy) the backup copy is stored, and go-ahead and free up the space when it is needed, but not remove the file, but maintain basic info about it in the directory (catalog?) .. oh, I could go on. years ago, I started a "wish-list", maybe we should collect "wish-lists" on the net, merge them, and have people prioritize them (vote on them?!) ... and then submit our "demands" (-: to Apple ... back to reality ......
ccasths@pyr.gatech.EDU (Scott Hinckley) (06/18/88)
In article <5560@utah-cs.UUCP> t-jacobs@cs.utah.edu.UUCP (Tony Jacobs) writes: >I have some 200 - 300 floppies and it gets to be a real pain to find things >sometimes.-- >Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu 200-300 floppies? I hope they are all data or bought/public programs. The only time I ever had that many was when most of my software was...well...lets just say I lost the originals. Now I am down to 15 application disks and about 40 data disks. Also about 15 program disks. That isn't even 100. +=======================================================================+ |Scott Hinckley - OCS User Assistant AKA - Galaxy's End | |Georgia Insitute of Technology, Atlanta Georgia, 30332 | |uucp: ...!gatech!pyr!ccasths | |ARPA: ccasths@pyr.gatech.edu | +=======================================================================+
dorourke@polyslo.UUCP (David O'Rourke) (06/19/88)
In article <8806161351.AA09732@decwrl.dec.com> hunt@atse.dec.com (Phil Hunt) writes: >Apple, does this not sound like an excellent idea? My system folder currently >contains 106 files (26 inits) and assorted 'Preferences' files created by >applications.... I think this is a great idea!!!!! It would also be good for help files and other things. Now if Apple were to provide a way of pathing like is {uggh} MS-Dos or Unix then we wouldn't need Virtual folders, can we please have one or the other Apple? I'm partial to Virtual folders myself, I hate having to have paths. -- David M. O'Rourke Disclaimer: I don't represent the school. All opinions are mine!
sg1q+@andrew.cmu.edu (Simon Peter Gatrall) (06/19/88)
The thing that everyone who has been so enthusiastic about this idea is forgetting is that it is hard to make complicated features like these transparent. The more "features" you add the harder it is to make a consistent, clear interface. I think this is the biggest problem facing software developers right now. When the Mac first came out, it was clean, and simple. Now, the "machine for the rest of us" is getting almost as bad as IBM. Instead of the trend of bigger and bigger systems, and bigger and bigger applications, Apple needs to reevaluate its whole system. It would be better if software could be even more compatible than it is now so that you could use many small applications as building blocks, instead of these big messy programs. Whenever you find people making keyboard macro programs and all sorts of add on features to "symplify" using a computer, you know something is wrong. People have a tendency to cure the symptoms of problems instead of the causes. -Simon Gatrall
gagaku@ucscd.UCSC.EDU (23527000) (06/19/88)
Since my original posting of this idea, I've seen a bunch of follow-ups generally enthusiastic, but nothing from programmers or Apple folks as to whether the concept is even feasible within the structure of the Mac System. Any ideas on this? One reply suggested that real folders could function equally as well if the system simply recognized 'cdevs' in folders labelled 'cdev' etc. This would certainly be a simple 'fix' for some problems, but would not be suffiently general. I still like the simpler idea of MFS-like 'virtual folders' distinguished by a distinctive icon (how about a folder with window-pane?). This would allow maximum flexibility and elegance in hard-disk organization. A work-around might be to have the system give the user an option to specify what folders it should look in for what sorts of files. But this begins to look like MS-DOS paths.. Rather than compiling an extensive wish list of other add-ins, perhaps if all of you who think this might be a good idea would e-mail me your comments, I could compile them and forward to the Apple Folks. Fred Lieberman gagaku@ucscd.ucsc.edu
paulm@nikhefk.UUCP (Paul Molenaar) (06/20/88)
In article <3216@polyslo.UUCP> dorourke@polyslo.UUCP (David O'Rourke) writes: #In article <8806161351.AA09732@decwrl.dec.com> hunt@atse.dec.com (Phil Hunt) writes: #>Apple, does this not sound like an excellent idea? My system folder currently #>contains 106 files (26 inits) and assorted 'Preferences' files created by #>applications.... # # I think this is a great idea!!!!! It would also be good for help files #and other things. Now if Apple were to provide a way of pathing like is #{uggh} MS-Dos or Unix then we wouldn't need Virtual folders, can we please #have one or the other Apple? I'm partial to Virtual folders myself, I hate #having to have paths. # Try using the Set Paths or HFSFind DA. I believe both do what you want. I created a Preferences, LaserFonts, etc, folder to which I point with Set Paths. Some (not all) applications fall for it. I surely agree that Apple should provide for this... . . such . a . waste . of . valuable . space . Paul Molenaar "Just checking the walls" - Basil Fawlty - -- Paul Molenaar "Just checking the walls" - Basil Fawlty -
peter@aucs.UUCP (Peter Steele) (06/20/88)
> But why even use virtual folders? Why not use true folders? The system > could look for cdevs in a cdev folder, inits in an inits folder, etc. Of > course, to keep compatibility the system should also look in the system > folder itself - this way people who don't know about this feature won't get > stung by it. But, for people who know this could save substantial amounts > of time when using either the control panel, chooser, etc. There's no > reason why the system folder itself has to have tons of files in it. All it > would take is a simple modification to INIT31, the Chooser, and the Control > Panel. I've always felt that when Apple introduced the HFS, they should have had some user interface guidelines to go along with the new feature. For example, instead of just dumping everything in the system folder, recommend to developers that they create a folder in the system folder for storing things like help files and dictionaries (and possibly even have sub-folders within these for storing things like temp files--I hate all these Word Temp files cluttering things up). And of course, as suggested above, there should *obviously* be folders for INITs, cdevs, fonts, etc. I see no need to reinvent the "virtual folder"--intelligent use of the exiting true folder would suffice much better. -- Peter Steele, Microcomputer Applications Analyst Acadia University, Wolfville, NS, Canada B0P1X0 (902)542-2201x121 UUCP: {uunet|watmath|utai|garfield}dalcs!aucs!Peter BITNET: Peter@Acadia Internet: Peter%Acadia.BITNET@CUNYVM.CUNY.EDU
sidlives@bucsb.UUCP (David Rho) (06/20/88)
In article <8806161351.AA09732@decwrl.dec.com> hunt@atse.dec.com (Phil Hunt) writes: >I always thought that the idea of 'Virtual' folders, ie MFS-type folders on an >HFS disk was a good idea as an organizer. You could place all your INITs in >a Virtual folder that visually unclutters the desktop display, but to the >system, these items look on the directory level the virtual folder is stored >in. > >Apple, does this not sound like an excellent idea? My system folder currently >contains 106 files (26 inits) and assorted 'Preferences' files created by >applications.... > >Phil Hunt This would truly be great. I know I have problems with clutter problems on my hard disk (80 meg). What would also be nice would be links to directores such as in unix. How about it Apple? David Rho
lsr@Apple.COM (Larry Rosenstein) (06/21/88)
In article <3818@saturn.ucsc.edu> gagaku@ucscd.UCSC.EDU (PUT YOUR NAME HERE) writes: >Since my original posting of this idea, I've seen a bunch of follow-ups >generally enthusiastic, but nothing from programmers or Apple folks as >to whether the concept is even feasible within the structure of the Mac >System. Any ideas on this? Since I don't have to implement any changes to the System, I guess I will comment. :-> The idea of "virtual folders" technicay possible, since it is done on MFS systems. I don't think it would be such a good idea from the user interface point of view. One would end up with 2 ways of organizing files that have subtle differences. Even if you make the virtual folder icons look different, the concepts would still be the same (a way to categorize files). In particular, you cannot have 2 files in different "virtual folders" with the same name. You can do this for "real" folders. This is likely to be confusing when the user sees the message "Replace file(s) with the same name?" because a file in some totally different virtual folder (at any depth!) happened to have the same name. Also realize that since these folders are constructed by the Finder, virtual folders would not be seen by any other programs (Std File, DiskTop, etc.). Also, recall that folder structure on MFS disks was lost when the desktop file was rebuilt. (Some of these problems might be corrected by changing the file system, but it seems strange to add two kinds of directories to a file system.) Finally, using virtual folders instead of "real" folders will slow the system, since one of the values of HFS was reducing the number of files in each subdirectory. Even though the icons would not be seen, the files would still be in the subdirectory, and the Finder would still have to determine if they were in the virtual folder or not. I think adding virtual folders is a hasty reaction to some problems with the Macintosh system. It would be better to write down what the problems are, and think about a cleaner solution. For example, one problem is the proliferation of cdevs, INIT, etc. in the System folder. As was pointed out, it would be simpler and cleaner to modify the System to search for these things in a subfolder. If this change would solve 90% of the problems, then it would make more sense than adding virtual folders and their possible complexity. >Rather than compiling an extensive wish list of other add-ins, perhaps if all >of you who think this might be a good idea would e-mail me your comments, I >could compile them and forward to the Apple Folks. This is always a useful thing to do, whether the topic is "virtual folders" or not. One can never guarantee that the suggestions will be adopted, but it never hurts. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
mce@tc.fluke.COM (Brian McElhinney) (06/21/88)
Simon Peter Gatrall writes: > The thing that everyone who has been so enthusiastic about this idea > is forgetting is that it is hard to make complicated features like these > transparent. The more "features" you add the harder it is to make a > consistent, clear interface. > > Instead of the trend of bigger and bigger systems, and bigger and > bigger applications, Apple needs to reevaluate its whole system. > It would be better if software could be even more compatible than > it is now so that you could use many small applications as building > blocks, instead of these big messy programs. One solution is to adapt Smalltalk's concept of a meta-document. To the user, the meta-document would be a system software application, allocating areas of a document for use among various data types. Word processors would have areas separate from drawings, etc. To the programmer, it would mean a new architecture that passes events to CODE-like resources that match the type of data the user is manipulating. The user interface is similar what we already have: the File and Edit menus belong to the meta-document, and the others change depending on the data selected. This is a radical change, and thus suspect. And of course there would be more to it than a single paragraph can describe. But with the new system software rewrite providing virtual memory and IPC, it will not be impossible. The Macintosh user interface has been static for a long time now; it's about time to move on. Brian McElhinney mce@tc.fluke.com
dtw@f.gp.cs.cmu.edu (Duane Williams) (06/21/88)
| I've always felt that when Apple introduced the HFS, they should have had | some user interface guidelines to go along with the new feature. For example, | instead of just dumping everything in the system folder, recommend to | developers that they create a folder in the system folder for storing | things like help files and dictionaries (and possibly even have sub-folders Apple should introduce a flexible search path mechanism into the file system so that the user can organize his files as he wishes, while minimizing the number of folders that have to be searched to find a file. The current "poor man's search path" is largely responsible for the clutter in the System Folder. It's well named. It was a poor idea. If the "poor man's search path" had just been the default value of a user definable search path, users could eliminate the clutter to suit themselves. The search path is nothing new to the Mac. The problem is simply that you can't edit/extend the one that's there. Duane -- uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw arpa: dtw@cs.cmu.edu
hirchert@uxe.cso.uiuc.edu (06/22/88)
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 Applicationstwakeman@hpcea.CE.HP.COM (Teriann Wakeman) (06/22/88)
Sometimes, there are just too many items in a directory (HSF folder) for easy identification. The user needs to scroll through a large window and scan a lot of items. I for one do this too often and find it time consuming. Having an additional sub-file of the MSF type would allow me to reduce visual clutter and allow me to keep items within a directory in such a way that I can find them quickly. It isn't always desirable to make all groups separate hirechical levels. I think this is a dandy idea. However, I also agree that a HSF style container and a MSF style container should look different and have different names to minimize confusion. Looking around my office for a desk top simile, all I could find was a file drawer (for HSF) and a folder (would revert back to its old MSF status). Hmmm..... Appologies, the file drawer icon is already used in the New Wave user interface. Anyway, having both real and virtual folders is an exellent idea and I'm sure the highly imaginative people at Apple could come up with a way to conseptualize it to minimize confusion. My I expect to see this nifty idea implemented in system 7? TeriAnn
mnkonar@srcsip.UUCP (Murat N. Konar) (06/22/88)
Rather than confuse the user by requiring him/her to differentiate between true (HFS) and virtual (MFS) folders, why not call the virtual folders "envelopes" and give them a unique icon? _____________________________________________________________ disclaimer: I was just thinking...
freeman@spar.SPAR.SLB.COM (Jay Freeman) (06/24/88)
In article <46100167@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: > 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 think that's a useful idea. How about a simple implementation as a display hack: Suppose it worked that whenever I positioned two icons so that they overlapped, the finder noticed it and instead of displaying two overlapping icons it displayed just one icon, a sheaf of documents held together by a paperclip. One could presumably then grab that icon and move all the documents as one; indeed, almost any selection of that icon would be immediately interpretable as a selection of all the clipped-together documents. Exception: I think I would like all the special commands that reorganize the desktop to continue to preserve clipped-together documents, and I would like an additional menu command to spread apart the documents in a (selected) clipped-together sheaf. Maybe there should also be a way to peel the top document off a sheaf, like using a modifier key when mousing on it. If it were done this way, then there would be no need for a special, "make-virtual-folder" command; you'd make a pile of things by putting one thing on top of another, just as we all do with real desktops. (Surely a computer interface for the rest of us should preserve the paradigms whereby we create and manipulate messes.) And at a slightly lower level, the finder info data structure for a file would not need to be changed; it already contains position information and that's all the finder would need to determine whether to display individual icons or clipped-together bunches. I think I would want this hack to work with full-sized or miniature icons, but I think I would like the displays of documents by name, kind, date and so forth to list all documents in a folder, whether or not they were clipped together. -- Jay Freeman <canonical disclaimer -- these are personal opinions only>
phssra@emory.uucp (Scott R. Anderson) (06/24/88)
In article <5195@altaira.srcsip.UUCP> mnkonar@ely.UUCP (Murat N. Konar) writes: > >Rather than confuse the user by requiring him/her to differentiate between >true (HFS) and virtual (MFS) folders, why not call the virtual folders >"envelopes" and give them a unique icon? I think a better metaphor might be that of the "paperclip", since the files are merely "clipped" together at the same level, rather than stuffed out of sight in a folder. The icon would be significantly different, too. * Scott Robert Anderson * ** gatech!emoryu1!phssra * * * ** phssra@emoryu1.{bitnet,csnet} * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
cloos@batcomputer.tn.cornell.edu (James H. Cloos Jr.) (06/24/88)
In article <1437@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes: >In article <46100167@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: > >> 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 think that's a useful idea. How about a simple implementation as a >display hack: Suppose it worked that whenever I positioned two icons so >that they overlapped, the finder noticed it and instead of displaying two >overlapping icons it displayed just one icon, a sheaf of documents held >together by a paperclip. One could presumably then grab that icon and move >all the documents as one; indeed, almost any selection of that icon would be >immediately interpretable as a selection of all the clipped-together >documents. Exception: I think I would like all the special commands that >reorganize the desktop to continue to preserve clipped-together documents, >and I would like an additional menu command to spread apart the documents in >a (selected) clipped-together sheaf. Maybe there should also be a way to >peel the top document off a sheaf, like using a modifier key when mousing on >it. > > If it were done this way, then there would be no need for a special, >"make-virtual-folder" command; you'd make a pile of things by putting one >thing on top of another, just as we all do with real desktops. (Surely >a computer interface for the rest of us should preserve the paradigms >whereby we create and manipulate messes.) And at a slightly lower level, >the finder info data structure for a file would not need to be changed; >it already contains position information and that's all the finder would >need to determine whether to display individual icons or clipped-together >bunches. > > I think I would want this hack to work with full-sized or miniature >icons, but I think I would like the displays of documents by name, kind, >date and so forth to list all documents in a folder, whether or not they >were clipped together. > > -- Jay Freeman > ><canonical disclaimer -- these are personal opinions only> This is by far the best suggestion yet on this topic. The idea to simply alter the system routines to have them look in specific sub-folders w/in the System folder when searching for inits, cdevs, etc. is desireable, and I hope it gets included in the next system release. Jay's proposal, however, is much more useful, and can be applied to many more situations. Further, the implementation would seem to be an order of magnitude easier. In addition to displaying the paper-clipped icon (PCI) whenever two icons are manually overlapped, I would like to see a new entry in the Special menu. This entry is active whenever either multiple icons or a PCI is selected. If a single PCI is selected, the entry would read something like 'Expand Selection' and when selected, would separate all of the icons in the stack a la 'Cleanup Selection' does when a stack of icons are selected. If multiple icons are selected, the entry would read something like 'Collect' and when selected, would stack all of the selected icons, creating a new PCI. The placement of the new PCI would be dependent on what kinds of files were selected. The 1st choice is the top left PCI if any current PCI's are selected. The 2nd choice is the top left normal icon if no PCI's were selected. Whenever a single normal icon or no icons are selected, the entry would be a greyed-out version of the 'Collect' option. The changes to the finder are, in addition to manipulating the new menu entry discussed above, that clicking on a stack of icons now would default to selecting them all. Clicking while depressing the command and/or option key(s) [nb: for simplification in writing, I'll assume below that the option key is the modifier, but any of the 3 choices could be chosen] would chose only the top icon, and then (maybe) scroll thru the other icons in the stack. (Comments on this appreciated, as it might be non-intuitive re: double opt-click would not open the application/document.) Also (the only sticky point I can see) a change would likely be required re: the text displayed w/ the icon. Do you name it, say, PCIn (where n is an unique integer), or still show the name of the top icon plastered over those below it, or let the user give the PCI its own unique name, or sPCi (where s is a string containing a concat of the document types; eg. if cdevs are known as 'Control Panel Device's and inits are known as 'Init Document's then a PCI w/ cdevs and inits is called 'Control Panel Device/Init Document PCI'), or what? I can think of arguments for each of these, but tend to lean toward maintaining the current method. There are manu uses for this feature, and it would seem rather easy to implement in the Finder. I would hope that Apple gives some serious thought to implementing it--and failing that does anyone else out there want to write an application that alters the Finder to add this feature? -JimC -- batcomputer!cloos@cornell.UUCP |James H. Cloos, Jr.|#include <disclaimer.h> cloos@batcomputer.tn.cornell.EDU|B7 Upson, Cornell U|#include <cute_stuff.h> cloos@tcgould.tn.cornell.EDU |Ithaca, NY 14853 |"Entropy isn't what cloos@crnlthry.BITNET | +1 607 272 4519 | it used to be."
dxjsb@dcatla.UUCP (Jack S. Brindle) (06/24/88)
The subject of 'Virtual Folders has been very interesting, but there are some ramifications that are being missed. What happens when the user faces a 'mini-finder' dialog such as that displayed by SFGetFile? He will still see every file in the 'real' directory, plus all those in the 'Virtual' directories. This does not alleviate the cluttered directory problem at all. I would far prefer the "special subdirectory" solution where files with common attributes are placed in a single subdirectory. This allows the mini-finder to work properly and is far less confusing to the user. _THIS_ is what I hope to see (besides IPC) in the 7.0 release! Jack Brindle.
rhsu@topaz.rutgers.edu (Robert Hsu) (06/24/88)
phssra@emory.uucp (Scott R. Anderson) writes: > > why not call the virtual folders > >"envelopes" and give them a unique icon? > > I think a better metaphor might be that of the "paperclip"... An even better idea would be a "pile", since it represents a bunch of files piled together and readily accessible. The icon could be a lot more fun than a mere envelope or a paperclip. To avoid cluttering up the desktop, a different interface could be implemented for such a pile. A limit on the number of files in a pile could be imposed, and instead of opening a window for a pile, a pop-up menu or a modal dialog can be used, or some other "clean" modal interface. This is certainly a good idea, and Apple should definitely consider it. ---------------------------------- Rob rhsu@topaz.rutgers.edu ...!rutgers!topaz.rutgers.edu!rhsu
dtw@f.gp.cs.cmu.edu (Duane Williams) (06/25/88)
I certainly hope that Apple has the good sense to ignore all this nonsense about reincarnating "virtual folders" or creating "clipped together" documents and that they will instead enhance the "poor man's search path." > (Surely a computer interface for the rest of us should preserve the > paradigms whereby we create and manipulate messes.) This is exactly what computer interfaces should avoid. "Clipped together" documents are a pretty dumb idea. If there were a good search path mechanism built into the file system, then the real folders we already have would do everything that "clipped together" documents would do, but in a visibly organized way. -- uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw arpa: dtw@cs.cmu.edu
sbb@esquire.UUCP (Stephen B. Baumgarten) (06/28/88)
In article <6082@dcatla.UUCP> dxjsb@sunb.UUCP (Jack S. Brindle) writes: >The subject of 'Virtual Folders has been very interesting, but >there are some ramifications that are being missed. What happens >when the user faces a 'mini-finder' dialog such as that displayed >by SFGetFile? He will still see every file in the 'real' directory, >plus all those in the 'Virtual' directories. This does not alleviate >the cluttered directory problem at all. One would hope that the entire modal "mini-Finder" idea will go away soon. In case anyone hasn't noticed, it's kind of a kludge, especially in the age of MultiFinder. Since Apple is going to be rewriting things, it would be a good idea to take another look at how HFS is interacted with from within an application; the narrow, claustrophobic view of your disk the mini-Finder gives you (i.e., where am I in relation to other directories? what are some of my sibling directories, etc.) worked well for the original Mac, but ever since HFS and large hard disks, it's been kind of a hack. I won't miss it. On the other hand, I just saw a demo of Open Look at Usenix (it was strictly hand's off, though, since from what I understand if you sneeze it crashes), and the Sun rep was touting the hideous user-interface. One thing she was proud of in particular was an "Open..." dialog box that has a push-pin in it so it stays around after the file is opened (i.e., becomes non-modal). This is wonderful, I guess, but what was more interesting to me was why, after the Mac has been around for 4 years already, you had to *type in* the name of a file (i.e., no scrolling list of appropriate files). She didn't have any good answer to that, except to say that the interface "wasn't finalized" yet. So people in Mac-land shouldn't gripe too much. Apple did a *fine* job and is still way ahead of the pack in many areas. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
sbb@esquire.UUCP (Stephen B. Baumgarten) (06/28/88)
In article <2044@pt.cs.cmu.edu> dtw@f.gp.cs.cmu.edu (Duane Williams) writes: >I certainly hope that Apple has the good sense to ignore all this nonsense >about reincarnating "virtual folders" or creating "clipped together" >documents and that they will instead enhance the "poor man's search path." > >> (Surely a computer interface for the rest of us should preserve the >> paradigms whereby we create and manipulate messes.) > >This is exactly what computer interfaces should avoid. "Clipped together" >documents are a pretty dumb idea. If there were a good search path >mechanism built into the file system, then the real folders we already have >would do everything that "clipped together" documents would do, but in a >visibly organized way. >-- >uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw >arpa: dtw@cs.cmu.edu This is all true, although I don't really know why everyone has problems with the current "solution" (i.e., just throw everything in the System Folder in a big jumble). I agree it makes things hard to organize, but what exactly are you organizing, anyway? I mean, there are no runnable programs in the System Folder, and really there are no double-clickable documents either. I only rarely ever look in there -- mostly it just stays closed and buried off in the corner. The only time I ever mess with it is to add new INITs, and this doesn't happen very often, so it's not a big problem to find them (especially if you use DiskTop to find all files of type INIT or cdev). A
gersh@aplvax.jhuapl.edu (John R. Gersh) (06/29/88)
In article <443@esquire.UUCP> sbb@esquire.UUCP (Stephen B. Baumgarten) writes: > >This is all true, although I don't really know why everyone has problems >with the current "solution" (i.e., just throw everything in the System >Folder in a big jumble). ... > I tend to agree with this, at least as far as System Folder organization goes. What I do (admittedly only useable on a Mac II) is to organize the System Folder by color. System files are blue, INITs orange, cdevs cyan, etc. This allows easy visual recognition of what's what and permits View by Color to list things by type.
twakeman@hpcea.CE.HP.COM (Teriann Wakeman) (06/29/88)
>/ hpcea:comp.sys.mac / dxjsb@dcatla.UUCP (Jack S. Brindle) / 7:38 am Jun 24, 1988 / >The subject of 'Virtual Folders has been very interesting, but >there are some ramifications that are being missed. What happens >when the user faces a 'mini-finder' dialog such as that displayed >by SFGetFile? He will still see every file in the 'real' directory, >plus all those in the 'Virtual' directories. This does not alleviate >the cluttered directory problem at all. (second paragraph deleted) >Jack Brindle. ---------- To me that is exactly the beauty of having HFS and MFS containers together. You can use MSF containers to limit visual clutter of things that you would want to see in a single SFGetFile. That way you could scroll down the list ruther then search multiple folders. And when you are in the desktop you can have things arranged into easer to locate subcatagories. TeriAnn
freeman@spar.SPAR.SLB.COM (Jay Freeman) (06/29/88)
In article <443@esquire.UUCP> sbb@esquire.UUCP (Stephen B. Baumgarten) writes: >In article <2044@pt.cs.cmu.edu> dtw@f.gp.cs.cmu.edu (Duane Williams) writes: >>I certainly hope that Apple has the good sense to ignore all this nonsense >>about reincarnating "virtual folders" or creating "clipped together" >>documents and that they will instead enhance the "poor man's search path." >This is all true, although I don't really know why everyone has problems >with the current "solution" (i.e., just throw everything in the System >Folder in a big jumble). I agree it makes things hard to organize, but >what exactly are you organizing, anyway? > Anyway, is this more of an aesthetic issue, or >am I missing something? I suggest that the issue is certainly wider than the system folder -- the various schemes proposed would all apply to iconic displays in any folder, or on the desktop. I think that it is precisely an aesthetic issue. I would find iconic displays more appealing and useful if I could pile icons one on top of another and then manipulate them as one, with some systematic hint to remind me that the front one is hiding others behind it. I like the ability to tell at a glance, from the icon, what kind of document I am looking at, but I find a folder or desktop with lots of icons to be confusing. I find myself making little heaps of the icons I am not presently interested in, and putting them off in one corner of the folder, or whatever. But such a heap looks messy in its own right, and if I neaten everything up squarely then a maximium-sized icon with a long name will hide everything behind it, and perhaps "help" me forget that the others are there. And of course, whenever I do "option clean-up", the finder will unstack my pile of icons, so I have to stack them up again, and then rearrange all the other icons more compactly. Sure, I could put things in extra folders, but often I would rather not. After all, it isn't the software that minds looking through lots of icons, it's me! It seems silly to have to create a folder, and perhaps (in an optimistic future) change a search path or (presently) change path-names embedded in "make" files, just because I want a visual display that I personally find more useful or appealing. Besides, my choices as to what's stacked and what isn't vary from day to day, sometimes from minute to minute. Perhaps I have everything stacked up except for a few files that I am presently working on. Perhaps I have a desktop pile of unrelated things to be worked on, from which I peel documents one at a time. In the latter case I specifically do not want to put the documents in a separate folder, because I intend to "put away" each one when I am done with it, and I do not want it to forget the identity of the folder in which it originally resided. I think the issue is completely orthogonal to that of search path -- I agree in any case that Apple's search-path convention is not as powerful as it should be. But whether they fix the search-path mechanism or not, I would also like to be able systematically to display and manipulate icons in groups that are minimal in extent on the screen, that retain identity when selected or dragged, and that do not spread apart when the rest of the desktop or folder is reorganized. -- Jay Freeman <canonical disclaimer -- these are my opinions only>
chow@batcomputer.tn.cornell.edu (Christopher Chow) (06/29/88)
In article <956@aplcomm.UUCP> gersh@aplvax.jhuapl.edu.UUCP (John R. Gersh) writes: |In article <443@esquire.UUCP| sbb@esquire.UUCP (Stephen B. Baumgarten) writes: || ||This is all true, although I don't really know why everyone has problems ||with the current "solution" (i.e., just throw everything in the System ||Folder in a big jumble). ... || | |I tend to agree with this, at least as far as System Folder |organization goes. What I do (admittedly only useable on a Mac II) is |to organize the System Folder by color. System files are blue, INITs |orange, cdevs cyan, etc. This allows easy visual recognition of what's |what and permits View by Color to list things by type. This brings up something which I'm disappointed at with the Finder. Since the color menu dosen't show up unless you're in 16-color mode or better, why is there only 8 colors in the color menu? Very often I wished that I had more colors avaliable when I organize a group of files in a folder by color (e.g., green = disk utils, red = apple sys utils, etc.) At a minimum the color menu ought to support 16 colors, and the colors should be user choosable! What do other Mac II owners think? Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-272-8014 Address: 107 Catherine St, Ithaca NY 14850 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
peter@aucs.UUCP (Peter Steele) (06/29/88)
> This is all true, although I don't really know why everyone has problems > with the current "solution" (i.e., just throw everything in the System > Folder in a big jumble). I agree it makes things hard to organize, but > what exactly are you organizing, anyway? I mean, there are no runnable > programs in the System Folder, and really there are no double-clickable > documents either. I only rarely ever look in there -- mostly it just stays > closed and buried off in the corner. The only time I ever mess with it > is to add new INITs... Some of us are organization freaks so even if we don't look in the system folder frequently we liked to keep things respectable (just in case company comes!). If found my system folder used to be a mess until I adopted an organization and stuck to it. Now it's probably the best organized folder on my hard disk. What I did was organize the system folder files as horizonal rows of icons. The first row I call "System files", identified by a dummy folder on the extreme left of this row by this name. If I have to add another system file, I scroll to the right end of the row and add it there. My next row is called INITs/cdevs, again identified by a folder by this name, and again used only as a tag for the column (the only thing I put in the folder are INITs and cdevs that I don't want to use). When I add a new INIT or cdev, I scroll to the far right and add it to the end of the row. I always do a cleanup selection on the new icon to make sure it's positioned just right (like I said, some of us are organization freaks). My next row is one I call Fonts/DAs. This one is a little different. The files that I keep opposite this folder are only my laserwriter downloadable fonts. The screen fonts and DAs that I use I keep in the folder itself rather than along side it like my INITs and cdevs row. I do this primarily because I have Suitcase and it automatically looks for fonts and DAs in a folder by this name, so I make use of this feature. I'd do the same with my INITs and cdevs if the system automatically looked in a particular folder. I have some other rows, one called "misc" where I put things like help and preferences files, one called Sounds where I put my digitized sounds, and others I as need them. So life in my system folder is quite acceptable since I've made a concerted effort into keeping it organized. I'd still like to see the system look in certain folders, however, on boot-up for things like fonts, das, cdevs, inits, system files (the printer drivers and all those other files that are part of the Mac system). -- Peter Steele, Microcomputer Applications Analyst Acadia University, Wolfville, NS, Canada B0P1X0 (902)542-2201x121 UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!Peter BITNET: Peter@Acadia Internet: Peter%Acadia.BITNET@CUNYVM.CUNY.EDU
tecot@Apple.COM (Ed Tecot) (07/01/88)
All this talk about these horrid virtual folders makes me glad that we do user testing before making interface changes. If you have a hard time understanding why it is so bad, try explaining it to your grandparents. _emt
cyosta@taux01.UUCP (Yossie Silverman) (07/02/88)
In article <13123@apple.Apple.COM> tecot@apple.apple.com.UUCP (Ed Tecot) writes: >All this talk about these horrid virtual folders makes me glad that we do user >testing before making interface changes. > >If you have a hard time understanding why it is so bad, try explaining it to >your grandparents. > > _emt Well. I would like to throw in my own $0.02 of thought. UN*X has always had the "invisible" files (invisible under the ls command). The method they adopted was to mark the file with a "." as its first character. I don't think this is a very nice method to use in Finder but I think "virtual" folders would do the job in a similar manner. Finder is an integral part of the Mac environment (you can't even turn it off under MultiFinder) and so I think that it should have some special file display facilities that other programs wouldn't have, like minifinder (not the application, the SFGetFile one). The minifinder CAN'T sort by date,type, etc.. Nor can it display by small ICON or even by ICON! Why should there be any problem with not allowing it to display "virtual" folders? "virtual" folders should be treated as what they are, a way of looking at your disk without cluttering the display with unneeded information. Another possibility would be to add a menu ITEM "Show Hidden" and another "Hide" the first of which would display all hidden files, wherever they may be positioned, the second of which would Hide/Unhide a file (should work in any view mode). I think the "virtual" folder method is nicer, but the second method has some merit too! -- Yossie Silverman What did the Caspian sea? National Semiconductor Ltd. (Israel) - Saki UUCP: taux01!yossie@nsc.UUCP NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOCLAY ITAY
tecot@Apple.COM (Ed Tecot) (07/11/88)
In article <1137@aucs.UUCP> peter@aucs.UUCP (Peter Steele) writes: >Some of us are organization freaks so even if we don't look in the >system folder frequently we liked to keep things respectable (just >in case company comes!). If found my system folder used to be a >mess until I adopted an organization and stuck to it. Now it's >probably the best organized folder on my hard disk. What I did was >organize the system folder files as horizonal rows of icons. The >first row I call "System files", identified by a dummy folder on the >extreme left of this row by this name. If I have to add another system >file, I scroll to the right end of the row and add it there. I do something similar, except I use the small icon view and organize by columns. The first column, like Peter, is System stuff (System, Finder, Clipboard File, Scrapbook File, MultiFinder, DA Handler, Macintalk, Macsbug, Responder (you ARE using Responder, aren't you?), Easy Access, Key Layout, etc.) The second column is Chooser and Printing stuff (Appletalk ImageWriter, LaserWriter, Laser Prep, AppleShare, AppleShare Prep, PrintMonitor, Spool Folder, etc.) The next column is Control Panel stuff (I won't name any), and the fourth and final column is for miscellaneous things, such as MacWrite Options. _emt
twakeman@hpcea.CE.HP.COM (Teriann Wakeman) (07/16/88)
>(You are using Responder aern't you?)
What Prey tell is Responder??????
TeriAnn
HPMUG