tonyrich@titanic.cs.wisc.edu (Anthony Rich) (10/11/89)
This rather long posting is:
1) An observation about the conventional use and abuse of filenames.
2) An plea to Apple to prevent things from getting worse in System 7.0.
3) A few suggestions as to how that could be done.
BACKGROUND
A previous posting to this newsgroup suggested that System 7.0 should allow
filename pattern searches, so that one could, for example, find all
Stuffit files by searching for filenames ending in ".sit". Applications,
scripts, or people could then use filename pattern-matching to select and
process a group of related files.
The goal is good, but I think the technique of matching filename patterns
is the *WRONG* way to get the job done. Apple, please DON'T!
A filename should simply be a meaningful name that tells a person a file
contains, or, if it's a program, what it is or does. That's ALL it should be.
Trouble is, it has become common practice to "encode" additional
information into filenames, like the file's type, its version number,
whether it has been compressed, and the like. It's not unusual to see
files with cryptic names like "xmodem17.hqx". Filenames aren't the right
place to store all that information, and pattern matching based on nonstandard
naming conventions isn't a reliable file lookup method.
WHAT I'M AFRAID MIGHT HAPPEN
My fear is that if System 7.0 makes it easy to do filename pattern matching,
people are going to be even more encouraged to rely on filename encoding,
either sticking with the old MS-DOS "8-dot-3" format for compatibility,
or even worse, NOT sticking with it and introducing all kinds of nonstandard
conventions. There's the potential for a big step backward in user-
friendliness for the Mac, and it will make it impossible to develop utility
programs or scripts which *reliably* find and process groups of related
files. The mechanism may defeat the goal.
DISCUSSION OF THE PROBLEM
The basic problem is that it takes a lot of info to describe a file.
MS-DOS or Unix file systems don't store much info about files, but the
Mac does better. For example, version numbers can be stored separately
from filenames and can be viewed by picking Get Info from the FILE menu.
With a little effort, I think the Mac can do much better.
Even though the Mac stores more info about files than other filesystems,
System 6.0.x still has at least three serious drawbacks:
1. You can't see enough of the extra file info on the desktop without
asking for it (e.g., using "Get Info").
If you use "View by Icon" you see only the filename and icon.
"View by Date" shows you a couple more facts that you may not care
about and omits some interesting things that you might, such as
a program's version number. That's why people compensate by encoding
the extra info (redundantly) into the filename or even its icon,
just so it's always directly visible.
2. The system stores only a few predetermined facts about a file.
Since it's impossible for Apple or anyone else to predict in advance
ALL the interesting facts someone might want to store about a file,
there should be some way of storing lots more *arbitrary* information
about a file instead.
3. There isn't an easy way for the casual user to write, access, and
change the system-stored information about files.
For example, how does one set the version number that appears in the
"Get Info" box? I don't consider using ResEdit or writing a program
to alter file info or to create resources "easy for casual users."
But changing a filename is, which is why users stuff file info into
filenames now.
SOME SUGGESTED IMPROVEMENTS
So how can we improve the situation in future versions of the System?
Here are a couple of suggestions. I'll bet you can think of more.
1. Allow ANY combination of items of the system-stored file info to be
displayed on the desktop in some kind of compact, legible format.
Let me, the casual user, select what info should be displayed in the
"View by Date" columns, maybe. Or using "View by Icon", let me show
a file's version number on a line under the filename. I should be able
to set up the Finder so that it shows me any info about files that I
want to see. I don't want canned choices like those in the current
"View by Date", "View by Icon" menu; or if you want to keep those
options for old-time's sake, add a "Custom View..." choice that lets
me freely customize what file info is shown and how it is displayed.
BENEFIT: Users don't have to encode file info into the filename to see it.
2. Give me a "File Info" dialog box that has at least two user-writable
fields in it: KEYWORDS and NOTES.
The FILE INFO dialog box should display everything that "Get Info"
displays now. It should also contain two HyperCard-like fields which
allow me to add more info about a file by just typing it in. I want
the FILE INFO to pop up when I option-click on the file icon; I don't
want to have to first select the file and then go paw at "Get Info" on
a menubar to get to it.
This File Info box should have a predefined subfield on it labelled
KEYWORDS. There I can type any list of keywords or phrases that I
want to. This allows me to use KEYWORD RETRIEVAL to locate files and
to select groups of files more reliably and flexibly than by pattern-
matching encoded filenames. You could provide a scrolling list of
STANDARD keywords in this box that I can choose from, too, that
Apple system utilities and third-party applications would recognize:
"Pascal", "PICT", etc. They wouldn't be limited to 4 characters like
resource IDs are, although resource IDs could be included.
There should also be a free-form NOTES field where I can enter any
information I want to about the file. If I later want to do text
searches for strings in this field (either instead of or in addition
to searching in the previous KEYWORD field), I should be able to do
that; otherwise the System can ignore the contents of this field. If
I want to use it as a notes file or as a "read-me" associated with the
underlying file, I could do that, too. It would save having to create
a separate text document that might get separated from the original
file. Rebuilding the desktop wouldn't destroy it.
BENEFIT: Files can be reliably located by matching Apple-standard
or user-defined keywords or user-defined text strings rather
than relying on cryptic, nonstandard filename conventions.
Perhaps there should be other fields the System could use, too.
A File Info box could contain a list of applications which can
or should be used to open the document if the application that created it
isn't found, for example. If a user double-clicked a document when an
appropriate application wasn't present, the alert box that comes up could
then say something more informative, such as "One of the following
applications is needed to open this document: ..."
One last wish. Normally, when one tries to copy a file into a folder that
already has a file by that name, an alert asks "Replace item(s) with the
same name?" Clicking "NO" aborts the operation. But if managed system
info like *file version numbers* are always user-visible, the Finder can do
a better job. If the version numbers differ, the operation should complete
normally, since there really isn't a conflict! If the version numbers are
the same, the user could 1) abort the operation, 2) request that one of the
version numbers be incremented, or 3) add a distinguishing KEYWORD or NOTE
to the File Info information to allow the copy operation to continue.
Bringing file version numbers out of the closet could be useful when a user
selects "SAVE" within an application, too. A user could ask to create a
higher-numbered version of the file (keeping the same name) instead of
overwriting the existing file. Or an application could provide a "SAVE AS
NEW VERSION" menu item which does that automatically.
To summarize: Let me store and show more file info, give me keyword search,
and don't do filename pattern-matching in System 7.0.
If not, I'll bet we're right back to cryptic, nonstandard MS-DOS naming
conventions, and we'll severely undermine the usefulness of a command-line
interface or scripting capability.
** Claimer: These ideas and opinions are strictly my own, but if you like
them, you can have them, too. They're free.
paryavi@harris.cis.ksu.edu (Saiid Paryavi) (10/11/89)
In article <8821@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: >This rather long posting is: > 1) An observation about the conventional use and abuse of filenames. > 2) An plea to Apple to prevent things from getting worse in System 7.0. > 3) A few suggestions as to how that could be done. > One other addition that would be nice is a small visible area (maybe a small question mark icon) under the file/folder name that one could click to get the information stored in the Get Info part of the file instantly right there on the desktop. -- Saiid Paryavi Computer Science Dept. Internet: paryavi@harris.cis.ksu.edu Nichols Hall BITNET: paryavi@ksuvax1.bitnet Kansas State University UUCP: {rutgers, texbell}!ksuvax1!harry!paryavi Manhattan, KS 66506
erc@pai.UUCP (Eric Johnson) (10/11/89)
In article <8821@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > This rather long posting is: > 1) An observation about the conventional use and abuse of filenames. > 2) An plea to Apple to prevent things from getting worse in System 7.0. > 3) A few suggestions as to how that could be done. > > BACKGROUND > > A previous posting to this newsgroup suggested that System 7.0 should allow > filename pattern searches, so that one could, for example, find all > Stuffit files by searching for filenames ending in ".sit". Applications, > scripts, or people could then use filename pattern-matching to select and > process a group of related files. > > The goal is good, but I think the technique of matching filename patterns > is the *WRONG* way to get the job done. Apple, please DON'T! Right or wrong doesn't matter to me (I don't want to make ethical judgements on how others names files :-), but I suspect we use our computers for different things. For example, I often program using the C language. Most C source files are given a name ending in ".c" and most C header files are given a name ending in ".h"--these conventions may be right or wrong, but they are all-pervasive. I, for one, want to at least try to port source files between machines and operating systems. One of the major benefits of C is that C compilers exist for just about every computer (you can get UNIX and C on a Cray supercomputer, you can get C on a parallel Transputer and you can even get C on an MS-DOS PC). So, why do I want filename-based searches on the Mac? Because every day on UNIX I use filename-based searches and I find these searches invaluable (e.g., grep socket *net*.c ). Other times I want to back up all the source files (based on the principle that I can always re-compile to generate the executable applications if I just have the source), using *.c, *.h and so on. Anyway, one of the benefits of a command-line interface is the ability to use wildcards in filename-based searches (which is one of maybe two things that are easier to do on a PC than on the Mac). So, Apple, please DO! > A filename should simply be a meaningful name that tells a person a file > contains, or, if it's a program, what it is or does. That's ALL it should be. > Trouble is, it has become common practice to "encode" additional > information into filenames, like the file's type, its version number, > whether it has been compressed, and the like. It's not unusual to see > files with cryptic names like "xmodem17.hqx". Filenames aren't the right > place to store all that information, Sorry, but this is common practise. Right or not, this method is used. One reason may be that listing the names of the files in a directory is often the most information you will get about the contents of the files. UNIX does have a "file" command that will try to guess the type of a file (e.g., executable, ascii text, c program, awk script, etc.), but still most people use the file name method. > and pattern matching based on nonstandard > naming conventions isn't a reliable file lookup method. Right, but it works most of the time. > WHAT I'M AFRAID MIGHT HAPPEN > [deleted due to space] You have a lot of good arguments, but I feel filename-based searches would add a lot to the already-nice Mac interface. Perhaps Apple's user interface guidelines could help limit abuse of this feature. In the end, though, the features you ask for would be nice, but I would still want filename-based searches. Have fun, -Eric -- Eric F. Johnson, Prime Automation, Inc. 415 W. Travelers Trail, Burnsville, MN 55337 USA. Phone: +1 612-894-0313. erc@pai.mn.org - or - bungia!pai!erc (We have a very dumb mailer, so please send a bang-!-style return address.)
pepke@loligo (Eric Pepke) (10/11/89)
Anthony Rich's ideas are excellent. The details of the user interface would have to be worked out, however, but the nice thing is that all of this could be done in the Finder in such a way as to provide compatibility with existing programs. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
bj@gvgspd.GVG.TEK.COM (Brion Johnson) (10/11/89)
While we are at it, please lets have all "Get Info" contents stored in the file, not in the desktop, so that it doesn't go away when the desktop has to be rebuilt! Brion
d88-jwa@nada.kth.se (Jon W{tte) (10/12/89)
In article <8821@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: >This rather long posting is: > 1) An observation about the conventional use and abuse of filenames. > 2) An plea to Apple to prevent things from getting worse in System 7.0. > 3) A few suggestions as to how that could be done. "Rather" is an understatement... But I liked it. >** Claimer: These ideas and opinions are strictly my own, but if you like > them, you can have them, too. They're free. > Thanx. Yes, DON'T USE FILENAME EXTENSIONS FER GOSSAKE ! (Now that's said) And LET THE USER CHANGE THE VERSION NUMBER in the "info". I mean, he can change the "SIZE" resource IN USE (two copies - original and in use) so why not the "vers" resource ? (N.b. this would be the definate end of files with no resource fork: you'll have to store data about the file IN THE FILE (that's logical anyway) and keep a copy in the desktop for performance reasons.) And yeah, more things should use the option key. I mean, it's got to be there for some reason !? Why have Command-Shift-# for function keys, when you can use the option key ? Or Ctrl-Cmd-Shift-Cokebottle for "hidden" things in applications ? Or the SHIFT key to change menu selections meanings ? USE the option key ! (This was also brought up before) And, of course, give me protected memory. If anyone cares to mail me the docs for the MMU, I'll hack an init that does this (well... no promises :-) h+@nada.kth.se -- Reality's the only obstacle to happiness.
czychi@ethz.UUCP (Gary Czychi) (10/12/89)
Thank you, Anthony Rich, this is a superb idea. I come from the MS/DOS
and DEC-VMS world and this is exactly why I hate it.
Your ideas are *really* Mac-Like: New, different and BETTER.
I have to regularly update several hundreds of Mac files in a couple of
folders and have to include the version info even into the folder name!
What I fear however is, that Apple already has decided how system 7.0
will look like and that this idea won't benefit us. Maybe with system
8.0 or even later, when IBM, Microsoft and NeXT have it...
Gary
Gary T. Czychi University of St.Gallen, Switzerland
CZYCHI@CSGHSG52.bitnet (preferred)
CZYCHI@ETHZ.uucp
Tel.: --41 / 71 / 28 30 55
Disclaimer: My words are my own.
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (10/13/89)
In <885@gvgspd.GVG.TEK.COM> bj@gvgspd.GVG.TEK.COM (Brion Johnson) writes: >While we are at it, please lets have all "Get Info" contents >stored in the file, not in the desktop, so that it doesn't >go away when the desktop has to be rebuilt! Hear, hear! M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
zeller@ethz.UUCP (Lukas Zeller) (10/15/89)
In article <8821@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > [Some very interesting alternatives to pattern-matching for file names and > a vote against including the latter in System 7.0] In article <700@pai.UUCP> erc@pai.UUCP (Eric Johnson) replies: >[...] I suspect we use >our computers for different things. For example, I often program using >the C language. Most C source files are given a name ending in ".c" and >most C header files are given a name ending in ".h"--these conventions >may be right or wrong, but they are all-pervasive. > [...] >So, why do I want filename-based searches on the Mac? Because >every day on UNIX I use filename-based searches and I find these >searches invaluable (e.g., grep socket *net*.c ). Other times >I want to back up all the source files [...] using *.c, *.h and so on. I agree with the first part of the sentence above: I'd like to back up all my source and header files without having to select them one by one, too. But do we need wildcards for that ? I don't think so. When you type "*.c" in UNIX, what you want to say is: "all C source files". And only because a *property* of the file (the fact that it contains C source) is encoded in the *name* of the file instead of being kept as a separate piece of information, you need wildcards to extract it. In the file system proposed by Anthony Rich the "keyword" list would contain entries labelled "C source file" or "C header file". Selections could then be based on a keyword: Option clicking a file would bring up the Info dialog box with a list of keywords. You would select "C source file" from the list and hit a "Select files with same keyword" button. Of course, most probably the details would be different (I'm not a human interface designer) but the need for wildcards would be eliminated. Even with today's finder it is obvious how additional properties of the file (location, type, creator and color) make wildcards more and more useless: Nobody could survive a single day without wildcards under UNIX, but most Mac users have, since 1984 :-) >> Trouble is, it has become common practice to "encode" additional >> information into filenames, like the file's type, its version number, >> whether it has been compressed, and the like. It's not unusual to see >> files with cryptic names like "xmodem17.hqx". Filenames aren't the right >> place to store all that information, > >Sorry, but this is common practise. Right or not, this method is >used. (mild flame) If the MAC OS had been built on what was "common practise" then, you could not distinguish it from MS-DOS today. Is that what you want for the future ? (mild flame off) > One reason may be that listing the names of the files in >a directory is often the most information you will get about the >contents of the files. Exactly. And that's the reason why we need an extended "Info" box, and NOT a method that encourages encoding additional information into file names. > UNIX does have a "file" command that will >try to guess the type of a file (e.g., executable, ascii text, c program, >awk script, etc.), but still most people use the file name method. (mild flame) If this command would not *guess* but *know* about the file contents without reading the file and then doing some statistics (many ((((())))) --> LISP, for example :-), and if "find" was not a separate command but a part of "ls", the "file name method" would be far less popular. (mild flame off) >You have a lot of good arguments, but I feel filename-based searches >would add a lot to the already-nice Mac interface. Perhaps Apple's >user interface guidelines could help limit abuse of this feature. I fear that wildcards would destroy more of the user interface's consistency than they would add to its functionality. And because consistency is THE philosophy behind the "user interface guidelines", I doubt if Apple will include wildcards. Maybe System 7.0 will prove me wrong :-( ========================== +---------------------------+ ***************** Lukas Zeller |\ E-Mail: /| * Never trust a * ETH Zurich, Switzerland | \_______________________/ | * computer * (SFIT, Swiss Federal | / zeller@ethz.UUCP \ | * bigger than * Institute of Technology) | / ..cernvax!ethz!zeller \ | * you can lift * ========================== +---------------------------+ *****************
allbery@NCoast.ORG (Brandon S. Allbery) (10/15/89)
As quoted from <8821@spool.cs.wisc.edu> by tonyrich@titanic.cs.wisc.edu (Anthony Rich): +--------------- | whether it has been compressed, and the like. It's not unusual to see | files with cryptic names like "xmodem17.hqx". Filenames aren't the right +--------------- Most of these files are so named because they are often stored on or used by programs intended for different systems: for example, OzTeX keeps the *.tex naming convention because the TeX copyleft requires that a TeX pass the "trip test" and this is undoubtedly part of the test, and *.hqx is because BinHex files are intended for storage on Unix or VMS systems which don't have "Get Info..." boxes. Standard Mac programs which use this convention, however, should be regarded as violating the User Interface Guidelines. +--------------- | programs or scripts which *reliably* find and process groups of related | files. The mechanism may defeat the goal. +--------------- See above. The change doesn't have to be made to the System or Finder, but to the User Interface Guidelines. And anyone who uses a method not compatible with StdFile to get their file names (e.g. file extensions) deserves what they get. +--------------- | 1. Allow ANY combination of items of the system-stored file info to be | displayed on the desktop in some kind of compact, legible format. +--------------- How slow do you want the Finder to be, anyway? Remember, the display format is stored on a per-folder basis. Having to compute an arbitrary display format upon folder open of a large folder (say, the blessed folder) is going to bog down even a IIci. +--------------- | One last wish. Normally, when one tries to copy a file into a folder that | already has a file by that name, an alert asks "Replace item(s) with the | same name?" Clicking "NO" aborts the operation. But if managed system | info like *file version numbers* are always user-visible, the Finder can do | a better job. If the version numbers differ, the operation should complete | normally, since there really isn't a conflict! If the version numbers are +--------------- NO!!!!!!!! This requires that version numbers or the other distinguishing information be visible, or the user is going to get extremely confused. Are the concepts behind the User Interface Guidelines now considered Politically Incorrect? You might also consider that DEC operating systems have traditionally supported version numbers. I haven't missed them under Unix *or* Macintosh. In this particular case, the file name is where the distinguishing information *should* go. I don't want to be forced to open some special window (option-click within StdFile or etc.) to be able to distinguish between two or more files with the same name. Your suggestions are well intended, but will turn the Mac into another ugly user-hostile environment. +--------------- | If not, I'll bet we're right back to cryptic, nonstandard MS-DOS naming | conventions, and we'll severely undermine the usefulness of a command-line | interface or scripting capability. +--------------- The User Interface Guidelines are quite sufficient to prevent this, since users given a choice between a StdFile-compatible interface and 8.3[;ver] are going to choose the former. Let's not cure a hangnail by amputation, eh? ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
macman@ethz.UUCP (Danny Schwendener) (10/15/89)
> A previous posting to this newsgroup suggested that System 7.0 should > allow filename pattern searches, so that one could, for example, find all > Stuffit files by searching for filenames ending in ".sit". The basic idea is to include the "find file" DA into the Finder. You have to be able to find at least a pattern at any position of a filename (e.g. "street map" in "N Camarillo street map(1989)"). Explicit use of wildcards is, in my opinion, not an absolute necessity. Keep in mind that what has made the Macintosh System so attractive, was that it was very easy to use, even for complete computer neophytes. And I think that adding options that are nice to some power users, but complicate the learning process to the new users, is *not* a good idea. > The FILE INFO dialog box should display everything that "Get Info" > displays now. It should also contain two HyperCard-like fields > which allow me to add more info about a file by just typing it in. > [...] There should also be a free-form NOTES field where I can enter any > information I want to about the file. Whoa! A Get-Info box of the kind you'd like would take up the whole screen. Why do you need *three* fields for your personal information? I think one single editable text field which will not be deleted when you rebuild the desktop is nice. And I agree that Find-File should be able to look at the information in this field. Most people will not use the File-Info/Notes field. And even more people would ignore the Keywords field, if it was to be implemented. I like the idea of finding by Keywords, and I think the File-Info/Notes field is a great place for this. Keep the Finder simple. -- Danny DISCLAIMER: These are my opinions. Leave my employers alone.
mcdonald@uxe.cso.uiuc.edu (10/16/89)
Why add wildcard searches to the MAC, rather than some sort of keywords attached some other way. Simple. Obvious: flexibility. The *USER** can attach whatever meaning he wishes to a filename - with zero additional work, as a file has to have a name. And he could use that info any way he wishes. That is the real beauty of UNIX, and other real OS shells. Flexibility - do what you wish. The user is not limited to what the system designer wants him to do. The MAC has a reasonably good, in fact very good, user interface inside programs. But the top-level shell, the "finder", is excruciatingly bad due to its limitations. Apparently even APPLE recognizes this, as their development environments provide more functionality. So, the bottom line is - provide an info section as part of files directory entries - but allow using any part of it - including the name, with the usual wildcards (or regular expressions) to do searches, copies, deletes, etc.
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (10/17/89)
In article <2245@ethz.UUCP> macman@ethz.UUCP (Danny Schwendener) writes: >The basic idea is to include the "find file" DA into the Finder. You >have to be able to find at least a pattern at any position of a filename >(e.g. "street map" in "N Camarillo street map(1989)"). Explicit use of >wildcards is, in my opinion, not an absolute necessity. I believe Apple has announced that they intend to have a find command in their new version of the Finder scheduled with 7.0 (I recall a magazine article: "...the Finder finally will...") Wildcards, I don't know. -Sho -- sho@physics.purdue.edu